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:
Der DAkkS-Leitfaden „Usability“ definiert eine Nutzungsanforderung wie folgt:
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 etwas eingeben, etwas auswählen oder eine kognitive Leistung erbringen, wie verstehen, erkennen oder unterscheiden.
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:
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.“
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.
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.
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.
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.
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“.
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“.
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:
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, 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…
Details
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…
Details
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…
Details
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…
Details
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.
DetailsUnter „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 »
DetailsBeim 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.
Wie identifiziert man die wirklichen User Requirements (Kundenanforderungen)? Einfach: Man fragt die User was Ihre Requirements (Anforderungen) seien. Falsch! So erfahren Sie nicht, was die User Requirements sind, sondern die User Requests! Diese Verwechslung kann das Scheitern Ihres Projekts bedeuten!
