Shall, Should, Must, Will, May …

Beim Schreiben von Anforderungen zählt jedes Wort. Anforderungen werden meist in Satzschablonen in englischer Sprache geschrieben. Englisch ist heutzutage der Standard, da die Produkte weltweit zugelassen werden oder die Entwicklungsteams bzw. Kunden weltweit verteilt sind. Besonders wichtig ist die richtige Verwendung der modalen Hilfsverben “shall”, “should”, “must”, “will” und “may”.

Must shall should may will

Shall (muss)

Ein “shall” kennzeichnet eine Anforderung als verbindlich und stellt wohl den wichtigsten Begriff für Anforderungen dar. Eine Anforderung mit “shall” im Satz muss umgesetzt und deren Implementierung verifiziert werden. “Shall” darf somit keineswegs mit einem “sollte”, sondern ganz klar mit einem “muss” übersetzt werden!

Meine Empfehlung ist, jede Anforderung die verbindlich ist mit “shall” zu formulieren. Ein “Shall not” zeigt an, dass etwas nicht zulässig ist. “Shall not” bedeutet also nicht, dass etwas nicht sein muss, sondern dass es nicht sein darf. Ein wesentlicher Unterschied.

Ihr Ansprechpartner:
Dipl.-Ing. Goran Madzar, Systems Engineer
E-Mail: madzar@medtech-ingenieur.de
Tel.:  +49 9131 691 240
Benötigen Sie Unterstützung bei der Entwicklung Ihres Medizingeräts? Wir helfen gerne! MEDtech-Ingenieur bietet Hardware-, Software Entwicklung, Systems Engineering und Beratung aus einer Hand. Nehmen Sie Kontakt auf.

Kontakt aufnehmen

Should (sollte)

Das modale Hilfsverb “should” zeigt eine weiche Anforderung an. Hier wird eine Anforderung formuliert, die aber, falls gute Gründe dafür sprechen, unter Berücksichtigung der Zusammenhänge, entfallen kann. Wenn z.B. die Entwicklungskosten durch diese Anforderung unverhältnismäßig in die Höhe getrieben werden, kann diese Anforderung unter den Tisch fallen. Weiterhin hat “should” seine Berechtigung für Anforderungen die nicht testbar sind. Damit kann man Anforderungen formulieren, um einem Entwicklungsteam Ziele vorzugeben, die aber nicht formal verifizierbar sind.

Must (muss)

“Must” wird oft gleichberechtigt zu “shall” verwendet. Ich empfehle “must” nicht zu verwenden, da es nur Unsicherheiten schafft. Was ist der Unterschied zwischen “must” und “shall”? Ein Mischmasch soll auf jeden Fall vermieden werden. Mit “shall” sind Sie auf jeden Fall auf der sicheren Seite.

Will (wird)

Mit “will” kann man Tatsachenentscheidungen dokumentieren. Diese Information sind für einen Zulieferer relevant, jedoch keine Anforderung an den Zulieferer selbst. Mit “will” kann man z.B. spezifizieren, wie sich ein Fremdsystem oder eine bereits existierende Lösung verhält oder verhalten wird. “Will”-Anforderungen benötigen keine Verifizierung durch den Zulieferer.

May (darf)

Weniger als “may” geht wohl nicht. Eine Anforderung mit “may” ist absolut beliebig. Hiermit kann man sich ein Feature wünschen, das schön wäre, welches aber auch absolut irrelevant ist. So ganz nach dem Motto “Mach es oder lass es”.

Wer Freude an den Begrifflichkeiten gefunden hat, für den habe ich ein Zitat vom Mathematiker und Physiker Georg Christoph Lichtenberg.

Ich kann freilich nicht sagen, ob es besser werden wird, wenn es anders wird; aber so viel kann ich sagen: es muss anders werden, wenn es gut werden soll.

Herzlichst

Ihr Goran Madzar

Auch interessant:

Kundenanforderungen im Rahmen eines Workshops ermitteln

"Mein Kunde/Produktmanager weiß nicht was er will!" Oft sind Kunden-Anforderungen in Entwicklungsprojekten nicht klar und es gibt kein geeignetes Lastenheft. Führt man jedoch ein Entwicklungsprojekt durch ohne die Kunden-Anforderungen verstanden…

Goran Madzar

Seit Mai 2007 bin ich zusammen mit meinem Kollegen Martin Bosch selbständig. Wir haben ein Ingenieurbüro im Innovations- und Gründerzentrum in Erlangen aufgebaut. Hier entwickeln wir für Kunden in der Medizintechnik mit unseren Mitarbeitern Lösungen für die Produkte von Morgen.

Getagged mit: , , ,
6 Kommentare zu “Shall, Should, Must, Will, May …
  1. automotivation sagt:

    https://www.faa.gov/about/initiatives/plain_language/articles/mandatory/

    hier ist ein Text einer offiziellen US-Behörde, der genau andersherum fordert, “must” dem “shall” vorzuziehen.

    nicht zu mischen halte ich in jedem Fall für wichtig und richtig.

    • So ändern sich die Zeiten… Vielen Dank für den tollen Link.

      “Until recently, law schools taught attorneys that shall means must. That’s why many attorneys and executives think shall means must. It’s not their fault. The Federal Plain Writing Act and the Federal Plain Language Guidelines only appeared in 2010. And the fact is, even though must has come to be the only clear, valid way to express mandatory, most parts of the Code of Federal Regulations (CFRs) that govern federal departments still use the word shall for that purpose.”

  2. Florian sagt:

    Anforderungen im Aktiv zu formulieren birgt das immense Risiko, zwischen Anforderungen und Statements nicht mehr eindeutig unterscheiden zu können.
    Aktiv verwende ich nur für Constraints (immer in Verbindung mit dem Schlüsselwort Constraint!), an denen nicht zu rütteln ist.
    Requirements dagegen formuliere ich nur mit “shall”.
    Neben dem Vorteil, Requirements damit eindeutig identifizieren zu können, vermeidet man auch eine Vermischung von Spezifikation und Priorisierung bzw. Projektplanung. Sonst kommt die Frage auf: “Muss das Requirement mit “shall” und Prio “Medium” oder das Requirement mit “should” und Prio “Hoch” zuerst realisiert werden?”
    Abgesehen davon können Priorisierungen sich laufend ändern und Requirements müssten dann reihenweise umgeschrieben werden.

  3. Tobias sagt:

    Die mir sympathischste Methode ist es Anforderungen im AKTIV zu formulieren und “Shall, Should, Must, Will, May …” explizit zu vermeiden. Also z.B. „Das Auto erreicht eine max. Höchstgeschwindigkeit von 220 km/h.“ Über ein Attribut des Requirements kann dann ggf. festgelegt werden, dass es “optional” ist. Default ist am besten „mandatory“.

    Aber warum überhaupt die Mühe von nicht verbindlichen Requirements?

    • Goran Madzar sagt:

      Hallo Tobias,

      das klingt interessant, Anforderungen im Aktiv zu formulieren. Ich habe das in meinen bisherigen Projekten und bei verschiedensten Kunden so noch nicht gesehen. Oft ist die Spezifikation eine Vertragsgrundlage und ich habe gelesen, dass dabei die Formulierung “shall” für juristische Auseinandersetzungen vorteilhaft ist:-) Aber mir gefällt die Vorgehensweise, sofern sie einheitlich und im Projekt oder Unternehmen abgesprochen ist. Wichtig ist, dass Anforderungen gut formuliert sind und einer Schablone folgen. Und das ist in dem Beispiel der Fall. Von Attributen in Anforderungen bin ich ebenfalls sehr überzeugt. Das ist wohl die eleganteste Möglichkeit Informationen (z.B. Priorität, Variante oder Anforderungstyp) zu hinterlegen.
      Nicht verbindliche Anforderungen nutze ich, wenn der Kunde einen Wunsch hat, der optional ist. Hinter jedem Wunsch verbergen sich Realisierungsaufwand und Kosten. Es kann im Interesse des Kunden sein, eine Anforderung optional zu gestalten, um im Projektverlauf noch entscheiden zu können, ob die Anforderungen umgesetzt werden soll oder nicht. Z.B. fordert ein Kunde, dass ein Produkt aus 75cm Höhe einen Fall unbeschadet überstehen soll. Jetzt fordert der Kunde weiterhin, dass das Produkt aus 1m Höhe den Fall überlebt. Die zweite Anforderung ist optional. Das bedeutet, dass bei der Konstruktion versucht wird, diese Anforderung einzuhalten. Falls es aber zu einer Verzögerung oder Kostenerhöhung im Projekt führt, so wird diese Anforderung wieder hinterfragt.

      Danke für deinen Kommentar und die sympathische Methode Anforderungen im Aktiv zu formulieren:-)

  4. Ferdinand Kerl sagt:

    “Mögen hätte ich schon wollen, aber dürfen hab ich mich nicht getraut.” Karl Valentin

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.