Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

IT SERVICES IT SERVICES, Guideline Requirements Engineering.

Ähnliche Präsentationen


Präsentation zum Thema: "IT SERVICES IT SERVICES, Guideline Requirements Engineering."—  Präsentation transkript:

1 IT SERVICES IT SERVICES, Guideline Requirements Engineering

2 IT SERVICES Seite2 Überblick Guideline Requirements Engineering

3 IT SERVICES Seite3 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 IT SERVICES Seite4 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 IT SERVICES Seite5 Überblick Guideline Requirements Engineering

6 IT SERVICES Seite6 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 IT SERVICES Seite7 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 Auftrags- verwaltung Stakeholder Rechnung Auftragsstornierung Lager Lieferauftrag Lieferbestätigung Lieferstornierung Zahlung Bestellung

8 IT SERVICES Seite8 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 IT SERVICES Seite9 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 IT SERVICES Seite10 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 IT SERVICES Seite11 Überblick Guideline Requirements Engineering

12 IT SERVICES Seite12 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: a)mindestens ein Auslöser, der auf das System einwirkt und die Funktion auslöst, b)eine Vorbedingung, die erfüllt sein muss, während eines der zugelassenen Ereignisse eintritt, und c)eine Machbedingung, die beobachtbaren Ergebnisse der Funktion. Genaue englische Entsprechung: functional requirement (Glossar: CRE)

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

14 IT SERVICES Seite14 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 Benutzte System-schnitt- stelle 2 Produkt Bereitgestellte System-schnitt- stelle 1 Bereitgestellte System-schnitt- stelle 2 System C System D Subsystemn Benutzerverwaltung 8000 Stammdatenverwaltung 9000

15 IT SERVICES Seite15 … der Use-Cases/Anwendungsfälle 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 IT SERVICES Seite16 Worauf kommt es dabei an? Use-Cases/Anwendungsfälle 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 IT SERVICES Seite17 Attribute –repräsentieren Wissen des Systems und –beschreiben Eigenschaften der Fachklassen. Ziel: Wichtige fachliche Datenaspekte modellieren. Person - Name - Adresse

18 IT SERVICES Seite18 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 Bus Fahrgast transportiert

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

20 IT SERVICES Seite20 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 RechteckKreis GeoFigur Dreieck

21 IT SERVICES Seite21 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 IT SERVICES Seite22 Beispiel - Anwendungsdiagramm Mögliche Techniken für Anforderungsspezifikation: –Objektorientierte Analyse und UML-Modellierung, z.B. UML-Anwendungsdiagramm (use cases)

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

24 IT SERVICES Seite24 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 IT SERVICES Seite25 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 IT SERVICES Seite26 Anwendungsfälle erheben (4/5): Use Cases - Begriffe BegriffDefinition / Erklärung AkteurJemand oder etwas mit Verhalten BeteiligterJemand oder etwas mit einem Interesse am Verhalten des betroffenen Systems HauptakteurDer Beteiligte der die Interaktion mit dem System auslöst, um sein Ziel zu erreichen Use-CaseEin Vertrag über das Verhalten des Systems. (Auch: Anwendungsfall) Umfang / ScopeIdentifiziert das betroffene System Vorbedingungen und Garantien Was muss vor und nach dem Ablauf des Use- Cases erfüllt oder wahr sein? ErfolgsszenarioDer Fall, in dem nichts fehlschlägt (sondern alles glatt geht) Erweiterung, AlternativenWas kann in diesem Szenario anders ablaufen?

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

28 IT SERVICES Seite28 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 IT SERVICES Seite29 Beispiel FRIEND FRIEND – ein verteiltes Informationssystem für Unfallmanagement

30 IT SERVICES Seite30 Arten von Szenarien Ist-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 IT SERVICES Seite31 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 IT SERVICES Seite32 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 IT SERVICES Seite33 Beispiel für einen Anwendungsfall für FRIEND (1/2)

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

35 IT SERVICES Seite35 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 IT SERVICES Seite36 Testfälle vorbereiten (2/2) - Beispiel SchrittAktivität 2Anzeige 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 SchrittTestkriterien 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 … … 2 Es werden folgende Detailinformationen angezeigt: … 3

37 IT SERVICES Seite37 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 IT SERVICES Seite38 Definition, Sinn und Zweck Abnahmekriterien 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). 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.

39 IT SERVICES Seite39 Überblick Guideline Requirements Engineering

40 IT SERVICES Seite40 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 IT SERVICES Seite41 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 IT SERVICES Seite42 Überblick Guideline Requirements Engineering

43 IT SERVICES Seite43 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 IT SERVICES Seite44 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 IT SERVICES Seite45 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?


Herunterladen ppt "IT SERVICES IT SERVICES, Guideline Requirements Engineering."

Ähnliche Präsentationen


Google-Anzeigen