Requierements Engineering

- Kommunikationsprobleme

- Ergebnisorientiert

- Selbstverständlichkeiten

- Projektdruck

1. Erheben

2. Dokumentieren

3. Prüfen

4. Verwalten

Implizite => Stakeholder gehen davon aus, dass diese ohne ausdrückliche Forderungen erfüllt werden, da sie aus Ihre Sicht selbsverständlich sind.

explizite => Anforderungen werden durch die Stakeholder offiziell gefordert und dokumentiert

1. gesagt ist noch nicht gehört => Hat der Gesprächspartner uns gehört?

2. gehört ist noch nicht verstanden => Er hat uns gehört, jedoch uns verstanden, das richtige/gleiche verstanden?

3. verstanden ist noch noch nicht einverstanden => Gehört hat er uns, jedoch damit einverstanden?

Inhaltsebene => rationaler, sachlicher Austausch von Informationen

Beziehungsebene => Werden durch Emotionen, bewusste und unbewusste Wahrnehmungen und Gefühlre beinflusst

1. Forming (Orientierungsphase)
Erstes Kennenlernen der Teilnehmer

2. Storming (Konfrontationsphase)
Entscheidung ob das Team weitere besteht oder nicht. Wenn die Konflikte gelöst werden können, kommt es am Ende dieser Phase zur Definition von Aufgabenrollen.

3. Norming
Hier ensteht ein WIR-Gefühl. Ideen und Gedanken werden ausgetauscht. Gute Stimmung, guter Zusammenhalt

4. Performing
Wachstumsphase...Hier fliesst die gesamte Teamenergie in die Aufgabenbewältigung.

- Analystisches Denkvermögen

- Methodische Kompetenzen

- Fachliche Kompetenzen

- Kommunikationsfähigkeiten und sprachliche Kompetenzen

- Selbstbewusstes Auftreten und Moderationsfähigkeit

- Überzeugungsfähigkeit

- Empathische Fähigkeit

- Auftraggeber

- Lenkungsausschuss

- Projektteam (Projekt- oder TeilProjektleiter)

- Anwender

1. Funktionale Anforderungen
WAS soll das System können

2. Qualitätsanforderungen (nicht funktionale)
Bezug auf Performance, Verfügbarkeit, Skalierbarkeit des Systems (PC soll in 5 Sekunden booten)

3. Randbedingungen
Werden nicht umgesetzt, sondern schränken die Handlungsfähigkeit ein (OR, ZGB, etc...)

- Stakeholder

- Dokumente

- Altsysteme

1. Basisfaktoren
Unbewusste Anforderungen, die erst bei Nicht Erfüllung einem auffallen (implizite Anforderungen). Erfüllte Basisfaktoren erzeugen keine positive Stimmung, sondern vermeiden Unzufriedenheit.

2. Leistungsfaktoren
Leistungen die vom System erwartet werden. Pro nicht erfüllter Faktor, sinkt die Zufriedenheit

3. Begeisterungsfaktoren
Faktoren, die dem Stakeholder unbekannt sind, sogenannte Goodies. => Löst Begeisterung aus.

- Befragung: Interview, Fragebogen

- Kreativität: Brainstorming (paradox), Perspektiven wechsel, Analogietechnik

- Dokumentenzentrierte: Systemarchäologie, Perspektivenbasiertes Lesen, Wiederverwendung von Anforderungen

- Beobachtung: Fallbeobachtung, Apprenticing

- Unterstützende: Mind Mapping, Workshop, CRC-Karten, Audio/Video Aufnahmen, UseCase, Prototypen

Ein Dokument, das spezifische Anforderungen enthält, d.h. Anforderungen, die definierten Spezifikationen genügen.

1. Strukturperspektive auf Dokumentation
Auf diese Perspektive wird betrachtet, welche Strukturen das System aufweisen muss, um die Anforderungen zu efüllen => geeignet dazu: UML-Klassendiagramme, ERD

2. Funktionsperspektive auf Dokumentation
Welche Funktion ein System bereitstellen muss. Welche Daten (Informationen) vom System als Ein- und Ausgabe genutzt und in welcher Art und Weise diese konkret verarbeitet werden => Datenfluss- oder UML-Aktivitätsdiagramm

3. Verhaltensperspektive auf Dokumentation
Gezielte Betrachtung der Zustände, bzw. Zustandswechsel, die ein System, dessen Komponenten und Objekte einnehmen können. => UML Zustandsdiagramm

- RUP

- IEEE 830-1998

- V-Modell

- Lasten- und Pflichtenheft

- Kompenenten basierte Architektur

- Visuelle Software-MOdellierung

- Verifizierbare Software-Qualität

- Kontrolliertes Change Management

Einstieg, Ausarbeitugn, Konstruktion, Überleitung

- Hauptkapitel  mit einleitenden Informationen (Bsp. Systemzweck, Systemabgrenzung)

- Hauptkapitel für allg. Beschreibungen der Software (Bsp. Perspektive des Systems, Merkmale der zukünftige Anwender, Einschränkung für die Entwicklung)

- Hauptkapitel für spez. Anforderungen (Bsp. funktionale Anf., Performance, Schnittstellen)

Lastenheft => Beschreibt die Gesamheit der Forderungen des Auftraggebers an die Lieferungen und Leistungen eines Auftragnehmers

Pflichtenheft => Beschreibt in konkreter Form, wie der Auftragnehmer die Anforderungen im Lastenheft zu lösen gedenkt

1. Eindeutigkeit und Konsistenz
Anforderungen müssen identifizierbar sein durch eine Nummierierung. Auch dürfen sie sich nicht wiedersprechen

2. Klare Struktur
Dokument so strukturieren, dass es den Bedürfnissen aller Stakeholder Rechnung getragen wird (Nach Dokumentenstandards)

3. Modifizierbarkeit und Erweiterbarkeit
Anforderungsdokumente müssen erweiterbar sein

4. Vollständigkeit
Muss vollständig sein inkl. Anhänge

5. Verfolgbarkeit
Anforderungen müssen von der Enstehung bis zum Verfall (Lebenszyklus von Anforderungen) nachvollziehrbar sein

- Abgestimmt
Von allen Stakeholder akzeptiert und als i.O empfunden

- Bewertet
Priosierierung der Anforderungen (Muss & Kann)

- Eindeutig
Die Aussage einer Anforderung erlaubt keine Interpretation.

- gültig und aktuell
Anforderungen können geändert werden. Dabei immer auf die Gültigkeit und Aktualität achten

- Korrekt
Explizite Anforderungen dokumentieren und keine Annahmen treffen, bei denen die Anforderungen nicht bekannt sind.

- Konsitent
Widerspruchsfrei

- Prüfbar
Das Ergebnis muss prüfbar sein

- Realisierbar

- Verfolgbar

- Vollständig

- Verständlich

- Normalisierung

- Substantive ohne Bezugsindex

- Universalquantoren

- Unvollständig spezifizierte Bedingungen

- Unvollständig spezifizierte Prozesswörter

Bsp. Bei einem Bargeldbezug am Bankautomaten sollen eine Kontoprüfung und eine Kartenprüfung vorgenommen werden

Kontoprüfung & Kartenprüfung beschreiben einen eigenen Prozess, der genauer analysiert werden sollte.  Evtl. besteht eine separate Anforderungen zur Kontoprüfung. Wenn ja, kann ein Querverweis erstellt werden.

Bsp. Der Kontostand soll dem Kunde angezeigt werden.

=> Der Programmierer fragt sich nun: Kontostand von welchem Konto? Welchem Kunde etc....

Besseres Bsp. Der Kontostand der benutzen Kontokarte des am Bankautomaten angemeldeten Kunden soll nach einem Bargeldbezug am Bildschirm des Bankautomaten angezeigt werden

Darauf achten bei Anforderugen, dass die Universalquoten wie immer, kein, jeder, alle etc... nur dann verwendet werden, wenn sie effektiv zutreffen.

Bsp. Dem Kunden sollen nach Eingabe des Codes alle Menüpunkte angezeigt werden.

=> Der Programmierer fragt sich nun: Welche Menüpunkte?

Achte beim Formulieren von Anforderungen auf Signalwörter wenn, falls, abhängig etc.... Bei diesen Fällen sollten alle möglichen Kombinationen von Bedingungen erklärt werden.

Bsp. Bei genügender Kontodeckung sollte der Kunde den Betrage beziehen können.

=> Wenn keine Kontodeckung? Was soll dann passieren?

Bsp. Beim Anmelden am Bankautomaten wird der Code eingegeben.

Es empfiehlt sich die Anforderung aktiv zu formulieren (Ausführende Person muss angegeben werden) => Besser wäre:

Der Bankomat soll dem Kontoinhaber (Kunde) die Möglichkeit bieten, deim Anmelden am Bankomaten den Code über den intergrierten Nummernblock einzugeben.

1. Festlegen der rechtlichen Verbindlichkeit (Muss, Sollte, Wird)

2. Den Kern der Anforderungen benennen (Das System muss drucken => "Funktion")

3. Charaktirisieren der Aktivität des Systems (selbständige Systemaktivität, Benutzerinteraktion, Schnittstellenanforderungen)

4. Objekte einfügen (Das System muss drucken => Das System muss den Tagesrapport des aktuellen Tags auf dem Drucker XY drucken)

5. Formulieren von logischen und zeitliche Bedingungen
Logische Bedingungen beginnen mit "falls" (Falls die Anforderungen 1 war, sollte das System......)
Zeitliche Bedingungen beginnen mit "Sobald" (Sobald die Anforderungen 1 ausgeführt wurde, sollte das System....)

1. Und-Oder Bäume
2. Use-Case-Diagramm
3. STRUKTUR-Perspektive
   1. ERD
   2. UML-Klassendiagramm
4. FUNKTIONS-Perspektive
   1. Datenflussdiagramm
   2. Modelle für Funktionsperspektive und Kontrollfluss
   3. UML-Aktivitätsdiagramm
5. VERHALTENS-Perspektive
   1. Statecharts
   2. UML-Zustandsdiagramm

1. Inhalt
   1. Vollständigkeit des Anforderungsdokument (Sicht auf dokumentierte Anforderungen)
   2. Vollständigkeit der einzelnen Anforderungen (Formulierung der Anforderungen)
   3. Vorfolgbarkeit (Quellen der Anforderungen)
   4. Korrektheit / Adäquatheit (Anforderungen erfüllen die Wünsche der Stakeholder?)
   5. Konsistenz (Widerspruchsfrei)
   6. Keine vorzeitigen Entwurfsentscheidungen (Messbarkeit der Anforderungen)
   7. Überprüfbarkeit (Anforderungen notwendig oder überflüssig)
2. Dokumentation
   1. Konformität zum Dokumentationsformat (Satschablonen richtig,etc)
   2. Konformität zur Dokumentationsstruktur (Struktur vom Dokument nach Standard)
   3. Verständlichkeit (Glossar vorhanden?)
   4. Eindeudigkeit (kein Interpretationsspielraum bei den Anforderungen)
   5. Konformität mit Dokumentationsregeln
3. Abgestimmtheit
   1. Abstimmung (Anforderungen durch Stakeholder abgenommen?)
   2. Absimmung nach Änderung (geänderte Anforderungen durch Stakeholder abgenommen?)
   3. Konflikte aufgelöst (Konflikte erkannt und entsprechend dokumentiert sind)

• Beteiligung der richtigen Stakeholder
• Trennung von Fehlersuche und Fehlerkorrektur (von Anforderungen)
• Prüfung aus unterschiedlichen Sichten
• Geeigneter Wechsel der Dokumentationsform
• Konstruktion von Entwicklungsartefakten
• Wiederholte Prüfung

• Review
  • Stellungsnahme
  • Inspektion
  • Walktrough
• Perspektivenbasiertes Lesen
  • Einleitung (Beschrieb welche Perspektiven der Instruktor annehmen muss und welche Kriterien wichtig sind)
  • Instruktionen (Anleitung für den Instruktur, wie er das Dokument durchsuchen soll)
  • Fragen
• Prüfung durch Prototypen
  • Wegwerfprototypen (Werden nur für die Stakeholder erstellt zur Visualisierung)
  • Evolutionäre Prototypen (wird konstant verbessert und weiterentwickelt)
• Einsatz von Checklisten

1. Konflikt identifikation (Konflikte erkennen und offen anzusprechen)
2. Konflikt-Analyse
   1. Sachkonflikt (Mangel an Informationen untern Stakeholdern - Der eine weiss mehr als der andere)
   2. Interessenkonflikt (Möglichst viel Sparen oder möglichst beste Qualität)
   3. Wertekonflikt (Widerspruch durch verschiedene Wertevorstellungen der Stakeholder)
   4. Beziehungskonflikt (Profilierung der Stakeholder untereinander)
   5. Strukturkonflikt (Vorgesetzter lehnt konstant Anforderungen eines Mitarbeiters ab)
3. Konfliktauflösung
   1. Einigung (Beide Parteien favorisieren eine Lösung)
   2. Kompromiss
   3. Abstimmung (Mehrheit entscheidet)
   4. Variantebildung
   5. Ober-sticht-Unter-Methode (Hierarchische Entscheidung)
   6. Consider-all-Facts-Methode (alle Einflussfaktoren für eine Entscheidung berücksichtigen)
   7. Plus-Minus-Interesting (Vorteile gegenüber Nachteile stellen)
   8. Entscheidungsmatrix
4. Dokumentation der Konfliktauflösung