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 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 »


Mittwoch 11. Juli 2018 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 frühzeitig erkannt werden, auch dadurch, dass die für das Testen verantwortlichen Personen mit eingebunden werden.

V-Modell vs. Wasserfallmodell für Hardware- und Softwareentwicklung | 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.

Wann ‚Personas‘ mehr schaden als nützen | 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 »


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.

Design Input: Was Sie nicht vergessen sollten | 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.Was macht eigentlich ein Produktmanager? Müssen die uns leidtun? | 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 »


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.

User Stories: Anforderungen an Medizinprodukte formulieren? | 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.

 

Mit IEEE 830 Software-Anforderungen IEC 62304 konform dokumentieren? | Beitrag lesen »

Seite 1