Você está na página 1de 28

ENGENHARIA DE REQUISITOS

Professor: Amadeu Anderlin Neto


amadeu.neto@ifam.edu.br
IMPORTÂNCIA DOS REQUISITOS DE SOFTWARE
 Estudo feito com 350 companhias e 8000 projetos de software
 Definidas 3 categorias de projetos:
 Sucesso (16,2%): cobre todas as funcionalidades, dentro do prazo e
custo previsto
 Problemático (52,7%): não cobre todas as funcionalidades, custo
aumentou e com atraso
 Fracasso (31,1%): cancelado durante o desenvolvimento

2
IMPORTÂNCIA DOS REQUISITOS DE SOFTWARE

Requisitos envolvidos na maioria das causas!


3
CUSTO DE DEFEITOS
 Segundo Boehm e Papaccio (Pfleeger, 2004), o custo relativo
para o conserto de um problema de requisitos em cada fase de
desenvolvimento de sistema, em relação a cada dólar investido,
comumente é:
 $1 na fase de análise de requisitos
 Até $5 na fase de projeto do sistema
 Até $10 na fase de codificação
 Até $20 na fase de teste de unidade
 Até $200 após a entrega do sistema
4
CENÁRIO ATUAL DE DESENVOLVIMENTO

 Gasta-se cada vez mais em testes e manutenção de sistemas


 85% dos erros são causados por defeitos inseridos na análise
de requisitos e projeto do sistema 5
DESAFIOS NO DESENVOLVIMENTO DE SISTEMAS
 Compreensão do domínio do problema
 Comunicação efetiva com reais usuários do sistema
 Evolução contínua dos requisitos do sistema
 Especificação de requisitos é importante porque:
 Estabelece uma base de concordância entre o cliente e o fornecedor
sobre o que o software fará
 Fornece uma referência para a validação do produto final
 Reduz o custo de desenvolvimento
6
O QUE É ENGENHARIA DE REQUISITOS?
 Processo em que os requisitos de um produto de software são
coletados, analisados, documentados e gerenciados
A Engenharia de Requisitos é realizada em todo o ciclo de vida
do software
 Requisitospossuem um papel fundamental no desenvolvimento
de software
 Se os requisitos não forem atendidos, o projeto é considerado um
fracasso!
7
O QUE É UM REQUISITO?
 Disciplinas do curso de Engenharia de Software

Lógica de Estrutura de Estrutura de


Programação Dados I Dados II

 Requisitos para concorrer ao cargo de Presidente da República


Ter idade Pleno exercício
Ser brasileiro
superior a 35 dos direitos
nato
anos políticos

Requisito é uma condição ou exigência 8

indispensável para um fim determinado


REQUISITO DE SOFTWARE
 Um requisito é uma característica do sistema ou a descrição de
algo que o sistema é capaz de realizar para atingir seus objetivos
(Pfleeger, 2004)
 Requisitossão descrições das funções do sistema e suas
restrições operacionais (Sommerville, 2015)
 Condição ou capacidade com a qual o sistema deve estar de
acordo
 Funções que o sistema deve incorporar e restrições que devem
ser satisfeitas 9
TIPOS DE REQUISITOS:
QUANTO AO NÍVEL DE ABSTRAÇÃO

10
TIPOS DE REQUISITOS:
QUANTO AO NÍVEL DE ABSTRAÇÃO
 Requisitos de Usuário: descrições de quais serviços o sistema
deve fornecer e as restrições sob as quais deve operar
 Alto nível de abstração, ou seja, poucos detalhes
 Podem ser lidos por pessoas leigas
 Podem ser funcionais ou não funcionais
 Em geral, trata do domínio do problema – o mundo do usuário

 Exemplos:
 O sistema deve ser rápido
 O sistema deve gerar um relatório
11
TIPOS DE REQUISITOS:
QUANTO AO NÍVEL DE ABSTRAÇÃO
 Requisitos de Sistema: descrições detalhadas sobre as funções,
operações e restrições de sistema que definem exatamente o que
deve ser implementado
 Baixo nível de abstração, ou seja, muitos detalhes
 Podem ser lidos por pessoas experientes
 Podem ser funcionais ou não funcionais
 Em geral, trata do domínio da solução – o mundo do software

 Exemplos:
 O sistema deve responder em menos de 0.2ms com 200Mb de memória
 O sistema deve gerar um relatório interativo com índices e views
materializadas 12
TIPOS DE REQUISITOS:
QUANTO À QUALIDADE
 Requisitos normais: refletem os objetivos e metas
estabelecidos para um produto ou sistema durante reuniões com
o cliente. Se esses requisitos estiverem presentes, o cliente fica
satisfeito
 Requisitosesperados: estão implícitos no produto ou sistema.
Podem ser tão fundamentais que o cliente não os declara
explicitamente. Sua ausência será causa de grande insatisfação
 Requisitos fascinantes: vão além da expectativa dos
clientes e demonstram ser muito satisfatórios quando presentes
13
TIPOS DE REQUISITOS:
QUANTO À EVOLUÇÃO
 Requisitos permanentes (ou estáveis): diretamente ligados
à atividade principal da organização. São concebidos com a
essência de um sistema e seu domínio da aplicação. Mudam
mais lentamente que requisitos voláteis
 Requisitos voláteis (ou instáveis): específicos para a
instanciação de um sistema em um ambiente ou um cliente
particular. São mais propensos a mudança. Se modificam
quando o sistema está em desenvolvimento ou em uso. Podem
ser: mutáveis, emergentes, consequentes, de compatibilidade
14
TIPOS DE REQUISITOS:
QUANTO À EVOLUÇÃO
 Requisitos mutáveis: são os requisitos que se modificam em
função de mudanças no ambiente no qual o sistema opera
 Exemplo: os requisitos de um sistema que calcula taxas de dedução
que evoluem conforme as leis fiscais são atualizadas (muito comum no
Brasil)

 Requisitos emergentes: requisitos que não podem ser


completamente definidos quando o sistema é especificado e
emergem à medida que a compreensão do cliente sobre o
sistema se desenvolve. Em geral, só aparecerão durante o
desenvolvimento 15
TIPOS DE REQUISITOS:
QUANTO À EVOLUÇÃO
 Requisitos consequentes: são requisitos baseados em
suposições de como o sistema será utilizado no ambiente do
usuário. O usuário percebe as necessidades enquanto utiliza o
sistema e esses requisitos são uma consequência do uso
 Requisitos de compatibilidade: são os requisitos que
dependem de outro equipamento, processo, componente ou
elemento. Conforme outros elementos mudam, esses requisitos
também mudam

16
TIPOS DE REQUISITOS:
QUANTO À FUNCIONALIDADE
 Requisitos funcionais: ligados diretamente às funcionalidades
do sistema
 Descrevem as funções que o sistema deve executar
 Descrevem uma interação entre o sistema e seu ambiente
 Exemplo: o sistema deve permitir que o administrador emita um
relatório com os resultados dos testes clínicos de um paciente

 Regra de formação (boa prática):


 [ID] O software deve permitir que o [responsável pela ação] [ação]
 Exemplo: [RF1] O software deve permitir que o setor financeiro libere
o pagamento dos funcionários 17
TIPOS DE REQUISITOS:
QUANTO À FUNCIONALIDADE
 Problemas de requisitos funcionais:
 Ambiguidade
 Incompletude
 Inconsistência

18
TIPOS DE REQUISITOS:
QUANTO À FUNCIONALIDADE
 Requisitos não-funcionais: requisitos que expressam condições que
o software deve atender ou qualidades específicas que o software deve
ter
 Em vez de informar o que o sistema fará, os requisitos não-funcionais
colocam restrições no sistema
 Definem propriedades e restrições do sistema (tempo, espaço, etc.)
 Requisitos não-funcionais podem ser mais críticos que requisitos
funcionais
 Não satisfaz, sistema inútil

 Exemplo: as consultas ao sistema devem ser respondidas em


menos de três segundos 19
TIPOS DE REQUISITOS:
QUANTO À FUNCIONALIDADE
 Requisitos não-funcionais devem ser mensuráveis e
verificáveis
 Deve-se associar forma de medida a cada requisito não-funcional
Propriedade Medida
Velocidade Transações por segundo
Tempo de resposta
Tamanho Bytes ocupados em disco
Bytes ocupados na RAM
Facilidade de uso Tempo de treinamento
Confiabilidade Tempo médio entre falhas 20

Robustez Tempo de reinício após falha


TIPOS DE REQUISITOS:
QUANTO À FUNCIONALIDADE
 Algumas palavras levam a requisitos impossíveis de serem
verificados
Palavras não- Possíveis substitutos
verificáveis
Amigável Número máximo de passos
Lista de funcionalidades presentes em outras aplicações
Portável Requisitos mínimos de hardware
Sistemas operacionais em que deve funcionar
Pequeno Dimensões aceitáveis (em Bytes)
Flexível Variáveis que acomodam uma gama de mudanças de
valores 21
TIPOS DE REQUISITOS:
QUANTO À FUNCIONALIDADE
 Problemas de requisitos não-funcionais:
 Difíceis de especificar objetivamente
 Conflito entre requisitos. Exemplo: alto desempenho com baixo custo

22
CLASSIFICAÇÃO DE REQUISITOS NÃO-FUNCIONAIS
 Requisitos do Produto: especificam o comportamento ou
características desejáveis de um determinado produto
 Requisitos do produto são divididos em:
 Requisitos de usabilidade
 Requisitos de confiabilidade
 Requisitos de proteção
 Requisitos de desempenho
 Requisitos de eficiência
23
 Requisitos de armazenamento
CLASSIFICAÇÃO DE REQUISITOS NÃO-FUNCIONAIS
 Requisitos Organizacionais: derivados de políticas e
procedimentos da organização do cliente e do desenvolvedor
 Requisitos Organizacionais são divididos em:
 Requisitos ambientais
 Requisitos de implementação
 Requisitos operacionais

24
CLASSIFICAÇÃO DE REQUISITOS NÃO-FUNCIONAIS
 Requisitos Externos: abrange todos os requisitos derivados de
fatores externos ao sistema e seu processo de desenvolvimento
 Requisitos Externos são divididos em:
 Requisitos regulatórios
 Requisitos de contabilidade
 Requisitos éticos
 Requisitos legais
 Requisitos de segurança
25
TIPOS DE REQUISITOS:
QUANTO À FUNCIONALIDADE
 Requisitos de Domínio (ou Regra de Negócio): derivados do
domínio da aplicação
 Descrevem características do sistema e qualidades que refletem o
domínio
 Ajudam a detalhar requisitos funcionais novos, restrições sobre
requisitos existentes, ou computações específicas
 Serequisitos de domínio não forem satisfeitos, o sistema pode
não ser útil
26
TIPOS DE REQUISITOS:
QUANTO À FUNCIONALIDADE
 Problemas de requisitos de domínio:
 Entendimento
 Requisitos são descritos na linguagem do domínio da aplicação
 Não é entendido pelos engenheiros de software que vão desenvolver a
aplicação
 Implicitude
 Especialistas no domínio entendem a área tão bem que não tornam todos os
requisitos de domínio explícitos

27
ENGENHARIA DE REQUISITOS

Professor: Amadeu Anderlin Neto


amadeu.neto@ifam.edu.br

Você também pode gostar