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: [Link]
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
