requisitos funcionais - use palavras baseadas em verbos?
Os requisitos funcionais em um documento de requisitos devem usar palavras baseadas em verbos?
Tarefa escolar, trabalhando em equipe, trabalhando no SDLC. O documento de requisitos foi concluído e agora estamos no design.
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ê".
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.
dois ovos, presunto, bacon, queijo ... que tem de ser forno apoiado queijo com bacon borrifado e decorado com ovo cru ... sim eu acho que eu entendi
Sua idéia de um documento de requisitos tem um verbo: "has". Não são apenas substantivos.
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á.
U / A / T: há algum dever de casa para mim! É reconfortante obter confirmação de que QUAL é o objetivo. Mostrar justificativa pode precisar de algum trabalho. Obrigado.
PS - obrigado por reconhecer o conceito e o contexto geral, em vez de se concentrar no cenário "omelete", oferecido apenas para simplificar, fornecer algo concreto e não expor detalhes; estava no topo da minha cabeça; improviso, realmente.
@yas Não tem problema, bom em você por fazer um esforço para melhorar os requisitos depois de perceber que eles eram muito desajeitados!
— CFL_Jeff 27/03
É normal ter requisitos de nível superior e inferior, onde os superiores são divididos em inferiores - em um projeto que envolve design, em vez de apenas codificação, eu esperaria uma árvore de requisitos, não apenas os atômicos de nível mais baixo.
"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".
Na verdade, estou bastante alinhado com esta resposta. Estávamos até usando o seguinte padrão para expressar requisitos funcionais (e esse padrão ajuda bastante): Um determinado sistema deve (fazer, criar, ferver ...) algo, em uma determinada condição, com os desempenhos mencionados.
— Marc-Emmanuel Coupvent des Gra 29/01
... 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.
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á.
Não esperava essa resposta; nós nunca discutimos estilos funcionais versus objetos. A linguagem fornecida é Java e eu / nós (?) Presumimos o estilo Object. Parece que deixar de lado o Java como linguagem foi um descuido da minha parte. Sua resposta me dá uma visão que eu não esperava! Obrigado pela resposta.
— 26712
Os requisitos funcionais de um sistema não têm a ver com a implementação de seus componentes de software em um estilo de programação funcional, mas são aqueles que governam o fluxo ou a transformação de matéria, energia ou informação (consulte o artigo "Engineering Design" de Pahl e Beitz, 1988, e John Gero, Modelo de design de função, comportamento e estrutura, ou vários outros requisitos de engenharia ou documentos e livros de design).
@PeteKirkham: Eu não fiz essa afirmação.
Então, por que você está falando sobre programação funcional?
@PeteKirkham: Você me pegou ... Pensamento lateral, suponho.
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:
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.
Atualmente, um dos produtos de software em funcionamento está falhando, pois usa muita CPU para o gabinete à prova de respingos no qual o sistema é executado para dissipar o calor. Embora você possa definir alguns requisitos como verbos - 'o sistema de monitoramento portátil deve estar em um gabinete que atenda aos padrões de entrada de água IP 4' - parece que o único verbo é 'come' e nenhum comportamento do componente que está causando um risco que o requisito não será atendido e está presente no requisito do cliente.
@PeteKirkham Você descreveu um problema de hardware. Especificamente, uma especificação de forma, não de função. Isso não invalida minha resposta à pergunta do OP, que é sobre especificação funcional. No entanto, abordando o caso que você descreveu, sua especificação funcional pode ser "Dada 'Configuração de software X', quando o uso da CPU exceder (uma limitação e tempo pré-especificados) e esperar uma falha do sistema". Melhor ainda, substitua "falha do sistema" por um "processo de recuperação" para especificar como evitar falhas. Às vezes, precisamos pensar um pouco criativamente para descobrir comportamentos específicos. :-)