features functional requirements
Este tutorial explica os tipos, recursos, comparação de requisitos funcionais x não funcionais e requisitos comerciais x funcionais com exemplos:
Os requisitos funcionais definem o que um sistema de software deve fazer. Ele define uma função de um sistema de software ou seu módulo. A funcionalidade é medida como um conjunto de entradas do sistema em teste para a saída do sistema.
A implementação de requisitos funcionais em um sistema é planejada na fase de design do sistema, enquanto, no caso de requisitos não funcionais, ela é planejada no documento Arquitetura do sistema. O requisito funcional suporta a geração de requisitos não funcionais.
O que você aprenderá:
Requisitos funcionais e requisitos não funcionais
Requisitos funcionais
Vamos entender o que são requisitos funcionais com a ajuda de exemplos-
Exemplo: Em um projeto automotivo ADAS, um requisito funcional do sistema de visão surround poderia ser “A câmera traseira deve detectar uma ameaça ou objeto”. Os requisitos não funcionais aqui podem ser “a rapidez com que o alerta para um usuário deve ser exibido quando uma ameaça é detectada pelos sensores da câmera”.
Pegue outro exemplo do projeto de sistemas de informação e entretenimento. O usuário habilita o Bluetooth aqui a partir da HMI e verifica se o Bluetooth está habilitado ou não. Observação , outros serviços Bluetooth são ativados (de cinza a negrito) quando o usuário ativa o Bluetooth.
quais dispositivos operam na camada osi 2
Portanto, os requisitos funcionais falam sobre um determinado resultado do sistema quando uma tarefa é executada neles pelo usuário. Por outro lado, o requisito não funcional dá o comportamento geral do sistema ou seu componente e não da função.
Tipos de requisitos funcionais
Os requisitos funcionais podem incluir os seguintes componentes que podem ser medidos como parte do teste funcional:
# 1) Interoperabilidade: O requisito descreve se um sistema de software é interoperável em diferentes sistemas.
Exemplo: Para o requisito funcional do Bluetooth no sistema de infoentretenimento do carro, quando o usuário emparelha um smartphone com Android habilitado para Bluetooth ao sistema de infoentretenimento baseado em QNX, devemos ser capazes de transferir a lista telefônica para o sistema de infoentretenimento ou transmitir música do nosso telefone para o sistema de infoentretenimento.
Portanto, a interoperabilidade verifica se a comunicação entre os dois dispositivos diferentes é possível ou não.
Outro exemplo é dos sistemas de serviço de e-mail como o Gmail. O Gmail permite importar e-mails de outro servidor de troca de correio como Yahoo.com ou Rediffmail.com. Isso é possível devido à interoperabilidade entre os servidores de e-mail.
# 2) Segurança: O funcional requisito descreve o aspecto de segurança dos requisitos de software.
Exemplo: Serviços baseados em segurança cibernética no sistema baseado em câmera ADAS surround-view que usa Controller Area Network (CAN) que protege o sistema contra ameaças à segurança.
Outro exemplo é do site de rede social Facebook . Os dados de um usuário devem ser protegidos e não podem ser divulgados para terceiros. Esperamos que este exemplo do Facebook forneça um alcance mais amplo de segurança aos leitores devido à recente incidência de violação de dados no Facebook e às consequências enfrentadas pelo Facebook.
# 3) Precisão: A precisão define que os dados inseridos no sistema são calculados e usados corretamente pelo sistema e que a saída está correta.
Exemplo: Na rede de área do controlador, quando um valor de sinal CAN é transmitido pelo barramento CAN por uma ECU (viz. Unidade ABS, unidade HVAC, unidade de cluster de instrumento, etc.), outra ECU será capaz de identificar se os dados enviados estão corretos ou não via verificação CRC.
Outro exemplo pode ser de uma solução de banco online. Quando o usuário recebe um fundo, o valor recebido deve ser creditado exatamente na conta e nenhuma variação na precisão é aceita.
# 4) Conformidade: Os requisitos funcionais de conformidade validam que o sistema desenvolvido está em conformidade com os padrões industriais.
Exemplo: Se as funcionalidades dos perfis Bluetooth (viz. Streaming de áudio via A2DP, chamada telefônica via HFP) são compatíveis com as versões do perfil de lançamento Bluetooth SIG.
Outro exemplo pode ser o jogo da Apple Car no sistema de infoentretenimento do carro. O aplicativo no infoentretenimento obtém um certificado de maçã se todas as pré-condições mencionadas no site da Apple forem cumpridas por dispositivos Car Play de terceiros (neste caso, infotainment).
Outro exemplo pode ser de um aplicativo baseado na Web para o sistema de bilhetagem ferroviária. O site deve seguir as diretrizes de segurança cibernética e estar em conformidade com a World Wide Web em termos de acessibilidade.
Exemplo de formulário de requisito:
Já vimos o que é requisito funcional com alguns exemplos. Vamos agora ver como seria um requisito funcional quando integrado a ferramentas de gerenciamento de requisitos como o IBM DOORS. Existem vários atributos a serem levados em consideração ao documentar um requisito funcional na ferramenta de gerenciamento de requisitos.
Abaixo estão alguns atributos a serem levados em consideração:
- Tipo de objeto: Este atributo explica qual seção do documento de requisito faz parte deste atributo. Eles podem ser Título, Explicação, Requisito, etc. Principalmente a seção “Requisito” é considerada para a implementação e teste, enquanto as seções de título e explicação são usadas como descrições de apoio para requisitos para melhor compreensão.
- Pessoa responsável: Um autor que documentou o requisito na ferramenta de gerenciamento de requisitos.
- Nome do projeto / sistema: O projeto para o qual o requisito é aplicável, por exemplo, “Sistemas de informação e entretenimento para XYZ OEM (fabricante de equipamento original) uma empresa automotiva ou aplicativo da Web para a empresa limitada de bancos ABC”.
- Número da versão do requisito: Este campo / atributo notifica o número da versão do requisito se o requisito passou por várias modificações devido a atualizações do cliente ou mudanças no design do sistema.
- ID do requisito: Este atributo menciona o id de requisito exclusivo. A Id do requisito é usada para rastrear os requisitos no banco de dados facilmente e também para mapear os requisitos no código de forma eficiente. Também pode ser usado para fornecer uma referência aos requisitos ao registrar defeitos nas ferramentas de rastreamento de bugs.
- Descrição do requisito: Este atributo é um dos atributos mais importantes que explicam o requisito. Ao ler este atributo, um engenheiro seria capaz de entender o requisito.
- Status do requisito: O atributo de status do requisito informa sobre o status de um requisito na ferramenta de gerenciamento de requisitos, ou seja, se ele foi aceito, suspenso, rejeitado ou excluído do projeto.
- Comentários: Este atributo fornece à pessoa responsável ou gerente de requisitos uma opção para documentar qualquer comentário sobre o requisito. Exemplo: um possível comentário para um requisito funcional poderia ser “dependência de um pacote de software de terceiros para implementar o requisito”.
Um instantâneo do DOORS
Derivando Requisitos Funcionais de Requisitos de Negócios
Isso já é coberto como parte da seção “ Derivando requisitos funcionais de requisitos de negócios ' debaixo de Análise de Requisitos artigo.
Requisitos de negócios vs. requisitos funcionais
Esta diferença é vagamente coberta no Análise de requisitos artigo. Vamos, no entanto, tentar destaque mais alguns pontos aqui na tabela abaixo:
Sl. Não. | Requisitos de negócio | Requisitos funcionais |
---|---|---|
7 | Por exemplo, no sistema de banco on-line, um requisito de negócios poderia ser “Como usuário, devo ser capaz de obter o extrato da transação em dinheiro”. | O requisito funcional neste sistema de banco online pode ser, “Quando o usuário fornece o intervalo de datas na consulta de transação, esta entrada é usada pelo Servidor e a página da web é fornecida com os dados de transação de dinheiro necessários”. |
1 | Os requisitos de negócios dizem “qual” aspecto dos requisitos do cliente. Exemplo, O que deve estar visível para o usuário após o login do usuário. | Os requisitos funcionais dizem o aspecto “como” dos requisitos de negócios. Exemplo, Como a página da web deve exibir a página de login do usuário quando o usuário se autentica. |
dois | Os requisitos de negócios são identificados por analistas de negócios. | Requisitos funcionais são criados / derivados por desenvolvedores / arquiteto de software |
3 | Eles enfatizam o benefício para a organização e estão relacionados aos objetivos de negócios. | Seu objetivo é o cumprimento dos requisitos do cliente. |
4 | Os requisitos de negócios são do Cliente. | Os requisitos funcionais são derivados dos requisitos de software, que, por sua vez, são derivados dos requisitos de negócios. |
5 | Os requisitos de negócios não são testados por engenheiros de teste de software diretamente. Eles são testados principalmente pelo cliente. | Os requisitos funcionais são testados por engenheiros de teste de software e geralmente não são testados pelos clientes. |
6 | O requisito de negócios é um documento de requisito de alto nível. | Um requisito funcional é um documento de requisito técnico detalhado. |
Requisito não funcional
O requisito não funcional diz sobre “o que um sistema deve ser” ao invés de “o que um sistema deve fazer” (requisito funcional). Eles são derivados principalmente de requisitos funcionais com base em informações do cliente e de outras partes interessadas. Os detalhes da implementação de requisitos não funcionais estão documentados no documento Arquitetura do Sistema.
Requisitos não funcionais explicam os aspectos de qualidade do sistema a ser construído viz. desempenho, portabilidade, usabilidade, etc. Os requisitos não funcionais, ao contrário dos requisitos funcionais, são implementados de forma incremental em qualquer sistema.
URPS (Usabilidade, confiabilidade, desempenho e capacidade de suporte) de FURPS Os atributos de qualidade (Funcionalidade, Usabilidade, Confiabilidade, Desempenho e Suportabilidade) que são amplamente usados na indústria de TI para medir a qualidade de um desenvolvedor de software, são todos cobertos por requisitos não funcionais. Além disso, existem outros atributos de qualidade (detalhes na próxima seção).
A Wikipedia chama o requisito não funcional de 'ilidades' às vezes, devido à presença de vários atributos de qualidade, como portabilidade e estabilidade.
Tipos de requisitos não funcionais
Os requisitos não funcionais consistem nos subtipos abaixo (não exaustivos):
# 1) Desempenho:
Um tipo de atributo de desempenho de requisito não funcional mede o desempenho do sistema. Exemplo: No sistema de visão surround ADAS, “a visão da câmera traseira deve ser exibida dentro de 2 segundos após iniciar a ignição do carro”.
Outro exemplo de desempenho pode ser de um sistema de navegação de sistemas de infoentretenimento. “Quando um usuário vai para a tela de Navegação e entra no destino, a rota deve ser calculada em“ X ”segundos”. Mais um exemplo na página de login do aplicativo da web. “Tempo que leva para a página de perfil do usuário carregar após o login.”
Lembre-se de que a medição de desempenho do sistema é diferente da medição de carga. Durante o teste de carga, carregamos a CPU e a RAM do sistema e verificamos a taxa de transferência do sistema. No caso de desempenho, testamos o rendimento do sistema em condições normais de carga / estresse.
# 2) Usabilidade :
A usabilidade mede a usabilidade do sistema de software que está sendo desenvolvido.
Por exemplo , um aplicativo da web móvel foi desenvolvido para fornecer informações sobre a disponibilidade de encanadores e eletricistas em sua área.
A entrada para este aplicativo é o código postal e o raio (em quilômetros) de sua localização atual. Mas para inserir esses dados, se o usuário tiver que navegar por várias telas e a opção de entrada de dados for exibida em pequenas caixas de texto que não são facilmente visíveis para o usuário, então este aplicativo não é amigável e, portanto, a usabilidade do aplicativo será muito baixo.
# 3) Capacidade de manutenção :
A capacidade de manutenção de um sistema de software é a facilidade com que o sistema pode ser mantido. Se o tempo médio entre falhas (MTBF) for baixo ou o tempo médio de reparo (MTTR) for alto para o sistema que está sendo desenvolvido, a capacidade de manutenção do sistema é considerada baixa.
A capacidade de manutenção é geralmente medida em nível de código usando a complexidade ciclomática. A complexidade ciclomática diz que quanto menos complexo é o código, mais fácil é manter o software.
Exemplo: É desenvolvido um sistema de software que possui um grande número de códigos mortos (códigos não usados por outras funções ou módulos), altamente complexos devido ao uso excessivo da condição if / else, loops aninhados, etc. ou se o sistema é enorme com códigos em execução em muitos milhões de linhas de códigos e nenhum comentário adequado. Esse sistema é de baixa manutenção.
Outro exemplo pode ser uma página de compras online. Se houver muitos links externos no site para que o usuário possa ter uma visão geral do produto (isso para economizar memória), então a manutenção deste site é baixa. Isso ocorre porque, se o link da página da web externa mudar, ele terá que ser atualizado no site de compras online também e com muita frequência.
# 4) Confiabilidade :
A confiabilidade é outro aspecto da disponibilidade. Este atributo de qualidade enfatiza a disponibilidade de um sistema sob certas condições. É medido como MTBF assim como facilidade de manutenção.
Exemplo: Recursos mutuamente exclusivos, como câmera retrovisora e Trailer no sistema de câmera surround-view ADAS, devem funcionar de forma confiável no sistema, sem qualquer interferência entre si. Quando um usuário acessa o recurso Trailer, o retrovisor não deve interferir e vice-versa, pois os dois recursos acessam a câmera traseira do carro.
Outro exemplo do sistema de reivindicação de seguro online. Quando um usuário inicia o relatório de sinistro e, em seguida, carrega as contas de despesas relevantes, o sistema deve dar tempo suficiente para o upload ser concluído e não deve cancelar o processo de upload rapidamente.
# 5) Portabilidade:
Portabilidade significa a capacidade de um sistema de software trabalhar em um ambiente diferente se a estrutura dependente subjacente permanecer a mesma.
Exemplo: O sistema / componente de software em um sistema de infoentretenimento desenvolvido (por exemplo, serviço Bluetooth ou serviço multimídia) para um fabricante de automóveis deve permitir o uso em outro sistema de infoentretenimento com pouca ou nenhuma alteração no código, embora os dois sistemas de infoentretenimento sejam totalmente diferentes .
Vamos pegar outro exemplo do WhatsApp. É possível instalar e usar o serviço de mensagens no IOS, Android, Windows, Tablet, Laptop e Telefone.
# 6) Capacidade de suporte:
A facilidade de manutenção de um sistema de software é a capacidade de um serviço / especialista técnico de instalar o sistema de software em um ambiente em tempo real, monitorar o sistema enquanto ele está em execução, identificar quaisquer problemas técnicos no sistema e fornecer uma solução para resolver o problema.
A facilidade de manutenção é possível se o sistema for desenvolvido para facilitar a manutenção.
Exemplo: Fornecimento de pop-up de lembrete periódico ao usuário para uma atualização de software, mecanismo de registro / rastreamento para depurar problemas, recuperação automática de falha por meio de mecanismo de reversão (reverter o sistema de software para o estado de condição de trabalho anterior).
Outro exemplo a partir de Rediffmail. Quando houve uma atualização na versão do serviço de mala direta baseado na web, o sistema permitiu que o usuário mudasse para uma versão mais recente do sistema de mala direta mantendo a antiga intacta por alguns meses. Isso também melhora a experiência do usuário.
# 7) Adaptabilidade:
A adaptabilidade de um sistema é definida como a capacidade de um sistema de software de se adaptar às mudanças em um ambiente sem qualquer mudança em seu comportamento.
Exemplo: O Sistema de Frenagem Antibloqueio no Carro deve funcionar de acordo com o padrão em todas as condições climáticas (quente ou frio). Outro exemplo poderia ser o de um sistema operacional Android. É usado em diferentes tipos de dispositivos, viz. Smartphones, tablets e sistemas de informação e entretenimento e são altamente adaptáveis.
Além dos 7 requisitos não funcionais listados acima, temos muitos outros como:
testar meu site em diferentes navegadores
Acessibilidade, backup, capacidade, conformidade, integridade de dados, retenção de dados, dependência, implantação, documentação, durabilidade, eficiência, explorabilidade, extensibilidade, gerenciamento de falhas, tolerância a falhas, interoperabilidade, modificabilidade, operabilidade, privacidade, legibilidade, relatórios, resiliência, reutilização, Robustez, escalabilidade, estabilidade, testabilidade, taxa de transferência, transparência, integrabilidade.
Cobrir todos esses requisitos não funcionais está fora do escopo deste artigo. Você pode, no entanto, ler mais sobre esses tipos de requisitos não funcionais em Wikipedia.
Derivando Requisitos Não Funcionais de Requisitos Funcionais
Os requisitos não funcionais podem ser derivados de muitas maneiras, mas a melhor e a maioria das indústrias experimentadas e testadas é a partir dos requisitos funcionais.
Tomemos o exemplo de nossos sistemas de infoentretenimento que já examinamos em alguns lugares neste artigo. O usuário pode realizar várias ações no sistema de informação e lazer, viz. alterar a música, alterar a fonte da música de USB para FM ou áudio Bluetooth, definir o destino de navegação, atualizar o software de infoentretenimento por meio de uma atualização de software, etc.
# 1) Coleta de requisitos não funcionais:
Listaremos as tarefas realizadas por um usuário, o que faz parte dos requisitos funcionais. Uma vez que as ações do usuário são anotadas no diagrama de caso de uso UML (cada oval), iniciaremos perguntas relevantes (cada retângulo) em cada ação do usuário. As respostas a essas perguntas fornecerão nossos requisitos não funcionais.
# 2) Categorização de requisitos não funcionais:
A próxima etapa é a categorização dos requisitos não funcionais que identificamos por meio de perguntas. Nesta fase, podemos verificar a resposta possível e categorizar as respostas para possíveis categorias não funcionais ou diferentes qualidades.
Na imagem abaixo você pode ver os possíveis atributos de qualidade identificados a partir das respostas.
Requisitos Funcionais Vs Não Funcionais
Já vimos o que são requisitos funcionais e não funcionais e como eles são derivados. Vamos dar uma olhada nas principais diferenças entre requisitos funcionais e não funcionais.
Sl. não | Requisitos funcionais (FR) | Requisitos não funcionais (NFR) |
---|---|---|
7 | Requisitos funcionais formam o esqueleto da implementação do sistema de software | Os requisitos não funcionais completam o sistema SW, ajudando os requisitos funcionais a se unirem, como um músculo. |
1 | Eles dizem, o que um sistema deve fazer. | Eles dizem o que um sistema deve ser. |
dois | Eles são detalhados no documento System Design. | Eles são detalhados no documento de arquitetura do sistema. |
3 | Eles falam sobre o comportamento de uma função ou recurso. | Eles falam sobre o comportamento de trabalho de todo um sistema ou de um componente do sistema e não de uma função específica. |
4 | O usuário irá passar a entrada e verificar se a saída é exibida corretamente. | Quando o usuário passa uma entrada, as seguintes perguntas podem ser respondidas por NFRs: i) Quanto tempo leva para exibir a saída? ii) A produção é consistente com o tempo? iii) Existem outras maneiras de passar o parâmetro de entrada? iv) Quão fácil é passar o parâmetro de entrada? |
5 | Em um aplicativo da web, o usuário deve ser capaz de fazer o login via autenticação é FR | Em um aplicativo da web, quanto tempo leva para fazer login no site, a aparência da página de login, a facilidade de uso de uma página da web, etc. fazem parte do NFR |
6 | Os requisitos funcionais são derivados primeiro dos requisitos de software. | Os requisitos não funcionais são derivados dos requisitos funcionais. |
8 | Os requisitos funcionais podem existir sem um requisito não funcional. | Requisitos não funcionais não podem existir sem requisitos funcionais. |
9 | Um requisito funcional fornece informações concretas sobre um recurso, Exemplo , A foto do perfil no Facebook deve estar visível no login. | Um requisito funcional pode ter muitos atributos de requisitos não funcionais. Exemplo, tempo para fazer login (desempenho), aparência e comportamento da página de perfil (usabilidade), número de usuários que podem fazer login por vez (capacidade, desempenho) |
10 | Derivar requisitos funcionais de requisitos de SW é possível para quase todos os requisitos de negócios | Freqüentemente, os NFRs não são documentados, pois não são feitas perguntas relevantes sobre os FRs. |
onze | A implementação de um requisito funcional normalmente é feita em um build de software. | Os NFRs são implementados ao longo do ciclo de vida do projeto até que o comportamento desejado seja alcançado. |
12 | Estes são principalmente visíveis para o cliente. | Geralmente, estes não são visíveis para o cliente, mas podem ser experimentados a longo prazo. Exemplo, Usabilidade, desempenho, etc. podem ser experimentados apenas a longo prazo, mas não podem ser visíveis de forma alguma. |
Conclusão
Os requisitos formam o bloco de construção básico para desenvolver qualquer sistema de software. É possível construir um sistema com requisitos funcionais, mas suas habilidades não podem ser determinadas nem medidas. Dito isso, é muito importante ter requisitos funcionais de boa qualidade derivados de um requisito de negócios para ter um sistema de software funcional de alta qualidade.
Conseqüentemente, os requisitos funcionais fornecem a direção da implementação de um sistema de software, mas os requisitos não funcionais determinam a qualidade da implementação que os usuários finais terão.
Leitura recomendada
- Como testar a especificação de requisitos de software (SRS)?
- Teste Funcional Vs Teste Não Funcional
- Como testar um aplicativo sem requisitos?
- O que é análise e coleta de requisitos no SDLC?
- 5 erros mortais no gerenciamento de requisitos e como superá-los
- Características dos requisitos funcionais e requisitos não funcionais
- Como Criar Matriz de Rastreabilidade de Requisitos (RTM): Exemplo e Modelo de Amostra
- As 20 melhores ferramentas de gerenciamento de requisitos (a lista completa)