„Anforderungsanalyse (Informatik)“ – Versionsunterschied
[gesichtete Version] | [gesichtete Version] |
Keine Bearbeitungszusammenfassung |
Vorlagen-fix (Paremeterfehler (Ort)) |
||
Zeile 1: | Zeile 1: | ||
Die '''Anforderungsanalyse''' (englisch ''requirements analysis'') ist in der Informatik ein Teil des [[Systems Engineering|Systementwicklungsprozesses]] (u. a. neben dem [[Anforderungsmanagement]]) sowie ein Teil der [[Business-Analyse]]. Ziel ist es, die [[Anforderung (Informatik)|Anforderungen]] des Auftraggebers an das zu entwickelnde [[System]] zu ermitteln, zu strukturieren und zu prüfen. Das Ergebnis einer Anforderungsanalyse wird meistens in einem [[Lastenheft]] dokumentiert oder bei einer [[ |
Die '''Anforderungsanalyse''' (englisch ''requirements analysis'') ist in der Informatik ein Teil des [[Systems Engineering|Systementwicklungsprozesses]] (u. a. neben dem [[Anforderungsmanagement]]) sowie ein Teil der [[Business-Analyse]]. Ziel ist es, die [[Anforderung (Informatik)|Anforderungen]] des Auftraggebers an das zu entwickelnde [[System]] zu ermitteln, zu strukturieren und zu prüfen. Das Ergebnis einer Anforderungsanalyse wird meistens in einem [[Lastenheft]] dokumentiert oder bei einer [[Agile Softwareentwicklung|agilen Softwareentwicklung]] resultiert daraus ein [[Scrum#Product Backlog|Product Backlog]]. |
||
== Bestandteile == |
== Bestandteile == |
||
Zeile 5: | Zeile 5: | ||
=== Nach IEEE === |
=== Nach IEEE === |
||
Laut [[IEEE]]<ref>{{Literatur| |
Laut [[IEEE]]<ref>{{Literatur |Hrsg=Alain Abran, James W. Moore |Titel=SWEBOK: Guide to the Software Engineering Body of Knowledge |Verlag=IEEE Computer Society |Ort=Los Alamitos, Kalifornien, USA |Datum=2004 |ISBN=0-7695-2330-7 |Seiten=2-2}}</ref> kann das ''requirements engineering'' unterteilt werden in: |
||
* Anforderungserhebung (''requirements elicitation''), |
* Anforderungserhebung (''requirements elicitation''), |
||
* Anforderungsanalyse (''requirements analysis''), |
* Anforderungsanalyse (''requirements analysis''), |
||
* [[Software Requirements Specification| |
* [[Software Requirements Specification|Anforderungsspezifikation (''requirements specification'')]] und |
||
* Anforderungsbewertung (''requirements validation'') |
* Anforderungsbewertung (''requirements validation'') |
||
Diese Tätigkeiten überlappen einander und werden oft auch mehrfach – [[Iteration|iterativ]] – durchgeführt. |
Diese Tätigkeiten überlappen einander und werden oft auch mehrfach – [[Iteration|iterativ]] – durchgeführt. |
||
=== Nach CMMI === |
=== Nach CMMI === |
||
Das [[Software Engineering Institute]] (SEI) der [[Carnegie Mellon University|Carnegie Mellon Universität]] unterscheidet in ihrem [[Capability Maturity Model Integration]]<ref name=cmmi-rd>{{Literatur|Autor=CMMI Product Team| |
Das [[Software Engineering Institute]] (SEI) der [[Carnegie Mellon University|Carnegie Mellon Universität]] unterscheidet in ihrem [[Capability Maturity Model Integration]]<ref name="cmmi-rd">{{Literatur |Autor=CMMI Product Team |Hrsg=Software Engineering Institute, Carnegie Mellon |Titel=CMMI® for Development, Version 1.2, Improving processes for better products |Ort=Pittsburgh, Pennsylvania |Datum=2006}}</ref> |
||
* die Entwicklung der Anforderungen und |
* die Entwicklung der Anforderungen und |
||
* das Management von Anforderungen. |
* das Management von Anforderungen. |
||
=== Nach Volere === |
=== Nach Volere === |
||
In dem von den Robertsons entwickelten Vorgehensmodell [[Volere]]<ref name="volere">http://www.volere.co.uk/books.htm</ref> existieren |
In dem von den Robertsons entwickelten Vorgehensmodell [[Volere]]<ref name="volere">http://www.volere.co.uk/books.htm</ref> existieren |
||
* Anforderungsspezifikation, |
* Anforderungsspezifikation, |
||
* Stakeholder-Analyse, |
* Stakeholder-Analyse, |
||
* Bedarfsanalyse, |
* Bedarfsanalyse, |
||
* Analyse der Priorisierung und |
* Analyse der Priorisierung und |
||
* Aufzeichnung der elementaren Anforderungen. |
* Aufzeichnung der elementaren Anforderungen. |
||
=== Nach IIBA === |
=== Nach IIBA === |
||
Das [[International Institute of Business Analysis]] führt zu diesem Thema im ''Business Analysis Body of Knowledge'' drei Kapitel auf:<ref>http://www.goetz-schmidt-verlag.de/index.php?id=95</ref> |
Das [[International Institute of Business Analysis]] führt zu diesem Thema im ''Business Analysis Body of Knowledge'' drei Kapitel auf:<ref>http://www.goetz-schmidt-verlag.de/index.php?id=95</ref> |
||
* Anforderungserhebung: Anforderungen der Stakeholder ermitteln, |
* Anforderungserhebung: Anforderungen der Stakeholder ermitteln, |
||
* Anforderungs-Management & Kommunikation: Anforderungen verwalten und kommunizieren, wiederverwendbare Anforderungen identifizieren, Anforderungen zusammenstellen, Anforderungen zur Genehmigung vorbereiten, Anforderungsänderungen managen, |
* Anforderungs-Management & Kommunikation: Anforderungen verwalten und kommunizieren, wiederverwendbare Anforderungen identifizieren, Anforderungen zusammenstellen, Anforderungen zur Genehmigung vorbereiten, Anforderungsänderungen managen, |
||
* Anforderungsanalyse: Anforderungen priorisieren, strukturieren, Anforderungen in Textform dokumentieren, Anforderungen mit Grafiken/Modellen dokumentieren, auf inhaltliche Qualität prüfen, auf Übereinstimmung mit den Zielen prüfen. |
* Anforderungsanalyse: Anforderungen priorisieren, strukturieren, Anforderungen in Textform dokumentieren, Anforderungen mit Grafiken/Modellen dokumentieren, auf inhaltliche Qualität prüfen, auf Übereinstimmung mit den Zielen prüfen. |
||
Zeile 64: | Zeile 64: | ||
== Literatur == |
== Literatur == |
||
* {{Literatur | |
* {{Literatur |Autor=[[Christof Ebert]] |Titel=Systematisches Requirements Engineering und Management |Auflage=4. |Verlag=dpunkt.Verlag |Ort=Heidelberg |Datum=2012 |ISBN=978-3-89864-812-7}} |
||
* {{Literatur | |
* {{Literatur |Autor=Colin Hood, Simon Wiedemann, Stefan Fichtinger, Urte Pautz |Titel=Requirements Management: Interface Between Requirements Development and All Other Engineering Processes |Verlag=Springer |Ort=Berlin |Datum=2007 |ISBN=3-540-47689-X}} |
||
* {{Literatur | |
* {{Literatur |Autor=Helmuth Partsch |Titel=Requirements-Engineering systematisch |Auflage=2. |Verlag=Springer |Ort=Heidelberg |Datum=2010 |ISBN=978-3-642-05357-3}} |
||
* {{Literatur | |
* {{Literatur |Autor=[[Klaus Pohl (Informatiker)|Klaus Pohl]] |Titel=Requirements Engineering: Grundlagen, Prinzipien, Techniken |Verlag=dpunkt.Verlag |Ort=Heidelberg |Datum=2008 |ISBN=3-89864-550-9}} |
||
* {{Literatur | |
* {{Literatur |Autor=Suzanne Robertson, James Robertson |Titel=Mastering the Requirements Process |Auflage=2. |Verlag=Addison-Wesley Professional |Ort=Boston, Massachusetts |Datum=2006 |ISBN=0-321-41949-9}} |
||
* {{Literatur | |
* {{Literatur |Autor=[[Chris Rupp]] & die SOPHISTen |Titel=Requirements Engineering und Management. Professionelle, iterative Anforderungsanalyse für die Praxis |Verlag=Hanser |Datum=2009 |ISBN=3-446-41841-5}} |
||
* {{Literatur | |
* {{Literatur |Autor=Bruno Schienmann |Titel=Kontinuierliches Anforderungsmanagement: Prozesse – Techniken – Werkzeuge |Verlag=Addison-Wesley |Ort=München |Datum=2001 |ISBN=3-8273-1787-8}} |
||
* {{Literatur | |
* {{Literatur |Autor=Götz Schmidt |Titel=Organisation und Business Analysis - Methoden und Techniken |Auflage=15 |Ort=Gießen |Datum=2015 |ISBN=978-3-921313-93-0}} |
||
* {{Literatur | |
* {{Literatur |Autor=Karl E. Wiegers |Titel=Software Requirements |Auflage=2. |Verlag=Microsoft Press |Ort=Redmond, Washington |Datum=2003 |ISBN=0-7356-1879-8}} |
||
== Weblinks == |
== Weblinks == |
||
Zeile 78: | Zeile 78: | ||
* [http://www.gi-muc-ak-req.de/ Arbeitskreis „Requirements“ der GI/GChACM-Regionalgruppe München]. Neben einer ausführlichen Literatur- und Linkliste sind hier auch die Vortragsfolien der monatlich stattfindenden Veranstaltungen zu finden. |
* [http://www.gi-muc-ak-req.de/ Arbeitskreis „Requirements“ der GI/GChACM-Regionalgruppe München]. Neben einer ausführlichen Literatur- und Linkliste sind hier auch die Vortragsfolien der monatlich stattfindenden Veranstaltungen zu finden. |
||
* [http://www.fg-re.gi.de/ Fachgruppe „Requirements Engineering“ der Gesellschaft für Informatik] |
* [http://www.fg-re.gi.de/ Fachgruppe „Requirements Engineering“ der Gesellschaft für Informatik] |
||
* [http://www.requirements-engineering.org International Requirements Engineering Conference] |
* [http://www.requirements-engineering.org/ International Requirements Engineering Conference] |
||
* [http://www.reconf.de ReConf]: deutschsprachige Konferenz, die sich mit Requirements Engineering aus Sicht der Wissenschaft und der Industrie auseinandersetzt. |
* [http://www.reconf.de/ ReConf]: deutschsprachige Konferenz, die sich mit Requirements Engineering aus Sicht der Wissenschaft und der Industrie auseinandersetzt. |
||
* [http://www.iiba.org Internetseiten des IIBA] |
* [http://www.iiba.org/ Internetseiten des IIBA] |
||
== Einzelnachweise == |
== Einzelnachweise == |
Version vom 13. September 2017, 20:40 Uhr
Die Anforderungsanalyse (englisch requirements analysis) ist in der Informatik ein Teil des Systementwicklungsprozesses (u. a. neben dem Anforderungsmanagement) sowie ein Teil der Business-Analyse. Ziel ist es, die Anforderungen des Auftraggebers an das zu entwickelnde System zu ermitteln, zu strukturieren und zu prüfen. Das Ergebnis einer Anforderungsanalyse wird meistens in einem Lastenheft dokumentiert oder bei einer agilen Softwareentwicklung resultiert daraus ein Product Backlog.
Bestandteile
Führende Organisationen nennen für die Anforderungsanalyse folgende Bestandteile.
Nach IEEE
Laut IEEE[1] kann das requirements engineering unterteilt werden in:
- Anforderungserhebung (requirements elicitation),
- Anforderungsanalyse (requirements analysis),
- Anforderungsspezifikation (requirements specification) und
- Anforderungsbewertung (requirements validation)
Diese Tätigkeiten überlappen einander und werden oft auch mehrfach – iterativ – durchgeführt.
Nach CMMI
Das Software Engineering Institute (SEI) der Carnegie Mellon Universität unterscheidet in ihrem Capability Maturity Model Integration[2]
- die Entwicklung der Anforderungen und
- das Management von Anforderungen.
Nach Volere
In dem von den Robertsons entwickelten Vorgehensmodell Volere[3] existieren
- Anforderungsspezifikation,
- Stakeholder-Analyse,
- Bedarfsanalyse,
- Analyse der Priorisierung und
- Aufzeichnung der elementaren Anforderungen.
Nach IIBA
Das International Institute of Business Analysis führt zu diesem Thema im Business Analysis Body of Knowledge drei Kapitel auf:[4]
- Anforderungserhebung: Anforderungen der Stakeholder ermitteln,
- Anforderungs-Management & Kommunikation: Anforderungen verwalten und kommunizieren, wiederverwendbare Anforderungen identifizieren, Anforderungen zusammenstellen, Anforderungen zur Genehmigung vorbereiten, Anforderungsänderungen managen,
- Anforderungsanalyse: Anforderungen priorisieren, strukturieren, Anforderungen in Textform dokumentieren, Anforderungen mit Grafiken/Modellen dokumentieren, auf inhaltliche Qualität prüfen, auf Übereinstimmung mit den Zielen prüfen.
Vorgehen
In allen oben genannten Modellen existieren die folgenden Schritte in der einen oder anderen Form. Dabei werden Anforderungen gesammelt (englisch elicitation); durch Analyse soll ein gemeinsames Verständnis hergestellt werden; die Anforderungen werden textlich oder in Modellen dokumentiert, d. h. spezifiziert. Danach wird üblicherweise geprüft, ob das Ganze noch stimmig ist (englisch validation). Rund um diese Schritte existiert Verwaltung und Management des Prozesses.
Ermittlung, Analyse
Beim Sammeln der Anforderungen (engl. elicitation) ist der Übersetzungsprozess zwischen Fachseite und Entwickler von besonderer Bedeutung. Folgende Kriterien sind zu erfüllen:
- vollständig
- Alle Anforderungen des Kunden müssen explizit beschrieben sein, es darf keine impliziten Annahmen des Kunden über das zu entwickelnde System geben.
- eindeutig definiert / abgegrenzt
- Präzise Definitionen helfen, Missverständnisse zwischen Entwickler und Auftraggeber zu vermeiden.
- verständlich beschrieben
- Damit sowohl der Auftraggeber als auch der Entwickler mit vertretbarem Aufwand die gesamten Anforderungen lesen und verstehen kann.
- atomar
- Es darf nur eine Anforderung pro Abschnitt oder Satz beschrieben sein. Das Kriterium für ein „Atom“ sollte die Entscheidbarkeit einer Anforderung sein.
- identifizierbar
- Jede Anforderung muss eindeutig identifizierbar sein (z. B. über eine Kennung oder Nummer).
- einheitlich dokumentiert
- Die Anforderungen und ihre Quellen sollten nicht in unterschiedlichen Dokumenten stehen oder unterschiedliche Strukturen haben.
- nachprüfbar
- Die Anforderungen sollten mit Abnahmekriterien verknüpft werden, damit bei der Abnahme geprüft werden kann, ob die Anforderungen erfüllt wurden. Testfälle werden aus den Abnahmekriterien abgeleitet. Siehe auch Verifizierung.
- rück- und vorwärtsverfolgbar
- Es muss nachverfolgbar sein, ob eine Anforderung vollständig erfüllt wurde (vorwärts). Ebenso soll für jede implementierte Funktionalität kontrollierbar sein, aufgrund welcher Anforderungen sie erstellt wird (rückwärts), um Überflüssiges zu vermeiden. Siehe Rückverfolgbarkeit (Anforderungsmanagement).
- konsistent
- Die definierten Anforderungen sind untereinander widerspruchsfrei.
Das Ergebnis der Anforderungsaufnahme ist eine Liste mit Anforderungen. Diese kann z. B. in ein Lastenheft überführt werden.
Strukturierung und Abstimmung
Nach der Erfassung muss eine Strukturierung und Klassifizierung der Anforderungen vorgenommen werden. Damit erreicht man, dass die Anforderungen übersichtlicher werden. Dies wiederum erhöht das Verständnis der Beziehungen zwischen den Anforderungen. Kriterien sind hierbei:
- abhängig
- Anforderungen müssen daraufhin überprüft werden, ob eine Anforderung die Voraussetzung für eine andere ist, sich gegenseitig bedingen oder sich unabhängig voneinander realisieren lassen.
- zusammengehörig
- Anforderungen, die fachlich-logisch zusammengehören, sollen nicht allein realisiert werden.
- rollenbezogen
- Jede Benutzergruppe hat ihre eigene Sicht auf die Anforderungen, die damit unterstützt werden soll, siehe Benutzerrolle.
Weitere Strukturierungsmöglichkeiten sind funktionale und nichtfunktionale Anforderungen sowie fachlich motivierte (fachliche und technische) und technisch motivierte (nur technische) Anforderungen. Die so strukturierten Anforderungen müssen dann zwischen Kunde und Entwickler abgestimmt werden. Diese Abstimmung kann gegebenenfalls zu einem iterativen Prozess werden, der zur Verfeinerung der Anforderungen führt.
Prüfung und Bewertung
Nach der Strukturierung, zum Teil auch parallel dazu, erfolgt die Qualitätssicherung der Anforderungen nach Qualitätsmerkmalen:
- korrekt
- Die Anforderungen müssen untereinander widerspruchsfrei sein. Siehe Korrektheit (Informatik).
- machbar
- Die Anforderung muss realisierbar sein. Siehe Machbarkeit.
- notwendig
- Was nicht vom Auftraggeber gefordert wird, ist keine Anforderung.
- priorisiert
- Es muss erkennbar sein, welche Anforderungen die wichtigsten sind. Ziel der Priorisierung ist es, häufig benötigte oder dem Kunden besonders wichtige Funktionen vor den weniger häufig benötigten bereitzustellen. Man erreicht es über eine Quantifizierung der Funktionszweige.
- nutzbar, nützlich
- Auch bei teilweiser Realisierung soll bereits ein produktives System entstehen.
Das Ergebnis der Prüfung stellt die Basis für das Pflichtenheft dar. Die Bewertungen stehen teilweise in Konkurrenz zueinander. Eine Realisierung von nur als hoch priorisierter Aufgaben erbringt nicht automatisch ein produktives System. Bei der Bewertung ist nicht nur die Einzelfunktion für sich, sondern auch ihr Wirken im Gesamtsystem zu betrachten.
Literatur
- Christof Ebert: Systematisches Requirements Engineering und Management. 4. Auflage. dpunkt.Verlag, Heidelberg 2012, ISBN 978-3-89864-812-7.
- Colin Hood, Simon Wiedemann, Stefan Fichtinger, Urte Pautz: Requirements Management: Interface Between Requirements Development and All Other Engineering Processes. Springer, Berlin 2007, ISBN 3-540-47689-X.
- Helmuth Partsch: Requirements-Engineering systematisch. 2. Auflage. Springer, Heidelberg 2010, ISBN 978-3-642-05357-3.
- Klaus Pohl: Requirements Engineering: Grundlagen, Prinzipien, Techniken. dpunkt.Verlag, Heidelberg 2008, ISBN 3-89864-550-9.
- Suzanne Robertson, James Robertson: Mastering the Requirements Process. 2. Auflage. Addison-Wesley Professional, Boston, Massachusetts 2006, ISBN 0-321-41949-9.
- Chris Rupp & die SOPHISTen: Requirements Engineering und Management. Professionelle, iterative Anforderungsanalyse für die Praxis. Hanser, 2009, ISBN 3-446-41841-5.
- Bruno Schienmann: Kontinuierliches Anforderungsmanagement: Prozesse – Techniken – Werkzeuge. Addison-Wesley, München 2001, ISBN 3-8273-1787-8.
- Götz Schmidt: Organisation und Business Analysis - Methoden und Techniken. 15. Auflage. Gießen 2015, ISBN 978-3-921313-93-0.
- Karl E. Wiegers: Software Requirements. 2. Auflage. Microsoft Press, Redmond, Washington 2003, ISBN 0-7356-1879-8.
Weblinks
- Fachgruppe „Requirements Engineering“ beim ASQF (Arbeitskreis Software-Qualität und -Fortbildung e.V.)
- Arbeitskreis „Requirements“ der GI/GChACM-Regionalgruppe München. Neben einer ausführlichen Literatur- und Linkliste sind hier auch die Vortragsfolien der monatlich stattfindenden Veranstaltungen zu finden.
- Fachgruppe „Requirements Engineering“ der Gesellschaft für Informatik
- International Requirements Engineering Conference
- ReConf: deutschsprachige Konferenz, die sich mit Requirements Engineering aus Sicht der Wissenschaft und der Industrie auseinandersetzt.
- Internetseiten des IIBA
Einzelnachweise
- ↑ Alain Abran, James W. Moore (Hrsg.): SWEBOK: Guide to the Software Engineering Body of Knowledge. IEEE Computer Society, Los Alamitos, Kalifornien, USA 2004, ISBN 0-7695-2330-7, S. 2-2.
- ↑ CMMI Product Team: CMMI® for Development, Version 1.2, Improving processes for better products. Hrsg.: Software Engineering Institute, Carnegie Mellon. Pittsburgh, Pennsylvania 2006.
- ↑ http://www.volere.co.uk/books.htm
- ↑ http://www.goetz-schmidt-verlag.de/index.php?id=95