Análise de Requisitos Eveline Alonso Veloso PUC-Minas.

Apresentação em tema: "Análise de Requisitos Eveline Alonso Veloso PUC-Minas."— Transcrição da apresentação:

1 Análise de Requisitos Eveline Alonso Veloso PUC-Minas

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

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

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

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

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

7 Ambigüidades Entrada É obrigatório: calçar os sapatos
carregar animais de estimação Se eu não tiver sapatos; posso entrar? Se eu não tiver animais de estimação; não posso entrar?

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

9 Exemplos de Requisitos Ambíguos
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?

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

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

12 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. O sistema retorna um livro que não contém a palavra desejada em seu título.

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

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

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

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

17 Resolução 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; exceto os que forem cliente há mais de 10 anos.

18 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; Quantas pipocas então deve ganhar quem alugar exatamente 3 filmes?

19 Resolução 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 mais de 3 filmes;

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

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

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

23 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á?

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

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

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

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

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

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

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