Download PRINCE2 Workbook PDF

TitlePRINCE2 Workbook
File Size2.2 MB
Total Pages128
Document Text Contents
Page 64

Anforderungsmanagement 61

Anforderungsmanagement
Anforderungsmanagement (AM; englisch requirements management, RM) ist ein Teilgebiet des Requirements
Engineerings (RE) sowie ein Teilgebiet der Business-Analyse und eine Managementaufgabe für die effiziente und
fehlerarme Entwicklung komplexer Systeme.
Weitere Disziplinen des RE sind z. B. die Anforderungsdefinition und beinhaltet dabei die Teilgebiete
Anforderungserhebung (engl. requirements elicitation), Anforderungsdokumentation (engl. requirements
documentation) und Anforderungsvalidierung (engl. requirements validation), während Anforderungsverwaltung
Maßnahmen zur Steuerung, Kontrolle und Verwaltung von Anforderungen, also Risikomanagement,
Änderungsmanagement und Umsetzungsmanagement umfasst.
Diese Definition trägt den Erkenntnissen aus der Vergangenheit Rechnung, dass Probleme mit Anforderungen
zumeist aus mangelndem Management ebendieser resultieren. Es ist inzwischen die Erkenntnis gereift, dass alleine
das Aufstellen von Anforderungen nicht ausreicht, sondern für die Realisierung eines Produktes oder Systems der
weitergehende Prozess des Anforderungsmanagements notwendig ist.

Ziele
Anforderungsmanagement ist vor allem dort von Bedeutung, wo komplexe Produkte bzw. Systeme konzipiert
werden und sehr arbeitsteilig an deren Entwicklung gearbeitet wird.
Das Ziel des Anforderungsmanagement ist es, ein gemeinsames Verständnis über ein zu entwickelndes System
zwischen Auftragnehmer und Auftraggeber zu erreichen. Zugleich dienen die resultierenden Dokumente häufig als
vertragliche Basis für eine weitere Umsetzung.
Ein gemeinsames Verständnis kann durch die Einführung und Umsetzung von Anforderungsmanagementmethoden
(u. a. Scoping, Anforderungserhebung, Anforderungsspezifikation, Anforderungsanalyse,
Anforderungsmodellierung, Anforderungsreviews) erreicht werden. Durch den Einsatz dieser Methoden kann die
Qualität der Anforderungsdokumentation gesteigert werden. Qualitätskriterien einer Anforderungsdokumentation
sind u. a. Verständlichkeit, Eindeutigkeit, Nachweisbarkeit, Widerspruchsfreiheit, Vollständigkeit, Testbarkeit.
Das Management von Anforderungen bedeutet, dass Prozesse definiert und implementiert werden, indem die
Anforderungsdokumentation während des gesamten Projektverlaufs aktualisiert wird und diese am Ende als
Grundlage für die Erstellung von Testfällen verwendet werden kann.

Normen und Sprache
Anforderungsmanagement gehört zu den elementaren Prozessen in den Software- und System-Reifegrad-Modellen
CMMI und ISO/IEC 15504 (SPICE) sowie im Standard ISO/IEC 12207.
Es verwendet zur Darstellung die natürliche Sprache, oder bei Bedarf eine formalisierte natürliche Sprache mit
eingeschränktem Vokabular und festen Satzkonstruktionen, den sogenannten Requirements Templates. Die ebenfalls
verstärkt verwendeten künstlichen Sprachen zur Modellierung wie z. B. UML oder Message Sequence Charts (MSC)
erleichtern in vielen Situationen eine Formulierung der Anforderungen.
Ziel einer Anforderungsspezifikation (u. a. Lastenheft, Pflichtenheft, Fachkonzept, …) ist es, die Anforderungen so
zu formulieren, dass zwischen dem Auftraggeber und Auftragnehmer ein gemeinsames Verständnis über das zu
entwickelnde System geschaffen wird. Um das bei natürlicher Sprache zu erreichen, sollten Regeln eingehalten
werden. Dabei wird beispielsweise empfohlen, kurze Sätze zu gebrauchen und ungenaue Adjektive und Adverbien
nicht zu verwenden (sogenannte „schwache Wörter“, engl. weak words, wie z. B. schneller, schöner, automatisch,
circa, …). Ein Autor einer Spezifikation sollte sich an diese Regeln halten, um die Qualität der Anforderungen zu
verbessern. Damit der Autor diese Regeln einhält, gibt es auch Software-Werkzeuge, die ihn dabei unterstützen

http://de.wikipedia.org/w/index.php?title=Englische_Sprache
http://de.wikipedia.org/w/index.php?title=Business-Analyse
http://de.wikipedia.org/w/index.php?title=System
http://de.wikipedia.org/w/index.php?title=Anforderungserhebung
http://de.wikipedia.org/w/index.php?title=Anforderungsdokumentation
http://de.wikipedia.org/w/index.php?title=Anforderungsvalidierung
http://de.wikipedia.org/w/index.php?title=Anforderung
http://de.wikipedia.org/w/index.php?title=Risikomanagement
http://de.wikipedia.org/w/index.php?title=%C3%84nderungsmanagement
http://de.wikipedia.org/w/index.php?title=Umsetzungsmanagement
http://de.wikipedia.org/w/index.php?title=Managementprozess
http://de.wikipedia.org/w/index.php?title=Vertrag
http://de.wikipedia.org/w/index.php?title=Scoping
http://de.wikipedia.org/w/index.php?title=Anforderungserhebung
http://de.wikipedia.org/w/index.php?title=Anforderungsspezifikation
http://de.wikipedia.org/w/index.php?title=Anforderungsmodellierung
http://de.wikipedia.org/w/index.php?title=Anforderungsreviews
http://de.wikipedia.org/w/index.php?title=Qualit%C3%A4tskriterien
http://de.wikipedia.org/w/index.php?title=Verst%C3%A4ndlichkeit
http://de.wikipedia.org/w/index.php?title=Eindeutigkeit
http://de.wikipedia.org/w/index.php?title=Nachweisbarkeit
http://de.wikipedia.org/w/index.php?title=Widerspruchsfreiheit
http://de.wikipedia.org/w/index.php?title=Vollst%C3%A4ndigkei
http://de.wikipedia.org/w/index.php?title=Testbarkeit
http://de.wikipedia.org/w/index.php?title=Prozess
http://de.wikipedia.org/w/index.php?title=CMMI
http://de.wikipedia.org/w/index.php?title=ISO/IEC_15504
http://de.wikipedia.org/w/index.php?title=ISO/IEC_12207
http://de.wikipedia.org/w/index.php?title=Sprache
http://de.wikipedia.org/w/index.php?title=Modell
http://de.wikipedia.org/w/index.php?title=Unified_Modeling_Language
http://de.wikipedia.org/w/index.php?title=Message_Sequence_Chart
http://de.wikipedia.org/w/index.php?title=Lastenheft
http://de.wikipedia.org/w/index.php?title=Pflichtenheft
http://de.wikipedia.org/w/index.php?title=Fachkonzept
http://de.wikipedia.org/w/index.php?title=Adjektiv
http://de.wikipedia.org/w/index.php?title=Adverb

Page 65

Anforderungsmanagement 62

können.
In Deutschland hat sich ein Standard zum einheitlichen Austausch von Anforderungen etabliert, das so genannte
Requirements Interchange Format (ReqIF, ehemals RIF). ReqIF wird durch ein XML Schema definiert und ist ein
Format und Datenmodell, das Strukturen für Anforderungen, deren Attribute, Typen, Zugriffsrechte, Relationen
(Links) usw. enthält. Die RIF-Projektgruppe wurde 2004 im Rahmen der Herstellerinitiative Software (HIS) von
deutschen Automobilherstellern wie Audi, BMW, Daimler, Porsche und Volkswagen gestartet. Grund war die
Notwendigkeit, Anforderungen zwischen verschiedenen Partnern auszutauschen, welche unterschiedliche RM-Tools
einsetzen.

Anwendung
Anforderungen dürfen bei Anforderungsmanagement nicht nur Aussagen über gewünschte Eigenschaften machen,
sondern müssen parallel dazu Kriterien beschreiben, wie diese Eigenschaften überprüft werden können
(Akzeptanzkriterien).
Diese oft auch als Testfälle bezeichneten Kriterien dienen nicht nur der Qualitätssicherung des Produktes, sondern
ganz wesentlich der Qualität der Anforderungen selbst, da das Beistellen eines Akzeptanzkriteriums zu einer
sofortigen inhaltlichen Überprüfung der Anforderung zwingt.

Anforderungsmanagement-Software
→ Hauptartikel: Anforderungsmanagement-Software
Um das Anforderungsmanagement besser zu strukturieren, Redundanzen zu reduzieren sowie
Versions-/Konfigurationsmanagement und Rückverfolgbarkeit zu ermöglichen, wird für das
Anforderungsmanagement Software eingesetzt. Diese Software sollte dann auch mehrbenutzerfähig sein. Vielfach
werden anstelle dieser speziellen Software Standard-Textverarbeitungsprogramme eingesetzt, was dann aber zu den
oben genannten Problemen führen kann.
Die Software basiert in aller Regel auf einer Datenbank, in der die Einzel-Requirements gespeichert und in der Folge
ihre Abarbeitung verfolgt und überwacht werden. Zu jedem Requirement wird der Start der Bearbeitung, die
Erreichung von Meilensteinen und der (erfolgreiche) Abschluss der Arbeit vermerkt.
Diese Anforderungsmanagementsoftware ermöglicht es meist über diese Datenbanken, Anforderungen in Beziehung
zu setzen. So können dann zum Beispiel Systemanforderungen auf Kundenanforderungen zurückgeführt werden und
damit unter anderem Systemanforderungen registriert werden, die auf keine Kundenanforderungen zurückzuführen
sind, um damit ein Overengineering zu vermeiden. Genauso können Tests mit den Anforderungen in Beziehung
gesetzt werden, um eine Vollständigkeit dieser Tests zu gewährleisten.

Literatur
• A. Herrmann, E. Knauss, R. Weißbach: Requirements Engineering und Projektmanagement. Springer, Berlin

2013, ISBN 978-3-642-29431-0.
• Klaus Pohl, Chris Rupp: Basiswissen Requirements Engineering. dpunkt.verlag, 2009, ISBN 978-3-89864-613-0.
• Christof Ebert: Systematisches Requirements Management. dpunkt.verlag, 2005, ISBN 3-89864-336-0.
• Bruno Schienmann: Kontinuierliches Anforderungsmanagement : Prozesse – Techniken – Werkzeuge.

Addison-Wesley, München 2001, ISBN 3-8273-1787-8.
• Colin Hood, Simon Wiedemann, Stefan Fichtinger, Urte Pautz: Requirements Management: Interface Between

Requirements Development and All Other Systems Engineering Processes. Springer, Berlin 2007, ISBN
978-3-540-47689-4.

• Andreas Kress, Robert Stevenson, Rupert Wiebel, Colin Hood, Gerhard Versteegen: Requirements Engineering
Methoden und Techniken, Einführungsszenarien und Werkzeuge im Vergleich, iX Studie

http://de.wikipedia.org/w/index.php?title=Requirements_Interchange_Format
http://de.wikipedia.org/w/index.php?title=XML_Schema
http://de.wikipedia.org/w/index.php?title=Herstellerinitiative_Software
http://de.wikipedia.org/w/index.php?title=Akzeptanzkriterium
http://de.wikipedia.org/w/index.php?title=Anforderungsmanagement-Software
http://de.wikipedia.org/w/index.php?title=Versionierung
http://de.wikipedia.org/w/index.php?title=R%C3%BCckverfolgbarkeit_%28Anforderungsmanagement%29
http://de.wikipedia.org/w/index.php?title=Datenbank
http://de.wikipedia.org/w/index.php?title=Kundenanforderung
http://de.wikipedia.org/w/index.php?title=Overengineering
http://de.wikipedia.org/w/index.php?title=R%C3%BCdiger_Wei%C3%9Fbach
http://de.wikipedia.org/w/index.php?title=Klaus_Pohl_%28Informatiker%29
http://de.wikipedia.org/w/index.php?title=Chris_Rupp

Page 127

http://en.wikipedia.org/wiki/Lizenzbestimmungen_Commons_Attribution-ShareAlike_3.0_Unported
http://de.wikipedia.org/wiki/Wikipedia:Lizenzbestimmungen_Commons_Attribution-ShareAlike_3.0_Unported)
http://creativecommons.org/licenses/by-sa/3.0/deed.de
http://creativecommons.org/licenses/by-sa/3.0/deed.de
http://de.wikipedia.org/w/index.php?title=Free_Software_Foundation

Page 128

Lizenz 125

In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled
"Dedications". You must delete all sections Entitled "Endorsements".
6. COLLECTIONS OF DOCUMENTS
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection,
provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding
verbatim copying of that document.
7. AGGREGATION WITH INDEPENDENT WORKS
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation
is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not
themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the
Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.
8. TRANSLATION
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders,
but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any
Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of
this License or a notice or disclaimer, the original version will prevail.
If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.
9. TERMINATION
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate
your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
10. FUTURE REVISIONS OF THIS LICENSE
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new
problems or concerns. See http:/ / www. gnu. org/ copyleft/ .
Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and
conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version
ever published (not as a draft) by the Free Software Foundation.
ADDENDUM: How to use this License for your documents
To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:

Copyright (c) YEAR YOUR NAME.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled
"GNU Free Documentation License".

If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the "with...Texts." line with this:
with the Invariant Sections being LIST THEIR TITLES, with the
Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.

If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.
If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free
software.

http://www.gnu.org/copyleft/.

Similer Documents