Erfordernis

In der Ingenieurwissenschaft bezeichnet eine Anforderung eine Bedingung, die erfüllt sein muss, damit das Ergebnis einer Arbeitsleistung als akzeptabel gilt. Es handelt sich um eine explizite, objektive, klare und oft quantitative Beschreibung einer Bedingung, die ein Material, eine Konstruktion, ein Produkt oder eine Dienstleistung erfüllen muss. ^{[ 1 ]}

Eine Spezifikation oder Spec ist eine Reihe von Anforderungen, die typischerweise von Entwicklern in der Entwurfsphase der Produktentwicklung und von Testern im Rahmen des Verifizierungsprozesses verwendet werden.

Bei iterativen und inkrementellen Entwicklungsmethoden wie der agilen Softwareentwicklung werden die Anforderungen parallel zu Design und Implementierung erarbeitet. Beim Wasserfallmodell hingegen sind die Anforderungen vor Beginn von Design oder Implementierung abgeschlossen.

Anforderungen werden in vielen Ingenieurdisziplinen verwendet, darunter Konstruktion , Systemtechnik , Softwareentwicklung , Unternehmensentwicklung , Produktentwicklung und Prozessoptimierung.

Der Begriff „Anforderung“ ist relativ weit gefasst und kann jede notwendige oder gewünschte Funktion, Eigenschaft, Fähigkeit, Charakteristik oder Qualität eines Systems beschreiben, damit dieses für einen Kunden, eine Organisation, einen Benutzer oder einen anderen Interessengruppen Wert und Nutzen hat.

Der Begriff „ Anforderung“ ist in der Softwareentwicklungsgemeinschaft mindestens seit den 1960er Jahren gebräuchlich. ^{[ 2 ]}

Gemäß dem Leitfaden zum Business Analysis Body of Knowledge® Version 2 des IIBA (BABOK) ^{[ 3 ]} ist eine Anforderung:

1. Eine Bedingung oder Fähigkeit, die ein Interessensvertreter benötigt, um ein Problem zu lösen oder ein Ziel zu erreichen.
2. Eine Bedingung oder Fähigkeit, die von einer Lösung oder einer Lösungskomponente erfüllt oder besessen werden muss, um einem Vertrag, einer Norm, einer Spezifikation oder anderen formal auferlegten Dokumenten zu genügen.
3. Eine dokumentierte Darstellung eines Zustands oder einer Fähigkeit wie in (1) oder (2).

Diese Definition basiert auf IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology. ^{[ 4 ]}

Die Anforderungen lassen sich in zwei Bereiche einteilen:

• Produktanforderungen legen die Eigenschaften eines Systems oder Produkts fest.
• Prozessanforderungen legen die von der sich entwickelnden Organisation durchzuführenden Aktivitäten fest. Beispielsweise können Prozessanforderungen die einzuhaltenden Methoden und die von der Organisation zu beachtenden Einschränkungen spezifizieren.

Produkt- und Prozessanforderungen sind eng miteinander verknüpft. Eine Produktanforderung spezifiziert die zur Unterstützung einer Prozessanforderung notwendige Automatisierung, während eine Prozessanforderung die zur Unterstützung einer Produktanforderung erforderlichen Aktivitäten festlegt. Beispielsweise kann eine maximale Entwicklungskostenvorgabe (eine Prozessanforderung) festgelegt werden, um eine maximale Verkaufspreisvorgabe (eine Produktanforderung) zu erreichen. Die Anforderung, dass das Produkt wartungsfreundlich sein muss (eine Produktanforderung), wird häufig durch die Festlegung von Anforderungen an bestimmte Entwicklungsstile (z. B. objektorientierte Programmierung ), Styleguides oder einen Prüf-/Inspektionsprozess (Prozessanforderungen) erfüllt.

Anforderungen werden typischerweise in Typen klassifiziert, die in verschiedenen Phasen eines Entwicklungsprozesses entstehen, wobei die Taxonomie vom verwendeten Gesamtmodell abhängt. Beispielsweise wurde das folgende Schema vom International Institute of Business Analysis in seinem Business Analysis Body of Knowledge ^{[ 5 ]} entwickelt (siehe auch FURPS und Anforderungstypen ).

Architektonische Anforderungen

Architektonische Anforderungen erklären, was zu tun ist, indem sie die notwendige Integration von Systemstruktur und Systemverhalten , d. h. die Systemarchitektur eines Systems, identifizieren.

In der Softwareentwicklung werden sie als architektonisch relevante Anforderungen bezeichnet. Diese sind definiert als Anforderungen, die einen messbaren Einfluss auf die Architektur eines Softwaresystems haben . ^{[ 6 ]}

Geschäftsanforderungen

Zielsetzungen sind übergeordnete Formulierungen der Ziele, Vorgaben oder Bedürfnisse einer Organisation. Sie beschreiben üblicherweise Chancen, die eine Organisation nutzen möchte, oder Probleme, die sie lösen will. Häufig werden sie in einem Business Case dargestellt .

Anforderungen der Nutzer (Interessengruppen)

Bedarfsbeschreibungen auf mittlerer Ebene beschreiben die Bedürfnisse eines bestimmten Stakeholders oder einer Stakeholdergruppe. Sie geben in der Regel Auskunft darüber, wie die Interaktion mit der angestrebten Lösung gestaltet werden soll. Oftmals fungieren sie als Bindeglied zwischen den übergeordneten Geschäftsanforderungen und den detaillierteren Lösungsanforderungen.

Funktionale (Lösungs-)Anforderungen

Üblicherweise handelt es sich dabei um detaillierte Beschreibungen der Funktionen, Fähigkeiten, des Verhaltens und der Informationen, die die Lösung liefern soll. Beispiele hierfür sind die Formatierung von Text, die Berechnung einer Zahl oder die Modulation eines Signals. Sie werden auch als Fähigkeiten bezeichnet .

Anforderungen an die Servicequalität (nicht-funktionale Anforderungen)

Üblicherweise handelt es sich um detaillierte Beschreibungen der Bedingungen, unter denen die Lösung wirksam bleiben muss, der Eigenschaften, die sie aufweisen muss, oder der Einschränkungen, innerhalb derer sie funktionieren muss. ^{[ 7 ]} Beispiele hierfür sind Zuverlässigkeit, Testbarkeit, Wartbarkeit und Verfügbarkeit. Sie werden auch als Eigenschaften , Einschränkungen oder Merkmale bezeichnet .

Implementierungs- (Übergangs-) Anforderungen

Detaillierte Beschreibungen von Fähigkeiten oder Verhaltensweisen sind üblicherweise nur erforderlich, um den Übergang vom aktuellen Zustand des Unternehmens zum gewünschten zukünftigen Zustand zu ermöglichen; danach werden sie nicht mehr benötigt. Beispiele hierfür sind Personalbeschaffung, Rollenwechsel, Weiterbildung und die Migration von Daten zwischen Systemen.

Regulatorische Anforderungen

Anforderungen, die durch Gesetze (Bund, Länder, Gemeinden oder Regionen), Verträge (Bedingungen) oder Richtlinien (Unternehmens-, Abteilungs- oder Projektebene) definiert sind.

Die Merkmale guter Anforderungen werden von verschiedenen Autoren unterschiedlich beschrieben, wobei jeder Autor im Allgemeinen die Merkmale hervorhebt, die für seine allgemeine Diskussion oder den jeweiligen Technologiebereich am relevantesten sind. Die folgenden Merkmale sind jedoch allgemein anerkannt. ^{[ 8 ] [ 9 ]}

Es gibt viele weitere Attribute, die zur Qualität von Anforderungen beitragen. Unterliegen Anforderungen beispielsweise Regeln der Datenintegrität , sind Genauigkeit/Korrektheit und Gültigkeit/Autorisierung ebenfalls wichtige Attribute. Die Rückverfolgbarkeit bestätigt, dass die Anforderungen den Bedarf decken (nicht mehr und nicht weniger als erforderlich).

Einige ergänzen das oben Genannte um die extern beobachtbare Anforderung, d. h. die Anforderung spezifiziert eine Produkteigenschaft, die extern beobachtbar oder vom Benutzer wahrgenommen wird. Diese Befürworter argumentieren, dass Anforderungen, die interne Architektur-, Design-, Implementierungs- oder Testentscheidungen festlegen, wahrscheinlich Einschränkungen darstellen und im Abschnitt „Einschränkungen“ des Anforderungsdokuments klar formuliert werden sollten. Die gegenteilige Ansicht besagt, dass diese Perspektive in zweierlei Hinsicht fehlerhaft ist. Erstens berücksichtigt sie nicht, dass die Benutzererfahrung durch Anforderungen unterstützt werden kann, die für den Benutzer nicht wahrnehmbar sind. Beispielsweise kann eine Anforderung zur Anzeige geokodierter Informationen für den Benutzer durch eine Anforderung für eine Schnittstelle zu einem externen Geschäftspartner unterstützt werden. Die Schnittstelle selbst ist für den Benutzer nicht wahrnehmbar, die Darstellung der darüber erhaltenen Informationen jedoch schon. Zweitens schränkt eine Einschränkung die Designalternativen ein, während eine Anforderung Designmerkmale spezifiziert. Um beim Beispiel zu bleiben: Eine Anforderung, die eine Webdienstschnittstelle vorgibt, unterscheidet sich von einer Einschränkung, die die Designalternativen auf Methoden beschränkt, die mit einer Single-Sign-On-Architektur kompatibel sind.

Alle Anforderungen müssen überprüfbar sein. Die gängigste Methode hierfür ist der Test. Ist dies nicht möglich, sollte stattdessen eine andere Verifizierungsmethode angewendet werden (z. B. Analyse, Demonstration, Inspektion oder Überprüfung des Entwurfs).

Bestimmte Anforderungen sind aufgrund ihrer Struktur nicht überprüfbar. Dazu gehören Anforderungen, die besagen, dass das System eine bestimmte Eigenschaft niemals oder immer aufweisen darf. Ein ordnungsgemäßes Testen dieser Anforderungen würde einen unendlichen Testzyklus erfordern. Solche Anforderungen müssen so umformuliert werden, dass sie überprüfbar sind. Wie bereits erwähnt, müssen alle Anforderungen überprüfbar sein.

Nichtfunktionale Anforderungen, die auf Softwareebene nicht verifizierbar sind, müssen dennoch als Dokumentation der Kundenabsicht aufbewahrt werden. Sie können jedoch auf Prozessanforderungen zurückgeführt werden, die sich als praktikabler Weg zu ihrer Erfüllung erweisen. Beispielsweise kann die nichtfunktionale Anforderung, frei von Hintertüren zu sein , durch die Prozessanforderung der Verwendung von Paarprogrammierung erfüllt werden . Andere nichtfunktionale Anforderungen lassen sich auf andere Systemkomponenten zurückführen und werden auf dieser Ebene verifiziert. So wird beispielsweise die Systemzuverlässigkeit häufig durch Analysen auf Systemebene verifiziert. Avioniksoftware mit ihren komplexen Sicherheitsanforderungen muss dem DO-178B -Entwicklungsprozess folgen.

Aktivitäten, die zur Ableitung der System- oder Softwareanforderungen führen. Das Anforderungsmanagement kann eine Machbarkeitsstudie oder eine Konzeptanalysephase des Projekts sowie die Anforderungserhebung (Erfassung, Verständnis, Überprüfung und Formulierung der Bedürfnisse der Stakeholder ), die Anforderungsanalyse ^{[ 10 ]} ( Prüfung auf Konsistenz und Vollständigkeit), die Spezifikation (Dokumentation der Anforderungen) und die Validierung (Sicherstellung der Korrektheit der spezifizierten Anforderungen) umfassen. ^{[ 11 ] [ 12 ]}

Anforderungen sind anfällig für Mehrdeutigkeiten, Unvollständigkeiten und Inkonsistenzen. Techniken wie die sorgfältige Prüfung haben sich als hilfreich erwiesen, um diese Probleme zu beheben. Mehrdeutigkeiten, Unvollständigkeiten und Inkonsistenzen, die in der Anforderungsphase behoben werden können, verursachen in der Regel um ein Vielfaches geringere Korrekturkosten als dieselben Probleme, wenn sie in späteren Phasen der Produktentwicklung entdeckt werden. Die Anforderungsanalyse zielt darauf ab, diese Probleme zu lösen.

Es gilt, einen technischen Kompromiss zwischen zu vagen Anforderungen und solchen, die so detailliert sind, dass sie

• Die Herstellung dauert lange – manchmal so lange, dass die Produkte nach ihrer Fertigstellung bereits veraltet sind.
• die verfügbaren Implementierungsoptionen einschränken
• sind kostspielig in der Herstellung

Agile Ansätze entwickelten sich als Mittel zur Überwindung dieser Probleme, indem Anforderungen auf einer hohen Ebene als Basis festgelegt und Details erst bei Bedarf oder zum letzten verantwortlichen Moment ausgearbeitet werden .

Anforderungen dienen üblicherweise der Kommunikation zwischen den verschiedenen Beteiligten. Daher sollten sie sowohl für normale Anwender als auch für Entwickler leicht verständlich sein. Eine gängige Methode zur Dokumentation von Anforderungen besteht darin, zu beschreiben, was das System leisten muss. Beispiel: „Der Auftragnehmer muss das Produkt bis spätestens Datum xyz liefern.“ Weitere Methoden sind Anwendungsfälle und User Stories .

Anforderungen ändern sich in der Regel im Laufe der Zeit. Nach ihrer Definition und Genehmigung unterliegen sie dem Änderungsmanagement . Bei vielen Projekten werden Anforderungen bereits vor Fertigstellung des Systems geändert. Dies liegt unter anderem an der Komplexität von Software und daran, dass Anwender oft erst nach der Implementierung wissen, was sie genau benötigen. Diese Eigenschaft von Anforderungen hat zu Studien und Praktiken im Bereich des Anforderungsmanagements geführt.

Es gibt verschiedene, teils unterschiedliche Auffassungen darüber, was Anforderungen sind und wie sie verwaltet und genutzt werden sollten. Zwei führende Branchenverbände sind das IEEE und das IIBA. Beide Organisationen haben zwar unterschiedliche, aber dennoch ähnliche Definitionen von Anforderungen.

Viele Projekte waren erfolgreich, obwohl es kaum oder gar keine Einigung über die Anforderungen gab. ^{[ 13 ]} Es gibt zudem Hinweise darauf, dass die Spezifizierung von Anforderungen Kreativität und Designleistung beeinträchtigen kann. ^{[ 14 ]} Anforderungen behindern Kreativität und Design, weil sich Designer zu sehr mit den bereitgestellten Informationen beschäftigen. ^{[ 15 ] [ 16 ] [ 17 ]} Allgemeiner gefasst legen einige Forschungsergebnisse nahe, dass Softwareanforderungen eine Illusion sind , die entsteht, indem Designentscheidungen fälschlicherweise als Anforderungen dargestellt werden, obwohl keine wirklichen Anforderungen vorliegen. ^{[ 18 ]}

Die meisten agilen Softwareentwicklungsmethoden stellen die Notwendigkeit einer detaillierten Beschreibung von Softwareanforderungen im Vorfeld infrage, da diese als dynamisch betrachtet werden. Extreme Programming beispielsweise beschreibt Anforderungen informell mithilfe von User Stories (kurze, auf eine Karteikarte passende Zusammenfassungen, die einen Aspekt der Systemfunktionalität erläutern) und sieht es als Aufgabe des Entwicklers an, den Kunden bei Unklarheiten direkt zu kontaktieren. Agile Methoden versuchen, Anforderungen in einer Reihe automatisierter Akzeptanztests zu erfassen .

Durch sich im Laufe der Zeit ändernde Anforderungen kann es zu einer Ausweitung des Projektumfangs kommen. Im Anforderungsmanagement ist die Änderung von Anforderungen zwar zulässig, doch wenn diese nicht ausreichend nachverfolgt werden oder vorhergehende Schritte (Geschäftsziele zuerst, dann Benutzeranforderungen) nicht durch zusätzliche Kontrollen eingeschränkt oder als Kostenfaktor und potenzielles Projektrisiko betrachtet werden, sind Anforderungsänderungen leicht und wahrscheinlich. Es kann leicht passieren, dass sich Anforderungen schneller ändern, als Entwickler arbeiten können, und der damit verbundene Aufwand, frühere Änderungen rückgängig zu machen , ist entsprechend hoch.

Es gibt verschiedene Taxonomien für Anforderungen, je nachdem, welches Rahmenwerk verwendet wird (z. B. die Standards des IEEE im Vergleich zu den Ansätzen des IIBA oder des US-Verteidigungsministeriums). Unterschiedliche Formulierungen und Vorgehensweisen in verschiedenen Kontexten oder informelle Ausdrücke können zu Verwirrung und Abweichungen vom gewünschten Prozess führen.

Ein von Menschen gesteuerter Prozess unterliegt menschlichen Fehlern in der Steuerung, bei denen Bequemlichkeit, persönliche Wünsche oder politische Erwägungen zu Ausnahmen oder gar zur Untergrabung des Prozesses und zu Abweichungen vom eigentlich vorgesehenen Ablauf führen können. Beispiele hierfür sind:

• Prozesse ohne Strenge finden keinen Respekt – Wenn Ausnahmen oder Änderungen häufig vorkommen, beispielsweise weil die Organisation, die den Prozess durchführt, wenig Unabhängigkeit oder Macht besitzt oder in ihren Aufzeichnungen nicht zuverlässig und transparent ist, kann dies dazu führen, dass der gesamte Prozess ignoriert wird.
• Neue Akteure, die eine zweite Chance wollen – z. B. die natürliche Tendenz neuer Mitarbeiter, die Arbeit ihrer Vorgänger zu verändern, um ihre Macht oder ihren Wertanspruch zu demonstrieren, wie etwa ein neuer CEO, der die Planung des vorherigen CEOs, einschließlich der Geschäftsziele, für etwas (z. B. eine Softwarelösung) ändern möchte, das sich bereits in der Entwicklung befindet, oder neu erstellte Büroobjekte in die aktuelle Entwicklung eines Projekts einbeziehen möchte, weil diese zum Zeitpunkt der Erstellung der Benutzeranforderungen noch nicht existierten, sodass sie versuchen, das Projekt zurückzuverfolgen und neu zu definieren.
• Malen außerhalb der Linien - z.B. geben Benutzer, die mehr Kontrolle wünschen, nicht nur Dinge ein, die der Definition des Anforderungsmanagements von "Benutzeranforderung" oder der Prioritätsstufe entsprechen, sondern fügen Designdetails oder bevorzugte Eigenschaften von Anbietern als Benutzeranforderungen ein oder alles, was ihr Büro als höchstmögliche Priorität angibt.
• Spätes Erscheinen – z. B. geringe oder gar keine Bemühungen bei der Anforderungserhebung vor der Entwicklung. Dies kann darauf zurückzuführen sein, dass man annimmt, unabhängig von der individuellen Beteiligung denselben Nutzen zu erzielen, oder dass es sinnlos erscheint, Anforderungen einfach in der Testphase und beim nächsten Durchlauf einzufügen, oder auf die Präferenz, durch das Abwarten auf Feedback nach der Arbeit immer Recht zu haben.

Im Rahmen des Prozesses des US-Verteidigungsministeriums gibt es einige historische Beispiele für Probleme mit den Anforderungen:

• die in Pentagon Wars dargestellten Probleme der Bewegungsabläufe beim M-2 Bradley ;
• Das Wachstum der F-16 vom Konzept des leichten Kampfflugzeugs durch die „Fighter Mafia“ wird darauf zurückgeführt, dass das F-15-Programm versucht, die Konkurrenz zu sabotieren, oder dass einzelne Abteilungen lokale Interessen verfolgen, wodurch das Konzept von geringem Gewicht und niedrigen Kosten untergraben wird.
• Die Begeisterung für „Net-Ready“ um 1998 führte dazu, dass es vom Net-Ready-Büro als Key Performance Parameter (KPP) festgelegt wurde, außerhalb des Büros, das den Prozess der Anforderungsdefinition festlegte und nicht mit dem zuvor definierten Prozess dieses Büros, seiner Definition dessen, was ein KPP ist, oder der Tatsache, dass einige Bemühungen möglicherweise nicht geeignet oder in der Lage sind, zu definieren, was „Net-Ready“ ausmacht.

• Geschäftsanforderungen
• Softwareanforderungen
• Anforderungsanalyse
• Anforderungsanalyse
• Anforderungserhebung
• Anforderungsmanagement
• Anforderungspriorisierung
• Rückverfolgbarkeit der Anforderungen
• Spezifikation (technischer Standard)
• „Shall“ und „will“ – Formulierung
• MoSCoW-Methode – Priorisierungstechnik
• Benutzergeschichte
• Anwendungsfall

• Systemanforderungen ermitteln