113 lines
3.2 KiB
Markdown
113 lines
3.2 KiB
Markdown
# 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
|
|
|
|
- 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
|
|
- 
|
|
- Identifizierung:
|
|
- 
|
|
|
|
#### Use Case
|
|
|
|
|
|
#### Communication Lines
|
|
|
|
|
|
#### System Boundaries
|
|
|
|
|
|
|
|
## 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
|
|
|
|
|
|
|
|
### Good User Stories: INVEST Criteria
|
|
|
|
|
|
#### 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:**
|
|
- 
|
|
|
|
#### 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:**
|
|
- 
|
|
|
|
#### V - Valuable
|
|
- **Beispiel:**
|
|
- 
|
|
|
|
#### E - Estimable
|
|
- Devs müssen workload abschätzen können
|
|
- **Gegenbeispiel:**
|
|
- 
|
|
|
|
#### S - Small
|
|
|
|
|
|
#### 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 |