Requirements EngineeringRequirements Engineering umfasst das Ermitteln, Analysieren, Spezifizieren und Validieren aller Eigenschaften und Rahmenbedingungen eines Softwaresystems, die über seinen gesamten Lebenszyklus gewünscht werden bzw. relevant sind. 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 AnforderungenAnforderungen 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]:
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:
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.]:
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ätenIm 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:
Techniken zum Ermitteln von AnforderungenExistierende 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:
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-EinsatzEine 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]. LiteraturBoehm, 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, 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![]() Prof. Dr. Susanne Patig, IWI, Universität Bern, Engehaldenstrasse 8, CH-3012 Bern, Switzerland Prof. Dr. Jens Dibbern Institut für Wirtschaftsinformatik Abteilung Information Engineering Universität Bern Engehaldenstr. 8, Büro 207 CH - 3012 Bern |