O documento discute os desafios da análise de requisitos, incluindo compreensão do domínio do problema, comunicação, evolução contínua e reutilização. Ele também aborda conceitos como domínio do problema, responsabilidade do sistema, comunicação, mudança contínua de requisitos e reutilização. Finalmente, discute as tarefas da engenharia de requisitos, como concepção, levantamento, elaboração, negociação, especificação, validação e gestão.

1. Pós Graduação em Desenvolvimento de
Software
Módulo: Engenharia de Requisitos
Aula 1: Requisitos
Professor: Licardino Siqueira Pires

2. O desafio da análise
• São quatro os desafios da análise:
• Compreensão do domínio do problema
• Comunicação interpessoal
• Evolução contínua
• reutilização

3. Domínio do Problema e Responsabilidade
• Estudo do domínio do problema e a identificação das suas
características;
• Significados:
• Problema: [Jogar para frente, empurrar para frente (Grego)]; Uma
questão proposta para solução ou consideração;
• Domínio: [Direito de propriedade, posse (Grego)]; A esfera ou
campo de atividade ou influência; como por exemplo o domínio
da arte ou política.
• Assim: Domínio do Problema. Um campo sob estudo
ou consideração.
• Exemplo: controle do espaço aéreo, a aviônica, as
finanças e as leis.

4. Domínio do Problema e Responsabilidade
• Significados:
• Sistema: [reunir (Grego)];Um conjunto ou arranjo de elementos
relacionados ou interligados de modo a formar uma unidade ou
um todo orgânico, por exemplo sistema solar e sistema de
irrigação;
• Responsabilidade: [que precisa de uma resposta (Grego)]; A
condição, qualidade, fato ou ocorrência de ser responsável,
exigível, cobrável ou imputável; aplica-se a pessoas, mandados,
ofícios ou dívidas.
• Assim: Responsabilidade do sistema. Uma
organização de elementos relacionados de modo a
formar um todo.

5. Domínio do Problema e Responsabilidade
• Um analista precisa especificar requisitos, reunidos
concisamente de forma que as pessoas possam ler e
entender o que o analista acredita que são estes
requisitos.
• Mas o crucial é entender o domínio do problema.

6. Comunicação
• Todo o trabalho de análise precisa de comunicação;
• Retornar ao cliente o que foi sintetizado para validação;
• Negociar com cliente requisitos que não possam ser
atendidos, devido ao cronograma e custo;
• Engenharia de software baseada fortemente em pessoas;
• Os processos de software são efetivos somente até o
ponto em que ajudam as pessoas a se comunicarem;

7. Comunicação

8. Mudança Contínua
• Requisitos sempre mudam;
• “Temos que aceitar a instabilidade dos requisitos como
um fato da vida, e não condená-la como o resultado de um
raciocínio mal conduzido” afirma Gerard Fischer;
• Agrupar os requisitos estáveis
• Tratar com diferenciação os instáveis

9. Reutilização
• Reutilizar é o ato de incorporar resultados de análise
anteriores na análise atual;

10. Tarefas da Engenharia de Requisitos
• O processo é composto de sete funções distintas:
concepção, levantamento, elaboração, negociação,
especificação, validação e gestão.

11. Concepção
• Como um projeto de software é iniciado?
•Existe um evento único que torna catalisador de um novo
sistema, ou a necessidade evolui com o tempo?

12. Levantamento
•Parece simples?
• Questione o cliente, o usuário quais os objetivos do
sistema. Pode ser difícil.
Limite mal
definido
Requisitos
mudam

13. Elaboração
•Refinamento das informações obtidas do cliente durante a
concepção e levantamento;
•Modelo técnico refinado das funções, características e
restrições de software;
•O resultado final da elaboração define
• Domínio do problema informacional, funcional e
comportamental.

14. Elaboração
Considere por um momento que lhe foi solicitado especificar todos os requisitos para a
construção de uma cozinha gourmet.
A fim de especificar totalmente o que deve ser construído, você poderia listar todos os
gabinetes e seus eletrodomésticos. Você então poderia especificar o revestimento dos
balcões, peças de encanamento e pavimentação. Essas listas poderiam fornecer uma
especificação útil, mas não fornecem um modelo completo do que você quer.
Para completar o modelo, você poderia criar uma apresentação tridimensional que
mostrasse a posição dos gabinetes, dos eletrodomésticos e relacionamento entre eles.
Construímos modelos de análise por motivos muito semelhantes àqueles pelos quais
desenvolveríamos uma planta ou uma apresentação 3D da cozinha. É importante avaliar
os componentes do sistema em relação uns com os outros, para determinar como os
requisitos se encaixam nesse quadro e avaliar a estética do sistema tal como concebida.

15. Negociação
•Usuários pedem mais do que pode ser conseguido
•Usuários diferentes possuem requisitos de acordo com seus
interesses.
•O Engenheiro de requisitos deve negociar.
•Não deve haver ganhador e nem perdedor em uma
negociação efetiva.

16. Especificação
•Pode ser:
• Cenários de uso
• Documento escrito
• Modelo gráfico
•Último produto do engenheiro de requisitos
•Serve como subsídio das atividades subsequentes;
•Descreve a função e o desempenho de um sistema de
computador e as restrições que governarão seu
desenvolvimento.

17. Validação
•Os produtos de trabalho são avaliados quanto a qualidade

18. Check list da Validação
• Os requisitos foram claramente
estabelecidos? Eles podem ser mal
interpretados?
• A fonte do requisito foi identificada?
• O requisito está limitado em termos
quantitativos?
• Que outros requisitos se relacionam a
este requisito? Eles foram claramente
anotados em uma matriz de referência
cruzada?
• O requisito viola alguma restrição de
domínio?
• O requisito pode ser testado? Em caso
positivo, podemos exercitar os testes
para exercitar o requisito?
• Pode-se relacionar o requisito a qualquer
modelo de sistema que tenha sido criado?
• O requisito está relacionado aos objetivos
globais do sistema/produto?
• A especificação do sistema está
estruturada de modo que leve a fácil
entendimento, fácil referenciação e fácil
tradução em produtos de trabalho mais
técnicos?
• Foi criado um índice para a especificação?
• Os requisitos relacionados ao
desempenho, ao comportamento e às
características operacionais do sistema
foram claramente declarados? Que
requisitos podem estar implícitos?

19. Gestão de Requisitos
•A cada requisito é atribuída uma identificação;
•Tabelas de rastreamento são desenvolvidas

20. Requisitos
• Requisitos tem papel central no processo de software,
sendo considerados um fator determinante para o sucesso
ou fracasso de um projeto de software;
•O processo de levantar, gerenciar e controlar a qualidade
dos requisitos é chamado Engenharia de Requisitos;

21. Definições
• Requisitos de um sistema são descrições dos serviços
que devem ser fornecidos por esse sistema e as suas
restrições operacionais(SOMMERVILLE, 2007).
• Um requisito de um sistema é uma característica do
sistema ou a descrição de algo que o sistema é capaz de
realizar para atingir seus objetivos (PFLEEGER, 2004).
• Um requisito é alguma coisa que o produto tem de fazer ou
uma qualidade que ele precisa apresentar (ROBERTSON;
ROBERTSON, 2006).

22. Tipos de Requisitos
• Requisitos Funcionais:
• são declarações de serviços que o sistema deve
prover, descrevendo o que o sistema deve fazer
(SOMMERVILLE, 2007).
• Um requisito funcional descreve uma interação entre o
sistema e o seu ambiente (PFLEEGER, 2004), podendo
descrever, ainda, como o sistema deve reagir a
entradas específicas, como o sistema deve se
comportar em situações específicas e o que o sistema
não deve fazer (SOMMERVILLE, 2007).

23. Tipos de Requisitos
• Requisitos não Funcionais:
• descrevem restrições sobre os serviços ou funções
oferecidos pelo sistema (SOMMERVILLE, 2007), as
quais limitam as opções para criar uma solução para o
problema (PFLEEGER, 2004).
• Neste sentido, os requisitos não funcionais são muito
importantes para a fase de projeto (design), servindo
como base para a tomada de decisões nessa fase.

24. Requisitos
Organização de Requisitos
• Requisitos Funcionais
• Evidentes são efetuados com conhecimento do
usuário
• Ocultos são efetuados pelo sistema sem o
conhecimento explícito do usuário.
• Transitórios: podem ser mudados por legislações e
normas, por exemplo. (parametrização)
• Exemplo: Registrar empréstimo.
• Requisitos não-funcionais:
• Obrigatórios
• Desejáveis
• Exemplo: O tempo de registro de cada DVD deve ser
inferior a um segundo.

25. Exemplo
• Registrar o empréstimo de uma fita é um requisito funcional.
• Estabelecer que o tempo de empréstimo da fita não pode ser
superior a 48 horas é uma restrição, ou requisito não
funcional.

26. Classificação de requisitos não
funcionais
• Sommerville (2007), por exemplo, classifica-os em:
• Requisitos de produto: especificam o comportamento do
produto (sistema). Referem-se a atributos de qualidade .
• Requisitos organizacionais: são derivados de metas,
políticas e procedimentos das organizações do cliente e
do desenvolvedor.
• Requisitos externos: referem-se a todos os requisitos
derivados de fatores externos ao sistema e seu processo
de desenvolvimento.

27. Níveis de descrição de requisitos
• Requisitos de Usuário: são declarações em linguagem
natural acompanhadas de diagramas intuitivos de quais
serviços são esperados do sistema e das restrições sob as
quais ele deve operar.
• Requisitos organizacionais: definem detalhadamente as
funções, serviços e restrições do sistema.

28. Documento de Especificação de
Requisitos
1. Introdução
1. Propósito do documento de requisitos
2. Escopo do produto
3. Definições, escopo e abreviaturas
4. Referências
5. Visão geral do restante do documento
2. Descrição Geral
1. Perspectiva do produto
2. Funções do produto
3. Características dos usuários
4. Restrições gerais
5. Suposições e dependências
3. Requisitos específicos
4. Apêndices
5. Índice

29. Entendendo as necessidades dos usuários
• Identificar as fontes de requisitos dos Envolvidos
• Definir lista de requisitos do sistema
• Pode-se utilizar técnicas de brainstorming para
levantamento dos requisitos junto aos envolvidos.
• Os requisitos podem ser classificados em duas grandes
categorias:
• Requisitos Funcionais que correspondem a listagem
de tudo que o sistema deve fazer.
• Requisitos não-funcionais que são restrições
colocadas sobre como o sistema deve realizar seus
requisitos funcionais.

30. Quais são as fontes dos requisitos?
Analistas
Parceiros
Usuários
Cliente
Domínio do
Problema
Requisitos Iniciais
Relatórios de Problemas
Solicitações de Mudanças
Visitas no site
Informações dos concorrentes
Legislações
Sistemas legados
Especificações de requisitos
Modelos de negócios
Planos de negócios
Objetivos pessoais

31. Quais problemas podem ser encontrados
• Envolvidos
• Possuem uma ideia pré-concebida da solução
• Não sabem o que eles realmente desejam
• São inabilitados em articular o que eles desejam
• Pensam que sabem o que eles Desejam, mas não os
reconhecem quando eles são entregues
• Analistas
• Pensam que eles entendem os problemas do usuário
melhor do que o usuário.
• Os outros
• Todo mundo enxerga as coisas do seu próprio ponto
de vista
• Acredita que tudo é motivado politicamente (a equipe
comercial deseja a implementação de requisitos que
atraem mais clientes e a financeira requisitos que
tornem os gastos menores)

32. Técnicas para elicitação de requisitos
•Revisar as especificações de requisitos dos clientes
•Entrevista
•Leitura de Documentos
•Questionário
•Participação ativa dos usuários
•Brainstorming
•Workshop de requisitos
•Protótipos
•Observações e análises sociais

33. Técnicas para elicitação de requisitos
Workshop de requisitos
• Criar consenso no escopo, riscos e características
chaves do sistema de software.
• São direcionados por um facilitador
• Duração: 3 a 5 dias
• Artefatos produzidos, como:
• Declaração do problema
• Requisitos dos envolvidos
• Características chaves
• Diagrama de caso de uso
• Lista de risco priorizada

34. Técnicas para elicitação de requisitos
Benefícios do Workshop de requisitos
• Provê um framework para aplicar outras técnicas de
elicitação
• Workshop de caso de uso, brainstorming
• Acelera o processo de elicitação
• Reuni todos os envolvidos para uma discussão intensa e
focado no problema
• Promove a participação de todos
• Resultados avaliados imediatamente

35. Técnicas para elicitação de requisitos
Workshop: Planejar e Executar
Pré-workshop Sessão Produção Acompanhamento
Motivar o workshop
Estabelecer equipe
Organizá-lo
Enviar materiais
Preparar agenda
Facilitar
Rastreamento
Registrar
descobertas
Resumir as
conclusões
Sintetizar
descobertas
Condensar info
Apresentar ao
cliente
Planejar próximos
passos

36. Reunião de Coleta de Requisitos
• Jamie Lazar, Vinod e Ed, membro da
equipe de software; Doug, gerente de
engenharia de software; membros de
marketing; facilitador
• Facilitador (apontando para um quadro):
Então, esta é a lista de objetos e serviços
para a função de segurança residencial.
• Pessoa de Marketing: Isso praticamente
cobre tudo do nosso ponto de vista.
• Vinod: Alguém não mencionou que queria
toda a funcionalidade do CasaSegura
acessível via internet? Isso, incluiria a
função de segurança residencial, não?
• Pessoa de Marketing: É, está certo ...
Vamos ter de acrescentar essa
funcionalidade e os objetos adequados.
• Facilitador: Isso também acrescenta
alguma restrição?
• Jamie: Sim, tanto técnicos quanto legais
• Representante da Produção: O que
significa?
• Jamie: Precisamos estar certos de que uma
pessoa de fora não pode invadir o sistema,
desarmá-lo e roubar o lugar ou pior.
Pesada responsabilidade de nossa parte.
• Doug: Muito Certo
• Marketing: Mas nós ainda precisamos de
conectividade via internet ... Basta nos
certificarmos de impedir a invasão de uma
pessoa de fora.
• Ed: Isso é mais fácil de falar do que fazer...
• Facilitador (interrompendo): Eu não quero
discutir esse ponto agora. Vamos anotá-lo
com um item de ação e prosseguir.
• Facilitador: Estou sentindo que existe
ainda mais a considerar.

37. Técnicas para elicitação de requisitos
Entrevistas
• O engenheiro de requisitos ou analista discute o sistema
com diferentes stakeholders e obtêm um entendimento
dos requisitos.
• Vantagens: contato direto com o usuário e validação
imediata
• Desvantagens: conhecimento tácito e diferenças de
cultura

38. Técnicas para elicitação de requisitos
Entrevistas: tipos
• Entrevistas fechadas. O engenheiro de requisitos busca
respostas para um conjunto de questões pré-definidas
• Entrevistas abertas. Não há uma agenda pré-definida e o
engenheiro de requisitos discute, de forma aberta, o que
o stakeholders quer do sistema.

39. Técnicas para elicitação de requisitos
Entrevistas
• Entrevistadores devem estar de “cabeça aberta” e não
fazer a entrevista com noções pré-concebidas sobre o
que é necessário
• Informar aos stakeholders o ponto inicial da discussão.
Isto pode ser uma questão, uma proposta de requisitos
ou um sistema existente
• Entrevistadores devem estar cientes da política
organizacional - muitos requisitos reais podem não ser
discutidos devido as implicações políticas

40. Técnicas para elicitação de requisitos
Questionário
• Quando existe conhecimento sobre o problema e grande
número de clientes
• Dão idéia definida sobre como certos aspectos universo
de informação/software são percebidos
• Possibilitam análises estatísticas
• Vantagens: padronização das perguntas e tratamento
estatístico das respostas
• Desvantagens: limitação do universo de respostas e
pouca iteração

41. Técnicas para elicitação de requisitos
Modos de comunicação