Warum ist Dokumentation wichtig?
Persistenz
common reference
fördert Kommunikation
fördert Objektivität
unterstützt das Training neuer Mitarbeiter
Speichert Expertenwissen
hilft über Probleme zu reflektieren
Lastenheft: Konsens zwischen Stakeholdern, Vertrag zwischen Customer und Supplier, für Meilensteindefinition
Pflichtenheft: Informationsquelle für Design & Implementierung, Referenz für Tests, Change & Release Management, für Bedienungsanleitungen
Wie kann Dokumentation verbessert weden?
systemspezifisch
Security Requirements
Usability Requirements
Performance Requirements
Look & Feel Requirements
projektspezifisch
offene Probleme, neue Probleme
Aufgaben
Risiken
User Doku
Wie sieht das Requirements Pattern von Rupp aus?
When: logische oder zeitliche Bedingung
The System: Name
Shall / Should / Will: zeigt die Wichtigkeit des Requirements
shall = legal bindendes Requirement
should = highly recommended
Process: die Funktionalität
Process: Funktion unabhängig von Usern
Provide X with the ability to <process>: Funktion für User
Be able to <process>: Funktion als Reaktion auf Trigger events von anderen Systemen
object: Objekt für was die Funktion gebraucht wird, zb Dokument
weitere details über das Objekt
Was ist EARS?
Easy Approach to Requirements Syntax
Template Set
Struktur: While <optional pre condition>, when <optional trigger>, the <system name> shall <system response>
0-n pre conditions
0/1 trigger
1 system name
0-n responses
verschiedene Templates
Ubiquitous Requirements: immer aktiv
the <system name> shall <system response>
State driven Requirements: aktiv solange der Status true ist
while <precondition>, the <system name> shall <system response>
Event driven Requirements: Antwort auf Event
when <trigger>, the <system name> shall <system response>
Optional feature Requirements: nur wenn Produkt/System ein bestimmtes Feature hat
where <feature is included>, the <system name> shall <system response>
Unwanted behaviour Requirements: Antwort auf unerwünschte Situationen
if <trigger>, then the <system name> shall <system response>
Was ist ein goal?
ein Intention über ein System, dessen Erfüllung die Kooperation von Komponenten, aus denen das System besteht, erfordert
Intention in Hinblick auf Ziele, Eigenschaften oder Nutzung des Systems
Vorteile
Identifikation & Lösung von Konflikten
Stabilität
besseres Verständnis für das System
unterstützen Erhebung von Requirements
Identifikation & Evaluation von alternativen Realisierungen
begründet Requirements
wenig Aufwand
Wie kann ein Goal zerlegt werden?
Goals werden in sub-goals zerteilt, rekursiv, bis man das Statement Requirement nennen kann
AND-Composition: alle subgoals müssen erfüllt sein
OR-decomposition: eines der sub-goals muss erfüllt sein
Wie sieht die Goal Hierarchie aus?
Vision: Essenz der Requirements, Ultimative Antwort auf “Warum?”
steuert die frühe dev Phase
hilft in späteren Phasen zwischen wichtigen und unwichtigen Aspekten zu unterscheiden (Vision muss eingehalten werden)
Goals
Requirements
Design
Implementation
Zuletzt geändertvor einem Jahr