Análise de Requisitos

Eveline Alonso VelosoPUC-Minas

Bibliografia PRESSMAN, Roger S. Engenharia de

Software. 5ª ed., Rio de Janeiro: McGraw Hill, 2002, capítulos 10 e 11.

IEEE. SWEBOK: Guide to the Software Engineering Body of Knowledge. 2004, capítulo 2.

Transparências da professora Maria Augusta Vieira Nelson – PUC-Minas.

PAULA-FILHO, Wilson de Pádua. Engenharia de Software: Fundamentos, Métodos e Padrões. 2ª ed., Rio de Janeiro: LTC - Livros Técnicos e Científicos, 2003, capítulo 6.

Análise de Requisitos

Conjunto de atividades da

Engenharia de Requisitos; em que os requisitos são

refinados e analisados; para garantir clareza,

completude e consistência.

Objetivos da Análise de Requisitos Eliminar ambigüidades nos requisitos

do 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 do sistema. Modelar de forma precisa os conceitos

relevantes do domínio do problema. Priorizar os requisitos elicitados.

Ambigüidades nos Requisitos

Muitas vezes um mesmo requisito está sujeito a mais de uma interpretação; sendo compreendido de

diferentes formas por desenvolvedores e usuários.

Problemas podem surgir quando isso acontece.

Ambigüidades nos Requisitos Por isso, sempre que esse for o

caso, é necessário esclarecer melhor o requisito; eliminando ambigüidades para que:

seu entendimento seja uniforme; por todos os stakeholders do sistema;

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.

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

O sistema retorna um livro que não contém a palavra desejada em seu título.

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.

Critérios de Aceitação – Exemplos

Critérios de Aceitação – Exemplos

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.

Conflitos entre Requisitos Também chamado de:

negociação de 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. Resolve-se os conflitos de duas formas: alterando um dos requisitos do produto; acrescentando condições;

que delimitam a aplicação de cada requisito.

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

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 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 3 filmes ou mais; no mesmo dia.

Quantas pipocas então deve ganhar quem alugar exatamente 3 filmes?

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 Muitas vezes os conflitos entre requisitos;

vêm de stakeholders diferentes. 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 É preciso então alcançar um

consenso; sobre os objetivos e requisitos do

sistema; antes de prosseguir.

Em geral, é impossível alcançar totalmente: todos os objetivos; de todos os stakeholders.

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

implementação.

Priorização de Requisitos Estimativas de tempo e custo para o

desenvolvimento de software; são imprecisas.

É preciso então definir quais são os requisitos prioritários para que o projeto tenha sucesso; independentemente de acidentes de

percurso. Já pensou um sistema de controle acadêmico

em que: a emissão de boletins está pronta no dia da

matrícula; mas o módulo de matrícula não?

Priorização de Requisitos Priorizar:

é fazer uma escolha consciente entre: as funcionalidades do software; os recursos disponíveis;

inclusive o tempo.

é necessário para: delimitar ou controlar o escopo do projeto; garantir que o essencial seja realizado.

Quanto maior a prioridade de um requisito; mais essencial esse requisito é;

para atingir os objetivos gerais do software.

Técnicas para Priorização de Requisitos

Simplesmente perguntar aos

stakeholders: “Quais são os requisitos mais

importantes?” não surte bons resultados.

A resposta em geral é: “Todos são.”

Técnicas para Priorização de Requisitos Comparação por pares de requisitos;

também chamada de pairwise comparison. Técnica dos R$100,00:

cada participante de uma reunião de negociação de requisitos:

recebe R$100,00 para usar na compra de requisitos;

escreve em um papel quanto gastaria para comprar cada requisito.

resultados são computados; para determinação da prioridade dos requisitos.

Técnicas para Priorização de Requisitos IEEE 1998:

classificação dos requisitos quanto à importância:

essencial: sem seu atendimento;

o produto torna-se inaceitável.

condicional: seu atendimento aumenta o valor do produto;

mas sua ausência pode ser considerada em caso de necessidade.

opcional: pode ou não ser implementado;

dependendo dos prazos e recursos disponíveis.

Exemplos de Priorização de Requisitos 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.

Prioridade: essencial.

Restrição de processo: Os livros retornados como resposta à consulta do

aluno devem ser exibidos de acordo com o padrão Y. Prioridade:

condicional. Requisito não-funcional de usabilidade:

Os livros, disponíveis no acervo da biblioteca, retornados como resposta à consulta do aluno devem ser exibidos na cor azul.

Prioridade: opcional.