IT: Anforderungen erfassen (Lasten- und Pflichtenheft)

Anforderungsanalyse (requirements engineering)

Gliederung

funktionale Anforderungen (vorgesehene Funktion, Ein- und Ausgabe)
- Gesamtablauf (Workflow)
- interne Abläufe
- Anwendungsfälle (Verhalten an Systemgrenze)
- Anwendungsfälle/UseCases
  - Basic Course = Optimalfall
  - Verhalten an Systemgrenze
  - Alternative Course
  - Ableitung aus UseCases
- keine Umsetzungsdetails (Benutzeroberfläche etc.)
nicht funktionale Anforderungen (sonstige Anforderungen)
- Qualität
  - An Gesamtsystem oder an Teilsysteme
  - z.B. Antwortzeiten, Speicherverbrauch, Zuverlässigkeit, Änderbarkeit, Wartbarkeit, Portabilität
- Termine
  - Ab Auftragsvergabe (ohne konkretes Datum) rechnen.
- Benutzbarkeit des Systems
  - z. B. ergonomische Gestaltung der Benutzungsschnittstelle, Fehler-Robustheit, Individualisierbarkeit
- Implementierung
  - Zielplattform mit Hardware/Software-Komponenten, Schnittstellen zu anderen Systemen, Dokumentation und Betriebshandbücher
- Systemerstellung, -einführen und -betreuung
  - Entwicklungsumgebung, zu beachtende Vorschriften, Prüfverfahren sowie die Entwicklungsdokumentation

Bezeichnung der Anforderungen: Subjekt + Verb

Wer gibt Anforderungen vor? Kunde des Kunden, andere Abteilung?
Wer entscheidet, wer gibt Projekt frei?
- Darf mit (Budget-) Entscheider kommuniziert werden?

Vorgehen:

Erstellt vom Auftraggeber: Beschreibt WAS getan werden soll (Forderungen)
Grundlage für Einholung von Angeboten
Kann auch Ausschreibung sein
Definition von allen Forderungen an die gewünschte Lieferung und Leistung (Soll-Zustand)
- funktionale/nicht funktionale Anforderungen
- Wunsch-, Muss, Abgrenzungskriterien
- Intention, Qualität, Abnahme, Wartung…
wird/muss-Formulierung

Spezifizierung in DIN 69905

daraus folgt Analyse bei Auftragnehmer

Erstellt vom Auftragnehmer
Beschreibt WIE die Umsetzung erfolgen soll (Definition von Lösungskonzept)
Ist das Angebot und später die (konkretisierte) Vertragsgrundlage
Detailierung, Planung, Analyse, Lösungsansätze
Beinhaltet
- das Lastenheft
- Analyse-Modell
  - Use Cases
  - Aktivitätsdiagramme
  - Anforderungen
- weitere Diagramme und Pläne (Zeit, Tests, Einführung…)
Wird versioniert
Ist erster Eindruck des Kunden
- Grundlage für wirtschaftlichen Erfolg des Auftragnehmers

Zielbestimmung
- Beschreibung von Muss-, Wunsch-und Abgrenzungskriterien (bewusste Verzichte)
Produkteinsatz
- Festlegen von Anwendungsbereich(en), Zielgruppe und Betriebsbedingungen
Produktumgebung
- Software/Hardware
- Schnittstellen
- Orgware (Organisatorische Rahmenbedingungen (IT-Abteilung, Abteilungsleiter…)
Produkt-Funktionen (funktionale Anforderungen)
- Produktdaten
  - zu speichernde Daten und deren Eigenschaften
- Produktleistungen
  - allgemein und funktionsbezogen (funktional)
Benutzeroberfläche
Qualitätsbestimmung
- messbare Kriterien!
Testszenarien/Testfälle
- Beschreibung von Testfällen für das zu entwickelnde System (anwendungsbezogen)
Entwicklungsumgebung, Arbeitsprogramme, Betriebssysteme…
weitere Anforderungen

Solange vier Eigenschaften der Anforderungen nicht erreicht, braucht man nicht weitermachen.
Interessen von Kunden des Kunden beachten (Nutzungsszenarien erstellen)
Bei Annahmen über Ablauf dies mit Kunde abklären
viel mit Kunden kommunizieren.
Weitere Tipps: https://zukunftsarchitekten-podcast.de/5-schritte-zur-erstellung-eines-guten-lastenheftes/