Requirements Engineering und Spezifikation

Requirements Engineering

Bevor in einem Softwareprojekt mit der Konstruktion der Software begonnen werden kann, muss zunächst das Ziel bestimmt werden, das mit dem System erreicht werden soll. Eine grobe Zielbestimmung erfolgt dabei bereits in der Phase Planung im Softwarelebenszyklus. Ausgehend von diesem Ziel, müssen nun Stück für Stück alle Funktionen und Eigenschaften des Systems ermittelt werden, welche das System nach Abschluss der Entwicklung unterstützen soll.

Beispiel:
In der Planungsphase wird beschlossen ein System einzuführen, mit dem die Beantragung und Abrechnung von Dienstreisen durchgängig digitalisiert werden kann, um vollständig auf Papierformulare zu verzichten. Ausgehend von diesem allgemeinen Ziel des Systems müssen nun die konkreten Funktionen ermittelt, dokumentiert und abgestimmt werden, die das Softwareentwicklungsteam dann umsetzen soll.

Im Software Engineering werden die geforderten Funktionen und Eigenschaften Anforderungen (engl.: requirements) genannt. Die Aktivitäten zur Ermittlung, Dokumentation, Abstimmung und Verwaltung werden unter dem Begriff "Requirements Engineering" (abgekürzt: RE) zusammengefasst. Pohl und Rupp definieren Requirements Engineering folgendermaßen:

"Requirements Engineering (RE) ist ein kooperativer, iterativer, inkrementeller Prozess, dessen Ziel ist zu gewährleisten, dass:

• Alle relevanten Anforderungen bekannt und in erforderlichem Detaillierungsgrad verstanden sind.
• Alle Anforderungen konform zu den Dokumentationsvorschriften dokumentiert bzw. konform zu den Spezifikationsvorschriften spezifiziert sind.
• Die involvierten Stakeholder ausreichende Übereinstimmung über die bekannten Anforderungen erzielen."

Folgende Merkmale zum Requirements Engineering lassen sich aus dieser Definition ableiten:

In Aktivitäten des RE sind immer mehrere Personen oder Personengruppen involviert, die miteinander kooperieren müssen. Konkret handelt es sich dabei um Personen oder Personengruppen, deren Arbeits- und Einflussbereich vom zu erstellenden System beeinflusst wird oder mit dem System in Kontakt kommt. Aber auch alle Personen deren Arbeits- und Einflussbereich am Erstellungsprozess des Systems miteinbezogen wird. Die Menge aller betroffenen bzw. beteiligten Personen wird "Stakeholder" genannt.

Requirements Engineering ist keine einzelne, abgeschlossene Aktivität zu Beginn eines Softwareprojektes. RE erfolgt in mehreren Zyklen (sogenannten Iterationen). Durch mehrfache Durchführung von Aktivitäten des RE werden Anforderungen an das System Stück für Stück ermittelt und verfeinert. Da Software Engineering ein stark erkenntnisgetriebener Prozess ist, erfolgt RE in der Regel projektbegleitend.

Aus der oben genannten Definition von RE lassen sich drei Kernaktivitäten des Requirements Engineerings ableiten:

• Ermittlung von Anforderungen
• Dokumentation von Anforderungen
• Prüfen und Abstimmen von Anforderungen

Zu diesen Aktivitäten lässt sich keine feste Reihenfolge beschreiben, denn der verantwortliche Requirements Engineer entscheidet immer in Abhängigkeit der aktuellen Projektsituation welche Art von Aktivität als nächstes erfolgt.

Ermittlung von Anforderungen

Ziel der Aktivität "Ermittlung" von Anforderungen ist die Identifikation der Anforderungen an das System, die zur Erreichung des Ziels benötigt werden. Dafür müssen die Anforderungen erkannt und in dem für die aktuelle Projektsituation erforderlichen Detaillierungsgrad verstanden werden.

Beispiel:
Beim Start des Projektes ist zunächst wichtig, alle relevanten grundsätzlichen Funktionsbereiche zu ermitteln, ohne dabei bereits auf Details einzugehen (z. B. "Anlegen einer Dienstreise", "Bearbeiten einer Dienstreise", "Anlegen einer Reisekostenabrechnung", "Erstattung von Spesen", "Genehmigen der Spesenerstattung"). Je weiter fortgeschritten ein Projekt ist, desto detaillierter müssen die einzelnen Anforderungen beschrieben werden. So muss zum Funktionsbereich "Bearbeiten einer Dienstreise" unter anderem genau festgelegt werden, welche Eingabefelder zur Verfügung stehen, welche Felder Pflichtfelder sind, welche Bedingungen eingehalten werden müssen und welche Personen überhaupt Änderungen vornehmen dürfen.

Die systematische Ermittlung von Anforderungen unterteilt sich in die folgenden vier Schritte:

1. Systemkontext bestimmen: Es wird analysiert, welche Stakeholder und welche anderen Systeme direkte Abhängigkeiten zu dem erstellenden System haben. Diese müssen beim RE explizit mit berücksichtigt werden.
2. Quellen für Anforderungen ermitteln: Typische Quellen für Anforderungen sind Stakeholder, Dokumente (z. B. Gesetze, Richtlinien) und andere Systeme (z. B. abzulösende Altsysteme oder Konkurrenzsysteme).
3. Geeignete Ermittlungstechniken auswählen: Je nach Anforderungsquelle, Projektsituation und Art der Anforderungen muss eine geeignete Ermittlungstechnik oder eine Kombination aus verschiedenen Ermittlungstechniken ausgewählt werden (z. B. Befragungstechnik, Kreativitätstechnik, Beobachtungstechnik, Erstellen von GUI-Prototypen).
4. Anforderungen unter Einsatz der Technik ermitteln: Aus den bestimmten Quellen mit den gewählten Ermittlungstechniken werden Anforderungen in dem für die aktuelle Situation erforderlichen Detailgrad ermittelt.

Dokumentation von Anforderungen

Ziel der Aktivität "Dokumentation" ist es, dafür zu sorgen, dass der aktuelle Erkenntnisstand für alle Stakeholder gesichert wird und sich jeder Beteiligte zu jeder Zeit einen Überblick verschaffen kann. Anforderungsdokumente sind in der organisationsübergreifenden Softwareentwicklung Bestandteil von rechtsgültigen Verträgen, auf deren Basis geprüft wird, ob die vereinbarte Leistung durch den SW-Hersteller auch tatsächlich erbracht wurde.

Um komplizierte Strukturen und Zusammenhänge geeignet zu dokumentieren, werden im Software Engineering ergänzend zur Beschreibung von Anforderungen in Textform häufig grafische Modelle, sogenannte Softwaremodelle (sind grafische Modelle, deren Notationselemente eine festgelegte Bedeutung haben) eingesetzt. Die konkrete Dokumentationsform ist jedoch immer abhängig von der Art der Anforderungen, die dokumentiert werden sollen, vom Zweck und vom Personenkreis, für den die Dokumentation bestimmt ist, und von Vorschriften oder Vereinbarungen zum Dokumentationsformat, die im Rahmen des Projektes gelten.

Für die systematische Dokumentation von Anforderungen lassen sich vier Schritte identifizieren:

1. Zweck und Zielgruppe der Dokumentation bestimmen: Die Dokumentation von Anforderungen unterstützt den Kommunikationsprozess im Softwareprojekt. Daher müssen vor der Dokumentation gezielt Zweck und Zielgruppe bestimmt werden, für welche die Dokumentation erstellt wird.
2. Detailebene und Darstellungsart auswählen: In Abhängigkeit von Zweck und Zielgruppe werden die Detaillierungsebene und die Darstellungsart (z. B. Text, Grafiken, Softwaremodelle, Prototypen) festgelegt.
3. Anforderungen dokumentieren: Die ermittelten Anforderungen müssen in einer für den Zweck und die Zielgruppe geeigneten Form dokumentiert werden.
4. Prüfen: Passt die Dokumentation noch zu Zweck und Zielgruppe? Nach Abschluss der Dokumentation muss noch einmal kritisch reflektiert werden, ob die Art und Form noch zum Zweck und der Zielgruppe passen. Damit wird noch einmal geprüft, ob sich das Dokumentationsteam gegebenenfalls verrannt hat oder ob sich während der Dokumentation aus dem aktuellen Projektverlauf die Zielgruppe oder der Zweck geändert haben.

Prüfen und Abstimmen von Anforderungen

Da alle weiteren Aktivitäten im Software Engineering direkt von den ermittelten und dokumentierten Anforderungen abhängen, müssen die Anforderungen vor der Freigabe zur Umsetzung geprüft und mit den relevanten Stakeholdern abgestimmt werden. Ziel der Prüfung ist, die Qualität der Menge der dokumentierten Anforderung hinsichtlich der Kriterien Inhalt, Dokumentation und Abgestimmtheit sicherzustellen. Mit der Prüfung soll erreicht werden, dass die Anforderungen eine hohe Dokumentationsqualität haben und beispielsweise Missverständnisse durch Mehrdeutigkeiten vermieden werden und sich widersprechende oder konkurrierende Anforderungen identifiziert werden.

Werden bei einer Prüfung Konflikte oder Widersprüche identifiziert, müssen diese unter Einbeziehung der Stakeholder aufgelöst werden. Insbesondere in Projekten zur Erstellung von industriellen Informationssystemen sind viele verschiedene Stakeholder einzubeziehen. Im Verlauf des Requirements Engineerings werden daher in der Regel konkurrierende oder sich gegenseitig widersprechende Anforderungen ermittelt und dokumentiert. Daher nimmt das Konfliktmanagement im Abstimmungsprozess eine wichtige Rolle ein.

Die Kernaktivität Prüfen und Abstimmen lässt sich in vier Schritte unterteilen:

1. Prüfkriterien festlegen: Im Vorfeld der Prüfung ist festzulegen, nach welchen Kriterien genau gepüft werden soll. Damit wird der Fokus der Prüfung bestimmt, was insbesondere bei der Prüfung von umfangreichen Dokumenten notwendig ist, um den vorgegebenen Zeitplan einzuhalten.
2. Prüfprinzipien und Prüftechniken auswählen: Abhängig von den Prüfkriterien, der zur Verfügung stehenden Zeit und dem aktuellen Stand der Dokumentation werden zu berücksichtigende Prüfprinzipien und Prüftechniken ausgewählt (z. B. Review, Walkthrough, Erstellung von Softwareartefakten).
3. Prüfung durchführen und Ergebnisse dokumentieren: Während der Prüfung sollten nur Ergebnisse dokumentiert werden. Die Fehlerbehebung erfolgt dann im Anschluss.
4. Abstimmen der Anforderungen/Konfliktmanagement: Werden bei der Prüfung Konflikte oder Widersprüche identifiziert, muss eine Abstimmung mit den relevanten Stakeholdern erfolgen, der sich gegebenenfalls Maßnahmen zur Konfliktauflösung anschließen.

Ergänzend zu den vorgestellten Kernaktivitäten wird in der Literatur auch die Verwaltung von Anforderungen als Kernaktivität genannt.