IRE FL

1. Zentral verwaltet (nur 1 Version!)
2. Verantwortliche für Edit (Konsistenz!)
3. Allgemein zugänglich
4. Verbindlich verwenden
5. Herkunft eines Begriffes (für Rückfragen)
6. Abgestimmt mit Stakeholder + Freigabe
7. Einträge mit einheitlicher Struktur

1. Strukturperspektive (Struktur von In / Out Daten + Nutzung unsd Abhängigkeit zu Systemen)
2. Funktionsperspektive (ggf Systematik zur Manipulation der In-Daten)
3. Verhaltensperspektive (Zustandsorientiert dokumentieren)

Syntax: Verwendete Modellelemente + Gültige Kombinationen

Semantik: Bedeutung der Modellelemente -> Basis für Interpretation 

1. Befragungstechnik (Interview, Fragebogen)
2. Kreativitätstechniken (Brainstorming, Perspektivenwechsel, Analogietechnik)
3. Doku-Zentrierte Techniken(Systemarchäologie, Perspektivenbasiertes Lesen, Wiederverwendung)
4. Beobactungstechniken (Feldbeobachtung, Apprenticing)
5. Unterstützende Techniken (Mindmapping, Workshops, CRC-Karten, Audio-/Videorecordings, UseCase-Modellierung, Prototypen

1. RUP
   1. Auftraggeber -> Business Model
   2. Auftragnehmer -> Spezifiziert tiefer
2. ISO 29148:2011
   1. Einführung
   2. Ref Dokumente
   3. A
   4. Verifikation
   5. Anhänge (Annahmen...)
3. V-Modell
   1. Auftraggeber -> Lastenheft (Was + Wofür)
   2. Auftragnehmer -> Pflichtenheft (Wie

1. Abbild der Realität
2. Verkürzung der Realität -> Selektiv oder Verdichtung (Zusammenfassung)
3. Pragmatische Eigneschaft ->Redukion auf nötiges für die Aufgabe

1. Eindeutig + Konsistent
   1. -> Alle einzelnen Anforderungen eindeutig und konsistent + Identifizierbar
2. Klare Struktur
   1. -> Lesbar für jeden Stakeholder (auch Dinge überspringen können)
3. Modifizierbar + Erweiterbar
   1. A-Dokus sind Teil der Projekt-Versionsverwaltung
4. Vollständigkeit
   1. Alle relevanten A
   2. Formale: Tabellen beschriftet, konsistene Quelleangaben / Abkverzeichniss, Definitionen, Normenreferenz...
5. Verfolgbarkeit

1. Use Case -> Systemübersicht
2. Klassendiagramm -> Begriffssyteme und Datenmodellierung 
3. Aktivitätsdiagramm
4. Zustandsdiagramm

1. Schnelle Einarbeitung neue MA
2. Schnelles erfassen von A
3. Selektives Lesen
4. Automatische Prüfung (Vollständigkeit)
5. Einfache Wiederverwendung von A

1. Abgestimmt
2. Eindeutig
3. Notwendig (Systemkontext!)
4. Konsistent (widerspruchsfrei)
5. Prüfbar (durch Tester)
6. Realisierbar (durch Entwickler)
7. Verfolgbar (ID)
8. Vollständig
9. Verständlich (für alle Stakeholder!)

UND: Waagerecht -> Alle müssen vorhanden sein

ODER: Direkte Linie

1. EntityTYP
2. BeziehungsTYP + Kardinalität
3. Attribute

1. Prozess
2. Datenspeicher (persistent)
3. Terminator (ausserhalb des Entwicklungssystems)
4. Datenfluss (Welche Daten)

1. Richtige Stakeholder
2. Trennen Fehlersuche und Fehlerkorrektur
3. Unterschiedliche Sichten
4. Wechsel der Dokumentationsform
5. Konstruktion Entwicklungsartefakte (> Testfälle, Bedieungsanleitung,..)
6. Wiederholte Prüfung

Adressaten:

1.  Kunde / Nutzer
2. Softwarearchitekt
3. Tester

Qualität:

1. "Inhalt" -> inhaltliche Qualität (Vollständig, Korrekt, Konsistent, Notwendig,...)
2. "Dokumentation" -> Dokumentationsrichtlinien, keine Mehrdeutigkeiten
3. "Abgestimmtheit" -> Abgestimmt und Konflikte aufgelöst

1. Sachkonflikt 
2. Interessenkonflikt -> Hohe Qualiät vs Preis
3. Wertekonflikt -> z.B -> Open Source vs Closed Source
4. Beziehungskonflikt -> Profilieren
5. Strukturkonflikt -> MA vs Vorgesetzter
6. Vermischtekonflikte...

1. Einigung
2. Kompromiss
3. Abstimmung -> Mehrheit gewinnt
4. Variantenbildung -> Parametrierung -> Fisch und Vogel
5. Ober-sticht-Unter
6. Consider all Facts
7. Plus-Minus-Interestin
8. Entscheidmatrix

1. Pre-RS -> Quelle für Anforderung
2. Post-RS -> getestet durch, implementiert in,...
3. Tracability zwischen A ->  welche A sind abhängig

1. Selbständiges: <Wann / Bedigung> das System muss/sollte/wird/kann <Objekt> <Prozesswort>
2. Benutzerinteraktion: <Wann / Bedigung> das System muss/sollte/wird/kann <wem> die Möglichkeit bieten <Objekt><Prozesswort>
3. Schnittstelle: <Wann / Bedigung> das System muss/sollte/wird/kann fähig sein <Objekt> <Prozesswort>

1. Bedingung oder Fähigkeit die von einem Benutzer (Person oder System) zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird
2. Bedingung oder Fähigkeit, die ein System erfüllen oder besitzen muss um einen Vertrag, eine Norm eine Spezifikation zu erfüllen
3. 1 oder 2 in dokumentierter Form

1. Ermitteln
2. Dokumentieren
3. Prüfen und Abstimmen
4. Verwalten

1. Analytisches Denken
2. Empathie
3. Kommunikationsfähigkeit
4. Konfliktlösungs
5. Moderationsfähigkeit
6. Selbstbewusstsein
7. Überzeugungsfähigkeit (Anwalt der A)

Eine R. wird nicht umgesetzt, sondern schränken den Lösungsraum ein

(z.B. Das System muss bis 2020 eingführt sein; Das System muss mit Webservices realisiert werden)

1. Performanz
2. Sicherheit
3. Zuverlässigkeit (Verfügbarkeit, Fehlertoleranz, Wiederherstellbarkeit)
4. Benutzbarkeit
5. Änderbarkeit / Wartbarkeit
6. Übertragbarkeit (Anpassbarkeit, Installierbarkeit, Austauschbarkeit)

1. Use Case Diagramme
2. Datenflussdiagramme (deMarco)