No mundo da engenharia, particularmente no desenvolvimento de software e engenharia de sistemas, entender a distinção crítica entre requisitos funcionais e não funcionais é fundamental para o sucesso do projeto. 37% dos projetos falham por causa de requisitos não claros ou errados, tornando essencial para engenheiros, desenvolvedores, gerentes de projetos e stakeholders para compreender esses conceitos completamente. Esses requisitos formam a espinha dorsal do design do sistema, influenciando diretamente tudo, desde a experiência do usuário e desempenho do sistema até a manutenção e escalabilidade de longo prazo.

Este guia abrangente explora os requisitos funcionais e não funcionais em profundidade, fornecendo exemplos práticos, melhores práticas para a documentação e estratégias para gerenciamento eficaz de requisitos. Se você está construindo uma plataforma de comércio eletrônico, desenvolvendo software empresarial ou projetando sistemas complexos, dominar esses requisitos melhorará significativamente os resultados do seu projeto.

Quais são os Requisitos Funcionais?

Em engenharia de software e engenharia de sistemas, um requisito funcional define uma função de um sistema ou seu componente, onde uma função é descrita como um resumo (ou especificação ou declaração) de comportamento entre entradas e saídas. Requisitos funcionais definem as características específicas e operações que um sistema deve realizar para atender às necessidades de negócios e usuários.

Requisitos funcionais definem as características e funções de um sistema. Em outras palavras, eles descrevem o que exatamente o produto de software deve fazer em condições normais para atender às necessidades do usuário. Do ponto de vista de um desenvolvedor, essas são as características que devem ser implementadas para garantir que o sistema funcione como pretendido.

Os requisitos funcionais podem envolver cálculos, detalhes técnicos, manipulação e processamento de dados e outras funcionalidades específicas que definem o que um sistema deve realizar, servindo como base para equipes de desenvolvimento, fornecendo diretrizes claras sobre o que precisa ser construído e como o sistema deve responder a vários insumos.

Características-chave dos requisitos funcionais

Os requisitos funcionais possuem várias características definidoras que os distinguem de outros tipos de requisitos:

  • Especificação: Eles descrevem comportamentos e funções precisas que o sistema deve executar
  • Testabilidade: Cada requisito pode ser verificado através de testes para confirmar a implementação
  • Focado pelo utilizador: Relacionam-se directamente com as necessidades do utilizador e os objectivos de negócio
  • Action-Oriented: Eles definem o que o sistema faz em resposta a entradas
  • Mensurabilidade: Eles definiram resultados que podem ser medidos, como login bem sucedido com credenciais válidas

Tipos de requisitos funcionais

Os requisitos funcionais podem ser categorizados em vários tipos com base nos fluxos de trabalho e comportamentos que descrevem:

Regras de negócio e lógica

As regras de negócios são geralmente o maior grupo, pois definem como o sistema responde aos comandos no fluxo principal do usuário. Esses requisitos especificam a lógica de negócios central que impulsiona o comportamento da aplicação, incluindo cálculos, processos de tomada de decisão e automação de fluxo de trabalho.

Autenticação e Autorização do Usuário

Os requisitos de autenticação e autorização definem como os usuários acessam o sistema e quais permissões possuem. Esses requisitos especificam mecanismos de login, políticas de senha, controle de acesso baseado em funções e protocolos de segurança para verificação de identidade do usuário.

Requisitos de gestão de dados

Os requisitos de dados definem como os dados devem ser criados, armazenados, modificados e excluídos. Eles são especialmente importantes se o produto lidar com dados sensíveis do usuário. Esses requisitos abrangem operações de banco de dados, regras de validação de dados, processos de transformação de dados e políticas de retenção de dados.

Requisitos de interface do usuário

Os requisitos de interface de usuário especificam como seus usuários irão interagir com seu produto. Eles definem elementos de design que tornam a navegação intuitiva. Esses requisitos descrevem os elementos visuais, padrões de interação, fluxos de navegação e componentes de interface de usuário que os usuários encontrarão.

Requisitos de Transação e Processamento

Esses requisitos definem como o sistema processa transações, lida com operações de negócios e gerencia fluxos de trabalho. Eles especificam as etapas envolvidas no preenchimento de tarefas, a sequência de operações e os resultados esperados de vários processos.

Exemplos abrangentes de requisitos funcionais

Compreender os requisitos funcionais torna-se mais claro através de exemplos concretos entre diferentes indústrias e tipos de aplicação. Aqui estão exemplos detalhados organizados por domínio:

Exemplos de aplicações de comércio eletrónico

Um site de eCommerce deve ter requisitos funcionais que definam como os clientes buscam itens, revisam suas características, fazem uma encomenda, pagam e recebem confirmação. Exemplos específicos incluem:

  • O sistema deve permitir que os usuários criem uma conta usando o endereço de e-mail e senha
  • Os usuários devem ser capazes de navegar por produtos por categoria, preço e filtros de marca
  • Os usuários devem ser capazes de adicionar produtos a um carrinho de compras e visualizar o conteúdo do carrinho
  • O usuário pode revisar itens no carrinho, alterar seu número ou removê-los antes da saída
  • O usuário pode adicionar o promocode e obter um desconto antes do checkout
  • O sistema deve processar as operações de pagamento de forma segura através de gateways de pagamento integrados
  • O sistema envia um e-mail de confirmação ao usuário após reserva de voo
  • Os utilizadores devem poder fornecer serviços/produtos de feedback ou de taxa dentro da aplicação

Sistemas Bancários e Financeiros

  • O sistema deve permitir aos clientes transferir fundos entre contas
  • Os usuários devem ser capazes de visualizar o histórico de transações nos últimos 12 meses
  • O aplicativo deve permitir agendamento de pagamento de faturas com opções de pagamento recorrentes
  • O sistema deve gerar declarações de contas mensais em formato PDF
  • Os utilizadores devem poder estabelecer indicações de contas para tipos específicos de transacções
  • O sistema deve verificar os saldos da conta antes de processar os pedidos de levantamento

Sistemas de Gestão de Saúde

  • O sistema deve permitir que os prestadores de cuidados de saúde marquem consultas com os doentes
  • Os médicos devem poder aceder e actualizar os registos médicos dos doentes
  • O pedido deve permitir o gerenciamento de prescrição e pedidos de recarga
  • O sistema deve gerar lembretes de marcação automatizados via e-mail e SMS
  • Os prestadores de cuidados de saúde devem poder visualizar os resultados dos exames e relatórios de diagnóstico do doente
  • O sistema deve apoiar a integração do registo electrónico de saúde (REE) com sistemas externos

Gestão de Conteúdos e Mídias Sociais

  • O sistema deve permitir que os visitantes do blog se inscrevam para o boletim informativo, deixando seu e-mail
  • Os usuários devem ser capazes de criar, editar e publicar conteúdo com formatação de texto rica
  • O sistema deve ativar a categorização de conteúdo usando tags e categorias
  • Os usuários devem ser capazes de carregar e gerenciar arquivos de mídia, incluindo imagens e vídeos
  • O aplicativo pode enviar notificações aos usuários para atualizações, lembretes ou conteúdo promocional
  • O sistema deve fornecer funcionalidade de pesquisa em todo o conteúdo publicado
  • Os utilizadores devem poder partilhar conteúdos em plataformas de redes sociais externas

Sistemas de Planejamento de Recursos Empresariais (ERP)

  • Software de gestão de hotéis deve permitir que a equipe para gerenciar reservas recebidas, criar e gerenciar planos de taxas, aceitar pagamentos, gerar relatórios, etc.
  • O sistema deve acompanhar os níveis de inventário e gerar alertas de reordenação automáticos
  • Os utilizadores devem poder gerar relatórios financeiros, incluindo demonstrações de resultados
  • O pedido deve apoiar as operações e conversões de várias moedas
  • O sistema deve permitir o rastreamento de tempo e processamento de folha de pagamento do funcionário
  • Os utilizadores devem ser capazes de gerir relações de fornecedores e encomendas de compra

Exemplos de Aplicações Móveis

  • O aplicativo deve permitir que os usuários criem contas e entrem usando credenciais como e-mail e senha ou através da integração de mídias sociais
  • O aplicativo deve suportar o modo offline com sincronização de dados quando a conectividade é restaurada
  • Os utilizadores devem poder aceder a serviços e funcionalidades baseados na localização
  • O aplicativo deve ativar notificações de push para atualizações e alertas importantes
  • Os usuários devem ser capazes de personalizar as configurações e preferências do aplicativo
  • O sistema deve apoiar a autenticação biométrica, incluindo o reconhecimento de impressões digitais e de rosto

What Are Requisitos não funcionais?

Na engenharia de sistemas e engenharia de requisitos, um requisito não funcional (NFR) é um requisito que especifica critérios que podem ser usados para julgar o funcionamento de um sistema, em vez de comportamentos específicos. Eles são contrastados com requisitos funcionais que definem comportamentos ou funções específicas.

Define em geral o que um sistema deve fazer e os requisitos não funcionais definem como um sistema deve ser. Requisitos não funcionais (NFRs) definem como um sistema deve funcionar, focando no desempenho, confiabilidade e experiência do usuário, em vez de recursos específicos. Eles garantem que o sistema é eficiente, seguro e mantendível ao longo do tempo.

Requisitos não funcionais são frequentemente chamados de "atributos de qualidade" de um sistema. As propriedades gerais do sistema geralmente marcam a diferença entre se o projeto de desenvolvimento foi bem sucedido ou falhou. Enquanto os requisitos funcionais garantem que o sistema funcione, os requisitos não funcionais garantem que ele funcione bem e atendem às expectativas do usuário quanto à qualidade, desempenho e confiabilidade.

Entender a importância dos requisitos não funcionais

Focar apenas em requisitos funcionais à custa de requisitos não funcionais pode causar grandes problemas. Requisitos funcionais podem ser considerados cumpridos mesmo quando os requisitos não funcionais não são. Uma transação que leva 20 segundos para ser concluída com sucesso pode ser funcional – mas certamente não é utilizável.

Requisitos não funcionais impactam diretamente a satisfação do usuário, a adoção do sistema e o sucesso a longo prazo. Um sistema que executa todas as funções necessárias, mas carrega lentamente, trava frequentemente ou apresenta vulnerabilidades de segurança, em última análise, não atende aos objetivos de negócios e às necessidades do usuário.

Tipos abrangentes de requisitos não funcionais

Informalmente, estas são às vezes chamadas de "ilidades", de atributos como estabilidade e portabilidade. Qualidades – ou seja, requisitos não funcionais – podem ser divididas em duas categorias principais: Qualidades de execução, tais como segurança, segurança e usabilidade, que são observáveis durante a operação (no tempo de execução). Qualidades de evolução, tais como testabilidade, manutenção, extensibilidade e escalabilidade, que são incorporadas na estrutura estática do sistema.

Requisitos de desempenho

Requisitos de desempenho especificam como o sistema deve reagir à carga pesada do usuário. Isso envolve verificar métricas como tempo de inicialização, tempo de resposta, latência e o número máximo de usuários simultâneos que o aplicativo pode suportar.

Os requisitos de desempenho são fundamentais para garantir que os sistemas possam lidar com cargas de trabalho esperadas sem degradação.

  • Tempo de resposta: O tempo máximo permitido para o sistema responder às solicitações do usuário
  • Put: O número de transações ou operações que o sistema pode processar por unidade de tempo
  • Utilização de recursos: CPU, memória e consumo de largura de banda em várias condições de carga
  • Usuários Concorrentes: O número de usuários simultâneos que o sistema pode suportar
  • Tempo de carga: Quão rapidamente páginas, telas ou dados carregam para usuários

Exemplo: Um requisito de desempenho para uma aplicação bancária seria que ela pudesse processar transações em 3 segundos, mesmo durante períodos de alto tráfego de usuários.

Requisitos de segurança

Requisitos de segurança definem como o sistema protege dados, impede o acesso não autorizado e mantém a confidencialidade, integridade e disponibilidade. Esses requisitos são cada vez mais críticos no cenário de ameaça de hoje.

Os requisitos de segurança incluem:

  • Autenticação: Métodos para verificar a identidade do usuário
  • Autorização: Mecanismos de controle de acesso e níveis de permissão
  • Cryptografia de dados: Protecção de dados em trânsito e em repouso
  • Auditoria: Registo e monitorização de eventos relevantes para a segurança
  • Proteção contra vulnerabilidade: Defesas contra ameaças comuns de segurança
  • Privacidade de dados: Conformidade com as normas de privacidade e proteção de dados

Exemplo: Os dados devem ser criptografados tanto em trânsito usando TLS 1.3 e em repouso usando padrões de criptografia AES-256.

Requisitos de usabilidade

A usabilidade é basicamente sobre a facilidade de utilização. Isso significa que a interface do produto deve ser intuitiva e fácil de navegar, suas características devem ser compreensíveis e fáceis de encontrar, e, mais importante, deve atender às necessidades do usuário.

Endereço dos requisitos de usabilidade:

  • Aprenabilidade: Como rapidamente novos usuários podem se tornar produtivos com o sistema
  • Eficiência: Como usuários experientes rapidamente podem realizar tarefas
  • Memorabilidade: Como facilmente os usuários podem retornar ao sistema após um período de não-uso
  • Prevenção de Erros: Recursos de projeto que evitam erros de usuário
  • Satisfação: Quão agradável e satisfatório é o sistema de usar
  • Acessibilidade: Apoio a utilizadores com deficiências e necessidades diversas

Exemplo: Novos usuários devem ser capazes de concluir sua primeira transação em 5 minutos sem precisar de ajuda externa ou documentação.

Requisitos de Confiabilidade e Disponibilidade

Este conjunto de NFRs declara que o sistema deve estar disponível para uso tanto quanto possível, e que o tempo de inatividade deve ser minimizado. Requisitos de confiabilidade garantem que o sistema funcione de forma consistente e previsível ao longo do tempo.

As principais considerações incluem:

  • Hora de funcionamento: Percentagem de tempo em que o sistema está operacional e acessível
  • Tempo médio entre falhas (MTBF): Tempo médio entre falhas do sistema
  • Tempo médio para reparar (MTTR): Tempo médio necessário para restaurar a funcionalidade do sistema
  • Tolerância de falha: Capacidade do sistema para continuar a funcionar apesar das falhas dos componentes
  • Recuperação de desastres: Procedimentos e capacidades para recuperar de falhas catastróficas

Exemplo: O sistema deve estar disponível 99,9% do tempo, excluindo janelas de manutenção programadas, que se traduz em não mais de 8,76 horas de inatividade por ano.

Requisitos de escalabilidade

Os requisitos de escalabilidade definem como o sistema cresce e se adapta a demandas crescentes, seja em termos de usuários, volume de dados ou processamento de transações. Esses requisitos são essenciais para sistemas que se espera cresçam ao longo do tempo.

  • Escalabilidade horizontal: Capacidade de adicionar mais servidores ou nós para distribuir carga
  • Escalabilidade vertical: Capacidade de aumentar os recursos nos servidores existentes
  • Escalabilidade de dados: Capacidade para lidar com volumes de dados crescentes
  • Escalabilidade Geográfica: Suporte para expansão para novas regiões ou locais

Exemplo: O sistema deve ser capaz de lidar com 20 milhões de usuários sem deterioração de desempenho.

Requisitos de manutenção

Um sistema mantendível deve ser capaz de ser mantido de forma rentável ao longo da sua vida útil prevista e pode incorporar requisitos adicionais, tais como a capacidade de modificação, a configuração, a extensibilidade e a interoperabilidade.

A manutenção abrange:

  • Qualidade do código: Normas para legibilidade, documentação e estrutura do código
  • Modularidade: Grau em que os componentes do sistema são independentes e intercambiáveis
  • Testabilidade: Facilidade dos componentes e funcionalidade do sistema de ensaio
  • Configurabilidade: Capacidade de modificar o comportamento do sistema sem alterações de código
  • Extensibilidade: Facilidade de adicionar novas funcionalidades e capacidades

Requisitos de conformidade e regulamentação

Requisitos não funcionais na categoria de conformidade afirmam que os sistemas de software devem cumprir os requisitos legais e regulamentares; a auditoriabilidade é normalmente incluída também nesta categoria.

Os requisitos de conformidade variam de acordo com a indústria e jurisdição, mas geralmente incluem:

  • O gateway de processamento de pagamentos deve ser compatível com PCI DSS
  • O software clínico deve cumprir com HIPAA (Lei de Portabilidade e Responsabilidade do Seguro de Saúde) e GDPR (Regulamento Geral de Proteção de Dados)
  • Os data centers em nuvem devem cumprir a certificação de segurança ISO 27001
  • Os sistemas devem atender a padrões específicos da indústria, como SOC 2, FISMA ou regulamentos FDA
  • Capacidades de registo de auditoria e de comunicação de informações para o cumprimento das regras

Requisitos de compatibilidade e interoperabilidade

Esses requisitos definem como o sistema funciona com outros sistemas, plataformas e tecnologias. Eles garantem integração e troca de dados sem descontinuidades em diferentes ambientes.

  • Compatibilidade com plataforma: Sistemas operacionais e dispositivos que o sistema deve suportar
  • Compatibilidade do navegador: Navegadores Web e versões que devem ser suportadas
  • Compatibilidade API: Normas e protocolos para integração do sistema
  • Compatibility formato de dados: Suporte para vários formatos e padrões de dados
  • Integração do Sistema de Legacy: Capacidade de trabalhar com sistemas existentes

Exemplo: Um programa em execução no Windows 10 deve ser capaz de executar no Windows 11 sem qualquer alteração em seu comportamento e desempenho.

Requisitos de capacidade

Os requisitos de capacidade especificam o volume de dados, transações e usuários que o sistema deve acomodar, tanto no momento como no futuro.

  • Capacidade de armazenamento: Quantidade de dados que o sistema deve armazenar
  • Capacidade do utilizador: Número máximo de utilizadores registados e concorrentes
  • Volume de transação: Número de transações processadas por período de tempo
  • Largura de banda da rede: Requisitos de transferência de dados

Exemplo: As páginas da página Web deverão carregar em 3 segundos com o número total de utilizadores simultâneos < 5 mil.

Comparação detalhada: Requisitos Funcionais vs. Não Funcionais

Compreender as diferenças entre requisitos funcionais e não funcionais é crucial para uma gestão eficaz de requisitos. Aqui está uma comparação abrangente:

Definição e Foco

Requisitos funcionais impulsionam a arquitetura de aplicação de um sistema, enquanto requisitos não funcionais impulsionam a arquitetura técnica de um sistema. Requisitos funcionais respondem "o que" o sistema faz, enquanto requisitos não funcionais respondem "como bem" ele faz isso.

Estilo de Documentação

Geralmente, os requisitos funcionais são expressos na forma "sistema deve fazer", enquanto requisitos não funcionais assumem a forma "sistema deve ser ". Esta distinção linguística reflete a diferença fundamental no que cada tipo de requisito especifica.

Método de ensaio

Os requisitos funcionais são normalmente testados através de métodos de teste funcionais, como teste unitário, teste de integração e teste de aceitação do usuário. Cada requisito funcional pode ser verificado verificando se o sistema produz a saída esperada para determinadas entradas.

Medindo Requisitos Não Funcionais: As características são mais fáceis de testar, mas qualidades como usabilidade, escalabilidade e confiabilidade são mais difíceis de medir e validar. Requisitos não funcionais requerem abordagens de teste especializadas, incluindo testes de desempenho, testes de segurança, testes de usabilidade e testes de estresse.

Impacto no sucesso do projeto

Requisitos funcionais e não funcionais são dois lados da mesma moeda. E juntos, eles criam softwares que são completos e utilizáveis. Ambos os tipos são essenciais, mas impactam projetos de forma diferente:

  • Requisitos funcionais determinam se o sistema pode executar tarefas necessárias
  • Requisitos não funcionais determinam se os usuários realmente querem usar o sistema
  • Os requisitos funcionais em falta resultam em funcionalidades incompletas
  • Faltam requisitos não funcionais que resultam em má experiência do usuário e qualidade do sistema

Desafios de priorização

Os requisitos funcionais recebem muitas vezes mais atenção, enquanto aspectos importantes como escalabilidade, segurança ou monitoramento podem ser ignorados, o que pode levar a sistemas que tecnicamente funcionam, mas que não atendem às expectativas de qualidade ou às necessidades dos negócios.

Por que ambos os requisitos são críticos para o sucesso do projeto

Os requisitos funcionais são a espinha dorsal do desenvolvimento de software e sistema bem sucedidos. Eles definem exatamente o que um produto deve fazer para atender às necessidades do usuário e do negócio. Ao especificar as funções e comportamentos que um sistema deve exibir, os requisitos funcionais garantem que cada recurso se alinha com as expectativas do usuário e objetivos do projeto.

No entanto, os requisitos funcionais por si só são insuficientes. Ambos os tipos de requisitos trabalham em conjunto para criar sistemas bem sucedidos:

Fornecendo clareza e direção

Having clearly defined functional requirements reduces the risk of miscommunication between stakeholders and your development team. This w