Fundamentos da

Engenharia de
Requisitos
Prof. Ernesto Veiga
ernestoveiga@ufg.br
Imaginemos situações como estas...
Imaginemos situações como estas...
Defeitos x Custos
Desenvolvimento de Software
 Definições de Requisitos
PROPRIEDADE QUE DEVE SER
DEMONSTRADA PARA RESOLVER
EXIGÊNCIA RELACIONADA AO
ALGUM PROBLEMA DO MUNDO REAL
SOFTWARE, NA PERSPECTIVA DE

ALGUMA PARTE INTERESSADA

(STAKEHOLDER)

CONDIÇÃO NECESSÁRIA PARA

ALCANÇAR UM CERTO OBJETIVO

NECESSIDADE OU RESTRIÇÃO
IMPOSTA AO SOFTWARE OU AO
PROCESSO DE SOFTWARE

 CLASSIFICAÇÃO DE REQUISITOS PELO

QUE DESCREVEM

1. 1. Do usuário
1. Funcionais ->
1.2. Do sistema
Requisitos ->
2. Não funcionais

* existem outras classificações...

 REQUISITOS FUNCIONAIS (RF)
Descrevem as funcionalidades ou serviços
Dependem do tipo de software, dos usuários esperados e do tipo de
sistema onde o software será usado

Podem descrever em alto nível (geralmente em linguagem natural e/ou

diagramas) o que o sistema deve fazer - requisitos funcionais de usuário*
Podem descrever os serviços do software em detalhes - requisitos
funcionais de sistema*

*Nomenclatura adotada por Sommerville

 EXEMPLOS REQUISITOS FUNCIONAIS
RF1 - O sistema deve permitir que o administrador cadastre funcionários
com os seguintes dados: CPF, nome, email e telefone. O cadastro de
funcionário não deve se repetir.

RF2 - O sistema deve permitir que o administrador atribua um cargo a um

funcionário. (tipos de cargos: assistente, supervisor, gerente, diretor)

RF3 - O sistema deve permitir que o administrador exclua um funcionário.

Para ser excluído, o funcionário não pode ter nenhum cargo atribuído a ele.
REQUISITOS NÃO FUNCIONAIS (RNF)

Define uma propriedade que o software deve apresentar ou é uma restrição ao

software. Ex: confiabilidade, tempo de resposta, armazenamento, capacidade
de dispositivos de E/S, representações de dados na interface com o usuário.

Podem ser mais críticos do que os requisitos funcionais.

Se não forem atendidos, pode tornar o software inútil.

TIPOS DE REQUISITOS NÃO FUNCIONAIS
 EXEMPLOS DE REQUISITOS NÃO FUNCIONAIS
RNF1 - O banco de dados de estoque deve ser atualizado em tempo real
(Produto - Eficiência - Desempenho)
RNF2 - O executável do sistema não pode ser superior a 512 Kbytes
(Produto - Eficiência - Espaço)
RNF3 - O sistema deve funcionar em dispositivos móveis com iOS e Android (Produto
- Portabilidade)
RNF4 - O sistema deve emitir o relatório de progresso [RF1] a cada duas semanas
(Organizacionais - De Entrega)
RNF5 - O sistema deve salvar os arquivos nos formatos do Word, RTF e HTML
(Organizacionais - De Implementação)
RNF6 - O sistema deve obedecer ao padrão estabelecido para emissão de NFE
(Organizacionais - De Padrões)
RNF7 - O sistema deverá se comunicar com o serviço de consultas de CEP
(Externos - Interoperabilidade)
 QUEM LÊ OS REQUISITOS?
CLIENTE DO SISTEMA Para ver se atendem suas necessidades
Para planejar uma proposta para o
GERENTES
desenvolvimento do sistema

ENGENHEIROS DO Para compreender o sistema que será

SISTEMA desenvolvido

ENGENHEIROS DE Para efetuar os testes de validação

TESTES

ENGENHEIROS DE Para compreender e ajustar a relação entre

MANUTENÇÃO as suas partes
 PROPRIEDADES DOS REQUISITOS
Identidade: para gerenciar a configuração do software. Identificar
os requisitos com um ID único.
Ex: RF01, RNF01, HU01

Prioridade: é muito importante saber a prioridade do requisito.

Ex: 1, 2, 3 e 4; Baixa, Média e Alta; Desejado, Importante e Urgente

Status: para monitorar o progresso.

Ex: em análise, aprovado, alocado, implementado, testado,
planejado, cancelado
 REQUISITOS COMO HISTÓRIAS DE USUÁRIO
User Story é a menor unidade de trabalho com base na necessidade do cliente final que
vai usar/interagir com o Produto.
O objetivo é expressar, em poucas palavras, as necessidades, propor critérios mínimos
para aceitação e o valor de negócio agregado de uma forma clara, limpa e leve
Comumente usada em Métodos Ágeis
Formato padrão:
Como uma <função>
Eu quero <objetivo / desejo>
Para que <benefício>

Deve conter apenas informações suficientes para os desenvolvedores

produzirem estimativa razoável de esforço para implementá-la.
Antes que uma história de usuário seja implementada, um
procedimento de aceitação apropriado deve ser escrito.
REQUISITOS COMO HISTÓRIAS
DE USUÁRIO

Como administrador
Eu quero cadastrar funcionários
com CPF, nome, email e telefone
Para gerenciar os funcionários
REQUISITOS COMO HISTÓRIAS
DE USUÁRIO

Como administrador
Eu quero atribuir um cargo a um
funcionário
Para gerenciar os cargos e
funções dos funcionários
REQUISITOS COMO HISTÓRIAS
DE USUÁRIO

Como administrador
Eu quero excluir um funcionário
Para manter o cadastro dos
funcionários atualizados
 ATIVIDADE

Mapa Mental sobre Fundamentos de Engenharia de

Requisitos.

1
Referência SWEBOK: Cap. 1 Sec.

Data de entrega: 24/05/2023 até 20h30 pelo SIGAA.

DÚVIDAS?