Requisito funcional ou não funcional?

Estou pensando em requisitos funcionais ou não funcionais. Encontrei muitas definições diferentes para esses termos e não posso atribuir alguns dos meus requisitos à categoria adequada.

Estou pensando em requisitos que não estão conectados a alguma ação ou têm algumas condições adicionais, por exemplo:

1. Na lista de dispositivos selecionados, o dispositivo pode ser repetido.
2. O banco de dados deve conter pelo menos 100 itens
3. A moeda de algum valor deve estar em dólares americanos.
4. O dispositivo deve ter um nome e um valor de consumo de energia em Watts.

esses requisitos são funcionais ou não funcionais?

Os requisitos funcionais definem o que o sistema ou aplicativo fará - especificamente no contexto de uma interação externa (com um usuário ou com outro sistema).

Ao fazer um novo pedido, o sistema deve exibir o custo total e exigir confirmação do usuário. Esse é um requisito funcional; descreve uma função do sistema.

Consulte Wikipedia: Requisito Funcional para obter mais detalhes.

Requisitos não funcionais são aqueles que não descrevem o comportamento de entrada / saída do sistema. Observe que ainda estamos falando de requisitos , não de detalhes de implementação , portanto, apenas porque estamos usando a frase "não-funcional" não significa que algo seja justo para colocar nessa seção.

Os tipos mais comuns de requisitos não funcionais que você verá relacionados à operação do sistema (disponibilidade, continuidade, DR), desempenho (taxa de transferência, latência, capacidade de armazenamento) e segurança (autenticação, autorização, auditoria, privacidade).

Todas essas são preocupações transversais que afetam todos os "recursos", mas ainda não são realmente recursos; eles são mais como metadados de recursos, ajudando a descrever não apenas se o sistema faz o que deveria, mas também o quão bem ele faz. Não leve essa analogia longe demais - é apenas uma analogia.

Os requisitos não funcionais não são subjetivos ou ondulatórios, ao contrário do que algumas pessoas aqui parecem sugerir. De fato, eles realmente devem ter uma métrica rígida anexada a eles (ou seja, tempo de resposta não superior a 100 ms). Os requisitos da NF também não são detalhes de implementação ou tarefas como "atualizar a estrutura ORM" - nenhuma pista de onde alguém teria essa ideia.

Mais detalhes na Wikipedia: Requisitos não funcionais .

Para abordar especificamente os exemplos na pergunta:

1. Na lista de dispositivos selecionados, o dispositivo pode ser repetido.

   • Claramente um requisito funcional. Descreve como é a saída do sistema.

2. O banco de dados deve conter pelo menos 100 itens

   • Parece uma regra de negócios, também um requisito funcional. No entanto, parece incompleto. Qual o motivo dessa regra? O que acontecerá / deverá acontecer se o banco de dados contiver menos de 100 itens?

3. A moeda de algum valor deve estar em dólares americanos.

   • Requisito funcional, mas não realmente adequado. Uma redação mais útil seria: O sistema deve suportar uma moeda (USD). Obviamente, isso seria alterado se mais de uma moeda precisasse ser suportada, e o requisito precisaria incluir informações sobre conversões de moeda e assim por diante.

4. O dispositivo deve ter um nome e um valor de consumo de energia em Watts.

   • Não é realmente nenhum tipo de requisito, é mais como uma especificação técnica. Um requisito funcional seria declarado como a potência nominal assumida em Watts. Se houver mais de uma UOM, como na moeda, os requisitos funcionais devem ter seções sobre conversões de unidades, onde / como elas estão configuradas etc. (se aplicável).

Já existe uma excelente resposta de Aaronaught, mas como outras respostas, agora removidas, estavam totalmente erradas sobre o que é um requisito não-funcional, acho que seria útil adicionar algumas explicações para evitar erros. requisito não-funcional é.

Um requisito não funcional é "uma qualidade ou propriedade que o produto deve ter" ¹. James Taylor diz que um requisito não-funcional "[...] é [no entanto] um requisito, e é importante para o cliente - às vezes até mais importante que um requisito funcional" . Ele então dá dois exemplos: o logotipo do produto e a precisão e confiabilidade do equipamento. Esses dois exemplos mostram muito bem que:

• Os requisitos não-funcionais não são como um tagarela de marketing: "A Internet é importante hoje em dia e queremos ter um site".
• Os requisitos não funcionais dizem respeito aos clientes, pois eles podem impactar fortemente sua produtividade e a capacidade de usar o produto.
• Os requisitos não funcionais são totalmente objetivos.

O último ponto é essencial. Se o requisito é subjetivo, não há nada a fazer na lista de requisitos. Seria impossível criar testes de validação a partir de algo subjetivo . O único objetivo da lista de requisitos é enumerar as expectativas não ambíguas do cliente. "Quero que este quadrado seja vermelho" é um requisito. "Quero que este quadrado tenha uma cor bonita" é um desejo que requer explicação.

Lembre-se de que a lista de requisitos é como um contrato (e na maioria dos casos faz parte de um contrato). Ele é assinado pelo cliente e pela empresa de desenvolvimento e, no caso de um litígio, será usado legalmente para determinar se você fez seu trabalho corretamente. E se eu solicitar um produto de software, especificar que "o produto deve ser ótimo" e se recusar a pagar quando o produto estiver pronto, porque, para mim, o que você realmente fez não é um ótimo produto?

Então, vamos ver alguns exemplos.

  1. O produto de software é responsivo ao usuário final.

Isso não é um requerimento. Não é funcional. Não é um não funcional. Não é apenas um requisito. Em absoluto. Tem valor zero. Você não pode verificar se o sistema de software atende a esse requisito durante o teste de validação. Nem você - o departamento de controle de qualidade, nem o cliente.

  2. O recarregamento das estatísticas do usuário executa 90% do tempo abaixo de 100 ms. quando testado na máquina com os desempenhos especificados no apêndice G, parte 2, e a carga abaixo de 10% para a CPU, abaixo de 50% para memória e nenhuma operação de disco R / W ativa.

É um requisito. Se o apêndice G, parte 2, for preciso o suficiente, posso levar a máquina com o hardware semelhante e executar o teste de validação no departamento de controle de qualidade e sempre obterei um resultado binário: aprovado ou reprovado.

É um requisito funcional? Não. Ele não especifica o que o sistema deve fazer. Provavelmente havia um requisito funcional antes, especificando que o aplicativo de software deve poder recarregar as estatísticas do usuário.

É um requisito não funcional? Isto é. Ele especifica uma propriedade que um produto deve ter, ou seja, o tempo máximo / médio de resposta, dado o limite percentual.

  3. O aplicativo está escrito em C #.

Isso é um requisito? Realmente não sabemos sem um contexto. Pode ser um desejo do desenvolvedor principal, que deseja, inserindo esse requisito, evitar mais tarde uma discussão com seus colegas sobre o idioma a ser usado. Também pode ser um requisito baseado em hardware / software, elementos herdados ou de compatibilidade. Nós não sabemos.

  4. A base de código C # do produto segue as Regras Mínimas Recomendadas da Microsoft e as Regras de Globalização da Microsoft.

Isso é uma coisa estranha. Pessoalmente, prefiro não chamá-lo de requisito e colocá-lo em um documento separado, especificando os padrões e as melhores práticas.

  5. A janela principal do aplicativo possui uma borda azul (# 00f) de 10 px com círculos preenchidos em rosa (#fcc), esses círculos sendo colocados na borda interna da borda e com 3 px de diâmetro, separados por 20 px.

É um requisito e não funcional. Ele especifica algo que podemos testar durante o teste de validação e especifica uma propriedade do produto, não o que o produto deve fazer.

  6. O sistema de rastreamento de veículos mede a velocidade com uma precisão de ± 0,016 mph.

Também um requisito não funcional. Ele fornece um limite mensurável da precisão do sistema. Ele não diz o que o sistema deve fazer, mas diz quão preciso é seu trabalho. Mas espere? Diz que o sistema de rastreamento de veículos mede a velocidade, não é? Portanto, também é um requisito funcional? Bem, não, uma vez que enfatizamos a precisão da medição, não o fato de a medição ser feita.

  7. O sistema de rastreamento de veículos mede a velocidade do veículo.

Agora é um requisito funcional. Não diz como o sistema funciona, mas o que está fazendo. Através de requisitos funcionais, pudemos aprender que o sistema de rastreamento de veículos mede a velocidade, a energia da bateria, a pressão de não sei o que e se as luzes estão acesas ou não.

  8. As páginas do site levam 850 ms. carregar.

Isso não é um requerimento. Is tenta ser um, mas é totalmente inválido. Como você classificaria isso? Que páginas? Todos? Testado através de uma rede local de 1 Gbps em uma máquina cliente de quatro núcleos e um servidor de oito núcleos com SSDs usados ​​a 2% ou através de um modem de um laptop antigo e ruim enquanto o site está sendo hospedado por um pequeno servidor usado a 99% ? O que se entende por "carregar"? Isso significa baixar a página? Baixando e exibindo? Enviando a solicitação POST com alguns dados grandes, carregando a resposta e exibindo-a?

Para concluir, um requisito não-funcional é sempre um requisito, o que significa que descreve algo que é totalmente objetivo e pode ser verificado através de um teste de validação manual ou automatizado, mas, em vez de dizer o que o sistema está fazendo, explica como o sistema está fazendo algo ou como o próprio sistema é .

^{¹ Gerenciamento de projetos de tecnologia da informação: Aplicação de estratégias de gerenciamento de projetos a iniciativas de software, hardware e integração, James Taylor, ISBN: 0814408117.}

Um requisito funcional descreve o resultado da interação com o sistema (o que o sistema faz em determinadas situações), enquanto um requisito não funcional geralmente se refere a especificações de desempenho, capacidade, tempo de resposta, etc. coisas que não representam funcionalidade, processo no sistema ou o resultado de uma interação.

Dito isto, o requisito não funcional que você está descrevendo é, na verdade, um requisito funcional com uma especificação técnica (o que realmente o tornaria um requisito ruim). Um exemplo de requisito não funcional para o seu caso seria algo como isto:

- A interface do usuário não deve estar bloqueada enquanto a animação dos dados estiver em execução.

Os requisitos do usuário geralmente são requisitos específicos da interface do usuário, que, dependendo do contexto, seriam funcionais ou não funcionais, enquanto os requisitos do sistema (capacidade do usuário simultânea, por exemplo) geralmente não são funcionais na maioria das vezes.

Apenas para acrescentar a algumas boas respostas existentes que os requisitos não funcionais às vezes são chamados de "ilidades" - qualidades que o sistema precisa possuir além de sua funcionalidade simples. "ilidades" incluem disponibilidade, usabilidade, segurança, flexibilidade - e ainda mais estética subjetiva.

Alguns deles são muito difíceis de especificar e avaliar. No entanto, eles importam. Se você estiver assinando com eles contratualmente, evite as versões sem sentido onduladas à mão, como "O sistema deve ser seguro". O problema de tentar definir esses requisitos é que as pessoas tendem a gravitar para coisas facilmente mensuráveis, e não para as que importam (e os requisitos podem muito bem ser escritos por pessoas que não têm nenhuma base nas especialidades relevantes) ) O resultado final é que você geralmente acaba com sistemas que não são seguros, utilizáveis ​​nem flexíveis (a disponibilidade não é tão difícil de especificar e medir, embora ainda cause muitas dores de cabeça).

Existem diferenças culturais aqui entre pessoas que lidam com contratos e outras coisas formais, e pessoas que lidam na análise mais geral, arquitetura, pesquisa etc. A exigência de mão-ondulado vaga é ainda uma exigência , tanto quanto o último está em causa, porque expressa coisas que importam para o cliente, mesmo que simpatizem completamente com as pessoas contratuais de que não é um requisito contratual útil até que tenha sido explorado em detalhes e minuciosamente estabelecido.

Um ponto final - se você ainda não pode propor uma medida objetiva de uma "ilidade", isso não significa que o cliente não precise dela. Vague! = Desnecessário. No entanto, isso pode significar que precisamos desenvolver melhores maneiras de medir essas coisas, extrair e refinar os requisitos não funcionais de forma incremental ou contrair de maneiras (Agile etc.) que possam funcionar sem medidas objetivas iniciais para tudo.

Esses comentários são muito bons, mas são muito cozidos e não oferecem um modelo claro para trabalhar. Não seria claro especificá-lo como:

Na minha opinião, um requisito funcional é o que o usuário experimenta ao usar o aplicativo. É um requisito que precisa ser atendido quando um desenvolvedor tenta implementar isso do zero, fazer aprimoramentos ou modificações. Por exemplo: o usuário deve efetuar login. Digamos que se você também adicionar uma nova maneira de executar o aplicativo por meio de um prompt de comando, o usuário ainda precisará fazer login.

Um requisito não funcional acontece sob o capô. O usuário não está ciente disso, mas precisa estar lá, no entanto, é implementado. Por exemplo: O aplicativo deve ser desenvolvido em C #. Se for desenvolvido em qualquer outro idioma, o usuário não notará. Mas isso pode ser um requisito, pois é baseado no código existente. Outro exemplo seria que ele deve ser instalado em determinado servidor. A movimentação de servidores não seria percebida pelo usuário.

Funcional ou não funcional? Eu também não diria. A maioria, se não todos os exemplos listados, parecem regras de negócios para mim (especificando restrições relacionadas ao processo e regras de decisão que os processos do sistema devem seguir).

Eles são algo que muitos engenheiros esquecem ou desconhecem, pois as regras de negócios geralmente são coletadas como parte da análise de negócios (e geralmente incorporadas às especificações de requisitos funcionais em vez de referenciadas externamente).

Um requisito funcional é geralmente algo que o sistema pode ou fará. Pode ser expresso como resultado de uma ação (De um resultado negativo). Um requisito não-funcional é algo com o qual o cliente / usuário final não se importa e não afeta o resultado - por exemplo, o
Windows terá uma borda azul com pontos cor-de-rosa. - O programa será escrito em Java
- Qualquer coisa a ver com padrões, métodos e processos de codificação.

Entretanto, esteja avisado de que os requisitos não funcionais podem ser transformados em requisitos funcionais pelos clientes. exemplos: - O programa será escrito em Erlang porque o cliente leu um artigo de revista e deseja que ele seja escrito em Erlang. - O programa deve usar o DB 2. porque o cliente o executará em seus sistemas DB 2 existentes, possui anos de experiência e uma equipe de TI familiarizada com essa plataforma.
- O código fonte deve passar por todas as recomendações MISRA.

Em resumo - se o cliente se importa com isso, é um requisito funcional, caso contrário, é um requisito não funcional ou possivelmente nem mesmo um requisito.

Eu acho que os requisitos funcionais são uma coisa necessária para descrever o sistema e seu comportamento, mas os requisitos não funcionais não são necessários para o sistema e não são reunidos durante as negociações do projeto do sistema, são apenas os resultados do sistema, como qualidade da cobertura de velocidade , segurança, manutenção etc. do sistema construído.