Universidade Federal da Paraíba

Centro de Ciências Aplicadas e Educação

Departamento de Ciência Exatas

Engenharia de Software

Engenharia de Requisitos de Software

Capítulo 05
Juliana Saraiva
julianajags@dcx.ufpb.br

Adaptado de SOMMERVILLE
Sumário
● Introdução
● Definição de Engenharia de Requisitos
● Definição de Requisitos
● Tipos de Requisitos
● Imprecisão de Requisitos
● Metas x Requisitos
● Medidas de Requisitos Não-Funcionais
● Interação entre requisitos
● Requisitos e Projeto
● Diretrizes para escrever requisitos
● DDR (Documento de Requisitos)
● Usuário de DDR
● Validação de Requisitos

2
Introdução
“56% dos erros de um software podem ser rastreados para a fase de
requisitos.” (Tom DeMarco, 89)

• Quanto mais tarde um erro é detectado, maior o custo de corrigí-lo.

• Muitos erros são realizados durante a definição de requisitos.
• Erros típicos incluem fatos incorretos, omissões, inconsistências e
ambiguidade.
• Erros nos requisitos constituem uma das maiores preocupações da
indústria de software.

3
Iniciando um projeto...
• Problemas complexos
– Não basta mais fazer um simples controle de estoque.
– As exigências dos clientes crescem rapidamente.
• Domínio desconhecido
– Como é que funciona uma imobiliária?
• Aplicação inexistente
– Se não tem um sistema semelhante para servir de base, por onde
começar?

4
Engenharia de Requisitos
• Requisitos são identificados com os clientes de uma maneira
formal e cuidadosa
– Os clientes nem sempre conseguem descrever com exatidão o que precisam
• Principalmente para pessoas que não são da sua área.
• Cada área possui um vocabulário diferente.
– Nós nem sempre somos capazes de entender aspectos do negócio
• Sabemos como utilizar o computador para solucionar problemas.
• Mas nem sempre sabemos como as possíveis soluções podem afetar as necessidades do negócio
do cliente.
• Também possuímos nosso próprio vocabulário.
• As vezes achamos que estamos falando da mesma coisa e não estamos.
– Conclusão: A identificação de requisitos precisa ser cuidadosamente executada

5
Engenharia de Requisitos
• Definição

A Engenharia de Requisitos, uma sub-área da Engenharia de

Software, estuda o processo de definição dos requisitos que o
software deverá atender.

– A área surgiu em 1993 com a realização do I International Symposium on

Requirements Engineering.
– O processo de definição de requisitos é uma interface entre os desejos,
necessidades e limitações dos clientes e a posterior implementação desses
requisitos em forma de software.

6
Quais os Objetivos de se ter requisitos?
• Estabelecer e manter um acordo com clientes e outros
stakeholders sobre o que o sistema deve fazer.
• Prover desenvolvedores com um melhor entendimento sobre o
que o sistema deve fazer.
• Definir os limites do sistema.
• Prover base para o planejamento.

7
Importância
• A fase de levantamento de requisitos é decisiva para o sucesso do
projeto:
– A satisfação do usuário só poderá ser atingida se suas necessidades forem
compreendidas.
– Um levantamento de requisitos mal feito pode comprometer o
andamento do projeto.

8
Engenharia de Requisitos

● Estabelece os serviços que o cliente requer de um

sistema e as restrições sob as quais tal sistema operará e
será desenvolvido.
●Tais serviços e restrições são chamados de requisitos.

9
Engenharia de Requisitos

• Processo (Sommerville, 2008)

Elicitação e
Estudo de Especificação de Validação de
análise de
viabilidade requisitos requisitos
requisitos

Gerenciamento de requisitos

10
Estudo de Viabilidade
• Descrição geral do sistema e de como ele será utilizado dentro da
organização.
• Nessa fase, deve ser gerado um relatório indicando se vale a pena
ou não realizar o projeto.
• O documento pode propor ainda mudanças no enfoque, no
orçamento e no cronograma do projeto, e considerar questões
como integração com outros sistemas e escolha de tecnologias
atuais.

11
Viabilidade Técnica
• Questões
– A solução ou a tecnologia proposta é prática?
– Já possuímos a tecnologia necessária?
– Já possuímos o conhecimento técnico necessário?

12
Viabilidade de Cronograma
• Dado nosso conhecimento técnico, os prazos dos projetos são
razoáveis?
– Alguns projetos são iniciados com prazos específicos.
• Você precisa determinar se os prazos são obrigatórios ou desejáveis.
• Se são mais desejáveis que obrigatórios, o analista pode propor outros
cronogramas.

13
Viabilidade Econômica
• Talvez a mais crítica
– Durante as fases iniciais do projeto, a análise da viabilidade
econômica consiste em julgar se os possíveis benefícios de
solucionar o problema são ou não vantajosos.
– Tão logo os requisitos específicos e soluções sejam identificados,
o analista pode levar em consideração os custos e benefícios de
cada alternativa.
• Isso é chamado de análise de custo-benefício.

14
Levantamento e Análise de Requisitos
• Nessa etapa, os membros da equipe técnica de desenvolvimento
trabalham com o cliente e os usuários finais do sistema para
conhecer melhor o domínio da aplicação.

• Stakeholder: qualquer pessoa que tem influência direta ou indireta

sobre os requisitos do sistema.

15
Levantamento e Análise de Requisitos
• Principais desafios
– Lidar com pedidos não realistas (não se tem noção do custo das
solicitações).
– Entender os requisitos na linguagem do negócio (uso de jargões, omissão
de detalhes considerados de conhecimento geral).
– Saber identificar requisitos iguais, apresentados de maneiras distintas
– Lidar com a mudança de stakeholders na empresa.

16
 Comunicação Desenvolvedor X Usuário
Visão dos Desenvolvedores
• Usuários não sabem o que querem
• Usuário pedem sem necessidade
• Usuários não conseguem transmitir
o que eles querem
• Usuários têm muitas necessidades
puramente políticas
• Usuários não sabem priorizar suas
necessidades
Visão dos Usuários
• Desenvolvedores não entendem as
necessidades operacionais
• Desenvolvedores colocam muita
dificuldade em qualquer pequena
solicitação
• Desenvolvedores querem definir o que
os usuários devem fazer
• Desenvolvedores não conseguem
transformar necessidades em um
sistema de sucesso
17
 Comunicação Desenvolvedor X Usuário
Visão dos Desenvolvedores
• Usuários se recusam a ter
responsabilidade pelo sistema
• Usuários não estão
compromissados com o projeto
• Usuários mudam de idéia e não
permanecem dentro do
planejamento
Visão dos Usuários
• Desenvolvedores estão sempre
atrasados
• Desenvolvedores sempre querem
mais tempo e menos esforço
• Desenvolvedores são incapazes de
atender rapidamente as
necessidades de modificação
18
O que é um requisito?
● Pode ser uma descrição abstrata de alto nível de um
serviço, uma restrição de sistema ou até uma
especificação matemática, entre outras coisas.
● O problema cujo desenvolvimento do sistema deve
resolver.
●O sistema tem que ser construído de modo a satisfazer todos os
seus requisitos.

19
Conceitos Importantes

Requisitos
Descrição das funções e restrições para o sistema

---------------------------

Engenharia de Requisitos
Processo de descobrir, analisar, documentar e verificar requisitos

20
Tipos de requisitos
● Requisitos de Usuário
●Declarações de alto nível escritas em linguagem natural.
●Escritos para os clientes.
● Requisitos de Sistema
●Um documento estruturado estabelecendo descrições detalhadas
das funções, serviços e restrições operacionais do sistema.
●Define o que deve ser implementado e pode até ser parte de um
contrato entre o cliente e o desenvolvedor.

21
Leitores de diferente requisitos

22
Requisitos de Usuário
● Requisitos funcionais e não-funcionais descritos de modo a ser
compreensíveis por usuários que não têm conhecimento técnico
detalhado.
● São definidos usando uma linguagem simples, tabelas e diagramas
quando estes podem ser compreendidos por todos os usuários.
● Estórias de usuários são similares a requisitos de usuários.

23
Requisito de Grade de Editor

24
Requisitos de Sistema
● Especificações mais detalhadas das funções do sistema, dos
serviços e das restrições.
● Visam fornecer ser uma base para o desenvolvimento do sistema.
●Em XP: estórias de usuário + tarefas de desenvolvimento
● Eles podem ser incorporados no contrato de sistema.
● Requisitos de sistema podem ser definidos ou ilustrados usando
notações gráficas.

25
EXEMPLO: O Sistema LIBSYS
DESCRIÇÃO DO SISTEMA:
Um sistema de biblioteca que fornece uma interface única para
uma série de banco de dados de artigos em bibliotecas
diferentes. Os usuários podem pesquisar, baixar e imprimir
estes artigos para estudo pessoal.

26
Definições e Especificações
(Requisitos de Usuário x de Sistema)

27
Requisitos Funcionais e Não-funcionais
● Requisitos funcionais
●Serviços que o sistema deve fornecer.
●Como o sistema deve reagir a entradas específicas.
●Como o sistema deve se comportar em determinadas situações.
● Requisitos não-funcionais ou de qualidade
●Restrições sobre serviços ou funções oferecidos pelo sistema tais
como restrições de timing, restrições sobre o processo de
desenvolvimento, padrões, etc.

28
Requisitos Não-funcionais
● Definem propriedades e restrições de sistema.
● Exemplos incluem confiabilidade, tempo de resposta e requisitos de
armazenamento.
● Restrições são capacidade de dispositivos de E/S, representações
de sistema, etc.
● Requisitos de processo podem também ser especificados, impondo
uma linguagem de programação, IDE ou método de desenvolvimento
particular
● Requisitos não-funcionais podem ser mais críticos do que os
requisitos funcionais.

29
Exemplos de Requisitos Não-Funcionais
“O usuário deve ser capaz de pesquisar em todo o conjunto inicial de
banco de dados ou selecionar um subconjunto a partir dele.”

“Para todo pedido deve ser alocado um identificador único

(ORDER_ID) que o usuário possa copiar para a área de
armazenamento permanente da sua conta.”

“O sistema deve fornecer telas apropriadas para o usuário ler os

documentos no repositório de documentos.”
30
Tipos de requisitos não-funcionais

31
Exemplos de requisitos não- funcionais

32
Requisitos Não-Funcionais
• Devido à sua própria definição, requisitos não-funcionais são
esperados mensuráveis.
• Assim, deve-se associar forma de medida/referência a cada
requisito não-funcional elicitado.
• Exemplos de perguntas
– Com que rapidez o sistema deve operar?
– Quanta memória ele requer?
– Qual a taxa aceitável de falhas?
– Qual a linguagem de programação desejada?
– Quando o produto deve ser entregue?
– Como o sistema poderá interagir com os sistemas já existentes?

33
Requisitos de Domínio
• Estão ligados aos requisitos funcionais, mas estão relacionados a
regras do negócio e não aos desejos dos usuários.
• São expressos com o uso de linguagens que são específicas do
domínio da aplicação, dificultando a compreensão por parte do
desenvolvedor.
• Exemplos: Cálculo de multa ou desconto, restrição de um
dependente por cliente em uma locadora

34
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 – tela de propósito especial para cada tipo diferente de
documento;
●Interpretação do desenvolvedor – fornece uma tela de texto que mostra o
conteúdo do documento.

35
36
Requisitos completos e consistentes
Em princípio, requisitos devem ser completos e consistentes.
●COMPLETUDE
●Eles devem incluir descrições de todos os recursos requeridos.
●CONSISTÊNCIA
●Não deve haver conflitos ou contradições nas descrições dos
recursos de sistema.
● Na prática, é impossível produzir um documento de requisitos
completo e consistente.

37
Metas e requisitos
● Requisitos não-funcionais podem ser difíceis de
definir precisamente
●Requisitos imprecisos podem ser difíceis de verificar.
● Meta
●Uma intenção geral do usuário, tal como facilidade de uso.
● Requisito não-funcional verificável
●Uma declaração usando alguma medida que pode ser
objetivamente testada.
● Metas são úteis para desenvolvedores quando
exprimem as intenções dos usuários do sistema.

38
Exemplo

39
Medidas de Requisitos Não-Funcionais

40
Interação de Requisitos
● Conflitos entre os diferentes requisitos não-funcionais
são comuns em sistemas complexos.
EXEMPLO: Sistema de aeronave
●Para minimizar o peso, o número de chips separados no sistema deve ser
minimizado.
●Para minimizar o consumo de energia, chips de baixa potência devem ser
usados.
●E o desempenho pode ser impactado!
●Contudo, o uso de chips de baixa potência pode significar que mais chips
devem ser usados . Qual é o requisito mais crítico?

41
Requisitos e Projeto
● Requisitos devem definir o que o sistema deve fazer e o
projeto deve descrever como ele faz isto.
●Requisitos => problema.
●Projeto => solução.
● Na prática, requisitos e projeto são inseparáveis.
●Uma arquitetura de sistema pode ser projetada para estruturar os requisitos;
●O sistema pode ter que interoperar com outros sistemas que geram novos
requisitos;
●O uso de uma solução de projeto específica pode ser um requisito de
domínio.

42
Diretrizes para escrever requisitos
● Usar um formato padrão para todos os requisitos.
● Usar a linguagem de uma forma consistente.
●‘deve’ para requisitos obrigatórios, e
●‘deveria’ para requisitos desejáveis.
● Realçar o texto para identificar as partes principais do
requisito.
● Evitar o uso de jargões de computação.

43
Problemas com linguagem natural
● Falta de clareza
●É difícil atingir uma precisão sem tornar o documento difícil de ler e
ambíguo.

● Confusão de requisitos
●Requisitos funcionais e não-funcionais tendem a estar misturados.

● Fusão de requisitos
●Vários requisitos diferentes podem ser expressos juntos.

● Dificuldade de estruturar a especificação

44
Alternativas à especificação em linguagem natural

45
Especificações em linguagem estruturada
● A liberdade do elaborador de requisitos é limitada por um
template (modelo) pré-definido para requisitos.
● Todos os requisitos são escritos de maneira padronizada.
● A terminologia usada na descrição pode ser limitada.
● A vantagem é que a maior parte da expressividade da
linguagem natural é mantida
●Mas o grau de uniformidade é imposto na especificação.

46
Especificação Estruturada

47
Especificação Baseada em Formulário
Especificação tabular
● Usada para suplementar a linguagem natural.
● Particularmente útil quando você tem de definir
uma série de possíveis cursos alternativos de ação.

49
Especificação tabular

50
DDR (Documento De Requisitos)
● O documento de requisitos é a declaração oficial do que é
requisitado pelos desenvolvedores do sistema.
●Em XP é um pouco diferente (Estória de Usuário)
● Deve incluir ambos, uma definição dos requisitos de usuário e
uma especificação dos requisitos de sistema.
● NÃO É um documento de projeto.
●Logo que possível, será preciso definir como o sistema deve
fazer, ao invés de o que deve ser feito.

51
(IMPORTANTE) Especificação dos requisitos
• Deve incluir:
– (1) Ambiente físico
• Onde o equipamento funcionará?
• Esse funcionamento se dará em um ou vários locais?
• Existe alguma restrição ambiental, tal como temperatura, umidade ou
interferência magnética?
– (2) Interfaces
• A entrada tem origem em outro ou outros sistemas?
• A saída vai para outro ou outros sistemas?
• Existe uma maneira preestabelecida pela qual os dados devem ser formatados?
• Existe alguma mídia definida, que os dados devem utilizar?

52
(IMPORTANTE) Especificação dos requisitos
• (3) Os usuários e fatores humanos
– Quem utilizará o sistema?
– Haverá diversos tipos de usuários?
– Qual o nível de habilidade de cada tipo de usuário?
– Que tipo de treinamento será necessário para cada tipo de usuário?
– Que facilidade o usuário terá para entender e utilizar o sistema?
– Qual será a dificuldade para que o usuário utilize inadequadamente o sistema?
• (4) Funcionalidade
– O que o sistema realizará?
– Quando o sistema fará?
– Existem diversos modos de operação?
– Como e quando o sistema pode ser modificado ou aprimorado?
– Existem limitações quanto à velocidade de execução, ao tempo de resposta, ou à saída?

53
(IMPORTANTE) Especificação dos requisitos
• (5) Documentação
– Que documentação é necessária?
– Essa documentação deve ser on-line, no formato de livro, ou ambos?
– A que público se destina cada tipo de documentação?
• (6) Dados
– Qual deverá ser o formato dos dados de entrada e saída?
– Com que frequência eles serão enviados ou recebidos?
– Quem precisão devem ter?
– Com que grau de precisão os cálculos devem ser feitos?
– Qual será o fluxo de dados do sistema?
– Existem dados que devem ser mantidos por algum tempo?
• Recursos, segurança e garantia de qualidade...

54
Usuários de um documento de requisitos

55
Validação de Requisitos
• Tarefa difícil
– Como garantir que os requisitos listados representam exatamente o
sistema que o cliente deseja?
• Tarefa importante
– É preciso evitar custos desnecessários e retrabalho (requisitos têm
impacto sobre todo o projeto).

56
Validação de Requisitos
• Técnicas
– Revisões de requisitos
• Inspeções feitas em conjunto pelos membros da equipe técnica e pelos
stakeholders.
– Prototipação
• Uma versão simplificada e provisória do sistema é gerada apenas para dar uma
visão ao cliente.
– Geração de casos de teste
• Requisitos bem definidos podem ser testados.

57