REQUISITOS DE SOFTWARE

Objetivo da Aula

✓ Identificar e diferenciar os requisitos Funcionais e os

Requisitos Não Funcionais
✓ Entender a importância do FURPS+ : Classificação de
Requisitos;
✓ Descobrir a importância dos Requisitos para a Arquitetura
do Software
✓ Saber os critérios básicos para se fazer uma elicitação de
requisitos
 Re q u i s i to s d e S o f t wa re s

O Que São Requisitos?

• Uma condição ou capacidade necessitada por
um usuário para resolver um problema ou
atingir um objetivo (IEEE).

• Uma condição ou capacidade que deve ser

cumprida ou possuída por um sistema ou
componente do sistema para satisfazer um
contrato, padrão, especificação ou outro
documento formal imposto (IEEE).
 Re q u i s i to s d e S o f t wa re s

O Que São Requisitos?

• Características que definem os critérios de

aceitação de um produto (Wilson de Pádua).

• Propriedade que um software deve exibir para

resolver um problema do mundo real
(SWEBOK).
 Re q u i s i to s d e S o f t wa re s

O Que São Requisitos?

Re q u i s i to s d e S o f t wa re s
 E n ge n h a r i a d e Re q u i s i to s

• Uma boa engenharia de requisitos é um passo essencial

para o desenvolvimento de um bom produto.

• Requisitos bem entendidos e gerenciados, reduzem

riscos na construção de um sistema de software.
 E n ge n h a r i a d e Re q u i s i to s

Uma boa especificação de requisitos deve ser:

✓Clara e não-ambígua
✓Completa
✓Correta
✓Compreensível
✓Consistente
✓Concisa
✓Confiável
 E n ge n h a r i a d e Re q u i s i to s

Vamos olhar esse cenário

 E n ge n h a r i a d e Re q u i s i to s

Onde pode dar errado?

 E n ge n h a r i a d e Re q u i s i to s

Onde pode dar errado?

 E n ge n h a r i a d e Re q u i s i to s

Onde pode dar errado?

 E n ge n h a r i a d e Re q u i s i to s

Onde pode dar errado?

 E n ge n h a r i a d e Re q u i s i to s

Onde pode dar errado?

 P r i n c í p i o s d a E n ge n h a r i a d e Re q u i s i to s

• Boas especificações de requisitos são indispensáveis.

• Não representam custos supérfluos:
mas investimentos necessários.
• A participação dos usuários é fundamental:
para que suas verdadeiras necessidades sejam atendidas.
• Uma boa especificação de requisitos;
custa tempo e dinheiro.
• A ausência de uma boa especificação de requisitos;
custa muito mais tempo e dinheiro
 Fa l h a s d e Re q u i s i to s

As falhas em requisitos estão entre as principais razões para o

fracasso de um software. Entre as principais razões destacam-se
os:
✓Requisitos mal organizados;
✓Requisitos mal expressos/identificados;
✓Requisitos desnecessários para os clientes e;
✓A dificuldade para lidar com requisitos frequentemente
mutáveis.
Fa l h a s d e Re q u i s i to s
 C o m o t rata r o s Re q u i s i to s

• Um sistema deve ter a capacidade de atender aos seus

requisitos.
• Nosso problema é entender o problema do usuário dentro da
sua cultura, linguagem e construir sistemas que venham de
encontro às suas necessidades.
• Característica é um serviço que o sistema fornece a fim de
atender as necessidades dos usuários
• O diagrama de Casos de Uso descrevem a sequência de ações,
executados por um sistema, que resultam em valores para o
usuário.
C o m o t rata r o s Re q u i s i to s
 Re q u i s i to s F u n c i o n a i s

• Especificam ações que um sistema deve

executar, sem levar em consideração
restrições físicas.

• Dão origem a
casos de uso.
 Re q u i s i to s F u n c i o n a i s

Exemplo de Requisito Funcional

O Gerente deverá visualizar todos os
empréstimos efetuados no mês, indicando o
funcionário que disponibilizou o empréstimo, o
cliente que obteve o empréstimo e o valor
emprestado.
 Re q u i s i to s N ÃO F u n c i o n a i s

• Descrevem restrições desejadas ou necessárias, atributos do

sistema ou de seu ambiente.

• São também chamados de restrições ou

requisitos de qualidade.

• Determinam a arquitetura do sistema.

• Caso os requisitos não funcionais não forem satisfeitos o sistema

fica sem utilidade.
 Re q u i s i to s N ÃO F u n c i o n a i s

Exemplo de Requisito Não Funcional

• O fechamento contábil do mês deverá ser

realizado em no máximo 4h para um volume
de até 40 milhões de registros.

• O sistema deverá suportar dois idiomas:

português e espanhol.
 C ate go r i a s d o s Re q u i s i to s N ÃO F u n c i o n a i s

• Confiabilidade, usabilidade, desempenho, suporte,

desenho, físico, implementação,
interface, segurança, entre outros.

• Categorias apoiam a identificação de requisitos não

funcionais.
 Re q u i s i to s N ÃO F u n c i o n a i s

FURPS+ : Classificação de Requisitos

• Funcionalidade (Functionality);

• Usabilidade (Usability);

• Confiabilidade (Reliability);

• Desempenho (Performance);

• Suportabilidade (Supportability).
 E l i c i ta ç ã o d o s Re q u i s i to s

ELICITAR: descobrir, tornar explícito, obter o máximo de

informações para o conhecimento do objeto em questão

Cabe à elicitação a tarefa de identificar os fatos

relacionados aos requisitos do Sistema, de forma a prover
o mais correto e o mais completo entendimento do que é
demandado daquele software
 E l i c i ta ç ã o d o s Re q u i s i to s

A elicitação de requisitos visa identificar e descrever os

requisitos de um software a ser desenvolvido. O processo
para a elicitação de requisitos prevê primeiramente a
identificação dos objetivos gerais do software,
informações sobre os problemas atuais existentes e por
fim as necessidades que devem ser endereçadas pelo
software.
E l i c i ta ç ã o d o s Re q u i s i to s
 At i v i d a d e s d a E l i c i ta ç ã o d o s Re q u i s i to s
✓ Entendimento do domínio da aplicação
– O conhecimento do domínio da aplicação é o conhecimento geral onde
o sistema será aplicado.
✓ Entendimento do problema
– Os detalhes dos problemas específicos do problema do cliente onde o
sistema será aplicado deve ser entendido.
✓ Entendimento do negócio
– Entender como os sistemas interagem e contribuem de forma geral com
os objetivos de negócio.
✓ Entendimento das necessidades e limitações dos stakeholders do
sistema
– Entender, em detalhe, as necessidades específicas das pessoas que
requerem suporte do sistema no seu trabalho.
N e go c i a ç ã o d o s Re q u i s i to s
 R a st re a b i l i d a d e d o s Re q u i s i to s
Um requisito é rastreável se:
✓ é possível identificar quais são as partes do produto que existem
por causa dele:
rastreabilidade para frente.
✓ para qualquer parte do produto;
✓ é possível identificar o requisito que causou sua existência:
rastreabilidade para trás
Através da rastreabilidade é possível identificar:
✓ os relacionamentos entre os requisitos;
✓ suas fontes;
✓ os artefatos criados durante o ciclo de vida do sistema;
que são derivados do requisito.
 R a st re a b i l i d a d e d o s Re q u i s i to s

Por quê Rastrear?

✓ Auxiliar a gerência do projeto:
acompanhando a evolução dos requisitos;
registrando sua situação.
✓ Auxiliar a gerência de mudanças:
acompanhando como a alteração nos requisitos;
pode impactar em mudanças nos diversos artefatos
do projeto.
✓ Garantir a qualidade
R a st re a b i l i d a d e d o s Re q u i s i to s
R a st re a b i l i d a d e d o s Re q u i s i to s
Fim