Share ZU:
24 July 2018 @ Philip Stolz

Modell einer Anforderung

Modell einer Anforderung

Ein Modell ist eine vereinfachte Abbildung der Wirklichkeit mit einem bestimmten Zweck. Das hier vorgestellte Modell hilft mir dabei, herauszufinden, ob eine Anforderung im Kontext einer Produktentwicklung verifizierbar ist. Zudem wird mir dadurch klar, welche der drei Aspekte Stakeholder, Aussage und Adressat einer Anforderung fehlen, unbekannt sind und ggf. ermittelt werden müssen. Die Anwendung dieses Modells hat mir im Übrigen gezeigt, dass auch User Stories und Use Cases Anforderungen sind.

Versuchen Sie, dieses Modell auf Ihre Anforderungen anzuwenden und berichten Sie von Ihren Erfahrungen im Kommentar meines Artikels.

Beschreibung des Modells

Stakeholder

Ein Stakeholder bezeichnet eine Person, die eine Anforderung an den Adressaten hat. Ohne Stakeholder gibt es auch keine Anforderung. Bei der Kommunikation von Anforderungen im Entwicklungsalltag fehlt meistens der Hinweis auf die Stakeholder. Anders sieht dies bei der Nutzung der User-Story-Vorlage, wie z.B. hier, hier und hier beschrieben, aus. Dabei taucht zumindest die Rolle der Stakeholder explizit auf.

Anforderung

Eine Anforderung besitzt eine Aussage, die definiert, unter welchen Umständen sie erfüllt ist. Zudem richtet sich die Anforderung an einen Adressaten, der dafür sorgen soll, dass die Anforderung erfüllt wird.

Aussage

Die Aussage einer Anforderung definiert, unter welchen Umständen die Anforderung erfüllt ist.

Beispiel:

Anforderung: Das System muss es dem Nutzer ermöglichen, eine Nachricht innerhalb von 3 s an einen Empfänger zu übermitteln.

Aussage: Der Nutzer kann eine Nachricht innerhalb von 3 s an einen Empfänger übermitteln.

Die Aussage kann entweder wahr oder falsch sein, und somit verifiziert oder falsifiziert werden.

Die Aussage einer Anforderung bezieht sich auf einen Entwicklungsgegenstand oder aber auf einen anderen Gegenstand, wie zum Beispiel ein Szenario oder ein Supersystem des Entwicklungsgegenstands.

Gegenstand

Mit dem Gegenstand einer Aussage bezeichne ich das, worauf sich die Aussage bezieht.

Beispiele:

Aussage: Der Nutzer kann eine Nachricht innerhalb von 3 s an einen Empfänger übermitteln.

Gegenstand: Ein Szenario, in dem ein Nutzer, eine Nachricht und ein Empfänger existieren.

Aussage: Das Display des Gerätes hat eine Diagonale von mindestens 3,5 cm.

Gegenstand: Das Display, ein Entwicklungsgegenstand.

Gegenstand der Aussage kann der Entwicklungsgegenstand selbst sein, ein Teilentwicklungsgegenstand oder aber etwas anderes, wie zum Beispiel ein Szenario, in dem der Entwicklungsgegenstand eingesetzt wird.

Beispiele für Gegenstände:

Gegenstandsart Beispiel
Entwicklungsgegenstand Mobilfunkgerät
Teilentwicklungsgegenstand Display
Szenario Übermitteln einer Nachricht
Supersystem Mobilfunknetz

Entwicklungsgegenstand

Ein Entwicklungsgegenstand stellt das System oder Produkt dar, welches entwickelt werden soll, oder ein Teil davon. Diese Teilentwicklungsgegenstände können jede Art von Hardware-, Software- oder Konstruktionseinheiten sein, aus denen ein Entwicklungsgegenstand besteht.

Adressat

Mit dem Adressat einer Anforderung bezeichne ich einen (Teil-)Entwicklungsgegenstand oder die Eigenschaft eines (Teil-)Entwicklungsgegenstandes, der bzw. die dafür sorgen soll, dass die Aussage der Anforderung wahr wird.

Der Adressat einer Anforderung muss nicht identisch mit dem Gegenstand der Aussage der Anforderung sein. Je nachdem, wie Gegenstand und Adressat in Beziehung zueinander stehen, kann ich einschätzen, welches Abstraktionsniveau eine Anforderung hat, und ob dieses angemessen ist oder nicht.

Fazit

Die Beschreibung des Modells hat gezeigt, wie eine Anforderung auf das vorgestellte Modell projiziert werden kann. Wenn Sie sich weiter mit dem Thema “Anforderungen” auseinandersetzen möchten, empfehle ich Ihnen, sich bei unseren Trainings umzusehen.

Hier geht`s zu unseren Trainings.

Philip Stolz

Kontaktieren Sie Philip Stolz

Herr Philip Stolz ist als Senior Consultant im Bereich Requirements Engineering (RE) tätig. Seine Schwerpunkte liegen in der Einführung und Prozessverbesserung von Requirements Engineering (RE). Herr Stolz verfügt über eine fundierte Ausbildung im Bereich Software Engineering (Dipl.-Inf., Softwaretechnik). Durch Erfahrung aus unterschiedlichen Entwicklungsprojekten in verschiedenen industriellen Branchen sind ihm typische Projektsituationen sowie das Vorgehen bei der Einführung methodischer Verfahren innerhalb von Projektteams bekannt.