Requirement Engineering (RE) bedeutet übersetzt etwa Anforderungstechnik, allerdings ist auch im deutschen Sprachraum der Begriff „Requirement Engineering“ gebräuchlicher. Konkret geht es dabei um die systematische Ermittelung, Beschreibung, Prüfung und Verwaltung von Anforderungen in der Systementwicklung. Das letztendlich Ziel ist dann die Produktion einer guten „Software Requirements Specification“ (SRS).
Requirement Engineering ist heute wichtige denn je und ein elementarer Bestandteil von Web Engineering. Web-Projekte scheitern selten technologie-bedingt, viel mehr an der Fehleinschätzung des Auftragsproblems, als Resultat von falschen Anforderungen. Sichtbar macht dies unter anderem die Ergebnisse des sogenannten CHAOS-Reports. Diese Studie beschäftigt sich mit den Erfolgs- und Misserfolgsfaktoren in IT-Projekten und gehört zu den bekanntesten und wichtigsten Langzeitstudien im Bereich Projektmanagement. In den Top-10 der Erfolgsfaktoren eines Projektes landeten im Jahr 2013 unter anderem die Punkte: „Exekutive Management support“ (Platz 1), „User involvement“ (Platz 2), „Optimization“ (Platz 3), „Projekt Management expertise“ (Platz 5) oder auch „Agile Process“ (Platz 6).
Inhaltsverzeichnis
Was sind Requirements?
Bevor man sich dem Requirement Engineering widmet, muss man erst einmal wissen, was denn überhaupt Requirements, also auf Deutsch „Anforderungen“, überhaupt sind. Eine bzw. gleich mehrere Definitionen liefert der IEEE Standard Glossar für Software Engineering Technology. Danach wird eine Software Anforderung beschrieben als:
- Eine Bedingung oder Fähigkeit, die ein User zum Lösen eines Problems oder dem Erreichen eines Ziels benötigt (A condition or capability needed by a user to solve a problem or achieve an objective.)
- Eine Bedingung oder Fähigkeit, die ein System oder Systemkomponente erfüllen oder besitzen muss, um einen Vertrag, Standard, Spezifikation oder ein anderes formell bestimmtes Dokument zu erfüllen. (A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.)
- Eine dokumentierte Darstellung einer Bedingung oder Fähigkeit, wie in 1. oder 2. (A documented representation of a condition or capability as in 1 or 2.)
Funktionale vs. Nicht-funktionale Anforderungen
Weiter unterscheidet man Anforderungen in funktionale und nicht-funktionale Anforderungen (functional / non-functional requirements). In einem Satz ausgedrückt betreffen funktionale Anforderungen die Dienste eines Systems und nicht-funktionale Anforderungen die Qualitätsaspekte/Kostenziele.
Phasen des Requirements development process
Basierend auf den „Software Requirements“ lassen sich auch für das Requirements Engineering bei Web-Anwendungen die folgenden fünf Phasen bilden:
- Initiate
- Elicitation
- Assess
- Specification
- Validation
Zu beachten ist, dass die Benennung der Phasen abweichen kann.
Initiate Phase
Die „Initiation“ ist der Prozess der formellen Autorisierung eines neues Projekts. Der rituelle Akt ist dabei das sogenannte „Project Kick-off“. Am Ende der Phase steht ein Projektauftrag (Project Charter), welches das Projekt zu einem offiziellen Projekt macht. Es findet das erste Kundentreffen statt, bei dem unter anderem mit der Geschäftsleitung (CEO, CTO, CIO) gesprochen wird. Aus diesen Gesprächen leiten sich anschließend die Business Requirements ab.
Im Microsoft Solutions Framework heißt die Initiation Phase übrigens Envisioning. Darin wird ein erstes Vision Statement (strategischer Plan, Fokus auf business requirements) entwickelt. Am Ende der Phase steht ein Vision und Scope Document (im Vergleich bei SCRUM: Backlock & User Stories).
Am Ende der Initiate Phase besitzt man im besten Fall also: Vision und Scope Dokument, gesammelte Business Requirements, Glossar, Memorandum of Agreement und ein Projektauftrag (Project Charter).
Elicit Phase
In der Elicit Phase geht es unter anderem um die Präzisierung der business requirements. Dafür werden beispielsweise die Use Cases aus der Initiate Phase umgeschrieben/vervollständigt. Allgemein werden weitere Anforderungen gesammelt (über Interviews, Shadowing, Umfragen …) und zusammen mit den existierenden Business Requirements klassifiziert nach:
- Business Requirements: Fokus auf Daten und Semantiken (Inhalt) und ihr Nutzen
- User Requirements: Fokus auf User Interface Design
- Operations Requirements: Fokus auf System Management und Betrieb
- Environmental Requirements: Fokus auf Prozess und Kommunikationsaspekte
Ähnliche Themen: