Hersteller, denen es gelingt, die Nutzungsanforderungen vollständig und korrekt zu erheben und zu erfüllen, handeln nicht nur konform mit den gesetzlichen Anforderungen. Sie sind auch mit gebrauchstauglichen Produkten erfolgreich im Markt.

Inhalt

Diese Seite verschafft Ihnen eine kompakte Einführung und verlinkt weiterführende Artikel:

  1. Nutzungsanforderungen: Grundlagen
  2. Regulatorische Anforderungen an das Erheben
  3. Nutzungsanforderungen erheben und nachweisen
  4. Unterstützung

1. Nutzungsanforderungen: Die Grundlagen

a) Definition

Der DAkkS-Leitfaden „Usability“ definiert eine Nutzungsanforderung wie folgt:

Definition:  Nutzungsanforderung

Eine erforderliche Benutzeraktion an einem interaktiven System, in einer die Tätigkeit beschreibenden Weise – nicht in technisch realisierter Weise.

Quelle: DAkkS-Leitfaden Usability

b) Formulierung und Beispiele

Nutzer können an interaktiven Systemen nur etwas eingeben, etwas auswählen oder eine kognitive Leistung erbringen, wie verstehen, erkennen oder unterscheiden.

Tipp

Formulieren Sie Nutzungsanforderungen mit folgender Satzschablone:

„Der Nutzer muss am System XY können“, wobei XY für Verben steht wie eingeben, auswählen, verstehen, erkennen oder unterscheiden.

Beispiele für Nutzungsanforderungen sind:

  • Der Nutzer muss am System Patienten mit zu niedrigem Hämoglobin-Wert erkennen können.
  • Der Nutzer muss am System den Patienten auswählen können.
  • Der Nutzer muss am System den Namen des Patienten eingeben können.

c) Englische Übersetzung

Als Übersetzungen von Nutzungsanforderung finden sich die Begriffe „usage requirement“, „user requirement“, „requirement for use“ usw. Thomas Geis, Autor vieler Usability-Normen, urteilt:

„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.“

d) Abgrenzung zu anderen Anforderungen

Die Nutzungsanforderungen zählen neben den regulatorischen Anforderungen und den Marktanforderungen zu den Stakeholder-Anforderungen. Diese wiederum bilden gemeinsam mit den technischen Anforderungen die Anforderungen im Allgemeinen.

Weiterführende Informationen

Um mehr über die anderen Anforderungstypen und deren Taxonomie zu erfahren, beachten Sie die Artikel zu den Anforderungen im Allgemeinen, zu den Stakeholder-Anforderungen und zu den technischen Anforderungen.

2. Regulatorische Anforderungen

Normen und Gesetze stellen Anforderungen an das Erheben und Nachweisen von Stakeholder-Anforderungen. Diese regulatorischen Anforderungen stellt der oben bereits genannte Artikel zu den Stakeholder-Anforderungen vor.

Hinweis

Viele Normen und Gesetze unterscheiden die verschiedenen Anforderungen nicht präzise. Sie differenzieren z. B. nicht zwischen Kundenanforderungen und Nutzungsanforderungen. Die Anforderungen der Kunden (Käufer) sind die Marktanforderungen. Die Kunden sind nicht notwendigerweise auch die Nutzer (Anwender) der Produkte.

3. Nutzungsanforderungen erheben und nachweisen

a) Erheben der Nutzungsanforderungen

Nutzungsanforderungen können nicht erhoben werden, indem man die Nutzer nach ihren Anforderungen fragt: Wenn man die Nutzer fragt, was sie benötigen, antworten diese, was sie wünschen.

Mit anderen Worten: Wenn man „User“ nach deren „Requirements“ befragt, erhält man als Antwort nicht die „User Requirements“, sondern die „User Requests“.

Weiterführende Informationen

Lesen Sie in diesem Artikel mehr zum Unterschied von User Requirements und User Requests.

Nutzungsanforderungen lassen sich am effizientesten und systematischsten mit der Kontextmethode ermitteln, welche die ISO 9241 beschreibt. Thomas Geis vermittelt sie im Seminar „Usability und Requirements Engineering & IEC 62366-1“.

b) Nachweisen der Nutzungsanforderungen

Hersteller sind verpflichtet nachzuweisen, dass die Nutzungsanforderungen erfüllt sind, d. h. dass die Nutzer tatsächlich an einem System etwas wie spezifiziert eingeben, auswählen und erkennen können.

Dieser Nachweis gelingt in zwei Schritten:

  1. Schritt:
    Bei der Usability-Verifizierung prüft man, ob Eingabe, Auswahl und Erkennen möglich sind. Als Methoden kommen zum Einsatz

    1. die Inspektion anhand von Checklisten und der Abgleich gegen die Nutzungsanforderungen,
    2. der Cognitive Walkthrough und
    3. die heuristische Evaluation.
  2. Schritt:
    Bei der Usability-Validierung prüft man in Usability Tests (summative Evaluation), ob die Nutzer die Nutzungsziele erreichen. Dazu ist es notwendig, dass die Nutzungsanforderungen erfüllt sind.

4. Unterstützung

Haben Sie noch Fragen zu den Nutzungsanforderungen? Antworten erhalten Sie in unserem kostenlosen Micro-Consulting.

Im Seminar Usability, Requirements und IEC 62366-1 lernen Sie, die Anforderungen systematisch und normenkonform zu erheben.

Durch Usability Tests in den Labs des Johner Instituts stellen Sie sicher, dass alle Stakeholder-Anforderungen normenkonform nachgewiesen sind und Ihre Produkte dank ihrer Gebrauchstauglichkeit erfolgreich werden.

Melden Sie sich gleich hier, wenn Sie Unterstützung wünschen. Wir helfen Ihnen, möglichst schnell, einfach und gesetzeskonform alle relevanten Anforderungen zu erheben und nachzuweisen. Dann werden Ihre Produkte sicher und nachgefragt und kommen schnell in den Markt.


Lastenheft und Pflichtenheft

Lastenheft und Pflichtenheft

Lastenheft und Pflichtenheft, Systemspezifikation und Systemanforderungen Die Vorstellungen darüber, was Lastenhefte und Pflichtenhefte enthalten müssen, gehen weit auseinander – manchmal auch innerhalb einer Firma. Das liegt u. a. daran, dass die beiden Dokumente die verschiedenen Anforderungstypen nicht konsequent unterscheiden. Vielmehr unterscheiden sie sich in der Granularität und dem Detailgrad. Schon aus regulatorischer Sicht sollten Sie…

Weiterlesen

V-Modell: Die 5 häufigsten Probleme vermeiden

Das V-Modell ist ein Entwicklungsprozessmodell, das ursprünglich bei staatlichen Projekten (u. a. Rüstung) zur Anwendung kam. Bis heute ist es bei Projekten im regulierten Umfeld (z. B. Medizintechnik, Banken) in vielen Köpfen und Normen verankert. Das führt zu Konflikten in Teams, die agile Entwicklungsprozesse bevorzugen. Dieser Artikel hilft, diesen Widerspruch aufzulösen. Sie erfahren, wie Sie…

Weiterlesen

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

‚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