Fundamentos de Análise Orientada a Objetos Etapa 02 – Análise de Requisitos
Unidade Joinville Prof. Mario José Pereira
2 Requisitos - Conceitos
O que é requisito de sistema?
“Requisito é a descrição dos serviços e das restrições de um sistema.” (Somerville, 2001)
3
Necessidades
Características
Requisitos
Problemas
Soluções
Requisitos - Conceitos4
Necessidades
O cliente tem um problema de negócio que precisa ser resolvido;
5
Afinal o que o cliente quer? Características:
Um serviço que o sistema provê para atender uma ou mais necessidades dos atores;
Ex.: uma casa resistente ao sol e chuva, e que no inverno seja aconchegante;
6
Requisitos de Software
Detalhamento das características; Maior especialização
Maior Volume;
Diferentes tipos de aplicação, precisam de diferentes requisitos.
7
O que um Requisitos pode descrever?
Uma facilidade em nível de usuário final (Ex.: o processador de texto deve incluir um corretor ortográfico on-line);
Uma propriedade bem genérica do sistema (ex.: o sistema deve ter segurança de acesso a documentos sigilosos);
Uma restrição específica (o verificador de recebimento de e-mail, deve fazer uma leitura a cada 10 segundos);
Uma regra de negócio (a nota final do aluno em uma disciplina, será a média aritmética de todas as notas nesta disciplina);
Uma restrição ao desenvolvimento do sistema (o sistema deve utilizar *.dll padrões do Windows para exibição de mensagens ao usuário).
Por quê os requisitos são importantes? (Pfleeger, 2004. p. 112)
8
Natureza do documento de Requisitos
É o documento oficial de descrições de requisitos de um projeto de software. Principais características:
Funcionalidade: O que o software deverá fazer?
Interfaces externas: Como o software interage com as pessoas, hardware e outros sistemas?
Desempenho: Qual a velocidade de processamento e tempo de resposta ou outros requeridos?
Outros Atributos: Quais as considerações de portabilidade, manutenibilidade e confiabilidade que devem ser observadas?
Restrições: Existem padrões e limites a serem obedecidos?
9
Elaboração do documento de Requisitos
Descritos pela equipe de desenvolvimento, com participação obrigatória de usuários chaves(pessoas capacitadas e indicadas pelo cliente)
Nem sempre a equipe está qualificada para descrever requisitos porque: Os clientes não entendem o processo de desenvolvimento;
Os desenvolvedores não entendem a área de aplicação, ou o negócio.
10
Evolução do documento de Requisitos
Descoberta de defeitos nos requisitos originais;
Falta de detalhes suficientes nos requisitos originais;
Alterações nos cenários de contexto do projeto(mudanças na legislação).
11
Limites do documento de Requisitos
Definir completa e corretamente todos os requisitos de software; Não descrever qualquer detalhe de desenho ou de implementação:
Partição do produto em componentes; Alocação de funções aos componentes; Fluxo de informação entre componentes; Estruturas internas de dados.
Não descrever aspectos gerenciais do projeto: Custo;
Cronograma de entregas; Relatórios requeridos;
Métodos requeridos de desenvolvimento; Procedimentos de garantia de qualidade; Critérios de verificação e validação.
12
De onde surgem os Requisitos?
Dentro da análise de requisitos, a fase de coleta das informações é chamada de Elicitação de Requisitos.
Elicitar: descobrir, tornar explícito, obter o máximo de informações para o conhecimento do objeto em questão
Cabe à elicitação a tarefa de identificar os fatos que compõem os
requisitos do Sistema, de forma a prover o mais correto e mais completo entendimento do que é demandado daquele software
13
Para se descobrir requisitos podemos recorrer a algumas técnicas: Questionários
Entrevistas Observação Documental Workshop
14
Questionário
Aplicado quando:
Conhecimento sobre o problema em grande número de clientes Precisa de uma amostragem, pois o universo é grande
Possibilitam análises estatísticas
Vantagens: padronização das perguntas e tratamento estatístico das respostas
Desvantagens: limitação do universo de respostas, pouca iteração, pouco retorno
15
Entrevista
Aplicada quando:
Há possibilidade de discussão do problema com diferentes stakeholders O conhecimento do negócio é restrito
Vantagens: contato direto com o usuário e validação imediata Desvantagens: conhecimento tácito e diferenças de cultura
16
Observação
Aplicada quando:
as pessoas acham difícil descrever o que elas fazem, pois isto é muito natural/tácito para elas.
Possibilidade de observá-las no trabalho.
Etnografia é uma técnica das ciências sociais que se mostrou útil no entendimento das processos reais realizados nos trabalhos
Os processo reais de trabalho geralmente diferem daqueles processos formais descritos
Um etnógrafo passa algum tempo observando as pessoas no trabalho e constrói uma imagem de como o trabalho é realizado
Vantagem: visão mais completa e perfeitamente ajustada ao contexto Desvantagem: tempo gasto e pouca sistematização do processo
17
Documental
Aplicada quando:
Domínio conhecido e registrado
Formulários, relatórios, manuais, imagens bibliografia farta
Vantagens: facilidade de acesso e volume de informações
Desvantagens: dispersão das informações e volume de trabalho
18
Workshop
São cenários ou exemplos que explicam/simulam o funcionamento das atividades de um negócio:
uma descrição do estado do sistema antes de começar o cenário o fluxo normal de eventos do cenário
exceções ao fluxo normal de eventos
informações sobre atividades concorrentes
uma descrição do estado do sistema ao final do cenário Vantagens: envolvimento das pessoas
Desvantagens: esforço em conseguir com que as pessoas participem
19
Critérios de descrever bem requisitos: Completo (nada está faltando?)
Preciso (somente uma interpretação) Verificável (testável e mensurável)
Necessário & Suficiente (Pergunte: Qual a pior coisa que pode acontecer se este requisito não for incluído?)
Viável & Realista (os requisitos podem ser implementados com o orçamento e tecnologia disponíveis ?)
20
Critério Completo
Quais erros são mais comuns na descrição de requisitos? (Pfleeger, 2004. p. 145)
21
Critério Completo
Reflete todas as decisões de especificação que foram tomadas? Completa? (dentro dos padrões? Com todos seus componentes presentes/preenchidos)?
às vezes algum componente é dispensável mas de forma geral espera-se;
que o padrão de elaboração da especificação seja seguido e obedecido; Priorizada? (a lista de requisitos está priorizada?);
Identificada? (a lista de requisitos está identificada de forma unívoca?); Finalizada? (nada a definir, ainda?);
Compreensível? (legibilidade da 1ª leitura) [ de 1(muito ruim) a 5(excelente)] (aceita se >=4);
Organizada? (organização do texto/índice/glossário/ título condizente com o conteúdo/ referências a figuras/tabelas/anotações?) [ de 1(muito ruim) a 5(excelente)] (aceita se >=4);
22
Critério Completo
Quantificada? (data sheet com métricas elementares?);
n°de páginas, tempo de elaboração, n°de requisitos, n°de requisitos de Teste, Prazos, Esforços;
Tipo (Evolutiva, Legal, Corretiva);
Abrangente? (todos os atributos de qualidade padrão foram endereçados?);
Testável? (existem requisitos de teste para cada requisito da especificação?);
TÉCNICAS
Leitura diagonal/ por Perspectiva/ por utilização com contagem e
verificação de quesitos (checklist) e preenchimento do Mapa de Métricas dos Testes de Requisitos.
23
Critério Preciso
Por quê é importante ser preciso?
(Pfleeger, 2004. p. 127)
24
Critério Preciso
Terminologia consistente?
Há um glossário para o significado exato dos termos/siglas/ utilizados na especificação?
Os requisitos utilizam estes termos de forma consistente na sua descrição?
Cada referência a um termo dentro de um requisito é consistente com sua definição?
TÉCNICAS
Substitua mentalmente cada termo por sua definição por extenso e releia a frase para verificar se ainda faz sentido!
25
Critério Preciso
Coerência e não ambigüidade?
Todo requisito presente possui apenas uma única interpretação, aceita por todos os envolvidos?
TÉCNICAS
Localize palavras suspeitas (vagas, imprecisas, generalistas) tipo (usuários, normalmente, freqüentemente, alto, baixo, grande, médio, máximo, mínimo...)
Localize condições pernetas (Se condição então ação (senão ????? ))
26
Critério Preciso
Localize Omissões (etc.) e Generalizações (todos, sempre);
Localize Causas sem Efeitos, Efeitos sem causas e Efeitos faltantes; Evite Operadores ambíguos como Negações e duplas negações;
Refaça e verifique todos os cálculos apresentados (erros e ou imprecisões);
Certifique-se que existem unidades de medida;
Certifique-se que os documentos referenciados existem com a identificação correta;
Procure afirmações conflitantes. Compreensibilidade e clareza?
Tem como interpretar de forma diferente cada um dos requisitos? Há maneira de entender isto de mais de uma forma?
Tem algum conhecimento implícito?
Todos os intere$$ados tem o mesmo entendimento de cada requisito?
27
Critério Preciso TÉCNICAS
Desconfie/reescreva frases/requisitos com + de 2 linhas e parágrafos com + de 4 linhas.
Use a técnica de redação 5W2H ou 4Q1POC para analisar cada requisito:
5W2H (What, When, Who, Why, Where, How, How much)
4Q1POC (Que, Quando, Quem, Quanto, Porque, Onde e Como) Aplique a técnica do “telefone/elevador” (30”) a cada requisito.
28
Critério Verificável
Para que se testam requisitos?
(Pfleeger, 2004. p. 114)
29
Critério Verificável Testabilidade:
Requisitos Quantificáveis?
Existe uma medida de qualidade mensurável para cada requisito e que pode ser utilizada para testar se o produto atende (passou/falhou) o
requisito?
As medidas de qualidade estão definidas com tolerâncias? IDEAIS (verde, +80%);
ACEITÁVEIS (amarelo, entre 60%-80%) INACEITÁVEIS (vermelho, -60%).
Existem medidas de Performance, Estabilidade e Testabilidade para os requisitos?
TÉCNICAS
Verificação e Contabilização
Sugestão de quantificação com apresentação aos intere$$ados.
30
Critério Necessário/Suficiente
Afinal, qual o nível que se deve descrever requisitos?
(Pfleeger, 2004. p. 140)
31
Critério Necessário/Suficiente Requisito ou Solução?
Os Requisitos são Soluções disfarçadas de Requisitos?
Quais foram as alternativas consideradas e porque algumas foram descartadas?
TÉCNICAS
Verifique referências a tecnologia no enunciado do requisito. Se tiver provavelmente é solução.
Requisitos devem ser mais abstratos.
Desenvolva, documente e discuta sempre pelo menos 2 alternativas.
32
Critério Necessário/Suficiente
Prioridade aos Intere$$ados?
Existe uma prioridade explícita entre os requisitos da especificação? Essencial (must have) e
Desejável (nice to have) Possível/Opcional.
Cada requisito é classificado de acordo com a sua importância, estabilidade e complexidade.
Existem alternativas de escopo de implementação baseados nestas prioridades?
TÉCNICAS
Verificação e Classificação (por curva ABC, pareto 20/80)
Explore a possibilidade de implementar apenas os requisitos essenciais e classifique-os em alternativas Ideais, Aceitáveis e Inaceitáveis
33
Critério Necessário/Suficiente
Faça uma pesquisa de opinião com seus usuários e priorize pelo cruzamento das respostas:
“Qual o índice de satisfação (1 a 5) para cada requisito se ele for implementado?”
“Qual o índice de insatisfação (1 a 5) para cada requisito se ele não for implementado?”
Motivação
Em relação as funcionalidade implementadas: 7% sempre utilizadas (essenciais)
13% freqüentemente utilizadas 16% utilizadas algumas vezes 19% raramente utilizadas
45% nunca utilizadas
34
Critério Necessário/Suficiente Relevância para a função?
Este requisito contribui para a finalidade do produto? Use a classificação de prioridade como ponto de partida
Cada requisito é relevante dentro dos limites definidos para o produto? O que aconteceria se alguns não fossem implementados?
TÉCNICA
“Procura-se um órfão ou gêmeo” (Rastreabilidade)
Associar cada requisito funcional com seus requisitos de usuário e estes com seus requisitos de negócio (Matriz de relacionamento)
Confrontar cada requisito com os usuários, limites, questionamentos, suposições e restrições da especificação procurando por irrelevâncias.
35
Critério Necessário/Suficiente Benefícios explícitos?
Existe uma lista das deficiências do atual sistema que serão sanadas, melhoradas e ou resolvidas pela nova especificação?
Existe uma lista de benefícios esperados para o novo sistema pela implementação da nova especificação?
TÉCNICA
Verifique a existência de Discurso Persuasivo (Fato, Ação e Benefício) para cada requisito.
Paternidade?
Cada requisito tem uma origem formalmente identificada, um responsável?
Tem como identificar os requisitos que entraram na especificação após a sua “conclusão”?
Os “novos” requisitos foram analisados pelo seu impacto e priorizados? Mapa de Origem dos Requisitos
Mapa de Rastreabilidade e Dependências entre requisitos.
36
Critério Viável/Realista
Responsabilidades Explicitadas?
Existe uma lista completa definindo procedimentos/recursos/prazos que são de responsabilidade dos usuários e sem os quais o sistema baseado nas novas especificações não poderá atender seus objetivos?
TÉCNICA
Verificação e Contabilização
Lista de Atributos de Qualidade.
37
Critério Viável/Realista
Viabilidade do Desenvolvimento?
A estimativa de esforço, prazo e recursos é substanciada? Você possui o skill tecnológico para construir o requisito?
Você possui o tempo, os recursos e o dinheiro para construir o requisito?
Existe uma proposta de prazo, esforço e custo para implementar estritamente os requisitos essenciais?
TÉCNICA
Reestimar e comparar Avaliar
38
Critério Viável/Realista Contingências?
Em caso de não concretização de algum requisito das especificações, qual o plano de contingência previsto?
Rastreabilidade?
Existe uma matriz de relacionamento mostrando a relação entre os
componentes da especificação para permitir determinar impactos no caso de modificação de algum dos componentes da especificação?
TÉCNICAS
Verificar/Elaborar Mapa de Rastreabilidade Requisitos funcionais X requisitos de teste? Features X Requisitos funcionais agrupados? Requisitos Funcionais X de Usuário x Negócio
Contabilizar se todos os componentes estão presentes
39
Critério Viável/Realista Entregáveis?
Cada teste gera um relatório sobre os resultados tempo do teste e recursos envolvidos.
questionamentos levantados, resolvidos, em aberto. recomendações de melhoria da especificação.
melhorias sugeridas no processo/checklist.
consolidação do Mapa de Requisitos de Teste. (coming soon)
40
Dentro da Análise de Requisitos, ainda distinguimos um requisito de outro:
Requisitos Funcionais
Requisitos Não Funcionais.
41
Funcionais:
Determinam “WHAT” é requerido (sem a preocupação do “HOW” será feito.
Derivados a partir dos Requisitos de Usuário.
Traduzem o que o sistema/produto precisa fazer para atender as necessidades dos usuários relacionados a um problema de negócio.
Descrevem um comportamento que deve ser percebido pelo usuário. Definem as funcionalidades esperadas sob o ponto de vista de funções. Base para os Requisitos Não Funcionais e Detalhados.
Exemplos:
“O sistema deve emitir um comprovante para cada operação.”
“O usuário deve ser capaz de calcular gastos diários, semanais e mensais com pessoal.”
“O sistema deve emitir um relatório de operações diário.”
“O sistema de correio eletrônico deve validar a entrada de “User-ID” pelo funcionário observando os padrões de segurança.”
42
Não Funcionais:
São atributos de qualidade que devem ser atingidos pelos requisitos funcionais, assim como, para todo o sistema/produto.
• Norteiam as atividades para o desenvolvimento do projeto/sistema. • Definem quão bem o sistema/produto deve ser operado, ao invés do que ele deve fazer.
• Impõem RESTRIÇÕES sobre “COMO” os requisitos funcionais serão implementados.
Derivados a partir dos Requisitos Funcionais. • Base para os Requisitos Detalhados.
43
Não Funcionais:
Tipos de Requisitos Não Funcionais:
Operacionais (Usabilidade e Sensoriais): aparência, “look-and-feel”, facilidade de uso
Performance: tempo de resposta
Interface: elementos (HW/SW) com os quais o sistema deve interagir ou comunicar-se
Recursos: limites como capacidade de memória, disco e processador Manutenção: quão fácil é corrigir defeitos e adaptar o software a novos requisitos
Recuperação: o que precisa ser feito antes e depois de uma falha Escalabilidade: habilidade do sofware continuar funcionando bem quando ampliado
Disponibilidade: razão entre o tempo durante o qual um software mantem-se operacional
Segurança: a segurança, a confidencialidade e a integridade do projeto/sistema
Políticos & Culturais: fatores humanos
Legais: conformidade com as leis aplicáveis
44
Não Funcionais: Exemplo:
• “A base de dados deve ser acessada apenas por usuários autorizados.”
• “A capacidade de processamento deverá suportar em média 20 transações por segundo.”
• “O sistema deve suportar 1000 operações de I/O simultaneamente.” • “O banco de dados do sistema deve ser DB2.”
• “O correio eletrônico deve validar o “User-ID” em 5 seg. após o recebimento do dado.”
45
Regras de Negócio:
Regras de Negócio
São políticas, condições ou restrições que devem ser consideradas na execução dos processos existentes em uma organização.
Descrevem a maneira pela qual a organização funciona.
Estas regras são identificadas e documentadas no chamado modelo de regras do negócio.
A descrição do modelo de regras do negócio pode ser feita utilizando-se texto informal, ou alguma forma de estruturação.
Regras do negócio normalmente têm influência sobre um ou mais casos de uso.
Os identificadores das regras do negócio devem ser adicionados à descrição do caso de uso.
46
Exemplos:
Regras de Negócio
O valor total de um pedido é igual à soma dos totais dos itens do pedido acrescido de 10% de taxa de entrega.
Um professor só pode estar lecionando disciplinas para as quais esteja habilitado.
Um cliente do banco não pode retirar mais de R$ 1.000 por dia de sua conta.
Os pedidos para um cliente não especial devem ser pagos antecipadamente.
47
Referências Bibliográficas:
PFLEEGER, Shari Lawrence. Engenharia de software: teoria e prática.
São Paulo: Prentice Hall, 2004
PRESSMAN, Roger S.; SANTOS, José Carlos Barbosa dos.
Engenharia de Software. 7ª ed. São Paulo: Makron Books, 2007.
POMPILHO, S.. Análise Essencial : Guia Prático de Análise de
Sistemas. 2ª ed. Rio de Janeiro: Ciência Moderna, 2002.
