# 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


## Hallo Test