Guideline Requirements Engineering IT SERVICES,

Überblick Guideline Requirements Engineering

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

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

Überblick Guideline Requirements Engineering

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

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

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.

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.

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

Überblick Guideline Requirements Engineering

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)

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

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

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“).

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.

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

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

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.

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

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

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

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

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

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.

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?

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

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

Beispiel FRIEND FRIEND – ein verteiltes Informationssystem für Unfallmanagement

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

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

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

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

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

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

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:

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

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).

Überblick Guideline Requirements Engineering

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

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

Überblick Guideline Requirements Engineering

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)

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

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?