Análise e Modelagem de Sistemas

O processo de engenharia de requisitos

Você sabia que seu material didático é interativo e multimídia? Isso significa que você pode interagir com o conteúdo de diversas formas, a qualquer hora e lugar. Na versão impressa, porém, alguns conteúdos interativos ficam desabilitados. Por essa razão, fique atento: sempre que possível, opte pela versão digital. Bons estudos!


Nesta webaula vamos conhecer os processos da Engenharia de Requisitos, os conceitos, os tipos de requisitos e as atividades que envolvem esses processos.

Engenharia de requisitos

Conforme Sommerville (2011), engenharia de requisitos é o processo de descrever todas as funcionalidades que um sistema deve possuir, bem como descrever todos os serviços e as restrições de seu funcionamento, refletindo diretamente as determinações dos clientes (usuários do software projetado) e contribuindo, de forma significativa, para o desenvolvimento de um produto final com qualidade.

O objetivo da engenharia de requisitos, para Pressman (2016), é proporcionar a todos os envolvidos no desenvolvimento do sistema uma mesma compreensão por escrito do problema; para isso é utilizada uma série de elementos (artefatos) que garante a qualidade do que foi especificado.

Definir os requisitos de um sistema são fundamentais para o sucesso de um software.

O que são os requisitos de um sistema?

Os requisitos de um sistema abrangem a função que o software deve ter, a qualidade que ele deve apresentar, as especificações dos serviços que ele deve oferecer, as restrições que deve possuir, as características gerais e as restrições que devem ser atendidas no seu processo de desenvolvimento.

Os requisitos podem evoluir e podem ser modificados no decorrer do desenvolvimento do software, eles não são estáticos e sofrem atualizações constantes; além disso, devem ser documentados para fins de controle. Paula Filho (2019) destaca os seguintes fatores que contribuem para a evolução dos requisitos:

1. Descobrimento de defeitos e inconformidades nos requisitos originais.

2. Falta de detalhamento nos requisitos originalmente elencados. 

3. Modificações incontornáveis no projeto (por exemplo, alterações de legislação, moedas, impostos). 

Classificação de requisitos

Um fator de destaque na produção de um requisito é determinar a prioridade que ele deve ter. Essa prioridade possui denominações diferenciadas de acordo com a literatura consultada, e cada empresa pode adotar a sua terminologia. Os requisitos são classificados como: essencial, importante ou desejável.

Um requisito classificado como essencial é de extrema importância (é fundamental) para o software ser executado. Sem esse requisito, o software ficará incompleto. O sistema não poderá ser implantado ou concluído caso um requisito essencial não esteja totalmente realizado.

Um requisito classificado como importante deve ser realizado, mas não é essencial para que o software seja implantado. Esse requisito será realizado, mas pode ficar em segundo plano, pois é desejável, porém não imprescindível.

Um requisito classificado como desejável é aquele que não é imprescindível para o software estar concluído, é algo opcional que pode ou não ser realizado e que até pode ser eliminado no decorrer do desenvolvimento do sistema.

Descrição dos requisitos

Na engenharia de requisitos é importante fazer uma distinção dos diferentes tipos de descrições dos requisitos conforme afirma Sommerville (2011).

Requisitos de usuário

Descrevem os requisitos funcionais
e os não funcionais do sistema.

Requisitos de sistema

Especificam detalhes do sistema
(apoiados nos requisitos de usuários). 

Tipos de Requisitos

Determinar o tipo de requisito em um sistema pode ser uma tarefa extenuante, e um requisito pode ser classificado inicialmente como de um tipo e, no decorrer no projeto, pode sofrer alterações e receber outra classificação, podendo gerar, ainda, uma série de novos requisitos.

Os requisitos de um sistema podem ser classificados como:

Determinam de forma clara e precisa as funcionalidades específicas do que o sistema deve ou não realizar. Eles definem os objetivos específicos do sistema, ou seja, o que ele deve possuir ao final de seu desenvolvimento (Sommerville, 2011). Esse tipo de requisito deverá conter todas as funções e informações fornecidas pelo cliente antes da construção do software. Usamos a sigla RF (requisito funcional) seguida de uma numeração para indicar o requisito.

Estabelecem restrições sobre as funcionalidades do sistema, por meio do estabelecimento de padrões específicos de desenvolvimento, plataforma, tempos de resposta e restrições de acessos; estão relacionados às qualidades que o sistema deverá apresentar. Possuem a sigla RFN e especificam critérios para qualificar os funcionais. Esse tipo de requisito aponta para questões relacionadas à qualidade, performance, confiabilidade, usabilidade, implementação, etc. Um requisito não funcional pode gerar uma grande quantidade de requisitos funcionais.

Determinam as características do domínio do sistema, refletindo as características do sistema; podem estabelecer restrições aos requisitos funcionais ou podem indicar cálculos específicos sobre determinado requisito. Eles descrevem as características e estabelecem ressalvas aos requisitos funcionais, indicando, por exemplo, um cálculo obrigatório para o requisito ser validado. Eles podem ser novos requisitos funcionais ou alguma restrição (complementar) de algum requisito funcional.

Atividades do processo

De acordo com Pressman (2016), as atividades do processo da engenharia de requisitos envolvem a coleta de informações sobre o software (sistema) a ser realizado, a análise do problema e, em seguida, a descrição dos requisitos, classificação e priorização, sendo que logo após isso é gerada a especificação desses requisitos.

Fonte: adaptada de Pfleeger (2004) e Sommerville (2011).

Todas as atividades que englobam a engenharia de requisitos possuem como finalidade a produção de um documento de requisitos, como afirmam Sommerville (2011) e Pressman (2016), englobando as seguintes etapas:  

1. Concepção

Determina-se o escopo geral do sistema e todos os envolvidos.

2. Elicitação

Faz-se o levantamento dos requisitos funcionais e não funcionais, utilizando técnicas como entrevistas, observação e pesquisa.

3. Elaboração

Detalha-se cada requisito (levantado e escrito em linguagem natural) para transformá-los em modelos conceituais (UML – Linguagem Unificada de Modelagem), eliminando erros, esquecimentos, duplicidades e inconsistências.

4. Negociação

Identificam-se os requisitos conflitantes, sendo realizada uma negociação entre as partes envolvidas para modificar e/ou eliminar o requisito.

5. Especificação

Transformam-se os requisitos ao se observar a visão do sistema (do desenvolvimento da solução).

6. Validação

Realiza-se a homologação dos requisitos pelos usuários envolvidos, verificando se todos os requisitos foram atendidos (na visão do cliente).

7. Gerenciamento

É a verificação constante (no decorrer dos processos) de que os requisitos estão de acordo com o escopo do projeto e a garantia da rastreabilidade, que é o gerenciamento das eventuais modificações que um requisito pode sofrer.

Os requisitos são a essência de qualquer software. Antes de sair desenvolvendo algum sistema, é necessário criar uma lista de funcionalidades e características que ele deve possuir (esses são os requisitos iniciais), mas não paramos nessa etapa.

Portanto, podemos concluir que o desenho de processos adequado determinará o sucesso do desenvolvimento de sua atividade e, portanto, é necessário focar em uma coleta de dados adequada para que possa atender aos requisitos do cliente de forma satisfatória.

Pesquise mais!

Para colaborar na ampliação de seus conhecimentos a respeito dos requisitos de um sistema, consulte o capítulo Requisitos, seção 1.11 até 1.3.9, do livro Engenharia de software, de Wilson de Pádua Paula Filho. Na seção indicada é apresentada uma visão complementar sobre os requisitos de um sistema, observando sempre a qualidade dos requisitos. Disponível na biblioteca virtual.

PAULA FILHO, W. P. Engenharia de software. 4. ed. Rio de Janeiro: Editora LTC, 2019. p. 101-109.

Bons estudos!

AVALIE ESTE MATERIAL

OBRIGADO PELO SEU FEEDBACK!