Wiki source for AnforderungsSpezifikation
=====Anforderungserhebung und -management=====
engl. requirement engineering
==a==Grundlagen==a==
Anforderungserhebung ist der zentrale Gedanke vieler [[ProzessModelle|Vorgehensmodelle]], in der frühen Entwicklungsphase ist es der Schwerpunkt beim [[SystemsEngineering|Systems Engineering]], in der [[SoftwareTechnik|Softwaretechnik]] wegen der Komplexität inzwischen unumgänglich, die Voraussetzung für die Einführung von Qualitätsmanagementsystemen (siehe [[Norm9001 DIN EN ISO 9001]]) und die Grundlage für die Orientierung (Ist-Zustand) beim [[ProjektManagement|Projektmanagement]]. Zum diesem Thema existiert eine breite Auswahl bewährter Methoden in der Literatur (Bücher und sogar Normen), um gemeinsam mit dem Auftraggeber die Anforderungen an ein Produkt möglichst genau zu erfassen. Während dieser Arbeit verständigen sich Auftragnehmer und Auftraggeber mit [[StakeHolder Stakeholdern]] und eigenen Beratern (möglichst Experten). Sie erarbeiten dabei systematisch eine möglichst detaillierte Liste mit Anforderungen - die Anforderungsspezifikation.
Eine genaue Anforderungserhebung sind die Voraussetzung für ein erfolgreiches Projekt. Keine oder eine unzureichende Anforderungserhebung ist übrigens eines der wichtigsten Gründe, [[ScheiternVonSwProjekten|warum viele Software-Projekte scheitern]].
Definitionen:
~-Eine **Anforderung** (engl. requirement) an ein Produkt ist die eindeutige, für alle Beteiligten verständliche, präzise Formulierung __einer__ eindeutig identifizierbaren, nachprüfbaren, atomaren Eigenschaft eines Produkts.
~-Eine **Anforderungsspezifikation** ist eine vollständige, einheitlich dokumentierte und konsistente Zusammenstellung aller Anforderungen an ein Produkt. Beispiele hierfür sind das ([[Lastenheft]] und [[ProductBacklog Product backlog]]).
Vergleiche auch andere Definitionen in Sophist2007 auf S. 13, in IEEE 830 und in IEEE 1233.
Wissenswertes:
- Was sind [[StakeHolder|Stakeholder]]? (erforderlich für das weitere Verständnis)
- Was ist ein [[Anwendungsszenario]]?
- Was sind [[UseCase|Anwendungsfälle]]?
- Was sind [[StoryCards|User Stories]]?
- Was ist ein [[BusinessCase|Business Case]]?
- Was ist [[Produktpolitik]] im Marketing?
==a==Anforderungserhebung==a==
=a=Definition=a=
Die Anforderungserhebung besteht aus der Anforderungsanalyse, Anforderungsklassifikation, Anforderungspriorisierung und Anforderungsspezifikation.
Siehe auch [[AnforderungsErmittlung|Anforderungsermittlung]] aus SkriptHopf2008
=a=Anforderungen sammeln=a=
Es stehen diverse [[RequirementElicitation|Techniken zum Sammeln]] von Anforderungen zur Wahl. Welche die beste ist, ist der Kreativität des Teams überlassen. Manche Techniken klingen spielerisch, sind aber in Ihrer Durchführung und dem Ergebnis sehr effizient. Vor dem Sammeln der Anforderungen müssen die [[Stakeholder]] bekannt sein und nach Priorität sortiert vorliegen.
Die Interessen __aller__ [[Stakeholder]] an einem Produkt und alle Randbedingungen (Normen, Standards, Bestimmungen) müssen erfasst und als Anforderungen formuliert werden.
=a=Anforderungsanalyse=a=
Als Voraussetzung für eine Anforderungsanalyse müssen die [[Stakeholder]] bekannt sein und bestenfalls nach Priorität sortiert vorliegen.
Der Vorgang der Anforderlungsanalyse kann ggf. stark mit dem Sammeln von Anforderungen verzahnt sein. In der Regel ist es empfehlenswert den [[Stakeholder]] nicht mit der Analyse zu beeinflussen (siehe UnaffectedStakeholder).
Zu berücksichtigen ist
~-Wie wichtig sind die [[Stakeholder]], die diese Anforderung stellen?
~-Jeder Stakeholder wird befragt, aber die Priorität sollte berücksichtigt werden
=a=Anforderungsklassifikation=a=
[[RequirementClassification Klassifikation von Anforderungen]] (darf hier nicht öffentlich gemacht werden)
Siehe dazu das VolereTemplate13, S. 4
=a=Anforderungspriorisierung=a=
Möglicherweise, es ist sogar sehr wahrscheinlich, werden nicht alle Anforderungen als Eigenschaften des Produkts umgesetzt. Empfehlenswert ist es jedoch, dass die wichtigsten Anforderungen umgesetzt werden. Es lohnt sich die Anforderungen zu priorisieren um Vorweg die Prioritäten bei der Umsetzung festzulegen (Passender Artikel dazu: [[AnforderungenWollmilchsau|Die eierlegende Wollmilchsau]]).
Hierzu können die folgenden Fragen bereits bei der Anforderungsanalyse helfen:
~-Wie hoch ist Enttäuschung des/der betreffenden [[Stakeholder Stakeholder(s)]], wenn die Anforderung nicht umgesetzt wird?
~~-Unmöglich, Produkt dadurch unbrauchbar
~~-Große Unzufriedenheit, es sollte kein weiteren Vorfall diese Art geben
~~-Große Unzufriedenheit, unter den Umständen wird es toleriert
~~-Es wird akzeptiert
~-Wie hoch ist Zufriedenheit des/der betreffenden [[Stakeholder Stakeholder(s)]], wenn die Anforderung umgesetzt wird?
~~-Das ist egal, dann sollte es ggf. raus.
~~-Das ist ok, es war klar, dass das umgesetzt werden muss.
~~-Das ist eine beachtliche Leistung? Der Stakeholder schätzt diese Anforderung sehr.
~-(Advanced: Wie viele kritische Anforderungen können bereits nicht umgesetzt werden?)
Mögliche Verfahren zum Ermitteln von Prioritätsstufen:
~-[[AnforderungenPrioritaetenBeispiel1|Präzise definierten Klassen]]
~-[[AnforderungenPrioritaetenBeispiel2|Intuitives Einstufen]]
~-[[PriorisierungRelativitaetsMethode|Relativitätsmethode]]
~-[[AnforderungenPrioritaetenFuzzyLogic|Fuzzy-Logic-System]] zum Ermitteln der Priorität
=a=Anforderungsspezifikation=a=
~-Die Anforderungsspezifikation ist eine Liste von Anforderungen an ein Produkt
~-Die Anforderungen müssen präzise nach vorher definierten Vorgaben formuliert werden. Dazu passend: [[AnforderungenFormulieren|Formulierung von Anforderungen]]
~-Ein projektspezifisches Glossar hilft eine einheitliche Sprache zu etablieren. Es sollte gleich am Anfang erstellt werden.
~-Die Anforderungsliste muss den Entwickler in die Lage versetzen, Teile des Produkts umzusetzen, so wie es die [[StakeHolder|Stakeholder]] tatsächlich __benötigten__ (nicht so wie es [[StakeHolder|Stakeholder]] formulieren - eine wahrhaftig schwere Aufgabe).
~-Idealerweise befähigt eine Anforderungsspezifikation den Stakeholder zur selbständigen Validierung der Anforderungen
So werden Anforderungen Formuliert: [[AnforderungenFormulieren|Formulierung von Anforderungen]]
Beispiele für eine Anforderungsspezifikation (also eine Liste von Anforderungen) sind
~-ein [[Lastenheft]]
~-im Entwicklungsprozess [[Scrum]] kann das [[ProductBacklog|Product Backlog]] eine Anforderungskatalog sein; muss aber nicht!
~-[[AnforderungsKatalog|Anforderungskatalog]] im Sinne der DIN 69905 ist die "Auflistung von Anforderungen, durch deren Erfüllung ein angestrebtes Projektziel erreicht werden soll." (kann auch Bestandteil eine Lastenheftes sein)
~-Software Requirements Specification nach [[http://de.wikipedia.org/wiki/Software_Requirements_Specification IEEE 830]]
==a==Strukturierung von Anforderungen==a==
Mit zunehmender Anforderungesanzahl wird eine reine Liste mit Anforderungen sehr unübersichtlich (schon ab 100) bis tatsächlich unbrauchbar (ab 300). Eine große Hilfe kann hier eine Filterfunktion und auch eine Sortierfunktion sein. Nichts, was man nicht mit einer heute üblichen Tabellenkalkulation machen könnte. Der Anforderungstyp wurde schon oben als Merkmal einer Anforderung erwähnt. So könnte die Liste bereits nach der Anforderungsnummer sortiert und mit der Filterfunktion nur die funktionalen Anforderungen angezeigt werden. Man schafft damit eine sortierte Teilliste mir funktionalen Anforderungen. Auf diese Weise schaft man sich etwas mehr Überblick.
Bei mehreren Hundert Anforderungen reicht das nicht. Man muss bedenken: Projekte können Jahre dauern. Was heute aufgrund einiger verinnerlichter Zusatzinformationen für einen selbst übersichtlich erscheint, kann in einem Jahr bereits unüberschaubar sein, weil diese Information dann fehlt. Außerdem müssen auch andere einen Anforderungskatalog überblicken können.
Zusätzliche Merkmale und Zusammenhänge als Eigenschaften von Anforderungen können helfen die Übersicht für sich selbst und andere zu bewahren.
~-**Abhängigkeit** – Anforderungen können voneinander abhängig sein. So ist es interessant zu wissen, ob eine Anforderung erst erfüllt werden kann, wenn eine andere umgesetzt wurde.
~-**Gruppieren** – Thematisch zusammenhängende Anforderungen, können gruppiert werden. So kann beispielsweise ein bestimmte Eingabemaske oder ein teil eines Gerätes oder von Software gemeint sein.
~-**Teams** – arbeiten mehrere Teams an einem Projekt, so ist es sehr hilfreich, wenn Fragestellungen, die nur ein bestimmtes Team betreffen nur die Anforderungen die das Team betreffen angezeigt werden können.
~-**Status** – Generell kann man hier zwischen umgesetzt und nicht ungesetzt unterscheiden. Aber eine Anforderung kann auch zur Überarbeitung markiert sein, weil Fragen aufgekommen sind; oder einfach als irrelevant markiert werden. So können beispielsweise bereits umgesetzte Funktionen ausgeblendet werden.
Die Strukturierung hilft bei der Arbeit mit den Anforderungen - dem Anforderungsmanagment.
==a==Anforderungsmanagment==a==
Die Liste mit Anforderungen, egal welcher Art, muss während der Projektlaufzeit gepflegt werden, was ggf. in __sehr großen Projekten__ eines Anforderungsmanagement (siehe weiter unten) oder auch [[RequirementsEngineering|Requirements Engineering]] bedarf.
Das Anforderungsmanagment ist eine Tätigkeit, die sich über die gesamte Projektlaufzeit zieht und eigentlich vor dem Projektstart beginnt, wenn der erste Kontakt zu dem [[Stakeholder|Stakeholdern]] aufgenommen wird.
Anforderungen ändern sich während der Projektlaufzeit - das ist ein Naturgesetz. Es ist natürlich jedem selbst überlassen sich dagegen zu wären. Es hilft aber nichts. Die Liste der Anforderungen sollten deshalb stets aktualisiert werden. Das geschieht indem man in Kontakt mit den [[Stakeholder|Stakeholdern]] bleibt und dabei in regelmäßigen Abständen über Status der Umsetzung der Anforderungen berichtet, die Ergebnisse möglichst vorführt und dabei die neuen Anforderungen aufnimmt, die geänderten korrigiert, die unwichtigen herausnimmt und stets die gesamte Liste der Anforderungen neu priorisiert.
Aber! Das Einfrieren eine Anforderungsliste, während der Entwicklungsphasen ist jedoch von großer Bedeutung. Dabei werden Änderungen der Anforderungen aufgenommen, die Entwicklung läuft jedoch mit der alten Anforderungsliste weiter. Erst ab einer neuen Entwicklungsphase wird die neue Liste der Anforderungen an die Entwicklung gegeben. Wie sie Entwicklungsphasen definieren ist eine andere Philosophie. Siehe dazu als Beispiel die Sprints in [[Scrum]].
Das Anforderungsmanagment umfasst:
~-vor allem die Priorisierung bestehender Anforderungen!
~-das Kommunizieren mit den Stakeholdern
~-das Erfassen neuer Anforderungen
~-das Erfassen von Änderungen der Anforderungen
~-die Priorisierung von neuen Anforderungen
~-das Validieren von Anforderungen
~-das Kommunizieren von Änderungen an die Entwicler
Definition in [[Wikipedia:Anforderungsmanagement]]
==a==Aufwanadschätzung==a==
Die [[AufwandSchaetzung|Aufwandschätzung]] für die Umsetzung von Anforderungen sollte im IT-Bereich in Personentagen reichen. Aus den Anforderungen ergeben sich allerdings im Verlauf der Planung mehrere Aufgaben pro Anforderung, für die dann der Aufwand präziser in Stunden geschätzt werden kann. Der auf diese Weise genauer ermittelte Aufwand kann im späteren Verlauf im Rahmen des Anforderungsmanagements auch in der Anforderungsspezifikation aktualisiert werden. Zur [[AufwandSchaetzung|Aufwandschätzung]] gibt es einige Methoden, die alle demselben Zweck dienen - einer möglichst genauen Schätzung.
==a==Anforderungserhebung und -management in der Praxis==a==
Eine Zusammenstellung von Empfehlungen, Literatur, Normen, Organisationen und Beispiele zum Thema Anforderungserhebung und -management. Vor allem die ersten Zwei sind sehr empfehlenswert.
~-Anforderungserhebung nach Volere (VolereTemplate13) - eine gute Wahl und zugleich eine Vorlage in Word!
~-Anforderungserhebung und -management der [[http://www.sophist.de SOPHISTen]] (Sophist2007) - sehr gut!
~-Anforderungserhebung nach [[AnforderungsSpezifikationHubertHofmann|Hubert F. Hofmann, Franz Lehner, IEEE SOFTWARE July / August 2001]]
~-Anforderungsanalyse mit Hilfe der [[StrukturierteAnalyse|strukturierten Analyse]]
~-Anforderungsentwicklung und -management nach [[CMMI]] (Prozessgebiete RD und REQM, Kategorie Entwicklung)
~-IEEE 830 - Software Requirements Specification
~-IEEE 1233 - Guide for Developing System Requirements Specifications
~-Vorgehensbaustein Anforderungsfestlegung im V-Modell XT ([[DokuVModellXT1V3|Dokumentation zum V-Modell XT in der Version 1.3]], Seite 3-115)
~-[[Norm9001 DIN EN ISO 9001]] fordert die Verantwortung der obersten Leitung der Organisation die Bedeutung der Erfüllung der Kundenanforderungen zu vermitteln und sicherstellen, dass die Kundenanforderungen ermittelt und erfüllt werden.
~-Anforderungsspezifikation als ein Teil eines [[Lastenheft Lastenheftes]] ([[Balzert2000]], S. 62)
~-Anforderungsspezifikation in Rahmen von [[Scrum]] in Form eines [[ProductBacklog|Product Backlogs]]
~-Laut [[http://www.incose.org INCOSE]] konzentriert sich das [[SystemsEngineering|Systems Engineering]] auf die Definition und Dokumentation der Systemanforderungen in der frühen Entwicklungsphase
~-[[http://www.re-wissen.de/Wissen/ Praktiken im Requirements Engineering]] auf re-wissen.de
~-[[http://en.wikipedia.org/wiki/IREB IREB]] (International Requirements Engineering Board); [[http://certified-re.de/de/downloads/lehrplane/ Lehrplan]]; [[http://www.dpunkt.de/buecher/3142.html Buch zur Vorbereitung auf die Prüfung zum CPRE]] (Certified Professional for Requirements Engineering)
~-Probleme und Fehler bei im Requirements Engineering: Ergebnisse einer Studie ([[ZeitschriftObjektSpektrum OBJEKTspektrum]], 1/2009, S. 10)
~-[[http://www.sti-ev.de/veranstaltungen/arbeitskreise/2009/22042009.html|Erfolgreiches Anforderungsmanagement in KMUs dank bausteinorientierter Prozessverbesserung]], Michael Eisenbarth, Fraunhofer IESE
~-[[http://www.sophist.de/sophist-blog/blog/einfuehrungsstrategien-fuer-re-das-pilotierungskonzept/sophist-blog/2009/september.html Einführungsstrategien für RE: das Pilotierungskonzept]] von der Sophist-Group
~-Konferenz [[http://www.requirementsdays.de|Requirements Days]]
~-Konferenz [[http://www.reconf.de REConf]]
~-[[AnforderungenFehlerquellen|Woher kommt die Fehlerquote in der initialen Anforderungsspezifikation]]
~-[[http://www.elektroniknet.de/embedded/technik-know-how/entwicklungs-tools-fuer-hard-und-software/article/31059/0/Anforderungsmanagement_Lesbarkeit_und_Effizienz/|Anforderungsmanagement: Lesbarkeit und Effizienz]]
----
CategoryStudiumSE
Siehe auch {{backlinks}}
engl. requirement engineering
==a==Grundlagen==a==
Anforderungserhebung ist der zentrale Gedanke vieler [[ProzessModelle|Vorgehensmodelle]], in der frühen Entwicklungsphase ist es der Schwerpunkt beim [[SystemsEngineering|Systems Engineering]], in der [[SoftwareTechnik|Softwaretechnik]] wegen der Komplexität inzwischen unumgänglich, die Voraussetzung für die Einführung von Qualitätsmanagementsystemen (siehe [[Norm9001 DIN EN ISO 9001]]) und die Grundlage für die Orientierung (Ist-Zustand) beim [[ProjektManagement|Projektmanagement]]. Zum diesem Thema existiert eine breite Auswahl bewährter Methoden in der Literatur (Bücher und sogar Normen), um gemeinsam mit dem Auftraggeber die Anforderungen an ein Produkt möglichst genau zu erfassen. Während dieser Arbeit verständigen sich Auftragnehmer und Auftraggeber mit [[StakeHolder Stakeholdern]] und eigenen Beratern (möglichst Experten). Sie erarbeiten dabei systematisch eine möglichst detaillierte Liste mit Anforderungen - die Anforderungsspezifikation.
Eine genaue Anforderungserhebung sind die Voraussetzung für ein erfolgreiches Projekt. Keine oder eine unzureichende Anforderungserhebung ist übrigens eines der wichtigsten Gründe, [[ScheiternVonSwProjekten|warum viele Software-Projekte scheitern]].
Definitionen:
~-Eine **Anforderung** (engl. requirement) an ein Produkt ist die eindeutige, für alle Beteiligten verständliche, präzise Formulierung __einer__ eindeutig identifizierbaren, nachprüfbaren, atomaren Eigenschaft eines Produkts.
~-Eine **Anforderungsspezifikation** ist eine vollständige, einheitlich dokumentierte und konsistente Zusammenstellung aller Anforderungen an ein Produkt. Beispiele hierfür sind das ([[Lastenheft]] und [[ProductBacklog Product backlog]]).
Vergleiche auch andere Definitionen in Sophist2007 auf S. 13, in IEEE 830 und in IEEE 1233.
Wissenswertes:
- Was sind [[StakeHolder|Stakeholder]]? (erforderlich für das weitere Verständnis)
- Was ist ein [[Anwendungsszenario]]?
- Was sind [[UseCase|Anwendungsfälle]]?
- Was sind [[StoryCards|User Stories]]?
- Was ist ein [[BusinessCase|Business Case]]?
- Was ist [[Produktpolitik]] im Marketing?
==a==Anforderungserhebung==a==
=a=Definition=a=
Die Anforderungserhebung besteht aus der Anforderungsanalyse, Anforderungsklassifikation, Anforderungspriorisierung und Anforderungsspezifikation.
Siehe auch [[AnforderungsErmittlung|Anforderungsermittlung]] aus SkriptHopf2008
=a=Anforderungen sammeln=a=
Es stehen diverse [[RequirementElicitation|Techniken zum Sammeln]] von Anforderungen zur Wahl. Welche die beste ist, ist der Kreativität des Teams überlassen. Manche Techniken klingen spielerisch, sind aber in Ihrer Durchführung und dem Ergebnis sehr effizient. Vor dem Sammeln der Anforderungen müssen die [[Stakeholder]] bekannt sein und nach Priorität sortiert vorliegen.
Die Interessen __aller__ [[Stakeholder]] an einem Produkt und alle Randbedingungen (Normen, Standards, Bestimmungen) müssen erfasst und als Anforderungen formuliert werden.
=a=Anforderungsanalyse=a=
Als Voraussetzung für eine Anforderungsanalyse müssen die [[Stakeholder]] bekannt sein und bestenfalls nach Priorität sortiert vorliegen.
Der Vorgang der Anforderlungsanalyse kann ggf. stark mit dem Sammeln von Anforderungen verzahnt sein. In der Regel ist es empfehlenswert den [[Stakeholder]] nicht mit der Analyse zu beeinflussen (siehe UnaffectedStakeholder).
Zu berücksichtigen ist
~-Wie wichtig sind die [[Stakeholder]], die diese Anforderung stellen?
~-Jeder Stakeholder wird befragt, aber die Priorität sollte berücksichtigt werden
=a=Anforderungsklassifikation=a=
[[RequirementClassification Klassifikation von Anforderungen]] (darf hier nicht öffentlich gemacht werden)
Siehe dazu das VolereTemplate13, S. 4
=a=Anforderungspriorisierung=a=
Möglicherweise, es ist sogar sehr wahrscheinlich, werden nicht alle Anforderungen als Eigenschaften des Produkts umgesetzt. Empfehlenswert ist es jedoch, dass die wichtigsten Anforderungen umgesetzt werden. Es lohnt sich die Anforderungen zu priorisieren um Vorweg die Prioritäten bei der Umsetzung festzulegen (Passender Artikel dazu: [[AnforderungenWollmilchsau|Die eierlegende Wollmilchsau]]).
Hierzu können die folgenden Fragen bereits bei der Anforderungsanalyse helfen:
~-Wie hoch ist Enttäuschung des/der betreffenden [[Stakeholder Stakeholder(s)]], wenn die Anforderung nicht umgesetzt wird?
~~-Unmöglich, Produkt dadurch unbrauchbar
~~-Große Unzufriedenheit, es sollte kein weiteren Vorfall diese Art geben
~~-Große Unzufriedenheit, unter den Umständen wird es toleriert
~~-Es wird akzeptiert
~-Wie hoch ist Zufriedenheit des/der betreffenden [[Stakeholder Stakeholder(s)]], wenn die Anforderung umgesetzt wird?
~~-Das ist egal, dann sollte es ggf. raus.
~~-Das ist ok, es war klar, dass das umgesetzt werden muss.
~~-Das ist eine beachtliche Leistung? Der Stakeholder schätzt diese Anforderung sehr.
~-(Advanced: Wie viele kritische Anforderungen können bereits nicht umgesetzt werden?)
Mögliche Verfahren zum Ermitteln von Prioritätsstufen:
~-[[AnforderungenPrioritaetenBeispiel1|Präzise definierten Klassen]]
~-[[AnforderungenPrioritaetenBeispiel2|Intuitives Einstufen]]
~-[[PriorisierungRelativitaetsMethode|Relativitätsmethode]]
~-[[AnforderungenPrioritaetenFuzzyLogic|Fuzzy-Logic-System]] zum Ermitteln der Priorität
=a=Anforderungsspezifikation=a=
~-Die Anforderungsspezifikation ist eine Liste von Anforderungen an ein Produkt
~-Die Anforderungen müssen präzise nach vorher definierten Vorgaben formuliert werden. Dazu passend: [[AnforderungenFormulieren|Formulierung von Anforderungen]]
~-Ein projektspezifisches Glossar hilft eine einheitliche Sprache zu etablieren. Es sollte gleich am Anfang erstellt werden.
~-Die Anforderungsliste muss den Entwickler in die Lage versetzen, Teile des Produkts umzusetzen, so wie es die [[StakeHolder|Stakeholder]] tatsächlich __benötigten__ (nicht so wie es [[StakeHolder|Stakeholder]] formulieren - eine wahrhaftig schwere Aufgabe).
~-Idealerweise befähigt eine Anforderungsspezifikation den Stakeholder zur selbständigen Validierung der Anforderungen
So werden Anforderungen Formuliert: [[AnforderungenFormulieren|Formulierung von Anforderungen]]
Beispiele für eine Anforderungsspezifikation (also eine Liste von Anforderungen) sind
~-ein [[Lastenheft]]
~-im Entwicklungsprozess [[Scrum]] kann das [[ProductBacklog|Product Backlog]] eine Anforderungskatalog sein; muss aber nicht!
~-[[AnforderungsKatalog|Anforderungskatalog]] im Sinne der DIN 69905 ist die "Auflistung von Anforderungen, durch deren Erfüllung ein angestrebtes Projektziel erreicht werden soll." (kann auch Bestandteil eine Lastenheftes sein)
~-Software Requirements Specification nach [[http://de.wikipedia.org/wiki/Software_Requirements_Specification IEEE 830]]
==a==Strukturierung von Anforderungen==a==
Mit zunehmender Anforderungesanzahl wird eine reine Liste mit Anforderungen sehr unübersichtlich (schon ab 100) bis tatsächlich unbrauchbar (ab 300). Eine große Hilfe kann hier eine Filterfunktion und auch eine Sortierfunktion sein. Nichts, was man nicht mit einer heute üblichen Tabellenkalkulation machen könnte. Der Anforderungstyp wurde schon oben als Merkmal einer Anforderung erwähnt. So könnte die Liste bereits nach der Anforderungsnummer sortiert und mit der Filterfunktion nur die funktionalen Anforderungen angezeigt werden. Man schafft damit eine sortierte Teilliste mir funktionalen Anforderungen. Auf diese Weise schaft man sich etwas mehr Überblick.
Bei mehreren Hundert Anforderungen reicht das nicht. Man muss bedenken: Projekte können Jahre dauern. Was heute aufgrund einiger verinnerlichter Zusatzinformationen für einen selbst übersichtlich erscheint, kann in einem Jahr bereits unüberschaubar sein, weil diese Information dann fehlt. Außerdem müssen auch andere einen Anforderungskatalog überblicken können.
Zusätzliche Merkmale und Zusammenhänge als Eigenschaften von Anforderungen können helfen die Übersicht für sich selbst und andere zu bewahren.
~-**Abhängigkeit** – Anforderungen können voneinander abhängig sein. So ist es interessant zu wissen, ob eine Anforderung erst erfüllt werden kann, wenn eine andere umgesetzt wurde.
~-**Gruppieren** – Thematisch zusammenhängende Anforderungen, können gruppiert werden. So kann beispielsweise ein bestimmte Eingabemaske oder ein teil eines Gerätes oder von Software gemeint sein.
~-**Teams** – arbeiten mehrere Teams an einem Projekt, so ist es sehr hilfreich, wenn Fragestellungen, die nur ein bestimmtes Team betreffen nur die Anforderungen die das Team betreffen angezeigt werden können.
~-**Status** – Generell kann man hier zwischen umgesetzt und nicht ungesetzt unterscheiden. Aber eine Anforderung kann auch zur Überarbeitung markiert sein, weil Fragen aufgekommen sind; oder einfach als irrelevant markiert werden. So können beispielsweise bereits umgesetzte Funktionen ausgeblendet werden.
Die Strukturierung hilft bei der Arbeit mit den Anforderungen - dem Anforderungsmanagment.
==a==Anforderungsmanagment==a==
Die Liste mit Anforderungen, egal welcher Art, muss während der Projektlaufzeit gepflegt werden, was ggf. in __sehr großen Projekten__ eines Anforderungsmanagement (siehe weiter unten) oder auch [[RequirementsEngineering|Requirements Engineering]] bedarf.
Das Anforderungsmanagment ist eine Tätigkeit, die sich über die gesamte Projektlaufzeit zieht und eigentlich vor dem Projektstart beginnt, wenn der erste Kontakt zu dem [[Stakeholder|Stakeholdern]] aufgenommen wird.
Anforderungen ändern sich während der Projektlaufzeit - das ist ein Naturgesetz. Es ist natürlich jedem selbst überlassen sich dagegen zu wären. Es hilft aber nichts. Die Liste der Anforderungen sollten deshalb stets aktualisiert werden. Das geschieht indem man in Kontakt mit den [[Stakeholder|Stakeholdern]] bleibt und dabei in regelmäßigen Abständen über Status der Umsetzung der Anforderungen berichtet, die Ergebnisse möglichst vorführt und dabei die neuen Anforderungen aufnimmt, die geänderten korrigiert, die unwichtigen herausnimmt und stets die gesamte Liste der Anforderungen neu priorisiert.
Aber! Das Einfrieren eine Anforderungsliste, während der Entwicklungsphasen ist jedoch von großer Bedeutung. Dabei werden Änderungen der Anforderungen aufgenommen, die Entwicklung läuft jedoch mit der alten Anforderungsliste weiter. Erst ab einer neuen Entwicklungsphase wird die neue Liste der Anforderungen an die Entwicklung gegeben. Wie sie Entwicklungsphasen definieren ist eine andere Philosophie. Siehe dazu als Beispiel die Sprints in [[Scrum]].
Das Anforderungsmanagment umfasst:
~-vor allem die Priorisierung bestehender Anforderungen!
~-das Kommunizieren mit den Stakeholdern
~-das Erfassen neuer Anforderungen
~-das Erfassen von Änderungen der Anforderungen
~-die Priorisierung von neuen Anforderungen
~-das Validieren von Anforderungen
~-das Kommunizieren von Änderungen an die Entwicler
Definition in [[Wikipedia:Anforderungsmanagement]]
==a==Aufwanadschätzung==a==
Die [[AufwandSchaetzung|Aufwandschätzung]] für die Umsetzung von Anforderungen sollte im IT-Bereich in Personentagen reichen. Aus den Anforderungen ergeben sich allerdings im Verlauf der Planung mehrere Aufgaben pro Anforderung, für die dann der Aufwand präziser in Stunden geschätzt werden kann. Der auf diese Weise genauer ermittelte Aufwand kann im späteren Verlauf im Rahmen des Anforderungsmanagements auch in der Anforderungsspezifikation aktualisiert werden. Zur [[AufwandSchaetzung|Aufwandschätzung]] gibt es einige Methoden, die alle demselben Zweck dienen - einer möglichst genauen Schätzung.
==a==Anforderungserhebung und -management in der Praxis==a==
Eine Zusammenstellung von Empfehlungen, Literatur, Normen, Organisationen und Beispiele zum Thema Anforderungserhebung und -management. Vor allem die ersten Zwei sind sehr empfehlenswert.
~-Anforderungserhebung nach Volere (VolereTemplate13) - eine gute Wahl und zugleich eine Vorlage in Word!
~-Anforderungserhebung und -management der [[http://www.sophist.de SOPHISTen]] (Sophist2007) - sehr gut!
~-Anforderungserhebung nach [[AnforderungsSpezifikationHubertHofmann|Hubert F. Hofmann, Franz Lehner, IEEE SOFTWARE July / August 2001]]
~-Anforderungsanalyse mit Hilfe der [[StrukturierteAnalyse|strukturierten Analyse]]
~-Anforderungsentwicklung und -management nach [[CMMI]] (Prozessgebiete RD und REQM, Kategorie Entwicklung)
~-IEEE 830 - Software Requirements Specification
~-IEEE 1233 - Guide for Developing System Requirements Specifications
~-Vorgehensbaustein Anforderungsfestlegung im V-Modell XT ([[DokuVModellXT1V3|Dokumentation zum V-Modell XT in der Version 1.3]], Seite 3-115)
~-[[Norm9001 DIN EN ISO 9001]] fordert die Verantwortung der obersten Leitung der Organisation die Bedeutung der Erfüllung der Kundenanforderungen zu vermitteln und sicherstellen, dass die Kundenanforderungen ermittelt und erfüllt werden.
~-Anforderungsspezifikation als ein Teil eines [[Lastenheft Lastenheftes]] ([[Balzert2000]], S. 62)
~-Anforderungsspezifikation in Rahmen von [[Scrum]] in Form eines [[ProductBacklog|Product Backlogs]]
~-Laut [[http://www.incose.org INCOSE]] konzentriert sich das [[SystemsEngineering|Systems Engineering]] auf die Definition und Dokumentation der Systemanforderungen in der frühen Entwicklungsphase
~-[[http://www.re-wissen.de/Wissen/ Praktiken im Requirements Engineering]] auf re-wissen.de
~-[[http://en.wikipedia.org/wiki/IREB IREB]] (International Requirements Engineering Board); [[http://certified-re.de/de/downloads/lehrplane/ Lehrplan]]; [[http://www.dpunkt.de/buecher/3142.html Buch zur Vorbereitung auf die Prüfung zum CPRE]] (Certified Professional for Requirements Engineering)
~-Probleme und Fehler bei im Requirements Engineering: Ergebnisse einer Studie ([[ZeitschriftObjektSpektrum OBJEKTspektrum]], 1/2009, S. 10)
~-[[http://www.sti-ev.de/veranstaltungen/arbeitskreise/2009/22042009.html|Erfolgreiches Anforderungsmanagement in KMUs dank bausteinorientierter Prozessverbesserung]], Michael Eisenbarth, Fraunhofer IESE
~-[[http://www.sophist.de/sophist-blog/blog/einfuehrungsstrategien-fuer-re-das-pilotierungskonzept/sophist-blog/2009/september.html Einführungsstrategien für RE: das Pilotierungskonzept]] von der Sophist-Group
~-Konferenz [[http://www.requirementsdays.de|Requirements Days]]
~-Konferenz [[http://www.reconf.de REConf]]
~-[[AnforderungenFehlerquellen|Woher kommt die Fehlerquote in der initialen Anforderungsspezifikation]]
~-[[http://www.elektroniknet.de/embedded/technik-know-how/entwicklungs-tools-fuer-hard-und-software/article/31059/0/Anforderungsmanagement_Lesbarkeit_und_Effizienz/|Anforderungsmanagement: Lesbarkeit und Effizienz]]
----
CategoryStudiumSE
Siehe auch {{backlinks}}
