Specifiche dei requisiti del software e schemi

Per me, l'obiettivo fondamentale dello SRS è dire al team del software cosa dovrebbe fare il software . Questa è un'alternativa al solo fatto di andare avanti (aka "agile").

Se stai orientando verso gli oggetti, allora devi adottare un'analisi orientata agli oggetti e un approccio alla progettazione. Molto probabilmente, il primo passo è identificare gli attori nello SRS e identificare gli oggetti (ce ne può essere solo uno a questo livello).

Quindi puoi sviluppare casi d'uso. Probabilmente sono molti i diagrammi dei casi d'uso, a meno che tu non voglia un diagramma mostruosamente grande.

In seguito, suddividerai gli oggetti in pacchetti, quindi in classi.

La coerenza è garantita dalla tracciabilità, fino in fondo. Ogni requisito del software deve essere indirizzato da qualcosa sotto di esso nel tuo progetto (spesso un caso d'uso, ma non sempre). Una "matrice dei requisiti" è spesso il modo migliore per documentarlo.

In casi estremi (come quelli critici per la sicurezza), potrebbe essere necessario andare così lontano con la tracciabilità dei requisiti che se qualcuno punta a una riga del tuo codice e chiede "a cosa serve?", puoi risalire fino in fondo eseguire il backup per rispondere esattamente ai requisiti che sta aiutando a soddisfare.

Non rendere le cose più complicate di loro. Lo SRS è semplicemente un documento che descrive cosa dovrebbe fare il software, ma non come lo farà. Può essere un testo semplice, ma spesso ha senso includere i diagrammi. Spesso è una buona idea usare diagrammi UML standardizzati come Use Case o Activity. Ma questo non è assolutamente necessario.

Una specifica dei requisiti del software (SRS) è uno strumento per aiutare nella comunicazione tra le parti interessate. Non ha lo scopo di ridurre al minimo il tempo e gli sforzi o ridurre i costi, oltre ad aiutare a facilitare le comunicazioni. I documenti SRS descrivono l'ambito, forniscono un punto di partenza per la creazione di casi di test e danno una cosa tangibile da esaminare e discutere.

Standard IEEE 29148-2011 - Standard internazionale ISO / IEC / IEEE - Ingegneria dei sistemi e del software - Vita cicli di lavorazione - L'ingegneria dei requisiti è lo standard corrente per la struttura e il contenuto di un SRS. Sebbene gran parte della discussione riguardi i requisiti testuali, lo standard riconosce altri metodi di acquisizione dei requisiti, inclusi i modelli visivi. UML (e linguaggi o tecniche simili) dovrebbero essere inclusi come modelli visivi. Lo standard menziona anche il flusso di dati, il flusso di controllo, i modelli di stato, i modelli di oggetti, "e molti altri".

La definizione di metodi e approcci per i modelli visivi per i requisiti software è qualcosa su cui puoi ottenere un intero libro .

Personalmente, alcuni modelli si prestano meglio all'ingegnerizzazione dei requisiti rispetto ad altri. In UML, trovo che i diagrammi Activity, State, Deployment e Use Case tendono a prestarsi meglio all'ingegnerizzazione dei requisiti (sebbene raccomando di evitare i diagrammi Use Case nella maggior parte dei casi). Ciò non esclude l'utilizzo di altri modelli (diagrammi di classe, diagrammi di sequenza), ma probabilmente saranno a bassa fedeltà. Considera anche le modalità UML , in particolare UML come schizzo , nonché le tecniche Agile Modeling .