Requirements Engineering

Im Detail variieren die Definitionen des Begriffs ‚Requirements Engineering‛. Alle Definitionen führen jedoch bestimmte Kernaktivitäten auf (ermitteln, spezifizieren, prüfen), die an Anforderungen (Systemeigenschaften und Rahmenbedingungen) vollzogen werden, s. Abb. 1. Der begleitende Prozess, der Änderungen von Anforderungen verfolgt, Anforderungsdokumente über ihren gesamten Lebenszyklus verwaltet und die Kernaktivitäten des Requirements Engineering plant, organisiert und kontrolliert, heißt Requirements Management [CMU/SEI 2006, p. 143; Sommerville 2011, p. 111; Pohl 2010, p. 594].

Abb. 1: Requirements Engineering und Requirements Management

Anforderungen

Anforderungen beschreiben die Eigenschaften, die ein Softwaresystem besitzen muss, sowie Rahmenbedingungen, die für seinen Lebenszyklus (Entwicklung, Betrieb, Wartung) gelten [IEEE Std. 610.12-1990, p. 62; Rupp et al. 2009, S. 17 f.]. Abb. 2 fasst die Arten von Anforderungen zusammen.

Abb. 2: Arten von Anforderungen

Hinsichtlich der Eigenschaften des Softwaresystems lassen sich funktionale Anforderungen und Qualitätsanforderungen unterscheiden [Sommerville 2011, p. 85; Pohl 2010, p. 17-19]:

• Funktionale Anforderungen geben an, was das Softwaresystem oder einzelne seiner Komponenten tun sollen (und was nicht). Typischerweise werden diese Anforderungen definiert aus der Funktionsperspektive (Systeminput und -output, Fehlersituationen), aus der Datenperspektive (Datenstrukturen und Integritätsbedingungen) und aus der Verhaltensperspektive (Systemzustände, Zustandsübergänge, Ereignisse) [Pohl 2010, p. 214-215].
• Qualitätsanforderungen geben Kriterien an für die Güte des Softwaresystems oder einzelner Systembestandteile. Beispiele für solche Anforderungen sind Zuverlässigkeit, Benutzbarkeit und Performance (aus der Sicht der Systembenutzer) sowie Änderbarkeit und Portabilität (aus der Sicht der Entwickler).

Rahmenbedingungen sind Anforderungen, die die Realisierungsmöglichkeiten für ein Softwaresystem einschränken und nur schwer oder gar nicht geändert werden können. Nach ihrem Ursprung lassen sich Rahmenbedingungen klassifizieren als:

• Technologisch: die vorhandene, technische IT-Infrastruktur, in der das Softwaresystem betrieben und entwickelt werden soll
• Organisatorisch: Aufbau- und Ablauforganisation der Einheiten, die die Software nutzen (z. B. Abteilungen mit speziellen Zuständigkeiten) bzw. entwickeln (Vorgehensmodelle für die Entwicklung, Projekttermine)
• Rechtlich: einzuhaltende Gesetze und Richtlinien, z. B. hinsichtlich des Datenschutzes
• Ethisch: Sitten des jeweiligen Kulturkreises, denen das System genügen muss, um akzeptiert zu werden (z.B. Anredeformen)

Formuliert werden die Anforderungen durch die verschiedensten Stakeholder. Stakeholder sind Personen oder Organisationen mit Interesse am geplanten Softwaresystem, z. B. Geldgeber, Nutzer, Entwickler, Administratoren, die Marketingabteilung (in der Softwareindustrie) sowie Regulierungsbehörden und Kontrollgremien [Pohl 2010, p. 79].

Unabhängig von der Anforderungsart und den beteiligten Stakeholdern sollten die Anforderungen so formuliert werden, dass sie eine hohe Qualität besitzen. Typische Qualitätsmerkmale für einzelne Anforderungen sind [IEEE Std. 610.12-1990; Pohl 2010, p. 300; Schienmann 2001, S. 177 ff.]:

• Korrektheit: Die Anforderung entspricht den Bedürfnissen der Stakeholder.
• Eindeutigkeit: Die Formulierung der Anforderung erlaubt nur eine gültige Interpretation.
• Prüfbarkeit: Es lassen sich Kriterien oder Tests angeben, um nachzuweisen, ob die Anforderung erfüllt ist oder nicht.
• Nachverfolgbarkeit: Der Ursprung der Anforderung und ihre Entwicklung lassen sich feststellen.

Wird die Menge aller Anforderungen betrachtet, die an ein Softwaresystem gestellt werden, so muss jede Anforderung einmalig sein, darf sich nicht mit anderen Anforderungen überlappen (Normalisierung) oder zu diesen im Widerspruch stehen (Konsistenz). Zudem müssen sowohl die einzelne Anforderung als auch die Anforderungsmenge vollständig sein, d.h. jede Information für den gewünschten Sachverhalt bzw. alle Anforderungen an das Softwaresystem angeben.

Kernaktivitäten

Im Kern zielt das Requirements Engineering darauf ab, Anforderungen zu ermitteln, zu spezifizieren und zu prüfen. Diese Aktivitäten folgen nicht linear aufeinander, sondern sind durch Rücksprünge und Wiederholungen miteinander verbunden (s. Abb. 1). Deutlich wird dies z. B. am Prüfen von Anforderungen, das im Zusammenhang mit der Ermittlung auftritt (als Analysieren) und nach der Spezifikation (als Validieren). Im Einzelnen haben die Kernaktivitäten folgende Inhalte:

• Das Ermitteln soll sowohl existierende und als auch potenzielle Anforderungen an das Softwaresystem herausfinden [Pohl 2010, p. 395]. Dementsprechend gibt es unterschiedliche Ermittlungstechniken (s.u.).
• Das Analysieren (Prüfen I) dient dazu, die ermittelten, unstrukturierten Anforderungen zu klassifizieren und zu priorisieren [Sommerville 2011, 101]. Durch die Klassifikation entstehen Gruppen eng zusammenhängender Anforderungen; redundante, überlappende oder konfliktäre Anforderungen werden so deutlich. Verhandlungen zwischen den verschiedenen Stakeholdern lösen diese Probleme auf und ermöglichen die Priorisierung von Anforderungen (Übereinstimmung) [Pohl 2010, p. 487].
• Das Spezifizieren überführt die analysierten Anforderungen in eine Standardform. Die Standardform gibt mindestens einheitliche Attribute für jede Anforderung vor (z.B. Anforderungsschablonen [Rupp et al. 2009, S. 161 ff.]), teilweise auch den kompletten Aufbau des Anforderungsdokuments (z. B. IEEE/ANSI 830-1998). Grundsätzlich dürfen solche Dokumentationsvorschriften je Projekt frei definiert werden [Pohl 2010, p. 332-350]. Modelle können die resultierenden Dokumente ergänzen.
• Schließlich prüft das Validieren (Prüfen II), ob die spezifizierten Anforderungen tatsächlich das repräsentieren, was die Stakeholder vom Softwaresystem erwarten [Sommerville 2011, 110]. So soll gesichert werden, dass auf der Grundlage der Anforderungen das ‚richtige‛ Softwaresystem entwickelt wird. Nötigenfalls werden aufgedeckte Mängel der Konsistenz, Vollständigkeit oder formalen Korrektheit sowie Konflikte zwischen Anforderungen behoben [Pohl 2010, p. 494-498].

Techniken zum Ermitteln von Anforderungen

Existierende Anforderungen lassen sich durch Befragungen oder Analysen ermitteln, neue und innovative hingegen vor allem durch den Einsatz von Kreativitätstechniken [Pohl 2010, p. 408-450; Rupp et al. 2009, S. 86 ff.].

Befragungen können schriftlich oder mündlich (als Interview) durchgeführt werden; in beiden Fällen ist die Nutzung von Fragebögen möglich. Da sich mit Befragungen nur Anforderungen erfassen lassen, die den befragten Personen bewusst sind und die artikuliert werden können, sollte diese Ermittlungstechnik durch mindestens eine Form der Analyse ergänzt werden.

Analysen helfen dabei, unbewusste Anforderungen aufzudecken. Es lassen sich folgende Analysegegenstände und damit Arten von Analysen unterscheiden:

• vorhandene Softwaresysteme (Systemanalyse, z. B. abzulösende Altsysteme, Standardsoftware)
• Dokumente (Dokumentenanalyse, z. B. Architekturhandbücher, Benutzerdokumente, Fehlerberichte, Referenzmodelle)
• Nutzer in ihrem Umgang mit dem System (Beobachtung, Apprenticing).

Die Gefahren von Analysen liegen in falschen Ausgangsgrundlagen (fehlerhafte Dokumente, nicht authentisches Verhalten), Wahrnehmungsverzerrungen sowie im Zementieren des vorgefundenen und u. U. nicht mehr erwünschten Status quo.

Um neue, innovative Anforderungen zu ermitteln, setzt man Kreativitätstechniken ein, z. B. Brainstorming, Mind Mapping oder Kartentechniken (CRC-Karten, Snowcards [Rupp et al. 2009, S. 86 ff.]). Meist werden dazu Workshops mit Vertretern aller Stakeholdergruppen durchgeführt.

IT-Einsatz 

Eine wichtige Rolle innerhalb des Requirements Engineering spielt die Unterstützung durch IT. Bereits in frühen Jahren wurden Werkzeuge des Computer Aided Software Engineering (CASE) entwickelt, mit deren Hilfe Anforderungen in bestimmten Modellierungssprachen repräsentiert werden konnten [Konsynski et al. 1985; Teichrow et al. 1977]. Gerade aufgrund ihrer Abstraktion von der natürlichsprachigen Welt der Anwender waren diese Modellierungssprachen allerdings wenig geeignet, um das gemeinsame Verständnis zwischen Anwendern und Entwicklern in den früheren Phasen des Requirements-Engineering-Prozesses zu fördern [Guinan et al. 1998]. Um dieses Defizit zu beheben, hat man zunächst versucht, existierende Groupware für die Unterstützung der Kommunikation zwischen Anwendern und Entwicklern heranzuziehen; sie wurde beispielsweise zur konkreten Umsetzung der Prinzipien des Joint Application Development (JAD) angepasst [Chen et al. 1991]. Das Groupwaresystem Easy WinWin von Boehm et al. (2001) gehört zu den bekanntesten Systemen dieser Gattung.

Neuerdings wird angestrebt, nicht nur den persönlichen Austausch zwischen Anwendern und Entwicklern durch den begleitenden Einsatz von IT-Werkzeugen zu fördern, sondern diesen sogar zu substituieren. Die Notwendigkeit dafür ergibt sich vor allem durch die zunehmende örtliche und zeitliche Distanz ‑ sowohl innerhalb als auch zwischen den Gruppen der Anwender und Entwickler, da Software heute oft in global verteilten Teams entwickelt wird. Die Forschung konzentriert sich darauf, alle Kernaktivitäten des Requirements Engineering sowie das Requirements Management ganzheitlich mit Hilfe internetbasierter Technologien zu unterstützen [Dibbern et al. 2009; Gruenbacher et al. 2003; Lang et al. 2001; Seyff et al. 2005; Sinha et al. 2006].

Literatur

Boehm, B.; Grunbacher, P.; Briggs, R.O.: Developing groupware for requirements negotiation: lessons learned. In: IEEE Software 18 (2001), pp 46-55.

Carnegie Mellon Software Engineering Institute (CMU/SEI): CMMI® for Development, Version 1.2. CMU/SEI-2006-TR-008, ESC-TR-2006-008. Carnegie Mellon University,
August 2006.

Chen, M.; Nunamaker, J.F.: The Architecture and Design of a Collaborative Environment for Systems Definition, In: The DATA BASE for Advances in Information Systems 22 (1991), pp 22-28.

Dibbern, J.; Geisser, M.; Hildenbrand, T.; Heinzl, A.: Design, Implementation, and Evaluation of an ICT-Supported Collaboration Methodology for Distributed Requirements Determination. Working Paper 5/2009, University of Mannheim, 2009.

Gruenbacher, P.; Braunsberger, P.: Tool Support for Distributed Requirements Negotiation. In: Cimitile, A.; Lucia, A.D.; Gall, H. (Eds.)Cooperative Methods and Tools for Distributed Software Processe., Milano; Franco Angeli, pp. 56-66.

Guinan, P.J.; Cooprider, J.G.; Faraj, S.: Enabling Software Development Team Performance During Requirements Definition: A Behavioral Versus Technical Approach, In: Information Systems Research 9 (1998), pp 101-125.

Konsynski, B.; Kottemann, J.; Nunamaker, J.; Scott, J.: PLEXSYS-84: An Integrated Development Environment for Information Systems, In: Journal of Management Information Systems 1 (1985), pp 62-104.

Lang, M.; Duggan, J.: A Tool to Support Collaborative Software Requirements Management, In: Requirements Engineering 6 (2001), pp 161-172.

Pohl, Klaus: Requirements Engineering: Fundamentals, Principles and Techniques. Berlin et al.: Springer, 2010.

Rupp, C. et al.: Requirements Engineering und –Management : Professionelle, iterative Anforderungsanalyse für  die Praxis. 5. Aufl., München/Wien: Hanser, 2009.

Seyff, N.; Kroiher, E.; Hoyer, C.; Grünbacher, P.: Enhancing GSS-based Requirements Negotiation with Distributed and Mobile Tools. In: IEEE (Ed.): Proceedings WETICE'05: 14th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprise. Los Alamitos: IEEE, 2005, pp. 87-92.

Schienmann, B.: Kontinuierliches Anforderungsmanagement: Prozesse, Techniken, Werkzeuge. München et al.: Addison-Wesley, 2002.

Sinha, V.; Sengupta, B.; Chandra, S.: Enabling Collaboration in Distributed Requirements Management, In: IEEE Software 23 (2006), pp 52-61.

Sommerville, Ian: Software Engineering. 9th edition, Harlow et al.: Addison-Wesley, 2011.

Teichrow, D.; Hershey, E.A.: PSL/PSA: A Computer-Aided Technique for Structured Documentation and Analysis of Information Processing Systems, In: IEEE Transactions on Software Engineering 3 (1977), pp 41-48.

IEEE: Recommended Practice for Software Requirements Specifications. IEEE Standard 830-1998. New York : The Institute of Electrical and Electronics Engineers, Inc., 1998.

IEEE: Standard Glossary of Software Engineering Terminology. IEEE Standard 610.12-1990. New York : The Institute of Electrical and Electronics Engineers, Inc., 1990.

Autoren