Best practice per l'utilizzo di must e must durante la scrittura dei requisiti

In precedenza ho inviato una e-mail per ricordare ai nostri sviluppatori che l'uso della parola "Devo" nei requisiti derivati non dovrebbe seguire i requisiti funzionali. Quando si scrivono i requisiti funzionali, la parola "Must" viene utilizzata per descrivere la funzione che un requisito derivato deve svolgere.
Derivato = Sistema Sarà necessario
Funzionale = Il sistema deve fare i requisiti

È stato rispedito da uno dei nostri Anziani che, che era sbagliato e che dovrebbe essere utilizzato in ogni esigenza.

Sbaglio qui e dovrei essere usato in ogni esigenza. Non sono stato in grado di trovare nulla per il backup.

requirements

— Tim Lieberman
fonte

Usiamo "deve" in ogni requisito obbligatorio. Ma "deve" e "deve" significare più o meno la stessa cosa. Vedi anche tynerblain.com/blog/2009/04/22/dont-use-shall

— Robert Harvey

Stai forse pensando al MUSTvs SHOULDnelle RFC? ietf.org/rfc/rfc2119.txt

— user10326

Vedi anche plainlanguage.gov/howto/wordsuggestions/shallmust.cfm

— Arseni Mourzenko

Euh, non essere il guastafeste, ma cosa stai vincendo quando tutti usano la parola corretta nella situazione corretta?

— Peter,

Requisiti Documentazione: Will vs Shall

— KMan

Risposte:

RFC 2119 "Le parole chiave da utilizzare nelle RFC per indicare i livelli dei requisiti" vanno specificate in cosa significano le diverse parole sui requisiti.

Le parole chiave "DEVE", "NON DEVE", "RICHIESTO", "DEVE ESSERE", "NON DEVE", "DOVREBBE", "NON DOVREBBE", "CONSIGLIATO", "MAGGIO" e "OPZIONALE" in questo documento sono da interpretare come descritto in RFC 2119.

Da questo documento:

MUSTè equivalente REQUIREDe SHALLindica che la definizione è un requisito assoluto.
MUST NOTè equivalente SHALL NOTe indica che è un divieto assoluto delle specifiche.
SHOULDequivale a RECOMMENDEDsignifica che ci sono validi motivi per ignorare un requisito particolare, ma le implicazioni devono essere ponderate.
SHOULD NOTe NOT RECOMMENDEDsignifica che un comportamento particolare può essere accettabile o utile, ma ancora una volta, le implicazioni devono essere ponderate.
MAYsignifica OPTIONALche il requisito è veramente facoltativo. L'interoperabilità con sistemi diversi che possono o meno implementare un requisito opzionale deve essere effettuata.

In seguito a questa RFC è SHOULDnecessario garantire la coerenza della comunicazione tra i propri documenti interni e il mondo delle norme in generale.

risposta solida; oggetti di scena per scavare la RFC

@ GlenH7 Lo sapevo (mi piace leggere le RFC del 1 ° aprile e un po 'dell'umorismo è nel' dovrebbe 'e' must ', e 2119 è anche sulla pagina di Wikipedia ) L'ho cercato, trovato, e poi ho letto il commento che stavo per fare - due sopra era di nuovo l'RFC. Quindi oggetti di scena non del tutto enormi per scavarlo.

Il mio pensiero era che i requisiti / requisiti funzionali Must dovevano richiedere tutte le funzionalità a un oggetto derivato che doveva esistere. Ma date le definizioni di must e must e il modo in cui tutti gli altri le usano, mi sbagliavo di poco

— Tim Lieberman,

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

Shalle mustsono lessicamente equivalenti. È un'azione richiesta.

Se usi shallo mustdipende davvero dal resto del documento in cui stai scrivendo e da cosa ha senso grammaticale per quella particolare frase.

Quindi sì, ti sbagli. Ma hai anche torto a usare sempre shallinvece di must. Rappresentano lo stesso grado di obbligo.

Shoulde maynon sono abbastanza equivalenti. Entrambi indicano funzionalità opzionali, ma should, a differenza may, implica che è necessario avere una buona ragione per non implementarla. Sono d'accordo con te su shallvs. must, però.

— Keith Thompson,

@KeithThompson - è un buon punto, e hai ragione. Ho estratto quella linea dalla risposta.

Il mio pensiero è diventato che i requisiti funzionali dovrebbero usare perché, se un oggetto derivato deve esistere, tutte le sue funzionalità devono funzionare.

— Tim Lieberman,

Immagino che ad un certo punto avrei dovuto essere incorporato come nuovo oggetto nella mia testa e come funzione.

— Tim Lieberman,

@TimLieberman - non è un brutto modo di vedere le cose, soprattutto perché collega i due livelli di specifiche. Un po 'utile, in realtà, dal momento che alcune persone vengono confuse dalla semantica dei termini. Soprattutto da quando ho corretto i documenti di processo in cui "deve" veniva spesso usato come sostituto di "dovrebbe". Tuttavia, non è abbastanza utile da richiederlo come standard particolare.

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

Se i tuoi strumenti di gestione dei requisiti non indicano automaticamente i requisiti derivati per te, renderli distinti dai requisiti funzionali mediante l'uso di un must invece di deve essere utile, ad esempio per dimostrare che sono stati raggiunti anche gli obiettivi di verifica per i requisiti derivati. Questo potrebbe essere un possibile motivo per il requisito di documentazione apparentemente arbitrario.

Si noti che nei requisiti derivati DO-178 e DO-254 si intende effettivamente un requisito che 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 orientativi commerciali utilizzati per lo sviluppo di software avionico ed elettronica, e disponibili solo a pagamento da www.rtca.org .

— Schedler
fonte