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
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
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
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
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
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
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.
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.
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
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
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)
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
- …
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
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“).
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.
IT SERVICESSeite 17
Attribute
■ Attribute
– repräsentieren Wissen des Systems und
– beschreiben Eigenschaften der Fachklassen.
■ Ziel: Wichtige fachliche Datenaspekte modellieren.
Person
- Name
- Adresse
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
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
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
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
IT SERVICESSeite 22
Beispiel - Anwendungsdiagramm
Mögliche Techniken für Anforderungsspezifikation:
– Objektorientierte Analyse und UML-Modellierung, z.B. UML-Anwendungsdiagramm (use cases)
IT SERVICESSeite 23
Beispiel - Sequenzdiagramm
Mögliche Techniken für Anforderungsspezifikation:
–Objektorientierte Analyse und UML-Modellierung, z.B. UML-Sequenzdiagramm (sequence diagram)
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
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.
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?
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
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
IT SERVICESSeite 29
Beispiel FRIEND
■ FRIEND – ein verteiltes Informationssystem für Unfallmanagement
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
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
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
IT SERVICESSeite 33
Beispiel für einen Anwendungsfall für FRIEND (1/2)
IT SERVICESSeite 34
Beispiel für einen Anwendungsfall für FRIEND (2/2)
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
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
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 -
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.
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
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
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
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
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)
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
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?