289685 Aula 05 Analise Requisitos

Análise de Requisitos

Análise de Sistemas de Informação I Prof. Marcelo Werneck

(com adaptações do material da Profa Eveline Alonso)

Análise de Requisitos

O que acontece?

Requisitos são refinados e analisados para garantir clareza, completude e consistência.

Um requisito pode ter mais de uma

interpretação;

Pode ser compreendido de diferentes formas por analistas, desenvolvedores e usuários.

Um produto diferente do esperado é produzido. Isso deve ser evitado.

Objetivos da Análise de Requisitos

software.

Analisar cada requisito do produto de software

em relação aos demais;

 detectando e resolvendo conflitos entre os requisitos;  conciliando diferentes pontos de vista dos stakeholders

(partes interessadas e envolvidos) do sistema.

Modelar de forma precisa os conceitos relevantes

do domínio do problema.

Ambigüidades nos Requisitos

É necessário SEMPRE esclarecer muito

bem o requisito;

Documentando em um nível de detalhe suficiente para entendimento;

eliminando ambigüidades para que:

seu entendimento seja uniforme para todos

envolvidos;

possa ser validado;

sua implementação possa seja verificada;
seus custos sejam estimados.

Ambigüidades

Se eu não tiver sapatos;

 posso entrar?

Se eu não tiver animais de estimação;

 não posso entrar?

Entrada

É obrigatório:

-calçar os sapatos

-carregar animais de estimação

Ambigüidades nos Requisitos

Cuidado com palavras que indicam imprecisão

ou múltiplas possibilidades, como:

 aceitável, adequado, suficiente;

 eficiente, rápido, fácil, flexível, robusto, elegante;  melhor, superior;

 normalmente, de preferência;  diversos, vários, alguns;  um (qual?), todos, cada;  ou.

Todo requisito precisa ser definido de forma

Exemplos de Requisitos Ambíguos

Exemplo 1:

 Depois de 3 ou 4 dias, deve-se cancelar a reserva.
Afinal de contas, são 3 dias ou 4 dias?

Exemplo 2:

 Deve haver uma reserva para todos os passageiros.
É uma reserva só para todos os passageiros, ou uma para cada um?
Exemplo 3:

 O valor da passagem é impresso no bilhete em quase 100%

dos casos.

Em quais casos o preço da passagem não deve ser impresso no bilhete?
Exemplo 4:

 A cada trinta minutos, um funcionário faz a vistoria das

engrenagens.

É sempre o mesmo funcionário, ou podem ser funcionários diferentes?

Correção de Requisitos Ambíguos

Exemplo 1:

 Deve-se cancelar a reserva após 3 dias, durante a alta

temporada; e após 4 dias, durante a baixa temporada.
Exemplo 2:

 Cada um dos passageiros deve ter sua própria reserva.
Exemplo 3:

 O valor da passagem é sempre impresso no bilhete,

exceto quando o passageiro usa o programa de milhagem como forma de pagamento.
Exemplo 4:

 A cada trinta minutos, o supervisor encarregado no

turno corrente faz a vistoria das engrenagens.

Critérios de Aceitação

Quantifica o comportamento, desempenho,

ou qualquer outro atributo do requisito.

Se aplicam a requisitos funcionais e não

funcionais.

Os testes devem demonstrar que o produto

realmente atende ao requisito

Dificuldade está em definir medida

Critérios de Aceitação

Definir critérios de aceitação para os requisitos

ajuda a:

resolver ambigüidades;

determinar se o requisito foi satisfeito.

Critérios de aceitação para requisitos

não-funcionais;

devem ser mensuráveis.

Se não for possível definir um critério de aceitação

mensurável para um requisito não-funcional;

ele não pode ser um requisito.

Critérios de aceitação

Para requisitos funcionais:

Não há escalas ou medidas

A ação ou é completada com sucesso ou não é. Algo deve ser satisfeito se a ação é completada Critério de aceitação não indica como o teste

deve ser realizado. Apenas um critério de conformidade.

Critérios de Aceitação – Exemplos

Requisito funcional:

O sistema deverá permitir que o aluno consulte os livros do

acervo da biblioteca através de palavras do título do livro.
Critérios de aceitação:

Todos os livros da biblioteca que possuem a palavra

indicada pelo aluno em seus títulos fazem parte da lista retornada.

Completeza.
Contra-exemplo:

O sistema não retorna um livro que contém a palavra indicada em

seu título.

Todos os livros retornados possuem a palavra indicada pelo

aluno em seus títulos.

Correção.
Contra-exemplo:

Critérios de aceitação

Para requisitos não funcionais:

Deve-se utilizar números.

Pode ser uma medida ou uma escala. Normalmente não é possível determinar o

requisito não funcional quantificado de primeira vez.

Pode-se obter primeiramente a intenção e depois refinar o requisito.

Determinar o critério de aceitação esclarece o requisito.

Requisito não-funcional de usabilidade: Deve ser fácil aprender a usar o sistema.
Critério de aceitação:

Um usuário especialista deverá ser capaz de realizar;

após um treinamento de 8 horas;
qualquer tarefa disponibilizada pelo sistema;

 em menos de 5 minutos.
Restrição de projeto:

 O sistema deve minimizar o tráfego de dados pela rede.
Critério de aceitação:

 O volume total de dados enviados pelos nodos do sistema

não deve ser superior a 1 Gigabyte em um período qualquer de 24 horas.

Critérios de Aceitação – Exemplos

Requisito não-funcional de usabilidade:

Deve ser fácil aprender a usar o sistema.

Critério de aceitação:

Um usuário especialista deverá ser capaz de realizar;

após um treinamento de 8 horas;

qualquer tarefa disponibilizada pelo

sistema;

em menos de 5 minutos.

Restrição de projeto:

O sistema deve minimizar o tráfego de dados

pela rede.

Critério de aceitação:

O volume total de dados enviados pelos

nodos do sistema não deve ser superior a 1 Gigabyte em um período qualquer de 24 horas

Critérios de Aceitação – Exemplos

Requisito não-funcional de desempenho:

Sistema deve ser rápido o suficiente para evitar interromper o raciocínio do usuário.

Critério de aceitação:

O tempo de resposta não deve ser maior que 1.5 segundos em 95% das respostas, e não mais do que 4 segundos para as restantes.

Critérios de Aceitação – Exemplos

Conflitos entre Requisitos

requisitos.

Dois ou mais requisitos podem fazer exigências que são impossíveis de serem satisfeitas simultaneamente.

Em geral, cabe ao cliente e usuários resolverem o conflito (não ao analista de requisitos).

 Resolvem-se os conflitos de duas formas:

alterando um dos requisitos do produto;

acrescentando condições que delimitam a aplicação de

Exemplos de Conflitos entre Requisitos

 Todos os que são clientes há mais de 10 anos;

têm direito a isenção de tarifas.

Requisito 2:

 Nenhum cliente que já teve 5 ou mais cheques

devolvidos;

tem direito a isenção de tarifas.

O que fazer então com aqueles que:

 são clientes há mais de 10 anos;  e já tiveram 5 ou mais cheques devolvidos?

Resolução de Conflitos entre Requisitos

Requisito 1:

Todos os que são clientes há mais de 10 anos;

têm direito a isenção de tarifas.

Requisito 2:

Nenhum cliente que já teve 5 ou mais cheques devolvidos;

tem direito a isenção de tarifas;

exceto os que forem cliente há mais de 10 anos.

Exemplos de Conflitos entre Requisitos

 Deve-se conceder exatamente uma pipoca grátis;

para quem alugar 3 filmes ou menos;
no mesmo dia.

Requisito 2:

 Deve-se conceder exatamente duas pipocas

grátis;

para quem alugar 3 filmes ou mais;
no mesmo dia.

Quantas pipocas então deve ganhar quem

Resolução de Conflitos entre Requisitos

Requisito 1:

Deve-se conceder exatamente uma pipoca grátis;

para quem alugar 3 filmes ou menos;
no mesmo dia.

Requisito 2:

Deve-se conceder exatamente duas pipocas grátis;

para quem alugar mais de 3 filmes;
no mesmo dia.

Conciliar Diferentes Pontos de Vista

 vêm de diferentes envolvidos (stakeholders).

Cada stakeholder tem um conjunto diferente

de objetivos para o sistema:

 o departamento de marketing quer o maior

número possível de funcionalidades para o sistema;

 o desenvolvedor quer o menor número possível

de funcionalidades para o sistema;

 o patrocinador quer o menor custo possível;  o usuário quer que o sistema seja fácil de usar.

Conciliar Diferentes Pontos de Vista

Em geral, é impossível alcançar totalmente:

todos os objetivos; de todos os stakeholders.

É preciso então alcançar um consenso;

sobre os objetivos e requisitos do sistema antes de prosseguir.

Modelagem dos Conceitos Relevantes

do Domínio do Problema

Modelagem conceitual;

para a descrição precisa dos requisitos do produto de software:

dos elementos relevantes do domínio do problema;
das relações e dependências desses elementos;

 no mundo real.

Modelagem é realizada;

utilizando-se um dos diversos métodos de análise.

Modelagem dos Conceitos Relevantes

do Domínio do Problema

Objetivo:

 auxiliar a adquirir uma maior compreensão do sistema

que deverá ser construído;

através do detalhamento completo e preciso dos dados,

funções e comportamentos do sistema;

 em nível de detalhes adequado aos desenvolvedores.

Foco:

 visão que os desenvolvedores têm dos requisitos do

produto;

mas ainda dentro do espaço do problema;

 o que o sistema fará?
não do espaço da solução.

 como o sistema fará?

Modelagem dos Conceitos Relevantes

do Domínio do Problema

O modelo de análise deve conter os detalhes

necessários para servir de base para o desenho do produto;

mas deve-se evitar a inclusão de detalhes que pertençam ao domínio da implementação;
e não do problema;

dando ao arquiteto de software a representação conceitual do software;

que pode ser mapeada para o modelo de