requisitos funcionais - use palavras baseadas em verbos?

Questão

Os requisitos funcionais em um documento de requisitos devem usar palavras baseadas em verbos?

Contexto

Tarefa escolar, trabalhando em equipe, trabalhando no SDLC. O documento de requisitos foi concluído e agora estamos no design.

Problema

O documento de requisitos possui uma lista enumerada do que eu chamaria de recursos do aplicativo - os requisitos funcionais. Nessa lista estão coisas que eu consideraria "como é", em vez de "como é", e agora, tentando trabalhar no design, sinto que uma parte do design foi ditada prematuramente.

Eu não fiz isso antes! Para mim, eu deveria estar lidando estritamente com coisas que descrevem "o quê".

Exemplo de corrente

Finja que o trabalho é fazer uma omelete. Listagem: quebrar o ovo, quebrar na tigela, mexer, etc .; atravessa a linha para o território de como. Ao longo dessa trilha, o mesmo ocorre com as palavras: criar, gerar, listar, calcular, determinar, validar etc. - verbos basicamente. No momento, tenho uma lista de requisitos parcialmente enraizados nos verbos.

Minha idéia de um documento de requisitos para uma omelete seria mais ou menos: tem dois ovos, x onças de presunto, x onças de bacon, x onças de queijo-montery jack, x onças de coentro, etc. - nada além do que (substantivos) .

Eu poderia ter falado antes de finalizar o documento de requisitos, se eu tivesse alguma experiência.

Você pode e deve usar verbos em seus requisitos. O importante é garantir que cada requisito seja:

• Não ambíguo - cada requisito pode significar apenas uma coisa e só pode ser interpretado de uma maneira.
• Atômica - cada requisito não pode ser dividido em vários requisitos.
• Testável - é possível demonstrar que cada requisito foi atendido ou não por meio de alguma forma de teste.

Você ficaria surpreso com a qualidade dos seus requisitos, seguindo estas três diretrizes a todo custo.

Além disso, certifique-se de escrever uma justificativa para cada requisito. Isso é muito importante e útil no futuro, quando alguém se pergunta por que um requisito específico foi criado.

E sim, você está correto, os requisitos devem descrever o que o software fará, não como o fará.

"Os requisitos funcionais em um documento de requisitos devem usar palavras baseadas em verbos?"

A resposta curta é "sim", mas o caminho para chegar lá é sinuoso.

Se o documento de requisitos for uma coleção de instruções "shall" escritas como sentenças em inglês, você deverá ter uma frase verbal. E essa frase verbal será "deve xxx" como em "o sistema deve xxx". A parte "xxx" é um dos três tipos de verbos "be", "do" e "have". Essas frases devem descrever o sistema como uma caixa preta, registrando apenas as coisas que podem ser vistas de fora. Como você disse, "o que e não o como". Se é visível do lado de fora, é um "o quê".

A única função possível disponível para um sistema digital é alterar o valor de uma variável. Portanto, todos os requisitos funcionais devem indicar qual variável foi alterada e os cálculos usados ​​para fazer a alteração. Estes são os requisitos "do".

Os requisitos "be" tendem a descrever recursos em vez de funções. "O sistema deve ser capaz de ...". Eles descrevem um "estado de ser".

Os requisitos "have" são os substantivos sobre os quais você falou. "O sistema deve ter ..." Eles fornecem os substantivos para as sentenças de requisitos funcionais.

Em um nível alto, existem muito poucos requisitos funcionais. A maioria dos requisitos são requisitos de recursos, requisitos de desempenho ou requisitos de composição (têm).

Todos os requisitos de alto nível que precisam de filhos são, por definição, ambíguos. Se fossem inequívocos, não precisariam de filhos para defini-los. Além disso, um requisito só é inequívoco se a maioria das pessoas em uma revisão de requisitos declarar que é. Ou seja, a ambiguidade é subjetiva. A definição mais próxima de um requisito FUNCIONAL inequívoco que eu conheço está em BarBaraBea.com na página "Requisitos funcionais inequívocos". Basicamente, diz-se que todos os substantivos em um requisito funcional devem ser derivados das entradas do sistema por meio de uma cadeia de requisitos funcionais inequívocos, e que a declaração da computação no requisito deve descrever um algoritmo. A definição de "algoritmo" é muito menos subjetiva do que a definição de "requisito inequívoco".

... Finja que o trabalho é fazer uma omelete. Listagem: quebrar o ovo, quebrar na tigela, mexer, etc .; atravessa a linha para o território de como ...
...
Minha idéia de um documento de requisitos para uma omelete seria mais parecida: tem dois ovos, x onças de presunto, x onças de bacon, x onças de bacon, x onças de queijo de montery jack , x onças de coentro, etc. - nada além do que (substantivos) ...

Bem, para omelete, eu preferiria os requisitos da primeira versão do que a segunda, simplesmente porque a segunda versão me coloca em risco de receber dois ovos, x onças de presunto, etc. - nada além disso, nem fritos nem mexidos.

A segunda versão garante obter o que eu preciso, mas também é um pouco chata - só porque a única maneira de garantir que os requisitos sejam atendidos parece ser ficar na cozinha observando atentamente cada passo de cada refeição.

Veja bem, eu preferiria requisitos que de alguma forma me permitissem testar / verificar o resultado sem ser obrigado a observar como você prepara a refeição.

Uma maneira de conseguir isso seria especificar requisitos como passando comparação por referência. Usando o exemplo omelete, eu faria meu próprio omelete de "referência" seguindo as mesmas instruções que você e compararia o seu por estar próximo o suficiente dele.

• ^{Usei essa abordagem quando precisei testar uma versão altamente otimizada de um algoritmo específico. O "omelete de referência" neste caso foi apresentado por um algoritmo simplificado e não otimizado. Eu corro a mesma entrada com dois tipos de algoritmo e verifiquei se a saída produzida pela versão otimizada estava próxima o suficiente da referência.}

Outra maneira seria declarar requisitos para que estes descrevam o resultado. Para omeletes, seria "4 oz de ovos mexidos e fritos, etc ...". Eu lidei principalmente com esse tipo de requisitos - acho que é o modo mais típico.

• ^{Por uma questão de completude, provavelmente tenho que descrever outro tipo de especificação de requisitos com os quais lidei - com base em testes. Não consigo imaginar uma maneira que não parecesse ruim para um exemplo de omelete - algo como "quando um especialista olha e prova, eles dizem OK" - mas tenho que admitir, no único caso que eu já vi usado para software , também não parecia particularmente inteligente.}

Um programa funcional é composto de funções. O que são funções? Eles são métodos que executam ações. O que são palavras de ação? Verbos.

Se você estivesse fazendo programação orientada a objetos, estaria trabalhando com substantivos. Na verdade, você estaria trabalhando com substantivos e verbos.

Estilo funcional:

crack(egg)

Estilo orientado a objetos:

egg.Crack();

No nível de requisitos, não tenho certeza de que nada disso importa, embora certamente seria útil se os requisitos fossem declarados na forma de ações, pois as funções são o que você escreverá.

Todos os requisitos podem ser essencialmente reduzidos a uma coleção de instruções que giram em torno do uso de verbos. Sim, você pode inserir alguns substantivos e adjetivos, mas são os verbos que descrevem como um sistema se comporta e o que o cliente deseja que o software faça. Mesmo uma grande parte da funcionalidade específica de estado de um programa pode ser pensada em termos de comportamento quando você apresenta o estado através de métodos getter e setter.

É como CFL_Jeff menciona na resposta dele , que você deseja que seus requisitos descrevam o que um sistema fará, e não para descrever como deve ser feito. É possivelmente por isso que considero o desenvolvimento orientado pelo comportamento tão atraente, porque incentiva o uso de verbos descrevem requisitos e o uso de verbos ao escrever testes de unidade para descrever requisitos como comportamentos a serem testados.

Considere por um momento os seguintes requisitos e modelos de cenário:

• As an {actor} I want to {do something} in order to {achieve an outcome}
• Given {an initial context} When {something is done} Then {expect an outcome}

No BDD, os recursos são sempre o bit descrito na seção "Quero" do modelo e sempre são carregados com verbos que descrevem o que o recurso faz. Ao testar, um Given-When-Thenmodelo é usado para validar cenários específicos relativos ao recurso e, mais uma vez, a seção "Quando" do modelo é sempre definida pelos verbos utilizados, que se relacionam de alguma maneira com os verbos usados ​​na especificação do recurso.

Usando seu exemplo omelete, definir vários comportamentos como uma série faz muito sentido. Você tem uma coleção de comportamentos e resultados e, como uma série, eles formam um fluxo de trabalho. Se você deveria definir uma lista de ingredientes, está efetivamente descrevendo a arquitetura muito livremente, no entanto, você fica com muitas perguntas. Qual é o fluxo de trabalho? Como os ingredientes devem ser usados? Você está basicamente perdendo a "cola" que guiará suas decisões sobre como montar seu sistema e como ele deve se comportar.

Ao definir requisitos em termos de comportamentos e resultados, você é capaz de fornecer uma imagem muito clara do que deseja que o software atinja, sem se preocupar em como atingir especificamente esses resultados no software.