update

Writerside/topics/02/OOAD/RequirementsAnalysis.md

@@ -0,0 +1,113 @@
+# Requirements Analysis
+## Domain Diagram
+- Konzeptuelles Modell um ein gemeinsames Vokabular im Projekt-Team zu etablieren
+### Problem Domain
+- Devs haben ein gemeinsames Verständnis von Lösungen
+
+### Solution Domain
+- Es muss ein gemeinsames Verständnis von dem Arbeitsumfeld des Klienten geschaffen werden
+
+### Beispiel Domain Diagram
+![image_410.png](image_410.png)
+- Zeigt die wichtigsten Problem-Domains und ihre Verbindungen
+
+
+## UML Use Case Diagram
+- System Anforderungen erfassen
+  - NUR [Functional Requirements](IntroductionOOAD.md#requirements-in-software-engineering)
+
+### Notation
+#### Actor
+- ![image_411.png](image_411.png)
+- Identifizierung:
+  - ![image_412.png](image_412.png)
+
+#### Use Case
+![image_413.png](image_413.png)
+
+#### Communication Lines
+![image_414.png](image_414.png)
+
+#### System Boundaries
+![image_415.png](image_415.png)
+
+
+## User Stories
+### Definition
+- Beschreiben funktionalen Wert für einen Nutzer des Systems / der Software
+- Aspekte
+  1. **Card**
+     - Beschreibung der Story
+       - Genutzt für Planung, Erinnerung
+     - Traditionell Handschriftlich
+     - Repräsentiert Kunden-Anforderungen
+       - nicht Dokumentation
+  2. **Conversation**
+     - Gibt Details über Story
+     - Wichtigster Teil der User Story
+     - Werden mit dem Kunden vor der Entwicklung diskutiert
+  3. **Confirmation**
+     - Akzeptierungskriterien (Tests)
+     - Dokumentation der Konversation
+     - Können entscheidend sein, wann eine Story abgeschlossen ist
+
+##### Beispiel UserStory: Job Posting und Search-Website
+- Ein Nutzer kann nach Jobs suchen
+- Eine Firma kann eine offene Stelle posten
+- Ein Nutzer kann einstellen, wer seinen Lebenslauf sehen kann
+
+![image_416.png](image_416.png)
+
+### Good User Stories: INVEST Criteria
+![image_417.png](image_417.png)
+
+#### I - Independent
+- Unabhängig von allen anderen Stories
+  - Stories sollten in allen möglichen Reihenfolgen bearbeitet werden können
+- Falls eine enge Kupplung besteht
+  - MERGE
+- **Beispiel:**
+  - ![image_418.png](image_418.png)
+
+#### N - Negotiable
+- Stories sind keine festen Verträge
+  - Kurze Beschreibung von Funktionalität
+- Details müssen in Konversation zwischen Kunde und Team verhandelt werden
+- Falls wichtige Details vorher bekannt sind
+  - als Annotation inkludieren
+- **Beispiel:**
+  - ![image_419.png](image_419.png)
+
+#### V - Valuable
+- **Beispiel:**
+  - ![image_420.png](image_420.png)
+
+#### E - Estimable
+- Devs müssen workload abschätzen können
+- **Gegenbeispiel:**
+  - ![image_421.png](image_421.png)
+
+#### S - Small
+![image_422.png](image_422.png)
+
+#### T - Testable
+
+## Gathering Stories
+- **Nutzer-Interviews**
+  - Standard
+  - Wichtig:
+    - Echte Nutzer befragen
+  - Fragen sollten offen und kontextfrei sein
+- **Umfragen**
+  - Für weitere Details in bekannten Stories
+  - Beispielfragen:
+    - Wie oft nutzt du [Feature]
+    - Warum nutzt du [Feature] nicht mehr
+- **Beobachtungen**
+  - Nutzer beobachten, während Nutzung befragen
+  - Seltene Möglichkeit zur Durchführung
+    - Wenn dann da: NUTZEN!
+- **Story-Writing-Workshops**
+  - Meeting mit Devs, Nutzer, Produkt-Kunde, andere Beteiligte
+  - Schnellste Möglichkeit für neue Stories
+  - Führen des Workshops benötigt Erfahrung