Stakeholder Requirements / Anforderungen

Der Begriff „Requirements“ (Anforderungen) ist sehr missverständlich. Das liegt v.a. daran, dass es völlig unterschiedliche Typen von Requirements / Anforderungen gibt:

Diese drei müssen Sie trennen, idealerweise sogar auf verschiedene Dokumente aufteilen, und dann aufeinander zurückführen können (–> Traceability).

Stakeholder- und System-Anforderungen im V-Modell

Laut Standish Chaos Report sind die meisten Projekte verspätet, überteuert, erfüllen nicht die Erwartungen oder scheitern insgesamt. Der Hauptgrund für dieses Scheitern sind unpräzise oder unvollständig erhobene Anforderungen.

Vorsicht!

Viele Firmen teilen die Anforderungen in Lasten- und Pflichtenhefte auf, ohne dabei die verschiedenen Typen an Anforderungen präzise zu differenzieren.

Business-Anforderungen („High-Level Requirements“)

Die Business Anforderungen stellen die Gründe („rationale“) dafür da, dass das System überhaupt entwickelt werden soll. Es gibt Anforderungen, die darauf zurückzuführen sind, dass der Ist- und Sollzustand nicht übereinstimmen.

Bei Medizinprodukten hat dies viel mit der Zweckbestimmung zu tun. Bei anderen Systemen kann es darum gehen, Arbeitsschritte zu vereinfachen, Durchlaufzeiten von Prozessen zu verkürzen, Papier zu eliminieren, einer bestehenden Personengruppe eine neue Dienstleistung anbieten zu können oder einer neuen Personengruppe eine bestehende Dienstleistung usw. usw.

Stakeholder-Anforderungen

Bei den Stakeholder-Anforderungen unterscheidet man die

  • Nutzungsanforderungen (das sind die wichtigsten), also was ein Nutzer an einem gedachten aber noch nicht spezifizierten System alles eingeben oder auswählen oder daran erkennen können muss.
  • Die gesetzlichen Anforderungen.
  • Die funktionalen Anforderungen, also die Anforderungen an das Arbeitsergebnis.
  • Die organisatorischen Anforderungen, die ggf. gar nichts mit dem Produkt zu tun haben.

Keine dieser Anforderungen beschreibt ein konkretes System.

Weiterführende Informationen

Lesen Sie hier mehr zum Thema Stakeholder-Anforderungen.

System-Anforderungen, System-Spezifikation

Das ist das Ziel der System-Anforderungen bzw. System-Spezifikation. Hier wird ein ganz konkretes System spezifiziert z.B. dessen Benutzerschnittstelle, dessen Datenschnittstellen oder bereits konkrete Anforderungen an die Umsetzung „Unter der Haube“.

Weiterführende Informationen

Lesen Sie hier mehr über Software-Anforderungen und über System-Anforderungen.

Wenn Sie den Unterschied zwischen System-Anforderungen und System-Spezifikation genau verstehen wollen – auch aus regulatorischer Sicht – dann sehen Sie sich die Videotrainings im Auditgarant an.

Videotrainings ansehen


Donnerstag 13. September 2018 von Prof. Dr. Christian Johner

Lastenheft und Pflichtenheft, Systemspezifikation und Systemanforderungen

Die Vorstellungen darüber, was diese Lastenhefte und Pflichtenhefte enthalten müssen, gehen weit auseinander – manchmal auch innerhalb einer Firma.

Regelmäßig beobachtet das Johner Institut, dass die beiden Dokumente die verschiedenen Anforderungstypen nicht konsequent unterscheiden.

Lastenheft und PflichtenheftNur in der Granularität und dem Detailgrad unterscheiden sie sich. Schon aus regulatorischer Sicht sollten Sie die Begriffe Lastenheft und Pflichtenheft gegeneinander abgrenzen.

Lastenheft und Pflichtenheft | Beitrag lesen »


Sonntag 13. Mai 2018 von Prof. Dr. Christian Johner

Viele Lastenhefte und Pflichtenhefte unterscheiden sogenannte funktionale Anforderungen und nicht-funktionale Anforderungen. Funktionale Anforderungen sind Anforderungen mit Bezug zur Zweckbestimmung des Produkts. Zu den nicht-funktionale Anforderungen zählen Anforderungen wie die Zuverlässigkeit und das Zeitverhalten.

Funktionale Anforderungen versus nicht-funktionale Anforderungen | Beitrag lesen »


Dienstag 8. Mai 2018 von Prof. Dr. Christian Johner

Viele Firmen verwenden Personas als Methode im Usability und Requirements Engineering. Eine Persona ist eine fiktive Person, die als repräsentativer Vertreter einer Gruppe dient, typischerweise einer Gruppe potenzieller Benutzer eines Systems.

Besonders in der agilen Software-Entwicklung sowie bei Marketing- und Design-Agenturen sind Personas beliebt. Doch die Methode wird häufig missverstanden und birgt Risiken, die den meisten Firmen nicht bewusst sind.

‚Personas‘: die 5 häufigsten Fehler vermeiden | Beitrag lesen »


Dienstag 6. Februar 2018 von Prof. Dr. Christian Johner

Der IEC TR 62366-2 ist ein „Technical Report“, den Medizinproduktehersteller als „Gebrauchsanweisung“ für die IEC 62366-1 nutzen können. Der Technical Report gibt konkrete Handlungsleitung beim Usability Engineering, um die Anforderungen der IEC 62366-1 zu erfüllen.

Dieser Artikel verschafft Ihnen einen Überblick über den mehr als hundertseitigen IEC TR 62366-2.

IEC TR 62366-2:2016: Gebrauchsanleitung für die IEC 62366-1:2015 | Beitrag lesen »


Freitag 5. Februar 2016 von Prof. Dr. Christian Johner

Die Uses Cases, auf Deutsch Anwendungsfälle, finden im Gegensatz zu User Stories in der agilen Entwicklung nicht mehr so viel Verwendung. Kann man mit der Modellierung von Use Cases zumindest die Forderungen der IEC 62366-1:2015 nach Benutzungsszenarien erfüllen? Sind die Begriffe Use Case und Benutzungsszenario synonym zu verstehen? Dieser Beitrag gibt Ihnen Antworten und Tipps.

Use Case und Benutzungsszenario: Synonyme? Was sagt die IEC 62366? | Beitrag lesen »


Donnerstag 24. September 2015 von Prof. Dr. Christian Johner

Ein Algorithmus ist eine Rechenvorschrift, die beispielsweise in Software umzusetzen ist. Vielen Medizinprodukteherstellern ist unklar, ob solch ein Algorithmus als Teil der Stakeholder-Anforderungen, in der Software-Anforderung oder in der Software-Architektur zu spezifizieren ist. Kein Wunder, denn die Sache ist gar nicht ganz so einfach.

Algorithmus gesetzeskonform spezifizieren. Aber wie? | Beitrag lesen »


Donnerstag 6. November 2014 von Prof. Dr. Christian Johner

Wie identifiziert man die wirklichen Customer Requirements (Kundenanforderungen)? Einfach: Man fragt die Customer was Ihre Requirements (Anforderungen) seien. Falsch! So erfahren Sie nicht, was die Customer Requirements sind, sondern die Customer Requests! Diese Verwechslung kann das Scheitern Ihres Projekts bedeuten!

Customer Request und Customer Requirement | Beitrag lesen »

Seite 1