Best practice per l'utilizzo di Shall and Must durante la scrittura dei requisiti

RFC 2119 "Le parole chiave per l'uso in RFC per indicare i livelli di requisito" vanno in dettagli di quali parole diverse sulla media dei requisiti.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Da questo documento:

• MUST equivale a REQUIRED e SHALL che indica che la definizione è un requisito assoluto.
• MUST NOT equivale a SHALL NOT e indica che si tratta di un divieto assoluto delle specifiche.
• SHOULD equivale a RECOMMENDED significa che ci sono validi motivi per ignorare un particolare requisito, ma le implicazioni devono essere valutate.
• SHOULD NOT e NOT RECOMMENDED significa che un particolare comportamento può essere accettabile o utile, ma ancora una volta, le implicazioni devono essere valutate.
• MAY significa OPTIONAL e il requisito è veramente facoltativo. È necessario eseguire l'interoperabilità con sistemi diversi che possono o meno implementare un requisito facoltativo.

Attenersi a questo RFC% diSHOULD per garantire la coerenza della comunicazione tra i propri documenti interni e il mondo degli standard in generale.

Non sei sicuro di dove sei arrivato alla conclusione che shall e must appartengono a livelli separati di documentazione. Questa è una distinzione piuttosto arbitraria che non è supportata da alcuna fonte che conosco.

Shall e must sono lessicalmente equivalenti. È un'azione richiesta.

Indipendentemente dal fatto che tu usi shall o must dipende in realtà dal resto del documento che stai scrivendo e che cosa ha senso grammaticale per quella particolare frase.

Quindi sì, ti sbagli. Ma hai anche sbagliato ad usare sempre shall anziché must . Rappresentano lo stesso grado di obbligo.

Se ti capita di lavorare nell'ambito di DO-178 o DO-254 linee guida, queste hanno le loro definizioni per requisiti in generale e requisiti derivati . Queste linee guida, tuttavia, non specificano quale parola, ad es. deve, dovrebbe, deve , deve essere usato per specificare i requisiti.

Se i tuoi strumenti di gestione dei requisiti non indicano automaticamente i requisiti derivati per te, rendere questi distinti dai requisiti funzionali mediante l'uso di deve invece di deve può essere utile , ad esempio per dimostrare che gli obiettivi di verifica per i requisiti derivati sono stati soddisfatti. Questa potrebbe essere una possibile ragione per il requisito di documentazione apparentemente arbitrario.

Si noti che in DO-178 e DO-254 requisito derivato in realtà significa un requisito che ha non stato derivato da un requisito di livello superiore. Un requisito derivato quindi avvia essenzialmente una nuova catena di tracciabilità.

Sia il DO-178 che il DO-254 sono documenti di orientamento commerciale utilizzati per lo sviluppo di software ed elettronica avionica e sono disponibili solo a pagamento da www.rtca.org .