1. Engenharia de
Requisitos
Mailson de Queiroz Proença

2. Tópicos
 A Engenharia de Requisitos
 Importância da Engenharia de Requisitos
 O que são requisitos?
 Requisitos de usuário e de sistema
 Funcionais e não funcionais
 Documento e Especificação de requisitos
 Desenvolvimento de requisitos
 Estudo de viabilidade
 Elicitação e análise de requisitos
 Validação de requisitos
 Gerenciamento de requisitos
 Principais eventos
 Conclusão

3. A Engenharia de Requisitos
 É o ramo da engenharia de software que se
preocupa com:
 os objetivos, funções e restrições dos sistemas de
software.
 É também o processo de estabelecer quais
serviços e restrições são necessários na
operação e desenvolvimento de um sistema.

4. A Engenharia de Requisitos
 Engenharia de Requisitos pode ser dividida em:
 Desenvolvimento de Requisitos:
Elicitação
Análise
Especificação
Validação
 Gerência de Requisitos
Gerência de Mudanças
Acompanhamento de desenvolvimento e
implementação dos requisitos

5. Importância da Engenharia de
Requisitos
 Alguns fatos
 Um trabalho consistente de análise dos requisitos é a
BASE de um projeto de SOFTWARE DE SUCESSO;
 Corrigir problemas na fase de especificação de
requisitos pode gerar uma economia até 200 vezes
maior do que em etapas posteriores.

6. Importância da Engenharia de
Requisitos
“Entender os requisitos de um problema está entre as
tarefas mais difíceis enfrentadas por um engenheiro de
software.” (Pressman, 2011)

7. Importância da Engenharia de
Requisitos
 Segundo pesquisa realizada pelo Standish Group* as principais
razões que levam a problemas de projeto são identificadas no
gráfico:
* http://blog.standishgroup.com/
0 5 10 15 20 25
23
12,8
12,3
11,8
7,5
7
6,4
5,9
5,3
4,3
3,7
% de Respostas
FatoresdeProjetosCríticos

8. O que são requisitos?
 São o ponto de partida para toda a definição
de um sistema.
 Fatores decisivos no desenvolvimento do
produto final de um projeto de software.
 “Capacidade que o software tem e que o
usuário precisa a fim de resolver um problema
e atingir seu objetivo.” (Dorfman e Thayer -
1990)

9. O que são requisitos?
 Um requisito pode variar de:
 Uma declaração abstrata de alto nível de um serviço
a
 Uma restrição do sistema para uma especificação
matemática funcional.

10. Níveis de Requisitos
 Requisitos de usuário:
 são declarações em uma linguagem natural com
diagramas de quais serviços o sistema deverá
fornecer a seus usuários e as restrições com as quais
este deve operar.
 Requisitos de sistema
 são descrições mais detalhadas das funções, serviços
e restrições operacionais do sistema de software.

11. Identificação dos Interessados
 Além do cliente e o do desenvolvedor, que podem,
naturalmente, ter diferentes nomes e títulos, existem
provavelmente:
 O pessoal de marketing,
 O pessoal de testes e garantia de qualidade.
 Gerentes de produtos.
 Gerente geral.
 E uma variedade de “stakeholders” (interessados) que no seu
dia-a-dia serão afetados pelo desenvolvimento do novo
sistema.

12. Identificação dos Interessados
 Sommerville – 1997 define interessados como:
“Qualquer um que se beneficia de forma direta
ou indireta do sistema que está sendo
desenvolvido.”

13. Identificação dos Interessados
 Dificuldades:
 Cada interessado:
Tem uma visão diferente do sistema;
Obtém diferentes benefícios quando o sistema é
desenvolvido com êxito;
E está sujeito a diferentes riscos caso o trabalho de
desenvolvimento venha a fracassar.

14. Identificação dos Interessados
 Reconhecimento de diversos pontos de vista:
 Gerentes Comerciais
 Estão interessados no conjunto de recursos que pode ser
construído dentro do orçamento e que estarão prontos
para atender às oportunidades definidas de ingresso no
mercado.
 Pessoal do Marketing
 Estão interessados nas funções e recursos que irão suscitar
o mercado potencial, facilitando a venda do sistema.

15. Busca de Colaboração
 Primeiro: identificar áreas em comum
 requisitos com os quais os interessados concordam
 Segundo: identificar áreas de conflito
 requisitos desejados por um interessado, mas que
conflitam com os de outros interessados.

16. Busca de Colaboração
 Colaboração não significa, necessariamente,
que os requisitos são definidos por um
comitê.
 Normalmente existe um “poderoso campeão
dos projetos ” (gerente comercial ou técnico
sênior) que pode tomar a decisão final sobre
quais requisitos que passam pelo corte.

17. Classificação de Requisitos
Com uma breve observação percebemos que há
uma infinidade de objetos envolvidos que são
requisitos de software, os quais devem ser
classificados em dois grandes grupos...
 Requisitos Funcionais;
 Requisitos Não Funcionais.

18. Classificação de Requisitos
 Requisitos Funcionais:
 Descrevem as funcionalidades e/ou serviços do sistema;
 Descrevem como o sistema deve reagir a entradas
específicas;
 Podem ser declarações de alto nível do que o sistema
deve fazer;
 Devem descrever os serviços de sistema em detalhes;
 O que o sistema não deve fazer;

19. Exemplos de requisitos funcionais
 O sistema deve permitir que qualquer usuário possa
consultar e visualizar o perfil de outro usuário do
sistema.
 O sistema deve permitir a inclusão, alteração e inativação
dos usuários do sistema.
 O sistema deve permitir aos usuários do tipo gerente
visualizar relatórios de projetos em aberto e/ou
finalizados, e seus respectivos feedbacks.

20. Imprecisão de requisitos
 Problemas surgem quando os requisitos não são
precisamente definidos.
 Requisitos ambíguos podem ser interpretados de
maneiras diferentes pelos desenvolvedores e
usuários.
 Considere o termo “telas apropriadas”:
 Intenção do usuário - telas para cada formato de
documento devem ser disponibilizadas.
 Intenção do desenvolvedor - disponibilizar uma tela de
texto que mostra o conteúdo do documento.

21. Requisitos completos e consistentes
 A princípio, todos os requisitos devem ser completos e
consistentes:
 Completos: Todas as funções requeridas pelo usuário
devem estar definidas.
 Consistentes: Não deve haver conflitos ou contradições
nas descrições dos recursos de sistema.
 Na prática, é quase impossível produzir um documento de
requisitos completos e consistentes.

22. Classificação de Requisitos
 Requisitos Não Funcionais:
 Definem propriedades e restrições do sistema;
 Dizem respeito ao sistema como um todo;
 Muitos requisitos não funcionais são também requisitos de
qualidade, como confiabilidade, tempo de resposta e
espaço em disco;
 Outros são restrições ou exigências de uso de tecnologia.

23. Classificação de Requisitos
 Classificação dos Requisitos Não Funcionais:
Especificam ou restringem
o comportamento do
software.
Derivados das políticas e
procedimentos da
organização do cliente e
do desenvolvedor.
Derivados de fatores externos
ao sistema e seu processo.

24. Exemplos de requisitos não
funcionais
 Requisito de Produto:
 O sistema deve ser capaz de responder até, em média, a 10
requisições por segundo.
 Requisito Organizacional:
 Todos os documentos entregues devem seguir o padrão de relatórios
XYZ-00.
 Requisito Externo:
 O sistema não deve revelar quaisquer informações pessoais sobre os
usuários do sistema, com exceção do nome e número de referência
da biblioteca.

25. Classificação de Requisitos
 Métricas para elecitar Requisitos Não Funcionais:
 Velocidade:
 Transações processadas/segundo;
 Tamanho:
 Megabytes;
 Facilidade de uso:
 Tempo de treinamento;
 Número de frames de ajuda;

26. Classificação de Requisitos
 Métricas para elicitar Requisitos Não Funcionais:
 Confiabilidade:
 Probabilidade de indisponibilidade;
 Taxa de ocorrência de falhas;
 Robustez:
 Tempo de reinício após falha;
 Percentual de eventos que causam falhas;
 Probabilidade de corrupção de dados em caso de falha;
 Portabilidade:
 Percentual de declarações dependentes do sistema-alvo;

27. Documento de requisitos de software
e Especificação de requisitos

28. Documento de requisitos de software
e Especificação de requisitos
 Variabilidade do documento de requisitos
 As informações no documento de requisitos dependem do tipo de
sistema e da abordagem de desenvolvimento usada.
 Normalmente, os sistemas desenvolvidos de forma incremental
terão menos detalhes no documento de requisitos.
 Os padrões dos documentos de requisitos foram
concebidos, tendo como exemplo, a norma IEEE Std 830-
1998.
 Esses são aplicáveis, principalmente, aos requisitos para projetos
de engenharia de sistemas de grande porte.

29. Documento de requisitos de software
e Especificação de requisitos
 Requisitos e Métodos ágeis
 A produção de um documento de requisitos é um desperdício
de tempo pois esses mudam rapidamente.
 Portanto, o documento estará sempre desatualizado.
 O XP, por exemplo, usa a engenharia de requisitos incremental
e expressa os requisitos como “estórias de usuário”.
 Prático para os sistemas de negócios e problemático para
sistemas que exigem várias análises pré-entrega (por
exemplo, sistemas críticos) ou sistemas desenvolvidos por
várias equipes.

30. Documento de requisitos de software
e Especificação de requisitos
 O documento de requisitos tem um conjunto
diversificado de usuários:
 Desde a alta administração da organização que está
pagando pelo sistema.
 Até os engenheiros responsáveis pelo
desenvolvimento do software.

31. Documento de requisitos de software
e Especificação de requisitos
 Especificação:
 É o processo de escrever os requisitos de usuário e de sistema em
um documento de requisitos.
 Idealmente, os requisitos de usuário e de sistema devem
ser:
 Claros
 Inequívocos
 De fácil compreensão
 Consistentes
 Completos

32. Processos de engenharia de
requisitos
 Os processos de engenharia de requisitos
podem incluir quatro atividades de alto nível:
 Estudo de viabilidade;
 Elicitação e Análise;
 Especificação;
 Validação.

33. Processos de engenharia de
requisitos
Estudo da
viabilidade
Relatório de
viabilidade
Validação de
requisitos
Especificações
de requisitos
Requisitos de usuários e
de sistema
Elicitação e
análise de
requisitos
Modelos
de sistema
Documentação de
requisitos

34. Processos de engenharia de
requisitos

35. Estudo de Viabilidade
 Decidir se vale a pena ou não gastar tempo e esforço com o
sistema proposto;
 Sistemas novos devem começar com um estudo da viabilidade;
 Responder Perguntas:
 O sistema contribui para os objetivos gerais da organização?
 O sistema pode ser implementado com a tecnologia atual dentro das
restrições de custo e de prazo?
 O sistema pode ser integrado a outros?
 Que contribuição direta o sistema trará para os objetivos da empresa?

36. Relatório de Viabilidade
 O relatório pode:
 Propor mudanças no enfoque, no orçamento e/ou no
cronograma;
 Sugerir outros requisitos de alto nível para o
sistema;
 Simplesmente cancelar o projeto de
desenvolvimento do sistema.

37. Elicitação e análise de requisitos
 Reúne informações sobre o sistema proposto e os
existentes.
 O objetivo é descobrir:
 O domínio de aplicação;
 Serviços que devem ser fornecidos pelo sistema;
 Restrições associadas ao domínio ou serviços;
 Envolvem diversos stakeholders;

38. Atividades da Elicitação e análise de
requisitos
1. Descoberta
de Requisitos
2. Classificação
e organização
de requisitos
3. Priorização
e negociação
de requisitos
4. Especificação
de requisitos

39. Obtendo os requisitos
 Técnicas para levantamento de requisitos:
 Descoberta de Requisitos(Pontos de vista)
 Entrevistas
 Cenários
 Casos de Uso
 Etnografia

40. Obtendo os requisitos
 Técnicas para levantamento de requisitos:
 Descoberta de Requisitos(Pontos de vista)
 Entrevistas
 Cenários
 Casos de Uso
 Etnografia

41. Descoberta de Requisitos
 Processo que reúne informações sobre o sistema
proposto e os existentes para obter os requisitos de
usuário e de sistema.
 Em uma empresa de tamanho médio ou grande, existem
vários stakeholders;
 Cada stakeholder tem um ponto de vista diferente
 Cada um vê o problema de modo diferente;
 Objetivo: conhecer o problema por várias perspectivas.

42. Descoberta de Requisitos
 Stakeholders frequentemente:
 Não sabem na realidade o que querem;
 Não conseguem expressar claramente o que
desejam;
 Fazem pedidos não realistas;
 Se expressam com seus próprios termos (técnicos).
 Diferentes stakeholders expressam o mesmo
requisito de forma diferente.

43. Obtendo os requisitos
 Técnicas para levantamento de requisitos:
 Descoberta de Requisitos(Pontos de vista)
 Entrevistas
 Cenários
 Casos de Uso
 Etnografia

44. Entrevistas
 Questionar os stakeholders sobre o sistema (ou
processo) atual e sobre o sistema que será
desenvolvido;
 Tipos de entrevistas:
 Entrevistas fechadas: conjunto pré-definido de
perguntas;
 Entrevistas abertas: sem agenda pré-definida; se
adapta para explorar o conhecimento do stakeholder.

45. Obtendo os requisitos
 Técnicas para levantamento de requisitos:
 Descoberta de Requisitos(Pontos de vista)
 Entrevistas
 Cenários
 Casos de Uso
 Etnografia

46. Cenários
 Descreve uma situação de uso do sistema;
 Inclui informações como:
 Nome do Cenário;
 Ator;
 Pré-condição;
 Fluxo normal;
 Fluxos alternativos;
 Pós-condição.

47. Exemplo de Cenário
 Nome do Cenário: Sacar dinheiro
 Ator: Correntista
 Pré-condição: Conta e senha validada
 Fluxo normal:
 Entrar com valor do saque
 Confirmar dados e operação
 Debitar valor da conta do cliente
 Fluxos alternativo: Saldo insuficiente
 Apresentar aviso ao cliente
 Pós-condição:
 Valor sacado é debitado do saldo do cliente

48. Obtendo os requisitos
 Técnicas para levantamento de requisitos:
 Descoberta de Requisitos(Pontos de vista)
 Entrevistas
 Cenários
 Casos de uso
 Etnografia

49. Casos de Uso
 Introduzida inicialmente no método Objectory
(JACOBSON et al., 1993).
 Em sua forma mais simples, identificam:
 Os atores envolvidos;
 As funcionalidades principais;
 A interação entre atores e funcionalidades do sistema.

50. Casos de Uso
Retirar
Dinheiro
Transferir
Fundos
Depositar
Fundos
Inicializar
o Sistema
Cliente
Operador de
Caixa Eletrônico
Sistema Bancário
 Descrição textual;

51. Obtendo os requisitos
 Técnicas para levantamento de requisitos:
 Descoberta de Requisitos(Pontos de vista)
 Entrevistas
 Cenários
 Casos de uso
 Etnografia

52. Etnografia
 É uma técnica de observação utilizada para
compreender os processos operacionais;
 O analista (engenheiro de requisitos) se insere
na organização do cliente:
 Observa o trabalho no dia a dia;
 Anota as tarefas dos funcionários.

53. Etnografia
 É eficaz para descobrir:
 maneira como as pessoas realmente trabalham;
 da cooperação e conscientização das atividades de
outras pessoas;
 Desenvolver um protótipo;
 Revelar detalhes importantes que são
ignorados por outras técnicas.

54. Validação de Requisitos
 Custos de erros de requisitos são altos, desse
modo, a validação é muito importante.
 Validar é:
 Demonstrar se os requisitos definem o sistema que o
cliente realmente quer.

55. Validação de Requisitos
 Os diferentes tipos de validação que devem ser
efetuados:
 Validade
 O sistema fornece as funções que melhor atendem às
necessidades do cliente?
 Consistência
 Existe algum conflito de requisitos?
 Completude
 Estão incluídas todas as funções e restrições requeridas pelo
cliente ?

56. Validação de Requisitos
 Os diferentes tipos de validação que devem ser
efetuados:
 Realismo
 Os requisitos podem ser implementados com o
orçamento e a tecnologia disponíveis?
 Verificabilidade
 Os requisitos podem ser verificados? Pode ser escrito
um conjunto de testes que demonstrem que o sistema
atende a cada requisitos especificado.

57. Validação de Requisitos
 Técnicas de Validação de Requisitos:
 Revisões de requisitos
 Análise manual sistemática dos requisitos.
 Prototipação
 Usando um modelo executável do sistema para verificar
os requisitos.
 Geração de casos de teste
 Desenvolvimento de testes para verificar os requisitos
implementados.

58. Gerenciamento de Requisitos
 Usuários muitas vezes mudam os requisitos ou “não sabem
o que querem”...
 Requisitos são, inevitavelmente, incompletos e
inconsistentes:
 Novos requisitos surgem durante o processo, à medida
que as necessidades de negócio mudam e uma melhor
compreensão do sistema é desenvolvida;
 Os diferentes pontos de vista têm requisitos diferentes
e estes são frequentemente contraditórios.

59. Gerenciamento de Requisitos
 É o processo de gerenciamento de mudanças de
requisitos durante o processo de engenharia de
requisitos e o desenvolvimento de sistema.
 É necessário:
 Compreender e controlar as mudanças dos requisitos;
 Avaliar os impactos das mudanças;

60. Gerenciamento de Requisitos
 Fatores para a mudança de requisitos
 Erros e inconsistência de requisitos
 Evolução do conhecimento sobre o sistema
 Problemas técnicos, de custo e prazo
 Mudança de prioridades
 Mudanças organizacionais

61. Planejamento de gerenciamento de
requisitos
 Durante o processo de gerenciamento de requsitos, você
tem de planejar:
 A Identificação de requisitos
 Como os requisitos são identificados individualmente;
 O processo de gerenciamento de mudanças
 Avalia o impacto e o custo das mudanças;
 Políticas de rastreabilidade
 É a quantidade de informações sobre os relacionamentos de requisitos;
 Ferramenta de apoio
 O apoio de ferramenta requisitada para auxiliar no gerenciamento das
mudanças requisitos.

62. Planejamento de gerenciamento de
requisitos
 Ferramentas:
 Caliber RM – comercial – Borland;
 QSS requirit – comercial – Quality System & Software;
 IBM – Rational RequisitePro – comercial – IBM Rational;
 OSRMT – open source;
 aNimble – open source.

63. Principais Eventos
 Requirements Engineering Conference 2015
 23ª edição
 Ottawa – Canadá, de 24 a 28 de Agosto
 Qualis A1
 Tema:
 Requirements for the masses.
Requirements from the masses.
 Working Conference on Requirements Engineering: Foundation for Software
Quality 2015
 21ª edição
 Essen – Alemanha, de 23 a 26 de Março.
 Qualis b3
 Workshop em Engenharia de Requisitos - WER 2015
 Qualis B3
 18ª edição
 Lima - Peru, de 22 a 24 de Abril.

64. Principais Eventos
 Principais Tópicos de Interesse:
 Elicitação de requisitos, análise, documentação,
validação e verificação;
 O gerenciamento de requisitos, pontos de vista,
priorização e negociação;
 Modelagem de requisitos, objetivos e domínios;
 Relacionando requisitos para objetivos de negócios,
arquitetura e testes;
 Requisitos em desenvolvimento ágil, linha de produtos
e modelo-dirigido a desenvolvimento;

65. Principais Eventos
 Principais Tópicos de Interesse:
 Requisitos em serviços orientados, virtualização, embarcados, em
nuvem e ambientes móveis;
 Requisitos relacionados com a segurança, confiabilidade,
segurança, privacidade e forense digital;
 Estudos empíricos, medições e previsão;
 Específicas de domínio problemas, experiências e soluções,
incluindo domínios novos e emergentes;
 Ferramenta de suporte para engenharia de requisitos;
 Evolução dos requisitos ao longo do tempo, as famílias de
produtos, a variabilidade e reutilização.

66. Conclusão
 A engenharia de requisitos define, sem dúvida, um dos
mais importantes conjuntos de atividades a serem
realizadas em projetos de desenvolvimento de software.
 Embora não garanta a qualidade dos produtos gerados, é
um pré-requisitos básico para que obtenhamos sucesso
no desenvolvimento do projeto.

67. Bibliografia
 DORFMAN, M., THAYER, R. H., 1990. Standards, Guidelines and
Examples of System and Software Requirements Engineering. Los
Alamitos, CA, IEEE Computer Society Press.
 Norma 830-1998 - IEEE Recommended Practice for Software
Requirements Specifications.
 PRESSMAN. “Engenharia de Software” 6ª Edição.
 SOMMERVILLE, I. Engenharia de software. 8ª edição São Paulo:
Pearson Addison- Wesley, 2007.
 SOMMERVILLE, I. Engenharia de Software, 9ª Edição. Pearson
Education, 2011.

68. Dúvidas