requisiti funzionali - usa una formulazione basata sui verbi?

Puoi e dovresti usare i verbi nei tuoi requisiti. L'importante è assicurarsi che ogni requisito sia:

• Univiguous - ogni requisito può significare solo una cosa e può essere interpretata solo in un modo.
• Atomico : ogni requisito non può essere suddiviso in più requisiti.
• Testabile : è possibile dimostrare che ogni requisito è stato rispettato o non è stato raggiunto tramite una qualche forma di test.

Saresti sorpreso di quanto siano soddisfacenti le tue esigenze seguendo solo queste tre linee guida a tutti i costi.

Inoltre, assicurati di scrivere una logica per ciascun requisito. Questo è molto importante e utile lungo la strada quando qualcuno si chiede perché è stato creato un particolare requisito.

E sì, sei corretto, i requisiti dovrebbero descrivere COSA il software farà, non come lo farà.

"I requisiti funzionali in un documento requisiti dovrebbero utilizzare termini basati sui verbi?"

La risposta breve è "sì", ma il percorso per arrivarci è tortuoso.

Se il documento requisiti è una raccolta di dichiarazioni "shall" scritte come frasi inglesi, è necessario avere una frase verbale. E quella frase verbale sarà "deve xxx" come in "il sistema deve xxx". La parte "xxx" è uno dei tre tipi di verbi, "essere", "fare" e "avere". Queste frasi devono descrivere il sistema come una scatola nera, registrando solo quelle cose che possono essere viste dall'esterno. Come hai detto, "il cosa piuttosto che il come". Se è visibile dall'esterno è un "cosa".

L'unica funzione possibile disponibile per un sistema digitale è la modifica del valore di una variabile. Pertanto, tutti i requisiti funzionali devono indicare quale variabile è stata modificata e i calcoli utilizzati per eseguire la modifica. Questi sono i requisiti "fai".

I requisiti "essere" tendono a descrivere caratteristiche piuttosto che funzioni. "Il sistema deve essere in grado di ...". Descrivono uno "stato di essere".

I requisiti "avere" sono i nomi di cui hai parlato. "Il sistema deve avere ..." Forniscono i nomi per le frasi dei requisiti funzionali.

A un livello elevato ci sono pochissimi requisiti funzionali. La maggior parte dei requisiti sono requisiti di caratteristiche, requisiti di prestazione o requisiti di composizione (avere).

Tutti i requisiti di alto livello che richiedono bambini sono, per definizione, ambigui. Se fossero inequivocabili, non avrebbero bisogno di bambini per definirli. Inoltre, un requisito è solo non ambiguo se la maggioranza delle persone in una revisione dei requisiti dichiara che lo è. I.e, l'ambiguità è soggettiva. La definizione più vicina per un requisito FUNZIONALE univoco che io conosca è su BarBaraBea.com nella pagina "Requisiti Unambientali dei requisiti". Fondamentalmente si dice che tutti i nomi in un requisito funzionale devono essere derivati dagli input del sistema attraverso una catena di requisiti funzionali non ambigui e che l'affermazione del calcolo nel requisito deve descrivere un algoritmo. La definizione di "algoritmo" è molto meno soggettiva della definizione di "requisito non ambiguo".

...Pretend that the job is to make an omelet. Listing: crack the egg, break into bowl, scramble, etc.; crosses over the line into the territory of how...
...
My idea of a requirements doc for an omelet would be more like: has two eggs, x ounces of ham, x ounces of bacon, x ounces of montery-jack cheese, x ounces of cilantro, etc. - nothing but what (nouns)...

Bene per l'omelette, preferirei i requisiti della prima versione al secondo, semplicemente perché la seconda versione mi mette a rischio di ottenere due uova, x once di prosciutto, ecc. - nient'altro che, né fritto né criptato.

La seconda versione garantisce di ottenere ciò di cui ho bisogno, ma in qualche modo fa schifo - solo perché l'unico modo per assicurarsi che i requisiti siano soddisfatti sembra essere stare in cucina osservando attentamente ogni singolo passo per preparare un pasto.

Vedete, preferirei requisiti che in qualche modo mi permettessero di testare / verificare il risultato senza essere obbligati a guardare come si prepara il pasto.

Un modo per ottenere ciò sarebbe specificare i requisiti come confronto di passaggio con riferimento. Usando l'esempio di omelette, vorrei creare la mia omeletta di "riferimento" seguendo le stesse istruzioni che hai tu, quindi confronta il tuo per esserti abbastanza vicino.

• ^{Ho usato questo approccio quando avevo bisogno di testare una versione strongmente ottimizzata di un particolare algoritmo. "L'omelette di riferimento" in questo caso è stata presentata da un algoritmo semplificato e non ottimizzato. Ho eseguito lo stesso input con due tipi di algoritmo, quindi ho verificato se l'output prodotto dalla versione ottimizzata era abbastanza vicino al riferimento.}

Un altro modo sarebbe quello di indicare i requisiti in modo che questi descrivano il risultato. Per omelette sarebbe come "4 once di uova, strapazzate e fritte, ecc ...". Mi sono occupato principalmente di questo tipo di requisiti - penso che questo sia il modo più tipico.

• ^{Per motivi di completezza, probabilmente dovrò descrivere ancora un altro tipo di requisiti che ho specificato, basati sui test. Non riesco ad immaginare un modo che non suona male per l'esempio di omelette - qualcosa come "quando l'esperto lo guarda e lo assaggia, dicono OK" - ma devo ammettere che, nel solo caso in cui l'ho visto usato per il software non è stato particolarmente intelligente neanche}

Un programma funzionale è composto da funzioni. Quali sono le funzioni? Sono metodi che eseguono azioni. Quali sono le parole d'azione? Verbi.

Se stavi programmando oggetti orientati, dovresti lavorare con i nomi. In realtà, lavoreresti con nomi e verbi.

Stile funzionale:

crack(egg)

Stile orientato agli oggetti:

egg.Crack();

A livello dei requisiti, non sono sicuro che ciò sia importante, anche se sarebbe certamente utile se i requisiti fossero dichiarati sotto forma di azioni, poiché le funzioni sono ciò che scriverete.

Tutti i requisiti possono essere essenzialmente ridotti a una raccolta di affermazioni che ruotano attorno all'uso dei verbi. Sì, puoi inserire pochi nomi e aggettivi, ma sono i verbi che descrivono come si comporta un sistema e che cosa desidera che il cliente faccia il software. Anche molte funzionalità specifiche dello stato di un programma possono essere pensate in termini di comportamento quando si presenta lo stato tramite metodi getter e setter.

È proprio come CFL_Jeff cita in la sua risposta , che vuoi avere i tuoi requisiti che descrivono cosa un sistema fare e non descrivere come dovrebbe essere fatto. Questo è probabilmente il motivo per cui trovo lo sviluppo basato sul comportamento così avvincente, perché incoraggia l'uso dei verbi a descrivere i requisiti e l'uso di verbi durante la scrittura di unit test per descrivere i requisiti come comportamenti da testare.

Considerare per un momento i seguenti requisiti e modelli di scenario:

• 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}

In BDD, le funzionalità sono sempre descritte nella sezione "Voglio" del modello e sono sempre caricate con verbi che descrivono ciò che fa la funzione. Durante il test, viene utilizzato un modello Given-When-Then per convalidare scenari specifici relativi alla funzione, e ancora una volta la sezione "Quando" del modello è sempre definita dai verbi utilizzati, che si riferiscono in qualche modo ai verbi utilizzati nel specifica delle caratteristiche.

Usando il tuo esempio di omelete, definire un numero di comportamenti come una serie ha molto senso. Hai una collezione di comportamenti e risultati, e come serie formano un flusso di lavoro. Se invece dovessi definire una lista di ingredienti, stai descrivendo l'architettura in modo molto approssimativo, tuttavia ti rimangono molte domande. Qual è il flusso di lavoro? Come sono gli ingredienti da usare? In pratica manchi la "colla" che guiderà le tue decisioni su come mettere insieme il tuo sistema e come dovrebbe comportarsi il tuo sistema.

Definendo i requisiti in termini di comportamenti e risultati, sei in grado di fornire un'immagine molto chiara di ciò che desideri ottenere dal software, senza preoccuparti di come ottenere specificamente tali risultati nel software.