Análise de Requisitos Eveline Alonso Veloso PUC-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 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?

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

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.

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

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;

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