Metodologie e strumenti dell'Ingegneria dei Requisiti ... - MobiLab

tracciare i collegamenti tra quest'ultimo ed il/i requisiti di alto livello con cui sussiste una "relazione
di derivazione".
Per questa classe di requisiti valgono tutte le considerazioni fatte per gli HLR, ma non è posto
alcuna restrizione alla lunghezza 158 della descrizione, poichè dovranno rappresentare informazioni
più dettagliate.
Si noti che, in base alla definizione di requisito derivato data dalla normativa DO-178B,
potrebbero esservi casi in cui non sia possibile tracciare un LLR con uno o più HLR, poichè manca
la corrispondenza.
5.6.4.1.5 Casi d'uso, scenari di interazione e gerarchie di requisiti
Un requisito di alto livello rappresenta una funzionalità richiesta al sistema, che sarà espressa
come un flusso di azioni da eseguire. È necessario, però, valutare i casi d'uso in cui il flusso normale
subisca delle deviazioni, dando luogo a flussi alternativi. Abbiamo già discusso questa evenienza
(cfr. § Scenari di interazione e casi d'uso), indicando come "padre" il caso d'uso che identifica la
funzionalità base, mentre come "figli" quelli che esprimono le possibili variazioni (scenari) della
stessa funzionalità.
Questa relazione di "parentela" si tradurrà in una classificazione gerarchica dei requisiti.
Un requisito deve essere numerato e numerabile all'interno di un documento SRS, pertanto, la
gerarchia sarà esplicitata assegnando al "requisito padre" un identificativo numerico che rispecchierà
la relazione con i "figli".
È bene notare che possono esservi casi in cui il flusso normale di eventi segua una piccola
variazione, tale per cui non si ritenga necessario derivare un ulteriore requisito che rappresenti
questa situazione.
Quanto detto è, normalmente, applicabile ai requisiti a tutti i livelli di astrazione.
Il flusso normale di eventi descrive le azioni intraprese a seguito di un "esito positivo" ed
indica una (post)condizione che, come mostrato, sarà comune ad entrambi i requisiti derivati. Infatti,
i controlli eseguiti dal TCMS termineranno, dando luogo ai due possibili esiti "checks KO" e
"checks OK".
Inoltre, i due requisiti figli esprimeranno ciascuno un flusso alternativo, specificando in quali
situazioni possa verificarsi e descrivendo l'azione a seguito intrapresa.
Rispetto ai requisiti software di basso livello, vi sono alcune considerazioni che vale la pena
approfondire.
Come è noto, essi dettagliano gli HLR che potranno essere strutturati gerarchicamente: in tal
158È consigliabile scrivere i requisiti di alto livello in poche righe (4-5) (cfr. § Scrittura dei requisiti).
125