Por que incomodar a diferenciação entre requisitos funcionais e não funcionais?

Entendo a diferença entre os dois, mas sou questionado por meus colegas sobre o benefício dos requisitos de rotulagem como funcionais ou não funcionais (ou transitórios). Por que se preocupar em fazer isso? Ele passou o que ele disse serem dois dias revisando uma lista de requisitos para um projeto e não viu nenhum benefício para ele, porque o resultado final foi enviar o documento para outra entidade comercial com o edital "Faça tudo".

O que temo são os requisitos agrupados em um documento. Tentei explicar o benefício em termos práticos, mas não consegui vendê-lo. Como posso vender o benefício de documentar quais requisitos são funcionais e quais não são funcionais.

Separar explicitamente os requisitos facilitará o projeto do sistema certo.

Com requisitos não funcionais (prefiro os atributos de qualidade do conceito / termo - deve fornecer novos insights além do funcional versus não funcional), você está mais preocupado com as propriedades do software do que com a funcionalidade. É assim que o sistema executa alguma função, não apenas o que o sistema faz. Os requisitos de qualidade têm uma influência significativa na arquitetura do sistema, de maneira que os requisitos funcionais não têm e, por esse motivo, devem ser tratados de maneira diferente.

Manter os atributos de qualidade separados dos requisitos funcionais permite analisar, especificar e priorizar diferentes tipos de requisitos de maneiras diferentes. Por exemplo, os atributos de qualidade são normalmente especificados usando um cenário de atributo de qualidade, enquanto os requisitos funcionais podem assumir a forma de histórias, casos de uso, declarações de dever ou qualquer outro número de formatos. A maioria dos sistemas em que trabalhei tinha menos de uma dúzia de atributos de qualidade e muitos, muitos mais requisitos funcionais.

Na verdade, eu introduziria outro tipo de requisitos - restrições técnicas . Novamente, a separação explícita dos requisitos nesses três blocos fornece dicas sobre como fazer as trocas corretas ao criar o sistema. Os requisitos funcionais geralmente são bastante negociáveis, os atributos de qualidade influenciam fortemente sua arquitetura e as estruturas que você escolher; as restrições técnicas não são negociáveis.

Se essa fosse minha equipe, eu diria a eles que os requisitos devem ser claramente anotados por tipo para garantir que não perdamos algo importante na arquitetura. Pense nos drivers de arquitetura, não apenas na funcionalidade.

Anthony Lattanze em Arquitetura de sistemas intensivos de software: um guia para profissionais fornece uma visão geral prática dos drivers de arquitetura e por que eles devem ser tratados de maneira diferente, muito mais abrangente do que o meu resumo aqui.

Quando todo requisito tem uma prioridade / peso iguais (particularmente "Obrigatório"), provavelmente você tem mais com o que se preocupar do que apenas dividir os requisitos Funcionais e Não Funcionais.

No entanto, existem várias razões para separar as duas categorias de requisitos:

Responsabilidade pela implementação Descobri que muitos requisitos não funcionais - particularmente aqueles focados no desempenho, são apenas moderadamente aplicáveis ​​ao desenvolvedor. Embora um design possa suportar escalabilidade e velocidade (e seções de código específicas possam ser ajustadas), em geral, a capacidade de atender a qualquer requisito de desempenho depende da arquitetura e geralmente depende da configuração do hardware.

Responsabilidade pelos testes Qual é a aptidão do usuário ou da equipe de controle de qualidade para verificar se os requisitos de segurança, tolerância a falhas, segurança e confiabilidade são atendidos?

Não se repita A documentação deve seguir o mesmo princípio DRY do código. Os requisitos comuns de estilo da interface do usuário devem ser agrupados. Se a pessoa responsável pelos requisitos realmente deseja, pode fazer referência a requisitos não funcionais (individualmente ou em grupo) nos requisitos funcionais.

Controle de versão Se você estiver em um ambiente corporativo com muitos "padrões" - poderá escrever documentos específicos de requisitos de interface do usuário ou segurança (para citar alguns) que podem ser versionados. Dessa forma, você pode escrever nos requisitos específicos do aplicativo (principalmente Requisitos funcionais): "O aplicativo deve seguir a V2.3 dos Requisitos de segurança definidos em XYZ-Company-SecReq-DocumnentNamingStandard.docx".

Por que incomodar a diferenciação entre requisitos funcionais e não funcionais?

Uma razão para diferenciar é o nível de abstração entre os dois tipos. Os requisitos não funcionais estão no nível do sistema e dizem como o sistema como um todo deve se comportar. Os requisitos funcionais se referem a um recurso específico e quais recursos e funcionalidades devem ser fornecidos aos clientes.

Os requisitos não funcionais também restringem o sistema, enquanto os requisitos funcionais dizem o que o sistema deve fazer. Os requisitos não funcionais fornecem limitações sobre como os requisitos funcionais devem ser projetados e implementados posteriormente. Ao separá-los, torna-se possível identificar claramente os recursos das restrições e limitações.

O que temo são os requisitos agrupados em um documento. Tentei explicar o benefício em termos práticos, mas não consegui vendê-lo. Como posso vender o benefício de documentar quais requisitos são funcionais e quais não são funcionais.

Nas minhas experiências, os requisitos funcionais e não funcionais são realmente agrupados no mesmo documento ou rastreados no mesmo sistema. No entanto, eles recebem seções próprias e separadas do documento, bem como critérios de sucesso para atender a cada uma.

Geralmente, você categoriza os requisitos para ajudar a equipe a cumprir com eles. Se houver um requisito especificamente direcionado a uma necessidade de arquitetura, chamá-lo de requisito de "Arquitetura" deve ajudar a equipe ao trabalhar na arquitetura.

Um documento grande e único de todos os requisitos não é necessariamente uma coisa ruim ... Passar 2 dias revendo também não é ruim. O problema geralmente é que, uma vez que uma pessoa reviu os requisitos, eles os compreendem, mas não é mais fácil para ninguém fazer o mesmo. Pode ser uma grande ajuda começar a rotular requisitos com metadados que ajudarão as outras pessoas que ingressam no projeto.

Talvez tente descrevê-lo como um problema de abstração. Se você precisar trabalhar em uma base de código herdada, não basta ler todas as linhas de código existentes e começar a trabalhar. Você segue a estrutura do código para ajudá-lo. Ter alguma estrutura nos requisitos ajuda da mesma maneira.

Existem vários benefícios para a separação.

1. Economize tempo no teste (ou seja, apenas teste os requisitos funcionais)
2. Economiza tempo em futuras alterações nos requisitos (ou seja, requisitos não funcionais levarão menos tempo para revisar / aprovar / implementar / testar)
3. Em um mundo regulamentado (isto é, FDA, etc.), Os requisitos não funcionais exigem 1/10 da quantidade de papelada exigida por um requisito funcional.
4. Dá à equipe a capacidade de dividir o trabalho entre os membros seniores (funcionais) e juniores (não funcionais) da equipe.

Eu poderia continuar ...

Na superfície, dois dias parecem muito tempo, a longo prazo, poderia economizar semanas ou até meses de trabalho futuro.