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.
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.
Roberto Paldês é pesquisador em Engenharia de Requisitos e professor universitário. Tem graduação e pós-graduação em Análise e Desenvolvimento de Sistemas. Cursou o Mestrado em Educação e o MBA em Gestão Pública. Leciona na Graduação no Cursos de Administração e no Curso de Análise e Desenvolvimento de Sistemas do UniCEUB. Na mesma instituição é professor e coordenador dos Cursos de Pós-Graduação presenciais: MBA em Gestão Empreendedora em Projetos, MBA em Logística, MBA em Gestão Pública. Endereço Currículo Lattes: http://lattes.cnpq.br/0464191770045460 . Endereço no Linkedin https://www.linkedin.com/in/roberto-paldês-54a625a4