04 requisitos

Prévia do material em texto

Engenharia de Software 
Paulo Cesar de Macedo 
Aula 4 
Como identificar requisitos? 
CONSIDERAÇÕES GERAIS SOBRE 
REQUISITOS 
 
l  Podem surgir de várias formas... 
l  ... mas não implicam simplesmente escrever 
uma lista de desejos das características 
pretendidas retirados da cabeça do usuário 
CONSIDERAÇÕES GERAIS SOBRE 
REQUISITOS 
l  A atividade de entender o que o produto 
pode realizar já recebeu várias 
denominações 
•  Coleta de requisitos ou captura de requisitos 
•  Elicitação de requisitos 
•  Análise de requisitos 
•  Engenharia de requisitos 
•  No design de interação é 
ESTABELECIMENTO DE REQUISITOS ! 
(interpretação + coleta) 
CONSIDERAÇÕES GERAIS SOBRE 
REQUISITOS 
l  E o que são requisitos? 
•  Declaração sobre um produto pretendido que 
especifica o que ele deveria fazer ou como deveria 
operar 
l  Objetivos do estabelecimento de requisitos 
•  Especificidade 
•  Retirar ambiguidades 
•  Clareza 
Exemplos de requisitos para um 
site: 
•  “Tempo de download de uma página completa em 
5 s” 
•  “Os adolescentes devem achar o site atrativo” 
•  “Tempo de resposta rápido” 
•  “Estrutura de menu fácil de utilizar” 
TIPOS DE REQUISITOS 
l  Requisitos funcionais – dizem o que o 
sistema deve fazer. Exs.: 
• Suporte a formatações 
 
• Formatação por parágrafo 
• Formatação por caractere 
TIPOS DE REQUISITOS 
•  Requisitos não-funcionais – indicam as 
limitações no sistema e em seu 
desenvolvimento 
• Ser executado em várias plataformas 
• Funcionar em um computador com 64 Mb de RAM 
• Estar pronto em seis meses 
Tipos de requisitos não 
funcionais 
 
•  Requisitos de dados 
•  Requisitos ambientais 
• Ambiente físico 
• Ambiente social 
• Ambiente organizacional 
• Ambiente técnico 
•  Requisitos do usuário 
•  Requisitos de usabilidade 
CUIDADOS NA ANÁLISE DE REQUISITOS 
 
•  Se perguntar não sobre COMO deve ser feita 
alguma tarefa para construir o sistema, mas 
sobre O QUE é exigido 
CUIDADOS NA ANÁLISE DE REQUISITOS 
• Estar preparado para ambiguidades: 
• “sei que você acredita que entendeu o que 
acha que eu disse, mas não estou certo de 
que percebe que aquilo que ouviu não é o 
que eu pretendia dizer…” 
CUIDADOS NA ANÁLISE DE REQUISITOS 
• Etapas que antes eram construídas 
posteriormente devem ser pensadas 
em conjunto com a análise: 
• Construção do manual do usuário 
• Plano dos testes de usabilidade 
Um analista deve exibir nos seus 
esforços traços característicos… 
• Compreensão de conceitos abstratos 
• Absorver fatos pertinentes 
• Entender o ambiente do usuário 
• Aplicar elementos do sistema aos elementos do 
usuário 
• Comunicar-se bem nas formas escrita e verbal 
• Capacidade de “ver as florestas entre as árvores” 
Um analista deve exibir nos seus 
esforços traços característicos… 
•  … e coordenar cada uma das tarefas associadas à 
análise de requisitos de software 
Primeira lei da engenharia de 
sistemas 
• “Não importa onde se esteja no 
ciclo de vida do sistema, o sistema 
se modificará, e o desejo de 
mudá-lo persistirá ao longo de 
todo o ciclo” (Bersoff) 
Como escolher os dados e fazer 
a coleta adequada? 
l  Um encontro pode estabelecer 
desconcerto entre as partes, mas 
algumas etapas podem ser iniciadas: 
•  Perguntas livres do contexto (direcionadas 
ao cliente) 
• Quem está por trás do pedido deste trabalho? 
• Quem usará a solução? 
• Qual é o benefício econômico de uma solução? 
• Há outra fonte para a solução exigida? 
Compreensão do problema 
(verbalização do cliente sobre uma 
percepção da solução) 
• Como você caracterizaria um bom 
resultado? 
• Qual problema essa solução resolverá? 
• Você pode mostrar o ambiente? 
• Existem questões de desempenho ou 
restrições especiais? 
Metaperguntas (efetividade do 
encontro) 
• Você é a pessoa certa? Suas respostas são 
oficiais? 
• Minhas perguntas são pertinentes ao problema 
que você tem? 
• Estou fazendo perguntas demais? 
• Há mais alguém que possa fornecer 
informações adicionais? 
• Existe algo mais que devo perguntar-lhe? 
Metaperguntas (efetividade do 
encontro) 
l  Após o encontro, desenvolvedores e 
clientes escrevem a requisição do 
produto com uma lista de objetos, suas 
restrições e desempenho, podendo ser 
feitas mini-especificações 
l  “minispecs” 
 
Revisão da especificação 
•  Nível macroscópico 
• Metas e objetivos permanecem consistentes? 
•  Interfaces foram descritas? 
• O fluxo e a estruura são adequados? 
• Os diagramas são claros? 
• As funções estão no escopo? 
• O comportamento é consistente com informação e 
funções? 
• As restrições são realísticas? 
• Qual é o risco tecnológico? 
• Requisitos foram considerados? 
• Critérios de validação foram detalhados? 
• Há inconsistência, omissão, redundância? 
• Contato com o cliente é completo? 
• Protótipo ou manual foram revisados? 
• Estimativas foram afetadas? 
Revisão detalhada 
l  Enunciados da especificação 
• Olhar o porquê de conectivos persuasivos 
•  Por exemplo, certamente, obviamente, claramente 
• Procurar termos vagos 
•  Algum, às vezes, usualmente, o mais, na maior 
parte 
• Identificar listas incompletas 
•  Etc, assim po diante, daí pra frente, tal como 
• Limites declarados com pressuposições 
não declaradas 
•  “códigos variam de 0 a 100” (inteiro, real…) 
Revisão detalhada 
• Cuidado com pronomes pendentes 
• Pedir prova das declarações com certeza 
• Evitar outras definições para um mesmo termo 
• Estrutura descrita em parágrafos (gráfico? 
Figura?) 
• Quando houver cálculo, criar 2 exemplos 
TÉCNICAS DE COLETA DE DADOS 
l  Pesquisas em arquivos, manuais de 
procedimentos operacionais, administrativos 
e outros, bem como a verificação de todos os 
tipos de registros de informações existentes 
TÉCNICAS DE COLETA DE DADOS 
l  Questionários 
•  Podem ter apenas respostas como SIM/NÃO 
•  Podem ter um conjunto de respostas pré-
estabelecidas 
•  Podem ser eletrônicos 
•  Podem atuar junto com outras técnicas 
l  Entrevistas 
•  A entrevista deve ser planejada, desenvolvida sem 
divergência e com controle da arrogância 
Planejamento da entrevista (todos 
os pontos devem ser obedecidos) 
•  1) Marcação de data e horário 
•  2) Preparação do entrevistador – com preparação 
dos itens e sua sequênca, com alguma documentação 
e registro 
•  3) Comportamento do entrevistador – adequação 
ao local, atenção ao entrevistado, interesse em 
resolver os problemas que lhe atingem, sem desviar a 
atenção para outros assuntos 
Planejamento da entrevista (todos 
os pontos devem ser obedecidos) 
•  4) Linguagem – evitar termos técnicos e só 
expressar elogios de forma honesta 
•  5) Distinção entre fatos e opiniões 
•  6) Necessidades do usuário – cuidado com 
o raciocínio em termos pessoais e o pedido 
antecipado de relatórios ou inclusão de 
recursos não necessários 
Considerações gerais sobre as 
entrevistas 
•  A entrevista pode ser dividida em três partes 
de forma que seja imperceptível para o 
usuário 
•  Perguntas abertas são bem vindas 
•  Princípios: não criticar a empresa, o trabalho 
do entrevistado, o sistema existente ou 
qualquer funcionário 
Considerações gerais sobre as 
entrevistas 
•  Relatório após deve ser feito com máxima 
urgência, para não esquecer os detalhes, 
mesmo que tenha gravado ou filmado 
•  Alguns princípios não tradicionais, sociais e 
situados podem ser observados para se fazer 
uma entrevista proveitosa 
COMO ESCOLHER A TÉCNICA 
ADEQUADA 
l  Grupo focal e workshop 
l  Observação natural 
l  Estudo de documentação 
COMO ESCOLHER A TÉCNICA 
ADEQUADA 
l  Deve-sedefinir a natureza da técnica e 
a tarefa a ser estudada 
l  Aspectos: 
•  Tempo 
•  Conhecimento do analista sobre processos 
cognitivos básicos 
Escalas de realização das 
tarefas a serem estudadas: 
•  Conjunto de passos ou subtarefas que se 
sobrepõem? 
•  Alto ou baixo conteúdo de informação? 
•  Realizadas por um leigo ou por alguém com 
domínio da tarefa? 
Diretrizes básicas 
•  Concentrar-se na identificação das necessidades dos 
stakeholders 
•  Envolver o grupo de stakeholders 
•  Envolver mais de um representante 
•  Usar uma combinação de técnicas 
•  Oferecer apoio às sessões 
•  Executar uma sessão-piloto 
•  Conscientizar-se da necessidade de tempo e da falta 
de recursos 
•  A forma de registro dos dados pode trazer grandes 
diferenças. 
REFERÊNCIAS 
l  PRESSMAN, Roger S. - Engenharia de 
Software - Uma Abordagem Profissional 
- 7º Edição 
l  SOMMERVILLE , Ian - Engenharia de 
Software