Per prima cosa, desidero normalizzare i termini.
Gli standard ISO e IEEE fanno riferimento a Specifiche dei requisiti del software (SRS), Descrizione dell'architettura e Descrizione della progettazione del software (SDD), che possono essere in qualsiasi formato (database, wiki, documenti elettronici, pagine scritte a mano). Un SRS identifica le informazioni che devono essere prese in considerazione quando si acquisiscono i requisiti (attributi funzionali e non funzionali / qualità) per la creazione o l'acquisto di software. Una descrizione dell'architettura definisce punti di vista, framework e linguaggi di descrizione architettonica per i sistemi (che possono includere o meno software). Un SDD contiene rappresentazioni di modelli di progettazione del software e motivazioni per uno o più stakeholder e indicazioni per l'uso dei linguaggi di progettazione.
DO-178 utilizza un diverso set di terminologia. I requisiti di sistema sono i requisiti tecnici per il sistema in costruzione 1 . I requisiti di sistema sono scomposti in requisiti di alto livello, che sono una serie di requisiti di blocco per il software. I requisiti di alto livello vengono utilizzati per creare l'architettura del software e i requisiti di basso livello, che si informano a vicenda. L'architettura ei requisiti di basso livello catturano i vincoli di progettazione, le definizioni di input e output, i flussi di dati e di controllo, la gestione delle risorse e la logica di progettazione. L'architettura e i requisiti di basso livello vengono utilizzati per creare il codice sorgente.
Dobbiamo anche considerare le caratteristiche dei buoni requisiti . I requisiti devono essere completi (le informazioni sono riunite in un unico posto), non ambigue (formulate in modo conciso senza parole in eccesso e soggette a una sola interpretazione) e verificabili (l'attuazione del requisito può essere confermata mediante ispezione, dimostrazione, strumentazione, test, e / o analisi).
Ora che abbiamo definito alcuni termini chiave, possiamo esaminare il problema in questione: i requisiti del software dovrebbero contenere unità?
In generale, sì, i requisiti dovrebbero contenere unità. Questo è necessario per avere requisiti completi e non ambigui. Queste unità forniscono informazioni ai progettisti e ai test. Per i progettisti, ottengono il contesto del sistema. Può informare le decisioni riguardanti input e output, sia di interfacce pubbliche che private. I tester ottengono anche una chiara comprensione di quali input validi sono, a tutti i livelli, dal livello di sistema al livello di unità.
Nel mondo ISO / IEEE, oltre a una guida associata a requisiti completi e non ambigui in un SRS, un SDD spesso contiene un dizionario dei dati . Un dizionario dati conterrà informazioni sulla fonte dei dati, il formato in cui i dati entrano e l'utilizzo. Se i dati rappresentano qualcosa che può essere misurato, cose come intervalli validi, unità e intervalli di errore verranno spesso specificati nel dizionario dei dati.
Nel mondo DO-178, i requisiti di sistema e di alto livello contengono quasi sempre unità. Queste unità eseguiranno il mapping al sistema, al sottosistema e ai test di integrazione condotti. La migliore descrizione di lavorare con requisiti di alto livello e basso livello I requisiti che ho letto erano che i requisiti di alto livello sono una descrizione di ciò che si sta progettando e implementando, mentre i requisiti di basso livello forniscono istruzioni specifiche su come progettare e implementare. Poiché un punto chiave di DO-178 è la tracciabilità dai requisiti di sistema fino al bytecode (in particolare ai livelli A e B), i requisiti di basso livello avranno meno probabilità di contenere unità, ma piuttosto di metodi, input e uscite rispetto a ciò che rappresentano diverse variabili.
1 Questo è dal punto di vista dell'organizzazione, quindi un esempio di un sistema sarebbe un sistema di gestione aerea. Dal punto di vista dell'integratore o del costruttore dell'aeromobile, il sistema di gestione dell'aria è un sottosistema dell'aeromobile. Per l'organizzazione che realizza il sistema di gestione dell'aria, è un sistema con sottosistemi e componenti, alcuni dei quali possono essere software.