Analise de Requisitos Software

Rildo F Santos ([email protected])Versão 28

An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re

Todos os direitos reservados e protegidos © 2006 e 2007

Análise de Requisitos de Software

Rildo F [email protected]

[email protected]

Twitter: http://twitter.com/rildosan

Blog: http://rildosan.blogspot.com/

mailto:[email protected]?subject=Contato




An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re

Todos os direitos reservados e protegidos © 2006 e 2007 2

Conteúdo:

Sobre o Autor

Sobre a Apresentação

Introdução

1 – Requisitos de Software

2 - Identificação e Elicitação de Requisitos

3 - Análise de Requisitos

4 - Especificação de Requisitos com Caso de Uso

5 - Validação de Requisitos

6 - Gerenciamento de Mudança de Requisitos

Anexo


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Sobre o autor:

Rildo Santos

Coach e Consultor de Gestão de Negócios, Inovação e Tecnologia para a Gestão 2.0, a Gestão Ágil.

A Gestão Ágil ajuda as empresas a responder mais rápido as demandas de negócio e mudanças. A Gestão 2.0, abrange

Planejamento Estratégico, Gestão por Processos Ágeis, Gestão de Projetos Ágeis, Tecnologia da Informação (Métodos Ágeis),

Inovação e Liderança.

Minha Experiência:

Tenho mais de 10.000 horas de experiência em Gestão de Negócios, Gestão de Inovação, Governança e Engenharia de

Software. Formado em Administração de Empresas, Pós-Graduado em Didática do Ensino Superior e Mestre em Engenharia

de Software pela Universidade Mackenzie.

Fui instrutor de Tecnologia de Orientação a Objetos, UML e Linguagem Java na Sun Microsystems e na IBM.

Conheço Métodos Ágeis (SCRUM, Lead, FDD e XP), Arquitetura de Software, SOA (Arquitetura Orientado a Serviço),

RUP/UP - Processo Unificado, Business Intelligence, Gestão de Risco de TI entre outras tecnologias.

Sou professor de curso de MBA da Fiap e fui professor de pós-graduação da Fasp e IBTA.

Possuo fortes conhecimentos de Gestão de Negócio (Inteligência de Negócio, Gestão por Processo, Inovação, Gestão de

Projetos e GRC - Governance, Risk and Compliance), SOX, Basel II e PCI;

E experiência na implementação de Governança de TI e Gerenciamento de Serviços de TI. Conhecimento dos principais

frameworks e padrões: ITIL, Cobit, ISO 27001 e ISO 15999;

Desempenhei diversos papéis como: Estrategista de Negócio, Gerente de Negócio, Gerente de Projeto, Arquiteto de Software,

Projetista de Software e Analista de Sistema em diversos segmentos: Financeiro, Telecomunicações, Seguro, Saúde,

Comunicação, Segurança Pública, Fazenda, Tecnologia, Varejo, Distribuição, Energia e Petróleo e Gás.

Possuo as certificações: CSM - Certified SCRUM Master, CSPO - Certified SCRUM Product Owner , SUN Java Certified

Instrutor, ITIL Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games;

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

Onde estou:



http://twitter.com/rildosan


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


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


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Um entendimento completo dos requisitos de software é essencial para um o sucesso do

desenvolvimento do software. Não importa quão bem projetado ou quão bem codificado

seja, um programa mal analisado e especificado frustrará o usuário.

Análise de requisitos é um processo de descoberta, refinamento, modelagem e

especificação.

O escopo do software, inicialmente estabelecido pelo Analista de Sistemas e refinado

durante o planejamento do projeto de software, é aperfeiçoado em detalhes.

Modelos, diagramas, fluxos são criados para melhor compreensão do problema.

O analista e o usuário desempenham um papel ativo na análise e especificação de

requisitos.

O cliente (usuário) tenta reformular um conceito de função e desempenho de software, às

vezes nebuloso, sem detalhes concretos. O analista age como indagador, consultor e

solucionador de problemas.

Entretanto, a análise e especificação de requisitos pode parecer uma tarefa relativamente

simples, mas as aparências enganam. O grau comunicação é elevado. Daí, surgem as

oportunidades de interpretações errôneas e informações falsas. A ambigüidade é provável.

O dilema com o qual se depara um analista pode ser mais bem entendido, repetindo-se a

declaração de um cliente anônimo:

“Sei que você acredita que entendeu o que acha que eu disse, mas não estou certo

que percebeu que aquilo que ouviu não é o que eu pretendia dizer...”

Análise de Requisitos: Introdução

Introdução


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Gerência de Projeto

Ambiente

Modelagem de Negócios

Implementação

Teste

Análise e Projeto

Fluxos de Trabalho

Iterações

Implantação

Gerência de Configuração

Requisitos

IteraçõesPreelim.

Iter.#1

Fases

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Elaboração TransiçãoConcepção Construção

Opcional

Ciclo de Desenvolvimento de Software:Melhores Práticas: A Metodologia de Teste deve ser aplicada durante todo o ciclo

de desenvolvimento do software

Nosso

escopo

Introdução


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Da perspectiva da engenharia de software, a “elicitação” de requisitos é talvez a mais parte mais critica

do processo de desenvolvimento de software.

Estudos indicam que os requisitos, só detectados depois do software implementado ou erros na análise

de requisitos, são até 20 vezes mais caros de se corrigir que qualquer outro tipo de erro.

Introdução


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


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



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Um cenário comum:

Introdução


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Requisitos

Definições de requisito (segundo IEEE)1) Uma condição ou uma capacidade de que o usuário necessita para solucionar um

problema ou alcançar um objetivo.

2) Uma condição ou uma capacidade que deve ser alcançada ou possuída por um sistema

ou componente do sistema, para satisfazer um contrato, um padrão, uma especificação

ou outros documentos impostos formalmente.

3) Uma representação documentada de uma condição ou capacidade, conforme os itens

(1) e (2).



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Contexto de Definição de Requisito:

Stakeholder = Todos os clientes interessados no contexto de requisitos



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Elicitação de Requisitos

A elicitação de requisitos corresponde a identificar junto aos clientes/usuários quais são

os objetivos do sistema, o que deve ser acompanhado, como o sistema se „encaixa‟ no

contexto das necessidades do negócio e, finalmente, como será a utilização do sistema

no dia-a-dia.

“A parte mais árdua na construção de um software consiste exatamente em identificar

o que construir. Nenhuma outra parte do trabalho compromete tanto o resultado do

trabalho se elaborado de forma incorreta. Nenhuma outra parte oferece tanta dificuldade

para efetuar correções posteriores. " — F. Brook

Apesar de parecer simples, trata-se de um processo extremamente complexo. Algumas

das razões desta dificuldade:

Problemas de escopo:

Os limites do sistema são geralmente definidos de forma incompleta, ou os

clientes/usuários especificam detalhes técnicos desnecessários;

Problemas de compreensão:

Os clientes/usuários geralmente não estão completamente certos das necessidades, têm

uma pouca compreensão ou do domínio do seu negócio, omitem informações que julgam

óbvias e etc.

Problemas de volatilidade:

Os requisitos mudam o tempo todo.



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re




Para ajudar a superar estes problemas, os desenvolvedores devem abordar os requisitos

de forma simples, prática e organizada. Alguns passos são recomendados para atividade

de Elicitação de Requisitos de Software:

- Avaliar a viabilidade técnica e de negócio para o sistema proposto;

- Identificar as pessoas que vão auxiliar a especificar os requisitos e compreender seus

preconceitos organizacionais;

- Definir o ambiente técnico no qual o sistema será instalado;

- Identificar regras de domínio que limitam a funcionalidade ou desempenho do software

que será construído;

- Definir um ou mais métodos de elicitação de requisitos;

- Solicitar participação de várias pessoas para que os requisitos sejam definidos a partir

de diversos pontos de vista;

- Identificar claramente a justificativa de existência para cada requisito registrado;

- Identificar requisitos ambíguos que serão candidatos a prototipação.

Os documentos criados como conseqüência da atividade de elicitação de requisitos irão

depender do tamanho do software/sistema que será construído.



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re



Para a maioria dos sistemas, estes documentos de trabalho incluem:

- As necessidades e viabilidade estruturadas;

- O limite de escopo do software/sistema;

- Lista de clientes, usuários e outros stakeholders* que participaram da atividade de

elicitação de requisitos;

- Descrição do ambiente técnico do sistema;

- Lista de requisitos e as regras de domínio aplicáveis a cada um.

- Conjunto de cenários de uso capazes de prover uma idéia do uso do sistema ou

produto sob diferentes condições de operação;

- Qualquer protótipo que eventualmente tenha sido desenvolvido para melhor definir os

requisitos.

Cada um destes documentos deve ser revisado por todas as pessoas que tenham

participado da elicitação de requisitos.

Stakeholder = Todos os clientes interessados no contexto de requisitos, pode ser uma pessoa ou entidade


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re




Objetivos da Elicitação de Requisitos:

Obter conhecimento relevante para o problema e prover o mais correto entendimento de

o que é esperado do software/sistema;

Técnicas para Elicitação de Requisitos:

- Cenários: representar tarefas que executam e as que desejam executar

- Técnicas tradicionais: questionários, entrevistas, análise de documentação existente

- Técnicas de elicitação de grupo: Dinâmica de grupo

- Prototipação: quando existe alto grau de incerteza e necessita de um rápido feedback



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Documento de Visão

Fazer identificação e elicitação

de requisitos

Requisitos. Road Map

Fazer Análise de Requisitos

Fazer Especificação de Requisitos

Documento de

Requisitos

Documento de

Especificação

de Requisitos

Regras de

negócio

Usuários e

Clientes

Documentos Fazer Validação de Requisitos



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Identificação e Elicitação de

Requisitos


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

elicitação de requisitos


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Documento de Visão


de requisitos




Documento de

Requisitos

Documento de

Especificação

de Requisitos

Usuários e

Clientes


Regras de

negócio

Identificação e Elicitação de Requisitos

http://egemsource.com/images/pic/main_column/check_mark.jpg


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Identificação e elicitação de requisitos é uma tarefa que parece simples, mas, não devemos

nos enganar, às vezes, para obtermos algumas informações é exigido muita dedicação,

persistência e técnica.

Esta parte apresenta e discute as principais técnicas para identificação e elicitação de

requisitos de software.


Por que o “elicitação” é importante:

O sucesso no desenvolvimento de um projeto de software depende basicamente da

elicitação de requisitos, pois, é a base que permitirá ao Analista tirar conclusões sobre as

situações, problemas ou fenômenos e, assim, sugerir propostas que possam contribuir para

a solução do problema.

Entretanto, esta atividade, nem sempre está presente no processo de desenvolvimento,

raramente ela é elaborada de forma metodológica, geralmente tem uma abordagem

intuitiva.

Principais características de uma “boa elicitação de requisitos”:

• Definir as técnicas de coleta de requisitos baseadas em fatores operacionais, táticos e

financeiros;

• Criar um planejamento com objetivo de alcançar as metas estabelecidas, tais como:

Prazos, Custos e Qualidade;

• Promover a integração e o comprometimento de todos os envolvidos no processo, por

exemplo: Clientes, Fornecedores, Usuários e o Patrocinador.

• Identificar os documentos e procedimentos que definem as políticas de negócios da

empresa.


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Uma Simples Comparação:

Elicitação RuimElicitação Boa

Diagnóstico ineficiente Bom Diagnóstico

Soluções medíocres Soluções eficientes

Insatisfação dos usuários Satisfação dos usuários

Problemas operacionais e financeiros Melhoria dos processos e redução de custo



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Documento (Artefato) desta etapa: “Documento de Visão”

Objetivo:

Descrever

a visão inicial

do software

Documento

de visão

Participantes:

Analistas e

Especialista

em Negócios

identificação/

elicitação de

Requisitos

Entrevistas

Documentos

e sistemasReuniões e

Workshops

Observação

de campo

Participantes:

Usuário,

Clientes,

Fornecedores e

Patrocinadores



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


As fases da Identificação/Elicitação de Requisitos:

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

Planejamento

Elicitação de

Requisitos

Documentação

Documento de Visão

Identificar FontesTécnicas

Como deve ser feito ?

O que devo coletar ?

Como devo documentar ?

Identificar Funcionalidades

Identificar Restrições e Riscos



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


As informações podem ser identificadas ou encontradas em diversas fontes:- Usuários;

- Documentos;

- Especificações técnicas;

- Clientes;

- Sistemas legados

- Patrocinadores;

- Analista de Negócio

- “Domain Experts” - Especialista em uma ou mais área de negócio



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Quais são as técnicas ?

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

próprios conceitos, vantagens e desvantagens,

que podem ser usada nesta atividade entre elas

estão:

- Reuniões formais;

- Reuniões informais;

- Entrevistas;

- Questionários;

- Workshop;

- Brainstorming;

- JAD (Join Application Development)

- Fast;

- Análise de Documentos;

- Manual de Sistemas Legados.



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Quais as informações que devo identificar, levantar e

coletar ?

Após a atividade de Identificação/Elicitação de Requisitos,

através de alguma técnica formal ou informal, as seguintes

informações que devemos obter são:

Entendimento do problema, identificação da

lista dos principais usuários, lista dos principais Requisitos,

identificação dos Riscos e as Restrições do software.

Daí podemos organizar as informações da seguinte maneira:

- Contexto (Declaração do problema e Diagrama de

Contexto);

- Identificação dos usuários e entidades externas;

- Identificação dos Requisitos;

- Identificação dos Riscos e

- Identificação das Restrições.



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


- Contexto:Após o entendimento do problema podemos escrever a

Declaração do Problema e também desenhar um diagrama de

contexto.

- Declaração do problema:É uma “descrição narrativa”, que apresenta de forma concisa e

clara às necessidades dos usuários.

Esta narrativa também deve descrever o cenário atual e as

necessidades futuras.

A linguagem usada neste documento pode ser técnica ou de

negócios, entretanto, evite o usar jargões que não se

enquadram no escopo do problema.

- Diagrama de Contexto:Estabelece quais são as fronteiras do software e principais

funcionalidades, ou seja, onde as responsabilidades do

software começam e quando acabam.



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


- Identificação dos “Stakeholders”

Que é “stakeholders” ?

Stakeholders podem ser pessoas ou entidades que influenciam

a construção do software.

Exemplo:

- Usuários, porque definem os requisitos

- Gerentes, Diretores, Patrocinadores porque influenciam

através de tomada de decisão.



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


- Identificação dos Requisitos:Identificar as funcionalidades do software que deve ter para atender as

necessidades do usuário.

Para identificar você pode fazer as seguintes perguntas:

- O que o software deve fazer ?

- Quais funcionalidades ele deve ter ?

Devemos identificar também as principais características do software

como:

- Performance:

Qual é tempo de resposta adequado ?

- Segurança:

Quais são os requisitos de segurança que o software precisa?

- Usabilidade:

O software deve seguir a identidade visual da empresa,as interfaces

devem ser intuitivas e amigáveis

Os requisitos encontrados não devem ser descritos neste momento,

precisamos apenas identificá-los, ou seja, é uma informação de alto

nível.



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


- Identificação dos Requisitos: Tipos de RequisitosOs requisitos podem ser divididos em duas categorias:


Requisitos

Requisitos

Funcionais

Requisitos

Não-Funcionais

Declaram as

características que o

sistema deve possuir e

que estão relacionadas

às suas

funcionalidades.

Definem as

funcionalidades do

sistema. O que sistema

deve fazer.



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Exemplo:

- Cadastrar Clientes;

- Fazer Análise de Crédito;

- Fazer uma Transação com Banco de Dados;

- Cadastrar um Registro de Atendimento;

- Imprimir Relatório

- etc.

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

necessárias para atender os objetivos do sistema.

- Identificação dos Requisitos: Tipos de RequisitosRequisitos Funcionais:



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Os requisitos não funcionais dizem respeito as características do software, exemplos:

performance, portabilidade, segurança, usabilidade e etc. Estas características descrevem

também a qualidade do serviço (QoS).

A não consideração ou esquecimento desses fatores na “Workflow de Requisitos” constitui

uma das principais razões de uma eventual insatisfação dos usuários com relação a um

software.

Os requisitos não funcionais também são chamamos de “RNF” ou “Requisito

Suplementares.”

Exemplos de RNF:

- Confidencialidade;

- Confiabilidade;

- Performance;

- Qualidade;

- Usabilidade;

- Portabilidade;

- Precisão;

- Integridade;

- Segurança

- etc.

- Identificação dos Requisitos: Tipos de RequisitosRequisitos Não Funcionais:



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


- Identificação dos Requisitos:Os requisitos de software podem ser identificados no texto da “declaração do

problema” (geralmente são verbos que identificam algumas ações).

Este documento possibilita a identificação, extração e

classificação dos requisitos

- Requisitos funcionais e

- Requisitos não funcionais.

Texto da Declaração do Problema



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Exemplo:

Declaração do Problema

Exemplo: Acompanhamento das estatísticas de aprendizado do aluno e da turma (professor)

Informação: Relatório de aproveitamento do aluno e da turma (s)

Requisitos Funcionais:

O sistema deve registrar as principais ações de cada usuário.

O sistema deve fornecer um relatório do aproveitamento do aluno.

O relatório de aproveitamento do aluno deve conter o tempo de uso do software,

o número de exercícios feitos, o número de acertos e o de erros.

O sistema deve fornecer um relatório do aproveitamento da turma.

O relatório de aproveitamento da turma deve conter a média e o desvio-padrão

dos seguintes dados: tempo de uso do software, número de exercícios feitos,

número de acertos e erros de cada exercício.

Requisitos Não-Funcionais:

O sistema deve usar gráficos comparativos do aproveitamento do aluno com a média

da turma

O sistema deve usar cores na construção dos gráficos

O tempo de resposta na elaboração do relatório não pode ser superior a 15 segundos.



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


- Identificação de Riscos:Os riscos são a principal razão de falha em um projeto de software.

Para um projeto ter sucesso é importante a identificação dos riscos o

mais cedo o possível. Assim poderemos criar um plano para reduzi-los.

No Documento de Visão precisamos apenas identificar e criar uma

Lista de Riscos encontrados.

Os eventos de riscos podem ter várias origens como:

- Política:

O software pode sofre a influência de Política de Negócios da

Empresa ou Leis, Decretos, Normas e Regulamentos que regulam a

sociedade.

Problemas financeiros

Exemplos de Sistemas que tem restrições legais:

- SPB (Sistema Brasileiro de Pagamentos) - Banco Central

- Sistema de Faturamento e Contábil (Secretária da Fazenda

Municipal, Estaduais e Federais)

- Sistema de Folha de Pagamento (Ministério do Trabalho e

Previdência Social)

- Sistema de Conta Corrente (Banco Central - CPMF)



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


- Identificação de Riscos:

- Tecnologia:

Uso de tecnologias emergentes; Integração com legado

- Recursos:

Orçamento estreito; Contratação de Terceiros

- Habilidade:

Falta de domínio da tecnologia (conhecimento e experiência)

- Requisitos:

Requisitos não são plenamente conhecidos



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


- Identificação das Restrições:

Definem o conjunto de restrições impostas sobre o

desenvolvimento do software.

Restrições definem, por exemplo, a adequação a custos e

prazos, a plataforma tecnológica, aspectos legais

(licenciamento), limitações sobre a interface com usuário,

componentes de hardware e software a serem adquiridos etc.

Nesta momento apenas identificamos as restrições e criamos

uma Lista das Restrições, esta lista podem ser divida em

partes como:

Restrições de Hardware, Restrições de Software e Restrições

de Ambiente e Tecnologia.

Exemplo de Restrição:

Quando o projeto requer uma determinada tecnologia, tal

como WebServices.

Ou quando o software necessita de algum hardware ou

software em especifico. Tal como um servidor exclusivo para

banco de dados.



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Documento de Visão:

Objetivo:

Fazer uma descrição da visão do software

Este documento tem as as seguintes seções:

- Declaração do Problema;

- Lista dos Stakeholders

- Lista dos Requisitos

- Lista de Riscos

- Lista das Restrições



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


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

Índice:

1.0 - Introdução

1.1 Objetivo do documento

1.2 Escopo

1.3 Abreviaturas, Siglas e etc.

2.0 Contexto

2.1 Declaração do Problema

3.0 Lista de Stakeholders

3.1 Stakeholders primários

3.2 Stakeholders segundários

4.0 Lista dos Requisitos

4.1 Requisitos funcionais

4.2 Requisitos não funcionais

5.0 Lista dos Riscos

6.0 Lista das Restrições

6.1 Software

6.2 Hardware

6.3 Ambiente e Tecnologia

Documento de Visão:


Exemplo de Simples Documento de Visão:


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Análise de Requisitos


É apresentar e discutir as atividades da análise de

requisitos de software


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Documento de Visão


de requisitos




Documento de

Requisitos

Documento de

Especificação

de Requisitos

Usuários e

Clientes


Regras de

negócio





An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


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

Essa sistematização é necessária porque a complexidade dos sistemas exige que se

preste mais atenção ao correto entendimento do problema antes do comprometimento de

uma solução. Uma definição para requisitos é apresentada a seguir.

“Requisitos: Condição necessária para a obtenção de certo objetivo, ou

para o preenchimento de certo objetivo.“

O Documento de Visão é um artefato importante na Análise de Requisitos, destacamos

algumas razões:

- Da perspectiva da engenharia de software, a elicitação de requisitos é talvez a mais parte

mais critica do processo de desenvolvimento de software.

Estudos indicam que os requisitos, só detectados depois do software implementado ou

erros na análise de requisitos, são até 20 vezes mais caros de se corrigir que qualquer

outro tipo de erro.

Análise de Requisitos: Introdução



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


A Análise de Requisitos deve ser:

Correta: Quando cada requisito expresso nela for encontrado no software;

Não Ambígua: Cada requisito deve ter somente uma interpretação;

Completa: Quando incluir todos os requisitos significativos relacionados as

funcionalidades e requisitos relacionados a qualidade do serviço (também

conhecidos como requisitos não funcionais)

Consistente: Quando não existir conflito entre os requisitos;

Verificável: Quando for possível verificar/validar cada requisito;

Modificável: Quando os requisitos podem ser facilmente alterados.




An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Atividades da Análise de Requisitos

A análise de requisitos possibilita que o Analista de Sistemas especifique as

funcionalidades, classificando e detalhando os requisitos encontrados na coleta.

Os requisitos funcionais serão descritos em detalhes. E os requisitos não funcionais serão

classificados.


Detalhar os

Requisitos Funcionais

Descrever os Usuários

e Entidades Externas

Documento de Requisitos

Classificar os

Requisitos não Funcionais

Fazer Plano de Redução

de Risco



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Requisitos Funcionais:

Os requisitos funcionais devem ser detalhados. Devemos usar um formato padrão para

esta atividade. Veja o exemplo:

Análise de Requisitos. Detalhar

Lista de Requisitos funcionais

Nome Descrição

Fazer ReservaEsta funcionalidade deverá permitir o usuário (funcionário)

a fazer reserva de apartamentos, as ações que estarão

disponíveis são: criar, remover, alterar e consultar reservas.

Cada reserva deverá ter um cliente e um apartamento e

respectiva período)

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

RF01E

Código



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


id Nome da Regra

Nome do Projeto Serviço de Atendimento e Reserva de Apartamento

ObjetivoDescrever todas as regras de negócio para para o serviço de atendimento e reserva de apartamentos.

Data

01/01/08 RFS 2.1

Nome / Equipe Versão

RN01

Descrição de Regras de Negócio

Descrição da Regra de Negócio

Registrar Reserva de

Apartamento

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

25% do valor da estadia.

Os clientes AA (pessoas que hospedaram no hotel mais de 10 dias por ano) tem

preferência de data e tipo de apartamento.

No período de baixa a estação (de mar a jun e ago a nov) o valor da diária tem um

desconto de 40%.

Para que agilizar o atendimento manter a satisfação do cliente as consultas de reserva devem

ser feitas em no máximo 30 segundos.

Vigente

Status

Nome Descrição

Registrar Reserva

de Apartamento

Esta funcionalidade deverá permitir o usuário (funcionário) a fazer reserva de apartamentos,

as ações que estarão disponíveis são: criar, cancelar, alterar e consultar reservas.

Requisitos Funcional

ID

RFC01


Nome: Reserva Descrição: Serviço de Atendimento e Reserva de ApartamentoRN: RN01

Os códigos permitem a rastreabilidade



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Requisitos Não Funcionais:

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

categorizar estes requisitos, as mais frequente são:

Análise de Requisitos. Classificar

- Performance:

Tempo de resposta

- Segurança:

Uso de senhas, certificados digitais e etc..

- Usabilidade:

Identidade Visual e Interfaces amigáveis

- Disponibilidade:

O software deve estar disponível para usuário 24x7. Exemplo: Tolerância a falha

- Flexibilidade:

Capacidade de adaptação quando um requisito muda

- Portabilidade:

Capacidade de se adaptar a outros ambientes (sistemas operacionais)

- Escalabilidade:

Capacidade de responder aumento de carga (novos usuários)

Outras categorias como Integração, Processamento, Manutenível e etc.



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re



Bem vamos descrever os requisitos não funcionais. Como na descrição dos Requisitos

funcionais, precisamos ter um padrão

Análise de Requisitos. Classificar e Detalhar

Lista de Requisitos Não funcionais

Descrição

Fazer

Consulta

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

exceder ao tempo de resposta de 15 segundos


Categoria: Performance

Req. Funcional Código

RNFP1

Por que preciso de um código ?

Este código tem como objetivo facilitar a “rastreabilidade”.

Ele pode ser usado no Formulário de Caso de Uso, por exemplo, desta

forma conseguiremos identificar qual é o caso de uso que realiza este

RNF, no caso de mudanças.



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re



Continuação:

Lista de Requisitos Não funcionais

Categoria: Usabilidade

RF /

AplicaçãoDescrição

AplicaçãoAs cores, as fontes e logotipos devem seguir o Manual de

Identidade Visual da empresa.


AplicaçãoAs interfaces com usuário devem seguir padrão de interfaces

estabelecido pelo Manual de Sistema

Código

RNFU1

RNFU2

Análise de Requisitos. Classificar e Detalhar



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Lista de Stakeholders:

Precisamos descrever todos as pessoas e/ou organização que influenciam a tomada de

decisão ou participam direta ou indiretamente do processo de construção do software.

Mais uma vez criaremos um formato padrão. Veja o exemplo:

Lista de Stakeholders

Nome Descrição

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


ColaboradorÉ qualquer pessoa que presta algum tipo serviço para

empresa




An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Continuação:

Lista dos Stakeholders

Nome Descrição

Administradora de

Cartão de Crédito

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

em transação de pagamento.



Lista de Stakeholders:



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Plano de Mitigação de Riscos:

Análise de Requisitos. Elaborar:

Precisamos elaborar um Plano de Mitigação de Risco, para os risco que já foram

identificados. Este plano deve detalhar como mitigar os riscos identificados.


Exemplo:

Foi identificado o Risco de Habilidade, pois, somente uma pessoa da equipe conhece a

Web 2.0, as outras pessoas nunca trabalharam com esta técnologia.

Para mitigar este risco toda equipe deverá receber treinamento de Web 2.0, antes do

começo do projeto.


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Documento de Requisitos:

Objetivo:

Classificar, descrever os requisitos de software,

usuários e entidade externas e elaboração do

plano de redução de risco

Este documento tem as seguintes seções:

- Requisitos Funcionais

- Requisitos Não Funcionais

- Descrição do Usuários e Entidades Externas

- Plano de Redução de Risco

Análise de Requisitos. Artefato



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


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


Análise de Requisitos. Artefato.Template



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Mitos e Lendas:

O que é dito:

- Usuários não entendem do negócio...

- Requisitos são estáticos...

- Achar que tem a solução, mesmo antes de conhecer todo o problema...

Entretanto, a realidade é outra...

- Requisitos não são estáticos, eles mudam constantemente...

- Fazer amplas discussões que envolvam o maior

número de pessoas que conheçam o negócio, antes de

apresentar uma a solução



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Especificação de Requisitos

com Caso de Uso


É apresentar as principais técnicas para especificação

de requisitos de software.


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Documento de Visão


de requisitos




Documento de

Requisitos

Documento de

Especificação

de Requisitos

Usuários e

Clientes


Regras de

negócio

Especificação de Requisitos com Caso de Uso





An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Casos de Uso

Seqüência Colaboração

Classes

DistribuiçãoImplementação

Estrutura

Comportamento interno

Comportamento externo

Especificação de Requisitos

Requisitos

FuncionaisDocumento

de Visão

Requisitos Não

Funcionais

Arquitetura

do Software

Restrições

de Projeto

Documento de

Requisitos



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Objetivos:

• Identificar os atores;

• Identificar os casos de uso;

• Desenhar os casos de uso e

• Escrever cenários.

Análise de Casos de Uso:

•Casos de uso expressam o diálogo entre os usuários e o sistema

•Casos de uso expressam “o quê” o sistema deverá fazer. E não “como” fazer.

•Casos de uso formam a base para testes e documentação do sistema

•O modelo de casos de uso expressam todos os casos de uso do sistema e os seus

relacionamentos.

•As técnicas para criar e expressar casos de uso em uma aplicação Web são as

mesmas para construir outros sistemas de software.


O produto que devemos ter após Análise de Requisitos é a “A especificação de

Requisitos” é feita através de Casos de Uso, conforme definido pela UML. Um

conjunto de casos de uso é importante para se compreender o que o usuário

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

pelo sistema, ou seja, um serviço.


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


59

Cliente

Emitir NF

Fazer Pedido

Fazer Cadastro

Calcular Total

Funcionário

Transformar os Requisitos

Funcionais em Casos de Uso:



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Atividades e Passos:

Fazer Diagrama de

Casos de Uso

Escrever cenários Ferramenta de

Modelagem UML

Identificar Atores /

Casos de Uso

Refinar Diagrama de

Casos de Uso

Escrever Formulário

Fazer Diagrama de

Caso de Uso



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Introdução:

Caso de Uso é uma representação gráfica e semântica da interação do usuário e o sistema.

Os diagramas de caso de uso são usados para capturar os requisitos funcionais do sistema. Ajuda o entendimento do contexto dos requerimentos do sistema.

Os casos de uso podem ser agrupados em pacotes, desta forma temos uma organização funcional.



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


O que são Caso de Uso?São diagramas de que permitem visualizar, especificar e documentar o comportamento de um elemento. Esses diagramas fazem com que sistema, subsistemas e classes fiquem acessíveis e compreensíveis, por apresentarem uma visão externa sobre como esses elementos interagem com sistema.

Definição:Caso de Uso é uma descrição de um conjunto de seqüências de ações, inclusive variantes, que um sistema pode produzir um resultado de valor observável por um ator. A representação gráfica é uma elipse.

Gerenciar

Reserva

Ator

Caso de Uso

Nome

Usuário

Os nomes de casos de uso

são breves expressões verbais

ativas.



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Casos de Uso e Cenários:

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

podemos ter vários caminhos para completar esta função.

Um cenários é como uma “instance” do Caso de uso, isto é, um caminho lógico com

início e fim.

Principais características:

- Cenários não contém declarações condicionais;

- Pode ter mesmo começo, mas, com final diferente;

- Um cenário é narrativa de uma situação e

- Os cenários devem descrever os bons caminhos e maus também.



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Este é um dos cenário que pode acontecer. Se houver algum problema, com a

autorização da transação do cartão de crédito teremos um novo cenário.


Exemplos:

Em dada Loja virtual, podemos o seguinte cenário de Compra de um produto:

“O cliente navega no catálogo de itens e adiciona os itens desejado à sua cesta de

compra. Quando o cliente deseja pagar, fornece os dados do cartão de crédito e

confirma a compra. O sistema solicita o endereço de entrega para o pedido.

O sistema verifica a autorização do cartão de crédito e confirma a transação

imediatamente enviando um e-mail para o usuário.”



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Autorização de acesso.

O usuário executa a aplicação, o sistema exibe a janela de identificação que pede a

identificação do usuário, ou seja, seu nome e sua senha, O usuário informa seu

nome e sua senha, o sistema valida as informações e dá a autorização de acesso ao

sistema.


Exemplos:

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



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Casos de Uso e Fluxo de Eventos:

Uso caso de uso descreve “o quê” um sistema (ou subsistema, classe, ou interface) faz,

ele não especifica “como” isso é feito. Ao fazer uma modelagem, importante manter

clara a separação de questões entre a visão interna e externa.

Podemos especificar o comportamento de um caso de uso pela descrição do fluxo de

eventos no texto de maneira suficientemente clara para que qualquer pessoa possa

entende-lo facilmente. Ao escrevermos o fluxo de eventos devemos incluir como

e quando o caso de uso inicia e termina, como e quando o caso de uso interage com os

atores e o fluxo básico e fluxo alternativo do comportamento.

Tipos de fluxos:

• Fluxo de eventos principal e

• Fluxo alternativo de eventos.



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Casos de Uso e Fluxo de Eventos:

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

ajudam a compreensão dos requisitos do sistema, entretanto, você desejará utilizar

os diagramas de interação para especificar esses fluxos graficamente. Além disso, você

também utilizará um diagrama de seqüência para especificar o fluxo principal de um

caso de uso e variação deste diagrama para especificar os fluxos excepcionais.

Cenário 1

Fluxo

alternativo 1

Fluxo

alternativo 2

Fluxo

alternativo 3

Fluxo Normal



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Casos de Uso e Formulário:

Os formulários devem ter as seguinte informações:

- Ponto de ativação (momento que caso de uso começa)

- Nome do caso de uso

- Objetivo

- Atores que participam do caso de uso

- Pré-condição

- Fluxo Normal

- Fluxo Alternativo

- Pós-condição.

Opcionalmente podemos acrescentar outros itens ao Formulário de Caso Uso.

Exemplos:

- Nome ou código dos Requisitos (RN e RNF) que estão associados a este caso de uso



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


69

Exemplo Formulário de Descrição de Caso Uso:

Nome: Fazer Busca Produto

Ponto de ativação: Este caso de uso começa quando entra na página

de Busca e seleciona um item da caixa de seleção

Ator: Visitante e Cliente

Objetivo: Fazer busca de produto por categoria

Pré-condição: Aplicação Disponível

Fluxo Normal:

1 - O visitante seleciona a página de busca

2 - O visitante seleciona a categoria para busca

3 - O visitante informar o produto

4 - O visitante pressiona o botão buscar

5 - O sistema processa a busca

6 - Retorna as informações sobre o produto

Fluxo Alternativo:

1 - O Visitante seleciona a página de busca

2 - O visitante seleciona a categoria para busca

3 - O visitante informar o produto

4 - O visitante pressiona o botão buscar

5 - O sistema processa a busca

6 - Retorna as uma mensagem “produto não encontrado”

Pós-condição: Busca realizada

Requisito Funcional: RF002 -Fazer Busca do Produto

Requisito Não Funcional: ---



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Organização dos Casos de Uso:

Os casos de uso também podem ser organizados pela especificação de relacionamento de

generalização, inclusão e extensão, existentes entre eles. Esses podem ser aplicados com

a finalidade de fatorar o comportamento comum (obtendo esse comportamento a partir de

outros casos de uso que ele inclui) e fatorar variantes (obtendo esse comportamento em

outros casos de uso que o estendem)



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Exemplos de Casos de Uso:

Professor

Selecionar curso

para ensinar

Pedir lista dos

matriculados

Gerente de

Educção

Manter informação de

aluno

Manter informação de

professor

Gerar catalogo

Manter informações dos

cursos

Sistema de

cobrançaMatrícula nos

Cursos

Aluno



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Elementos dos Caso de Uso:

Ator:Um ator representa um conjunto coerente de papéis que os usuários de casos de uso desempenham quanto interagem com esses casos de uso. Geralmente um ator representa um papel, que pode ser de pessoa, de um sistema ou de um dispositivo e etc...

Cenários:É narrativa de determinado fato ou de uma situação.“O caso de uso deve ser descrito através de cenários. Devem ser construídos tantos cenários quantos forem necessários para se entender completamente todo o sistema. Podem ser considerados como teste informais para validação dos requisitos do sistema.”

Formulário:É a representação estruturada de um ou mais cenários



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Generalização:

Entre os casos de uso é parecida à generalização existente entre as classes.

No caso de uso a generalização significa que o caso de uso filho herda o

comportamento e o significado do caso de uso pai; o filho poderá acrescentar ou

sobrescrever o comportamento de seu pai; poderá ser substituído em qualquer local

qual o pai apareça.

Include:

Quando você estiver se repetindo em dois ou mais caso de uso separados

devemos evitar a repetição

Extends:

Quando estivermos descrevendo uma variação em comportamento normal,

entretanto, querendo fazer uma descrição mais controlada, explicando os pontos de

extensão no caso de uso.

Realizes:

Especifica a colaboração entre os casos de uso

* Use (obsoleto): Especifica que a semântica do elemento de origem depende da

semântica da parte pública do destino. Substituído pelo include.



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Generalização:

Podemos usar a generalização entre casos de uso, pelo mesmo motivo que utilizamos

nas classes, para compartilhar comportamento:

Pagto Cartão de Crédito

Receber Pagamento

generalização

Pagto Cartão de Débito



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Generalização:

A generalização também pode ser aplicado aos atores e seus respectivos papéis. Veja

o exemplo:

Funcionário

RecepcionistaGerente de

Reservas



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Extends:

Podemos usa-lo para “Demonstrar Variação de Comportamento”:

Cada uma das extensões descreve as diferentes maneiras com que um passo do

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

Alterar status do carro Consulta Cliente

<<include>>

Devolver Veículo

Calcular Multa

<<extend>><<include>>

Locadora de Automóveis



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Fazer Pedido

<<include>>

Acompanhar Pedido

Validar Usuário<<include>>

Explicando o estereotipo “include”

Um relacionamento de inclusão entre casos de uso significa que o caso de uso base incorpora

explicitamente o comportamento de outro caso de uso em uma localização especificada na base.

O caso de uso incluído nunca permanece isolado, mas é apenas uma “instance” como parte de

alguma base maior que o inclui. Você pode pensar na inclusão como o caso de uso base que o

obtém o comportamento a partir do fornecedor do caso de uso. Você utiliza um relacionamento

de inclusão para evitar descrever o mesmo fluxo de eventos várias vezes, incluindo o

comportamento comum em um caso de uso próprio. O relacionamento de inclusão é

essencialmente um exemplo de delegação, você coleta um conjunto de responsabilidades do

sistema e o captura um único local (o caso de uso incluído); depois, permite que outras partes do

sistema (outros casos de uso) incluam a nova agregação de responsabilidade sempre que

precisamos utilizar essa funcionalidade.



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Fazer Check IN

<<include>>

Gerenciar Reserva

Include. (Mais) exemplos:

Fazer Check OUT

<<include>>

Receber Pagamento



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Casos de Uso - Identificação de Atores

Os atores não fazem parte do sistema - eles representam qualquer um e qualquer coisa

que faça interação com sistema. Podendo ser uma pessoa, software, hardware e etc.

Uma ator pode:

- Apenas fornecer informações ao sistema

- Apenas receber informações do sistema

- Fornecer e receber informações ao sistema

Tipicamente os atores são identificados nas Declarações de Problemas (Documento

de Visão) ou através de entrevistas com os usuários e outros envolvidos no processo,

como, Gerente, Especialista em Negócio, Analista de Sistema e Analista de Negócio,

por exemplo.

As seguintes questões podem ser usadas para identificar o atores:

- Onde o sistema será usado ?

- Quais áreas serão usuárias do sistema ?

- O sistema usará recurso externo ?

- Quem será o responsável pelo sistema ?

- Quem serão os usuários do sistema ?



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Um engano comum na identificação de casos de uso é representar como Caso de uso

passos individuais, operações ou transações.

Exemplo:

No domínio de ponto de venda, alguém pode definir um caso de uso chamado

“Imprimindo o Recibo”, quando de fato, a operação de impressão é meramente um passo

no processo muito mais abrangente do caso de uso Comprar Itens

Lembre-se:

Um caso de uso é uma descrição completa de processo, que inclui outros passos

ou transações.



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Documento de

Visão

O hotel contém um número de apartamentos disponíveis para ser alugado aos hospedes. Cada apartamento tem as

seguintes propriedades:

- Número, preços base, capacidade de pessoas

- Tipo (Single, double, triplo ou suite)

O preço de cada apartamento está relacionado com seu tipo e sazonalidades (períodos especiais, tais como: férias, natal,

carnaval...)

Um hospede pode fazer reserva de mais de um apartamentos através do telefone, Internet ou pessoalmente no balcão de

reserva do Hotel .

Refinado pelo

Requisitos Funcionais

• Gerenciar Reserva

•...

12

„

Documento

de Requisitos


Estudo de Caso:


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Especificação de Requisitos:

Cenários

Gerenciar ReservaUsuário

Formulário

Caso de Uso

AssociaçãoAtor

3

Caso de Uso: Gerenciar Reserva


Estudo de Caso:


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Escrevendo os Cenários:

Cenários

Gerenciamento de Reserva:

O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva

de apartamentos para data.

O cliente informa o período, ou seja, data de chegado e partida, e qual tipo de apartamento

ele precisa.

O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e informa

que não tem disponibilidade de apartamento para o período informado pelo cliente e

oferece um outro tipo de apartamento.

O cliente aceita o apartamento e então o funcionário confirma a reserva.





ele precisa.

O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e confirma a

reserva.


Estudo de Caso:


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Escrevendo os Cenários:

Cenários





ele precisa.

O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e informa

que não tem disponibilidade de apartamento para o período informado pelo cliente e

oferece um outro tipo de apartamento.

O cliente não aceita a proposta do funcionário e a reserva não é confirmada.


Estudo de Caso:


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Escrevendo o Formulário:

Compilar os Cenários em Formulário:

Cenário





ele precisa.

O funcionário do Setor de Reserva, verifica a disponibilidade do apartamento e confirma a

reserva.

Pré- condição

Pós- condição

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

Cenários Formulário


Estudo de Caso:


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


86


Compilar os Cenários em Formulário:

Nome: Gerenciar Reserva

Ponto de ativação: Este caso de uso começa quando o

funcionário do setor de reserva recebe uma solicitação de

reserva

Ator: Funcionário

Objetivo: Fazer reservar de apartamentos

Pré-condição: Solicitação de reserva

Fluxo Normal:

Fluxo Alternativo:

Pós-condição: Reserva confirmada

Primeiras linhas do cenário

Última linha do cenário

Gerenciar Reserva

“caminho feliz”

Gerenciar Reserva

“caminho alternativo”


Estudo de Caso:


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re



Formulário:Nome: Gerenciar Reserva

Ponto de ativação: Este caso de uso começa quando o funcionário do setor de

reserva recebe uma solicitação de reserva

Ator: Funcionário

Objetivo: Fazer reservar de apartamentos

Pré-condição: Solicitação de reserva

Fluxo Normal:

O cliente informa o tipo de apartamento

O cliente o período (data de chegada e partida)

O funcionário do Hotel verifica a disponibilidade do apartamento

O funcionário confirma a reserva

Fluxo Alternativo:

...

O funcionário do Hotel verifica a disponibilidade do apartamento

O funcionário faz proposta de outro apartamento para cliente

O cliente aceita e então o funcionário confirma a reserva

Pós-condição: Reserva confirmada


Estudo de Caso:


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Especificação de Requisitos:

Cenários

Formulário

Gerenciar ReservaFuncionário

Caso de Uso

AssociaçãoAtor

3

Caso de Uso: Gerenciar Reserva


Estudo de Caso:


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Ferramenta: Enterprise Architect (EA)



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Mitos e Lendas• Requisitos não são Casos de Uso;

• Um Caso de Uso pode relacionar mais de um requisito, veja o exemplo:

Caso de Uso Fazer Busca, está associado a dois requisitos:

• (RF) Fazer Buscar

• (RNF) O tempo de resposta para transação deve ser 10 segundos

(Desempenho)



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


91

Atividades e Passos:

Fazer Diagrama de

Casos de Uso

Escrever cenários Rational Rose


Casos de Uso

Refinar Diagrama de

Casos de Uso


Fazer Diagrama de

Caso de Uso



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Especificação de Requisitos, como fazer:

1 - Identifique quais os REQUISITOS e relacione com os CASOS DE USO;

2 - Identifique também os ATORES e seus respectivos PAPÉIS;

3 - Dê um nome para o CASO DE USO, lembre-se que este nome deve ser

único no modelo;

4 - Escreva os CENÁRIOS para o CASO DE USO;

5 - Compile os CENÁRIOS em único FORMULÁRIO e

6 - Faça o Diagrama de Caso de Uso (Use “Rational Rose” para fazer isto).

Vamos fazer os Caso de Uso (iniciais)



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Modelo do “Formulário de Descrição de Requisitos”:

Nome: <nome do caso de uso>

Ponto de ativação: <informar o ponto de ativação>

Ator: <informar os atores>

Objetivo: <descrever o objetivo>

Pré-condição: <descrever a pré-condição>

Fluxo Normal:

<descrever o fluxo normal>

Fluxo Alternativo:

<descrever o fluxo alternativo>

Pós-condição: <descrever a pós-condição>

RF: <informar os código ou nomes dos RFs>

RNF: <informar os código ou nomes dos RNFs>

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



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Refinar: Atividades e Passos

Fazer Diagrama de

Casos de Uso

Escrever cenários Rational Rose


Casos de Uso

Refinar Diagrama de

Casos de Uso


Fazer Diagrama de

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


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Exemplo 2 – Adicionando o <<include>>

Gerenciar

Reserva

Funcionário

Funcionário

Sem include: Com include:

Cadastrar Cliente

Buscar Apartamento

<<include>>

<<include>>


Gerenciar

Reserva


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Fazer Check INRecepcionista

Fazer Check INRecepcionista

Consultar

Cliente

Consultar

Reserva

<<extend>>

<<include>>


Exemplo 1 – Adicionando o <<include>> e <<extend>>

<<include>>

Cancelar

Check IN


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Fazer Check OUTRecepcionista

Fazer Check

OUTRecepcionista

Consultar

Cliente

Consultar

Reserva

<<include>>

<<include>>

Receber

Pagamento

<<include>>


Exemplo 3 – Adicionando o <<include>>

Sem include: Com include:


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Validação de Requisitos


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

requisitos de software.


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Documento de Visão


de requisitos




Documento de

Requisitos

Documento de

Especificação

de Requisitos

Usuários e

Clientes


Regras de

negócio







An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Deve preocupa-se em mostrar que os requisitos definem o sistema que o cliente/usuário

deseja.

Validação é importante uma vez que o custo para remover um erro de requisitos é

grande.

Pequeno Check List de Requisitos:

Validade. O sistema fornece as funções que melhor atende as necessidades do

usuário?

Consistência. Existem conflitos de requisitos?

Completeza. Todas as funções necessárias para o cliente estão incluídas?

Realismo. Os requisitos podem ser implementados com a tecnologia e orçamento

disponíveis?

Facilidade de verificação. Os requisitos podem ser checados?



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Revisão de requisitos:

- Revisões regulares devem ocorrer durante a formulação da definição dos requisitos

- Tanto o cliente quanto a equipe contratada devem estar envolvidos nas revisões

- As revisões podem ser formais (com documentos completos) ou informais. Uma boa

comunicação entre os desenvolvedores, clientes e usuários pode resolver problemas em

estágios iniciais

Verificação de revisões:

- “Verificabilidade”. O requisito é realisticamente testável?

- Compreensibilidade. O requisito é propriamente entendido?

- Rastreabilidade. A origem do requisito é claramente estabelecida?

- Adaptabilidade. O requisito pode ser modificado sem grande impacto sobre outros

requisitos?

Técnicas de validação de requisitos

Revisão de requisitos:

- Análise manual sistemática dos requisitos

Prototipação:

- Uso de um modelo executável do sistema para checar os requisitos.

Geração de casos de teste:

- Desenvolver testes para validar a implementação dos requisitos.

Análise automatizada da consistência:

- Uso de ferramenta para verificar a consistência do modelo.



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Definição: Caso de Teste

- Casos de Testes:

Especifica uma forma de fazer testes, incluindo o que testar (as entradas e/ou as saídas) ,

como testar e as condições de testes.

Em engenharia de software, Caso de Teste é um conjunto de condições usadas para

teste de software. Ele pode ser elaborado para identificar defeitos na estrutura interna

do software, através de situações que exercitem adequadamente todas as estruturas

utilizadas na codificação; ou ainda, garantir que os requisitos do software que foi

construído sejam plenamente atendidos. Podemos utilizar os Casos de Uso para criar e

rastrear os Caso de Teste.

O Caso de Teste deve especificar a saída esperada e os resultados esperados do

processamento. Numa situação ideal, no desenvolvimento de casos de teste, se espera

encontrar o subconjunto dos casos de teste possíveis com a maior probabilidade de

encontrar a maioria dos erros.

Os Casos de Uso são a base para os Casos de Teste

Caso de Teste



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Definição: Modelo de Teste - Caso de Teste. Exemplo:

Fazer Login

Fluxo Normal

Entrada: nome e senha

Caso de Teste

25

NomeID Caso Teste

Validar o Caso de Uso: Fazer Login de Acesso

Descrição

24

ID Caso de Uso

Resultado Esperado Resultado Observado OK ?Cenário

Usuário autorizado

(Sucesso)Usuário autorizado (Sucesso) OK

Fluxo Alternativo 1

Entrada: nome e senha

Mensagem usuário

inválido (Insucesso)Usuário autorizado (Sucesso) NOK

Cenário 1

Fluxo

alternativo 1

Fluxo

alternativo 2

Fluxo

alternativo 3

Caso de Uso

Fluxo Normal

Nome do Testador: Data:

____/____/_____

Fazer Login

ClienteDescrição

do Caso de Uso

Caso de Teste



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Técnicas de validação de requisitos

Verificação de Consistência Automatizada:

Requisitos em

linguagem formal

Processador de

Requisitos

Base de Dados

de Requisitos

Relatório

Análise de

Requisitos



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Gerenciamento de Mudança

de Requisitos


É apresentar as principais técnicas para processo de

gerenciamento de mudança de requisitos de software.


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Gerenciamento de Mudança de Requisitos é o processo de controlar as mudanças nos

requisitos durante o processo de engenharia de requisitos e desenvolvimento.

Requisitos são inevitavelmente incompletos e inconsistentes:

• Novos requisitos surgem durante o processo de desenvolvimento.

• Diferentes pontos de vista possuem diferentes requisitos e esses são freqüentemente

contraditórios.

Mudanças nos requisitos:

- A prioridade dos requisitos podem mudar para atender novas demandas de negócio

- Requisitos podem sofrer alteração quando muda a regra de negócio;

- As pessoas que pagam pelo software/sistema podem especificar os requisitos de maneira

conflitantes com os requisitos das pessoas que irão utilizar o software/sistema.

- A empresa e o ambiente técnico do software/sistema se modificam durante o processo

de desenvolvimento

Gerenciamento de Mudança de Requisitos


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Evolução dos requisitos

Entendimento

inicial do problema

Requisitos

iniciais

Entendimento

do problema

(alterado)

Requisitos

modificados

tempo



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re



Requisitos permanentes e voláteis:

- Requisitos permanentes. Requisitos estáveis, derivados da atividade principal da

organização.

Exemplo: Em um hospital sempre haverá requisitos relativos aos pacientes, aos

médicos, às enfermeiras e aos tratamentos.

- Requisitos voláteis. Requisitos que se modificam durante o desenvolvimento ou

quando o software/sistema está em uso. Requisitos resultantes de políticas

governamentais ou resultantes de regra de negócio da empresa.

Exemplo: Plano de saúde; Mudança na política de venda

Classificação dos requisitos:

Requisitos Mutáveis:

- Requisitos que se modificam por causa do ambiente do sistema.

Requisitos Emergentes:

- Requisitos que surgem à medida que a compreensão do cliente do sistema se desenvolve

Requisitos Conseqüentes:

- Requisitos que resultam da introdução do sistema de computador.

Requisitos de compatibilidade:

- Requisitos que dependem de outros sistemas ou processos de negócio específicos dentro

da organização


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Planejamento do gerenciamento de requisitos:

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

A identificação dos requisitos:

Como os requisitos são individualmente identificados

Um processo de mudança de gerenciamento:

O processo seguinte à análise de uma mudança de requisito

Políticas de rastreabilidade:

A quantidade de informações (histórico) sobre o relacionamento entre requisitos que é

mantida.

Como rastrear as mudanças de requisitos e seus possíveis impactos.

Suporte à ferramenta:

O suporte à ferramenta necessário para auxiliar no Gerenciamento de Mudanças de

Requisitos



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Rastreabilidade:

- Rastreabilidade preocupa-se com as relações entre requisitos, suas fontes e o projeto do

software/sistema

Rastreabilidade de fonte:

• Links de requisitos para stakeholders que propuseram os requisitos

Rastreabilidade de requisitos:

• Links entre requisitos dependentes

Rastreabilidade do projeto:

• Links dos requisitos para o projeto



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Suporte à ferramenta:

Armazenamento dos requisitos:

- Os requisitos devem ser gerenciados em uma memória de dados segura e gerenciada

Mudança de gerenciamento:

- O processo de mudança de gerenciamento é um processo de fluxo de trabalho cujos

estágios podem ser definidos e o fluxo de informação entre esses estágios parcialmente

automatizado

Gerenciamento de rastreabilidade

- Recuperação automática dos links entre requisitos



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Gerenciamento de Mudanças de Requisitos:

Deve ser feita em qualquer proposta de mudança de requisito.

Principais estágios:

- Análise do problema e especificação da mudança. Discute-se os problemas com os

requisitos e propõe-se mudanças.

- Análise e custo da mudança. Avalia-se os efeitos da mudança em outros requisitos do

sistema.

- Implementação das mudanças. O documento de requisitos e outros documentos são

alterados de forma a refletir as mudanças.

Análise do Problema

e especificação da

mudança

Análise e custo

mudança

implementação

da mudança

Solicitação

de Mudança de

Requisito

Requisito

Alterado



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Exemplo: Matriz de Rastreabilidade (na ferramenta ReqPro):



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Exemplo: Matriz de Rastreabilidade (na ferramenta EA):



An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Conteúdo:Técnicas para identificação/elicitação de requisitos:

- JAD

- FAST

Documento de Requisitos

- Padrão IEEE/ANSI 830-1993:


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


JAD (Join Application Development)

A técnica JAD desenvolvida na IBM no fim dos anos 70 visa criar sessões de trabalho

estruturadas, através de uma dinâmica de grupo e recursos visuais, em que analistas e

usuários trabalham juntos para projetar um sistema, desde os requisitos básicos até o

layout de telas e relatórios, prevalecendo a cooperação e o entendimento

[PORTELLA1994]. Os desenvolvedores ajudam os usuários a formular os problemas e

explorar possíveis soluções, envolvendo-os e fazendo com que eles se sintam

participantes do desenvolvimento

JAD se baseia em quatro princípios básicos:

1. Dinâmica de grupo, com a utilização de sessões de grupo facilitadas para aumentar a

capacidade dos indivíduos;

2. Uso de técnicas audiovisuais para aumentar a comunicação e o entendimento;

3. Manutenção do processo organizado e racional; e

4. Utilização de documentação-padrão, que é preenchida e assinada por todos os

participantes de uma sessão.

A técnica JAD tem duas grandes etapas: planejamento, cujo objetivo é elicitar e

especificar requisitos; e projeto, em que se lida com o projeto do software. Nesta

monografia somente será tratada a primeira etapa. Os participantes de uma sessão de

JAD desempenham seis diferentes papéis: líder da sessão, representantes do usuário,

especialista, analista, representantes dos sistemas de informação e patrocinador

executivo.

Anexo


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


JAD (Join Application Development) continuação

A técnica pode ser usada tanto para elicitar como nas fases iniciais da especificação de

requisitos. Ela ajuda a identificar os assuntos que podem necessitar de rastreamento e

fornece uma perspectiva multifacetada dos requisitos. Sessões de JAD permitem aos

analistas coletar simultânea e eficientemente uma grande quantidade de requisitos do

sistema junto a uma gama de usuários-chave. São úteis por considerar necessidades

específicas dos usuários. JAD também pode ser usada em conjunto com outra técnica de

elicitação como, por exemplo, a prototipação. À medida que os requisitos são obtidos nas

sessões, pode-se construir um protótipo que demonstre alguma funcionalidade destes

requisitos.

Anexo


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


FAST (facilited application specification technique):

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

preliminar de requisitos.

Diretrizes básicas:

- Encontro de clientes e desenvolvedores em local neutro

- Estabelecer regras para preparação e participação;

- É sugerida uma agenda cobrindo todos os pontos importantes e que encoraja o livre

fluxo de idéias;

- “Facilitador”(cliente,desenvolvedor, ou elemento externo) para controlar o encontro.

Anexo


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re



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

1993:

Estrutura do Documento:

1.0 Introdução

1.1 propósito do documento de requisitos

1.2 escopo do produto

1.3 definições, acrônimos e abreviações

1.4 referências

1.5 visão geral do restante do documento

2.0 Descrição geral

2.1 perspectiva do produto

2.2 funções do produto

2.3 características do usuário

2.4 restrições gerais

2.5 suposições e dependências

3. Requisitos (Específicos)

os requisitos podem documentar interfaces externas, descrever funcionalidade e

desempenho do sistema, especificar requisitos lógicos de banco de dados,restrições de

projeto, características de qualidade.

4. Apêndices

5. índice

Anexo


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


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

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 ([email protected])

[email protected]

mailto:[email protected]


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Licença:


An

alis

e d

e R

eq

uis

ito

s d

e S

oft

wa

re


Análise de Requisitos de Software

Rildo F [email protected]

[email protected]






Analise de Requisitos Software

Documents

Transcript of Analise de Requisitos Software