FHNW - Requirements Engineering - Buch Zusammenfassung

• Nachweisbarkeit (das eine Anforderung berücksichtig wurde)
• Identifikation von Goldrandlösungen
  • Identifikation von nicht geforderten Eigenschaften des Systems oder Anforderungen
  • Existenzberechtigung
• Auswirkungsanalyse
  • Was sind die folgen wenn sich die Anforderung ändert? Zusammenhang erkennen
• Wiederverwendung
  • Wiederverwendung von Entwicklungsartefakten wird einfacher. A010 => Test 010
• Zurechenbarkeit
  • Zuordnung von Entwicklungsaufwänden
• Wartung und Pflege
  • Ursache und Auswirkung von Fehler

• Pre RS Traceability
  • Anforderung auf Ursprung (Quelle)
• Post RS Traceability
  • Anforderung auf Entwicklungsartefakte (Komponente, Implem. Testfälle)
• Traceability zwischen Anforderungen
  • Verfeinern, generalisieren oder ersetzen

• Textuelle Referenz und Hyperlinks
• Verfolgbarkeitsmatrixen
• Verfolgbarkeitsgraphen

Anforderungen x Anforderungen

Konten Artefakte (Quelle, Anforderunge, Komponente etc.)
Kanten Beziehungen

Es gibt verschieden Gründe, warum eine Anforderung sich im Laufe der Zeit verändern kann.  Die Stakeholder erlangen durch den REQ Prozess immer mehr Wissen über ein System. Es macht Sinn Zugriff auf alte Versionen der Anforderungen zu haben.

Semantisch. Kleine Änderung 0.x, Grosse Änderung x.0

Eine Konfiguration von Anforderungen umfasst eine Menge von Anforderungen (jeweils eine spezifische Version)

• Sachologischer Zusammenhang
  • Zweckgerichtet
• Konsistenz
  • Widerspruchsfrei
• Eindeutige Identifikation
  • Eine Konfiguration besitzt eine ID
• Nicht veränderbar
  • Unveränderlicher Zustand der Anforderungsbasis

Eine Gruppe von Anforderungskonfigurationen.

• Grundlage für den Release
  • Für Kunden sichtbar
• Abschätzen des Realisierungsaufwandes eines Releases
• Vergleich mit Konkurrenz

Werden Änderungen für Anforderungen beantragt, so müssen diese vom CCB abgenommen werden. Diese evaluieren folgende Punkte:

• Aufwand der Änderung
• Verhältnis Aufwand Nutzen
• Definition der neuen Anforderung
• Entscheide Annahme /Ablehnung
• Klassifikation eingehender Änderungsanträge
• Priorisierung von angenommen Änderungen

• Änderungsmanager (Cheffe)
• Auftraggeber
• Architekt
• Entwickler
• Konfigurationsmanager (SCRUM Master)
• Kundenvertreter
• Nutzervertreter
• Produktmanager
• Qualitätsbeauftragter
• Requirements Engineer

• Identifikator       R-4
• Titel                      
• Beschreibung
• Begründung
• Datum
• Antragsteller
• Priorität aus der Sicht des Antragsstellers

• Korrektive Anforderungsänderung
  • Fehlverhalten des Systems wegen Anforderung
• Adaptive Anforderungsänderung
  • Anpassung des Systemes
• Ausnahmeänderung (Hotfix)
  • Unbedingt und unmittelbar umzusetzen

• Prozessmetrik z.B, Änderungsrate von Anforderungen
• Produktmetrik z.B. Fehler in Anforderungen

Werden Testfälle, Änderungsanträge oder Anforderungen in Systeme gepflegt mit denen die verschiedenen Teams arbeiten, so gibt das die Möglichkeit dies besser zu verknüpfen. Diese Systeme sollten dann mit Schnittstellen verknüpft werden.

Syntaktische Validation

• Verwaltung verschieden Informationen (Sprache, Bilder, Skizzen etc.)
• Veralten von logischen Beziehungen
• Eindeutige Identifizierbarkeit
• Multiuser und Accesscontrol
• Organisieren => Gruppieren, Hierarchiebildung Attribuierung etc.)
• Reports
• Versionierung

• Vorteile
  • Jeder kennt es
  • Jeder hat es
• Nachteile
  • Versionierung
  • Traceability

• Projektsicht
  • Wie stark unterstützt das Werkzeug die Projektvorbereitung, Planung und Durchführung.
• Benutzersicht
  • Wie gut lassen sich Benutzer verwalten. Und wie gut ist es bedienbar?
• Produktsicht
  • Was hat es für Funktionen? z.B, Dokumentationsformen für Anforderungen oder Dokumenttypen
• Prozesssicht
  • Methodische Untersetzung und wie ist die traceability?
• Anbietersicht
  • Welcher Hersteller? Sollte kein Nischenprodukt sein
• Technische Sicht
  • Skalierbarkeit, Performance, Hardwareanforderungen
• Betriebswirtschaftliche Sicht
  • Was sind die Kosten der Beschaffung, Einführbarkeit und Wartung

Eine Anforderung ist:

• Eine Voraussetzung des Benutzers ein Problem zu lösen oder sein Ziel zu erreichen
• Eine Voraussetzung an das System um einen Vertrag, eine Norm oder sonst ein formelles Dokument zu erfüllen
• Eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft gemäss (1) oder (2)

Ein Stakeholder eines Systems ist eine Person oder Organisation, die (direkt oder indirekt) Einfluss auf die Anforderungen des betrachteten Systems hat.

Das REQ hat die Aufgabe, die Anforderungen der Stakeholder zu ermitteln, zweckmässig zu dokumentieren, zu überprüfen und abzustimmen, sowie die dokumentierten Anforderungen zu verwalten.

Ermitteln => Dokumentieren = Prüfen und abstimmen => Verwalten

Analtisches Denken => Komplexe Sachverhalte verstehen

Empathie => Gruppendynamische Probleme von Stakeholder lösen

Kommunikationsfähigkeit => Richtig interpretieren und kommunizieren

Konfliktlösungsfähigkeit

Moderationsfähigkeit => Meetings moderieren

Selbstbeweustsein => Im Zentrum, also auch Zentrum der Kritik

Überzeugunsfähigkeit => 

Eine funktionale Anforderung ist eine Anforderung bezüglich des Verhaltens, das von einer Funktion des Systems bereitstellt werden soll.

Eine Qualitätsanforderung ist eine Anforderung die sich auf ein Qualitätsmerkmal bezieht, das nicht durch funktionale Anforderungen abgedeckt wird.

Performance, Verfügbarkeit, Zuverlässigkeit, Skalierbarkeit und Portabilität.

Oft zu wenig genau dokumentiert => die Akzeptanz des Systems leidet.

Klassen:

Performanz, Sicherheit Zuverlässigkeit Benutzbarkeit Änderbarkeit Übertragbarkeit

Beispiel:

95% aller Anfragen in weniger als 1.5 Sekunden

Randbedingungen werden, im Gegensatz zu funktionalen Anforderungen und QA nicht umgesetzt, sondern schränken die Umsetzungsmöglichkeiten ein.

Das System wird mit WebServices realisiert.

Das System muss bis 1.1.10 auf dem Markt sein.

Der Systemkontext ist der Teil der Umgebung eines Systems, der für die Definition und das Verständnis der Anforderungen des betrachteten Systems relevant ist. Er ist der Teil der Realität, der einen Einfluss auf das zu entwickelnde System hat und damit auch die Anforderungen an das zu entwickelnde System bestimmt.

Personen (Stakeholder/Gruppen)
Systeme im Betrieb
Prozesse
Ereignisse
Dokumente (Gesetzte, Standards)

Der Ursprung der Anforderungen eines Systems liegt im Systemkontext.

Systemabgrenzung => Welche Aspekte werden durch das System abgedeckt

Kontextabgrenzung =>

Innerhalb Die Aspekte welche eine Beziehung zum System haben

Ausserhalb: Die Irrelevanten Teile der Umgebung

Die Systemgrenze separiert das geplante System von seiner Umgebung. Durch die Wahl der Systemgrenze wird festgelegt, welche Aspekte das System abdeckt (Scope) und was ausserhalb des Systems liegt.

Systemgrenzen können sich im Verlaufe des REQ verändern. Manchmal ist noch nicht klar was alles vom System gemacht werden muss. Diese können sich auch verschieben.

Die Kontextgrenze separiert den relevanten Teil der Umgebung vom irrelevanten Teil. D.h.dem Teil der Umgebung, der keinen Einfluss auf das geplante System und damit auch keinen Einfluss auf die Anforderungen haben . 

Oft mit Use Case Diagrammen oder Datenflussdiagrammen.

Stakeholder
Dokumente
Systeme in Betrieb

Eine Tabelle mit Name Funktion Kontaktdaten, zeitliche und räumliche Verfügbarkeit Relevanz des Stakeholders seine Ziele und Interessen.

Um Missverständnisse oder Kompetenzstreitigkeiten vorzubeugen, muss der REQ Engineer mit jedem Stakeholder formal vereinbaren, welche Aufgaben, Verantwortungsbereiche, Weisungsbefugnisse und individuellen Zielen bestehen. Ebenfalls welche Kommunikationswege und Feedback-Schleifen von dem Stakeholder genutzt werden können.

Basisfaktoren => selbstverständliche Systemmerkmale
Leistungsfaktoren => explizit gefordert
Begeisterungsfaktoren => Systemmerkmale die erst während der Benutzung als angenehm und nützlich empfunden werden

Im Laufe der Zeit werden aus Begeisterungsfaktoren Leistungsfaktoren und dann Basisfaktoren. Der Benutzer gewöhnt sich an das Feature.

Diese Faktoren muss das System zwingend erfüllen. Werden diese nicht erfüllt so führt dies zu starker Unzufriedenheit.  Werden sie erfüllt führt dies noch nicht zur Zufriedenheit. Massgeben dafür sind Systeme welche bereits im Betrieb sind.

Leistungsfaktoren sind die Merkmale, die der Stakeholder bewusst und explizit fordert. Die Erfüllung dieser Merkmale erzeugt beim Kunden Zufriedenheit. Befragungstechniken eignen sich gut für Erhebung von Leistungsfaktoren