The Good, the Bad and the Ugly: Requisitos Funcionais, Requisitos Não Funcionais e Requisitos de Dados

The Good, the Bad and the Ugly: Requisitos Funcionais, Requisitos Não Funcionais e Requisitos de Dados

Ele é o mais querido, o desejado, o bom… o Requisito Funcional! O conjunto deles expressa o que o sistema deverá fazer para atender as necessidades e expectativas do cliente. Então, vamos dar todas as luzes a ele e correr para entregar as funcionalidades que ele tanto precisa, não é assim? Vamos debater com atenção os modelos e a especificação desses requisitos, gerar protótipos… tudo o que sabemos fazer de melhor.

Mas… sempre tem um “mas”! Lá vem o cliente falar em expectativas de desempenho, segurança, usabilidade. É um tal de Requisito Não Funcional, o mau, apresentando características de qualidade que as funcionalidades deverão observar.  Veio só limitar a minha capacidade de gerar soluções ou complicar o que era tão óbvio.

Foto: Cartaz do filme de Sergio Leone (1966), trilha sonora de Ennio Morricone

Um momento! Os Requisitos Não Funcionais podem até já ter sido um “patinho feio”. Hoje, entretanto, entram nos primeiros minutos de conversa sobre os requisitos do software. Imagine um sistema para controle financeiro, para a área médica, para a gestão de áreas críticas ou sensíveis.  As primeiras preocupações e solicitações do cliente deverão revelar a sua preocupação com a disponibilidade, a confiabilidade, a segurança, por exemplo. Então, olhe com carinho para ele, não o chame mais de mau.

E qual apontaremos como o feio? Parece não haver dúvida: o que tem o nome mais estranho é o Requisito de Dados! De onde saiu esse termo? Bem, ser notado que a abordagem orientada a negócios do método iRON adota esse termo. Apresenta os atributos de dados de cada requisito funcional identificado. Os Requisitos de Dados descrevem os dados necessários para implementar as funcionalidades. Por exemplo: para o Requisito Funcional “Incluir cliente” deve ser identificado o Requisito de Dados que reúna atributos como CPF, nome e endereço.

O argumento tem fundamento na norma ISO/IEC 25030, Software engineering – Software product Quality Requirements and Evaluation (SquaRE) – Quality requirements. A norma observa que um sistema computacional possui requisitos de hardware, requisitos do sistema operacional, requisitos do software aplicativo e requisitos dos dados. O termo foi incluído pelo iRON como uma das boas práticas na especificação de um software de qualidade, pois não concentra o ciclo de vida dos requisitos apenas nos processos, mas também nas suas estruturas de dados.

O que mais pitoresco em tudo isso é que todos os três tipos de requisitos seguem o que mandam as Regras! Regras de Execução ou de Negócio? Para responder corretamente, recorde nossa última postagem e acompanhe as próximas discussões.

Concluindo: é importante notar a relevância crescente que os Requisitos Não Funcionais adquirem nos sistemas atuais. Não se perca apenas nos Requisitos Funcionais. Considere, também, incorporar no seu repertório de conhecimentos os Requisitos de Dados. Serão peças básicas para estruturar um sistema de informação.