Nutzungsanforderungen

Vgl. Lastenheft & Pflichtenheft

Nutzungsanforderungen zählen neben den gesetzlichen Anforderungen und Marktanforderungen zu den Stakeholder-Anforderungen. Nutzungsanforderungen sind die Anforderungen der Nutzer (oder Benutzer).

Definition des Begriffs Nutzungsanforderung

Der DAkkS Leitfaden Usability definiert eine Nutzungsanforderung als eine erforderliche Benutzeraktion an einem interaktiven System, in einer die Tätigkeit beschreibenden Weise – nicht in technisch realisierter Weise. .

Nutzer können an interaktiven Systemen nur

  1. etwas eingeben,
  2. etwas auswählen oder
  3. eine kognitive Leistung erbringen wie verstehen, erkennen oder unterscheiden.

Das empfiehtl sich folgende Satzschablone zum Formulieren von Nutzungsanforderungen:

Der Nutzer muss am System XY können

wobei XY für die o.g. Verben „eingeben“, „auswählen“ oder „verstehen“ steht.

Englische Übersetzung

Was ist die richtige Übersetzung von Nutzungsanforderung? Usage requirement, user requirement, requirement for use oder…? Ich bin unsicher und frage meinen Usability-Guru Thomas Geis. Seine Antwort ist ebenso kurz wie klar:

„Das einzige, was wirklich verbreitet ist, ist „user requirement“. Das Problem mit usage requirement und requirement for use ist, dass es auch für „Nutzungsbedingungen“ verwendet wird. Am Ende des Tages ist der einfachste Kompromiss „user requirement“.“

Identifizieren von Nutzungsanforderungen — und typische Probleme dabei

Nutzungsanforderungen kann man nicht erfragen

Die Herausforderung beim Identifizieren von Nutzungsanforderungen bestehen darin, dass man sie nicht direkt erfagen kann. Würde man Nutzer fragen, was sie benötigen, würden diese antworten, was sie wünschen.

Regelmäßig verwechseln Hersteller „user requests“ mit „user requirements“. Während „user requirements“ Nutzungsanforderungen sind, entsprechen „user requests“ meist Systemspezifikationen bzw. Systemanforderungen, also Beschreibungen von konkreten Lösungen d.h. von Systemen aus Blackbox-Sicht.

Thomas Geis hat die Kontextmethode entwickelt, mit der Hersteller systematisch die wirklichen Nutzungsanforderungen für ihre Produkte identifizieren und daraus unstrittige Systemanforderungen ableiten können.

Demnächst wird eine Norm der Familie ISO 9241 diese Methode beschreiben. Mehrere Videotrainings des Auditgarant zeigen schon jetzt Schritt für Schritt, wie man mit dieser Methode zu den wirklichen „Kunden-Anforderungen“ kommt.

Videotrainings ansehen


Donnerstag 23. Februar 2017 von Prof. Dr. Christian Johner

Lastenheft und Pflichtenheft, Systemspezifikation und Systemanforderungen:
Die Vorstellungen darüber, was diese Dokumente enthalten müssen, gehen weit auseinander – manchmal auch innerhalb einer Firma.

Lastenheft und PflichtenheftRegelmäßig beobachte ich, dass alle mehrere Dokumente etwa die gleichen Anforderungen beschreiben. Nur in der Granularität und dem Detailgrad unterscheiden sie sich. Schon aus regulatorischer Sicht sollten Sie die Begriffe Lastenheft und Pflichtenheft gegeneinander abgrenzen.

Den ganzen Beitrag lesen »


Montag 20. Februar 2017 von Prof. Dr. Christian Johner

Unter „Design Input“ versteht man die Entwicklungsvorgaben, an die nicht nur die FDA konkrete Forderungen stellt.

Dieser Artikel beschreibt, welche Inhalte Ihr Design Input enthalten sollte. Sie erfahren, wie das Risikomanagement mit dem Design Input zusammenspielt.

Den ganzen Beitrag lesen »


Mittwoch 9. März 2016 von Prof. Dr. Christian Johner

Beim Wort „Produktmanager“ oder „Produktmanagement“ verdrehen viele Entwickler die Augen. Die Zusammenarbeit der beiden Abteilungen ist oft von Reibungsverlusten geprägt. Lesen Sie hier, weshalb dem so ist und was Sie dagegen machen können.Den ganzen 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.

Den ganzen Beitrag lesen »


Mittwoch 13. Mai 2015 von Prof. Dr. Christian Johner

User Stories werden in der agilen (Software-)Entwicklung genutzt, um die Kundenanforderungen zu erheben und zu dokumentieren.

Aber sind User Stories auch geeignet, um die Anforderungen an Medizinprodukte (normenkonform) zu beschreiben? Erfüllen sie die Anforderungen einer IEC 62366? Und wie hängen diese mit den Use Scenarios zusammen? Dieser Beitrag gibt Antworten.

Den ganzen Beitrag lesen »


Montag 2. März 2015 von Prof. Dr. Christian Johner

Die IEEE 830 ist eine Norm, die beschreibt, wie man Software Anforderungen bzw. Software Spezifikationen beschreiben sollte. Die IEEE 830 schlägt dazu mindestens drei Kapitel vor:

  1. Einleitung mit Dokumenten Meta-Informationen (Zweck, Verweise, Aufbau) und mit einer Übersicht über die Software
  2. Allgemeine Beschreibung der Software: Hier sollte man die Abgrenzung zu/von anderen Systemen ebenso beschreiben wie die wichtigsten Produktfunktionen und Einschränkungen des Lösungsraums. Auch sieht die IEEE 830 eine Charakterisierung der Nutzer als Teil dieses Kapitels vor.
  3. Die spezifischen Anforderungen umfassen laut IEEE 830 funktionale und nicht-funktionale Anforderungen, Anforderungen an die Performanz, Qualitätsanforderungen, externe Schnittstellen und sonstige Anforderungen.

 

Den ganzen Beitrag lesen »


Montag 26. Januar 2015 von Prof. Dr. Christian Johner

Das V-Modell ist ein Entwicklungsprozessmodell, das ursprünglich für staatliche Projekte entwickelt wurde. Das V-Modell unterscheidet sich vom Wasserfall-Modell dadurch, dass bereits während der konstruktiven Phasen (z.B. während dem Schreiben der Anforderungen oder dem Entwerfen der Architektur) die zugehörigen Tests spezifiziert werden müssen.

Das hat den Vorteil, dass unvollständige Spezifikationen oder Festlegungen frühzeitig erkannt werden, auch dadurch, dass die für das Testen verantwortlichen Personen mit eingebunden werden.

Den ganzen Beitrag lesen »


Dienstag 8. April 2014 von Prof. Dr. Christian Johner

Jeder wird zustimmen, dass es gut ist, die künftigen Anwender von Anfang an, in die Entwicklung mit einzubeziehen. „User Centered Design“ nennt man das oft. Dabei kann dieser User Centered Design Ansatz sogar zu fatalen Fehlentwicklungen führen.

Den ganzen Beitrag lesen »