Quale è una buona strategia per etichettare i requisiti software in uno SRS?
Normalmente la numerazione del profilo viene utilizzata nelle intestazioni, ma queste verranno rinumerate se nel documento viene inserita una nuova intestazione. Per me sembra una buona idea puntare a una designazione più stabile per ogni esigenza software. Ciò dovrebbe rendere più facile fare riferimento a un requisito particolare anche di fronte a un SRS aggiornato.
Quali sono le tue esperienze su questo?
Una strategia:
Esistono altre strategie, come l'utilizzo di decimali tratteggiati per i requisiti del cluster, ad esempio:
Come puoi immaginare, i rispettivi requisiti devono essere ordinati sotto il numero di livello superiore di conseguenza: 1.1, 1.2 ... per GUI, 2.1, 2.3, 2.4 per DB, ecc. Si noti che questa strategia richiederà una qualche forma di metodo controllato per la gestione di cancellazioni e aggiunte.
La cosa fondamentale da applicare in un documento dei requisiti: una volta che un ID è stato utilizzato per un requisito, non può essere riutilizzato un altro requisito. In altre parole, se SRS 1234 è stato utilizzato e quindi eliminato, non può riemergere in seguito. (Permettendogli di fare ciò distrugge in modo assoluto la tracciabilità dei requisiti nel corso di un progetto in evoluzione.)
Si noti che virtualmente qualsiasi organizzazione / struttura SRS avrà delle carenze. Scegli quello che si adatta al tuo ambiente di sviluppo e le tue esigenze applicative. (Ad esempio, le strategie di cui sopra funzionano ragionevolmente bene in ambienti di sviluppo altamente controllati, come quelli monitorati dalla FDA o da altri organismi governativi.)
Infine, considera l'utilizzo di uno strumento di gestione dei requisiti. Ce ne sono di buoni là fuori (open source to $$$$$) che si prenderanno cura di tutto questo per te.
Il miglior modo di pensare concettuale è che i Requisiti siano elementi distinti, correlati l'uno all'altro in vari modi e, pertanto, dovrebbero essere archiviati in un Database. L'uso di un elaboratore di testi per archiviare i requisiti è il modo sbagliato e causa molti problemi poiché guida il pensiero concettuale secondo cui "i requisiti sono un documento", quindi questa domanda. Se devi utilizzare un elaboratore di testi, tieni separati i requisiti, proprio come faresti se avessi usato Word per archiviare i contatti.
Pertanto, l'uso della numerazione dei contorni per mantenere i requisiti causerà problemi. Immagina di provare a incrociare il test di riferimento e SRS e le esigenze del cliente se cambi i numeri? Immagina di discutere di "Requisito 10.2.3.1" solo per scoprire che nel documento di ieri hai inviato il cliente che era "10.2.2.1"
I requisiti sono un'etichetta e dovrebbero dare poco significato. Potresti avere uno o un breve prefisso da 2 a 5 lettere per identificare lo scope o l'unità, ma nel momento in cui ne hai diverse migliaia, qualsiasi significato implicito dovrebbe essere limitato. per esempio. in un'auto potresti avere EM-FUEL-1234 (Gestione del motore, sistema di controllo del carburante, requisito 1234).
I requisiti dovrebbero poter essere riutilizzati tra i progetti.
I requisiti devono essere unici, oltre l'ambito e la vita del progetto. Come guida, cambiare un requisito per chiarire è lo stesso numero, ma per modificarlo in modo significativo, elimina quello vecchio e sostituiscilo. Utilizzare uno schema di versione (Append_1, _2 ecc.) Può essere utile.
Se è necessario utilizzare Word per archiviare questo database, un buon metodo è utilizzare i token di inizio e fine per identificare i requisiti. Se si utilizza uno stile di carattere univoco per la numerazione dei requisiti, diventa facile evidenziare, cercare ed estrarli utilizzando Macro (in un database, ad esempio). L'esempio potrebbe essere
#Req 1234 #
Bla bla bla bla
#ReqEnd #
#Req 1234a #
Bla bla bla bla e più bla
#ReqEnd #
Leggi altre domande sui tag requirements requirements-management