Você está na página 1de 122

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/

Análise de Requisitos de Software


Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007
Conteúdo:
Sobre o Autor

Sobre a Apresentação
Analise de Requisitos de Software

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 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;

Sou membro do IIBA-International Institute of Business Analysis (Canada)

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.

É abordado as principais técnicas, ferramentas e melhores práticas para desenvolvimento da


especificação de requisitos

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

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...”
Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 5
Introdução

Ciclo de Desenvolvimento de Software:


Melhores Práticas: A Metodologia de Teste deve ser aplicada durante todo o ciclo
de desenvolvimento do software
Analise de Requisitos de Software

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:

É apresentar e discutir o Ciclo de Requisitos de Software:


– Identificação, Elicitação, Análise, Especificação e
Validação

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

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 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

Stakeholder = Todos os clientes interessados no contexto de requisitos

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

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 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

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.

Stakeholder = Todos os clientes interessados no contexto de requisitos

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

- 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 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

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

Stakeholder = Todos os clientes interessados no contexto de requisitos

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

Fazer identificação e elicitação


Regras de
negócio
de requisitos

Documento de Visão

Fazer Análise de Requisitos


Usuários e
Clientes
Documento de
Requisitos
Fazer Especificação de Requisitos

Documentos Fazer Validação de Requisitos

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:

É apresentar e discutir as atividades de Identificação e


elicitação de requisitos

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

Fazer identificação e elicitação


Regras de
negócio
de requisitos

Documento de Visão

Fazer Análise de Requisitos


Usuários e
Clientes
Documento de
Requisitos
Fazer Especificação de Requisitos

Documentos Fazer Validação de Requisitos

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

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 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:

Elicitação Boa Elicitação Ruim


Analise de Requisitos de Software

Bom Diagnóstico Diagnóstico ineficiente


Soluções eficientes Soluções medíocres
Satisfação dos usuários Insatisfação dos usuários
Melhoria dos processos e redução de custo Problemas operacionais e financeiros

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:

Um projeto de elicitação de requisitos têm as seguintes fases:


Analise de Requisitos de Software

Identificar Fontes
Como deve ser feito ? Planejamento Técnicas

Elicitação de Identificar Funcionalidades


O que devo coletar ?
Requisitos Identificar Restrições e Riscos

Como devo documentar ? Documentação

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 ?

Existem várias técnicas, todas elas possuem seus


Analise de Requisitos de Software

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 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

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 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

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 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

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 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:

Os requisitos funcionais descrevem o que o sistema deve fazer, isto é, as funções


Analise de Requisitos de Software

necessárias para atender os objetivos do sistema.

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

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; - 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

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 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

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 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

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 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

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 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

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 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

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 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

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

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

Objetivo desta parte:

É apresentar e discutir as atividades da análise de


requisitos de software

Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 39
Análise de Requisitos

Requisitos. Road Map


Analise de Requisitos de Software

Fazer identificação e elicitação


Regras de
negócio
de requisitos

Documento de Visão

Fazer Análise de Requisitos


Usuários e
Clientes
Documento de
Requisitos
Fazer Especificação de Requisitos

Documentos Fazer Validação de Requisitos

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

Análise de Requisitos: Introdução


A análise de requisitos procura sistematizar o processo de definição de requisitos.
Analise de Requisitos de Software

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.

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

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 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

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

Classificar os
Requisitos não Funcionais

Documento de Requisitos
Descrever os Usuários
e Entidades Externas

Fazer 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 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:

Lista de Requisitos funcionais

Autor: Revisão: Data Atualização:

Nome Código Descrição


Fazer Reserva RF01E 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)

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

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.

id Nome da Regra Descrição da Regra de Negócio

A confirmação do registro de reserva de apartamento deve ocorrer após o pagamento de


RN01 Registrar Reserva de 25% do valor da estadia.
Apartamento 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.
Data Nome / Equipe Versão Status
Os códigos permitem a rastreabilidade 01/01/08 RFS 2.1 Vigente

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

Agora vamos descrever os Requisitos Não Funcionais. Entretanto, precisamos


categorizar estes requisitos, as mais frequente são:
- 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 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

Lista de Requisitos Não funcionais

Categoria: Performance

Autor: Revisão: Data Atualização:


Req. Funcional
Código Descrição

Fazer As consultas que serão realizadas pelo cliente não poderão


RNFP1
Consulta exceder ao tempo de resposta de 15 segundos

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 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:

Lista de Requisitos Não funcionais

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.

As interfaces com usuário devem seguir padrão de interfaces


Aplicação RNFU2
estabelecido pelo Manual de Sistema

Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 48
Análise de Requisitos

Análise de Requisitos. Detalhar


Lista de Stakeholders:
Analise de Requisitos de Software

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

Autor: Revisão: Data Atualização:

Nome Descrição

Cliente São todas as pessoas físicas ou jurídicas que fazem reservas

É qualquer pessoa que presta algum tipo serviço para


Colaborador
empresa

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:

Lista dos Stakeholders

Autor: Revisão: Data Atualização:

Nome Descrição

Administradora de Entidade que faz validação de um cartão de crédito presente


Cartão de Crédito em transação de pagamento.

Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 50
Análise de Requisitos

Análise de Requisitos. Elaborar:


Plano de Mitigação de Riscos:
Analise de Requisitos de Software

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 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 51
Análise de Requisitos

Análise de Requisitos. Artefato


Documento de Requisitos:
Analise de Requisitos de Software

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

Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007 52
Análise de Requisitos

Análise de Requisitos. Artefato.Template


Documento de Requisitos:
Analise de Requisitos de Software

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

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...

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 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:

É apresentar as principais técnicas para 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 55
Especificação de Requisitos com Caso de Uso

Requisitos. Road Map


Analise de Requisitos de Software

Fazer identificação e elicitação


Regras de
negócio
de requisitos

Documento de Visão

Fazer Análise de Requisitos


Usuários e
Clientes
Documento de
Requisitos
Fazer Especificação de Requisitos

Documentos Fazer Validação de Requisitos

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

Requisitos Requisitos Não Restrições


Analise de Requisitos de Software

Documento
de Visão Funcionais Funcionais de Projeto

Documento de
Requisitos

Arquitetura
Especificação de Requisitos do Software

Comportamento externo Casos de Uso

Comportamento interno Seqüência Colaboração

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

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
Analise de Requisitos de Software

quer. Um caso de uso descreve uma funcionalidade (“requisito”) a ser oferecida


pelo sistema, ou seja, um serviço.

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.

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 cenários Ferramenta de


Modelagem UML

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:

Caso de Uso é uma representação gráfica e semântica da


Analise de Requisitos de Software

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 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

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.

Caso de Uso Os nomes de casos de uso


Gerenciar são breves expressões verbais
Reserva ativas.
Usuário
Ator
Nome

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:

Os casos de uso exibem a funcionalidade na perspectiva do usuário. Entretanto,


Analise de Requisitos de Software

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 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

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.”

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.

Se senha for invalida ou nome neste caso teremos um novo cenário.

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.

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 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:

Tipicamente descrevemos um fluxo de eventos para um caso de uso. Os fluxos de eventos


Analise de Requisitos de Software

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.

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

- 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 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:

Nome: Fazer Busca Produto


Analise de Requisitos de Software

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: ---

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

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 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

Manter informações dos


Manter informação de cursos
aluno

Gerente de
Educção Gerar catalogo
Manter informação de
professor

Pedir lista dos


matriculados
Sistema de
cobrança
Matrícula nos
Cursos
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

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 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

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 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

Pagto Cartão de Crédito Pagto Cartão de Débito

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

caso de uso pode ser executado. Variação de Comportamento. Exemplo:

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

<<include>> Validar Usuário

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

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 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

- 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 .

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

Caso de Uso: Gerenciar Reserva

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

Identificando a pré-condição e pós-condição:


Cenário
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
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

Primeiras linhas do cená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
Gerenciar Reserva Pré-condição: Solicitação de reserva
“caminho feliz” Fluxo Normal:

Gerenciar Reserva Fluxo Alternativo:


“caminho alternativo”

Pós-condição: Reserva confirmada

Última linha do cenário


86

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

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

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

Caso de Uso: Gerenciar Reserva

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

Ferramenta: Enterprise Architect (EA)

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

• 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 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

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).

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”:

Data: ______ | Autor: ________ | Revisão: ____


Analise de Requisitos de Software

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>

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

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”
94
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
Exemplo 2 – Adicionando o <<include>>
Analise de Requisitos de Software

Sem include: Com include:

<<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

Sem include: Com include:


<<include>>
Consultar
Cliente
<<include>> Consultar
Recepcionista Reserva
Fazer Check OUT

<<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

Objetivo desta parte:

É apresentar as principais técnicas para validação de


requisitos de software.

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

Fazer identificação e elicitação


Regras de
negócio
de requisitos

Documento de Visão

Fazer Análise de Requisitos


Usuários e
Clientes
Documento de
Requisitos
Fazer Especificação de Requisitos

Documentos Fazer Validação de Requisitos

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

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 é
Analise de Requisitos de Software

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 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.

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

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

25 24 Fazer Login Validar o Caso de Uso: Fazer Login de Acesso

Cenário Resultado Esperado Resultado Observado OK ?

Fluxo Normal Usuário autorizado


Usuário autorizado (Sucesso) OK
Entrada: nome e senha (Sucesso)

Fluxo Alternativo 1 Mensagem usuário


Usuário autorizado (Sucesso) NOK
Entrada: nome e senha inválido (Insucesso)

Nome do Testador: Data:


____/____/_____

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

Verificação de Consistência Automatizada:


Analise de Requisitos de Software

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:

É apresentar as principais técnicas para processo de


gerenciamento de mudança de requisitos de software.

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.

Requisitos são inevitavelmente incompletos e inconsistentes:


Analise de Requisitos de Software

• 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

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

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 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:

Durante o processo de engenharia de requisitos, será necessário planejar:


Analise de Requisitos de Software

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 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 preocupa-se com as relações entre requisitos, suas fontes e o projeto do


software/sistema
Analise de Requisitos de Software

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:

Armazenamento dos requisitos:


Analise de Requisitos de Software

- 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 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

- 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.

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

Exemplo: Matriz de Rastreabilidade (na ferramenta ReqPro):


Analise de Requisitos de Software

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

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.

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

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.

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):

Combina: identificação do problema, negociação e especificação de um conjunto


preliminar de requisitos.
Analise de Requisitos de Software

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:

Formato do documento de especificação de requisitos sugerido pela IEEE/ANSI 830-


1993:
Analise de Requisitos de Software

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.

Rildo F dos Santos (rildosan@uol.com.br)


rildo.santos@companyweb.com.br

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/

Análise de Requisitos de Software


Versão 28 Rildo F Santos (rildosan@uol.com.br) Todos os direitos reservados e protegidos © 2006 e 2007