Codifica dell'architettura nei requisiti

In linea di massima i requisiti dovrebbero occuparsi dello spazio del problema e non dello spazio della soluzione. Tuttavia, quando si lavora con dispositivi medici, esiste una giustificazione normativa per includere questo come vincolo di progettazione, in quanto è necessario essere in grado di provare determinati comportamenti. Ciò è particolarmente vero quando si tratta di dimostrare i cambiamenti, in cui un'indipendenza definita tra i moduli renderà più semplice la spiegazione ai regolatori.

Le motivazioni che mostri non si allineano bene con quello che ho detto sopra, ma devi anche considerare che ci sono alcuni vincoli hardware impliciti con cui devi convivere (ex calcolo della potenza nel modulo Y).

Quindi penso che questo debba essere considerato un vincolo progettuale. Affermarlo come requisito assicurerà che qualcuno non decida di cambiarlo senza avviare una revisione.

"Il sistema deve utilizzare le tecnologie Windows" potrebbe essere un requisito perché l'utente finale è un negozio Windows e non può eseguire, ad esempio, soluzioni Linux. Questa è una decisione architettonica, ma farà comunque parte dei requisiti dell'utente.

Analogamente la modularizzazione lungo queste linee potrebbe avere una buona ragione basata sui sistemi dell'utente finale in cui questi ampi componenti devono essere definiti in questo modo, è comunque possibile implementarli come preferisci.

A volte le decisioni architettoniche fanno parte dei requisiti, si consideri l'esempio più comune di se un'applicazione sarà una webapp o desktop. Questa è sicuramente una decisione architettonica, eppure sarà spesso presente nelle esigenze degli utenti.

Quindi, se le vostre esigenze particolari sono solo un cliente troppo zelante e micromanaging, o se possedere un fondamento in motivi ragionevoli non è qualcosa che possiamo dire. Potrebbe dipendere dal modo in cui è definito il "modulo", se sono in esecuzione su una suite di box hardware, quindi sembrano abbastanza realistici. Se stai scrivendo un'applicazione desktop monolitica e sono analoghi alle DLL, probabilmente non sono sensibili e dovresti respingerli.

PS. Se si richiede una tracciabilità strong, non è possibile mappare tutto a un requisito utente poiché molti aspetti non saranno definiti dall'utente finale. In questi casi, dovrai mapparli a un requisito di progettazione definito da te stesso.

No, ciò che hai scritto non appartiene ai requisiti, ma all'architettura.

I requisiti sono costituiti dai desideri dell'utente e gli utenti non dovrebbero sapere e non dovrebbero preoccuparsi se hai usato la libreria X o il modulo Y.

Inoltre, aggiungere razionali ai requisiti non ha senso.

The system shall be composed of hardware modules X, Y and Z.
Rationale: This is how we have done it before and we didn't experience any trouble with it.

Dipende. Se i moduli hardware sono parti interne del dispositivo, questo non appartiene né ai requisiti né all'architettura software.

Ma, se i moduli hardware sono qualcosa che gli utenti possono inserire e disinserire, allora appartengono ai requisiti. Ad esempio, vogliono essere in grado di collegare chiavette USB. Oppure vogliono collegare una sonda specifica a un sistema ultra sound.

Il fatto che l'hai fatto per un prototipo è irrilevante. La tua motivazione può andare a un documento correlato all'hardware.

Hardware module X shall be physically detachable from hardware module Y.
Rationale: This allows for easier storage of the system and to allow the user to exchange the more fragile module X in case of problems.

Un testo migliore (in un approccio agile) sarebbe: come utente del dispositivo ABC, voglio essere in grado di staccare X in modo che possa essere sostituito in caso di problemi.

Sì, questo appartiene ai requisiti. E influenza il software.

Hardware module Y shall contain software function S.
Rationale: Software function S needs quite a lot of processing power that is only available in module Y.

Questo non sembra un requisito. In realtà, questo potrebbe essere un requisito interno per il dipartimento HW, che influenza anche il software. Come tale, l'ho messo nell'architettura (abbiamo cercato di implementarlo nel software, e non è andato bene. Lo facciamo invece in HW).

Questo non appartiene ai requisiti degli utenti, perché l'utente non si cura di come hai implementato alcune funzionalità.