III NA  

Inhalt

Inhalt

1  Systematisches Anforderungsmanagement ein Ansatz mit enormem Potential  1

1.1  Motivation  1

1.2  Situationsanalyse  1

1.3  Zielsetzung und Konzeption dieser Arbeit  4

2  Definition von Anforderung und Anforderungsmanagement  5

2.1  Der Anforderungsbegriff  5

2.2  Anforderungsmanagement  10

3  Ziele des Anforderungsmanagements  12

4  Klassifizierung von Anforderungen  15

4.1  Klassische Sichtweise  15

4.1.1  Funktionale Anforderungen  16

4.1.2  Nichtfunktionale Anforderungen  17

  (Besondere) Qualitätsanforderungen  18

4.1.2.1  NA  

4.1.2.1.1  Interoperabilität  19

4.1.2.1.2  Sicherheit  20

4.1.2.1.3  Bedienbarkeit  21

4.1.2.1.4  Zuverlässigkeit  21

4.1.2.1.5  Verfügbarkeit  21

4.1.2.1.6  Änderbarkeit  22

4.1.2.2  Leistungsanforderungen  22

4.1.2.3  Restriktionen Rahmenbedingungen  23

4.2  Ansatz nach Pohl  23

4.3  Anforderungen nach Kano  25

5  Anforderungsqualität  28

5.1  Qualitätskriterien für einzelne Anforderungen  28

5.2  Qualitätskriterien für Anforderungsdokumente  31

6  Haupttätigkeiten im Anforderungsmanagement  35

6.1  Steuerungstätigkeiten  35

6.1.1  Umsetzungs(-prozess-)management  35

6.1.2  Änderungsmanagement  36

6.1.3  Risikomanagement  36

6.2  Operative Tätigkeiten  36

  IV NA  

6.2.1  Anforderungen erheben analysieren und konsolidieren  37

6.2.1.1  Anforderungen erheben  37

6.2.1.2  Sprachliche Analyse von Anforderungen  38

6.2.1.2.1  Tilgung  39

6.2.1.2.2  Generalisierung  40

6.2.1.2.3  Verzerrung  40

6.2.1.3  Entwicklung innovativer Ideen  41

6.2.1.4  Auswirkungsanalyse  42

6.2.1.5  Anforderungen konsolidieren  43

6.2.1.6  Anforderungen dokumentieren  43

6.2.1.6.1  Natürlichsprachliche Dokumentation  45

6.2.1.6.2  Modellbasierte Dokumentation  46

6.2.1.7  Anforderungen qualitätssichern  50

6.2.1.7.1  Qualitätssicherung von Anforderungsdokumenten  51

6.2.1.7.2  Abnahmekriterien  59

6.2.1.8  Anforderungen verwalten  60

6.2.1.8.1  Nachverfolgbarkeit  60

6.2.1.8.2  Wiederverwendung  61

7  Anforderungen im Kontext von Vorgehensmodellen  63

7.1  Monumentale vs agile Prozess-Modelle  63

7.1.1  Monumentale Prozessmodelle  63

7.1.2  Agile Prozessmodelle  64

7.2  Vor- und Nachteile schwer- bzw leichtgewichtiger Prozessmodelle  65

8  Erfolgsfaktoren im Anforderungsmanagement  67

8.1  Kundenbindungsintensität  68

8.2  Qualität der Kommunikation im Team  70

9  Anforderungsmanagement im Kontext methodischer Qualitätssicherung  72

9.1  Capability Maturity Model Integration als Qualitätsmanagementmodell  72

9.2  Kombination der Qualitätsmethode Quality Function Deployment mit dem  

  Anforderungsmanagement  76

9.3  Metriken im Anforderungsmanagement  81

10  Fazit  85

  Abkürzungsverzeichnis  87

Tabellenverzeichnis........................................................................................................ 90

  Glossar  91

  Literatur  93

1 Systematisches Anforderungsmanagement – ein Ansatz mit enormem Potential

1.1 Motivation Die Fähigkeit, schnell und effektiv auf wechselnde Anforderungen und neue Chancen in einem Marktumfeld wachsender Komplexität und zunehmender Dynamik zu reagieren, wird immer mehr zur zentralen Herausforderung moderner Unternehmen. Der intelligente Umgang mit den Ressourcen ist längst eine ökonomische Notwendigkeit. Zugleich ist die konsequente Umsetzung der Kundenanforderungen erfolgsentscheidend.

In diesem Spannungsfeld stellt systematisches Anforderungsmanagement einen Ansatz dar, der enormes Potential aufweist, nämlich die Differenzierung im Wettbewerb durch Vorteile in den Dimensionen Zeit, Qualität und Kosten.

1.2 Situationsanalyse Besonders Großunternehmen sehen sich Herausforderungen gegenüber wie:

stärkere Kundenorientierung,

steigende Bedeutung softwareintensiver Systeme, steigende Komplexität, ständig steigende Anzahl von Stakeholdern, stetige Zunahme des Zeit- und Kostendrucks, zunehmender Verknüpfungsgrad von Software und Systemen, zunehmende Vernetzung der IT-Systeme mit denen von Partnern oder Kunden, gesetzliche Vorgaben, Erfordernis einer immer flexibleren Unterstützung der Geschäftsprozesse, Umstrukturierungen der IT-Organisation.

Ein zentrales Problemfeld stellen in vielen Unternehmen historisch gewachsene, starre Anwendungssilos dar. Diese wurden in der Vergangenheit für den Einsatz in einer stabilen, gleichbleibenden Umgebung erstellt. Unflexible Geschäftsprozesse richteten sich nicht selten nach der IT. Aus diesen Wurzeln hat sich eine vollkommen konträre Philosophie entwickelt. Heute wird eine anpassungsfähige Ausrichtung der IT an die geschäftsrelevanten Aufgaben angestrebt, um nicht zu sagen verlangt. Die fachliche Organisation der Anwendungslandschaft steht dabei im Vordergrund, wobei die Anwendungsarchitektur der Geschäftsarchitektur folgt und nicht umgekehrt. In diesem Zusammenhang hat das Thema Service Orientierte Architekturen (SOA) nicht an Aktualität verloren, weil viele Unternehmen inzwischen feststellen mussten, dass sie aufgrund ihrer starren IT-Infrastruktur so stark in ihrer Flexibilität eingeschränkt sind, dass sie dadurch an Wettbewerbsfähigkeit einbüßen. Änderungen, die sich beispielsweise durch ökonomische Einflüsse, dynamische Umfeldentwicklungen und/oder fachliche Anforderungen ergeben, müssen innerhalb kurzer Zeit umgesetzt werden können. Die Etablierung einer SOA ist jedoch mehr als nur die Entwicklung einzelner Services. SOA-Umgebungen benötigen die Unterstützung des gesamten Software Development Lifecycle (SDLC).

Eine Schlüsselrolle nimmt hier das Anforderungsmanagement in der Analysephase ein. Insbesondere bei einem hohen Verknüpfungsgrad sind die Auswirkungen von Änderungen sorgfältig zu analysieren. Werden Abhängigkeiten identifiziert, so geht mit dem Änderungsaufwand ein Koordinationsaufwand einher.

Nicht nur die gestiegene Komplexität spricht für einen veränderten Umgang mit Anforderungen, sondern auch die neuen Rahmenbedingungen, wie z.B. ggf. die Kommunikation über eine größere Distanz. Ein weiteres großes Problemfeld in diesem Zusammenhang stellt die Modifikation der Organisationsstrukturen in der IT dar. Diese geht häufig mit einem Verlust an Kommunikation zwischen Fachbereich und IT einher, weil sich deren Geschäftsbeziehungen verändern. Durch eine zunehmende Formalisierung wird die Kommunikation erschwert. Dies wiederum kann die Komplexität erhöhen. Zudem sollen die Steuerbarkeit der IT-Dienstleistungen verbessert und deren Leistungsfähigkeit gesteigert werden. „Unternehmensintern erbrachte IT-Serviceleistungen stehen auf dem Prüfstand. Sie werden zunehmend unter Kostenaspekten betrachtet und auf Transparenz getrimmt.“ [Reic06, S. 1]

Die Konzentration auf das Kerngeschäft ist eine Möglichkeit, durch Spezialisierung die eigene Wettbewerbsfähigkeit zu steigern. Outsourcing und Offshoring sind Themen, die in diesem Zusammenhang kontrovers diskutiert werden. Es ist die zunehmende Tendenz zu beobachten, dass Software nach wie vor im eigenen Unternehmen geplant, beauftragt und überwacht wird, aber keine Entwicklung mehr erfolgt.

Umso mehr ist es von Bedeutung, dass die Anforderungen klar spezifiziert sind.

Desweiteren verläuft diversen Studien zufolge ein großer Teil der Softwareentwicklungs-projekte nicht erfolgreich. Eine Aufstellung über die zu dieser Thematik durchgeführten Studien findet sich in der Arbeit von Buschermöhle et al. (vgl.[Bus+06, S. 15]). Dort werden zudem die jeweils verwendete Forschungsmethode, das Untersuchungssubjekt bzw. -objekt und die ermittelte Erfolgsquote (falls ermittelt) übersichtsartig dargestellt.

Der aktuelle CHAOS Report der Standish Group kommt zu dem Ergebnis, dass weltweit nur 35 Prozent der Softwareprojekte, die in 2006 begonnen wurden, erfolgreich verliefen (vgl. [Rubi07]). Eine ähnliche Studie führte der F&E Bereich Sicherheitskritische Systeme des Oldenburger Forschungs- und Entwicklungsinstitut für Informatik-Werkzeuge und – Systeme (OFFIS) mit seiner Umfrage SUCCESS (SUCCESS AND FAILURE OF HARD- AND SOFTWARE PROJECTS) im Rahmen des vom Bundesministerium für Bildung und Forschung geförderten Projektes VSEK (Virtuelles Software-Engineering-Kompetenznetz) in 2005/2006 durch. Ziel war die Identifikation aktueller Erfolgs- und Misserfolgsfaktoren bei der Durchführung von Hard- und Softwareprojekten in Deutschland. Auf Basis der erhobenen Daten von 378 untersuchten Projekten wurde eine Erfolgsrate in Höhe von 50,7 Prozent ermittelt (vgl. [Bus+06, S.289]).

Die Studienergebnisse sind zwar, nicht zuletzt aufgrund des unterschiedlichen Studiendesigns, nur beschränkt miteinander vergleichbar, dennoch lassen sie das Optimierungspotential von Softwareentwicklungsprojekten, die nach heutigen Standards abgewickelt werden, erkennen.

Die beschriebene Situation lässt erahnen, dass die zum Teil rasanten Veränderungen im IT-Umfeld einen veränderten Umgang mit Anforderungen erfordern. Die genannten

Herausforderungen haben zur Konsequenz, dass kontinuierliches und systematisches Anforderungsmanagement für eine erfolgreiche Produktentwicklung immer mehr an Bedeutung gewinnt.

1.3 Zielsetzung und Konzeption dieser Arbeit

Im Rahmen dieser Arbeit soll beleuchtet werden, welchen Beitrag das Anforderungsmanagement für die Differenzierung eines Unternehmens im Wettbewerb leisten kann.

Die Relevanz des Themas wurde in der Situationsanalyse bereits vorgestellt.

Nach den Erläuterungen zur Zielsetzung und Konzeption dieser Arbeit findet eine Klärung der für diese Arbeit zentralen Begriffe Anforderung und Anforderungsmanagement statt. Darauf aufbauend werden die Ziele des Anforderungsmanagements formuliert. Das 4. Kapitel beschäftigt sich mit der systematischen Klassifizierung von Anforderungen. Nach der Betrachtung der Qualitätskriterien für Anforderungen und Anforderungsdokumente im 5. Kapitel befasst sich das Kapitel 6 mit den Haupttätigkeiten im Anforderungsmanagement.

Im Kapitel 7 werden Anforderungen im Kontext von Vorgehensmodellen beleuchtet. Um ein Gefühl für die Erfolgsfaktoren im Anforderungsmanagement zu entwickeln, wird auf die kritischen im Kapitel 8 eingegangen.

Anschließend wird das Thema Anforderungsmanagement im Kontext methodischer Qualitätssicherung betrachtet.

Die Arbeit schließt mit einem Fazit.

2 Definition von Anforderung und Anforderungsmanagement

Der Begriff des „Anforderungsmanagements“ bezeichnet ein Forschungsgebiet, das in den letzten Jahren in neueren Publikationen eine zunehmende Bedeutung erfahren hat.

Trotz der mittlerweile großen Anzahl an Veröffentlichungen ist eine einheitliche terminologische Basis nicht sichtbar geworden.

2.1 Der Anforderungsbegriff

Literaturrecherchen fördern zutage, dass es keine allgemein anerkannte Definition davon gibt, was man unter dem Anforderungsbegriff versteht.

Im Standard IEEE 610.12-1990 ist der Begriff Anforderung (engl. requirement) wie folgt definiert:

(Vgl. [IEEE 610.12-1990], Übersetzung des Autors)

Sommerville und Sawyer definieren den Anforderungsbegriff wie folgt:

(Vgl. [SoSa97, S. 4], Übersetzung des Autors)

Von Grady Booch stammt folgende Definition im Rahmen des Rational Unified Process (RUP):

[KrBo99, S. 142]

Definition nach Balzert:

[Balz96, S. 111]

Anforderungen (Lastenheft) gem. V-Modell® XT

[KBSt07, S.71]

In der DIN EN ISO 9000 ist der Anforderungsbegriff abstrakt definiert als:

[DIN06]

Von Rupp, Chris / SOPHIST GROUP stammt folgende Definition:

[Rupp07, S. 13]

Die Synopse zeigt, dass der Begriff der Anforderung unterschiedlich weit gefasst wird und unterschiedliche Aspekte in den Vordergrund gestellt werden.

In der Definition des Instituts der Elektrik- und Elektronik-Ingenieure (vgl. [IEEE 610.12-1990]) fällt auf, dass auf die Wünsche und Ziele der Benutzer an erster Stelle eingegangen wird, bevor die Bedingungen und Fähigkeiten des Systems im zweiten Absatz behandelt werden. Die gewählte Reihenfolge lässt sich dahingehend interpretieren, dass der Erarbeitung kundenorientierter Lösungen ein hoher Stellenwert beigemessen wird. Ferner fällt auf, dass die Definition zwischen nicht dokumentierten und dokumentierten Anforderungen differenziert.

Die systematische Transformation von undokumentierten Anforderungen der Stakeholder in Anforderungsspezifikationen stellt eine Hauptaktivität im Anforderungsmanagementprozess dar.

Balzert (vgl.[Balz96]) stellt in seiner Definition auf die qualitativen und die quantitativen Eigenschaften eines Produktes aus Sicht der Rolle des Auftraggebers ab. Seine Definition zielt auf die Überprüfbarkeit der Anforderungen hinsichtlich der Erfüllung im Hinblick auf die spätere Produkt-Abnahme.

In der Grundlagenbeschreibung des V-Modell XT wird der Anforderungsbegriff doppelt belegt. Anforderungen werden hier zum einen als V-Modell XT-Produkt in Form des Lastenheftes und zum anderen als Rahmenbedingungen für die Entwicklung definiert. Die in Rede stehende Definition fokussiert rechtliche Aspekte (Lastenheft als Grundlage für Ausschreibung und Vertragsgestaltung). Daneben werden zwei Detailierungsgrade der Ausgestaltung von Anforderungen unterschieden, nämlich das Lasten- und das Pflichtenheft. Darüber hinaus werden die Rollen Auftraggeber und Auftragnehmer unterschieden.

In der Norm DIN EN ISO 9000 (vgl. [NORM DIN06]) ist der Anforderungsbegriff sehr allgemein definiert. Sie fasst den Anforderungsbegriff am weitesten. Anforderungen müssen nach dieser Definition nicht notwendigerweise explizit formuliert sein.

Die Definitionen von Grady Booch (vgl. [KrBo99]) sowie von Sommerville und Sawyer (vgl. [SoSa97]) stellen das zu implementierende System in den Vordergrund. Sommerville und Sawyer nehmen explizit eine Einschränkung auf die frühen Phasen einer Systementwicklung vor. Die Definition von Grady Booch wurde im Kontext des RUP formuliert. Der RUP ist ein schwergewichtigerer Softwareentwicklungsprozess. Im RUP wird ebenfalls versucht, den Großteil der Anforderungen möglichst früh festzuschreiben. Sommerville und Sawyer weiten den Begriff Anforderung explizit auf den Entwicklungsprozess aus.

Die Definition von Rupp, Chris / SOPHIST GROUP (vgl. [Rupp07]) bezieht den Entwicklungsprozess ebenfalls ein und darüber hinaus die nachgelagerten Prozesse wie Wartung und Support. Rupp, Chris / SOPHIST GROUP betont, dass ein Produkt und nicht nur ein System als Endergebnis einer Entwicklung erbracht werden muss. „Der Begriff ‚Produkt‘ in der Definition meint jedoch mehr als nur ‚System‘, umfasst Software und Hardware und zum Beispiel auch Abnahmekriterien, Handbücher, Protokolle, Planungsdokumente und so weiter.“ [Rupp07, S. 13]

Diese umfassende Sichtweise wird auch in dieser Arbeit vertreten.

Es sei darauf hingewiesen, dass sich Anforderungen verändern können. Versteegen et al. definieren den Änderungsbegriff als „modifizierten Anforderungswunsch“ (vgl. [Ver+03, S. 5]).

(Neue) Anforderungen entstehen während des gesamten Lebenszyklus eines Systems. Schienmann gibt eine durchschnittliche Änderungsrate von 2 Prozent der Anforderungen pro Monat an (vgl. [Schi01, S. 46]).

Als Ursachen für die Änderung von Anforderungen können beispielsweise angeführt werden:

(vgl. [Pohl07, S. 547 – 549]).

Die Terminologie für die dokumentierte Form von Anforderungen ist ebenfalls nicht einheitlich. Beispielsweise wird hierfür im Standard IEEE 610.12-1990 (vgl. [IEEE 610.12-1990]) und von Rupp, Chris / SOPHIST GROUP (vgl. [Rupp07]) der Begriff der Anforderungsspezifikation verwendet. Balzert (vgl. [Balz96]) hingegen verwendet in seiner Arbeit den Begriff Produkt-Definition, um „[…] Verwechslungen mit dem Begriff <> im Entwurf zu vermeiden […]“ [Balz96, S. 92]. Pohl (vgl. [Pohl07]) benutzt für die dokumentierte Form den Begriff Anforderungsartefakt. Er unterscheidet präzise zwischen dokumentierten und spezifizierten Anforderungen. „Eine dokumentierte Anforderung ist nur dann eine spezifizierte Anforderung, wenn sie die vorgegebenen Spezifikationsvorschriften für Anforderungen erfüllt.“ [Pohl07, S, 220]

2.2 Anforderungsmanagement

Wie eben festgestellt wurde, sind Anforderungen grundsätzlich nicht stabil und ändern sich.

Versteegen schreibt, dass Änderungen auf Zuruf zwar für den Kunden recht nett sein mögen und auch eine scheinbare Flexibilität vortäuschen, jedoch aber in höchstem Maße unprofessionell seien (vgl. [Ver+03, S. 5]).

Seine Aussage gilt vor allem, wenn die Anzahl der Stakeholder groß und das Unternehmen sehr arbeitsteilig organisiert ist.

„Das Anforderungsmanagement dient dazu, diese unvermeidlichen Änderungen von Anforderungen im Vorfeld zu erkennen, zu planen und zu steuern, sowie ihre Auswirkungen lokal zu halten.“ [Schi01, S. 21]

Grady Booch definiert Anforderungsmanagement im Rahmen des Rational Unified Process (RUP) wie folgt:

[KrBo99, S. 142]

Von Leffingwell und Widrig stammt die Definition:

(Vgl. [LeWi99, S. 16], Übersetzung des Autors)

Definition nach Kruchten:

(Vgl. [Kruc03, S. 25], Übersetzung des Autors)

Die angeführten Definitionen sind sehr ähnlich was das Ermitteln, Verwalten und

Dokumentieren von Anforderungen betrifft. Die Definition von Grady Booch beinhaltet

explizit das Einschätzen von Änderungen und das Einschätzen ihrer Auswirkungen. In

der Praxis ist dieser Aspekt des Anforderungsmanagements von zentraler Bedeutung.

Aufgrund des zunehmenden Verknüpfungsgrades von Systemen oder

Systemkomponenten können scheinbar harmlose Änderungen beträchtliche

Auswirkungen haben, wenn diese unzureichend bedacht werden.

Schnittstellen des Anforderungsmanagements sind das Projekt- und das

Qualitätsmanagement.

3 Ziele des Anforderungsmanagements

Zu den Zielen des Anforderungsmanagements zählen:

Betriebliche Informationssysteme werden zur Lenkung der betrieblichen Leistungserstellung oder zur Erstellung von Dienstleistungen eingesetzt. Als maschinelle Aufgabenträger müssen sie bestimmte Informationsverarbeitungs- Aufgaben erfüllen.

„Wesentliche Aufgabe und Zielsetzung des Anforderungsmanagements ist es, die aus diesen Aufgabenstellungen resultierenden Anforderungen an das System zu

spezifizieren und an Veränderungen des Anwendungsbereichs anzupassen.“ [Schi01, S. 18]

Dazu muss in erster Linie die Aufgaben-/Problemstellung genau bekannt sein, damit eine geeignete Lösung entwickelt werden kann. Entscheidend ist, in welchem Maße die Kundenanforderungen erfüllt werden (nähere Ausführungen hierzu finden sich im Kapitel 4.3 - Anforderungen nach Kano). Die Auswirkungen der Lösungsmöglichkeiten müssen genauestens analysiert werden, um die richtigen Entscheidungen treffen zu können. Ungewollte Seiteneffekte sind zu verhindern, Inkonsistenzen aufzulösen, Aufwandstreiber nach Möglichkeit zu eliminieren.

Zwischen allen Beteiligten (im Wesentlichen Auftraggeber und Auftragnehmer) muss ein einheitliches Verständnis über das zu entwickelnde System herbeigeführt werden. Mögliche Interessenskonflikte gilt es frühzeitig zu erkennen und aufzulösen. Getroffene Vereinbarungen müssen dokumentiert und sollten danach grundsätzlich nicht mehr in Frage gestellt werden.

Nachdem die Anforderungen an das System idealerweise nach vorgegebenen Qualitätskriterien (siehe Kapitel 5 - Anforderungsqualität) spezifiziert sind, muss deren Umsetzung zielgerichtet gesteuert und nachgehalten werden. Die Anforderungen müssen dazu koordiniert an die zuständigen Verantwortlichkeiten adressiert werden. Das erfordert verbindliche, klar definierte (messbare) an der Unternehmensstrategie ausgerichtete Prozesse an Stelle informeller Strukturen auf Basis persönlicher Beziehungen.

Das ökonomische Ziel der Wirtschaftlichkeit kann nur durch planvolles Vorgehen im Umsetzungsprozess erreicht werden. Hierzu bedarf es einer konsequenten und klaren Prioritätensetzung unter Einbeziehung der relevanten Stakeholder.

Entscheidungskriterien zur Priorisierung von Anforderungen sind:

Tab. 1: Entscheidungskriterien zur Priorisierung von Anforderungen (vgl. [Pohl07], S. 528f.)

Nicht unerwähnt soll der Aspekt der Mitarbeiterzufriedenheit bleiben. Diese wird dadurch erreicht, dass passgenaue Lösungen entwickelt werden, die eine hohe Akzeptanz des neuen Systems erwarten lassen und so zum Erfolg für alle Beteiligten werden.

4 Klassifizierung von Anforderungen

4.1 Klassische Sichtweise

Durch das Anforderungsmanagement soll die Frage beantwortet werden, was genau in welcher Qualität entwickelt werden soll.

Anforderungen können nach den geforderten Eigenschaften klassifiziert werden. Die als klassische Sichtweise bezeichnete Differenzierung bezieht sich die Unterscheidung von funktionalen und nicht-funktionalen Anforderungen.

Abbildung 1: Traditionelle Klassifizierung von Anforderungen

4.1.1 Funktionale Anforderungen

„Eine Funktion beschreibt eine Tätigkeit oder eine klar umrissene Aufgabe innerhalb eines größeren Zusammenhangs.“ [Balz96, S. 116]

Funktionale Anforderungen entstehen aus einer fachlichen Motivation und spezifizieren die Funktionen und das Verhalten des geplanten Systems. Klassisch werden die drei Perspektiven Funktionssicht, Datensicht und Prozesssicht unterschieden. Sie beschreiben, was in einem Softwaresystem gemacht wird.

Funktionssicht:

Die Funktionssicht beschreibt die Transformation der Daten von der Eingabe über die maschinelle Informationsverarbeitung bis zur Datenausgabe.

Verhaltenssicht:

Die Verhaltenssicht beschreibt die Systemabläufe. Hier wird definiert, welche Aktionen, welche Systemreaktionen auslösen. Hierzu zählen z.B. Zustände und (erlaubte) Zustandsübergänge

Datensicht:

Die Datensicht ist die inhaltliche Ausgestaltung der Informationsobjekte sowie die Beziehungen zwischen den Informationsobjekten (Struktur).

Die funktionalen Anforderungen erfahren in der Regel die größere Aufmerksamkeit im Softwareentwicklungsprozess. Sie sind zugegebenermaßen einfacher zu definieren als Qualitätsanforderungen. Ein Softwareentwicklungsprozess, der dem Entwicklerteam viel Freiraum für Kreativität einräumt, eröffnet einerseits Chancen, indem dem Kunden zusätzliche Features als Begeisterungsfaktoren angeboten werden können, andererseits besteht aber auch die Gefahr, dass hier Schaden durch eine falsche Prioritätensetzung oder durch „Function-Overhead“ bzw. „Gold Plating“ entsteht. Optionen sind genau zu hinterfragen. Die Entscheidungen sollten in jedem Fall bewusst vor dem Hintergrund