Ho alcuni requisiti del tipo
Li vedo come ambigui. Qualcuno può pensare a un modo di scriverli in modo inequivocabile?
I requisiti possono essere verificati in modo obiettivo.
I requisiti funzionali specificano una capacità del sistema e possono essere testati abbastanza facilmente. Per esempio. il requisito "Come utente, posso fare clic su un pulsante per ottenere un'immagine di gatto divertente" può essere testato assumendo il ruolo di un utente e facendo clic sul pulsante. Ho ricevuto una foto di gatto? In tal caso, il requisito è stato soddisfatto dal sistema.
I requisiti non funzionali specificano una qualità del sistema, ma questa qualità deve essere misurabile o verificabile. Una qualità è la performance del sistema. Un desiderio "il sistema dovrebbe essere veloce" non è un requisito perché non può essere testato, misurato, verificato. Cos'è "veloce"? Un requisito come "Il sistema può gestire 200 buffe richieste di immagini di gatti al secondo" può essere verificato oggettivamente attraverso un test di carico, e quindi è un requisito valido.
Se hai a che fare con desideri vaghi che non possono essere verificati, è compito di uno sviluppatore di software chiarirli. Spesso, c'è un requisito più fondamentale sotto questi desideri. Perché l'installazione distribuita è importante, perché il cablaggio dovrebbe essere ridotto? C'è forse un requisito di affidabilità nascosto? Cosa succede se riesci a soddisfare il requisito reale meglio non utilizzando un sistema distribuito? Qual è la quantità massima accettabile di cablaggio? Ogni funzione è un compromesso: possiamo scambiare più cavi per alcune funzionalità più importanti?
Sebbene i requisiti non dovrebbero in genere prescrivere dettagli di implementazione del sistema, è spesso ragionevole imporre alcuni vincoli di progettazione, specialmente se toccano le decisioni strategiche di un'organizzazione. Per esempio. se un'azienda decidesse di standardizzare l'hardware da un fornitore specifico, il sistema dovrà vivere entro questi limiti.
Ma non tutti i requisiti sono ugualmente importanti. Tecniche come il metodo MoSCoW ci permettono di valutare la loro importanza (deve, dovrebbe, potrebbe, o non lo sarà) (confronta anche RFC 2119 ). Alcune capacità o qualità sono desiderabili ma non assolutamente necessarie. I tuoi requisiti "il più possibile" potrebbero essere riformulati per essere misurabili, ma avere una priorità media. Per esempio:
- The system MUST continue to operate even when any one server fails.
- The system SHOULD use the same hardware and operating system for all servers.
No. La regola uno dei requisiti è che dovrebbero essere verificabili. Nessuno di questi è così che dovrebbero essere buttati fuori o perfezionati.
Entrambi i requisiti contengono la parola "possibile" che dovrebbe essere definita. Il "possibile" di un uomo è "impossibile" da un altro uomo.
Questi sono migliori (anche se avrebbero ancora bisogno di perfezionare):
Il primo requisito è non verificabile e non verificabile, come giustamente osserva Robbie Dee. Se portato al limite, si finisce con i file jar contenenti solo una singola classe.
Il secondo requisito è quasi così.
"to reduce development and maintenance costs, the same hardware shall be used for different subsystem's when possible"
Questo significa che quando l'hardware è estremamente sottodimensionato per l'attività, dovrebbe comunque essere usato ma richiede la riscrittura del software per ottimizzarlo? Una parola migliore sarebbe "fattibile", poiché si tratta chiaramente di un qualificatore economico che consente la giustificazione e il ragionamento basati su costi e benefici relativi.
Leggi altre domande sui tag requirements specifications