O documento discute a engenharia de requisitos, incluindo a elicitação, detalhamento e documentação de requisitos. Apresenta várias técnicas para análise de requisitos como entrevistas, questionários e protótipos. Discutem características de bons requisitos como não ambíguos, verificáveis e determinísticos. Também aborda classificação, validação e gerenciamento de requisitos.

1. Engenharia de Requisitos
Elicitação, detalhamento e documentação.

2. O que é um projeto de sucesso?
“Satisfaz seus clientes e patrocinadores com resultados
que atendem seus objetivos dentro das restrições de
tempo e custo, com produtos de qualidade, mantendo e
promovendo relações harmoniosas entre os envolvidos e
contribuindo pro aprendizado da organização.”
Daniel Garnier

3. “A parte mais difícil de construir um
sistema de software é decidir precisamente
o que construir. Nenhuma outra parte do
trabalho conceitual é tão difícil quanto
estabelecer os requisitos técnicos
detalhados… Nenhuma outra parte danifica
tanto o sistema resultante se for feita de
forma errada. Nenhuma outra parte é mais
difícil de retificar posteriormente.”
Frederick Brooks

4. Custo para se reparar um defeito

5. Requisitos
“Eu sei que você acredita que compreendeu o que eu
disse, mas não estou certo de que o que você ouviu era
realmente o que eu queria dizer!”

6. Identificando requisitos
 Requisito é a condição para se alcançar determinado fim
(Dicionário Houaiss)
 É a descrição dos serviços e das restrições de um
sistema (Somerville)
 Uma capacidade do software necessária ao usuário para
resolver um problema para atingir um objetivo (Dorfman)

7. Processo de requisitos do software

8. O processo de elicitação e análise de
requisitos

9. Técnicas para análise de requisitos
 Entrevista (reunião, call, estruturada ou não)
 Questionários (modelos padrão ou personalizados)
 Análise de formulários (automatização)
 Câmeras de vídeo (dia a dia do usuário)
 Cenários
 Cartões de estórias
 Árvores de decisão
 Prototipação

10. Classificação dos requisitos
 Funcionais
• Descrever a funcionalidade ou os serviços do sistema.
• Depende do tipo de software, possíveis usuários e o tipo de
sistema em que o software é usado.
• Requisitos funcionais dos usuários podem ser declarações de
alto nível a respeito do que o sistema deve fazer.
• Requisitos funcionais do sistema devem descrever
detalhadamente os serviços do sistema.
 Não Funcionais

11. Classificação dos requisitos
 Funcionais
 Não Funcionais
• Esses requisitos definem as propriedades e as restrições do
sistema por exemplo, confiabilidade, tempo de resposta e
ocupação de área.
• As restrições são capacidades de dispositivos de E/S, as
representações do sistema, etc.
• Os requisitos de processo também podem ser especificados
impondo um IDE particular, linguagem de programação ou
método de desenvolvimento.
• Os requisitos não-funcionais podem ser mais críticos do que os
requisitos funcionais. Se esses não forem atendidos, o sistema
pode ser inútil.

12. Classificação dos requisitos
 De usuário
 Declarações em linguagem
natural com diagramas dos
serviços que o sistema
deverá fornecer e suas
restrições operacionais.
Escrito para os clientes.
 De Sistema
 Um documento estruturado
estabelecendo descrições
detalhadas das funções do
sistema, serviços e restrições
operacionais. Define o que
deve ser implementado assim,
pode ser parte de um
contrato entre o cliente e o
empreiteiro.

13. Classificação dos requisitos

14. Classificação dos requisitos
 De usuário  De Sistema

15. Classificação dos requisitos

16. Características de bons requisitos
 Não ambíguo
 Verificável
 Determinístico
 Rastreável
 Correto

17. Não ambíguo
 Ambiguidade = incerteza por causa da obscuridade ou
indistinção
 Escrever para outra pessoa ler
 Problemas:
 Uso de pronomes
 “O sistema de RH deverá permitir somente cinco registros de
dependentes válidos e tipos de planos de saúde; ele deve incluir o
mais velho”
 Acrônimos e siglas
 Indeterminação
 “O sistema deverá fazer as correções no registro quando possível”
 Assumir conhecimento prévio
Características de bons requisitos

18. Verificável
 Pode ser testado completamente de modo razoável
(conforme a sua criticidade)
 Assegurar que
 Sistema funciona corretamente
 As exceções são tratadas de forma adequada
 Suporta vários conjuntos diferentes de dados
 Exemplo:
 “O sistema deve ser amigável”
Características de bons requisitos

19. Determinístico
 Precisa necessariamente ser determinável – todos os
caminhos devem ser previstos
 “O sistema deve enviar novos registros aos sistema
Financeiro a cada cinco minutos”
 E se não tiver novos registros neste período?
Características de bons requisitos

20. Rastreável
 De onde veio este requisito?
 No que ele vai se transformar (ou já se transformou) no
sistema?
 Caminho do requisitante à implementação em duas vias
 É muito importante quando
 Um requisito é alterado
 Um componente de software é alterado
 Se negocia prioridades (ou cortes)
Características de bons requisitos

21. Correto
 Consistência (um requisito não pode contradizer o outro)
 Deve ser assegurada a acuracidade e a correção no
texto do requisito
 Não enrolar
 Sentenças com começo, meio e fim
Características de bons requisitos

22. Atores no processo de requisitos
 Clientes e usuários
 Gerentes de negócios (áreas afetadas)
 Gerente e líderes do projeto
 Projetistas de software
 Testadores

23. Documentação de requisitos
 O documento de requisitos de software é a declaração
oficial do que é demandado dos desenvolvedores do
sistema.
 Deve incluir ambas, uma definição de requisitos do
usuário e uma especificação de requisitos do sistema.
 NÃO é um documento de projeto. Na medida do
possível, deve definir O QUE o sistema deve fazer ao
invés de COMO deve fazê-lo.
 Documento de especificação de requisitos: o que o
desenvolvedor precisa saber
 Lembrar: documento de visão, glossário e requisitos se
complementam

24. Documentação de requisitos

25. Documentação de requisitos
 Padronização da sintaxe
 Modelo de user histories
 Modelo em linguagem natural
 Modelo de casos de uso

26. Estrutura do documento de requisitos

27. Estrutura do documento de requisitos

28. Formas de escrever uma especificação
de requisitos de sistema

29. Usuários do documento de requisitos

30. Usuários do documento de requisitos

31. Validação dos requisitos

32. Revisão dos requisitos
 Rever metas e objetivos estabelecidos para o sistema
 Comparar requisitos metas o objetivos
 Descrever o ambiente operacional
 Examinar
 interfaces
 fluxo de informações
 funções
 Verificar omissões, imperfeições e inconsistências
 Documentar riscos
 Discutir sobre como o sistema será testado

33. Desafios da fase de requisitos
 Funcionários do cliente podem sentir-se
intimidados/substituídos pelos computadores
 Habilidade em negociação
 Pouco tempo para as discussões mais profundas
(essenciais)
 Flexibilidade e objetividade são essenciais

34. Gerenciamento de requisitos
 Gerenciamento de requisitos é o processo de gerenciar os
requisitos em constante mudança durante o processo de
engenharia de requisitos e desenvolvimento de sistemas.
 Após o sistemas começar a ser usado, surgem novos
requisitos.
 É preciso manter o controle das necessidades individuais e
manter ligações entre os requisitos dependentes para que
você possa avaliar o impacto das mudanças nos requisitos.
 É necessário estabelecer um processo formal para fazer
propostas de mudança e ligar essas aos requisitos de
sistema.

35. Mudanças nos requisitos
 O ambiente técnico e de negócios do sistema sempre muda após a
instalação.
 Um novo hardware pode ser introduzido, pode ser necessário para a interface
do sistema com outros sistemas, as prioridades do negócio podem mudar (com
as consequentes alterações no sistema de apoio necessário) e, podem ser que
o sistema deve, necessariamente, respeitar.
 As pessoas que pagam por um sistema e os usuários desse sistema
raramente são as mesmas pessoas.
 Clientes do sistema impõem requisitos devido a restrições orçamentais e
organizacionais. Esses podem entrar em conflito com os requisitos do usuário
final e, após a entrega, pode ser necessário adicionar novos recursos para
suporte ao usuário, caso o sistema seja para atender a seus objetivos.
 Sistemas de grande porte costumam ter uma comunidade de usuários
diversos, com muitos usuários tendo necessidades diferentes e
prioridades que podem ser conflitantes ou contraditórias.
 Os requisitos do sistema final são, inevitavelmente, um compromisso entre eles
e, a experiência mostra que, muitas vezes se descobre que o balanço de apoio
dado aos diferentes usuários precisa ser mudado.

36. Planejamento de gerenciamento de
requisitos
 Estabelece o nível de detalhamento necessário para o
gerenciamento de requisitos. Decisões do gerenciamento de
requisitos:
 Identificação de requisitos. Cada requisito deve ser identificado
exclusivamente para que ele possa ser comparado com outros
requisitos.
 Processo de gerenciamento de mudanças. Esse é o conjunto de
atividades que avaliam o impacto e o custo das mudanças. Esse
processo é discutido em mais detalhes na seção seguinte.
 Políticas de rastreabilidade. Essas políticas definem as relações
entre cada requisito e entre os requisitos e o projeto do sistema que
deve ser registrado.
 Ferramentas de suporte. As ferramentas de suporte que podem ser
usadas ​​variam desde sistemas especialistas, sistemas de
gerenciamento de requisitos até planilhas e sistemas de banco de
dados simples.

37. Gerenciamento de mundança de requisitos
 Decidir se uma mudança de requisitos deve ser aceita.
 Análise de problema e especificação de mudanças
 Durante essa fase, o problema ou a proposta de mudança é analisada
para verificar se é válida. O feedback dessa análise é devolvido para o
solicitante, que pode responder com uma proposta mais específica de
mudança dos requisitos, ou decidir retirar o pedido.
 Análise de mudanças e custos
 O efeito da mudança proposta é avaliado por meio de informações de
rastreabilidade e conhecimento geral dos requisitos do sistema. Uma
vez que essa análise é concluída, toma-se a decisão de prosseguir ou
não com a mudança de requisitos.
 Implementação de mudanças
 O documento de requisitos e, se necessário, o projeto e implementação do
sistema, são modificados. Idealmente, o documento deve ser organizado
de modo que as mudanças possam ser facilmente implementadas.

38. Gerenciamento de mudança de requisitos

39. AVISOS PAROQUIAIS
São avisos fixados nas portas de uma igreja, todos eles reais,
escritos com muito boa vontade e muito má redação.

40. AVISOS AOS PAROQUIANOS
Para todos os que tenham filhos e não o saibam, temos na
paróquia uma área especial para crianças.

41. AVISOS AOS PAROQUIANOS
Prezadas senhoras, não esqueçam a próxima venda para
beneficencia. É uma boa ocasião para se livrar das coisas
inúteis que há na sua casa. Tragam os seus maridos!

42. AVISOS AOS PAROQUIANOS
O mês de novembro finalizará com uma missa cantada por
todos os defuntos da paróquia.

43. Checklist
 Os requisitos:
 Estão corretos?
 São consistentes?
 Estão completos?
 São realistas?
 Descrevem algo necessário para o cliente?
 Podem ser verificados?
 Podem ser rastreados?

44. Relembrando

45. Pontos importantes
 Você pode usar uma variedade de técnicas para a elicitação
de requisitos, incluindo entrevistas, cenários, casos de uso e
etnografia.
 A validação dos requisitos é o processo de verificação da
validade, consistência, completude, realismo e verificabilidade
dos requisitos.
 Mudanças organizacionais e técnicas, e de negócios,
inevitavelmente levam a mudanças nos requisitos de um
sistema de software.
 O gerenciamento dos requisitos é o processo de
gerenciamento e controle dessas mudanças.

46. Engenharia de Requisitos
Elicitação, detalhamento e documentação.