V2 Anforderungsanalyse und Spezfikation Definitionen Anforderungen (requirements): legen fest, was man von einem Softwaresystem als Eigenschaften erwartet Funktionale Anforderung: Was soll ein System tun Beschreibung der Funktionen/Services, die das Softwaresystem oder eine seiner Komponenten bereitstellen soll. Gibt an wie das System auf bestimmte Eingaben und spezielle Situationen reagiert. Nicht funktionale Anforderung: Wie gut bzw. wie regelkonform werden die Funktionen erledigt. übergreifende Anforderungen, z.b. bzgl. der Qualitätseigenschaften, den Entwicklungsprozess, Standards, Normen oder gesetzlichen Regeln. Modell: Idealisierte, vereinfachte, in gewisser Hinsicht ähnliche Darstellung eines Gegenstands, Systems oder sonstigen Weltausschnitts mit dem Ziel, daran bestimmte Eigenschaften des Vorbilds besser studieren zu können. Anwendungsmodell: Modell, das sich auf einen Weltausschnitt bezieht, der Gegenstandsbereich einer Software-Anwendung ist. Lastenheft: WAS & WOFÜR [VDI 2519]: Zusammenstellung aller Anforderungen des Auftraggebers hinsichtlich Liefer- und Leistungsumfang. Im Lastenheft sind die Anforderungen aus Anwendersicht einschließlich aller Randbedingungen zu beschreiben. Diese sollen quantifizierbar und prüfbar sein. Im Lastenheft wird definiert WAS und WOFÜR zu lösen ist. Das Lastenheft wird vom Auftraggeber oder in dessen Auftrag erstellt. Es dient als Ausschreibungs-, Angebots und / oder Vertragsgrundlage. [DIN69905]: Vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrags Pflichtenheft: WIE & WOMIT [VDI 2519]: Beschreibung der Realisierung aller Anforderungen des Lastenheftes. Das Pflichtenheft enthält das Lastenheft. Im Pflichtenheft werden die Anwendervorgaben detailliert und die Realisierungsanforderungen beschrieben. Im Pflichtenheft wird definiert, WIE und WOMIT die Anforderungen zu realisieren sind. [...] Das Pflichtenheft wird in der Regel nach Auftragserteilung vom Auftragnehmer erstellt, falls erforderlich unter Mitwirkung des Auftraggebers. Der Auftragnehmer prüft bei der Erstellung des Pflichtenhefts die Widerspruchsfreiheit und Realisierbarkeit der im Lastenheft genannten Anforderungen. Das Pflichtenheft bedarf der Genehmigung durch den Auftraggeber. [DIN69905]: Vom Auftragnehmer erarbeitete Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes.
1. grobe Phase der Software Entwicklung Prozess zur Anforderungserhebung: Wichtigsten Eigenschaften von Anforderungen: Bilden die Grundlage für jedes Software Projekt Vorgaben für Entwurf und Entwicklung Bilden die Basis s für Verifikation und Validierung Können abstrakt oder detailliert sein Anforderungen ändern sich während eines Prozesses Anforderungen / Requirements werden in folgenden Schritten erfasst: Anforderungen ermitteln Anforderungen analysieren Anforderungen validieren Ableitung einer fachlichen Lösung bzw. eines Produktmodell Bei der Ermittlung von Anforderungen gibt es immer die Kundensicht nsicht (Anforderungen) und Lieferantensicht (Fachliche Lösung). Die Schwierigkeit ist ein gemeinsames Bild von den Anforderungen n zu schaffen. Besondere Fallen sind: Unterschiedliche he Interpretation von Anforderungen Widersprüchliche he Anforderungen Weitere Vorgaben die primär nichts mit der Anforderung gemein haben (Gesetze) Risken im Requriement engineering: 1. Kunden sind im Projekt unzureichend repräsentiert 2. Kritische Anforderungen werden übersehen 3. Es werden nur funktionale Anforderungen berücksichtigt 4. Anforderungen werden unkontrolliert geändert 5. Anforderungen beschreiben den Entwurf 6. Anforderungen werden nicht auf Qualität geprüft
7. Anforderungen werden perfektionier Um Risiken zu minimieren können Maßnahmen in folgenden Bereichen getroffen werden: Prozess: Priorisierung, Nachverfolgungsmatrix, gem. Reviews. Wissen: Erfahrene PL und Teammitglieder, Kunden/User einbinden, Ressourcen: 15%-30% für RE, Anforderungsschablonen, Anforderungsanalyse Das Ergebnis der Anforderungsanalyse sind die Anforderungen. Bei der Anforderungsanalyse werden: Vision Was soll das System können? / welcher Business case hat das System? Scope Welchen Umfang hat das Projekt? Stakeholder / Anforderungsquellen Wer hat welche Rolle? Analysiert. Dabei geht es darum, die von den Stakeholdern benötigten Funktionen / Services eines Systems herzuleiten bzw. die Einschränkungen zu ermitteln. Methoden der Anforderungsanalyse Nicht strukturierte Methoden Zumeist natürlich sprachlich Semi-strukturierte Methoden natürlich sprachlich mit Vorlagen und eingeschränktem Vokabular Strukturierte Methoden Definierte Syntax, Notation oder formale Spezifikation. Anforderungen ermitteln Workshops Interviews Beobachtungen Mitarbeit Natürlichsprachliche Anforderungen Pro: einfach verständlich, Flexible und universell Contra: Syntaktisch und Symantisch Mehrdeutig, Vage Begriffe, Durch Erstellung eines Glossars oder Verwendung von Anforderungsschablonen können Missverständnis reduziert werden.
Use Cases Beschreiben was passiert. Definition von Szenarien Methode der Analyse UML-Anwendungsfall Diagramm User Stories Teil der Agilen Software Entwicklung Beschreibung der Szenarien in Kundenterminologie Feine Granularität Beinhaltet: Story / Abnahmetest / Prio/ Aufwand Pro: Gemseinsame sicht auf das System, fördern Kommunikation, Contra: Interpretierbar,starke Involvierung des Kunden Allg. Probleme bei der Anforderungsermittlung Verständlichkeit Selbstverständlichkeit Geringe Präzision Vermischung Zusammenführung Mehrdeutigkeit Überflexibilität (Unpräzise mehrdeutig) Anforderungen an Anforderungen nach IEEE 830 Korrekt Vollständig Konsistent und Eindeutig Notwendig Einheitlich dokumentiert Im Unfang angemessen Nach versch. Sichten auswertbar Atomar Abhängigkeiten verdeutlichen Nach- und Rückverfolgbar Nachprüfbar Erweiterbar Modifizierbar Klassifizierbar nach Wichtigkeit und Stabilität Baseline Die Basline definiert einen stabile Zwischensituation der Anforderungen. Nach dieser Baseline müssen Änderungen an den Anforderungen einen definierten Änderungsprozess durchlaufen.
Grobarchitektur Die Architektur bestimmt im wesentlichen die nicht funktionalen Einheiten eines System. Schnittstellenbeschreibung Definiert die Interoperabilität eines Systems. Modellierung von Anforderungen Vorrausetzung: Abgenommen Anforderungen Ziel: Findung einer fachlichen Lösung * UML: Unified Modeling Language - Strukturmodelle (Class, Package, Component, Deployment, Object, Composite Structure Diagram) - Verhaltensmodelle (UC, Activity, Communication, Interaction, Sequence- Diagram) * DSL: Domain Specific Language Anforderungsspezifikation Aufteilung der Anforderungen in Lasten- und Pflichtenheft Dokumentation Gliederung der Anforderungen Anforderungen priorisieren nach Wichtigkeit Wichtigkeit ist abhängig von der Perspektive (Nach Funktion, Nach Kosten, etc. ) Anforderungen können auch nach IEE830 priorisiert werden (Essentiell, bedingt notwendig, optional) Oder nach RFC 2119 (MUST, MUST NOT, SHOULD, SHOULD NOT, MAY) Anforderungsattribute Generell sollten Anforderungen Attribute besitzen welche die Eckdaten der Anforderungen genauer beschreiben. Identifikator Kurzbezeichnung der Anforderung (optional)
Anforderungstyp Beschreibung der Anforderung Anforderungssicht Querbezüge (optional) Status des Inhalts Abnahmekriterien Schlüsselwörter (optional) Priorität der Anforderung Stabilität der Anforderung Kritikalität der Anforderung Entwicklungsrisiko Aufwand Konflikte (optional) Autor Quelle Version und Änderungsbeschreibung Bearbeitungsstatus