O desenvolvimento de um sistema envolve uma série de definições que precisam ficar bem claras e elaboradas para que o objetivo proposto no projeto seja alcançado. A definição dos Requisitos Não Funcionais (RNF) faz parte da engenharia de software, em que são feitos levantamentos de requisitos funcionais e não funcionais para identificar todas as necessidades do software.
Entender como definir esse requisito é importante para o projeto de desenvolvimento do sistema, pois existe uma série de variáveis que podem impactar o funcionamento do software, entre elas os recursos de hardware necessários para garantir o desempenho, a necessidade de integração com outras aplicações, as regras de segurança e muito mais.
Para que você possa entender sobre esse assunto, fizemos este guia completo em que vamos mostrar:
- O que são Requisitos Não Funcionais?
- Qual a estrutura de um Requisito Não Funcional?
- Quais as categorias de um Requisito Não Funcional?
- Exemplo de Requisito Não Funcional
- Qual a relação entre Requisitos Não Funcionais e a arquitetura de software?
- O que são requisitos funcionais?
- Quais os 10 principais tipos de requisitos funcionais?
- 3 exemplos de requisitos funcionais!
- Resumindo: quais as diferenças entre requisitos funcionais e não funcionais?
- O que é a engenharia de requisitos?
- Como analisar os requisitos de software na prática? Passo a passo!
Vamos lá!
O que são Requisitos Não Funcionais?
Os requisitos não funcionais são aqueles que não interferem diretamente no desenvolvimento do sistema propriamente dito, ou seja, não é um requisito que tem regras de negócios e, portanto, é necessário para determinar o que será feito no software. Em vez disso, os RNFs são requisitos que estabelecem como o sistema se comportará em determinadas situações.
Em outras palavras, apesar de não interferirem em suas funcionalidades básicas, são necessidades que podem impactar no objetivo final do software se não forem contempladas em tempo de análise e desenvolvimento do projeto. Portanto, são requisitos que se relacionam com a qualidade do software.
Um exemplo é a definição sobre qual plataforma o software deverá rodar. Trata-se de um requisito não funcional, pois não existe uma regra de negócio nessa definição. Entretanto, é um requisito necessário para fazer outras definições para o desenvolvimento do sistema, como a escolha da linguagem de programação, do banco de dados que será utilizado etc.
Entenda a importância dos Requisitos Não Funcionais
Deixar de efetuar o levantamento dos requisitos não funcionais pode fazer com que o software deixe de cumprir sua função. Isso pode significar o fracasso de um projeto, inclusive em sistemas de grande porte, já que eles sofrem muitas influências externas.
Entretanto, fazer a identificação de RNF não é uma tarefa simples. Ao entrevistar as pessoas usuárias do sistema, geralmente elas só conseguem identificar as necessidades funcionais, ou seja, as regras de negócio, já que muitas vezes sua função e visão são as de pessoas que utilizam o software.
Por isso, é preciso empenho por parte das pessoas profissionais de TI para identificar os fatores externos ao desenvolvimento que devem ser contemplados no projeto para atender aos requisitos não funcionais.
Qual a estrutura de um Requisito Não Funcional?
Embora não exista uma estrutura obrigatória, algumas informações devem estar presentes na definição de um requisito não funcional. A seguir, confira os principais itens que devem ser discriminados no documento:
- identificador do requisito;
- nome ou descrição do requisito;
- categoria;
- data de criação;
- pessoa que criou o documento;
- data da última alteração;
- última pessoa que editou o documento;
- versão do documento;
- prioridade, que pode ser desejável, importante ou essencial;
- descrição detalhada.
Quais as 14 categorias de um Requisito Não Funcional?
O requisito não funcional pode pertencer a diferentes categorias. É importante identificar a qual delas o RNF pertence para que haja uma melhor organização do projeto de software.
1. Requisitos de Desempenho
Os requisitos de desempenho são voltados às necessidades de infraestrutura para garantir que o sistema funcione sem lentidão, sem problemas por falta de espaço em disco ou com outras ocorrências que impactem na qualidade de uso do sistema.
2. Requisitos de Disponibilidade
Corresponde ao tempo em que o sistema está disponível para a utilização. Portanto, nesse requisito, devem ser especificadas, por exemplo, as necessidades de paradas para manutenção, qual será a contingência para os casos de indisponibilidade, entre outras informações semelhantes.
3. Requisitos de Segurança
Os requisitos de segurança correspondem às definições sobre as regras de segurança para criação de usuários, os procedimentos exigidos para a utilização de senhas, a necessidade de criptografia e demais questões relacionadas para garantir a proteção dos dados.
4. Requisitos de Interoperabilidade
Muitos sistemas podem ter necessidades de integração com outras aplicações. Assim sendo, na categoria interoperabilidade, devem ser especificadas as necessidades do sistema de implementação de webservices ou outros tipos de interfaces com sistemas externos.
5. Requisitos de Usabilidade
Trata-se de um requisito voltado à facilidade de compreensão e utilização do software, ou seja, o que é preciso para oferecer essas características às atividades desempenhadas pelo software, como a utilização de tradutores de línguas e recursos de acessibilidade.
6. Requisitos de Compatibilidade
Nesse requisito, são especificadas quais as compatibilidades necessárias para a execução do sistema. Logo, podem fazer parte dessa solicitação a compatibilidade com navegadores, em quais versões do sistema operacional o sistema é capaz de rodar etc.
7. Requisitos de Confiabilidade
Os requisitos de confiabilidade se referem às definições sobre como funcionam as rotinas de backup, de que forma são feitos os controles de integridade de dados, as definições sobre o que fazer para garantir a consistência das informações caso ocorra a indisponibilidade do sistema por queda de energia e outras semelhantes.
8. Requisitos de Padrões
Os requisitos de padrões determinam quais são utilizados tanto no desenvolvimento do sistema quanto na definição do projeto. Então, referem-se às formas utilizadas de acordo com a metodologia adotada, a forma de programação (que pode ser imperativa ou declarativa) etc.
9. Requisitos de Legais
Já os requisitos legais correspondem às necessidades de implementação de padrões exigidos por lei, como normas específicas, adoção de processos para garantir a segurança da informação (como os exigidos pela LGPD — Lei Geral de Proteção de Dados), entre outros.
10. Requisitos da organização
São os requisitos que correspondem a processos executados dentro de um ambiente corporativo, tais como regras de infraestrutura, padrões de projeto a serem seguidos, etc.
11. Requisitos externos
Derivados de fatores presentes fora do processo de desenvolvimento e do sistema, tais como regras de legislação, localização, etc.
12. Requisitos de facilidade
São os requisitos que informam o quão fácil o sistema ser utilizado por pessoas usuárias mediante um tempo de treinamento do mesmo, por exemplo.
13. Requisitos de eficiência
Informam se o sistema é eficiente em processar um número n requisições por um determinado intervalo de tempo, por exemplo.
14. Requisitos éticos
Garantem à pessoa utilizadora do sistema que seus dados não serão compartilhados para outras pessoas e que informações sensívei, não serão visíveis a olho nu.
Exemplo de Requisito Não Funcional
A descrição do requisito não funcional deve especificar de forma clara e detalhada todas as informações necessárias para que as pessoas que desenvolvem o sistema possam consultar e entender as informações do documento.
Abaixo, veja como deve ficar a documentação de um requisito:
Qual a relação entre Requisitos Não Funcionais e a arquitetura de software?
A relação é que, apesar da projeção da pessoa solicitante do sistema, é a pessoa arquiteta de software que define quais requisitos não funcionais serão necessários. A pessoa envolvida no projeto pode ser uma grande especialista do domínio em questão, mas normalmente, é a pessoa arquiteta que adiciona eles ao sistema.
Elas consideraram os requisitos não funcionais tendo a mesma importância que os funcionais, porque os requisitos não funcionais, influenciam diretamente na escolha da arquitetura e nos padrões a serem utilizados na aplicação em questão.
O que são requisitos funcionais?
Um Requisito Funcional é uma descrição do serviço que o software deve oferecer. Em outras palavras, um requisito funcional descreverá um comportamento particular de funcionamento do sistema quando determinadas condições forem atendidas, por exemplo: “Enviar e-mail quando uma nova pessoa se cadastrar” ou “Abrir uma nova conta”.
Em nosso cotidiano, podemos ter uma xícara como exemplo de requisito funcional, que seria: “capacidade de conter líquidos sem vazar”.
Quais os 10 principais tipos de requisitos funcionais?
Os tipos de requisitos funcionais mais comuns são os seguintes:
- Tratamento de transações;
- Regras do negócio;
- Requisitos de certificação;
- Requisitos de relatórios;
- Funções administrativas;
- Níveis de autorização;
- Acompanhamento de auditoria;
- Interfaces externas;
- Gerenciamento de dados históricos;
- Requisitos Legais e Regulamentares.
3 exemplos de requisitos funcionais!
Vejamos, a seguir, três exemplos de requisitos funcionais que podem existir em qualquer sistema:
- Autenticação de uma pessoa usuária quando ela tenta fazer login no sistema;
- Desligamento do sistema no caso de um ataque cibernético;
- O e-mail de verificação é enviado ao usuário ou usuária sempre que ela se registra pela primeira vez em algum sistema de software.
Resumindo: quais as diferenças entre requisitos funcionais e não funcionais?
Na tabela abaixo, vejamos um comparativo entre os requisitos funcionais e os não funcionais:
| Requisitos funcionais | Requisitos não Funcionais |
| Eles definem um sistema ou seu componente. | Eles definem o atributo de qualidade de um sistema |
| Ele especifica: “O que o sistema deve fazer?” | Ele especifica: “Como o sistema deve atender aos requisitos funcionais?” |
| A pessoa usuária especifica o requisito funcional. | O requisito não funcional é especificado por pessoas técnicas, por exemplo, pessoas arquitetas e pessoas desenvolvedoras de software. |
| É obrigatório cumprir estes requisitos. | Não é obrigatório cumprir estes requisitos. |
| Ele é capturado no caso de uso. | É capturado como um atributo de qualidade. |
| Definido em um nível de componente. | Aplicado a todo o sistema. |
| Ajuda você a verificar a funcionalidade do software. | Ajuda você a verificar o desempenho do software. |
| Testes funcionais como sistema, integração, ponta a ponta, testes de API, etc. | Testes não funcionais como desempenho, estresse, usabilidade, testes de segurança, etc. |
| Geralmente fácil de definir. | Geralmente mais difícil de definir. |
O que é a engenharia de requisitos?
A engenharia de requisitos (RE) refere-se ao processo de definição, documentação e manutenção de requisitos no processo de projeto de engenharia.
A engenharia de requisitos fornece o mecanismo apropriado para entender o que o usuário ou usuária deseja, analisando a necessidade e avaliando a viabilidade, negociando uma solução razoável, especificando a solução com clareza, validando as especificações e gerenciando os requisitos à medida que são transformados em um sistema em funcionamento.
Assim, a engenharia de requisitos é a aplicação disciplinada de princípios, métodos, ferramentas e notações comprovados para descrever o comportamento pretendido de um sistema proposto e suas restrições associadas.
Quais as 7 principais etapas da engenharia de requisitos?
1. Iniciação
- A iniciação é uma tarefa em que a engenharia de requisitos faz um conjunto de perguntas para estabelecer um processo de software;
- Nesta tarefa, a pessoa programadora entende o problema e avalia com a solução adequada;
- O programador ou programadora e a pessoa solicitante do sistema decidem o escopo geral e a natureza da questão.
2. Elicitação
Elicitação significa encontrar os requisitos de qualquer pessoa. Esse processo pode se tornar complicado, porque os seguintes problemas ocorrem na elicitação:
Problema de escopo: A pessoa solicitante fornece detalhes técnicos desnecessários em vez de clareza do objetivo geral do sistema;
Problema de compreensão: Falta de entendimento entre as partes interessadas e o programador ou programadora em relação a vários aspectos do projeto, como capacidade, limitação do ambiente computacional.
Problema de volatilidade: Neste problema, os requisitos mudam de tempos em tempos e é difícil manter o desenvolvimento do projeto, para ele ficar estável.
3. Elaboração
- Nesta tarefa, as informações retiradas da pessoa usuária durante a concepção e elaboração são expandidas e refinadas na elaboração;
- Sua principal tarefa é desenvolver um modelo puro de software usando funções, recursos e restrições de um software.
4. Negociação
- Na tarefa de negociação, um engenheiro ou engenheira de software decide como o projeto será alcançado com recursos de negócios limitados;
- Para criar estimativas aproximadas de desenvolvimento e acessar o impacto do requisito no custo do projeto e no tempo de entrega.
5. Especificação
- Nesta tarefa, a pessoa engenheira de requisitos constrói um produto de trabalho final;
- O produto de trabalho está na forma de especificação de requisitos de software;
- Nesta tarefa, é feita a formalização dos requisitos do software proposto como informativo, funcional e comportamental;
- Os requisitos são formalizados em formatos gráficos e textuais;
6. Validação
- Essa etapa consiste em fazer validações do sistema, para verificar se o que foi proposto corresponde com as necessidades da pessoa solicitante;
- As revisões técnicas formais do engenheiro ou engenheira de software e outras partes interessadas ajudam no mecanismo de validação de requisitos primários.
7. Gerenciamento de requisitos
- É um conjunto de atividades que auxiliam a equipe do projeto a identificar, controlar e rastrear os requisitos e mudanças podem ser feitas nos requisitos a qualquer momento do projeto em andamento;
- Essas tarefas começam com a identificação e atribuem um identificador único a cada um dos requisitos.
Como analisar os requisitos de software na prática? Passo a passo!
Existem três etapas principais na condução de uma análise completa de requisitos:
- O primeiro passo é reunir os requisitos coletando a documentação do processo de negócios e realizando entrevistas com as partes interessadas;
- Em seguida, analise e valide os requisitos, avaliando se eles são claros, completos, consistentes e inequívocos;
- Por fim, registre os requisitos e monitore sua implementação ao longo do projeto.
Vejamos como podemos fazer um processo de análise de requisitos para construir um sistema computacional:
1. Desenhe o diagrama de contexto: o diagrama de contexto é um modelo simples que define os limites e interfaces dos sistemas propostos com o mundo externo. Ele identifica as entidades fora do sistema proposto que interagem com o sistema. O diagrama de contexto de um sistema que emite notas fiscais eletrônicas, seria dessa forma:
2. Desenvolvimento de um Protótipo (opcional): yma maneira eficaz de descobrir o que as partes interessadas desejam é construir um protótipo, algo que pareça e preferencialmente atue como parte do sistema que ela diz querer.
Podemos usar o feedback das pessoas solicitantes para modificar o protótipo até que ele fique nos conformes com o que foi solicitado. Assim, o protótipo ajuda as pessoas envolvidas a visualizar o sistema proposto e aumentar o entendimento dos requisitos.
Quando pessoas programadoras e usuários ou usuárias não têm certeza sobre alguns dos elementos, um protótipo pode ajudar ambas as partes a decidir algum ponto que esteja indefinido.
O protótipo deve ser construído rapidamente e a um custo relativamente baixo. Portanto, sempre terá limitações e não seria aceitável no sistema final. Esta é uma atividade opcional, não obrigatória.
3. Modelar os requisitos: esse processo geralmente consiste em várias representações gráficas das funções, entidades de dados, entidades externas e os relacionamentos entre elas. A visualização gráfica pode ajudar a encontrar requisitos incorretos, inconsistentes, ausentes e supérfluos. Tais modelos incluem o diagrama de fluxo de dados, diagrama de entidade-relacionamento, dicionários de dados, diagramas de transição de estado, etc.
4. Finalizar os requisitos: após a modelagem dos requisitos, teremos um melhor entendimento do comportamento do sistema. As inconsistências e ambiguidades foram identificadas e corrigidas.
O fluxo de dados entre vários módulos foi analisado. As atividades de elicitação e análise forneceram uma melhor visão do sistema. Agora finalizamos os requisitos analisados, e o próximo passo é documentar esses requisitos em um formato prescrito.
Como vimos, as definições de requisitos não funcionais são essenciais para determinar como o software funciona e, com isso, proporcionar maior qualidade tanto em seu desenvolvimento quanto no produto final. Portanto, é preciso avaliar cuidadosamente cada necessidade do sistema para que todas as variáveis que possam interferir no sistema sejam contempladas.
Gostou do nosso artigo sobre levantamento de requisitos? Então, não deixe de conferir outros conteúdos sobre a área de programação.
1 comment