Upload
internet
View
126
Download
1
Embed Size (px)
Citation preview
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.