Revision history for AnforderungsSpezifikation


Revision [12123]

Last edited on 2011-07-06 13:18:23 by ToBo
Additions:
~-[[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]]


Revision [12074]

Edited on 2011-05-30 16:26:39 by ToBo
Additions:
- 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?
Deletions:
~-Was sind [[StakeHolder Stakeholder]]? (erforderlich für das weitere Verständnis)
~-Was sind [[UseCase Anwendungsfälle]]?
~-Was sind [[StoryCards User Stories]]?
~-Was ist ein [[BusinessCase Business Case]]?
~-Was ist [[Produktpolitik]] im Marketing?


Revision [11981]

Edited on 2011-05-04 19:27:47 by ToBo
Additions:
=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.
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).
Deletions:
Als Voraussetzung für eine Anforderungsanalyse müssen die [[Stakeholder]] bekannt sein und bestenfalls nach Priorität sortiert vorliegen.
~-Fragestellungen und Vorgehensmodelle der [[Usability Gebrauchstauglichkeit]] (Usability) sind hier genau richtig.
~-Standards und Normen bieten eine Vorlage für weitere Anforderungen an ein Produkt und müssen berücksichtigt werden
~-Bereits eingesetzte Technologie (z.B. der Kunde hat schon alle Systeme in C++ entwickelt bekommen und hat selbst Experten, die kleine Anpassungen machen können, stellt eine Anforderung an das System)


Revision [11926]

Edited on 2011-04-20 17:02:00 by ToBo
Additions:
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]]).
Deletions:
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.


Revision [10728]

Edited on 2010-03-31 22:50:43 by ToBo
Additions:
~-[[AnforderungenFehlerquellen Woher kommt die Fehlerquote in der initialen Anforderungsspezifikation]]
Deletions:
~-[[Woher kommt die Fehlerquote in der initialen Anforderungsspezifikation? AnforderungenFehlerquellen]]


Revision [10727]

Edited on 2010-03-31 22:50:19 by ToBo
Additions:
~-[[Woher kommt die Fehlerquote in der initialen Anforderungsspezifikation? AnforderungenFehlerquellen]]


Revision [10615]

Edited on 2010-01-09 03:18:38 by ToBo
Additions:
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.
~-[[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.
Deletions:
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 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.
~-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.


Revision [10106]

Edited on 2009-09-16 14:54:12 by ToBo
Additions:
~-[[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
Deletions:
~-[[http://www.sophist.de/sophist-blog/blog/einfuehrungsstrategien-fuer-re-das-pilotierungskonzept/sophist-blog/2009/september.html?tx_ttnews[day]=16&cHash=1a795d3763 Einführungsstrategien für RE: das Pilotierungskonzept]] von der Sophist-Group


Revision [10105]

Edited on 2009-09-16 14:51:59 by ToBo
Additions:
~-[[http://www.sophist.de/sophist-blog/blog/einfuehrungsstrategien-fuer-re-das-pilotierungskonzept/sophist-blog/2009/september.html?tx_ttnews[day]=16&cHash=1a795d3763 Einführungsstrategien für RE: das Pilotierungskonzept]] von der Sophist-Group


Revision [10102]

Edited on 2009-09-15 18:52:49 by ToBo
Additions:
~-Konferenz [[http://www.requirementsdays.de Requirements Days]]
~-Konferenz [[http://www.reconf.de REConf]]
Deletions:
~-Konferenz: [[http://www.requirementsdays.de Requirements Days]]


Revision [9999]

Edited on 2009-08-20 00:28:30 by ToBo
Additions:
~-Was sind [[StoryCards User Stories]]?
Deletions:
~~-[[SgsAnalysis SGS-Analysis]]


Revision [9991]

Edited on 2009-08-18 16:20:47 by ToBo
Additions:
engl. requirement engineering
~-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.
Deletions:
Anforderung: engl. Requirement
~-Eine **Anforderung** an ein Produkt ist die eindeutige, für alle Beteiligten verständliche, präzise Formulierung __einer__ eindeutig identifizierbaren, nachprüfbaren, atomaren Eigenschaft eines Produkts.


Revision [9990]

Edited on 2009-08-18 16:18:17 by ToBo
Additions:
~-[[http://www.sti-ev.de/veranstaltungen/arbeitskreise/2009/22042009.html Erfolgreiches Anforderungsmanagement in KMUs dank bausteinorientierter Prozessverbesserung]], Michael Eisenbarth, Fraunhofer IESE


Revision [9886]

Edited on 2009-08-12 00:51:12 by ToBo
Additions:
~-[[AnforderungenPrioritaetenBeispiel1 Präzise definierten Klassen]]
Deletions:
~-[[AnforderungenPrioritaetenBeispiel1 Methode der präzise definierten Klassen]]


Revision [9687]

Edited on 2009-08-05 00:23:51 by ToBo
Additions:
~-Probleme und Fehler bei im Requirements Engineering: Ergebnisse einer Studie ([[ZeitschriftObjektSpektrum OBJEKTspektrum]], 1/2009, S. 10)


Revision [9552]

Edited on 2009-07-27 00:14:34 by ToBo
Additions:
~-[[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)
Deletions:
~-[[http://en.wikipedia.org/wiki/IREB IREB]] (International Requirements Engineering Board); [[Lehrplan]]; [[http://www.dpunkt.de/buecher/3142.html Buch zur Vorbereitung auf die Prüfung zum CPRE]] (Certified Professional for Requirements Engineering)


Revision [9551]

Edited on 2009-07-27 00:13:56 by ToBo
Additions:
~-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://en.wikipedia.org/wiki/IREB IREB]] (International Requirements Engineering Board); [[Lehrplan]]; [[http://www.dpunkt.de/buecher/3142.html Buch zur Vorbereitung auf die Prüfung zum CPRE]] (Certified Professional for Requirements Engineering)
Deletions:
~-Laut [[http://www.incose.org INCOSE]] konzentriert [[SystemsEngineering Systems Engineering]] auf die Definition und Dokumentation der Systemanforderungen in der frühen Entwicklungsphase


Revision [8602]

Edited on 2009-05-13 02:45:47 by ToBo
Additions:
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 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.
Deletions:
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 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) und erarbeiten dabei systematisch eine möglichst detaillierte Liste mit Anforderungen (Anforderungsspezifikation).


Revision [8601]

Edited on 2009-05-13 02:43:52 by ToBo
Additions:
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 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) und erarbeiten dabei systematisch eine möglichst detaillierte Liste mit Anforderungen (Anforderungsspezifikation).
Deletions:
Anforderungserhebung ist der zentrale Gedanke vieler [[ProzessModell 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 ISO 9001) und die Grundlage für die Orientierung (Ist-Zustand) beim [[ProjektManagemnet Projektmanagemnet]]. 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) und erarbeiten dabei systematisch eine möglichst detaillierte Liste mit Anforderungen (Anforderungsspezifikation).


Revision [8600]

Edited on 2009-05-13 02:42:31 by ToBo
Additions:
Anforderungserhebung ist der zentrale Gedanke vieler [[ProzessModell 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 ISO 9001) und die Grundlage für die Orientierung (Ist-Zustand) beim [[ProjektManagemnet Projektmanagemnet]]. 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) und erarbeiten dabei systematisch eine möglichst detaillierte Liste mit Anforderungen (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 **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.
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!
~-Vorgehensbaustein Anforderungsfestlegung im V-Modell XT ([[DokuVModellXT1V3 Dokumentation zum V-Modell XT in der Version 1.3]], Seite 3-115)
~-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 [[SystemsEngineering Systems Engineering]] auf die Definition und Dokumentation der Systemanforderungen in der frühen Entwicklungsphase
Deletions:
~-Eine **Anforderungsliste** ist eine vollständige, einheitlich dokumentierte und konsistente Zusammenstellung aller Anforderungen an ein Produkt. Vergleiche mit ([[Lastenheft]] und [[ProductBacklog Product backlog]]).
Siehe dazu auch die Definitionen in Sophist2007, S. 13, IEEE 830 und IEEE 1233
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 im Anforderungskatalog aktualisiert werden. Zur [[AufwandSchaetzung Aufwandschätzung]] gibt es einige praktische Methoden (z.B. Analogieverfahren oder [[Produktmetriken]]), die alle demselben Zweck dienen - einer möglichst genauen Schätzung.
==a==Empfehlungen für Anforderungserhebung und -management==a==
Es gibt viele Arten und Empfehlungen für Anforderungserhebung und -management, wie man Anforderungen erheben und verwalten kann. Fakt ist: Meistens wird oft viel weniger Aufwand hinter der Anforderungsermittlung, -spezifikation und -pflege vermutet, als tatsächlich zur Umsetzung und zum Erfolg des Produkts benötigt wird.
Wichtig: Verwenden Sie für den Einstieg, also das erste Projekt indem sie das ausprobieren wollen, keine speziellen Tools zum Verwalten von Anforderungen. Lesen Sie dazu: [[DasToolUndDerGlaube Das "Tool" und der Glaube an die Erlösung]]
Literatur, Normen, Organisationen und Beispiele zum Thema Anforderungserhebung und -management:
~-Anforderungserhebung nach Volere (VolereTemplate13)
~-Anforderungserhebung und -management der [[http://www.sophist.de SOPHISTen]] (Sophist2007)
~-Anforderungsspezifikation in Kombination mit dem Entwicklungsprozess [[Scrum]] in Form eines [[ProductBacklog Product Backlogs]]
~-[[Lastenheft]] und Glossar (Balzert2000, S. 62)


Revision [8521]

Edited on 2009-05-03 18:29:37 by ToBo
Additions:
~-Anforderungsentwicklung und -management nach [[CMMI]] (Prozessgebiete RD und REQM, Kategorie Entwicklung)
Deletions:
~-Anforderungsmanagement nach [[CMMI]] (Prozessgebiet REQM, Maturity Level 2, Kategorie Entwicklung)


Revision [8519]

Edited on 2009-05-03 18:26:27 by ToBo
Additions:
Wichtig: Verwenden Sie für den Einstieg, also das erste Projekt indem sie das ausprobieren wollen, keine speziellen Tools zum Verwalten von Anforderungen. Lesen Sie dazu: [[DasToolUndDerGlaube Das "Tool" und der Glaube an die Erlösung]]
Deletions:
Wichtig: Verwenden Sie für den Einstieg, also das erste Projekt indem sie das ausprobieren wollen, keine speziellen Tools zum Verwalten von Anforderungen. Lesen Sie dazu: [[DasToolUndDerGlaube Das Toll und der Glaube an die Erlösung]]


Revision [8518]

Edited on 2009-05-03 18:25:17 by ToBo
Additions:
~-Anforderungserhebung nach Volere (VolereTemplate13)
~-Anforderungsanalyse mit Hilfe der [[StrukturierteAnalyse strukturierten Analyse]]
~-Anforderungsmanagement nach [[CMMI]] (Prozessgebiet REQM, Maturity Level 2, Kategorie Entwicklung)
Deletions:
~-Anforderungserhebung nach Velore (VolereTemplate13)
~-[[http://de.wikipedia.org/wiki/Strukturierte_Analyse Strukturierte Analyse]]


Revision [8423]

Edited on 2009-04-17 21:45:00 by ToBo
Additions:
~-Eine **Anforderung** 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 **Anforderungsliste** ist eine vollständige, einheitlich dokumentierte und konsistente Zusammenstellung aller Anforderungen an ein Produkt. Vergleiche mit ([[Lastenheft]] und [[ProductBacklog Product backlog]]).
Siehe dazu auch die Definitionen in Sophist2007, S. 13, IEEE 830 und IEEE 1233
Wissenswertes:
~-Was sind [[StakeHolder Stakeholder]]? (erforderlich für das weitere Verständnis)
~-Was sind [[UseCase Anwendungsfälle]]?
~-Was ist ein [[BusinessCase Business Case]]?
~-Was ist [[Produktpolitik]] im Marketing?
Deletions:
~-Eine **Anforderung** an ein Produkt ist die eindeutige, verständliche und präzise Formulierung __einer__ eindeutig identifizierbaren, nachprüfbaren, rück- und vorwärtsverfolgbaren und atomaren Eigenschaft des Produkts.
~-Eine **Liste von Anforderungen** ist vollständig, einheitlich dokumentiert und konsistent.
Siehe dazu auch die Definitionen in Sophist2007, S. 13
Was sich hinter den Eigenschaften der Anforderung und der Liste von Anforderungen verbirgt, wird unter [[http://de.wikipedia.org/wiki/Anforderungserhebung#Sammeln.2C_Analysieren Wikipedia:Anforderungserhebung:Sammeln und Analysieren]] genau erklärt.
Weitere Begriffe:
~-[[StakeHolder Stakeholder]]
~-[[UseCase Use cases]]
~-[[BusinessCase Business Case]] (optional)
~-[[Produktpolitik]]


Revision [8422]

Edited on 2009-04-17 21:31:12 by ToBo
Additions:
~-[[Produktpolitik]]


Revision [8364]

Edited on 2009-04-17 02:23:34 by ToBo
Additions:
~-**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.
Deletions:
~-**Teams** – arbeiten mehrere Teams an einem Projekt, so ist es sehr hilfreich, wenn bei Fragestellungen, sie ein bestimmtes Team betreffen nur die Anforderungen die das Team betreffen angezeigt werden können.


Revision [8361]

Edited on 2009-04-17 02:20:13 by ToBo
Additions:
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 im Anforderungskatalog aktualisiert werden. Zur [[AufwandSchaetzung Aufwandschätzung]] gibt es einige praktische Methoden (z.B. Analogieverfahren oder [[Produktmetriken]]), die alle demselben Zweck dienen - einer möglichst genauen Schätzung.
Deletions:
Die 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 im Anforderungskatalog aktualisiert werden. Zur Aufwandschätzung gibt es einige praktische Methoden (z.B. Analogieverfahren oder [[Produktmetriken]]), die alle demselben Zweck dienen - einer genaueren Schätzung.


Revision [8355]

Edited on 2009-04-17 01:06:12 by ToBo
Additions:
Die 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 im Anforderungskatalog aktualisiert werden. Zur Aufwandschätzung gibt es einige praktische Methoden (z.B. Analogieverfahren oder [[Produktmetriken]]), die alle demselben Zweck dienen - einer genaueren Schätzung.
Deletions:
Die 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 im Anforderungskatalog aktualisiert werden. Zur Aufwandschätzung gibt es einige praktische Methoden (z.B. Analogieverfahren oder [[Produktmetriken]]), die alle denselben Zweck dienen - einer genaueren Schätzung.


Revision [8354]

Edited on 2009-04-17 01:05:33 by ToBo
Additions:
Die 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 im Anforderungskatalog aktualisiert werden. Zur Aufwandschätzung gibt es einige praktische Methoden (z.B. Analogieverfahren oder [[Produktmetriken]]), die alle denselben Zweck dienen - einer genaueren Schätzung.
Deletions:
Die 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 im Anforderungskatalog aktualisiert werden. Zur Schätzung von Anforderungen gibt es viele Methoden (z.B. Analogieverfahren oder [[Produktmetriken]]).


Revision [8353]

Edited on 2009-04-17 01:04:03 by ToBo
Additions:
Die 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 im Anforderungskatalog aktualisiert werden. Zur Schätzung von Anforderungen gibt es viele Methoden (z.B. Analogieverfahren oder [[Produktmetriken]]).
Deletions:
Die Aufwandschätzung für die Umsetzung von Anforderungen sollte im IT-Bereich in Personentagen reichen. Aus den Anforderungen ergeben sich allerdings dann mehrere Aufgaben, für die dann der Aufwand präziser geschätzt werden kann. Der auf diese Weise genauer ermittelte Aufwand kann im späteren Verlauf im Rahmen des Anforderungsmanagements auch im Anforderungskatalog aktualisiert werden.


Revision [8352]

Edited on 2009-04-17 01:00:30 by ToBo
Additions:
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.
==a==Aufwanadschätzung==a==
Die Aufwandschätzung für die Umsetzung von Anforderungen sollte im IT-Bereich in Personentagen reichen. Aus den Anforderungen ergeben sich allerdings dann mehrere Aufgaben, für die dann der Aufwand präziser geschätzt werden kann. Der auf diese Weise genauer ermittelte Aufwand kann im späteren Verlauf im Rahmen des Anforderungsmanagements auch im Anforderungskatalog aktualisiert werden.
Deletions:
Mit zunehmende Anzahl von Anforderungen wird eine reine Liste mit Anforderungen sehr unübersichtlich. Eine große Hilfe kann hier eine Filterfunktion und eine Sortierfunktion sein. Nichts, was man nicht mit einer heute üblichen Tabellenkalkulation machen könnte. Der Anforderungstyp wurde schon oben erwähnt. So könnte bereits nach der Anforderungsnummer sortiert und nur die funktionalen Anforderungen angezeigt werden.
Doch bei mehreren Hundert an Anforderungen reicht selbst das nicht. Projekte können Jahre dauern. Was heute übersichtlich erscheint, kann in einem Jahr unüberschaubar sein. Außerdem müssen auch andere einen Anforderungskatalog überblicken können.
Merkmale und Zusammenhänge als Eigenschaften von Anforderungen können helfen die Übersicht für sich selbst und andere zu bewahren.


Revision [8351]

Edited on 2009-04-17 00:45:13 by ToBo
Additions:
==a==Strukturierung von Anforderungen==a==
Mit zunehmende Anzahl von Anforderungen wird eine reine Liste mit Anforderungen sehr unübersichtlich. Eine große Hilfe kann hier eine Filterfunktion und eine Sortierfunktion sein. Nichts, was man nicht mit einer heute üblichen Tabellenkalkulation machen könnte. Der Anforderungstyp wurde schon oben erwähnt. So könnte bereits nach der Anforderungsnummer sortiert und nur die funktionalen Anforderungen angezeigt werden.
Doch bei mehreren Hundert an Anforderungen reicht selbst das nicht. Projekte können Jahre dauern. Was heute übersichtlich erscheint, kann in einem Jahr unüberschaubar sein. Außerdem müssen auch andere einen Anforderungskatalog überblicken können.
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 bei Fragestellungen, sie 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.
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.
Deletions:
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.


Revision [8074]

Edited on 2009-03-15 22:09:56 by ToBo
Additions:
~-Anforderungserhebung und -management der [[http://www.sophist.de SOPHISTen]] (Sophist2007)
Deletions:
~-Anforderungserhebung und -management nach Sophist (Sophist2007)


Revision [8073]

Edited on 2009-03-15 22:07:36 by ToBo
Additions:
Literatur, Normen, Organisationen und Beispiele zum Thema Anforderungserhebung und -management:
~-Konferenz: [[http://www.requirementsdays.de Requirements Days]]
Deletions:
Literatur, Normen und Beispiele zum Thema Anforderungserhebung und -management:


Revision [8054]

Edited on 2009-03-11 23:56:54 by ToBo
Additions:
~-Software Requirements Specification nach [[http://de.wikipedia.org/wiki/Software_Requirements_Specification IEEE 830]]


Revision [8044]

Edited on 2009-03-11 23:22:54 by ToBo
Additions:
~-[[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)
Deletions:
~-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)


Revision [8041]

Edited on 2009-03-11 23:08:43 by ToBo
Additions:
~-ein [[Lastenheft]]
~-im Entwicklungsprozess [[Scrum]] kann das [[ProductBacklog Product Backlog]] eine Anforderungskatalog sein; muss aber nicht!
~-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)
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.
~-vor allem die Priorisierung bestehender Anforderungen!
~-die Priorisierung von neuen Anforderungen
~-das Kommunizieren von Änderungen an die Entwicler
~-[[Lastenheft]] und Glossar (Balzert2000, S. 62)
Deletions:
~-ein Lastenheft
~-im Entwicklungsprozess [[Scrum]] ein [[ProductBacklog Product Backlog]]
Anforderungen ändern sich während der Projektlaufzeit - das ist ein Naturgesetz. 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.
~-die Priorisierung neuen und alten Anforderungen
~-die Pflege der Anforderungsliste
~-das Kommunizieren von Änderungen
~-Lastenheft und Glossar (Balzert2000, S. 62)


Revision [8003]

Edited on 2009-03-01 22:21:26 by ToBo
Additions:
~-Die Anforderungen müssen präzise nach vorher definierten Vorgaben formuliert werden. Dazu passend: [[AnforderungenFormulieren Formulierung von Anforderungen]]
So werden Anforderungen Formuliert: [[AnforderungenFormulieren Formulierung von Anforderungen]]
Deletions:
~-Die Anforderungen müssen präzise nach vorher definierten Vorgaben formuliert werden. Dazu passend: Formulierung von Anforderungen (Sophist2007, S. 234), Qualitätskriterien von Anforderungen (Sophist2007, S. 28) und [[http://de.wikipedia.org/wiki/Anforderungserhebung#Sammeln.2C_Analysieren Wikipedia]]
So werden Anforderungen Formuliert: [[http://de.wikipedia.org/wiki/Anforderungserhebung#Sammeln.2C_Analysieren Wikipedia:Anforderungserhebung:Sammeln und Analysieren]]


Revision [7630]

Edited on 2009-01-28 23:20:45 by ToBo
Additions:
~-[[http://www.re-wissen.de/Wissen/ Praktiken im Requirements Engineering]] auf re-wissen.de


Revision [7096]

Edited on 2008-12-17 22:30:48 by ToBo
Additions:
Es gibt viele Arten und Empfehlungen für Anforderungserhebung und -management, wie man Anforderungen erheben und verwalten kann. Fakt ist: Meistens wird oft viel weniger Aufwand hinter der Anforderungsermittlung, -spezifikation und -pflege vermutet, als tatsächlich zur Umsetzung und zum Erfolg des Produkts benötigt wird.
Wichtig: Verwenden Sie für den Einstieg, also das erste Projekt indem sie das ausprobieren wollen, keine speziellen Tools zum Verwalten von Anforderungen. Lesen Sie dazu: [[DasToolUndDerGlaube Das Toll und der Glaube an die Erlösung]]
Literatur, Normen und Beispiele zum Thema Anforderungserhebung und -management:
~-IEEE 830 - Software Requirements Specification
~-IEEE 1233 - Guide for Developing System Requirements Specifications
Deletions:
Es gibt viele Arten und Empfehlungen für Anforderungserhebung und -management, wie man die Liste von Anforderungen verwalten kann. Fakt ist: Meistens wird oft viel weniger Aufwand hinter der Anforderungsermittlung, -spezifikation und -pflege vermutet, als tatsächlich zur Umsetzung und zum Erfolg des Produkts benötigt wird.
Wichtig: Verwenden Sie für den Einstieg, also das erste Projekt indem sie das ausprobieren wollen, keine speziellen Tools zum verwalten von Anforderungen. Lesen Sie dazu: [[DasToolUndDerGlaube Das Toll und der Glaube an die Erlösung]]
Einige Beispiele zum Thema Anforderungserhebung und -management sind:


Revision [6751]

Edited on 2008-11-30 22:31:53 by ToBo
Additions:
Was sich hinter den Eigenschaften der Anforderung und der Liste von Anforderungen verbirgt, wird unter [[http://de.wikipedia.org/wiki/Anforderungserhebung#Sammeln.2C_Analysieren Wikipedia:Anforderungserhebung:Sammeln und Analysieren]] genau erklärt.
~~-Das ist eine beachtliche Leistung? Der Stakeholder schätzt diese Anforderung sehr.
Anforderungen ändern sich während der Projektlaufzeit - das ist ein Naturgesetz. 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.
Wichtig: Verwenden Sie für den Einstieg, also das erste Projekt indem sie das ausprobieren wollen, keine speziellen Tools zum verwalten von Anforderungen. Lesen Sie dazu: [[DasToolUndDerGlaube Das Toll und der Glaube an die Erlösung]]
Deletions:
Was sich hinter den Eigenschaften der Andorderung und der Liste von Anforderungen verbirgt, wird unter [[http://de.wikipedia.org/wiki/Anforderungserhebung#Sammeln.2C_Analysieren Wikipedia:Anforderungserhebung:Sammeln und Analysieren]] genau erklärt.
~~-Das ist eine beachtliche Leistung? Der Stake holder schätzt diese Anforderung sehr.
Anforderungen ändern sich während der Projektlaufzeit - das ist ein Naturgesetz. Die Liste der Anforderungen sollten deshalb stets aktualisiert werden. Das geschieht idem 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.


Revision [6667]

Edited on 2008-11-30 00:09:55 by ToBo
Additions:
~-[[AnforderungenPrioritaetenFuzzyLogic Fuzzy-Logic-System]] zum Ermitteln der Priorität
Deletions:
Wie aus den Antworten auf die Fragen eine Priorität wird, kann gut intuitiv festgelegt werden oder für ganz genaue Anforderungsmanager ein Fuzzy-Logic-System zum Ermitteln der Priorität aus den Antworten herangezogen werden. :-)


Revision [6658]

Edited on 2008-11-29 23:28:48 by ToBo
Additions:
Als Voraussetzung für eine Anforderungsanalyse müssen die [[Stakeholder]] bekannt sein und bestenfalls 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.
Zu berücksichtigen ist
~-Jeder Stakeholder wird befragt, aber die Priorität sollte berücksichtigt werden
~-Fragestellungen und Vorgehensmodelle der [[Usability Gebrauchstauglichkeit]] (Usability) sind hier genau richtig.
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.
Hierzu können die folgenden Fragen bereits bei der Anforderungsanalyse helfen:
Deletions:
Die Interessen aller [[Stakeholder]] an einem Produkt und alle Randbedingungen (Normen, Standards, Bestimmungen) müssen erfasst und als Anforderungen formuliert werden.
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 festzulgen.
Hierzu können die folgenden Fragen helfen:


Revision [6409]

Edited on 2008-11-14 21:28:31 by ToBo
Additions:
Siehe dazu auch die Definitionen in Sophist2007, S. 13
~-Die Anforderungen müssen präzise nach vorher definierten Vorgaben formuliert werden. Dazu passend: Formulierung von Anforderungen (Sophist2007, S. 234), Qualitätskriterien von Anforderungen (Sophist2007, S. 28) und [[http://de.wikipedia.org/wiki/Anforderungserhebung#Sammeln.2C_Analysieren Wikipedia]]
~-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).
Deletions:
~-Die Anforderungen müssen präzise nach vorher definierten Vorgaben formuliert werden. Empfehlung: [[http://de.wikipedia.org/wiki/Anforderungserhebung#Sammeln.2C_Analysieren Wikipedia:Anforderungserhebung:Sammeln und Analysieren]]
~-Die Anforderungsliste muss den Entwickler in die Lage versetzen, Teile des Produkts umzusetzen, so wie es die Stakeholder tatsächlich __benötigten__ (nicht so wie sie es formulieren - eine wahrhaftig schwere Aufgabe).


Revision [4864]

The oldest known version of this page was created on 2008-08-26 23:34:00 by ToBo
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki