O que é um Requisito Não-Funcional? Como o próprio nome diz, é uma “não funcionalidade”, ou seja, trata-se de algo que não é uma funcionalidade, mas que precisa ser realizado para que o software atenda seu propósito.
Existe uma definição propagada na literatura de Engenharia de Software que afirma que um Requisito Funcional define o que o sistema fará, e o Requisito Não-Funcional define como o sistema fará.
Alguns afirmam que um Requisito Não-Funcional especifica como um Requisito Funcional será implementado; também não é uma boa definição, pois uma funcionalidade teoricamente pode ser implementada sem nenhum Requisito Não-Funcional no projeto e isso não gerar ônus nenhum.
Acho que nenhuma dessas definições é suficiente, não dá para entender muito bem; tem outra que diz que requisitos não funcionais são atributos de qualidade para o sistema, essa eu já acho melhor, mas ainda um pouco subjetiva.
Um Requisito Não-Funcional é um Requisito de Software.
Um RNF tem como objetivo atender a requisitos do sistema que não são requisitos funcionais (não se referem a funcionalidades do negócio), mas que fazem parte do escopo do sistema.
Um RNF pode ou não estar associado a um Requisito Funcional (essa associação é muito comum em requisitos não funcionais de integração de sistemas, por exemplo, pois para cada integração existe uma necessidade do negócio de fazê-la, necessidade que está descrita em um Requisito Funcional).
Toda necessidade que for realizada através de funcionalidades é resultado de um ou mais requisitos funcionais (pois uma funcionalidade pode realizar vários requisitos funcionais, não necessariamente apenas um) e toda necessidade que não puder ser atendida desta forma, é um Requisito Não-Funcional – geralmente trata-se de premissas e restrições técnicas aplicadas ao projeto. Acho que essa definição, aparentemente simples, define bem um RNF.
Importância dos Requisitos Não-Funcionais
Requisitos não funcionais são tão importantes quanto os requisitos funcionais ou regras de negócio. Infelizmente é muito difícil encontrar alguma empresa que leve isso a sério, e aí está a causa do fracasso de muitos projetos de software.
Existem duas principais causas que justificam a pouca importância que os RNFs tem na maioria dos projetos:
Usuários não sabem o que é um Requisito Não-Funcional
Usuários pensam apenas no negócio, o que remete a requisitos funcionais e, consequentemente, funcionalidades. Apenas em empresas de grande porte, com uma TI mais estruturada, onde a área de TI apoia os usuários nos projetos é que se dá alguma importância a RNFs;
RNF é algo difícil de estimar
É difícil estimar prazo/esforço/custo para implementação de Requisitos Não-Funcionais. Em termos de volume de trabalho/esforço (horas gastas na produção), geralmente isso é feito baseado na famosa “opinião de especialista”.
Medidas como Ponto de Função, Linha de Código, Pontos por Caso de Uso e técnicas semelhantes mensuram apenas o que é perceptível para o usuário, e RNFs geralmente não o são (na última versão da Análise por Pontos de Função há algo mais maduro para medir RNFs, mas na minha opinião ainda não atende por completo).
Muitos fornecedores ignoram os RNFs quando não é solicitado explicitamente pelo cliente, pois acham que “gastarão mais” no projeto.
Um Requisito Não-Funcional pode ser até mais importante que um Requisito Funcional, ou Regra de Negócio.
Se pensarmos num sistema de grande porte (como um ERP para grandes empresas), no escopo de um sistema como este tem facilmente mais que cinco mil requisitos funcionais e dez mil regras de negócio.
Mas podemos ter poucas dezenas de requisitos não funcionais.
No meio de cinco mil requisitos funcionais, deixar de atender no escopo uns poucos provavelmente não inviabiliza o sistema, no meio de quinze mil regras de negócio idem.
Mas existem RNFs que se não são atendidos, inviabilizam um sistema gigante como este.
Diferente dos RFs, os RNFs permeiam todo o sistema (geralmente são “utilizados” em vários módulos do sistema, de maneira horizontal), existem em quantidade muito menor nos projetos se comparado com os RFs mas possuem uma amplitude enorme no sistema. Um RNF pertinente à usabilidade, por exemplo, algo sobre padrão de barra de rolagem, pode existir em quase todas as telas do sistema.
Para ilustrar, no contexto do ERP citado, vamos imaginar a seguinte necessidade de um cliente, num cenário hipotético:
No módulo de logística, toda carga deve ser liberada em no máximo 20 minutos, pois temos uma frota de dois mil caminhões que não podem esperar mais que isso para sair dos armazéns. Para a liberação da carga, um documento de solicitação de liberação de carga deve ser emitido, e nele anexada a nota fiscal dos produtos contidos no caminhão.
A partir deste cenário imaginamos que um analista identificou um RNF de Desempenho (mais à frente falaremos sobre as categorias dos requisitos não funcionais) nomeado de “RNF0087 – Tempo limite para processamento de solicitação de liberação de carga”, onde foi especificada a restrição do tempo de vinte minutos para liberação da carga.
Requisitos não funcionais são entradas (input) para a definição da arquitetura técnica de um software. Em sistemas com alto volume de processamento e exigências “desafiadoras” de tempo de resposta, projetar e implementar a arquitetura ignorando os requisitos não funcionais é sacramentar o caos vindouro.
Quando o produto ficou pronto, iniciou-se a homologação. Na primeira bateria de testes de desempenho o sistema foi reprovado pela área de logística, pois estava demorando 35 minutos, em média, apenas para processar a solicitação de liberação de carga (gerar nota fiscal, anexá-la à solicitação, processar a solicitação e rodar o fluxo no sistema até o caminhão poder sair do armazém).
Entretanto, os arquitetos responsáveis pela implementação da arquitetura do ERP não deram a devida importância ao RNF citado e pensaram a estrutura do sistema ignorando uma performance otimizada, e esta necessidade de tempo de resposta ficou relegada para o fim do projeto.
Efeito: sistema inviável para produção, necessário reestruturar sua arquitetura porque a performance ficou muito ruim.
Causa: não atendimento do RNF0087.
Reestruturar uma arquitetura não é uma atividade trivial. E no geral (não é regra) o impacto de uma reestruturação destas é proporcional ao tamanho do sistema. Quanto maior o sistema, mais problemático é realizar alterações arquiteturais.
Já presenciei um caso onde a construção de um sistema levou três anos para ficar pronta, para então iniciar a homologação. Quando começaram os testes, percebeu-se inviabilidade em termos de performance.
Para constar apenas, não precisava chegar ao fim da construção para começar os testes, mas o ciclo de desenvolvimento adotado neste projeto não dava outra opção.
Neste caso, foram necessários mais 10 meses para reestruturação (além do atraso já contraído pelo projeto), orçamento adicional de R$ 1,2 milhões e desperdício de ao menos R$ 1 milhão em custo de implementação (horas gastas na implementação “errada” desta parte da arquitetura do sistema). Somando tudo, num sistema de grande porte (4000 pontos de função), prejuízo de R$ 2,5 milhões.
Estrutura de um Requisito Não-Funcional
Como no caso dos requisitos funcionais e regras de negócio, não há um padrão estabelecido sobre a estrutura de um RNF.
Mas a maioria das empresas utiliza um formato semelhante, contendo campos específicos. O modelo a seguir contempla os campos mais relevantes, com posterior descrição de cada um.
| Identificador | |||
| Nome | |||
| Categoria | |||
| Data de criação | Autor | ||
| Data da última alteração | Autor | ||
| Versão | Prioridade | ||
| Descrição | |||
Explicando cada campo
| Campo | Descrição |
| Identificador | Sufixo seguido de um identificador único. O sufixo geralmente utilizado é RNF (Requisito Não-Funcional) e o identificador único geralmente é composto de dois dígitos (dificilmente um projeto terá mais que 99 RNFs). |
| Nome | Nome curto do RF, mas que possibilite entender bem o que RF faz apenas pelo nome. |
| Categoria | Categoria à qual o RNF pertence (Desempenho, Usabilidade, Padrão etc.). |
| Data de criação | Data da criação do RNF, ou a data em que ele foi especificado. |
| Autor | Profissional que especificou o RNF pela primeira vez, quem o criou. |
| Data da última alteração | Data em que houve a última alteração no RNF. |
| Autor | Profissional que alterou a especificação do RNF pela última vez. |
| Versão | Número da versão do RNF. Geralmente utiliza-se algo simples, como 1, 2. A versão inicial sempre é a 1, e a cada alteração incrementa-se a versão (na criação versão 1, na primeira alteração versão 2 e por aí vai). |
| Prioridade | Se o RF é Essencial, Importante ou Desejável. |
| Descrição | Descrição detalhada (a mais detalhada possível) do RF. |
/* O uso de identificador é fundamental para uma melhor organização do projeto. Localizar requisitos pelo nome não funciona, devido ao volume dos requisitos e ambiguidades nos nomes. E também, é importante ter algum recurso de numeração automática, pois controlar os números dos identificadores manualmente é inviável */
Categorias para um Requisito Não-Funcional
Para uma melhor organização da especificação e semântica do projeto do software, RNFs são separados por categorias, conforme o propósito de cada requisito. A seguir, a lista das principais categorias existentes:
| Categoria | Descrição |
| Desempenho | Desempenho do sistema, restrições de performance, tempo de resposta em processamentos específicos, cargas, velocidade de resposta de processamentos em telas etc. |
| Disponibilidade | Disponibilidade do sistema em tempo útil, restrições sobre janelas de manutenção, janelas de produção, soluções de contorno quando houver queda de energia etc. |
| Segurança | Diretrizes pertinentes à segurança do sistema, como algoritmo de criptografia a ser utilizado, regras para criação e manutenção de usuários e senhas, uso de certificados digitais, uso de protocolos seguros específicos, uso de captcha etc. |
| Interoperabilidade | Necessidades de integração do sistema com outros sistemas, integração com APIs, componentes, banco de dados externos etc. |
| Usabilidade | Quantidade máxima de cliques por tipo de funcionalidade, uso de componentes e lógicas de telas específicas, restrição/premissas para uso de componentes gráficos (grids, barras de rolagem, menus), recursos de acessibilidade para deficientes, compatibilidade com idiomas etc. |
| Compatibilidade | Browser e sistemas operacionais nos quais o software deverá rodar, versões de browser e sistemas operacionais, protocolos compatíveis, versões de linguagens de programação e banco de dados para retrocompatibilidade etc. |
| Confiabilidade | Políticas para backup do sistema e seus dados, quantidade limite de erros em cálculos e processamentos com erro, regras para rollback quando houver alguma falha, recursos para restauração automática do sistema em caso de queda de energia etc. |
| Padrões | Padrões em geral, aplicáveis ao software e ao projeto: padrão de log de erro, de log de informação, padrão de mensagens, metodologia para desenvolvimento do sistema, padrões de projeto (design patterns) a serem aplicados, padrões arquiteturais etc. |
| Legais | Exigências de conformidade do software com alguma legislação pertinente ao projeto, por exemplo, atendimento a alguma norma da Agência Nacional de Saúde para software de hospital, a norma do Banco Central para sistemas financeiros etc. |
Exemplo de um RNF de Desempenho
A seguir, vamos ver um exemplo de RNF de Desempenho. Muitos profissionais de software acham que um RNF geralmente é algo subjetivo, relativo, mas com base no exemplo a seguir podemos ver que não, basta que sejam especificados com clareza e nível de detalhes suficientes para um bom entendimento.
| Identificador | RNF01 | ||
| Nome | Tempo limite para processamento de todos os lotes de fatura na rotina diária | ||
| Categoria | Desempenho | ||
| Data de criação | 18/01/2016 | Autor | Alexandre de Afrodísias |
| Data da última alteração | N/A | Autor | N/A |
| Versão | 1 | Prioridade | Essencial |
| Descrição | No módulo de faturamento o processamento de faturas em lote é um processo oneroso em termos de memória e CPU devido ao alto volume de dados. Em função desta realidade o sistema deverá prover recursos para processamento paralelo (multithreading) que possibilite processar lotes de faturas de forma paralela, compactando o tempo de execução da rotina diária.
A média diária de faturas a serem processadas é 80.000. Cada lote contém 500 (quinhentas) faturas, totalizando 160 (cento e sessenta) lotes. A janela de produção disponível para o processamento de todos os lotes é de 4h. Considerando as medidas acima, o sistema deve processar todos os 160 lotes em, no máximo, 4h. Para atender isso, o sistema deverá rodar os lotes na quantidade máxima permitida de threads, considerando a seguinte especificação do servidor de aplicativos: – 16 processadores com quatro núcleos cada. Obs.: deve haver no sistema alguma funcionalidade ou arquivo de configuração onde seja possível o próprio analista da TI parametrizar a quantidade de threads que o sistema deverá rodar. Esta informação não pode ser fixada em código e nem ser de domínio apenas do fornecedor que implementará a solução. |
||
Concluindo
“Não-Funcionalidades”, (ou Requisitos Não-Funcionais) são tão importantes quantos as funcionalidades do sistema.
E se todo projeto tivesse seus requisitos não-funcionais bem especificados e bem implementados, com certeza viveríamos num mundo melhor.
Para entender mais sobre tudo isso, nada melhor que exemplos práticos. Veja vários exemplos de requisitos não funcionais.
Abraço!