O documento resume uma aula sobre levantamento de requisitos para engenharia de software. Apresenta técnicas como análise do problema, identificação de stakeholders, e casos de uso para entender as necessidades dos usuários e definir os requisitos do sistema.

1. Engenharia de Software
Aula 4 – Levantamento de Requisitos do
Sistema
Profa. Dra. Judith Pavón
Universidade Salvador – UNIFACS
2012

2. Objetivo da aula
O objetivo desta aula é apresentar
algumas técnicas de Levantamento de
Requisitos.
2

3. Conteúdo
1. Análise do Problema
2. Técnicas de levantamento de requisitos
3. Casos de Uso
3

4. Análise do Problema
Domínio do Problema
Conceitos, processos,
necessidades, objetivos, Analistas
termos..
Clientes,
usuários, etc.
Torna-se nosso problema,
compreender o problema
dos
usuários (de
negócio/técnicos)

5. Análise do Problema
 Análise de problemas - processo de compreender um problema e
propor soluções para resolver esse problema.
 Entender o problema a ser resolvido antes de iniciar o desenvolvimento
da aplicação.
 Quando se considera este tópico (análise do problema) como principal
preocupação no levantamento de requisitos denomina-se “processo de
descoberta de requisitos orientado ao problema”.
identificar os
stakeholders
entender
definir as
as causas
fronteiras
do
da solução
problema
acordar na identificar
definição as
do restrições
problema da solução

6. Análise do Problema
Acordar na definição do problema
 Como formular um problema?
O Problema de Descrição do Problema
Afeta Os Stakeholders afetados pelo problema
Resultando em Qual é o impacto do problema?
Benefícios Indicação da solução proposta e uma lista de
benefícios chaves

7. Análise do Problema
Acordar na definição do problema
 Exemplo de formulação do problema
O Problema de Solução inadequada e fora dos prazos das
requisições de serviço dos clientes
Afeta Nossos clientes, equipe de suporte ao cliente, outros
técnicos
Resultando em Insatisfação do cliente e dos empregados, sentimento
de que qualidade dos serviços é inadequada, e
queda nas vendas.
Benefícios Solução: prover acesso em tempo real a uma base
de dados de problemas à equipe de suporte.
Benefícios: rápido acesso à informação, agilização
dos processos operacionais.

8. Entender as Causas do Problema
Análise da raíz do problema :
Forma sistemática de descobrir o que
está por trás de um problema ou dos
seus sintomas

9. Entender as Causas do Problema
 Exemplo de técnica: diagrama de
espinha de peixe
pouco tempo para causa X
escrever os relatórios
atrasos na entrega da
documentação do projeto
os conteúdos
causa Z causa Y estão dispersos

10. Entender as Causas do Problema
 Quais são as causas do problema?
A maior parte das vezes não vale a pena
considerar TODAS as causas que são raiz do
problema!!!... (???)
Porque os custos seriam muito superiores aos
benefícios...
Como saber quais as causas que vale a pena
considerar na resolução do problema?

11. Entender as Causas do Problema
 Selecionar as causas a considerar:
­ Recolher dados sobre a incidência de cada
causa.
­ Desenhar um diagrama de Pareto.

12. Entender as Causas do Problema
diagrama de Pareto das causas raíz
50
45
40
35
30
25
20
15
10
5
0
dispersão de conteúdos
causa x
tempo de escrita do relatório
causa y
causa z
Consiste em um gráfico de barras que ordena as freqüências das
ocorrências da maior para menor e permite a localização das causas
mais freqüentes.

13. Identificar os stakeholders
 Compreender as necessidades dos interessados no
sistema é um fator decisivo no desenvolvimento de uma
solução efetiva para um problema
­ Quem são os usuários do sistema?
­ Quem é o cliente (comprador) do sistema?
­ Quem será afetado pelas saídas que o sistema produz?
­ Quem fará a manutenção do sistema?
­ ...

14. Definir as Fronteiras da Solução
E/S
SOLUÇÃO
E/S
OUTROS
Usuários
SISTEMAS

15. Identificar as Restrições da
Solução
 Identificar e compreender as restrições impostas
ao sistema.
 Restrições
­ Econômicas;
­ Políticas;
­ Tecnológicas;
­ Sistemas existentes;
­ Ambiente;
­ Recursos.

16. Entendendo as Necessidades
dos Stakeholders
Diferentes Necessidades dos Stakeholders
 Os processos de engenharia de requisitos são dominados por fatores humanos,
sociais e organizacionais porque eles sempre envolvem um conjunto de partes
interessadas com backgrounds diferentes e com objetivos organizacionais e
individuais diferentes
 As partes interessadas (stakeholders) pelo sistema podem ter uma variedade de
background técnico e não técnico e de diferentes disciplinas.
usuários
finais
gestão
analistas
negociação, documento
aprendizagem de requisitos
clientes

17. Entendendo as Necessidades
dos Stakeholders
Características dos Stakeholders mais
importantes:
 Conhecimento do assunto;
 Poder de decisão;
 Objetividade;
 Representatividade.

18. Entendendo as Necessidades
dos Stakeholders
 Fatores que influenciam os requisitos:
­ Personalidade e status dos stakeholders.
­ Os objetivos pessoais dos indivíduos dentro da
empresa.
­ O grau de influência política dentro de uma organização.

19. Entendendo as Necessidades
dos Stakeholders
 Por que capturar ou levantar requisitos é tão
difícil?
­ Usuários são uma fonte imperfeita de
informação:

Vários usuários...inconsistências!
 Falta da visão geral do processo.
 Falta da visão técnica.

20. Entendendo as Necessidades
dos Stakeholders
“Conversa com o alienígena”
 Dificuldades de comunicação
entre usuários e desenvolvedores.
 Mundos diferentes, culturas e
termos distintos.
 Comunicação gera problemas que
afetam diretamente os requisitos
no meio do caminho.
 O quê fazer?
 Buscar aprender sobre a área de
conhecimento das pessoas do
outro grupo. Stakeholder Desenvolvedor

21. Entendendo as Necessidades dos Stakeholders
Problema Proposta de Solução
Usuários não sabem exatamente o que querem ou Reconheça o usuário como o especialista da área e
sabem mas não são capazes de organizar suas aprecie seu conhecimento; tente meios coletivos de
idéias para explicar aos desenvolvedores. identificação de requisitos.
Usuários somente descobrem o que realmente Gere protótipos rápidos antes de desenvolver o
querem quando os desenvolvedores lhes mostram sistema propriamente dito, apenas para validação
algum resultado preliminar. dos usuários.
Os analistas acham que entendem melhor os Aproxime o analista do usuário de forma que este
problemas do usuário do que o próprio usuário. verifique se seu conhecimento procede neste caso.
Todos acreditam que existem razões políticas por Seres humanos são seres políticos: devemos
trás das ações dos outros. aprender a lidar com estes aspectos.

22. Identificação da Fonte de
Informação
Identificação das fontes de informação:
 Stakeholders (Clientes, Usuários, Patrocinadores)
 Outras fontes de Informação:
­ Documentação do macro-sistema;
­ Políticas;
­ Manuais;
­ Memos, atas, contratos...
­ Livros sobre tema relacionado;
­ Outros sistemas da empresa;
­ Outros sistemas externos.

23. Identificação da Fonte de
Informação
Priorizar as fontes de informação:
 Stakeholders mais importantes;
 Documentos mais mencionados ou utilizados;
 Rede de comunicações entre os componentes do macro-
sistema.

24. Técnicas de Levantamento
(Elicitação)
 Entrevistas e Reuniões.
 Análise de Documentos.
 Brainstorm.
 Prototipagem.
 Workshop de Requisitos.
­ JAD.
 Questionários.
 Observação Direta.
 Casos de Uso.
 Role Playing.
 Storyboard.

25. Técnicas de Levantamento
Escrever requisitos
 Requisitos são geralmente escritos como textos em linguagem natural
complementados por diagramas e modelos.
 Geralmente são iniciados com a frase: “O sistema deve permitir.....”
Recomendações
 Evitar cláusulas condicionais complexas que podem confundir.
 Use a linguagem de forma simples, consistente e concisa.
 Use sentenças diretas e objetivas.
 Defina requisitos verificáveis.
 Evite ambigüidades.
 Evite sentenças muito longas.
 Complemente a linguagem natural com outras descrições de requisitos.
 Não assuma que todos os leitores dos requisitos tenham o mesmo background
e usem a sua terminologia.
 Permita tempo para revisão e ser for necessário reescreva os requisitos.

26. Casos de Uso
 Os casos de uso referem-se aos serviços ou processos de
negócio que podem ser utilizados de alguma maneira pelos
usuários do sistema, como emitir um relatório ou comprar um
produto.
 Os casos de uso são utilizados para expressar e documentar o
comportamento ou funções do sistema.
 Um modelo de casos de uso é composto pelo diagrama de
casos de uso e a documentação dos elementos do modelo,
Caixa Eletrônico
Consultar Saldo Efetuar Saque
Consultar
Saldo
- Breve descrição - Breve descrição
Cliente
- Fluxo de eventos - Fluxo de eventos
Efetuar
Saque
Gerente Consultar Extrato
Consultar
Extrato - Breve descrição
- Fluxo de eventos
O Hardware é a fronteira

27. Dúvidas
27