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


Mit User Centered Design die falschen Produkte entwickeln

Das User Centered Design zielt darauf ab, künftige Anwender von Anfang an in die Entwicklung einzubeziehen. So einleuchtend dieser Ansatz klingt, so häufig führt er zu fatalen Fehlentwicklungen. Sie erreichen das Gegenteil dessen, was Sie wollten, nämlich unsichere und gebrauchsuntaugliche Produkte, die gegen regulatorische Vorgaben verstoßen. Doch mit drei Schritten wird es gelingen, das wirkliche…

Weiterlesen

Lastenheft und Pflichtenheft

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.  Inhaltsübersicht Allgemeines zu Lasten- und Pflichtenheft » Lastenheft » Pflichtenheft » Der bessere Ansatz »…

Weiterlesen

V-Modell vs. Wasserfallmodell für Hardware- und Softwareentwicklung

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.  Inhaltsübersicht Phasen im V-Modell » Verantwortlichkeiten » V-Modell s. agile Entwicklung » Typische Missverständnisse…

Weiterlesen

‚Personas‘: die 5 häufigsten Fehler vermeiden

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…

Weiterlesen
IEC TR 62366-2 Projekt (Ausschnitt)

IEC TR 62366-2:2016: Gebrauchsanleitung für die IEC 62366-1:2015

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.

Weiterlesen

Design Input: Was Sie nicht vergessen sollten

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.  Inhaltsübersicht Definition „Design Input“ » Regulatorische Anorderungen » Inhalte des Design Inputs » Risikoanalyse als Design Input »

Weiterlesen
Use Case Diagramm

Use Case und Benutzungsszenario: Synonyme? Was sagt die IEC 62366?

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.