Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
rildosan@uol.com.br
rildo.santos@companyweb.com.br
Analise de Requisitos de Software
Twitter: http://twitter.com/rildosan
Blog: http://rildosan.blogspot.com/
Sobre a Apresentação
Analise de Requisitos de Software
Introdução
1 – Requisitos de Software
3 - Análise de Requisitos
5 - Validação de Requisitos
Anexo
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 2
Sobre o autor:
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.
Analise de Requisitos de Software
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.
Rildo Santos 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: http://twitter.com/rildosan
Blog: http://rildosan.blogspot.com/
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 3
Analise de Requisitos de Software 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.
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 4
Introdução
Análise de Requisitos: Introdução
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
Analise de Requisitos de Software
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...”
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 5
Introdução
Fases
Fluxos de Trabalho Concepção Elaboração Construção Transição
Modelagem de Negócios
Nosso Requisitos
escopo
Análise e Projeto
Implementação
Teste
Implantação
Opcional
Gerência de Configuração
Gerência de Projeto
Ambiente
Iterações Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Preelim. #1 #2 #n #n+1 #n+2 #m #m+1
Iterações
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 6
Analise de Requisitos de Software Introdução
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.
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 7
Analise de Requisitos de Software Requisitos de Software
Requisitos de Software
Objetivo desta parte:
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 8
Introdução
Um cenário comum:
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 9
Requisitos de Software
Requisitos
Definições de requisito (segundo IEEE)
Analise de Requisitos de Software
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.
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 10
Requisitos de Software
Contexto de Definição de Requisito:
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 11
Requisitos de Software
Elicitação de Requisitos
A elicitação de requisitos corresponde a identificar junto aos clientes/usuários quais são
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 12
Requisitos de Software
Elicitação de Requisitos
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
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 13
Elicitação de Requisitos
Para a maioria dos sistemas, estes documentos de trabalho incluem:
Analise de Requisitos de Software
Stakeholder = Todos os clientes interessados no contexto de requisitos, pode ser uma pessoa ou entidade
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 14
Requisitos de Software
Elicitação de Requisitos
Objetivos da Elicitação de Requisitos:
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 15
Requisitos de Software
Requisitos. Road Map
Analise de Requisitos de Software
Documento de Visão
Documento de
Especificação
de Requisitos
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 16
Analise de Requisitos de Software
Identificação e Elicitação de
Requisitos
Objetivo desta parte:
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 17
Identificação e Elicitação de Requisitos
Requisitos. Road Map
Analise de Requisitos de Software
Documento de Visão
Documento de
Especificação
de Requisitos
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 18
Identificação e Elicitação de Requisitos
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.
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 19
Identificação e Elicitação de Requisitos
Uma Simples Comparação:
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 20
Identificação e Elicitação de Requisitos
Documento (Artefato) desta etapa: “Documento de Visão”
Analise de Requisitos de Software
Participantes:
Analistas e Documentos
Reuniões e Objetivo:
Especialista e sistemas
em Negócios
Workshops Descrever
a visão inicial
Participantes: identificação/
do software
Usuário, elicitação de
Clientes, Requisitos
Fornecedores e Documento
Patrocinadores Observação de visão
Entrevistas
de campo
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 21
Identificação e Elicitação de Requisitos
As fases da Identificação/Elicitação de Requisitos:
Identificar Fontes
Como deve ser feito ? Planejamento Técnicas
Documento de Visão
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 22
Identificação e Elicitação de Requisitos
As informações podem ser identificadas ou encontradas em diversas fontes:
- Usuários;
- Documentos;
Analise de Requisitos de Software
- 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 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 23
Identificação e Elicitação de Requisitos
Quais são as técnicas ?
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 24
Identificação e Elicitação de Requisitos
Quais as informações que devo identificar, levantar e
coletar ?
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 25
Identificação e Elicitação de Requisitos
- Contexto:
Após o entendimento do problema podemos escrever a
Declaração do Problema e também desenhar um diagrama de
contexto.
Analise de Requisitos de Software
- 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 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 26
Identificação e Elicitação de Requisitos
- Identificação dos “Stakeholders”
Que é “stakeholders” ?
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 27
Identificação e Elicitação de Requisitos
- Identificação dos Requisitos:
Identificar as funcionalidades do software que deve ter para atender as
necessidades do usuário.
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 28
Identificação e Elicitação de Requisitos
- Identificação dos Requisitos: Tipos de Requisitos
Os requisitos podem ser divididos em duas categorias:
Analise de Requisitos de Software
Requisitos
Requisitos Requisitos
Funcionais Não-Funcionais
Definem as Declaram as
funcionalidades do características que o
sistema. O que sistema sistema deve possuir e
deve fazer. que estão relacionadas
às suas
funcionalidades.
Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 29
Identificação e Elicitação de Requisitos
- Identificação dos Requisitos: Tipos de Requisitos
Requisitos Funcionais:
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.
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 30
Identificação e Elicitação de Requisitos
- Identificação dos Requisitos: Tipos de Requisitos
Requisitos Não Funcionais:
Os requisitos não funcionais dizem respeito as características do software, exemplos:
Analise de Requisitos de Software
- Confidencialidade; - Portabilidade;
- Confiabilidade; - Precisão;
- Performance; - Integridade;
- Qualidade; - Segurança
- Usabilidade; - etc.
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 31
Identificação e Elicitação de Requisitos
- 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).
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 32
Identificação e Elicitação de Requisitos
Exemplo:
Declaração do Problema
Exemplo: Acompanhamento das estatísticas de aprendizado do aluno e da turma (professor)
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 33
Identificação e Elicitação de Requisitos
- 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
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 34
Identificação e Elicitação de Requisitos
- Identificação de Riscos:
- Tecnologia:
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 35
Identificação e Elicitação de Requisitos
- Identificação das Restrições:
Definem o conjunto de restrições impostas sobre o
desenvolvimento do software.
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 36
Identificação e Elicitação de Requisitos
Documento de Visão:
Objetivo:
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 37
Identificação e Elicitação de Requisitos
Exemplo de Simples Documento de Visão:
Documento de Visão:
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 38
Analise de Requisitos de Software
Análise de Requisitos
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 39
Análise de Requisitos
Documento de Visão
Documento de
Especificação
de Requisitos
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 40
Análise de Requisitos
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 41
Análise de Requisitos
Análise de Requisitos
A Análise de Requisitos deve ser:
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 42
Análise de Requisitos
Análise de Requisitos
Atividades da Análise de Requisitos
A análise de requisitos possibilita que o Analista de Sistemas especifique as
Analise de Requisitos de Software
Detalhar os
Requisitos Funcionais
Classificar os
Requisitos não Funcionais
Documento de Requisitos
Descrever os Usuários
e Entidades Externas
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 43
Análise de Requisitos
Análise de Requisitos. Detalhar
Requisitos Funcionais:
Analise de Requisitos de Software
Os requisitos funcionais devem ser detalhados. Devemos usar um formato padrão para
esta atividade. Veja o exemplo:
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 44
Análise de Requisitos
Análise de Requisitos. Detalhar
Descrição de Regras de Negócio
Analise de Requisitos de Software
Requisitos Funcional
RN: RN01 Nome: Reserva Descrição: Serviço de Atendimento e Reserva de Apartamento
ID Nome Descrição
RFC01 Registrar Reserva Esta funcionalidade deverá permitir o usuário (funcionário) a fazer reserva de apartamentos,
de Apartamento as ações que estarão disponíveis são: criar, cancelar, alterar e consultar reservas.
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 45
Análise de Requisitos
Análise de Requisitos. Classificar
Requisitos Não Funcionais:
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 46
Análise de Requisitos
Análise de Requisitos. Classificar e Detalhar
Requisitos Não Funcionais:
Analise de Requisitos de Software
Bem vamos descrever os requisitos não funcionais. Como na descrição dos Requisitos
funcionais, precisamos ter um padrão
Categoria: Performance
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 47
Análise de Requisitos
Análise de Requisitos. Classificar e Detalhar
Requisitos Não Funcionais:
Analise de Requisitos de Software
Continuação:
Categoria: Usabilidade
Autor: Revisão: Data Atualização:
RF /
Código Descrição
Aplicação
As cores, as fontes e logotipos devem seguir o Manual de
Aplicação RNFU1
Identidade Visual da empresa.
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 48
Análise de Requisitos
Lista de Stakeholders
Nome Descrição
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 49
Análise de Requisitos
Análise de Requisitos. Detalhar
Lista de Stakeholders:
Analise de Requisitos de Software
Continuação:
Nome Descrição
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 50
Análise de Requisitos
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 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 51
Análise de Requisitos
Objetivo:
Classificar, descrever os requisitos de software,
usuários e entidade externas e elaboração do
plano de redução de risco
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 52
Análise de Requisitos
Í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
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 53
Análise de Requisitos
Mitos e Lendas:
Analise de Requisitos de Software
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...
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 54
Analise de Requisitos de Software
Especificação de Requisitos
com Caso de Uso
Objetivo desta parte:
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 55
Especificação de Requisitos com Caso de Uso
Documento de Visão
Documento de
Especificação
de Requisitos
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 56
Especificação de Requisitos com Caso de Uso
Documento
de Visão Funcionais Funcionais de Projeto
Documento de
Requisitos
Arquitetura
Especificação de Requisitos do Software
Estrutura Classes
Implementação Distribuição
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007
57
Especificação de Requisitos com Caso de Uso
Objetivos:
• Identificar os atores;
• Identificar os casos de uso;
• Desenhar os casos de uso e
• Escrever cenários.
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 58
Analise de Requisitos de Software Especificação de Requisitos com Caso de Uso
Transformar os Requisitos
Funcionais em Casos de Uso:
Calcular Total
Fazer Cadastro
Cliente
Funcionário
Fazer Pedido
Emitir NF
59
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007
Especificação de Requisitos com Caso de Uso
Atividades e Passos:
Fazer Diagrama de
Analise de Requisitos de Software
Casos de Uso
Identificar Atores /
Casos de Uso
Escrever Formulário
Fazer Diagrama de
Caso de Uso
Refinar Diagrama de
Casos de Uso
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 60
Especificação de Requisitos com Caso de Uso
Introdução:
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 61
Especificação de Requisitos com Caso de Uso
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
Analise de Requisitos de Software
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.
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 62
Especificação de Requisitos com Caso de Uso
Casos de Uso e Cenários:
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 63
Especificação de Requisitos com Caso de Uso
Casos de Uso e Cenários:
Exemplos:
Analise de Requisitos de Software
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.
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 64
Especificação de Requisitos com Caso de Uso
Casos de Uso e Cenários:
Exemplos:
Analise de Requisitos de Software
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.
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 65
Especificação de Requisitos com Caso de Uso
Casos de Uso e Fluxo de Eventos:
Analise de Requisitos de Software
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.
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 66
Especificação de Requisitos com Caso de Uso
Casos de Uso e Fluxo de Eventos:
Fluxo Normal
Fluxo
alternativo 2
Fluxo
alternativo 1
Fluxo
alternativo 3
Cenário 1
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 67
Especificação de Requisitos com Caso de Uso
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)
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 68
Especificação de Requisitos com Caso de Uso
Exemplo Formulário de Descrição de Caso Uso:
69
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007
Especificação de Requisitos com Caso de Uso
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
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 70
Especificação de Requisitos com Caso de Uso
Exemplos de Casos de Uso:
Analise de Requisitos de Software
Gerente de
Educção Gerar catalogo
Manter informação de
professor
Aluno
Selecionar curso
para ensinar
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 71
Especificação de Requisitos com Caso de Uso
Elementos dos Caso de Uso:
Ator:
Um ator representa um conjunto coerente de papéis que os usuários de casos de
Analise de Requisitos de Software
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 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 72
Especificação de Requisitos com Caso de Uso
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
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 73
Especificação de Requisitos com Caso de Uso
Generalização:
Podemos usar a generalização entre casos de uso, pelo mesmo motivo que utilizamos
nas classes, para compartilhar comportamento:
Analise de Requisitos de Software
Receber Pagamento
generalização
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 74
Especificação de Requisitos com Caso de Uso
Generalização:
A generalização também pode ser aplicado aos atores e seus respectivos papéis. Veja
o exemplo:
Analise de Requisitos de Software
Funcionário
Recepcionista Gerente de
Reservas
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 75
Especificação de Requisitos com Caso de Uso
Extends:
Podemos usa-lo para “Demonstrar Variação de Comportamento”:
Cada uma das extensões descreve as diferentes maneiras com que um passo do
Analise de Requisitos de Software
Locadora de Automóveis
Devolver Veículo
<<extend>>
<<include>>
<<include>>
Calcular Multa
Alterar status do carro Consulta Cliente
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 76
Especificação de Requisitos com Caso de Uso
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.
Analise de Requisitos de Software
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.
Fazer Pedido
Acompanhar Pedido
<<include>>
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 77
Especificação de Requisitos com Caso de Uso
Include. (Mais) exemplos:
Analise de Requisitos de Software
Fazer Check IN
Fazer Check OUT
Gerenciar Reserva
Receber Pagamento
<<include>>
<<include>>
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 78
Especificação de Requisitos com Caso de Uso
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.
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 79
Especificação de Requisitos com Caso de Uso
Um engano comum na identificação de casos de uso é representar como Caso de uso
passos individuais, operações ou transações.
Analise de Requisitos de Software
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.
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 80
Especificação de Requisitos com Caso de Uso
Estudo de Caso:
O hotel contém um número de apartamentos disponíveis para ser alugado aos hospedes. Cada apartamento tem as
seguintes propriedades:
Analise de Requisitos de Software
1 Requisitos Funcionais
2
• Gerenciar Reserva
•...
Refinado pelo
Documento de
Visão
„
Documento
de Requisitos
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 81
Especificação de Requisitos com Caso de Uso
Estudo de Caso:
Especificação de Requisitos:
Analise de Requisitos de Software
3
Formulário
Cenários
Gerenciar Reserva
Usuário
Caso de Uso
Ator
Associação
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 82
Especificação de Requisitos com Caso de Uso
Estudo de Caso:
Escrevendo os Cenários:
Analise de Requisitos de Software
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.
Cenários O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e confirma a
reserva.
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.
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 83
Especificação de Requisitos com Caso de Uso
Estudo de Caso:
Escrevendo os Cenários:
Analise de Requisitos de Software
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.
Cenários 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.
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 84
Especificação de Requisitos com Caso de Uso
Estudo de Caso:
Escrevendo o Formulário:
Compilar os Cenários em Formulário:
Analise de Requisitos de Software
Cenários Formulário
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
Pré- condição ele precisa.
O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e confirma a
reserva.
Pós- condição
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 85
Especificação de Requisitos com Caso de Uso
Estudo de Caso:
Escrevendo o Formulário:
Compilar os Cenários em Formulário:
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007
Especificação de Requisitos com Caso de Uso
Estudo de Caso:
Escrevendo o Formulário:
Formulário:
Analise de Requisitos de Software
Ator: Funcionário
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 87
Especificação de Requisitos com Caso de Uso
Estudo de Caso:
Especificação de Requisitos:
Analise de Requisitos de Software
3
Formulário
Cenários
Gerenciar Reserva
Funcionário
Caso de Uso
Ator Associação
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 88
Analise de Requisitos de Software Especificação de Requisitos com Caso de Uso
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 89
Especificação de Requisitos com Caso de Uso
Mitos e Lendas
• Requisitos não são Casos de Uso;
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 90
Especificação de Requisitos com Caso de Uso
Atividades e Passos:
Fazer Diagrama de
Analise de Requisitos de Software
Casos de Uso
Identificar Atores /
Casos de Uso
Escrever cenários
Rational Rose
Escrever Formulário
Fazer Diagrama de
Caso de Uso
Refinar Diagrama de
Casos de Uso
91
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007
Especificação de Requisitos com Caso de Uso
Vamos fazer os Caso de Uso (iniciais)
Especificação de Requisitos, como fazer:
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 92
Especificação de Requisitos com Caso de Uso
Modelo do “Formulário de Descrição de Requisitos”:
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 93
Especificação de Requisitos com Caso de Uso
Refinar: Atividades e Passos
Fazer Diagrama de
Analise de Requisitos de Software
Casos de Uso
Identificar Atores /
Casos de Uso
Escrever cenários
Rational Rose
Escrever Formulário
Fazer Diagrama de
Caso de Uso
Refinar Diagrama de
Casos de Uso
<<include>>
Buscar Apartamento
Funcionário Gerenciar
Reserva
<<include>>
Funcionário Gerenciar Cadastrar Cliente
Reserva
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 95
Especificação de Requisitos com Caso de Uso
Exemplo 1 – Adicionando o <<include>> e <<extend>>
Analise de Requisitos de Software
Cancelar
Check IN
<<extend>>
Recepcionista Fazer Check IN
<<include>>
Recepcionista Fazer Check IN Consultar
Reserva
<<include>>
Consultar
Cliente
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 96
Especificação de Requisitos com Caso de Uso
Exemplo 3 – Adicionando o <<include>>
Analise de Requisitos de Software
<<include>>
Recepcionista Fazer Check Receber
OUT Pagamento
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 97
Analise de Requisitos de Software
Validação de Requisitos
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 98
Validação de Requisitos
Requisitos. Road Map
Analise de Requisitos de Software
Documento de Visão
Documento de
Especificação
de Requisitos
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 99
Validação de Requisitos
grande.
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 100
Validação de Requisitos
Técnicas de validação de requisitos
Revisão de requisitos:
- Análise manual sistemática dos requisitos
Analise de Requisitos de Software
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.
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?
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 101
Validação de Requisitos
Caso de Teste
Definição: Caso de Teste
Analise de Requisitos de Software
- 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.
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 102
Validação de Requisitos
Caso de Teste
Definição: Modelo de Teste - Caso de Teste. Exemplo:
Analise de Requisitos de Software
Caso de Teste
ID Caso Teste ID Caso de Uso Nome Descrição
Caso de Uso
Fluxo Normal
Fluxo
alternativo 2 Fazer Login
Fluxo
alternativo 1
Cliente
Fluxo Descrição
alternativo 3 do Caso de Uso
Cenário 1
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 103
Validação de Requisitos
Técnicas de validação de requisitos
Requisitos em
Relatório
linguagem formal
Processador de Análise de
Requisitos Requisitos
Base de Dados
de Requisitos
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 104
Analise de Requisitos de Software
Gerenciamento de Mudança
de Requisitos
Objetivo desta parte:
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 105
Gerenciamento de Mudança de Requisitos
Gerenciamento de Mudança de Requisitos é o processo de controlar as mudanças nos
requisitos durante o processo de engenharia de requisitos e desenvolvimento.
- A prioridade dos requisitos podem mudar para atender novas demandas de negócio
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 106
Gerenciamento de Mudança de Requisitos
Evolução dos requisitos
Analise de Requisitos de Software
Entendimento
Entendimento
do problema
inicial do problema
(alterado)
Requisitos Requisitos
iniciais modificados
tempo
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 107
Gerenciamento de Mudança de Requisitos
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
Analise de Requisitos de Software
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 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 108
Gerenciamento de Mudança de Requisitos
Planejamento do gerenciamento de requisitos:
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 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 109
Gerenciamento de Mudança de Requisitos
Rastreabilidade:
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 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 110
Gerenciamento de Mudança de Requisitos
Suporte à ferramenta:
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 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 111
Gerenciamento de Mudança de Requisitos
Gerenciamento de Mudanças de Requisitos:
Deve ser feita em qualquer proposta de mudança de requisito.
Principais estágios:
Analise de Requisitos de Software
Solicitação
de Mudança de Requisito
Requisito Análise do Problema Alterado
Análise e custo implementação
e especificação da
mudança da mudança
mudança
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 112
Gerenciamento de Mudança de Requisitos
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 113
Gerenciamento de Mudança de Requisitos
Exemplo: Matriz de Rastreabilidade (na ferramenta EA):
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 114
Analise de Requisitos de Software
Conteúdo:
Técnicas para identificação/elicitação de requisitos:
- JAD
- FAST
Documento de Requisitos
- Padrão IEEE/ANSI 830-1993:
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 115
Anexo
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
Analise de Requisitos de Software
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
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.
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 116
Anexo
JAD (Join Application Development)
continuação
A técnica pode ser usada tanto para elicitar como nas fases iniciais da especificação de
Analise de Requisitos de Software
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 117
Anexo
FAST (facilited application specification technique):
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.
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 118
Anexo
Documento de Requisitos:
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
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 119
Notas:
Marcas Registradas:
Todos os termos mencionados e reconhecidos como Marca Registrada e/ou comercial são de
responsabilidade de seus proprietários. O autor informa não estar associada a nenhum produto e/ou
Analise de Requisitos de Software
fornecedor 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 e/ou educativo, não
visando ao lucro, favorecimento ou desmerecimento do produto/fabricante.
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.
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.
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 120
Analise de Requisitos de Software Licença:
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 121
Rildo F Santos
rildosan@uol.com.br
rildo.santos@companyweb.com.br
Analise de Requisitos de Software
Twitter: http://twitter.com/rildosan
Blog: http://rildosan.blogspot.com/