Perché preoccuparsi di distinguere tra requisiti funzionali e non funzionali?

Comprendo la differenza tra i due, ma i miei colleghi mi chiedono il vantaggio dei requisiti di etichettatura come funzionali o non funzionali (o transitori). Perché preoccuparsi di farlo? Trascorse due giorni trascorrendo un elenco di requisiti per un progetto e non ne trasse alcun vantaggio, poiché il risultato finale fu di presentare il documento a un'altra entità commerciale con l'editto "Fai tutto".

Ciò che temo sono i requisiti raggruppati in un unico documento. Ho cercato di spiegare il vantaggio in termini pratici, ma non sono riuscito a venderlo. Come posso vendere il vantaggio di documentare quali requisiti sono funzionali e quali non funzionali.

La separazione esplicita dei requisiti renderà più semplice la progettazione del sistema giusto.

Con requisiti non funzionali (preferisco il concetto / il termine attributi di qualità - dovrebbe fornire nuove intuizioni oltre funzionali rispetto a non funzionali), sei più interessato alle proprietà del software piuttosto che alla funzionalità. Ecco come il sistema svolge alcune funzioni, non semplicemente quello che fa il sistema. I requisiti di qualità hanno un'influenza significativa sull'architettura del sistema in modi in cui i requisiti funzionali non lo fanno e per questo motivo dovrebbero essere trattati in modo diverso.

Mantenere gli attributi di qualità separati dai requisiti funzionali consente di analizzare, specificare e dare priorità ai diversi tipi di requisiti in diversi modi. Ad esempio, gli attributi di qualità vengono normalmente specificati utilizzando uno scenario di attributi di qualità, mentre i requisiti funzionali possono assumere la forma di storie, casi d'uso, dichiarazioni devono o qualsiasi altro numero di formati. La maggior parte dei sistemi su cui ho lavorato aveva meno di una dozzina di attributi di qualità e molti, molti più requisiti funzionali.

Vorrei effettivamente introdurre un altro tipo di requisiti: i vincoli tecnici . Ancora una volta, la separazione esplicita dei requisiti in questi tre bucket fornisce indicazioni su come effettuare i giusti compromessi durante la costruzione del sistema. I requisiti funzionali sono spesso abbastanza negoziabili, gli attributi di qualità influenzeranno fortemente la tua architettura e le strutture che scegli, i vincoli tecnici non sono negoziabili.

Se questo fosse il mio team, direi loro che i requisiti dovrebbero essere chiaramente annotati per tipo per assicurarsi che non ci perdiamo qualcosa di importante nell'architettura. Pensa ai driver dell'architettura, non solo alla funzionalità.

Anthony Lattanze in Architecting Software Intensive Systems: A Practitioners Guide offre una panoramica pratica dei driver dell'architettura e del perché dovrebbero essere trattati in modo diverso, molto più completo del mio sommario qui.

Quando ogni requisito ha la stessa priorità / peso (in particolare "Obbligatorio"), probabilmente dovrai preoccuparti di più della semplice suddivisione dei requisiti funzionali e non funzionali.

Tuttavia, ci sono diversi motivi per separare le due categorie di requisiti:

Responsabilità per l'implementazione Ho scoperto che molti requisiti non funzionali - in particolare quelli incentrati sulle prestazioni, sono solo moderatamente applicabili allo sviluppatore. Sebbene una progettazione possa supportare scalabilità e velocità (e possono essere ottimizzate specifiche sezioni di codice) in generale la capacità di soddisfare qualsiasi requisito prestazionale dipende dall'architettura e spesso dal tempo alla configurazione hardware.

Responsabilità per i test Quanto è abile l'utente o il team di controllo qualità nel verificare che siano soddisfatti i requisiti di sicurezza, tolleranza agli errori, sicurezza e affidabilità?

Non ripetere te stesso La documentazione dovrebbe seguire lo stesso principio DRY del codice. I requisiti comuni di stile dell'interfaccia utente devono essere raggruppati insieme. Se la persona responsabile dei requisiti lo desidera davvero, può fare riferimento ai requisiti non funzionali (individualmente o come gruppo) nei requisiti funzionali.

Controllo delle versioni Se ci si trova in ambienti aziendali con molti "standard", è possibile scrivere documenti specifici sui requisiti dell'interfaccia utente o della sicurezza (per nominare un paio) che possono essere sottoposti a versione. In questo modo è possibile scrivere nei requisiti specifici dell'applicazione (principalmente Requisiti funzionali): "L'applicazione deve aderire alla V2.3 dei requisiti di sicurezza definiti in XYZ-Company-SecReq-DocumnentNamingStandard.docx".

Perché preoccuparsi di distinguere tra requisiti funzionali e non funzionali?

Una ragione per differenziare è il livello di astrazione tra i due tipi. I requisiti non funzionali sono a livello di sistema e indicano come deve comportarsi il sistema nel suo insieme. I requisiti funzionali si riferiscono a una caratteristica specifica e quali caratteristiche e funzionalità devono essere fornite ai clienti.

I requisiti non funzionali limitano anche il sistema, mentre i requisiti funzionali indicano cosa deve fare il sistema. I requisiti non funzionali forniscono limitazioni su come i requisiti funzionali devono essere progettati e implementati in un secondo momento. Separandoli, diventa possibile identificare chiaramente le caratteristiche dai vincoli e dalle limitazioni.

Ciò che temo sono i requisiti raggruppati in un unico documento. Ho cercato di spiegare il vantaggio in termini pratici, ma non sono riuscito a venderlo. Come posso vendere il vantaggio di documentare quali requisiti sono funzionali e quali non funzionali.

Nelle mie esperienze, i requisiti funzionali e non funzionali sono effettivamente raggruppati nello stesso documento o tracciati nello stesso sistema. Tuttavia, vengono fornite sezioni separate e separate del documento, nonché criteri di successo per soddisfarle.

Generalmente, classifichi i requisiti per aiutare il team a fornire risultati contro di loro. Se esiste un requisito specificamente mirato a un'esigenza architettonica, chiamarlo requisito "Architettura" dovrebbe aiutare il team a lavorare sull'architettura.

Un grande documento unico di tutti i requisiti non è necessariamente una cosa negativa ... Trascorrere 2 giorni a rivederlo non è male. Il problema è in genere che una volta che una persona ha esaminato i requisiti, li comprende, ma non è più facile per chiunque fare lo stesso. Può essere di grande aiuto iniziare i requisiti di etichettatura con metadati che aiuteranno le altre persone che si uniranno al progetto.

Forse prova a descriverlo come un problema di astrazione. Se devi lavorare in una base di codice legacy, non devi solo leggere tutte le righe di codice esistenti, quindi iniziare a funzionare. Segui la struttura del codice per aiutarti. Avere una struttura nei requisiti aiuta allo stesso modo.

Ci sono molti vantaggi nella separazione.

1. Risparmia tempo sui test (ovvero verifica solo i requisiti funzionali)
2. Risparmia tempo sulle future modifiche ai requisiti (ad esempio, i requisiti non funzionali impiegheranno meno tempo per rivedere / approvare / implementare / testare)
3. In un mondo regolamentato (cioè FDA, ecc.), I requisiti non funzionali richiedono 1/10 della quantità di documenti richiesti da un requisito funzionale.
4. Offre al team la possibilità di dividere il lavoro tra membri del team senior (funzionale) e junior (non funzionale).

Potrei andare avanti ...

In superficie due giorni sembrano molto tempo, a lungo termine potrebbe salvare settimane o addirittura mesi di lavoro futuro.