Anlise de Requisitos

Andr Luiz Moura Jnior Universo

Bibliografia
n

PRESSMAN, Roger S. Engenharia de Software. 5 ed., Rio de Janeiro: McGraw Hill, 2002, captulos 10 e 11. IEEE. SWEBOK: Guide to the Software Engineering Body of Knowledge. 2004, captulo 2. Transparncias da professora Maria Augusta Vieira Nelson PUC-Minas. PAULA-FILHO, Wilson de Pdua. Engenharia de Software: Fundamentos, Mtodos e Padres. 2 ed., Rio de Janeiro: LTC - Livros Tcnicos e Cientficos, 2003, captulo 6.

Anlise de Requisitos
Conjunto de atividades da Engenharia de Requisitos em que os requisitos so refinados e analisados para garantir clareza, completude e consistncia.

Objetivos da Anlise de Requisitos

Eliminar ambigidades nos requisitos do software. Analisar cada requisito do produto de software em relao 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 domnio do problema.
Priorizar os requisitos elicitados.

Ambigidades nos Requisitos

Muitas vezes um mesmo requisito est sujeito a mais de uma interpretao sendo compreendido de diferentes formas por desenvolvedores e usurios. Problemas podem surgir quando isso acontece.

Ambigidades nos Requisitos

Por isso, sempre que esse for o caso, necessrio esclarecer melhor o requisito, eliminando ambigidades para que:
seu entendimento seja uniforme por todos os stakeholders do sistema; possa ser validado; sua implementao possa seja verificada; seus custos sejam estimados.

Ambigidades
Entrada obrigatrio: -calar os sapatos -carregar animais de estimao
Se eu no tiver sapatos;
posso entrar?

Se eu no tiver animais de estimao;

no posso entrar?

Ambigidades nos Requisitos

Cuidado com palavras que indicam impreciso ou mltiplas possibilidades, como:
aceitvel, adequado, suficiente; eficiente, rpido, fcil, flexvel, robusto, elegante; melhor, superior; normalmente, de preferncia; diversos, vrios, alguns; um (qual?), todos, cada; ou.

Exemplos de Requisitos Ambguos Exemplo 1:

Depois de 3 ou 4 dias, deve-se cancelar a reserva.
Afinal de contas, so 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 preo da passagem no deve ser impresso no bilhete?

Exemplo 4:
A cada trinta minutos, um funcionrio faz a vistoria das engrenagens.
sempre o mesmo funcionrio, ou podem ser funcionrios diferentes?

Correo de Requisitos Ambguos

Exemplo 1:
Deve-se cancelar a reserva aps 3 dias, durante a alta temporada; e aps 4 dias, durante a baixa temporada.

Exemplo 2:
Cada um dos passageiros deve ter sua prpria 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.

Critrios de Aceitao
Definir critrios de aceitao para os requisitos ajuda a:
resolver ambigidades; determinar se o requisito foi satisfeito.

Critrios de aceitao para requisitos no-funcionais;

devem ser mensurveis. Se no for possvel definir um critrio de aceitao mensurvel para um requisito nofuncional;
ele no pode ser um requisito.

Critrios de Aceitao Exemplos

Requisito funcional:
O sistema dever permitir que o aluno consulte os livros do acervo da biblioteca atravs de palavras do ttulo do livro.

Critrios de aceitao:
Todos os livros da biblioteca que possuem a palavra indicada pelo aluno em seus ttulos fazem parte da lista retornada.
Completeza. Contra-exemplo:
O sistema no retorna um livro que contm a palavra indicada em seu ttulo.

Todos os livros retornados possuem a palavra indicada pelo aluno em seus ttulos.
Correo. Contra-exemplo:
O sistema retorna um livro que no contm a palavra desejada em seu ttulo.

Critrios de Aceitao Exemplos

n

Requisito no-funcional de usabilidade:

n

Deve ser fcil aprender a usar o sistema. Um usurio especialista dever ser capaz de realizar;
n n

Critrio de aceitao:
n

aps um treinamento de 8 horas; qualquer tarefa disponibilizada pelo sistema;

n

em menos de 5 minutos.

Critrios de Aceitao Exemplos

Restrio de projeto:
O sistema deve minimizar o trfego de dados pela rede.

Critrio de aceitao:
O volume total de dados enviados pelos nodos do sistema;
no deve ser superior a 1 Gigabyte; em um perodo qualquer de 24 horas.

Conflitos entre Requisitos Tambm chamado de:

negociao de requisitos.

Dois ou mais requisitos podem fazer exigncias;

que so impossveis de serem satisfeitas simultaneamente.

Em geral, cabe ao cliente e usurios resolverem o conflito; Resolve-se os conflitos de duas formas:

no ao analista de requisitos. alterando um dos requisitos do produto; acrescentando condies;

que delimitam a aplicao de cada requisito.

Exemplos de Conflitos entre Requisitos

Requisito 1:
Todos os que so clientes h mais de 10 anos;
tm direito a iseno de tarifas.

Requisito 2:
Nenhum cliente que j teve 5 ou mais cheques devolvidos;
tem direito a iseno de tarifas.

O que fazer ento com aqueles que:

so clientes h mais de 10 anos; e j tiveram 5 ou mais cheques devolvidos?

Resoluo de Conflitos entre Requisitos

Requisito 1:
Todos os que so clientes h mais de 10 anos; tm direito a iseno de tarifas.

Requisito 2:
Nenhum cliente que j teve 5 ou mais cheques devolvidos; tem direito a iseno 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 grtis;
para quem alugar 3 filmes ou menos; no mesmo dia.

Requisito 2:
Deve-se conceder exatamente duas pipocas grtis;
para quem alugar 3 filmes ou mais; no mesmo dia.

Quantas pipocas ento deve ganhar quem alugar exatamente 3 filmes?

Resoluo de Conflitos entre Requisitos Requisito 1:

Deve-se conceder exatamente uma pipoca grtis;
para quem alugar 3 filmes ou menos; no mesmo dia.

Requisito 2:
Deve-se conceder exatamente duas pipocas grtis;
para quem alugar mais de 3 filmes; no mesmo dia.

Conciliar Diferentes Pontos de Vista

vm de stakeholders diferentes.

Muitas vezes os conflitos entre requisitos; Cada stakeholder tem um conjunto diferente de objetivos para o sistema:
o departamento de marketing quer o maior nmero possvel de funcionalidades para o sistema; o desenvolvedor quer o menor nmero possvel de funcionalidades para o sistema; o patrocinador quer o menor custo possvel; o usurio quer que o sistema seja fcil de usar.

Conciliar Diferentes Pontos de Vista

preciso ento alcanar um consenso;
sobre os objetivos e requisitos do sistema; antes de prosseguir.

Em geral, impossvel alcanar totalmente:

todos os objetivos; de todos os stakeholders.

Modelagem dos Conceitos Relevantes do Domnio do Problema

Modelagem conceitual;
para a descrio precisa dos requisitos do produto de software:
dos elementos relevantes do domnio do problema; das relaes e dependncias desses elementos;
no mundo real.

Modelagem realizada;
utilizando-se um dos diversos mtodos de anlise.

Modelagem dos Conceitos Relevantes do Domnio do Problema

Objetivo:
auxiliar a adquirir uma maior compreenso do sistema que dever ser construdo;
atravs do detalhamento completo e preciso dos dados, funes e comportamentos do sistema;
em nvel de detalhes adequado aos desenvolvedores.

Foco:
viso que os desenvolvedores tm dos requisitos do produto;
mas ainda dentro do espao do problema;
o que o sistema far?

no do espao da soluo.
como o sistema far?

Modelagem dos Conceitos Relevantes do Domnio do Problema

O modelo de anlise deve conter os detalhes necessrios para servir de base para o desenho do produto;
mas deve-se evitar a incluso de detalhes que pertenam ao domnio da implementao;
e no do problema;

dando ao arquiteto de software a representao conceitual do software;

que pode ser mapeada para o modelo de implementao.

Priorizao de Requisitos
Estimativas de tempo e custo para o desenvolvimento de software;
so imprecisas.

preciso ento definir quais so os requisitos prioritrios para que o projeto tenha sucesso;
independentemente de acidentes de percurso.
J pensou um sistema de controle acadmico em que:
a emisso de boletins est pronta no dia da matrcula; mas o mdulo de matrcula no?

Priorizao de Requisitos
Priorizar:
fazer uma escolha consciente entre:
as funcionalidades do software; os recursos disponveis;
inclusive o tempo.

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

Tcnicas para Priorizao de Requisitos

Simplesmente perguntar aos stakeholders:
Quais so os requisitos mais importantes?
no surte bons resultados. A resposta em geral :
Todos so.

Tcnicas para Priorizao de Requisitos Comparao por pares de requisitos;

tambm chamada de pairwise comparison.

Tcnica dos R$100,00:

cada participante de uma reunio de negociao de requisitos:
recebe R$100,00 para usar na compra de requisitos; escreve em um papel quanto gastaria para comprar cada requisito.

resultados so computados;
para determinao da prioridade dos requisitos.

Tcnicas para Priorizao de Requisitos IEEE 1998:

classificao dos requisitos quanto importncia:
essencial:
sem seu atendimento;
o produto torna-se inaceitvel.

condicional:
seu atendimento aumenta o valor do produto;
mas sua ausncia pode ser considerada em caso de necessidade.

opcional:
pode ou no ser implementado;
dependendo dos prazos e recursos disponveis.

Exemplos de Priorizao de Requisito funcional: Requisitos O sistema dever permitir que o aluno consulte os livros do
acervo da biblioteca atravs de palavras do ttulo do livro. Prioridade:
essencial.

Restrio de processo:

Os livros retornados como resposta consulta do aluno devem ser exibidos de acordo com o padro Y. Prioridade:
condicional.

Requisito no-funcional de usabilidade:

Os livros, disponveis no acervo da biblioteca, retornados como resposta consulta do aluno devem ser exibidos na cor azul. Prioridade:
opcional.