Please enable JavaScript.
Coggle requires JavaScript to display documents.
Dokumentation von Anforderungen - Coggle Diagram
Dokumentation von Anforderungen
Aktivitäten zur Dokumentation von Anforderungen
Bestimmung v. Zweck+Zielgruppe
Zweck+Zielgruppe variieren nach Projektsituation
typische Ziele
Komm.unterst. SH: Anf. klären+priorisieren, Anf Architekten/Devs z. Umsetzung übergeben
Wissensspeicher+Referenz f. Beschlüsse+Definitionen: Wartung+Weiterentw. sieht urspr. Anf
Verbindlk. Aussagen+Klärung im Streitfall: anerkannte gemeinsame Vereinbarung, bei Missv./Unklarheiten
Bestmg. Zweck+Zielgruppe -> Klarheit über Verwendung Doku
Ausrichtung n. Zielgruppe: Inhalt, Umfang, Form anpassen (Fachbereich <-> Top Management <-> Devs)
Risiken
SH verstehen Doku nicht, geben nicht zu
sehr detaillierte Swmodelle -> Missverständnisse
wichtige, ggf. nicht abestimmte Anf verborgen in großen Dokus + übersehen
Anf. nur Sammlung v. User Stories -> Übersicht+Abh. fehlen
typische Komm.situationen
Diskussion m. Fachbereich über fkt. Anf.
Entscheidgsvorlage Mngmt Freigabe Budget
Architekten+Devs: Schätzung Dauer+Umsetzung
Auswahl d. Detailebene+Dokumentationsform
versch. Personengruppen lesen+verstehen Doku
Vorwissen+Interessen SH berücksichtigen
Detailebene
Überblick -> Top Management
detaillierte Darstellung -> Schätzung Aufwand+Dauer Umsetzung
Dokumentationsformen
Softwaremodelle
Prototypen
Skizzen
Tabellen
Text
Dokumentation v. Anforderungen
auf Basis vorhergehender Aktivitäten in geeigneter Form dokumentieren
Prüfung, ob Doku noch zu Zweck+Zielgruppe passt
nach Abschluss prüfen, ob Ergebnisse noch für
ursprünglichen Zweck+Ziel angemessen
sind
oder
Änderungen zu Zielgruppe+Zweck
Ziel
Sicherung aktuellen Erkenntnisstands (alle Projektbeteiligte, anstatt in Köpfen einiger)
Unterstützung Kommunikation innerhalb Swprojekts
Gründe f. Doku
alle Aktivitäten direkt/indirekt abhängig (zentrale Bedeutung)
rechtliche Relevanz (Basis f. Verträge+Verbindlichkeiten, Klärung im Streitfall)
Menge Anforderungen sehr komplex, IT-Sys. tausende Anf. + Abhängigkeiten
Verfügbarkeit Anf. muss gewährleistet sein, Einarbeitung neuer Projektmitglieder
4 Schritte f. systematische Doku (s. rechts)
Typische Elemente in der Anforderungsdokumentation
Produkt- bzw. Projektvision
Beginn Projekt: Vorgaben+Anf. Auftraggeber ermitteln, dokumentieren, abstimmen
Projektidee -> Stück f. Stück Vorgaben, Ziele, Erwartungen ident.+festlegen
Vorteil Ausformulierung Projektvision
Erarbeitung gemeinsames Verständnis ü. Vision
hilft bei Kommunikation mit SH
dient Einleitung+Hinführung auf Doku
Anker+Abholer für WS+Besprechungen mit SH
abschließende Prüfung, ob Inhalt+Form n. z. Zweck+Zielgruppe passen
= erster Abschnitt eines Anf.dok.
enthält
Ziel/Zweck Projekt
Motivation für Projekt
Festlegung Ebene beschr. Anf., ggf. Zweck+Zielgruppe Doku
Überblicksebene
= technische + fachliche Einordnung d. Anwendung
Überblick über
Verortung d. Systeme in
fachl. Prozesslandschaft
(welche Prozesse+Fkt. werden dr. Systeme unterstützt
Einbettung Systeme in
IT-Landschaft
d. Orga
Kurzbeschreibung wichtigster
Systemfkten
(z.B. Use Cases)
techn.
SS
zu a. Systemen (techn. Abh., Integration frühzeitig)
Kurzbeschr.
Rollen
(welche SH aktiv in Anf.ermittlung)
ggf. mehrere Systeme verändern
systemübergr. Anf. berücks.+dokumentieren
ggf. Doku aller Systeme anpassen
Detaillierte Anforderungen
größter Teil im Anf.dok.
jede Systemfkt. kurz beschreiben
z.B. "Artikel in Bestand aufnehmen", "Waren durchsuchen", "Artikel kaufen", "Newsletter versenden"
Systemfunktion besteht aus Teilfunktionen
alle Infos zu jeder Teilfunktion für Devs
insbes.
funktionale Anforderungen, Qualitätsanforderungen, Randbedingungen
Anforderungen in versch.
Formen
dokumentiert
Texte
Aufzählungen
Tabellen
fachl. Modelle
Referenzen auf ext. Dok.
Screenshots v. Prototypen
zusätzlich sinnvoll:
übergreifendes Objektmodell
fachliche Zusammenhänge + Eigenschaften v. Geschäftsobjekten
UML-Klassendiagramm
Glossar
Fachbegriffe v. Fachbereich+IT
inbes. fach-/orga.spez., techn. Abkürzungen
Begriffe m. projektspez. Bedeutung
Begriffe, die im Projekt abweichend zu allgemein bekannten Bedeutung verwendet werden
keine einheitl. Struktur für Anf.doku
Art, Struktur, Inhalt abh. v. Art d. Systems, Orga Sw.projekt, unternehmenssp. Vorgaben
häufig verbindl.
Vorgaben/Empfehlungen/Templates
projektübergreifende Vergleichbarkeit
leichtere Einarbeitung
leichteres Zurechtfinden in Doku
Hilfestellung beim Verfassen
dient als Checkliste
in Praxis: oft Fokus auf
Vollständigkeit statt pragmatische Handhabung
Dokumentationsformen
Text + Tabellen
grunds. alle Anf. beschreibbar
häufigsten verwendete Doku.form
Formen
geschriebener Text
Auflistung einzelner Anf.
Tabellen
User Stories
Satzschablonen
Tabellen:
strukturieren Anf.
Wertebereichte, Eigenschaften, fachl. versch., strukturell ähnl. Apsteke übersichtlich
Vorteile
einfache Anwendung
kein Lernaufwand fürs Lesen
vielseitig einsetzbar
Nachteile
hoher Interpret.spielraum
Ungenauigkeiten in Formulierung
-> oft nur positiver Fall berücksichtigt ("nach erfolgreicher Anmeldung...")
Skizzen + einfache Grafiken
präziser+anschaulicher als Text
Formen
per Hand gezeichnet
fotografiert
mit Programmen wie PowerPoint/Visio -> als Grafik in Doku
Vorteil
einfache+schnelle Erstellung
-> im WS erstl -> als Foto in Doku
v.a. in frühen Phasen des RE (keine techn. Details, fachliche Zusammenhänge im Fokus)
Nachteil
großer Interpret.spielraum
-> Bedeutung Symbole, Formen, Farben
nur bedingt f. dauerhafte Doku
-> Ergänzung dr. Legende/Beschreibung nötig
Modelle
reduzieren Interpret.sp.raum v. Text, Skizzen, Grafiken weiter
grafische Modelle <-> textuelle Modelle
grafische Modelle
visuelle Ausprägung
Notationselemente haben best. Bedeutung
Anf. zu Struktur+Verhalten
grafische Prozessmodelle (BPMN, EPK)
grafische Softwaremodelle (UML)
textuelle Modelle
XML
Datenstrukturen an techn. SS
Vorteile
geringerer Interpret.sp.raum
Bedeutung zu Not.elementen bekannt
-> Leser erschließt Inhalt selbstst.
-> muss Ersteller nicht fragen (Bedeutung Elemente)
Infos kompakter dokumentiert
graf. Modelle erschl. schneller als Text
Nachteile
Schulungsaufwand
-> Bedeutung+Verwendung Notat.elemente (erstellen+lesen können)
nicht universell einsetzbar
-> Fokus: best. Aspekte (Struktur System, Verhalten System)
-> versch. Diagrammtypen nötig
GUI-Prototypen
Einsatz
Anforderung an BenutzerSS
sowohl Ermittlung Anf. + Doku
UI
Größe
Position
Farbe
Beschriftung v. Elementen
Erscheinung+Inhalt Fehlermeldungen
Reihenfolge Dialogmasken in Abh. Nutzerinteraktion
Skizzen, Wireframes, Mockups
Mischform versch. Doku.formen
in Praxis: Mischung Modelle+Text+GUI-Prototypen
Vorteil
Kombi gleicht individuelle Nachteile aus
z.B. graf. Modell+Text
-> nicht Inhalt vollst. beschreiben, kurze Beschreibung + Bezug zu anderen Anf.
Notationselemente erläutern (Aktionen, Funktionen, Informationsobjekte, Zustände, Klassen)
wichtig bei Nutzung versch. Dokuformen
gleichen Erkenntnisstand wiedergeben
keine Inkonsistenzen
möglichst kleiner Interpretationsspielraum
möglichst eindeutig formuliert
-> Fkt.+Eigensch., die tats. gemeint waren
jede Art möglich, die Komm.+Verständg. mit SH erleichtert