Engenharia de Software – Engenharia de

Requisitos
Prof. Washington Almeida, MSC, ISF 27002
 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).
3
 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).

4
 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.
5
 “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. 6
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).
7
Exemplo

8
 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.

9
Métricas RNF

(Sommerville, 2011)
10
 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.

11
 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.
12
13
 Questão 1
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

14
 Questão 2
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
15
 Continua...
• Atividades do Processo de
Engenharia de Requisitos
• Técnicas de Levantamento de
Requisitos
• Gerenciamento de Requisitos
• Outros tópicos relevantes

16
 Gabarito

Questão Resposta
1 ERRADO

2 E

17
 Referências
• PRESSMAN, Roger S. ; Bruce R. Maxim. Engenharia de Software, Uma Abordagem Profissional, 8° ed.
Porto Alegre: AMGH, 2016. ISBN 978-85-8055- 533-2.
• SOMMERVILLE, Ian. Engenharia de Software, 9. ed. São Paulo: Pearson Prentice Hall, 2011. ISBN 978-
85-7936-108-1.

18