Guideline Requirements Engineering

Präsentation zum Thema: "Guideline Requirements Engineering"—  Präsentation transkript:

1 Guideline Requirements Engineering
IT SERVICES,

2 Überblick Guideline Requirements Engineering

3 Requirements Engineering initialisieren (1/2)
Ziel des Arbeitsschrittes Eindeutige Eingrenzung der Aufgabenstellung anhand des freigegebenen Project Scope Statements Ergebnis des Arbeitsschrittes Kontext, Historie, Anstoß und Ziele des Vorhabens Aufgabenstellung und Abgrenzung des Projektes

4 Requirements Engineering initialisieren (2/2)
Best Practices Zusammenstellung eines Teams für das Requirements Engineering, das die gesamte Brandbreite des Projekt Scopes abdeckt Aufbauend auf Projekt Scope und der WBS Requirements Engineering Pakete definieren (z. B. Abteilungen, Prozesse, Personengruppen) Scope Review durch Projektleiter, QSV, Architekt mit dem Stakeholdern Spätere Verwendung der Pakete bei der Definition von Subsystemen und Use Cases

5 Überblick Guideline Requirements Engineering

6 Stakeholder identifizieren
Ziel des Arbeitsschrittes Identifikation der vom IT-Vorhaben betroffenen und beteiligten Individuen und Gruppen als Quelle für Anforderungen Untersuchung unterschiedlicher Sichtweisen auf das System Ergebnis des Arbeitsschrittes Best Practices Interviews mit Verwendern des IT-Systems (Anwender/Benutzer) und Personen mit Interessen am Produkt (Interessenvertreter/Stakeholder) Ggfs. erste grobe Geschäftsprozessmodellierung

7 Geschäftsprozesse abgrenzen
Ziel des Arbeitsschrittes Abgrenzung des für das IT-Vorhaben relevante Geschäftsprozesses inklusive der wichtigsten Beteiligten sowie der relevanten Eingangs- und Ausgangsdokumente Was muss das System „wissen“, um den fachlichen Ablauf des Auftraggebers abzubilden? Ergebnis des Arbeitsschrittes Best Practices Datenfluss- bzw. Kontext- oder UML-Diagramme Kontext, Beziehungen, Beteiligte, Schnittstellen und bereitgestellte bzw. benötigte Informationen ermitteln und aufzeigen Bestellung Stakeholder Lieferauftrag Lager Auftragsstornierung Auftrags-verwaltung Lieferstornierung Rechnung Lieferbestätigung Zahlung

8 Der Inhalt des Glossars
Alle „erklärungsbedürftigen“ Substantive des Fachbereichs. Alle „erklärungsbedürftigen“ Verb-/Prozessworte. Alle Hilfsverben für die juristische Verbindlichkeit (muss, sollte, wird, shall, should, will, …). Zudem: Abkürzungen und Akronyme, Beispiele und Gegenbeispiele, verwandte Begriffe/Synonyme, Beziehungen zu anderen Begriffen, evtl. Trennung Kurz- und Langbeschreibung.

9 Hinweise zur Vorgehensweise
Sammeln sie zuerst alles über den zu definierenden Begriff aus allen verfügbaren Quellen! Schreiben Sie danach die Definition, die den Begriff im Zusammenhang mit der Anwendung erklärt (d.h. keine allgemeinen Lexika erstellen, sondern den Zweck des Begriffes für das System!). Bei Unklarheiten: Sprechen Sie mit den Beteiligten! Stimmen Sie alle Begriffe mit den Stakeholdern ab! Passen Sie die Anforderungen an die nun definierten und ab jetzt verbindlich zu verwendenden Begriffe an. Ein Glossar ist verpflichtend! Ein Glossar kann in einer beliebigen Notation erstellt werden – Ziel ist Klarheit und Verstehbarkeit! Jeder muss Zugang zum Glossar haben. Jemand muss sich für das Glossar verantwortlich fühlen. Ein Glossar muss konsistent sein – dafür lieber mal auf absolute Aktualität und Vollständigkeit verzichten.

10 Beispiel eines Glossar
Ziel des Arbeitsschrittes Einheitliches Verständnis zwischen allen Beteiligten ein über die zentralen Fachtermini Ergebnis des Arbeitsschrittes Best Practices Glossar mit Definitionen der für das Projekt zentralen Fachbegriffe Erstellung und Pflege des Glossars während des gesamten Projektes

11 Überblick Guideline Requirements Engineering

12 Definition: funktionale Anforderung
Variante 1: Spezifikation der geforderten Reaktion eines Systems auf einen externen Auslöser, der in einem bestimmten Zustand des Systems auftritt; der Auslöser trägt in der Regel Daten an das System heran. Variante 2: Eine funktionale Anforderung beschreibt aus Black-Box-Sicht das zielgerichtete Verhalten eines Systems mit mindestens folgenden Angaben: mindestens ein Auslöser, der auf das System einwirkt und die Funktion auslöst, eine Vorbedingung, die erfüllt sein muss, während eines der zugelassenen Ereignisse eintritt, und eine Machbedingung, die beobachtbaren Ergebnisse der Funktion. Genaue englische Entsprechung: functional requirement (Glossar: CRE)

13 Kategorien von funktionalen Anforderungen
Anforderung an Funktion/Verhalten des Systems Daten Funktionale Anforderung Dokumentiert als: Use Case Szenario StateChart … Glossar-Eintrag Entity-Relationship- Modell Fachklassenmodell

14 IT-System abgrenzen und strukturieren
Ziel des Arbeitsschrittes Überblick über die grobe fachliche Struktur des Systems (Zerlegung in Subsysteme) Ergebnis des Arbeitsschrittes Best Practices Welche Systemschnittstellen muss das Produkt nutzen, um die benötigten Informationen zu erhalten? Welche Systemschnittstellen muss das Produkt für andere Systeme bereitstellen, um die Informationen zu liefern? System A Benutzte System-schnitt- stelle 1 System B System-schnitt- stelle 2 Produkt <Systemname> Bereitgestellte System-schnitt- stelle 1 System C System D Subsystemn 1 1000 Benutzerverwaltung 8000 Stammdatenverwaltung 9000

15 Anwendungsfälle… … der Use-Cases/Anwendungsfälle
Anwendungsfälle können… eine IST-Situation beschreiben (Ist-Anwendungsfälle), einen SOLL-Zustand beschreiben (Soll-Anwendungsfälle), eine Essenz beschreiben (Essenzielle Anwendungsfälle), den fachlichen Kontext beschreiben, d.h. die Einbettung des zu entwickelnden Systems in die gegebene Umwelt, nur die durch Software zu unterstützenden Sachverhalte beschreiben („System-Anwendungsfälle“), auch außerhalb der Software allgemeine geschäftliche Anwendungsfälle darstellen („Geschäfts-Anwendungsfälle“).

16 Use-Cases/Anwendungsfälle
Worauf kommt es dabei an? Anwendungsfälle eignen sich nicht zur funktionalen Zerlegung des Systems (d.h. keine Top-Down-Zerlegung). Ein Andwendungsfalldiagramm ist keine Ablaufbeschreibung. Es wird keine Ablaufreihenfolge u.ä. definiert. Hierzu gibt es andere Ausdrucksmittel, z. B. Aktivitätsdiagramme. Anwendungsfälle belassen das Sprachmonopol beim Stakeholder, wodurch sie angreifbarer und kritisierbarer werden.

17 Attribute Attribute repräsentieren Wissen des Systems und
beschreiben Eigenschaften der Fachklassen. Ziel: Wichtige fachliche Datenaspekte modellieren. Person - Name - Adresse

18 Beziehungen Beziehungen/Assoziationen
repräsentieren Zusammenhänge zwischen Fachklassen und modellieren dauerhafte Zusammenhänge. Ziel: Übersicht wesentlicher Beziehungen. Nicht zu viele Beziehungen modellieren, für das Verständnis wichtige Beziehungen modellieren und redundante Beziehungen vermeiden. 0..60 0..1 Bus Fahrgast transportiert

19 Beziehungen Assoziation/Aggregation/Komposition Bus Fahrgast
0..60 0..1 Bus Fahrgast Assoziation 0..30 0..1 Zug Wagon Aggregation 3..* 1..* Verein Mitglied Komposition Assoziationen: allgemeine Beziehungen zwischen Objekten. Aggregationen: Teil-Ganzes-Beziehungen. Kompositionen: Teil-Ganzes-Beziehungen, bei denen ein Teilobjekt ohne das Ganze keinen Sinn macht.

20 Vererbung Fachklassen Generalisierte/spezialisiere Fachkonzepte
Gemeinsamkeiten von Fachklassen werden abstrahiert (abstrahierte und spezialisierte Fachklassen). Stellt eine besondere Art der Beziehung zwischen fachlichen Konzepten/Begriffen dar. Kann im weitern Projektverlauf als Basis für Vererbungsstrukturen genutzt werden. Unterklasse Oberklasse Rechteck Kreis GeoFigur Dreieck

21 Anwendungsfälle erheben (1/5)
Ziel des Arbeitsschrittes Zu jedem identifizierten Subsystem werden Anwendungsfälle (engl. use cases) gesammelt Anwendungsfälle sollen verdeutlichen, was das System leisten soll Ergebnis des Arbeitsschrittes Anwendungsfälle je Subsystem als Überblick  siehe nebenstehendes Anwendungsfalldiagramm Spezifikation je Anwendungsfall  siehe folgendes Template Best Practices Übung Stake-holder [1] Status abfragen [2] Bestellung veranlassen [3] Versanddaten ausfüllen Verkäufer Sachbearbeiter Buchungen

22 Beispiel - Anwendungsdiagramm
Mögliche Techniken für Anforderungsspezifikation: Objektorientierte Analyse und UML-Modellierung, z.B. UML-Anwendungsdiagramm (use cases)

23 Beispiel - Sequenzdiagramm
Mögliche Techniken für Anforderungsspezifikation: Objektorientierte Analyse und UML-Modellierung, z.B. UML-Sequenzdiagramm (sequence diagram)

24 Allgemeine Systemanforderungen
Anwendungsfälle erheben (2/5): Use-Cases im Kontext der Systemanforderungen Allgemeine Systemanforderungen Zweck und Umfang des Systems (Scope) Was ist der Umfang? Was ist das Ziel? Wer ist beteiligt? Was ist drin, was ist draußen? Use-Cases (Anwendungsfälle) Die primären Akteure und ihre Ziele Die Use-Cases der Geschäftsebene Die System-Use-Cases Rahmenbedingungen Technische Einsatzumgebung Organisatorische Einsatzumgebung Schnittstellen Andere Anforderungen Performance Sicherheit Benutzbarkeit, Ergonomie Entwicklungsprozess Geschäftsregeln Nach hinten verschobene, künftige Anforderungen Sonstige (politische, organisatorische, juristische, …) Aspekte

25 Anwendungsfälle erheben (3/5): Use-Case definieren einen Vertrag
Ein Use-Case … ist die Beschreibung einer Folge von Aktivitäten (eventuell mit Varianten), die das System ausführt, um ein beobachtbares Ergebnis für einen Akteur zu erzeugen, das diesem einen Mehrwert liefert. … beschreibt einen Vertrag zwischen Beteiligtem (Stakeholder) eines Systems über dessen Verhalten unter verschiedenen Bedingungen.

26 Anwendungsfälle erheben (4/5): Use Cases - Begriffe
Definition / Erklärung Akteur Jemand oder etwas mit Verhalten Beteiligter Jemand oder etwas mit einem Interesse am Verhalten des betroffenen Systems Hauptakteur Der Beteiligte der die Interaktion mit dem System auslöst, um sein Ziel zu erreichen Use-Case Ein Vertrag über das Verhalten des Systems. (Auch: Anwendungsfall) Umfang / Scope Identifiziert das betroffene System Vorbedingungen und Garantien Was muss vor und nach dem Ablauf des Use- Cases erfüllt oder wahr sein? Erfolgsszenario Der Fall, in dem nichts fehlschlägt (sondern alles „glatt“ geht) Erweiterung, Alternativen Was kann in diesem Szenario anders ablaufen?

27 Anwendungsfälle erheben (5/5): Template: Use-Cases

28 Szenarien zur Systembeschreibung
Nach Caroll Ein Szenario ist die erzählende Beschreibung dessen, was Leute beim Versuch, Rechnersysteme und deren Anwendungen zu nutzen, tun und erleben. Brügge, Dutoit: Ein Szenario... ist konkret, fokussiert, informell beschreibt ein einzelnes Systemmerkmal beschreibt aus Sicht eines einzelnen Akteurs enthält keine Verallgemeinerungen, keine Fallunterscheidungen (dafür werden mehrere Szenarien benötigt!) Verständlichkeit für einzelne Nutzer / Stakeholder

29 Beispiel FRIEND FRIEND – ein verteiltes Informationssystem für Unfallmanagement

30 Arten von Szenarien Ist-Szenarien Visionäre Szenarien
beschreiben die gegenwärtige Situation zum Beispiel, um es gegen zukünftige Anforderungen abzugrenzen Visionäre Szenarien beschreiben ein künftiges System  Kommunikationsmedium, "preiswerter Prototyp“ Bewertungsszenarien dienen der (späteren) Evaluierung des Systems  Status-Bewertung, Usability, Akzeptanztest Übungsszenarien werden zur Einarbeitung neuer Anwender genutzt  Schritt-für-Schritt-Anleitung

31 Ziel der Szenario-Entwicklung
Anwender / Kunden und Software-Entwickler sollen ein gemeinsames Verständnis der Anwendungsdomäne, des Systemumfangs und der zu unterstützenden Arbeitsprozesse entwickeln Nächster Schritt: Szenarien verallgemeinern, Anwendungsfälle aus den Szenarien entwickeln

32 Anwendungsfälle zur Systembeschreibung
Ein Szenario ist eine Instanz eines Anwendungsfalls  Wenn der Anwendungsfall für eine gegebene Funktionalität identifiziert ist, sind damit alle möglichen Szenarien für diese Funktionalität beschrieben Alle bisherigen Szenarien beschäftigen sich mit der Meldung von Notfällen  Verallgemeinern / Abstrahiere zu einem (einzigen) Anwendungsfall "MeldeNotfall" Ein Anwendungsfall wird immer von einem Akteur initiiert

33 Beispiel für einen Anwendungsfall für FRIEND (1/2)

34 Beispiel für einen Anwendungsfall für FRIEND (2/2)

35 Testfälle vorbereiten (1/2)
Ziel des Arbeitsschrittes Zu jedem Anwendungsfall sind Testkriterien zu definieren, die das System erfüllen muss, um als akzeptabel betrachtet zu werden Die Anforderungen werden mit dem Festlegen der Abnahmekriterien messbar Ergebnis des Arbeitsschrittes Testkriterien für jeden Anwendungsfall (siehe nachfolgendes Beispiel) Best Practices Für jede Aktivität innerhalb eines Anwendungsfalls mindestens ein Testkriterium aufschreiben Testkriterien müssen in der Form „erfüllt“ „nicht-erfüllt“ überprüfbar sein. Unscharfe Aussagen sollten daher vermieden werden Überlegen Sie bei der Formulierung von Testkriterien, wie diese später überprüft werden können (Anzeige von Informationen? Welche im einzelnen?) Überlegen Sie auch, ob das System die formulierten Testkriterien überhaupt erfüllen kann

36 Testfälle vorbereiten (2/2) - Beispiel
Schritt Aktivität 2 Anzeige aller offenen Wareneingangspositionen. Es werden alle gefundenen Wareneingangspositionen in einer Liste angezeigt. Die Liste enthält folgende Attribute: … Entscheidung, ob in die Detailansicht zu einer Warenposition gewechselt werden soll: Detailinformationen anzeigen: Weiter mit Schritt 3 Keine Detailinformationen anzeigen: Weiter mit Schritt 4 Testkriterien Es wird eine Liste mit allen offenen Wareneingangspositionen in der Maske gemäß den in Schritt 1 definierten Suchkriterien angezeigt. 3 Die Details zur ausgewählten Warenposition können angezeigt werden. Die Kopfdaten der Bestellung werden angezeigt. Ist ein Fehler beim Transferieren der Buchungsdaten aufgetreten, wird dieser optional angezeigt. Akteur Es werden folgende Detailinformationen angezeigt:

37 Geschäftsobjekte/Daten modellieren
Ziel des Arbeitsschrittes Welche Daten müssen über das IT-System gespeichert werden? Sind entsprechende IT-Funktionen für das Einfügen, Mutieren und Abfragen dieser Daten bereits definiert oder muss das Use-Case-Diagramm ergänzt werden? Ergebnis des Arbeitsschrittes Best Practices Identifikation von Geschäftsobjekten bzw. -klassen Kategorisierung Textanalyse Beziehungen zwischen Geschäftsobjekten ermitteln Assoziationen auffinden Aggregationen bestimmen Generalisieren/Spezialisieren

38 Abnahmekriterien Definition, Sinn und Zweck
Ein Abnahmekriterium (AK) ist eine Anweisung für den Test bezüglich einer Anforderung (oder eines Anforderungsteils), welche die Prüfung und Bewertung des erstellten Produkts oder durchgeführten Prozesses gegenüber dieser Anforderung (oder des Teils) beschreibt. Abnahmekriterien: Sind Testrahmen zum Prüfen der Einhaltung von Anforderungen (Verifikation des Produkts). Sind ein wichtiges Hilfsmittel zur Qualitätssicherung von Anforderungen (Prüfen der Vollständigkeit und Testbarkeit von Anforderungen). Sollten vom Requirements Engineer erstellt werden (nicht vom Tester). Sind in der Analysephase zu jeder Anforderung zu formulieren. Sind Grundlage einer SW-Abnahme. Sind Bestandteil eines Vertrages. Werden unterschieden nach Art (formal/natürlichsprachlich, abstrakt/konkret).

39 Überblick Guideline Requirements Engineering

40 Benutzerschnittstelle spezifizieren
Ziel des Arbeitsschrittes Gestaltung der Schnittstelle zwischen Benutzer und Softwaresystem Ergebnis des Arbeitsschrittes Menüstruktur Anforderungen an Masken Best Practices Basis der Modellierung der Benutzungsschnittstelle ist die Liste der Anwendungsfälle Hilfsmittel sind Skizzen, Prototypen, User Interface Guidelines und Storyboard Checkliste der Guideline enthält wichtige Fragestellungen, die bei der Gestaltung der Benutzerschnittstelle zu beachten sind

41 System- und Datenschnittstelle spezifizieren
Ziel des Arbeitsschrittes Beschreibung aller neu zu entwickelnder bzw. zu ändernder Schnittstellen (Daten- und Systemschnittstellen) Ergebnis des Arbeitsschrittes Best Practices Zu jeder definierten Systemschnittstelle ist zu prüfen, ob Anforderungen bzgl. der Umsetzung vorliegen und zu berücksichtigen sind Checkliste liefert mögliche weitere Anforderungen an Schnittstellen

42 Überblick Guideline Requirements Engineering

43 Definition: nicht-funktionale Anforderungen
Nicht-funktionale Anforderungen sind alle Anforderungen, die nicht funktional sind. Beispiel: Alle Eingabefelder des Systems sollen blau sein. Das System soll alle Funktionen der Klasse 2 innerhalb einer Sekunde ausgeführt haben. Der Auftragnehmer hat für Tee und Kuchen bei Besprechungen zu sorgen. (Glossar: CRE)

44 Nichtfunktionale Anforderungen spezifizieren (1/2)
Ziel des Arbeitsschrittes Spezifikation der abgeleiteten Nichtfunktionalen Anforderungen an das zu entwickelnde / bestehende System Ergebnis des Arbeitsschrittes Qualitätsanforderungen Gesetzliche Anforderungen und Randbedingungen Technische Anforderungen und Randbedingungen Unternehmens-/Erstellungsprozessanforderungen Best Practices Als Hilfestellung zur vollständigen Erfassung dienen die Checkliste “Nichtfunktionale Anforderungen“ der Guideline Die Anforderungen sind in natürlich sprachlicher Form zu beschreiben Dabei ist zu beachten, dass die Anforderungen messbar sind. Adjektive (einfach, schnell etc.) sind zu quantifizieren Analog zu den funktionalen Anforderungen ist hier ebenfalls die Definition von Testkriterien sinnvoll

45 Nichtfunktionale Anforderungen spezifizieren (2/2)
Checklisten geben Hilfestellungen bei der Erhebung der nichtfunktionalen Anforderungen beim Stakeholder Beispiel: Kapazitätsanforderungen (Mengengerüst) Wie viele Benutzer sollen mit dem System gleichzeitig arbeiten? Von welchen Standorten arbeiten wie viele Benutzer? Wie oft werden die einzelnen Anwendungsfälle voraussichtlich stattfinden? Wie sieht die zeitliche Verteilung (über den Tag, die Woche, den Monat und über das Jahr gesehen) wahrscheinlich aus? (Gleichmäßige Verteilung oder saisonale Schwankungen) Müssen Geschäftsobjekte über mehrere Jahre aufbewahrt werden? Wie groß ist das zu erwartende Datenvolumen? Welche Datenübertragungskapazitäten werden benötigt?