Engenharia de Requisitos

 O processo de descobrir, analisar, documentar e verificar esses serviços

e restrições.
 O termo ‘requisito’ não é usado de forma consistente pela indústria de
software.
 Em alguns casos, o requisito é apenas uma declaração abstrata em alto
nível de um serviço que o sistema deve oferecer ou uma restrição a um
sistema.
 No outro extremo, é uma definição detalhada e formal de uma função
do sistema. (Sommerville, 2011).
Requisitos
 Essas diferenças existem porquê ?
“ Se uma empresa pretende fechar um contrato para um projeto de
desenvolvimento de software de grande porte, deve definir as necessidades
de forma abstrata o suficiente para que a solução para essas necessidades
não seja predefinida.
Os requisitos precisam ser escritos de modo que vários contratantes possam
concorrer pelo contrato e oferecer diferentes maneiras de atender às
necessidades da organização do cliente.
Uma vez que o contrato tenha sido adjudicado, o contratante deve escrever
para o cliente uma definição mais detalhada do sistema, para que este
entenda e possa validar o que o software fará. Ambos os documentos podem
ser chamados documentos de requisitos para o sistema.” (Sommerville, 2011).
 Para Pensar !

“ A parte mais difícil para construir um

sistema de software é decidir o que
construir. Nenhuma outra parte do trabalho
conceitual é tão difícil como o
estabelecimento dos requisitos técnicos
detalhados.
Nenhuma outra parte do trabalho mutila o
sistema resultante se for feita errada.
Nenhuma outra parte é tão difícil de corrigir
depois.”
(Frederick Brooks, engenheiro de software
responsável pelo OS/360 -mainframe da IBM).
Autor do Livro The Mythical Man-Month.
 “Bugs”

Observação: Custo para correção de um “bug” aumenta com o andar do projeto além de aumentar a dificuldade
e a maioria dos problemas ocorrem por problemas na especificação.
Fonte das Figuras: https://www.interaktiv.com.br/blog/post/o-custo-efetivo-dos-bugs-no-desenvolvimento-de-softwares
Visão Tradicional
 Visão ‘tradicional’ de requisitos e não de requisitos em processos ágeis.
 Para sistemas de grande porte, ainda é o caso de existir uma fase da
engenharia de requisitos antes de se iniciar a implementação do
sistema.
 O resultado é um documento de requisitos, que pode ser parte do
contrato de desenvolvimento do sistema.
 Certamente, haverá mudanças nos requisitos e os requisitos de
usuário(alto nível) poderão ser ampliados em requisitos de sistema
mais detalhados (baixo nível).
Exemplo
Tipos de Requisitos
 Requisitos Funcionais (RF) x Requisitos Não Funcionais (RNF)
 Na prática, no documento de requisitos, é difícil separar os requisitos
funcionais dos não funcionais. Se são apresentados separadamente, os
relacionamentos entre eles podem ficar difíceis de serem entendidos.
 Além disso, o custo de verificar RNF pode ser muito elevado, e os
clientes, que pagam pelo sistema, podem não achar que os custos
sejam justificados.
Métricas RNF

(Sommerville, 2011)
Documento de Requisitos
 O documento de requisitos de software, às vezes chamado
Especificação de Requisitos de Software (SRS — do inglês Software
Requirements Specification).
 É uma declaração oficial de o que os desenvolvedores do sistema
devem implementar. Deve incluir tanto os requisitos de usuário quanto
uma especificação detalhada dos requisitos de sistema.
 Em alguns casos, os requisitos de usuário e de sistema são integrados
em uma única descrição.
 Para pensar !!!
 Documentos de requisitos são essenciais quando um contratante externo está desenvolvendo o sistema de
software.
 Método ágeis pregam que requisitos mudam tão rapidamente que um documento de requisitos já está
ultrapassado assim que termina de ser escrito.
 O esforço é desperdiçado. Em vez de um documento formal, abordagens como a Extreme Programming
(BECK, 1999) coletam os requisitos de usuário em cartões como estórias de usuário.
 O usuário então prioriza os requisitos. Essa é uma boa abordagem para os sistemas de negócio em que os
requisitos são instáveis.
 No entanto, desse ser avaliado se ainda é útil escrever um pequeno documento de apoio no qual estejam
definidos os requisitos de negócio e de confiança(RNF) para o sistema.
 Quando o foco está nos requisitos funcionais dos próximos releases do sistema, é fácil nos esquecermos dos
requisitos que se aplicam ao sistema como um todo (RNF).

Requisitos do Negócio descrevem em termos

do negócio o que deve ser entregue ou
conseguido para fornecer valor.
 Questão
Ano: 2016 Banca: CESPE Órgão: FUB Prova: CESPE - 2016 - FUB - Técnico de
Tecnologia da Informação
Acerca dos conceitos de análise e projeto de sistemas em engenharia
de software, julgue o item subsequente:
Na atividade de levantamento de requisitos, as características de
qualidade que o sistema deve possuir e que estão relacionadas às suas
funcionalidades são denominadas requisitos funcionais.

ERRADO
 Questão
Ano: 2019 Banca: IADES Órgão: CRF-TO Prova: IADES - 2019 - CRF-TO - Analista de TI
Em um documento de engenharia de requisitos, são descritos cinco tipos de usuários.
Considere a definição a seguir:

Usam os requisitos para entender o sistema e os relacionamentos entre suas partes.

SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Education, 2011.

A definição apresentada se refere a qual tipo de usuário de um documento de

engenharia de requisitos:

a) Engenheiros de teste de sistema

b) Gerentes
c) Clientes do sistema
d) Engenheiros de sistema
e) Engenheiros de manutenção de sistema
LETRA E