Analise de Requisitos Software

Rildo Santos (rildo.santos@etecnologia.com.br) | www.etecnologia.com.br
Versão 29/2014
Analise de Requisitos de Software
Todos os direitos reservados e protegidos © 2014
Análise de Requisitos de Software
Rildo Santos (@rildosan)
rildo.santos@etecnologia.com.br http://rildosan.com
http://etecnologia.ning.com/
(11) 99123-5358 (11) 99962-4260
www.etcnologia.com.br
@rildosan | Versão: 29

Versão 29/2014
A empresa:
Gestão de Processos Análise de Negócio Gestão de Risco Métodos Ágeis e Lean Engenharia de Software Análise de Requisitos de Software Inovação e Empreendedorismo
Planejamento Estratégico Design de Serviços Design Thinking
Gestão de Serviços de TI Governança de TI

Versão 29/2014
O programa Menos Papel, Mais Árvores®, é uma ação, com objetivo de estimular o consumo sustentável de papel dentro das organizações.
Programa: “Menos Papel, Mais Árvores ®”
Qual é o mundo que queremos ? O primeiro passo para criar um mundo melhor, é saber qual tipo de mundo que queremos ter e qual tipo que deixaremos de herança para as próximas gerações.
Nossa missão: É buscar pelo equilibro do homem, da tecnologia e do meio ambiente.
Para cumprir esta missão é necessário: mobilizar, conscientizar, comprometer e AGIR.
Quer participar ? - Reduza o uso de papel (e de madeira) o máximo possível.
- Só imprima se for extremamente necessário.
- Evite comprar produtos com excesso de embalagem.
- Ao imprimir ou escrever, utilize os dois lados do papel. - Use papel reciclado.

Versão 29/2014
* http://www.slideshare.net/Ridlo/presentations :
Compartilhamento de Conhecimento:
Compartilhamento de conhecimento é parte da missão da aTecnologia:
Contribuir para que nossos clientes, profissionais, professores e alunos alcancem melhorias de desempenho que sejam duradouras, substanciais e sustentáveis. Publicamos nossas ideias para ajudar disseminar práticas da gestão, ser fonte de inspiração para líderes e para facilitar a tomada de decisão.
* Mais de 1.000.000 de views

Versão 29/2014
5
Conteúdo:
Sobre o Autor
Sobre a Apresentação
Introdução
1 – Requisitos de Software
2 - Identificação e Elicitação de Requisitos
3 - Análise de Requisitos
4 - Especificação de Requisitos com Caso de Uso
5 - Validação de Requisitos
6 - Gerenciamento de Mudança de Requisitos
Anexo

Versão 29/2014
6
Sobre o autor:
Rildo Santos
Coach e Consultor de Gestão de Negócios, Inovação e Tecnologia para a Gestão 2.0, a Gestão Ágil.
A Gestão Ágil ajuda as empresas a responder mais rápido as demandas de negócio e mudanças. A Gestão 2.0, abrange Planejamento Estratégico, Gestão por Processos Ágeis, Gestão de Projetos Ágeis, Tecnologia da Informação (Métodos Ágeis), Inovação e Liderança.
Minha Experiência:
Tenho mais de 10.000 horas de experiência em Gestão de Negócios, Gestão de Inovação, Governança e Engenharia de Software. Formado em Administração de Empresas, Pós-Graduado em Didática do Ensino Superior e Mestre em Engenharia de Software pela Universidade Mackenzie.
Fui instrutor de Tecnologia de Orientação a Objetos, UML e Linguagem Java na Sun Microsystems e na IBM.
Conheço Métodos Ágeis (SCRUM, Lead, FDD e XP), Arquitetura de Software, SOA (Arquitetura Orientado a Serviço), RUP/UP - Processo Unificado, Business Intelligence, Gestão de Risco de TI entre outras tecnologias.
Sou professor de curso de MBA da Fiap e fui professor de pós-graduação da Fasp e IBTA.
Possuo fortes conhecimentos de Gestão de Negócio (Inteligência de Negócio, Gestão por Processo, Inovação, Gestão de Projetos e GRC - Governance, Risk and Compliance), SOX, Basel II e PCI;
E experiência na implementação de Governança de TI e Gerenciamento de Serviços de TI. Conhecimento dos principais frameworks e padrões: ITIL, Cobit, ISO 27001 e ISO 15999;
Desempenhei diversos papéis como: Estrategista de Negócio, Gerente de Negócio, Gerente de Projeto, Arquiteto de Software, Projetista de Software e Analista de Sistema em diversos segmentos: Financeiro, Telecomunicações, Seguro, Saúde, Comunicação, Segurança Pública, Fazenda, Tecnologia, Varejo, Distribuição, Energia e Petróleo e Gás.
Possuo as certificações: CSM - Certified SCRUM Master, CSPO - Certified SCRUM Product Owner , SUN Java Certified Instrutor, ITIL Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games;
Onde estou: Twitter: @ridldosan Blog: http://rildosan.com/

Versão 29/2014
7
Sobre o Apresentação
Esta apresentação discute e fornece informação sobre o Ciclo de Requisitos de Software, indo da elicitação até a especificação de requisitos de software.
É abordado as principais técnicas, ferramentas e melhores práticas para desenvolvimento da especificação de requisitos

Versão 29/2014
8
Um entendimento completo dos requisitos de software é essencial para um o sucesso do desenvolvimento do software. Não importa quão bem projetado ou quão bem codificado seja, um programa mal analisado e especificado frustrará o usuário.
Análise de requisitos é um processo de descoberta, refinamento, modelagem e especificação.
O escopo do software, inicialmente estabelecido pelo Analista de Sistemas e refinado durante o planejamento do projeto de software, é aperfeiçoado em detalhes. Modelos, diagramas, fluxos são criados para melhor compreensão do problema.
O analista e o usuário desempenham um papel ativo na análise e especificação de requisitos.
O cliente (usuário) tenta reformular um conceito de função e desempenho de software, às vezes nebuloso, sem detalhes concretos. O analista age como indagador, consultor e solucionador de problemas.
Entretanto, a análise e especificação de requisitos pode parecer uma tarefa relativamente simples, mas as aparências enganam. O grau comunicação é elevado. Daí, surgem as oportunidades de interpretações errôneas e informações falsas. A ambigüidade é provável.
O dilema com o qual se depara um analista pode ser mais bem entendido, repetindo-se a declaração de um cliente anônimo:
“Sei que você acredita que entendeu o que acha que eu disse, mas não estou certo que percebeu que aquilo que ouviu não é o que eu pretendia dizer...”
Análise de Requisitos: Introdução
Introdução

Versão 29/2014
9
Gerência de Projeto
Ambiente
Modelagem de Negócios
Implementação
Teste
Análise e Projeto
Fluxos de Trabalho
Iterações
Implantação
Gerência de Configuração
Requisitos
Iterações Preelim.
Iter. #1
Fases
Iter. #2
Iter. #n
Iter. #n+1
Iter. #n+2
Iter. #m
Iter. #m+1
Elaboração
Transição
Concepção
Construção
Opcional
Ciclo de Desenvolvimento de Software:
Melhores Práticas: A Metodologia de Teste deve ser aplicada durante todo o ciclo de desenvolvimento do software
Nosso escopo
Introdução

Versão 29/2014
10
Da perspectiva da engenharia de software, a “elicitação” de requisitos é talvez a mais parte mais critica do processo de desenvolvimento de software.
Estudos indicam que os requisitos, só detectados depois do software implementado ou erros na análise de requisitos, são até 20 vezes mais caros de se corrigir que qualquer outro tipo de erro.
Introdução

Versão 29/2014
11
Requisitos de Software
Objetivo desta parte:
É apresentar e discutir o Ciclo de Requisitos de Software:
– Identificação, Elicitação, Análise, Especificação e Validação

Versão 29/2014
12
Um cenário comum:
Introdução

Versão 29/2014
13
Requisitos
Definições de requisito (segundo IEEE)
1) Uma condição ou uma capacidade de que o usuário necessita para solucionar um problema ou alcançar um objetivo.
2) Uma condição ou uma capacidade que deve ser alcançada ou possuída por um sistema ou componente do sistema, para satisfazer um contrato, um padrão, uma especificação ou outros documentos impostos formalmente.
3) Uma representação documentada de uma condição ou capacidade, conforme os itens (1) e (2).

Versão 29/2014
14
Contexto de Definição de Requisito:
Stakeholder = Todos os clientes interessados no contexto de requisitos

Versão 29/2014
15
Elicitação de Requisitos
A elicitação de requisitos corresponde a identificar junto aos clientes/usuários quais são os objetivos do sistema, o que deve ser acompanhado, como o sistema se ‘encaixa’ no contexto das necessidades do negócio e, finalmente, como será a utilização do sistema no dia-a-dia.
“A parte mais árdua na construção de um software consiste exatamente em identificar o que construir. Nenhuma outra parte do trabalho compromete tanto o resultado do trabalho se elaborado de forma incorreta. Nenhuma outra parte oferece tanta dificuldade para efetuar correções posteriores. " — F. Brook
Apesar de parecer simples, trata-se de um processo extremamente complexo. Algumas das razões desta dificuldade:
Problemas de escopo: Os limites do sistema são geralmente definidos de forma incompleta, ou os clientes/usuários especificam detalhes técnicos desnecessários;
Problemas de compreensão:
Os clientes/usuários geralmente não estão completamente certos das necessidades, têm uma pouca compreensão ou do domínio do seu negócio, omitem informações que julgam óbvias e etc.
Problemas de volatilidade: Os requisitos mudam o tempo todo.

Versão 29/2014
16
Para ajudar a superar estes problemas, os desenvolvedores devem abordar os requisitos de forma simples, prática e organizada. Alguns passos são recomendados para atividade de Elicitação de Requisitos de Software:
- Avaliar a viabilidade técnica e de negócio para o sistema proposto;
- Identificar as pessoas que vão auxiliar a especificar os requisitos e compreender seus preconceitos organizacionais;
- Definir o ambiente técnico no qual o sistema será instalado;
- Identificar regras de domínio que limitam a funcionalidade ou desempenho do software que será construído;
- Definir um ou mais métodos de elicitação de requisitos;
- Solicitar participação de várias pessoas para que os requisitos sejam definidos a partir de diversos pontos de vista;
- Identificar claramente a justificativa de existência para cada requisito registrado; - Identificar requisitos ambíguos que serão candidatos a prototipação.
Os documentos criados como conseqüência da atividade de elicitação de requisitos irão depender do tamanho do software/sistema que será construído.

Versão 29/2014
17
Para a maioria dos sistemas, estes documentos de trabalho incluem:
- As necessidades e viabilidade estruturadas;
- O limite de escopo do software/sistema;
- Lista de clientes, usuários e outros stakeholders* que participaram da atividade de elicitação de requisitos;
- Descrição do ambiente técnico do sistema;
- Lista de requisitos e as regras de domínio aplicáveis a cada um.
- Conjunto de cenários de uso capazes de prover uma idéia do uso do sistema ou produto sob diferentes condições de operação;
- Qualquer protótipo que eventualmente tenha sido desenvolvido para melhor definir os requisitos.
Cada um destes documentos deve ser revisado por todas as pessoas que tenham participado da elicitação de requisitos.
Stakeholder = Todos os clientes interessados no contexto de requisitos, pode ser uma pessoa ou entidade

Versão 29/2014
18
Objetivos da Elicitação de Requisitos:
Obter conhecimento relevante para o problema e prover o mais correto entendimento de o que é esperado do software/sistema;
Técnicas para Elicitação de Requisitos: - Cenários: representar tarefas que executam e as que desejam executar - Técnicas tradicionais: questionários, entrevistas, análise de documentação existente
- Técnicas de elicitação de grupo: Dinâmica de grupo
- Prototipação: quando existe alto grau de incerteza e necessita de um rápido feedback

Versão 29/2014
19
Documento de Visão
Fazer identificação e elicitação de requisitos
Requisitos. Road Map
Fazer Análise de Requisitos
Fazer Especificação de Requisitos
Documento de Requisitos
Documento de Especificação de Requisitos
Regras de negócio
Usuários e
Clientes
Documentos
Fazer Validação de Requisitos

Versão 29/2014
20
Identificação e Elicitação de Requisitos
É apresentar e discutir as atividades de Identificação e elicitação de requisitos

Versão 29/2014
21
Documento de Visão
Usuários e
Clientes
Documentos
Regras de negócio

Versão 29/2014
22
Identificação e elicitação de requisitos é uma tarefa que parece simples, mas, não devemos nos enganar, às vezes, para obtermos algumas informações é exigido muita dedicação, persistência e técnica. Esta parte apresenta e discute as principais técnicas para identificação e elicitação de requisitos de software.
Por que o “elicitação” é importante:
O sucesso no desenvolvimento de um projeto de software depende basicamente da elicitação de requisitos, pois, é a base que permitirá ao Analista tirar conclusões sobre as situações, problemas ou fenômenos e, assim, sugerir propostas que possam contribuir para a solução do problema.
Entretanto, esta atividade, nem sempre está presente no processo de desenvolvimento, raramente ela é elaborada de forma metodológica, geralmente tem uma abordagem intuitiva.
Principais características de uma “boa elicitação de requisitos”:
• Definir as técnicas de coleta de requisitos baseadas em fatores operacionais, táticos e financeiros;
• Criar um planejamento com objetivo de alcançar as metas estabelecidas, tais como: Prazos, Custos e Qualidade;
• Promover a integração e o comprometimento de todos os envolvidos no processo, por exemplo: Clientes, Fornecedores, Usuários e o Patrocinador.
• Identificar os documentos e procedimentos que definem as políticas de negócios da empresa.

Versão 29/2014
23
Uma Simples Comparação:
Elicitação Ruim
Elicitação Boa
Diagnóstico ineficiente
Bom Diagnóstico
Soluções medíocres
Soluções eficientes
Insatisfação dos usuários
Satisfação dos usuários
Problemas operacionais e financeiros
Melhoria dos processos e redução de custo

Versão 29/2014
24
Documento (Artefato) desta etapa: “Documento de Visão”
Objetivo:
Descrever
a visão inicial
do software
Documento de visão
Participantes:
Analistas e
Especialista em Negócios
identificação/ elicitação de
Requisitos
Entrevistas
Documentos e sistemas
Reuniões e Workshops
Observação de campo
Participantes:
Usuário, Clientes, Fornecedores e
Patrocinadores

Versão 29/2014
25
As fases da Identificação/Elicitação de Requisitos:
Um projeto de elicitação de requisitos têm as seguintes fases:
Planejamento
Elicitação de
Requisitos
Documentação
Documento de Visão
Identificar Fontes
Técnicas
Como deve ser feito ?
O que devo coletar ?
Como devo documentar ?
Identificar Funcionalidades
Identificar Restrições e Riscos

Versão 29/2014
26
As informações podem ser identificadas ou encontradas em diversas fontes: - Usuários; - Documentos; - Especificações técnicas;
- Clientes;
- Sistemas legados - Patrocinadores;
- Analista de Negócio
- “Domain Experts” - Especialista em uma ou mais área de negócio

Versão 29/2014 Rildo Santos (rildo.santos@etecnologia.com.br) | www.etecnologia.com.br
Todos os direitos reservados e protegidos © 2014 27
Quais são as técnicas ?
Existem várias técnicas, todas elas possuem seus
próprios conceitos, vantagens e desvantagens,
que podem ser usada nesta atividade entre elas
estão:
- Reuniões formais;
- Reuniões informais;
- Entrevistas;
- Questionários;
- Workshop;
- Brainstorming;
- JAD (Join Application Development)
- Fast;
- Análise de Documentos;
- Manual de Sistemas Legados.

Versão 29/2014
28
Quais as informações que devo identificar, levantar e coletar ?
Após a atividade de Identificação/Elicitação de Requisitos, através de alguma técnica formal ou informal, as seguintes informações que devemos obter são: Entendimento do problema, identificação da lista dos principais usuários, lista dos principais Requisitos, identificação dos Riscos e as Restrições do software.
Daí podemos organizar as informações da seguinte maneira:
- Contexto (Declaração do problema e Diagrama de Contexto);
- Identificação dos usuários e entidades externas;
- Identificação dos Requisitos;
- Identificação dos Riscos e
- Identificação das Restrições.

Versão 29/2014
29
- Contexto:
Após o entendimento do problema podemos escrever a
Declaração do Problema e também desenhar um diagrama de contexto.
- Declaração do problema:
É uma “descrição narrativa”, que apresenta de forma concisa e clara às necessidades dos usuários.
Esta narrativa também deve descrever o cenário atual e as necessidades futuras.
A linguagem usada neste documento pode ser técnica ou de negócios, entretanto, evite o usar jargões que não se enquadram no escopo do problema.
- Diagrama de Contexto:
Estabelece quais são as fronteiras do software e principais funcionalidades, ou seja, onde as responsabilidades do software começam e quando acabam.

Versão 29/2014
30
- Identificação dos “Stakeholders” Que é “stakeholders” ? Stakeholders podem ser pessoas ou entidades que influenciam a construção do software. Exemplo:
- Usuários, porque definem os requisitos
- Gerentes, Diretores, Patrocinadores porque influenciam através de tomada de decisão.

Versão 29/2014
31
- Identificação dos Requisitos: Identificar as funcionalidades do software que deve ter para atender as necessidades do usuário. Para identificar você pode fazer as seguintes perguntas: - O que o software deve fazer ? - Quais funcionalidades ele deve ter ? Devemos identificar também as principais características do software como: - Performance: Qual é tempo de resposta adequado ? - Segurança: Quais são os requisitos de segurança que o software precisa? - Usabilidade: O software deve seguir a identidade visual da empresa,as interfaces devem ser intuitivas e amigáveis Os requisitos encontrados não devem ser descritos neste momento, precisamos apenas identificá-los, ou seja, é uma informação de alto nível.

Versão 29/2014
32
- Identificação dos Requisitos: Tipos de Requisitos
Os requisitos podem ser divididos em duas categorias:
Requisitos
Requisitos
Funcionais
Requisitos
Não-Funcionais
Declaram as características que o sistema deve possuir e que estão relacionadas às suas funcionalidades.
Definem as funcionalidades do sistema. O que sistema deve fazer.

Versão 29/2014
33
Exemplo:
- Cadastrar Clientes;
- Fazer Análise de Crédito;
- Fazer uma Transação com Banco de Dados;
- Cadastrar um Registro de Atendimento;
- Imprimir Relatório
- etc.
Os requisitos funcionais descrevem o que o sistema deve fazer, isto é, as funções necessárias para atender os objetivos do sistema.
Requisitos Funcionais:

Versão 29/2014
34
Os requisitos não funcionais dizem respeito as características do software, exemplos: performance, portabilidade, segurança, usabilidade e etc. Estas características descrevem também a qualidade do serviço (QoS).
A não consideração ou esquecimento desses fatores na “Workflow de Requisitos” constitui uma das principais razões de uma eventual insatisfação dos usuários com relação a um software.
Os requisitos não funcionais também são chamamos de “RNF” ou “Requisito Suplementares.” Exemplos de RNF:
- Confidencialidade;
- Confiabilidade;
- Performance;
- Qualidade;
- Usabilidade;
- Portabilidade;
- Precisão;
- Integridade;
- Segurança
- etc.
Requisitos Não Funcionais:

- Identificação dos Requisitos:
Os requisitos de software podem ser identificados no texto da “declaração do
problema” (geralmente são verbos que identificam algumas ações).
Este documento possibilita a identificação, extração e
classificação dos requisitos
- Requisitos funcionais e
- Requisitos não funcionais.
Texto da Declaração do Problema

Versão 29/2014
36
Exemplo: Declaração do Problema Exemplo: Acompanhamento das estatísticas de aprendizado do aluno e da turma (professor) Informação: Relatório de aproveitamento do aluno e da turma (s) Requisitos Funcionais:
O sistema deve registrar as principais ações de cada usuário.
O sistema deve fornecer um relatório do aproveitamento do aluno.
O relatório de aproveitamento do aluno deve conter o tempo de uso do software, o número de exercícios feitos, o número de acertos e o de erros.
O sistema deve fornecer um relatório do aproveitamento da turma.
O relatório de aproveitamento da turma deve conter a média e o desvio-padrão dos seguintes dados: tempo de uso do software, número de exercícios feitos, número de acertos e erros de cada exercício. Requisitos Não-Funcionais:
O sistema deve usar gráficos comparativos do aproveitamento do aluno com a média da turma
O sistema deve usar cores na construção dos gráficos
O tempo de resposta na elaboração do relatório não pode ser superior a 15 segundos.

Versão 29/2014
37
- Identificação de Riscos: Os riscos são a principal razão de falha em um projeto de software. Para um projeto ter sucesso é importante a identificação dos riscos o mais cedo o possível. Assim poderemos criar um plano para reduzi-los. No Documento de Visão precisamos apenas identificar e criar uma Lista de Riscos encontrados. Os eventos de riscos podem ter várias origens como: - Política: O software pode sofre a influência de Política de Negócios da Empresa ou Leis, Decretos, Normas e Regulamentos que regulam a sociedade. Problemas financeiros Exemplos de Sistemas que tem restrições legais: - SPB (Sistema Brasileiro de Pagamentos) - Banco Central - Sistema de Faturamento e Contábil (Secretária da Fazenda Municipal, Estaduais e Federais) - Sistema de Folha de Pagamento (Ministério do Trabalho e Previdência Social) - Sistema de Conta Corrente (Banco Central - CPMF)

Versão 29/2014
38
- Identificação de Riscos:
- Tecnologia:
Uso de tecnologias emergentes; Integração com legado
- Recursos:
Orçamento estreito; Contratação de Terceiros
- Habilidade:
Falta de domínio da tecnologia (conhecimento e experiência)
- Requisitos:
Requisitos não são plenamente conhecidos

Versão 29/2014
39
- Identificação das Restrições:
Definem o conjunto de restrições impostas sobre o desenvolvimento do software. Restrições definem, por exemplo, a adequação a custos e prazos, a plataforma tecnológica, aspectos legais (licenciamento), limitações sobre a interface com usuário, componentes de hardware e software a serem adquiridos etc.
Nesta momento apenas identificamos as restrições e criamos uma Lista das Restrições, esta lista podem ser divida em partes como: Restrições de Hardware, Restrições de Software e Restrições de Ambiente e Tecnologia.
Exemplo de Restrição: Quando o projeto requer uma determinada tecnologia, tal como WebServices. Ou quando o software necessita de algum hardware ou software em especifico. Tal como um servidor exclusivo para banco de dados.

Versão 29/2014
40
Documento de Visão: Objetivo: Fazer uma descrição da visão do software Este documento tem as as seguintes seções:
- Declaração do Problema;
- Lista dos Stakeholders - Lista dos Requisitos - Lista de Riscos - Lista das Restrições

Versão 29/2014
41
Data: ________ | Autor: ________ | Revisão: ____
Índice:
1.0 - Introdução
1.1 Objetivo do documento
1.2 Escopo
1.3 Abreviaturas, Siglas e etc.
2.0 Contexto
2.1 Declaração do Problema
3.0 Lista de Stakeholders
3.1 Stakeholders primários
3.2 Stakeholders segundários
4.0 Lista dos Requisitos
4.1 Requisitos funcionais
4.2 Requisitos não funcionais
5.0 Lista dos Riscos
6.0 Lista das Restrições
6.1 Software
6.2 Hardware
6.3 Ambiente e Tecnologia
Documento de Visão:
Exemplo de Simples Documento de Visão:

Versão 29/2014
42
Análise de Requisitos
É apresentar e discutir as atividades da análise de requisitos de software

Versão 29/2014
43
Documento de Visão
Usuários e
Clientes
Documentos
Regras de negócio

Versão 29/2014
44
A análise de requisitos procura sistematizar o processo de definição de requisitos.
Essa sistematização é necessária porque a complexidade dos sistemas exige que se preste mais atenção ao correto entendimento do problema antes do comprometimento de uma solução. Uma definição para requisitos é apresentada a seguir.
“Requisitos: Condição necessária para a obtenção de certo objetivo, ou para o preenchimento de certo objetivo.“
O Documento de Visão é um artefato importante na Análise de Requisitos, destacamos algumas razões:
- Da perspectiva da engenharia de software, a elicitação de requisitos é talvez a mais parte mais critica do processo de desenvolvimento de software.
Estudos indicam que os requisitos, só detectados depois do software implementado ou erros na análise de requisitos, são até 20 vezes mais caros de se corrigir que qualquer outro tipo de erro.
Análise de Requisitos: Introdução

Versão 29/2014
45
A Análise de Requisitos deve ser:
Correta: Quando cada requisito expresso nela for encontrado no software;
Não Ambígua: Cada requisito deve ter somente uma interpretação;
Completa: Quando incluir todos os requisitos significativos relacionados as funcionalidades e requisitos relacionados a qualidade do serviço (também conhecidos como requisitos não funcionais)
Consistente: Quando não existir conflito entre os requisitos;
Verificável: Quando for possível verificar/validar cada requisito;
Modificável: Quando os requisitos podem ser facilmente alterados.

Versão 29/2014
46
Atividades da Análise de Requisitos
A análise de requisitos possibilita que o Analista de Sistemas especifique as funcionalidades, classificando e detalhando os requisitos encontrados na coleta.
Os requisitos funcionais serão descritos em detalhes. E os requisitos não funcionais serão classificados.
Detalhar os Requisitos Funcionais
Descrever os Usuários
e Entidades Externas
Classificar os
Requisitos não Funcionais
Fazer Plano de Redução de Risco

Versão 29/2014
47
Requisitos Funcionais:
Os requisitos funcionais devem ser detalhados. Devemos usar um formato padrão para esta atividade. Veja o exemplo:
Análise de Requisitos. Detalhar
Lista de Requisitos funcionais
Nome
Descrição
Fazer Reserva
Esta funcionalidade deverá permitir o usuário (funcionário) a fazer reserva de apartamentos, as ações que estarão
disponíveis são: criar, remover, alterar e consultar reservas.
Cada reserva deverá ter um cliente e um apartamento e respectiva período)
Autor:
Revisão:
Data Atualização:
RF01E
Código

Versão 29/2014
48
id
Nome da Regra
Nome do Projeto
Serviço de Atendimento e Reserva de Apartamento
Objetivo
Descrever todas as regras de negócio para para o serviço de atendimento e reserva de apartamentos.
Data
01/01/08
RFS
2.1
Nome / Equipe
Versão
RN01
Descrição de Regras de Negócio
Descrição da Regra de Negócio
Registrar Reserva de Apartamento
A confirmação do registro de reserva de apartamento deve ocorrer após o pagamento de 25% do valor da estadia. Os clientes AA (pessoas que hospedaram no hotel mais de 10 dias por ano) tem preferência de data e tipo de apartamento. No período de baixa a estação (de mar a jun e ago a nov) o valor da diária tem um desconto de 40%. Para que agilizar o atendimento manter a satisfação do cliente as consultas de reserva devem ser feitas em no máximo 30 segundos.
Vigente
Status
Nome
Descrição
Registrar Reserva de Apartamento
Esta funcionalidade deverá permitir o usuário (funcionário) a fazer reserva de apartamentos, as ações que estarão disponíveis são: criar, cancelar, alterar e consultar reservas.
Requisitos Funcional
ID
RFC01
Nome: Reserva
Descrição: Serviço de Atendimento e Reserva de Apartamento
RN: RN01
Os códigos permitem a rastreabilidade

Versão 29/2014
49
Agora vamos descrever os Requisitos Não Funcionais. Entretanto, precisamos categorizar estes requisitos, as mais frequente são:
Análise de Requisitos. Classificar
- Performance:
Tempo de resposta
- Segurança:
Uso de senhas, certificados digitais e etc..
- Usabilidade:
Identidade Visual e Interfaces amigáveis
- Disponibilidade:
O software deve estar disponível para usuário 24x7. Exemplo: Tolerância a falha
- Flexibilidade:
Capacidade de adaptação quando um requisito muda
- Portabilidade:
Capacidade de se adaptar a outros ambientes (sistemas operacionais)
- Escalabilidade:
Capacidade de responder aumento de carga (novos usuários)
Outras categorias como Integração, Processamento, Manutenível e etc.

Versão 29/2014
50
Bem vamos descrever os requisitos não funcionais. Como na descrição dos Requisitos funcionais, precisamos ter um padrão
Análise de Requisitos. Classificar e Detalhar
Lista de Requisitos Não funcionais
Descrição
Fazer Consulta
As consultas que serão realizadas pelo cliente não poderão exceder ao tempo de resposta de 15 segundos
Autor:
Revisão:
Data Atualização:
Categoria: Performance
Req. Funcional
Código
RNFP1
Por que preciso de um código ?
Este código tem como objetivo facilitar a “rastreabilidade”.
Ele pode ser usado no Formulário de Caso de Uso, por exemplo, desta forma conseguiremos identificar qual é o caso de uso que realiza este RNF, no caso de mudanças.

Versão 29/2014
51
Continuação:
Lista de Requisitos Não funcionais
Categoria: Usabilidade
RF / Aplicação
Descrição
Aplicação
As cores, as fontes e logotipos devem seguir o Manual de Identidade Visual da empresa.
Autor:
Revisão:
Data Atualização:
Aplicação
As interfaces com usuário devem seguir padrão de interfaces estabelecido pelo Manual de Sistema
Código
RNFU1
RNFU2
Análise de Requisitos. Classificar e Detalhar

Versão 29/2014
52
Lista de Stakeholders:
Precisamos descrever todos as pessoas e/ou organização que influenciam a tomada de decisão ou participam direta ou indiretamente do processo de construção do software. Mais uma vez criaremos um formato padrão. Veja o exemplo:
Lista de Stakeholders
Nome
Descrição
Cliente
São todas as pessoas físicas ou jurídicas que fazem reservas
Autor:
Revisão:
Data Atualização:
Colaborador
É qualquer pessoa que presta algum tipo serviço para empresa

Versão 29/2014
53
Continuação:
Lista dos Stakeholders
Nome
Descrição
Administradora de
Cartão de Crédito
Entidade que faz validação de um cartão de crédito presente
em transação de pagamento.
Autor:
Revisão:
Data Atualização:
Lista de Stakeholders:

Versão 29/2014
54
Plano de Mitigação de Riscos:
Análise de Requisitos. Elaborar:
Precisamos elaborar um Plano de Mitigação de Risco, para os risco que já foram identificados. Este plano deve detalhar como mitigar os riscos identificados.
Exemplo:
Foi identificado o Risco de Habilidade, pois, somente uma pessoa da equipe conhece a Web 2.0, as outras pessoas nunca trabalharam com esta técnologia.
Para mitigar este risco toda equipe deverá receber treinamento de Web 2.0, antes do começo do projeto.

Versão 29/2014
55
Documento de Requisitos:
Objetivo:
Classificar, descrever os requisitos de software,
usuários e entidade externas e elaboração do
plano de redução de risco
Este documento tem as seguintes seções:
- Requisitos Funcionais
- Requisitos Não Funcionais
- Descrição do Usuários e Entidades Externas
- Plano de Redução de Risco
Análise de Requisitos. Artefato

Versão 29/2014
56
Data: ________ | Autor: ________ | Revisão: ____
Índice:
1.0 - Introdução
1.1 Objetivo do documento
1.2 Escopo
2.0 Descrição dos Requisitos Funcionais
3.0 Descrição dos Requisitos Não Funcionais
4.0 Lista dos Stakeholders (clientes e usuários)
4.1 Stakeholders primários
4.2 Stakeholders segundárioss
5.0 Plano de Mitigação de Riscos
Documento de Requisitos:
Análise de Requisitos. Artefato.Template

Versão 29/2014
57
Mitos e Lendas:
O que é dito:
- Usuários não entendem do negócio...
- Requisitos são estáticos...
- Achar que tem a solução, mesmo antes de conhecer todo o problema...
Entretanto, a realidade é outra...
- Requisitos não são estáticos, eles mudam constantemente...
- Fazer amplas discussões que envolvam o maior
número de pessoas que conheçam o negócio, antes de
apresentar uma a solução

Versão 29/2014
58
Especificação de Requisitos com Caso de Uso
É apresentar as principais técnicas para especificação de requisitos de software.

Versão 29/2014
59
Documento de Visão
Usuários e
Clientes
Documentos
Regras de negócio

Versão 29/2014
60
Casos de Uso
Seqüência
Colaboração
Classes
Distribuição
Implementação
Estrutura
Comportamento interno
Comportamento externo
Especificação de Requisitos
Requisitos Funcionais
Documento de Visão
Requisitos Não Funcionais
Arquitetura
do Software
Restrições
de Projeto

Versão 29/2014
61
Objetivos:
• Identificar os atores;
• Identificar os casos de uso;
• Desenhar os casos de uso e
• Escrever cenários.
Análise de Casos de Uso:
•Casos de uso expressam o diálogo entre os usuários e o sistema
•Casos de uso expressam “o quê” o sistema deverá fazer. E não “como” fazer.
•Casos de uso formam a base para testes e documentação do sistema
•O modelo de casos de uso expressam todos os casos de uso do sistema e os seus relacionamentos.
•As técnicas para criar e expressar casos de uso em uma aplicação Web são as mesmas para construir outros sistemas de software.
O produto que devemos ter após Análise de Requisitos é a “A especificação de Requisitos” é feita através de Casos de Uso, conforme definido pela UML. Um conjunto de casos de uso é importante para se compreender o que o usuário quer. Um caso de uso descreve uma funcionalidade (“requisito”) a ser oferecida pelo sistema, ou seja, um serviço.

Versão 29/2014
62
Cliente
Emitir NF
Fazer Pedido
Fazer Cadastro
Calcular Total
Funcionário
Transformar os Requisitos Funcionais em Casos de Uso:

Versão 29/2014
63
Atividades e Passos:
Fazer Diagrama de Casos de Uso
Escrever cenários
Ferramenta de Modelagem UML
Identificar Atores / Casos de Uso
Refinar Diagrama de
Casos de Uso
Escrever Formulário
Fazer Diagrama de Caso de Uso

Versão 29/2014
64
Introdução:
Caso de Uso é uma representação gráfica e semântica da
interação do usuário e o sistema.
Os diagramas de caso de uso são usados para capturar os
requisitos funcionais do sistema. Ajuda o entendimento do
contexto dos requerimentos do sistema.
Os casos de uso podem ser agrupados em pacotes, desta
forma temos uma organização funcional.

Versão 29/2014
65
O que são Caso de Uso?
São diagramas de que permitem visualizar, especificar e
documentar o comportamento de um elemento. Esses
diagramas fazem com que sistema, subsistemas e classes
fiquem acessíveis e compreensíveis, por apresentarem
uma visão externa sobre como esses elementos interagem
com sistema.
Definição:
Caso de Uso é uma descrição de um conjunto de
seqüências de ações, inclusive variantes, que um sistema
pode produzir um resultado de valor observável por
um ator. A representação gráfica é uma elipse.
Gerenciar Reserva
Ator
Caso de Uso
Nome
Usuário
Os nomes de casos de uso
são breves expressões verbais
ativas.

Versão 29/2014
66
Casos de Uso e Cenários:
Os casos de uso exibem a funcionalidade na perspectiva do usuário. Entretanto,
podemos ter vários caminhos para completar esta função.
Um cenários é como uma “instance” do Caso de uso, isto é, um caminho lógico com
início e fim.
Principais características:
- Cenários não contém declarações condicionais;
- Pode ter mesmo começo, mas, com final diferente;
- Um cenário é narrativa de uma situação e
- Os cenários devem descrever os bons caminhos e maus também.

Versão 29/2014
67
Este é um dos cenário que pode acontecer. Se houver algum problema, com a
autorização da transação do cartão de crédito teremos um novo cenário.
Exemplos:
Em dada Loja virtual, podemos o seguinte cenário de Compra de um produto:
“O cliente navega no catálogo de itens e adiciona os itens desejado à sua cesta de
compra. Quando o cliente deseja pagar, fornece os dados do cartão de crédito e
confirma a compra. O sistema solicita o endereço de entrega para o pedido.
O sistema verifica a autorização do cartão de crédito e confirma a transação
imediatamente enviando um e-mail para o usuário.”

Versão 29/2014
68
Autorização de acesso.
O usuário executa a aplicação, o sistema exibe a janela de identificação que pede a
identificação do usuário, ou seja, seu nome e sua senha, O usuário informa seu
nome e sua senha, o sistema valida as informações e dá a autorização de acesso ao
sistema.
Exemplos:
Se senha for invalida ou nome neste caso teremos um novo cenário.

Versão 29/2014
69
Casos de Uso e Fluxo de Eventos: Uso caso de uso descreve “o quê” um sistema (ou subsistema, classe, ou interface) faz, ele não especifica “como” isso é feito. Ao fazer uma modelagem, importante manter clara a separação de questões entre a visão interna e externa. Podemos especificar o comportamento de um caso de uso pela descrição do fluxo de eventos no texto de maneira suficientemente clara para que qualquer pessoa possa entende-lo facilmente. Ao escrevermos o fluxo de eventos devemos incluir como e quando o caso de uso inicia e termina, como e quando o caso de uso interage com os atores e o fluxo básico e fluxo alternativo do comportamento. Tipos de fluxos:
•Fluxo de eventos principal e
•Fluxo alternativo de eventos.

Versão 29/2014
70
Casos de Uso e Fluxo de Eventos:
Tipicamente descrevemos um fluxo de eventos para um caso de uso. Os fluxos de eventos
ajudam a compreensão dos requisitos do sistema, entretanto, você desejará utilizar
os diagramas de interação para especificar esses fluxos graficamente. Além disso, você
também utilizará um diagrama de seqüência para especificar o fluxo principal de um
caso de uso e variação deste diagrama para especificar os fluxos excepcionais.
Cenário 1
Fluxo
alternativo 1
Fluxo
alternativo 2
Fluxo
alternativo 3
Fluxo Normal

Versão 29/2014
71
Casos de Uso e Formulário:
Os formulários devem ter as seguinte informações:
- Ponto de ativação (momento que caso de uso começa)
- Nome do caso de uso
- Objetivo
- Atores que participam do caso de uso
- Pré-condição
- Fluxo Normal
- Fluxo Alternativo
- Pós-condição.
Opcionalmente podemos acrescentar outros itens ao Formulário de Caso Uso.
Exemplos:
- Nome ou código dos Requisitos (RN e RNF) que estão associados a este caso de uso

Versão 29/2014
72
Exemplo Formulário de Descrição de Caso Uso:
Nome: Fazer Busca Produto
Ponto de ativação: Este caso de uso começa quando entra na página de Busca e seleciona um item da caixa de seleção
Ator: Visitante e Cliente
Objetivo: Fazer busca de produto por categoria
Pré-condição: Aplicação Disponível
Fluxo Normal:
1 - O visitante seleciona a página de busca
2 - O visitante seleciona a categoria para busca
3 - O visitante informar o produto
4 - O visitante pressiona o botão buscar
5 - O sistema processa a busca
6 - Retorna as informações sobre o produto
Fluxo Alternativo:
1 - O Visitante seleciona a página de busca
2 - O visitante seleciona a categoria para busca
3 - O visitante informar o produto
4 - O visitante pressiona o botão buscar
5 - O sistema processa a busca
6 - Retorna as uma mensagem “produto não encontrado”
Pós-condição: Busca realizada
Requisito Funcional: RF002 -Fazer Busca do Produto Requisito Não Funcional: ---

Versão 29/2014
73
Organização dos Casos de Uso:
Os casos de uso também podem ser organizados pela especificação de relacionamento de
generalização, inclusão e extensão, existentes entre eles. Esses podem ser aplicados com
a finalidade de fatorar o comportamento comum (obtendo esse comportamento a partir de
outros casos de uso que ele inclui) e fatorar variantes (obtendo esse comportamento em
outros casos de uso que o estendem)

Versão 29/2014
74
Exemplos de Casos de Uso:
Professor
Selecionar curso para ensinar
Pedir lista dos matriculados
Gerente de Educção
Manter informação de aluno
Manter informação de professor
Gerar catalogo
Manter informações dos cursos
Sistema de cobrança
Matrícula nos Cursos
Aluno

Versão 29/2014
75
Elementos dos Caso de Uso:
Ator:
Um ator representa um conjunto coerente de papéis que os usuários de casos de
uso desempenham quanto interagem com esses casos de uso. Geralmente um
ator representa um papel, que pode ser de pessoa, de um sistema ou de um
dispositivo e etc...
Cenários:
É narrativa de determinado fato ou de uma situação.
“O caso de uso deve ser descrito através de cenários. Devem ser construídos tantos
cenários quantos forem necessários para se entender completamente todo o
sistema. Podem ser considerados como teste informais para validação dos requisitos do
sistema.”
Formulário:
É a representação estruturada de um ou mais cenários

Versão 29/2014
76
Generalização:
Entre os casos de uso é parecida à generalização existente entre as classes.
No caso de uso a generalização significa que o caso de uso filho herda o
comportamento e o significado do caso de uso pai; o filho poderá acrescentar ou sobrescrever o comportamento de seu pai; poderá ser substituído em qualquer local qual o pai apareça.
Include:
Quando você estiver se repetindo em dois ou mais caso de uso separados
devemos evitar a repetição
Extends:
Quando estivermos descrevendo uma variação em comportamento normal, entretanto, querendo fazer uma descrição mais controlada, explicando os pontos de extensão no caso de uso.
Realizes:
Especifica a colaboração entre os casos de uso
* Use (obsoleto): Especifica que a semântica do elemento de origem depende da
semântica da parte pública do destino. Substituído pelo include.

Versão 29/2014
77
Generalização:
Podemos usar a generalização entre casos de uso, pelo mesmo motivo que utilizamos
nas classes, para compartilhar comportamento:
Pagto Cartão de Crédito
Receber Pagamento
generalização
Pagto Cartão de Débito

Versão 29/2014
78
Generalização:
A generalização também pode ser aplicado aos atores e seus respectivos papéis. Veja
o exemplo:
Funcionário
Recepcionista
Gerente de
Reservas

Versão 29/2014
79
Extends:
Podemos usa-lo para “Demonstrar Variação de Comportamento”:
Cada uma das extensões descreve as diferentes maneiras com que um passo do caso de uso pode ser executado. Variação de Comportamento. Exemplo:
Alterar status do carro
Consulta Cliente
<<include>>
Devolver Veículo
Calcular Multa
<<extend>>
<<include>>
Locadora de Automóveis

Versão 29/2014
80
Fazer Pedido
<<include>>
Acompanhar Pedido
Validar Usuário
<<include>>
Explicando o estereotipo “include”
Um relacionamento de inclusão entre casos de uso significa que o caso de uso base incorpora
explicitamente o comportamento de outro caso de uso em uma localização especificada na base.
O caso de uso incluído nunca permanece isolado, mas é apenas uma “instance” como parte de
alguma base maior que o inclui. Você pode pensar na inclusão como o caso de uso base que o
obtém o comportamento a partir do fornecedor do caso de uso. Você utiliza um relacionamento
de inclusão para evitar descrever o mesmo fluxo de eventos várias vezes, incluindo o
comportamento comum em um caso de uso próprio. O relacionamento de inclusão é
essencialmente um exemplo de delegação, você coleta um conjunto de responsabilidades do
sistema e o captura um único local (o caso de uso incluído); depois, permite que outras partes do
sistema (outros casos de uso) incluam a nova agregação de responsabilidade sempre que
precisamos utilizar essa funcionalidade.

Versão 29/2014
81
Fazer Check IN
<<include>>
Gerenciar Reserva
Include. (Mais) exemplos:
Fazer Check OUT
<<include>>
Receber Pagamento

Versão 29/2014
82
Casos de Uso - Identificação de Atores
Os atores não fazem parte do sistema - eles representam qualquer um e qualquer coisa que faça interação com sistema. Podendo ser uma pessoa, software, hardware e etc.
Uma ator pode:
- Apenas fornecer informações ao sistema
- Apenas receber informações do sistema
- Fornecer e receber informações ao sistema
Tipicamente os atores são identificados nas Declarações de Problemas (Documento de Visão) ou através de entrevistas com os usuários e outros envolvidos no processo, como, Gerente, Especialista em Negócio, Analista de Sistema e Analista de Negócio, por exemplo.
As seguintes questões podem ser usadas para identificar o atores:
- Onde o sistema será usado ?
- Quais áreas serão usuárias do sistema ?
- O sistema usará recurso externo ?
- Quem será o responsável pelo sistema ?
- Quem serão os usuários do sistema ?

Versão 29/2014
83
Um engano comum na identificação de casos de uso é representar como Caso de uso passos individuais, operações ou transações.
Exemplo:
No domínio de ponto de venda, alguém pode definir um caso de uso chamado “Imprimindo o Recibo”, quando de fato, a operação de impressão é meramente um passo no processo muito mais abrangente do caso de uso Comprar Itens
Lembre-se:
Um caso de uso é uma descrição completa de processo, que inclui outros passos ou transações.

Documento de
Visão
O hotel contém um número de apartamentos disponíveis para ser alugado aos hospedes. Cada apartamento tem as
seguintes propriedades:
- Número, preços base, capacidade de pessoas
- Tipo (Single, double, triplo ou suite)
O preço de cada apartamento está relacionado com seu tipo e sazonalidades (períodos especiais, tais como: férias, natal,
carnaval...)
Um hospede pode fazer reserva de mais de um apartamentos através do telefone, Internet ou pessoalmente no balcão de
reserva do Hotel .
Refinado pelo




Requisitos Funcionais
• Gerenciar Reserva
•...
1
2
‘
Documento
de Requisitos
Estudo de Caso:

Versão 29/2014
85
Especificação de Requisitos:
Cenários
Gerenciar Reserva
Usuário
Formulário
Caso de Uso
Associação
Ator
3
Caso de Uso: Gerenciar Reserva
Estudo de Caso:

Versão 29/2014
86
Escrevendo os Cenários:
Cenários
Gerenciamento de Reserva:
O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva
de apartamentos para data.
O cliente informa o período, ou seja, data de chegado e partida, e qual tipo de apartamento
ele precisa.
O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e informa
que não tem disponibilidade de apartamento para o período informado pelo cliente e
oferece um outro tipo de apartamento.
O cliente aceita o apartamento e então o funcionário confirma a reserva.
ele precisa.
O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e confirma a
reserva.
Estudo de Caso:

Versão 29/2014
87
Escrevendo os Cenários:
Cenários
ele precisa.
O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e informa
que não tem disponibilidade de apartamento para o período informado pelo cliente e
oferece um outro tipo de apartamento.
O cliente não aceita a proposta do funcionário e a reserva não é confirmada.
Estudo de Caso:

Versão 29/2014
88
Escrevendo o Formulário:
Compilar os Cenários em Formulário:
Cenário
ele precisa.
O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e confirma a
reserva.
Pré- condição
Pós- condição
Identificando a pré-condição e pós-condição:
Cenários
Formulário
Estudo de Caso:

Versão 29/2014
89
Compilar os Cenários em Formulário:
Nome: Gerenciar Reserva
Ponto de ativação: Este caso de uso começa quando o funcionário do setor de reserva recebe uma solicitação de
reserva
Ator: Funcionário
Objetivo: Fazer reservar de apartamentos
Pré-condição: Solicitação de reserva
Fluxo Normal:
Fluxo Alternativo:
Pós-condição: Reserva confirmada
Primeiras linhas do cenário
Última linha do cenário
Gerenciar Reserva
“caminho feliz”
Gerenciar Reserva
“caminho alternativo”
Estudo de Caso:

Versão 29/2014
90
Formulário:
Nome: Gerenciar Reserva
Ponto de ativação: Este caso de uso começa quando o funcionário do setor de reserva recebe uma solicitação de reserva
Ator: Funcionário
Objetivo: Fazer reservar de apartamentos
Pré-condição: Solicitação de reserva
Fluxo Normal:
O cliente informa o tipo de apartamento O cliente o período (data de chegada e partida) O funcionário do Hotel verifica a disponibilidade do apartamento
O funcionário confirma a reserva
Fluxo Alternativo:
... O funcionário do Hotel verifica a disponibilidade do apartamento
O funcionário faz proposta de outro apartamento para cliente
O cliente aceita e então o funcionário confirma a reserva
Pós-condição: Reserva confirmada
Estudo de Caso:

Versão 29/2014
91
Especificação de Requisitos:
Cenários
Formulário
Gerenciar Reserva
Funcionário
Caso de Uso
Associação
Ator
3
Caso de Uso: Gerenciar Reserva
Estudo de Caso:

Versão 29/2014
92
Ferramenta: Enterprise Architect (EA)

Versão 29/2014
93
Mitos e Lendas
• Requisitos não são Casos de Uso;
• Um Caso de Uso pode relacionar mais de um requisito, veja o exemplo: Caso de Uso Fazer Busca, está associado a dois requisitos:
• (RF) Fazer Buscar
• (RNF) O tempo de resposta para transação deve ser 10 segundos (Desempenho)

Versão 29/2014
94
Atividades e Passos:
Escrever cenários
Rational Rose
Refinar Diagrama de
Casos de Uso

Versão 29/2014
95
Especificação de Requisitos, como fazer:
1 - Identifique quais os REQUISITOS e relacione com os CASOS DE USO; 2 - Identifique também os ATORES e seus respectivos PAPÉIS;
3 - Dê um nome para o CASO DE USO, lembre-se que este nome deve ser único no modelo;
4 - Escreva os CENÁRIOS para o CASO DE USO;
5 - Compile os CENÁRIOS em único FORMULÁRIO e
6 - Faça o Diagrama de Caso de Uso (Use “Rational Rose” para fazer isto).
Vamos fazer os Caso de Uso (iniciais)

Versão 29/2014
96
Modelo do “Formulário de Descrição de Requisitos”:
Nome: <nome do caso de uso>
Ponto de ativação: <informar o ponto de ativação>
Ator: <informar os atores>
Objetivo: <descrever o objetivo>
Pré-condição: <descrever a pré-condição>
Fluxo Normal:
<descrever o fluxo normal>
Fluxo Alternativo:
<descrever o fluxo alternativo>
Pós-condição: <descrever a pós-condição>
RF: <informar os código ou nomes dos RFs>
RNF: <informar os código ou nomes dos RNFs>
Data: ______ | Autor: ________ | Revisão: ____

Versão 29/2014
97
Refinar: Atividades e Passos
Escrever cenários
Rational Rose
Refinar Diagrama de
Casos de Uso
Neste momento vamos “refinar” o Diagrama de Caso de Uso:
1 - Identificar os pontos de extensão
2 - Identificar as generalizações
3 - Identificar os pontos de “inclusão”

Versão 29/2014
98
Exemplo 2 – Adicionando o <<include>>
Gerenciar Reserva
Funcionário
Funcionário
Sem include:
Com include:
Cadastrar Cliente
Buscar Apartamento
<<include>>
<<include>>
Gerenciar Reserva

Versão 29/2014
99
Fazer Check IN
Recepcionista
Fazer Check IN
Recepcionista
Consultar Cliente
Consultar Reserva
<<extend>>
<<include>>
Exemplo 1 – Adicionando o <<include>> e <<extend>>
<<include>>
Cancelar Check IN

Versão 29/2014
100
Fazer Check OUT
Recepcionista
Fazer Check OUT
Recepcionista
Consultar Cliente
Consultar Reserva
<<include>>
<<include>>
Receber Pagamento
<<include>>
Exemplo 3 – Adicionando o <<include>>
Sem include:
Com include:

Versão 29/2014
101
Validação de Requisitos
É apresentar as principais técnicas para validação de requisitos de software.

Versão 29/2014
102
Documento de Visão
Usuários e
Clientes
Documentos
Regras de negócio

Versão 29/2014
103
Deve preocupa-se em mostrar que os requisitos definem o sistema que o cliente/usuário deseja.
Validação é importante uma vez que o custo para remover um erro de requisitos é grande.
Pequeno Check List de Requisitos:
Validade. O sistema fornece as funções que melhor atende as necessidades do usuário?
Consistência. Existem conflitos de requisitos?
Completeza. Todas as funções necessárias para o cliente estão incluídas?
Realismo. Os requisitos podem ser implementados com a tecnologia e orçamento
disponíveis?
Facilidade de verificação. Os requisitos podem ser checados?

Versão 29/2014
104
Revisão de requisitos:
- Revisões regulares devem ocorrer durante a formulação da definição dos requisitos
- Tanto o cliente quanto a equipe contratada devem estar envolvidos nas revisões
- As revisões podem ser formais (com documentos completos) ou informais. Uma boa
comunicação entre os desenvolvedores, clientes e usuários pode resolver problemas em estágios iniciais
Verificação de revisões:
- “Verificabilidade”. O requisito é realisticamente testável?
- Compreensibilidade. O requisito é propriamente entendido?
- Rastreabilidade. A origem do requisito é claramente estabelecida?
- Adaptabilidade. O requisito pode ser modificado sem grande impacto sobre outros requisitos?
Técnicas de validação de requisitos Revisão de requisitos: - Análise manual sistemática dos requisitos Prototipação:
- Uso de um modelo executável do sistema para checar os requisitos. Geração de casos de teste: - Desenvolver testes para validar a implementação dos requisitos. Análise automatizada da consistência: - Uso de ferramenta para verificar a consistência do modelo.

Versão 29/2014
105
Definição: Caso de Teste
- Casos de Testes: Especifica uma forma de fazer testes, incluindo o que testar (as entradas e/ou as saídas) , como testar e as condições de testes.
Em engenharia de software, Caso de Teste é um conjunto de condições usadas para teste de software. Ele pode ser elaborado para identificar defeitos na estrutura interna do software, através de situações que exercitem adequadamente todas as estruturas utilizadas na codificação; ou ainda, garantir que os requisitos do software que foi construído sejam plenamente atendidos. Podemos utilizar os Casos de Uso para criar e rastrear os Caso de Teste.
O Caso de Teste deve especificar a saída esperada e os resultados esperados do processamento. Numa situação ideal, no desenvolvimento de casos de teste, se espera encontrar o subconjunto dos casos de teste possíveis com a maior probabilidade de encontrar a maioria dos erros.
Os Casos de Uso são a base para os Casos de Teste
Caso de Teste

Versão 29/2014
106
Definição: Modelo de Teste - Caso de Teste. Exemplo:
Fazer Login
Fluxo Normal Entrada: nome e senha
Caso de Teste
25
Nome
ID Caso Teste
Validar o Caso de Uso: Fazer Login de Acesso
Descrição
24
ID Caso de Uso
Resultado Esperado
Resultado Observado
OK ?
Cenário
Usuário autorizado (Sucesso)
OK
Fluxo Alternativo 1 Entrada: nome e senha
Mensagem usuário inválido (Insucesso)
NOK
Cenário 1
Fluxo
alternativo 1
Fluxo
alternativo 2
Fluxo
alternativo 3
Caso de Uso Fluxo Normal
Nome do Testador:
Data:
____/____/_____
Fazer Login
Cliente
Descrição do Caso de Uso
Caso de Teste

Versão 29/2014
107
Técnicas de validação de requisitos Verificação de Consistência Automatizada:
Requisitos em linguagem formal
Processador de Requisitos
Base de Dados de Requisitos
Relatório

Versão 29/2014
108
Gerenciamento de Mudança
de Requisitos
É apresentar as principais técnicas para processo de gerenciamento de mudança de requisitos de software.

Versão 29/2014
109
Gerenciamento de Mudança de Requisitos é o processo de controlar as mudanças nos requisitos durante o processo de engenharia de requisitos e desenvolvimento.
Requisitos são inevitavelmente incompletos e inconsistentes:
• Novos requisitos surgem durante o processo de desenvolvimento.
• Diferentes pontos de vista possuem diferentes requisitos e esses são freqüentemente contraditórios.
Mudanças nos requisitos:
- A prioridade dos requisitos podem mudar para atender novas demandas de negócio
- Requisitos podem sofrer alteração quando muda a regra de negócio; - As pessoas que pagam pelo software/sistema podem especificar os requisitos de maneira conflitantes com os requisitos das pessoas que irão utilizar o software/sistema. - A empresa e o ambiente técnico do software/sistema se modificam durante o processo de desenvolvimento
Gerenciamento de Mudança de Requisitos

Versão 29/2014
110
Evolução dos requisitos
Entendimento inicial do problema
Requisitos
iniciais
Entendimento do problema (alterado)
Requisitos
modificados
tempo

Versão 29/2014
111
Requisitos permanentes e voláteis: - Requisitos permanentes. Requisitos estáveis, derivados da atividade principal da organização. Exemplo: Em um hospital sempre haverá requisitos relativos aos pacientes, aos médicos, às enfermeiras e aos tratamentos.
- Requisitos voláteis. Requisitos que se modificam durante o desenvolvimento ou quando o software/sistema está em uso. Requisitos resultantes de políticas governamentais ou resultantes de regra de negócio da empresa. Exemplo: Plano de saúde; Mudança na política de venda
Classificação dos requisitos:
Requisitos Mutáveis:
- Requisitos que se modificam por causa do ambiente do sistema.
Requisitos Emergentes:
- Requisitos que surgem à medida que a compreensão do cliente do sistema se desenvolve
Requisitos Conseqüentes:
- Requisitos que resultam da introdução do sistema de computador.
Requisitos de compatibilidade:
- Requisitos que dependem de outros sistemas ou processos de negócio específicos dentro da organização

Versão 29/2014
112
Planejamento do gerenciamento de requisitos:
Durante o processo de engenharia de requisitos, será necessário planejar:
A identificação dos requisitos:
Como os requisitos são individualmente identificados
Um processo de mudança de gerenciamento:
O processo seguinte à análise de uma mudança de requisito
Políticas de rastreabilidade:
A quantidade de informações (histórico) sobre o relacionamento entre requisitos que é mantida. Como rastrear as mudanças de requisitos e seus possíveis impactos.
Suporte à ferramenta:
O suporte à ferramenta necessário para auxiliar no Gerenciamento de Mudanças de Requisitos

Versão 29/2014
113
Rastreabilidade:
- Rastreabilidade preocupa-se com as relações entre requisitos, suas fontes e o projeto do
software/sistema
Rastreabilidade de fonte:
• Links de requisitos para stakeholders que propuseram os requisitos
Rastreabilidade de requisitos:
• Links entre requisitos dependentes
Rastreabilidade do projeto:
• Links dos requisitos para o projeto

Versão 29/2014
114
Suporte à ferramenta:
Armazenamento dos requisitos:
- Os requisitos devem ser gerenciados em uma memória de dados segura e gerenciada
Mudança de gerenciamento:
- O processo de mudança de gerenciamento é um processo de fluxo de trabalho cujos estágios podem ser definidos e o fluxo de informação entre esses estágios parcialmente automatizado
Gerenciamento de rastreabilidade
- Recuperação automática dos links entre requisitos

Versão 29/2014
115
Gerenciamento de Mudanças de Requisitos: Deve ser feita em qualquer proposta de mudança de requisito. Principais estágios: - Análise do problema e especificação da mudança. Discute-se os problemas com os requisitos e propõe-se mudanças. - Análise e custo da mudança. Avalia-se os efeitos da mudança em outros requisitos do sistema. - Implementação das mudanças. O documento de requisitos e outros documentos são alterados de forma a refletir as mudanças.
Análise do Problema e especificação da mudança
Análise e custo mudança
implementação da mudança
Solicitação de Mudança de Requisito
Requisito
Alterado

Versão 29/2014
116
Exemplo: Matriz de Rastreabilidade (na ferramenta ReqPro):

Versão 29/2014
117
Exemplo: Matriz de Rastreabilidade (na ferramenta EA):

Versão 29/2014
118
Conteúdo:
Técnicas para identificação/elicitação de requisitos:
- JAD
- FAST Documento de Requisitos - Padrão IEEE/ANSI 830-1993:

Versão 29/2014
119
JAD (Join Application Development)
A técnica JAD desenvolvida na IBM no fim dos anos 70 visa criar sessões de trabalho
estruturadas, através de uma dinâmica de grupo e recursos visuais, em que analistas e
usuários trabalham juntos para projetar um sistema, desde os requisitos básicos até o layout de telas e relatórios, prevalecendo a cooperação e o entendimento [PORTELLA1994]. Os desenvolvedores ajudam os usuários a formular os problemas e explorar possíveis soluções, envolvendo-os e fazendo com que eles se sintam participantes do desenvolvimento
JAD se baseia em quatro princípios básicos:
1. Dinâmica de grupo, com a utilização de sessões de grupo facilitadas para aumentar a
capacidade dos indivíduos;
2. Uso de técnicas audiovisuais para aumentar a comunicação e o entendimento;
3. Manutenção do processo organizado e racional; e
4. Utilização de documentação-padrão, que é preenchida e assinada por todos os
participantes de uma sessão.
A técnica JAD tem duas grandes etapas: planejamento, cujo objetivo é elicitar e especificar requisitos; e projeto, em que se lida com o projeto do software. Nesta monografia somente será tratada a primeira etapa. Os participantes de uma sessão de JAD desempenham seis diferentes papéis: líder da sessão, representantes do usuário, especialista, analista, representantes dos sistemas de informação e patrocinador executivo.
Anexo

Versão 29/2014
120
JAD (Join Application Development) continuação
A técnica pode ser usada tanto para elicitar como nas fases iniciais da especificação de
requisitos. Ela ajuda a identificar os assuntos que podem necessitar de rastreamento e
fornece uma perspectiva multifacetada dos requisitos. Sessões de JAD permitem aos
analistas coletar simultânea e eficientemente uma grande quantidade de requisitos do
sistema junto a uma gama de usuários-chave. São úteis por considerar necessidades
específicas dos usuários. JAD também pode ser usada em conjunto com outra técnica de
elicitação como, por exemplo, a prototipação. À medida que os requisitos são obtidos nas
sessões, pode-se construir um protótipo que demonstre alguma funcionalidade destes
requisitos.
Anexo

Versão 29/2014
121
FAST (facilited application specification technique):
Combina: identificação do problema, negociação e especificação de um conjunto preliminar de requisitos.
Diretrizes básicas:
- Encontro de clientes e desenvolvedores em local neutro
- Estabelecer regras para preparação e participação;
- É sugerida uma agenda cobrindo todos os pontos importantes e que encoraja o livre fluxo de idéias;
- “Facilitador”(cliente,desenvolvedor, ou elemento externo) para controlar o encontro.
Anexo

Versão 29/2014
122
Documento de Requisitos: Formato do documento de especificação de requisitos sugerido pela IEEE/ANSI 830- 1993: Estrutura do Documento: 1.0 Introdução 1.1 propósito do documento de requisitos 1.2 escopo do produto 1.3 definições, acrônimos e abreviações 1.4 referências 1.5 visão geral do restante do documento 2.0 Descrição geral 2.1 perspectiva do produto 2.2 funções do produto 2.3 características do usuário 2.4 restrições gerais 2.5 suposições e dependências 3. Requisitos (Específicos) os requisitos podem documentar interfaces externas, descrever funcionalidade e desempenho do sistema, especificar requisitos lógicos de banco de dados,restrições de projeto, características de qualidade. 4. Apêndices 5. índice
Anexo

Versão 29/2014
Comunidade eTecnologia:
http://etecnologia.ning.com/
Gostou quer mais, gostaria de receber outros materiais sobre o mesmo tema e novas versões deste material... Venha para fazer parte da comunidade eTecnologia, clique: http://etecnologia.ning.com

Versão 29/2014
Notas:
Marcas Registradas:
Todos os termos mencionados que são reconhecidos como Marca Registrada e/ou comercial são de responsabilidades de seus proprietários. O autor informa não estar associada a nenhum produto e/ou fornecedor que é apresentado neste material. No decorrer deste, imagens, nomes de produtos e fabricantes podem ter sido utilizados, e desde já o autor informa que o uso é apenas ilustrativo para fins educativo, não visando ao lucro, favorecimento ou desmerecimento da marca ou produto.
Melhoria e Revisão:
Este material esta em processo constante de revisão e melhoria, se você encontrou algum problema ou erro envie um e-mail para nós.
Criticas e Sugestões: Nós estamos abertos para receber criticas e sugestões que possam melhorar o material, por favor envie um e-mail para nós.
Imagens:
Google, Flickr e Banco de Imagem.
Rildo Santos by rildosan® 2014 (@rildosan | rildosan@rildosan.com | rildosan.com)

Versão 29/2014
125
Licença:

Analise de Requisitos Software

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Analise de Requisitos Software

Similar to Analise de Requisitos Software (20)

More from Rildo (@rildosan) Santos

More from Rildo (@rildosan) Santos (20)

Analise de Requisitos Software