it services it services, guideline requirements engineering

45
IT SERVICES IT SERVICES, Guideline Requirements Engineering

Upload: gitta-bodenschatz

Post on 05-Apr-2015

141 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICES

IT SERVICES,

Guideline Requirements Engineering

Page 2: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 2

Überblick Guideline Requirements Engineering

Projektauftrag

RequirementsEngineeringinitialisieren

Geschäfts-prozesse

analysieren

FunktionaleAnforderungen

analysieren

IT-System abgrenzen und strukturieren

Anwendungsfälle erheben

Testfälle vorbereiten

Geschäftsobjekte/Daten modellieren

NichtfunktionaleAnforderungen

analysieren

Qualitätsanforderungen bestimmen

Gesetzliche Anforderungen undRandbedingungen dokumentieren

Technische Anforderungen undRandbedingungen ermitteln

Unternehmens-/Erstellungsprozess-anforderungen erheben

Realisierung

Projektvorgaben klären

Scope Erstellung / Review

Schnittstellenanalysieren

Benutzerschnittstelle spezifizieren

System- und Datenschnittstellen spezifizieren

Interessengruppen identifizieren

Geschäftsprozesse abgrenzen

Katalog zu Fachbegriffen erstellen

Page 3: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 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

Page 4: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 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

Page 5: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 5

Überblick Guideline Requirements Engineering

Projektauftrag

RequirementsEngineeringinitialisieren

Geschäfts-prozesse

analysieren

FunktionaleAnforderungen

analysieren

IT-System abgrenzen und strukturieren

Anwendungsfälle erheben

Testfälle vorbereiten

Geschäftsobjekte/Daten modellieren

NichtfunktionaleAnforderungen

analysieren

Qualitätsanforderungen bestimmen

Gesetzliche Anforderungen undRandbedingungen dokumentieren

Technische Anforderungen undRandbedingungen ermitteln

Unternehmens-/Erstellungsprozess-anforderungen erheben

Realisierung

Projektvorgaben klären

Scope Erstellung / Review

Schnittstellenanalysieren

Benutzerschnittstelle spezifizieren

System- und Datenschnittstellen spezifizieren

Interessengruppen identifizieren

Geschäftsprozesse abgrenzen

Katalog zu Fachbegriffen erstellen

Page 6: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 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

Interessengruppe/ Stakeholder

Identifikation (Name, Abteilung, Rolle, Kontaktdaten)

Verfügbarkeit (Urlaub, Anteil Arbeitszeit für Projekt)

Wissensgebiet Priorität (kritisch, relevant, irrelevant)

Besondere funktionale Anforderungen

Besondere Nichtfunktionale Anforderungen

Hauptnutzer Herr Müller, Abt. IPC Tel. 2359 Email: [email protected]

Urlaub vom 2.7.04-23.7.04; 25% verfügbar

Arbeitet mit Altsystem, kennt Schwachstellen

Kritisch, da als Anwender auf das System angewiesen

Schnittstelle zu SAP HR

Einfache Eingabe von Massendaten

Page 7: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 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

Auftrags-verwaltung StakeholderRechnung

Auftragsstornierung

Lager

Lieferauftrag

Lieferbestätigung

Lieferstornierung

Zahlung

Bestellung

Page 8: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 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.

Page 9: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 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.

Page 10: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 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

Begriff Englische Bezeichnung Definition Quelle Kunde Customer Eingetragener Inhaber des

Telefonanschlusses Interview mit Herrn Meyer vom 2.4.2004

Page 11: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 11

Überblick Guideline Requirements Engineering

Projektauftrag

RequirementsEngineeringinitialisieren

Geschäfts-prozesse

analysieren

FunktionaleAnforderungen

analysieren

IT-System abgrenzen und strukturieren

Anwendungsfälle erheben

Testfälle vorbereiten

Geschäftsobjekte/Daten modellieren

NichtfunktionaleAnforderungen

analysieren

Qualitätsanforderungen bestimmen

Gesetzliche Anforderungen undRandbedingungen dokumentieren

Technische Anforderungen undRandbedingungen ermitteln

Unternehmens-/Erstellungsprozess-anforderungen erheben

Realisierung

Projektvorgaben klären

Scope Erstellung / Review

Schnittstellenanalysieren

Benutzerschnittstelle spezifizieren

System- und Datenschnittstellen spezifizieren

Interessengruppen identifizieren

Geschäftsprozesse abgrenzen

Katalog zu Fachbegriffen erstellen

Page 12: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 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:

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)

Page 13: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 13

Kategorien von funktionalen Anforderungen

Anforderung an Funktion/Verhalten des Systems

Anforderung an Datendes Systems

FunktionaleAnforderung

Dokumentiert als:

- Use Case

- Szenario

- StateChart

- …

Dokumentiert als:

- Glossar-Eintrag

- Entity-Relationship- Modell

- Fachklassenmodell

- …

Page 14: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 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

BenutzteSystem-schnitt-stelle 1

System B

Benutzte System-schnitt-stelle 2

Produkt <Systemname>

Bereitgestellte System-schnitt-stelle 1

Bereitgestellte System-schnitt-stelle 2

System C

System D

Subsystemn 11000

Benutzerverwaltung 8000

Stammdatenverwaltung9000

Page 15: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 15

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

Page 16: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 16

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.

Page 17: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 17

Attribute

■ Attribute

– repräsentieren Wissen des Systems und

– beschreiben Eigenschaften der Fachklassen.

■ Ziel: Wichtige fachliche Datenaspekte modellieren.

Person

- Name

- Adresse

Page 18: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 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..600..1Bus Fahrgast

transportiert

Page 19: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 19

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.

0..600..1Bus Fahrgast Assoziation

0..300..1Zug Wagon Aggregation

3..*1..*Verein Mitglied Komposition

Page 20: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 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

RechteckKreis

GeoFigur

Dreieck

Page 21: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 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] Statusabfragen

[2] Bestellung veranlassen

[3] Versanddaten

ausfüllen

Verkäufer

Sachbearbeiter

Buchungen

Page 22: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 22

Beispiel - Anwendungsdiagramm

Mögliche Techniken für Anforderungsspezifikation:

– Objektorientierte Analyse und UML-Modellierung, z.B. UML-Anwendungsdiagramm (use cases)

Page 23: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 23

Beispiel - Sequenzdiagramm

Mögliche Techniken für Anforderungsspezifikation:

–Objektorientierte Analyse und UML-Modellierung, z.B. UML-Sequenzdiagramm (sequence diagram)

Page 24: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 24

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

Page 25: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 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.

Page 26: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 26

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

Begriff 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?

Page 27: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 27

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

Projektname: Projekt

Auftrags-Nr. SAP: 300000xxxx

Bereich:

Systemprozess <<Anwendungsfallname>>

Anwendungsfall Name des Anwendungsfalls ID: Nummer des Anwendungsfalls Gliederungsebene: Ebene, in die sich der Anwendungsfall innerhalb des

Systems eingliedert (z.B. Systemprozess) Kritikalität: Dringlichkeit des Anwendungsfalls Akteure: Am Anwendungsfall beteiligte Akteure bzw. Rollen von

Personen, das System selbst und / oder andere Systeme Kurzbeschreibung: Kurze und übersichtliche Beschreibung des

Anwendungsfalls Hinweis: Üblicherweise wird auf abstraktem Niveau der „Gut“-Fall beschrieben.

Vorbedingungen: Zustände bzw. Bedingungen, die für die Auslösung des Anwendungsfalls erfüllt sein müssen (technische Beschreibung)

Nachbedingungen: Zustände bzw. Bedingungen, die nach Beendigung des Anwendungsfalls gelten; konkreter Ausblick auf den unmittelbar nachfolgenden (nicht den übernächsten!) Prozess

Auslöser: Ereignisse, die den Anwendungsfall auslösen (fachliche Beschreibung)

<Aktivitätendiagramm> / <Zustandsdiagramm> / <Sequenzdiagramm>

und / oder Beschreibung: Wer macht wann was? (Formulierung möglichst im Aktiv)

und / oder Gliederung des Anwendungsfalls in numerische Einzelpunkte

Schritt Akteur Aktivität

1 <Aktivität 1 – Entscheidung>

1.1 <Alternative 1.1>

1.2 <Alternative 1.2>

2 <Aktivität 2>

3 <Aktivität 3>

Sonderfall-Schritt Verzweigungsaktion Nr. Unter welchen Bedingungen wird wohin

verzweigt?

Erweiterungen Alternativen/ Sonderfälle

… … Anmerkungen:

Referenzen: Verweise auf weiterführende Literaturquellen / Dokumente

Page 28: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 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

Page 29: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 29

Beispiel FRIEND

■ FRIEND – ein verteiltes Informationssystem für Unfallmanagement

Page 30: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 30

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

Page 31: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 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

Page 32: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 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

Page 33: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 33

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

Page 34: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 34

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

Page 35: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 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

Page 36: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 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

Schritt 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

… …

2

Es werden folgende Detailinformationen angezeigt:…

3

Page 37: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 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

Objekttyp Datenfelder Beziehung zu anderen Objekttypen

Mengenangaben Datensicherheits- und Datenschutz-anforderungen

Artikel Nr., Bezeichnung, Einkaufspreis, Verlaufpreis

Bestellung, Lager 10 Artikelgruppen -

Page 38: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 38

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.

Page 39: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 39

Überblick Guideline Requirements Engineering

Projektauftrag

RequirementsEngineeringinitialisieren

Geschäfts-prozesse

analysieren

FunktionaleAnforderungen

analysieren

IT-System abgrenzen und strukturieren

Anwendungsfälle erheben

Testfälle vorbereiten

Geschäftsobjekte/Daten modellieren

NichtfunktionaleAnforderungen

analysieren

Qualitätsanforderungen bestimmen

Gesetzliche Anforderungen undRandbedingungen dokumentieren

Technische Anforderungen undRandbedingungen ermitteln

Unternehmens-/Erstellungsprozess-anforderungen erheben

Realisierung

Projektvorgaben klären

Scope Erstellung / Review

Schnittstellenanalysieren

Benutzerschnittstelle spezifizieren

System- und Datenschnittstellen spezifizieren

Interessengruppen identifizieren

Geschäftsprozesse abgrenzen

Katalog zu Fachbegriffen erstellen

Page 40: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 40

Benutzerschnittstelle spezifizieren

■ Ziel des ArbeitsschrittesGestaltung 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

Feld- Id.

Feldname Typ Länge Bereich Schlüssel Muss-eingabe

Anzeige/ Eingabe

Default-belegung

Page 41: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 41

System- und Datenschnittstelle spezifizieren

■ Ziel des ArbeitsschrittesBeschreibung 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

Nr. Quelle (Von) Ziel (Nach) Produkt Verantwortlich Quelle

Verantwortlich Ziel

X SAP Buchungssätze N.N.

X Provision Transaction-Record

X BILLING Payments

X x Aufbuchungsbestätigungen, Informationen über verfallene Guthaben

Page 42: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 42

Überblick Guideline Requirements Engineering

Projektauftrag

RequirementsEngineeringinitialisieren

Geschäfts-prozesse

analysieren

FunktionaleAnforderungen

analysieren

IT-System abgrenzen und strukturieren

Anwendungsfälle erheben

Testfälle vorbereiten

Geschäftsobjekte/Daten modellieren

NichtfunktionaleAnforderungen

analysieren

Qualitätsanforderungen bestimmen

Gesetzliche Anforderungen undRandbedingungen dokumentieren

Technische Anforderungen undRandbedingungen ermitteln

Unternehmens-/Erstellungsprozess-anforderungen erheben

Realisierung

Projektvorgaben klären

Scope Erstellung / Review

Schnittstellenanalysieren

Benutzerschnittstelle spezifizieren

System- und Datenschnittstellen spezifizieren

Interessengruppen identifizieren

Geschäftsprozesse abgrenzen

Katalog zu Fachbegriffen erstellen

Page 43: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 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)

Page 44: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 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

Page 45: IT SERVICES IT SERVICES, Guideline Requirements Engineering

IT SERVICESSeite 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?