Lade Inhalt...

Anforderungsermittlung im Requirement Engineering

Hausarbeit 2016 35 Seiten

Informatik - Software

Leseprobe

Inhaltsverzeichnis

Kurzfassung

Schlüsselwörter

Abkürzungen

Abbildungsverzeichnis

Vorwort

1. Einführung
1.1. Problemstellung
1.2. Zielsetzung
1.3. Vorgehensweise

2 Requirement Engineering und Requirement Management
2.1 Requirement
2.2 Requirement Engineering
2.3 Requirement Management
2.4 Ziele des Requirement Engineerings
2.5 Arten von Anforderungen

3 Ermittlung von Anforderungen
3.1 Untersuchungsphase für Anforderungen
3.2 Quellen für Anforderungen
3.3 Ermittlungstechniken
3.3.1 Kreativitätstechniken
3.3.2 Befragungstechniken
3.3.3 Beobachtungstechniken
3.3.4 Prototyping
3.3.5 Unterstützende Techniken
3.4 Gegenüberstellung der Ermittlungstechniken

4. Dokumentierungshilfen von Anforderungen
4.1 Schriftliche Anforderungen
4.2 FAPA
4.3 Priorisierungsverfahren
4.3.1 MosCOoW
4.3.2 Kano-Modell
4.4 Notationsmodelle
4.5 Zusammenfassung Anforderungsermittlung

5. Fazit

Literaturverzeichnis

Abkürzungen

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Requirement Engineering & Management

Abbildung 2: Arten von Funktionalen Anforderungen

Abbildung 3: Ermittlungstechniken

Abbildung 4: Gegenüberstellung

Abbildung 5: Swimlane Diagramm

Kurzfassung

Computersysteme und Softwareanwendungen gehören immer spürbarerfest zum Alltag unserer Gesellschaft dazu und prägen unser Leben.[1]

Das Geschäft mit den Informations- und Kommunikationstechnologie boomt wie nie zufuhr.[2] Die ITK-Branche allein in Deutschland verzeichnete im Jahr 2014 eine Gesamtgröße von 122,137 Mrd. Euro und wuchs somit um 5 Mrd. Euro zum Vorjahr.[3] Hiervon sind allein für Softwaresysteme,Umsätze von etwa 20 Mrd. Euro erzielt worden.[4] Software Systeme erleichtern uns durch ihre vielfältigen Funktionalitäten das Leben durch alle Lebensbereiche hindurch.[5] Um den stetigen neuen Anforderungen gewachsen zu seinist der Software Entwicklungsbereich durch einen schnell voranschreitenden Fortschritt undvon ständig neu eintretendenInnovationen gekennzeichnet.[6]

Demzufolge werden auch die Softwareanwendungen immerkomplexer.[7] So verdoppeln sich die Codeumfänge einiger Softwaresysteme jede 2 bis 4 Jahre.[8] Umso wichtigerund Grundlegender wird es hier ein effizientesRequirement Engineering& Management durchzuführen. Requirement Engineering& Management belegt zwar im Durchschnitt nur 2-5%[9] des Projektaufwandes, dennoch trägt es eine fundierte Grundlage zum Projekterfolg dar.[10]

Den unter den drei Hauptgründen die zu einem abgebrochenen oder dem nicht erreichen von gesetzten Zeit-, Qualitäts-, Leistungs- oder den Budget- Zieleneines Projektes, gehören unteranderem Unklare Verantwortlichkeiten, Unzureichende Prozesskenntnisse und ein unzureichendes und fehlerhaftes Anforderungsmanagement, was letzteres für Requirement Engineering steht.[11] Des Weiteren wurde Bewiesen, dass 55% Prozent der Fehler welche in ein Produkt einfließen, auf die Disziplin des Requirement Engineerings zurückzuführen ist.[12]

Schlüsselwörter

Anforderungsanalyse – Ziele – Phasen – Stakeholder – Risiken – Ermittlungstechniken – Methoden–Brainstorming – Prioriesierungsverfahren – MosCow – Kano Modell – Anforderungsarten – Ermittlungsprozess

Vorwort

Diese Seminararbeit ist im Auftrag der FOM Hochschule für Ökonomie und Management in Stuttgart, in dem Studiengang Wirtschaftsinformatik und im Rahmen des Modules Software –Engineering, erstellt worden.Die Seminararbeit beschäftigt sich mit der Thematik des Requirement Engineerings mit dem Schwerpunkt der Ermittlung von Anforderungen.

1. Einführung

Die Disziplin des RequirementEngineeringsist fundamental für den Erfolg eines Projektes.[13] Ohne die Ermittlung, Verwaltung, Dokumentation und Prüfung von Anforderungen bei einem Projekt, sind diese eher schwer umzusetzen und zu realisieren.Das Requirement Engineering & Management stellt die Grundlage, für die Entwickler, die durchzuführenden Testfälle, die Kalkulation des Gesamtprojektes und die Akzeptanz der Lösung durch die Endanwender, dar.[14] Desweiteren stellt RE&M einen festen und bedeutenden Bestandteil der Vertragsgundlagen zwischen Beauftragter und Dienstleister dar.[15]

1.1 Problemstellung

Einer Studie nach Scheitern etwa 18% der angefangen Projekte und 43% der Projekte scheitern gegenüber ihren Zielangaben.[16] Gründe für das Scheitern hinsichtlich den Zielangaben geben Projektteilnehmer einer Umfrage nach unzureichende Anforderung an.[17] Ein weiterer nicht zu unterschätzender Punkt für die Durchführung eines effizienten Requirement Engineerings sind die hohen Kosten von Fehlerbehebungen im späteren Projektverlauf.[18] Diese können schnellschwerwiegende Folgen für den Budgetrahmen hervorbringen.

Anforderungen sind die Basis für alle weiteren Aktivitäten und Entwicklungsschritte bis zum endgültigen Produkt eines Projektes und sorgen dafür, dass sowohl der Kunde als auch die jeweilige Organisation das Produkt bekommt, welches gewünscht und benötigt wird.[19]

1.2 Zielsetzung

Zielsetzung dieser Seminararbeit ist dem Leser die Disziplin des Requirement Engineerings zu erörtern.Schwerpunkt hierbei wird die Kern-Aktivität der Anforderungsermittlung sein, da diese eine der Grundlegenden Aktivitäten darstellt Anforderungen vollständig, Missverständnis frei und eindeutig festzuhalten. Hierbei existieren mehrere Techniken und Ansätze welche dem Leser aufgezeigt werden. Fortfolgend werden die vorgestellten Techniken anhand auserwählten Kriterienuntersucht und miteinander vergleichen. Daraus werden Schwächen und Stärken sowie Gemeinsamkeitenersichtlich welche dem Leser einen geeigneten Überblick der Anforderungsermittlungstechniken und Ansätze gibt. Dieser kann demnachdie passenden Techniken je nach Projektsituation und Bedürfnissen an zu ermittelnden Anforderungsartenselektieren.

1.3 Vorgehensweise

Dazu gehören dem Leser vorerst ein Verständnis gegenüber der Thematik des Requirement Engineerings zu vermitteln indem Grundlagen wie der Definition, die Ziele des RE&M, Kern Aktivitäten und unterstützende Aktivitäten des RE-Prozess vorgestellt werden.Anschließend wird der Schwerpunkt auf die Anforderungsermittlung gesetzt indem die existierenden Ansätze und Techniken der Anforderungsermittlung vorgestellt werden. Die wichtigsten Anforderungermittlungstechniken werden darauffolgend nochmals anhand selektierten Kriterien auf Ihre Vor- und Nachteile sowie Gemeinsamkeiten untersucht.Desweiteren werden Hilfestützen für die anschließende Dokumentierungsphase vorgestellt anhand denen Anforderungen strukturierter ermittelt werden können.

2 Requirement Engineering und Requirement Management

2.1 Requirement

Um die einzelnen Disziplinen gegenüber ihrer Terminologie zu beschreiben wird vorerst der Begriff Anforderung definiert. Nach C. Ebert beschreibt eine Anforderung was ein Kunde oder Benutzer aneinem zu erstellenden Produkt erwartet und die Formen, einer Bedingung, eines Attributes, Zieles oder eines Nutzen einnehmen kann.[20] Anforderungen beschrieben demnach notwendige Eigenschaften eines Systems zur Lösung eines gegebenen Problems.

2.2 Requirement Engineering

Die Disziplin des Requirement Engineerings hat seine Ursprünge aus der Luft und Raumfahrttechnik und der Medizintechnik.[21] Der Begriff Requirement Engineering welcher aus dem Englischen stammt und übersetzt Anforderungsentwicklung bedeutet wird nach der Literatur von C. Ebertfolgend definiert

,,[Requirement Engineering ist][d]as disziplinierte, systematische Vorgehen zur Ermittlung, Dokumentation, Analyse, Prüfung, Abstimmung und Verwaltung von Anforderungen, unter kundenorientierten, technischen und wirtschaftlichen Vorgaben[…] ‘‘. [22]

Dabei wird sich die Arbeit auf die ersten drei genannten Aktivitäten konzentrieren, vor allem die Anforderungsermittlungsprozess.

2.3 Requirement Management

Das Requirement Management,auf Deutsch, Anforderungsmanagment,befasst sich nach C. Ebert mit ,,…[ der] Evolution, Verwaltung und dem Managements von Anforderungen im Softwarelebenszyklus…‘‘.[23]

Die Literatur variiert gegenüber der Definition des Requirement Engineerings, der internationale Berufsverband ,, Institute ofElektronicaland Electronics Engineers ‘‘, kurz IEEE teilt das RE in 4 Phasen ein, Erhebung, Analyse, Spezifikation und Bewertung.[24] Das Internationale Institute of Business Analysis hat wiederrum eine weitaus größere Vorstellung des Begriffes Requirement Engineering und teilt diesen in mehrere Aktivitäten auf, wobei hier im Gegensatz zu der anderen Literaturen auch die Kommunikation in den Fokus kommt.[25] Prinzipiell hat jedes Standardisierungsinstitute, jeder Spezialist, jedes Reifegradmodell, wie CMMI oder Spice, welches dazu dient bestimmte Abläufe bzw. Prozesse und Praktiken für Durchführungen von Produktentwicklungen nachvollziehbar zu beschreiben[26], eine andere Auffassung wie Requirement Engineering & Management im Detail auszusehen hat und wann es Durchgeführt werden sollte.[27] Die Definition von Herrn C. Ebert in Anlehnung an das CMMI Reifegradmodell welches der selbigen Auffassung[28] ist, zwei unterschiedliche Bereiche zu betrachten, wird hierbei als Grundlage dieser Arbeit verwendet.

Unten dargestellltes Bild zeigt nochmals beide Begriffe im Kontext zusammengefasst.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung1: Requirement Engineering & Management ( Quelle: Eigene DarstellungVgl. et al.(Ebert, 2014), S.33)[29]

Aus dem Schaubild ist heraus zuerkennen, dass auf der Ebene des Requirement Managements sich die klassischen Aufgabenbereiche des Managements der Planung, Organisation und Kontrolle befinden. Diese sind durch den ganzen Lebenszyklus durchzuführen. Dies gilt für die Anforderungsänderungen sowie die Dokumentverwaltung. Der obere Abschnitt zeigt ebenfalls nochmal den Prozessartigen Verlauf des Requirement Engineerings. Im weiteren Verlauf der Arbeit wird hierbei Requirement Engineering als Synonym für beide Teilbereiche dem Requirement- Management und demRequirement- Engineering verwendet. Auf ein eingehen in die Aktivitäten des Requirement Managements wird in dieser Arbeit verzichtet, genau wie auf die Aktivitäten des Requirement Engineering Prozesses Prüfen, Abstimmen. Die Bereiche der Dokumentation und der Analyse werden lediglich in Kapiteln erwähnt oder kurz angeschnitten jedoch nicht tiefgründig erläutert. Da der Fokus dieser Arbeit auf den Fokus der Anforderungsermittlung liegt.

2.4 Ziele des Requirement Engineerings

Wie sich aus dem Kapitel der Problemstellung schon zu erkennen gab ist dem Requirement eine wichtige Rolle zu zuschreiben. Die Ziele welche RequirementEngneeringhierbei verfolgt können in sechs wesentliche Ziele eingeteilt werden.[30]

1. Ein Gemeinsames Verständnis zwischen dem zu Entwickelnden Produktes auf Kunden, Stakeholder und Entwicklerseite zu schaffen
2. Die Wissenserhaltungund die Wiederverwendung von Anforderungen durch
schriftliches Dokumentieren von Anforderungen
3. Die Nachverfolgbarkeit von Anforderungen zu ermöglichen
4. Geplante Kosten einzuhalten
5. Geplante Zeitrahmen einzuhalten

2.5 Arten von Anforderungen

Grundlage für die effiziente Anforderungsanalyse und die spätere übersichtliche Verwaltung von Anforderungen sind die Klassifizierungsmerkmale von Anforderungen. Innerhalb der geläufigen Literatur existieren auch hier wieder unterschiedliche Auffassungen. Die Literatur von Markus Grande und auch weitere, beziehen die sogenannten Qualitätsanforderungen und die sogenannten Anforderungen der Randbedingungen in eine Klassifizierung der Nicht Funktionalen Anforderungen Terminologisch ein.[31]

Eine strikte Trennung wie Sie in neueren Literaturen aufzufinden ist, ist hier von großem Nutze. Zu begründen ist dies indem, dass der Begriff ,,Nicht Funktionale Anforderungen´´ gerne von Stakeholdern Missverstanden werden könnte und im Sinne von ,, nicht Wichtig ‘‘verstanden werden könnte. Dies wiederrum könnte zu sehr ärgerlichen und evtl. kostspieligenFehlentscheidungen führen.

Der Literatur von C. Ebert nach kann die Klassifizierung von Anforderungen in drei Klassen eingeteilt werden.[32]

- Funktionale Anforderungen
- Qualitätsanforderungen
- Randbedingungen

Die Gruppe der Funktionalen und Nicht Funktionalen Anforderungen werden dabei nochmals in eine Externe und Interne Sicht untergliedert, was beim späteren Anforderungsmanagement eine Hilfestellung sein kann und wodurch Verantwortlichkeiten und Ansprechpartner demnach leichter zu identifizieren und sich besser Rückverfolgen lassen können.[33] So spiegelt die Interne Sicht stets die Entwicklersicht wieder, die Externe, die des Kunden oder Benutzers.[34] Funktionale Anforderungen beschreiben immer die benötigten fachlichen Funktionen und das Verhalten des zu entwerfenden Systems oder Produktes.Ein Beispiel wäre, die Bereitstellung eines integrierten Kontaktformulars auf einer Webseite durch, dass ein Kunde Anfragen zu gewissen Anliegen stellen kann. Die andere Gruppe der Anforderungen stellen die Qualitätsanforderungen dar, diese legen Qualitative Eigenschaften an das System oder Produkt dar und ergänzen die fachlichen Funktionen.Diese Qualitätsanforderungen können nach ISO/IEC 9126 die Änderbarkeit d. Systems sein, die Benutzerfreundlichkeit eines Systems, die Effizienz der Verarbeitungsprozesse, die Funktionalität im Sinne der beabsichtigten Ausführung, die Übertragbarkeit im Sinne von Umgebungshomogenität und Installierbarkeit, und letztendlich die Zuverlässigkeit des Systems, betreffen.[35]

Spezifische Beispiele für ein Qualitätsmerkmal wäre die Verschlüsselung der Datenübertragung bei dem Kontaktformular oder die Datenübertragung innerhalb 5 Sekunden an den Verantwortlichen. Die dritte und letzte Gruppe sind die Randbedingungen welche organisatorisch, technische oder gesetzliche Vorgaben gegenüber dem zu entwerfenden Systems vorgeben.Beispiel, die Datenspeicherung bis zu einem gewissen Zeitraum wie es etwa bei Internetprovidern der Fall ist und demnach die Bereitstellung von immensen Speicherkapazitäten zur Folge hat.

Folgendes Schaubild gibt nochmals einen Überblick über die Anforderungsarten auf die gerade eingegangen worden ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung2: Arten von Funktionalen Anforderungen (Quelle: Eigene Darstellung in Anlehnung an Vgl. Ebert,(2014), S.29.)

Somit kann man nochmals zusammenfassend sagen, dass die Anforderungsarten die Bereiche, Funktionen, Daten und Datenstrukturen, Hardware und Software Schnittstellen, dem ,, Graphical User Interface ‘‘ GUI, dem Accessmanagement, den Betriebsanforderungen, Anforderungen an Dokumentationen, der Compliance und dem Projekt, abdecken und Produkte der Anforderungsermittlungsphase sind.[36]

3 Ermittlung von Anforderungen

Je nach gewähltem Verfahrensmodell bei einerProjektinitiallisierung stellen die Anforderungen an ein Projekt oder Systems, einen Teilumfang an Eigenschaften oder den kompletten Umfang an Eigenschaften an ein Projekt dar.[37] Üblicherweise sind gerade bei den Agilen und Iterativen(= wiederholend)Vorgehensmodellen wie der ,, Scrum ‘‘ oder dem,, Extreme Programming ‘‘nur ein Teil der Gesamtanforderungen dar und werden durchgängig im Zeitverlaufe des Projektes mit dem Kunden ständig neu erhoben, spezifiziert, verwaltet, geprüft und dokumentiert.[38] Bei den Inkrementellen(=Schrittweise) Vorgehensmodellen wie dem Wasserfall Modell müssen alle Arten von Anforderungen möglichst vollständig zu Anfang des Projektbeginns an ein System erhoben und verwaltet werden.[39] Dies trägt dazu bei das gewisse Nachteile gegenüber dem Entwicklungsprozess entstehen können, die sich in einer gewissenInflexibilität bei Anforderungsänderungen oder sich in einer Verkomplizierung des Anforderungsmanagement während des Projektentwicklungsprozesses, bemerkbar machen können.[40] Die Ermittlung vonAnforderungen stellt somit die erste fundamentale und wichtige Aktivität innerhalb des Requirement Engineerings dar. Anforderungen konkretisieren Ziele[41].

3.1 Untersuchungsphase für Anforderungen

Um Methodisch und Strukturiert bei der Anforderungsermittlung Vorzugehen existieren in der gängigen Literatur mehrere Ansätze, zwei Ansätze von Herrn Ebert sollen hierbei vorgestellt werden. Die Feature-Orientierte Anforderungsermittlung und die Zielorientierte Anforderungsermittlung.[42] Die Feature Orientierte Methode sammelt erst Anforderungen, definiert daraufhin das Projekt, aus dem dann wiederrumein Produktentwickelt wird.[43] Die Zielorientierte Methode hingegen widmet sich erst der Entwicklung der Vision und der Wertevorstellung des Kunden wobei wichtige Kunden und Märkte sowie Wettbewerber identifiziert und verstanden werden.[44] Auch geläufig als Domain Knowledge Aspekte.[45] Aus diesen wird eine schrittweise, kontextartigeErmittlungvon Anforderungen durchgezogen.Vorteile letzterer Methode sind die Reduktion der Komplexität des Produktes und einer Vermeidung von Anforderungsänderungen was wiederrum Zeit und Kosten spart.[46]

3.2 Quellen für Anforderungen

Nach Struktur und Vorgehen festgelegt worden sind müssen die zu untersuchenden Artefakte aus denen man die Informationen für die Anforderungsbildung bekommen kann identifiziert werden.

Hierfür sind folgende drei Kategorien zu beachten.[47]

- Stakeholder
- Dokumente
- Randbedingungen ( siehe Kapitel Anforderungsarten)

Die Stakeholder sind nach Marcus Grande und in weiteren Literatur Stücken als Halter und Interviewpartner zur Ermittlung der richtigen Anforderungen sehr wertvoll.[48] Stakeholdern können Geschäftsführer, Unternehmensberater, Entwickler, Mitarbeiter und Abteilungsleiter aus Strategischen Geschäftseinheiten sein.[49] Um diese effektiv zu managen und zu analysieren gibt es, dass sogenannte ,, Business Analysis Process Model ‘‘welches eine sinnvolle Methodikhierfür darstellet.[50] Dabei werden die Stakeholdern vorerst anhand eines ,,Zwiebelmodells´´ erfasst um eine Übersicht zu bekommen.[51] Die Stakeholder werden dabei in vier Dimensionen eingeteilt, Extern, Organisationsbezogen, vom Projektbetroffen und dem Projektteam.[52] Anhand der Einteilung können demnach weitere Schritte durchgeführt werden wie etwa der Analyse von den jeweiligen Stakeholdern an erlesenen Aspekten welche z.B. Einfluss auf das Projekt, Informationen zu Kontexten, Verantwortlichkeiten von bestimmten Wissens und Informationsquellen zu bestimmten Anforderungen sein können. Der Kreativität ist hierbei keine Grenze gesetzt und kann je nach Analyst variieren.Wichtig ist dabei alles in ein Stakeholder Register zu erfassen welches dann Auskunft über die spezifischen Interessen, Rollen und deren Einflüsse auf das Projekt beinhalten.[53] Ein weiterer wichtiger Ansatz sind zur Verfügung stehende Dokumente, wie etwa bereits vorher vom Auftraggeber angefertigte Lastenhefte, Normen und Standardvorschriften der Organisation und andere aus den Anforderungen der Randbedingungenvorhandenen Dokumente.[54]

3.3 Ermittlungstechniken

Um aus dem Gesamten Mix der im vorigen Kapitel erwähnten Artefakte die Best möglichen Informationen wie Fachliche Prozesse, Systemkontexte, Anwendungsfälle, Datenmodelle, Masken, Berichte, Schnittstellen und Qualitätsanforderungenzu erfassen und zu ermitteln[55] befasst sich dieses Kapitel mit den Methoden und Techniken um dies effizient zu erreichen.

[...]


[1] Vgl.(Heuss, 2010)

[2] Vgl.(o.V., 2015)

[3] Vgl.(o.V., 2015)

[4] Vgl.(o.V., 2015)

[5] Vgl.(Prof. Dr. Richard Lackes, o.J.);(Braun, 2004), S.1.

[6] Vgl.(C. Rammer, 2013), S.3.

[7] Vgl.(Ebert, 2014), S.2.

[8] Vgl.(Ebert, 2014), S.2.

[9] Vgl.(Ebert, 2014), S.3.

[10] Vgl.(Ebert, 2014), S.3.

[11] Vgl.(Ebert, 2014), S.5.

[12] Vgl.(Grande, 2011), S.15.

[13] Vgl.(Ebert, 2014),S.5.

[14] Vgl.(Niebisch, 2013), S.39.

[15] Vgl. ebd., S.39.

[16] Vgl.(Ebert, 2014), S.5.

[17] Vgl.(Ebert, 2014), S.5.

[18] Vgl.(Ebert, 2014), S.12.

[19] Vgl.(Grande, 2011), S.11.

[20] Vgl.(Ebert, 2014), S.21.

[21] Vgl.(Herrmann, 2013), S.1.

[22] Vgl.(Ebert, 2014), S.444; Anpassung und Umstellung: Ronald Foerster

[23] Vgl. ebd., S.444.

[24] Vgl.(o.V., o.J.)

[25] Vgl.(o.V., o.J.)

[26] Vgl.(Grande, 2011), S.112.

[27] Vgl.(Grande, 2011), S.109 ff.;(Unterauer, 2015), S.1;(Ebert, 2014)S.316-332

[28] Vgl.(Grande, 2011), S.114.

[29] Vgl.(Ebert, 2014), S.33;(Grande, 2011), S.25;(Susanne Patig, 2015);(Herrmann, 2013), S.9.

[30] Vgl.(Grande, 2011), S.15 - S.16.

[31] Vgl.(Grande, 2011), S.37.

[32] Vgl.(Ebert, 2014),S.29.

[33] Vgl. ebd.,S.29.

[34] Vgl.(Ebert, 2014), S.31.

[35] Vgl.(Grande, 2011), S.38.

[36] Vgl.(Niebisch, 2013), S.77 – 78;(Ebert, 2014), S.312.

[37] Vgl.(o.V., o.J.)

[38] Vgl.(Bergsmann, 2014), S.22- S.23;(Ebert, 2014), S.312.

[39] Vgl.(Grande, 2011), S.109 - S.112;(Ebert, 2014), S.312.

[40] Vgl.(Grande, 2011), S.59-51;(Ebert, 2014), S.79;(Brückmann, 2014).

[41] Vgl.(Ebert, 2014), S.51 - 54.

[42] Vgl. ebd., S.54.

[43] Vgl. ebd., S.53.

[44] Vgl. ebd., S.54.

[45] Vgl.(Maalej Walid, 2013), S.7.

[46] Vgl.(Ebert, 2014), S.54.

[47] Vgl.(Grande, 2011), S.48;(Ebert, 2014)S.52.

[48] Vgl.(Grande, 2011), S.48.

[49] Vgl. ebd., S.22.

[50] Vgl.(James Cadle, 2010), S.60.

[51] Vgl.(Peter Gerstbach, o.J.);(James Cadle, 2010), S.60.

[52] Vgl.(Peter Gerstbach, o.J.)

[53] Vgl.(Raza, 2009)

[54] Vgl.(Grande, 2011), S.49.

[55] Vgl.(Unterauer, 2015), S.1.

Details

Seiten
35
Jahr
2016
ISBN (eBook)
9783668276024
ISBN (Buch)
9783668276031
Dateigröße
2 MB
Sprache
Deutsch
Katalognummer
v337884
Institution / Hochschule
FOM Essen, Hochschule für Oekonomie & Management gemeinnützige GmbH, Hochschulleitung Essen früher Fachhochschule
Note
2
Schlagworte
Requirement - Engineering - Software Entwicklung Kreativitätstechniken Anforderungsmanagement Anforderungen erheben Anforderungen Bewerten IT-Systeme MosCow Kano Modell Stakeholdermanagement Organisations und IT - Anforderungsarten Anforderungsarten Ermittlungsprozess Anforderungsanalyse

Autor

Zurück

Titel: Anforderungsermittlung im Requirement Engineering