Best Practice für die Verwendung von Soll und Muss beim Schreiben von Anforderungen

Ich habe vorhin eine E-Mail gesendet, in der wir unsere Entwickler daran erinnerten, dass die Verwendung des Wortes "Shall" in Ihren abgeleiteten Anforderungen nicht Ihren funktionalen Anforderungen entsprechen sollte. Beim Schreiben von funktionalen Anforderungen wird das Wort "Muss" verwendet, um die Funktion zu beschreiben, die eine abgeleitete Anforderung ausführen muss.
Abgeleitet =
System Muss Voraussetzung sein Funktional = System muss Voraussetzung erfüllen

Es wurde von einem unserer Senioren zurückgeschickt, dass dies falsch war und in jeder Anforderung verwendet werden sollte.

Liege ich hier falsch und Soll in jeder Anforderung verwendet werden. Ich habe nichts gefunden, um das zu belegen.

RFC 2119 "Schlüsselwörter zur Verwendung in RFCs zur Angabe von Anforderungsstufen" beschreibt die Bedeutung verschiedener Wörter für Anforderungen.

Die Schlüsselwörter "MUSS", "MUSS NICHT", "ERFORDERLICH", "MUSS", "MUSS NICHT", "MUSS NICHT", "EMPFOHLEN", "MAI" und "OPTIONAL" in diesem Dokument sind zu interpretieren wie in RFC 2119 beschrieben.

Aus diesem Dokument:

• MUSTist gleichbedeutend mit REQUIREDund SHALLzeigt an, dass die Definition eine absolute Anforderung ist.
• MUST NOTist äquivalent zu SHALL NOTund zeigt an, dass es ein absolutes Verbot der Spezifikationen ist.
• SHOULDist gleichbedeutend mit RECOMMENDED: Es gibt triftige Gründe, eine bestimmte Anforderung zu ignorieren, aber die Auswirkungen müssen abgewogen werden.
• SHOULD NOTund NOT RECOMMENDEDbedeutet, dass ein bestimmtes Verhalten akzeptabel oder nützlich sein kann, aber auch hier müssen die Auswirkungen abgewogen werden.
• MAYbedeutet OPTIONALund dass die Anforderung wirklich optional ist. Die Interoperabilität mit verschiedenen Systemen, die möglicherweise eine optionale Anforderung implementieren oder nicht, muss durchgeführt werden.

Befolgen Sie diese RFC SHOULD, um die Konsistenz der Kommunikation zwischen Ihren internen Dokumenten und der Standardwelt insgesamt sicherzustellen.

Nicht sicher , wo Sie kamen zu dem Schluss , dass shallund mustgehören auf verschiedenen Ebenen der Dokumentation. Das ist eine ziemlich willkürliche Unterscheidung, die von keiner mir bekannten Quelle gestützt wird.

Shallund mustsind lexikalisch gleichwertig. Es ist eine Aktion, die erforderlich ist.

Ob Sie ein Dokument verwenden shalloder mustwirklich, hängt vom Rest des Dokuments ab, in dem Sie schreiben, und davon, was für einen Satz grammatikalisch sinnvoll ist.

Also ja, du liegst falsch. Aber du bist auch falsch darin, immer shallstatt zu verwenden must. Sie stellen den gleichen Grad der Verpflichtung dar.

Wenn Sie zufällig im Rahmen von DO-178- oder DO-254- Richtlinien arbeiten, haben diese ihre eigenen Definitionen für Anforderungen im Allgemeinen und abgeleitete Anforderungen . Diese Richtlinien legen jedoch nicht fest, welches Wort zum Spezifizieren der Anforderungen verwendet werden soll, soll, muss .

Wenn Ihr Anforderungsmanagement-Tool abgeleitete Anforderungen für Sie nicht automatisch aufzeigt, kann es von Vorteil sein, diese von funktionalen Anforderungen durch die Verwendung eines Muss anstelle eines Muss zu unterscheiden, um beispielsweise nachzuweisen, dass die Verifizierungsziele für abgeleitete Anforderungen ebenfalls erfüllt wurden. Dies könnte ein möglicher Grund für die scheinbar willkürliche Dokumentationspflicht sein.

Beachten Sie, dass in DO-178 und DO-254 abgeleitete Anforderung tatsächlich eine Anforderung bedeutet, die nicht von einer übergeordneten Anforderung abgeleitet wurde. Eine abgeleitete Anforderung leitet daher im Wesentlichen eine neue Rückverfolgbarkeitskette ein.

Sowohl der DO-178 als auch der DO-254 sind kommerzielle Richtliniendokumente, die für die Entwicklung von Avionik-Software und -Elektronik verwendet werden und nur gegen eine Gebühr unter www.rtca.org erhältlich sind .