Estudando Engenharia de Requisitos para Concursos – Parte 1

Vamos saber mais sobre a Engenharia de requisitos?

A ideia dessa serie de postagens no blog do Gran é trazer os assuntos mais cobrados na área de Engenharia de Requisitos. Vamos iniciar nossos estudos com a definição do que é um requisito, de acordo com Sommerville:

Requisitos de um sistema são aquilo que o sistema faz: os serviços oferecidos e as restrições para sua operação. Os requisitos devem refletir as necessidades do usuário, o qual deseja um software que vai servir para determinado propósito.

Precisamos saber também a diferença entre requisitos funcionais e não funcionais. Trazendo as definições de Sommerville:

1. Requisitos funcionais: Apresentam descrições dos serviços que devem ser oferecidos, do modo como o software deve reagir a determinadas entradas e de como o sistema deve se comportar em determinadas situações. Em alguns casos, os requisitos funcionais podem explicitar o que o sistema não deve fazer (Requisitos inversos).
2. Requisitos não funcionais: São restrições aos serviços e funções do sistema. Inclui nessa definição as restrições de tempo, as relacionadas ao processo de desenvolvimento e as decorrentes da utilização de padrões. Requisitos não funcionais podem ser aplicados ao sistema como um todo ou a determinada funcionalidade do sistema.

Só que conhecer os requisitos funcionais e não funcionais não é suficiente para chegar na sua prova. Precisamos também estudar as diversas classificações de requisitos vistas na literatura. Vamos ver na sequência!

Os requisitos de domínio são apresentados por Sommerville como sendo derivados do domínio da aplicação do sistema. Eles podem se constituir de novos requisitos funcionais, restrições a requisitos funcionais (requisitos não funcionais) ou definir como uma computação deve ocorrer (também requisitos funcionais).

Além dos requisitos de domínio, também temos os Requisitos Estáveis (ou Permanentes), que são concebidos como a essência de um sistema e seu domínio da aplicação, mudando mais lentamente que os requisitos voláteis.

Os Requisitos Voláteis são específicos para a instanciação de um sistema em um ambiente particular e para um cliente particular. Caracterizam-se pela modificação ao longo do desenvolvimento (ou quando o sistema já está em uso).

Eles podem ser classificados em quatro tipos:

• Requisitos mutáveis: São os requisitos que mudam em função de mudanças no ambiente no qual o sistema opera. Por exemplo, os requisitos para um sistema que calcula taxas de dedução, o qual evolui conforme as leis de taxação mudam.
• Requisitos emergentes: São os requisitos que não podem ser completamente definidos quando o sistema é especificado, “emergindo” quando o sistema está sendo projetado e implementado. Por exemplo, pode não ser possível especificar de antemão os detalhes de como a informação será exibida pelo sistema. Conforme os stakeholders veem exemplos de apresentações possíveis (nossos famosos protótipos), podem ser pensadas novas maneiras de exibição da informação mais úteis ao negócio.
• Requisitos consequentes: São os requisitos baseados em suposições de como o sistema será utilizado. Quando o sistema é posto em uso, algumas destas suposições podem estar erradas. Usuários irão se adaptar ao sistema e encontrar novas maneiras de usar suas funcionalidades, o que irá resultar em demandas dos usuários para mudanças no sistema. Ou seja, são requisitos que aparecem como consequência da operação do sistema.
• Requisitos de compatibilidade: São os requisitos que dependem de outro equipamento ou processo. Conforme muda esse equipamento (ou processo), os requisitos também mudam.

Continuando, segundo Sommerville, os requisitos de usuário descrevem as funções e restrições do sistema de forma abstrata, tendo como premissa a capacidade de entendimento pelo usuário / cliente. São levantados tendo como ponto de vista as necessidades da empresa e não indicam uma solução tecnológica. São escritos em linguagem natural com diagramas simples (ex. tabelas).

Já os requisitos do sistema são descrições mais detalhadas das funções, serviços e restrições operacionais do sistema de software, devendo ser padronizados, completos e consistentes. São usados pela equipe de desenvolvimento e fazem parte do contrato.

Além desse monte de classificação de requisitos, uma outra coisa que você deve ter em mente é a Implantação da Função de Qualidade (IFQ), em inglês Quality Function Deployment (QFD), técnica que traduz as necessidades do cliente para requisitos técnicos do software. A IFQ concentra-se em maximizar a satisfação do cliente a partir do processo de engenharia de software.

Para conseguir isso, a IFQ enfatiza o entendimento do que tem valor para o cliente e depois implanta esses valores por meio do processo de engenharia.

A IFQ identifica três tipos de requisitos. Os requisitos normais são aqueles informados pelo usuário. Já os requisitos esperados são aqueles que o usuário não informou, porém, em sua percepção, esse requisito é óbvio e não necessita ser listado. Por fim, existem os requisitos excitantes (ou fascinantes), que vão além da expectativa do usuário.

É isso! Valeu pessoal! Na próxima postagem, estudaremos o processo de engenharia de requisitos. Ou seja, vamos conhecer as diversas etapas envolvidas! Até a próxima!