Spezifikationen Requirements Engineering / Software Engineering
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
RE
Requirements Engineering / Software Engineering:
Spezifikationen
(in Softwareentwicklungsprojekten)
Sie finden diese und weitere
Präsentationen unter (→ Klick):
https://www.peterjohann-
Eine Übersicht consulting.de/praesentationen
Für Softwareentwickler,
Requirements Engineers und Projektmitarbeiter
Stand: 12/2016
Zusammengestellt von H. Peterjohann
Zur Verteilung an Interessierte
Alle Rechte vorbehalten. Reproduktion zum nicht-kommerziellen Gebrauch mit Quellenangabe
gestattet. Reproduktion – auch auszugsweise – zum kommerziellen Gebrauch sowie der
Version 1.50 vom 20.12.2016
Gebrauch für Vortragszwecke sind nur mit schriftlicher Bewilligung des Verfassers gestattet. 44 Seiten
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 1 von 44
RE Motivation und Einordnung Diese Ausarbeitung ist eine (eigenständige) Anleitung für Softwareentwickler, um ohne großen theoretischen „Ballast“ recht schnell zu einer einfachen, aber dennoch gebrauchsfertigen Spezifikation zu gelangen. Daher wird hier ein einfaches Projektszenario vorausgesetzt, bei welchem dem Leser die Inhalte, der Projektumfang und der technische Rahmen seines Projekts bereits bekannt sind. Der Leser ist ein Softwareentwickler mit Vorkenntnissen, dem die gängigen Methoden und Modelle des Software Engineerings geläufig sind. Bitte beachten Sie: Als Ergänzung zu dem Thema „Spezifikationserstellung“ kann die Präsentationen „Requirements Engineering: Eine Einführung“ herangezogen werden (vom gleichen Autor, ebenfalls frei auf der Website verfügbar: https://www.peterjohann- consulting.de/_pdf/peco-re-einfuehrung.pdf). Peterjohann Consulting 1.50 – 20.12.2016 Requirements Engineering: Spezifikationen Vorwort Seite 2 von 44
RE Ziel dieser Ausarbeitung (für den Leser)
Folgende Inhalte werden in dieser Ausarbeitung behandelt und sollten Ihnen
nach dem Durcharbeiten bekannt sein:
• Sie wissen, was Spezifikationen sind
• Sie kennen die Vorgehensweisen bei der der Erstellung von Spezifikationen
(in Softwareentwicklungsprojekten)
• Sie können die wesentlichen Elemente einer Spezifikation benennen
Zielgruppe: Softwareentwickler, Requirements Engineers und Projektmitarbeiter
Voraussetzungen: Erste Erfahrungen mit Requirements in Projekten
Schwierigkeitsgrad: Gering bis mittel
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Vorwort Seite 3 von 44
RE Gliederung
• Einleitung
• Die Spezifikation im SW-Erstellungsprozess
• Zum Begriff der Spezifikation
• Motivation (Grundsätzliches, Das Wasserfallmodell, Gesamtaufwand und Kosten)
• Problemkreise (Muss spezifiziert werden?, Wer spezifiziert?)
Gliederung
• Der Fokus der Feinspezifikation
• Die Feinspezifikation als zentrales Element
• Die Anforderungsentwicklung
• Die Spezifikation und Änderungen
• Wortwahl
• Von der Spezifikation zur Abnahme
• Struktur der Anforderungsspezifikation (IEEE 830-1998)
• Die Gliederung einer Spezifikation (eigenes Modell)
• Der Start
• Was gehört hinein?
• Merkregeln (Richtige Begriffe & Zeitbezug, Elemente, Organisation)
• Der Publikationsprozess
• Die Status der Spezifikation
• Aufgaben und Verantwortlichkeiten des Projektmanagers
• Fragen
• Spezifikationen und Agilität
• Checkliste: Ist die Spezifikation formal korrekt?
Seite • Anhang (Literatur, Weblinks, Meine Dienstleistungen – Das kann ich für Sie tun, Kontakt
5-44 zum Autor)
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 4 von 44RE Einleitung
Die Spezifikation ist ein zentrales Element bei der Produktentwicklung,
insbesondere bei der Erstellung von Software-Produkten. In ihr wird
festgehalten, was entwickelt werden soll – eine gute Spezifikation hilft, dass
richtige Produkt richtig zu entwickeln.
Diese Ausarbeitung beschäftigt sich damit, wie eine Spezifikation aussehen
könnte (formaler Aufbau) und wie sie in einen organisatorischen
Ablauf(prozess) innerhalb von Projekten eingebettet werden sollte.
Requirements Projekt
Spezifi-
kationen
Software-
entwicklung
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 5 von 44RE Die Spezifikation im SW-Erstellungsprozess
Die „Spezifikation“ unterstützt den SW-Erstellungsprozess von der Aufnahme
der Idee oder des Problems bis zur Einführung der Lösung!
Analyse Design Realisierung Abschluss
Definition Entwurf Implementierung Einführung
Spezifikation
Idee Umsetzung Lösung
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 6 von 44RE Zum Begriff der Spezifikation (1/5)
Beim International Requirements Engineering Board – IREB /IREB15/ – wird
die Spezifikation als Anforderungsspezifikation bezeichnet und
folgendermaßen definiert:
„Eine Anforderungsspezifikation ist eine systematisch dargestellte
Sammlung von Anforderungen (typischerweise für ein System oder eine
Komponente), die vorgegebenen Kriterien genügt.“
Anforderungsspezifikationen können dabei in natürlicher Sprache oder durch
konzeptuelle Modelle (oder als Mischform) verfasst werden.
Weiter führt das IREB /IREB15/ aus:
„Das Requirements Engineering ist ein
systematischer und disziplinierter Ansatz Dokumentation
zur Spezifikation und zum Management
von Anforderungen …“
Natürlichsprachlich Modellbasiert Mischformen
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 7 von 44RE Zum Begriff der Spezifikation (2/5)
Der Begriff „Spezifikation“ ist nicht eindeutig festgelegt – es finden sich auch
folgende Begriffe: Lastenheft, Pflichtenheft, Software Requirements
Specification, Systemspezifikation, Anforderungsspezifikation,
Lösungsspezifikation, Produktspezifikation, …
In der Spezifikation werden alle (zu berücksichtigenden) Anforderungen
untergebracht.
• Anforderungsspezifikation:
Beschreibt, was von der Lösung erwartet wird. Wird auch Lastenheft
genannt
• Systemspezifikation:
Beschreibt, wie die Lösung ausschauen wird. Wird auch als Pflichtenheft
bezeichnet
Zum Thema Lastenheft und Pflichtenheft gibt es eine eigenständige Präsentation des
Autors, die ebenfalls auf der Website unter https://www.peterjohann-
consulting.de/_pdf/peco-pm-lastenheft-und-pflichtenheft.pdf frei herunterladbar ist.
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 8 von 44RE Zum Begriff der Spezifikation (3/5)
Definition Unterkategorie Definition
• Beschreibt, was zu tun ist (was von
der Lösung erwartet wird)
• Hat rechtliche Relevanz
(Vertragsgrundlage)
Lastenheft • DIN 69901-5:2009: Vom
(Anforderungs-
spezifikation)
Auftraggeber festgelegte
Gesamtheit der Forderungen an die
Ist hier der
Lieferungen und Leistungen eines Hauptfokus
Auftragnehmers innerhalb eines
(Projekt-)Auftrags.
Liefert eine Ausarbeitung des
Pflichtenheft Grobspezifikation
Lastenhefts, verzichtet aber auf Details
(System- wie die Benennung einzelner Fenster-
• Beschreibt, wie die Lösung
spezifikation, Elemente
ausschauen wird (was von der
Lösungs- Lösung erwartet wird)
spezifikation, Benennt alle Details der Lösung (nicht
• Basiert auf dem Lastenheft
Produktspezifikation) • DIN 69901-5:2009: Vom unbedingt technisch), ist aber für den
Feinspezifikation
(weniger Key User wie auch für den Entwickler
Auftragnehmer erarbeitete
gebräuchlich: lesbar und verstehbar
Realisierungsvorgaben auf der
Sollkonzept, Basis des vom Auftraggeber
Fachfeinkonzept, vorgegebenen Lastenheftes Benennt alle Details der Lösung, so
fachliche Technische
dass ggf. das Dokument nicht mehr
Spezifikation) Feinspezifikation
allgemein verständlich ist
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 9 von 44RE Zum Begriff der Spezifikation (4/5)
Unser Ansatz hier:
• Es wird nur die Erstellung der Feinspezifikation betrachtet
• Das Lastenheft ist nur als „mündliche Vereinbarung“ vorhanden (Inhouse-Projekt)
• Die Spezifikation treibt den Softwareerstellungsprozess
Analyse Design Realisierung Abschluss
Umsetzung
Fein-
Lastenheft
Idee spezifikation Lösung
Grob- Techn. Fein-
Studien
spezifikation spezifikation
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 10 von 44RE Zum Begriff der Spezifikation (5/5)
• Bei der Analyse entsteht ein Lastenheft, welches nur einmal erstellt wird (und damit
statisch ist); das Lastenheft hat rechtliche Relevanz
• Beim Design entstehen: die Grob-, die Fein- und die Technische Feinspezifikation,
wobei die Unterscheidung zwischen Grob-, Fein-, und Technischer Feinspezifikation
in der Praxis kaum noch vorgenommen wird; stattdessen werden häufig nur die
Feinspezifikationen für die (Teil-)Applikationen erstellt
• Typische Größenordnungen: Die Feinspezifikation ist etwa 2-3mal so umfangreich
wie die Grobspezifikation, die Technische Feinspezifikation etwa 3-4mal
Umsetzung
Fein-
Lastenheft
Idee spezifikation Lösung
Grob- Techn. Fein-
Studien
spezifikation spezifikation
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 11 von 44Motivation (1/3):
RE Grundsätzliches
• Egal, welche Vorgehensweise (welches Vorgehensmodell) man bei der
Softwareerstellung beherzigt: Spezifikationen müssen (fast) immer erstellt
werden
• Bei Großprojekten: etwa 10 % der Zeit fallen auf die Codierung, aber 30 %
auf die Erstellung der Anforderungsdokumente (Analyse und Design), der
Rest auf die Wartung und den Betrieb
• Im Wesentlichen werden in den Spezifikationen die „Ws“ beschrieben (Wer,
Wann, Was, Womit, …)
• Die Spezifikation dient zur Abstimmung der Entwicklungsarbeit zwischen
Entwickler und Benutzer und wird i.A. durch den Requirements Engineer
erstellt; die Spezifikation kann zudem als Vertragsgrundlage (Ausschrei-
bung), Kommunikationsgrundlage, Grundlage für die Systemintegration,
Wartung sowie Pflege, Grundlage für Architektur, … dienen
• Disziplinen hierzu: Requirements Engineering (RE) /Ebert14, Rupp14/,
Systemanalyse und -design /Balzert08, Balzert09/
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 12 von 44Motivation (2/3):
RE Das Wasserfallmodell
Die zentrale Frage: Wie viel Prozent
Analyse des Gesamtaufwandss stecken hinter
den einzelnen Schritten?
Design
Codierung
Implemen-
tierung
Entwicklungsrichtung
Nachbearbeitung Betrieb
(Iteration)
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 13 von 44Motivation (3/3):
RE Gesamtaufwand und Kosten
• Typische Größenordnung: 60-80 % der Kosten einer Software (im
gesamten Lebenszyklus) entstehen nach der ersten Produktivsetzung, d.h.
im Betrieb und bei Nachbesserungen
• Um den Gesamtaufwand im Rahmen zu halten, müssen nachträgliche oder
zusätzliche Änderungen (Iterationen) vermieden werden
• Dies geht nur, indem die Anforderungen möglichst früh (zu Beginn) so gut
wie möglich erfasst werden
• „Lieber mehr Aufwand in die Spezifikation stecken und dann anschließend
geringere Betriebs(nachfolge)kosten tragen“
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 14 von 44Problemkreise (1/2):
RE Muss spezifiziert werden?
Immer:
• Bei Projekten mit externen Kunden muss immer ein Lastenheft erstellt
werden
• Bei Projekten mit rechtlichen oder starken sicherheitstechnischen
Randbedingungen (Medizin, Luftfahrt, Automotive) muss ebenso wie bei
Großprojekten komplett (bis in das Detail) spezifiziert werden
• Bei „schwierigen Randbedingungen“ sollte spezifiziert werden
Nicht unbedingt:
• Bei Kleinprojekten mit internen Kunden, wenn die Inhalte bekannt sind
• Bei One-Man-Shows
Regel:
• Wenn das Risiko des Nichtspezifizierens getragen werden kann, so muss
nicht (unbedingt in vollem Umfang) spezifiziert werden
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 15 von 44Problemkreise (2/2):
RE Wer spezifiziert?
Die Spezifikation könnte durch den Kunde oder durch die Entwickler erstellt
werden (Problemkreis: Auftraggeber oder Auftragnehmer?).
Auftraggeber Auftragnehmer
Kunde Requirements Entwickler
Engineer
Anforderung/
Idee Spezifikation Umsetzung Lösung
• weiß, was er will • versteht die Sprache des • liest die Spezifikationen
• kann ausdrücken, was Kunden und des Entwicklers (und versteht sie)
er will • versteht den Problem- und den • setzt die Spezifikation um
• ist Repräsentant aller Lösungsbereich
Kunden und Benutzer • ist Mittler zwischen Kunde und Hier: Der Requirements
Entwickler Engineer ist Mitglied des
• hat genügend Zeit, die Anfor-
derungen zusammenzutragen Entwicklungsteams!
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 16 von 44RE Der Fokus der Feinspezifikation
Geschäftsführung
Geschäftsstrategie (Entscheider,
Management)
Geschäftsprozess Benutzer
Fokus der Requirements
Fein- Engineer
spezifikation Anwendung Entwickler
Infrastruktur Supporter (Service)
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 17 von 44RE Die Feinspezifikation als zentrales Element
GUI- Programmier Dokumenta-
Spezifikation -leitfaden tionsleitfaden
Der Master für die Fein- • Immer im Voraus
Anwendungsentwicklung • Vollständig
ist die Feinspezifikation!
spezifikation • Korrekt
Programm- Test- Benutzer-
code handbuch handbuch
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 18 von 44RE Die Anforderungsentwicklung
• Anforderungen müssen „nach und nach“ entwickelt werden; dies setzt
neben den technischen Fähigkeiten auch fachliche, organisatorische und
kommunikative Fähigkeiten beim Ersteller voraus
• Die Erstellung (alternativ auch: Entwicklung) der Spezifikation ist ein
iterativer, inkrementeller Prozess
Elicitation Analysis Specification Validation
(Erhebung) (Analyse) (Spezifizierung) (Validierung)
clarify close gaps rewrite
(klären) (Lücken schließen) (umschreiben)
re-evaluate
(neu bewerten)
confirm and correct
(bestätigen and korrigieren)
/Wiegers13/
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 19 von 44RE Die Spezifikation und Änderungen (1/2)
• Änderungen treten leider auf; diese müssen in einem definierten Prozess in
das Software-System zur Umsetzung gelangen
• Zunächst werden Änderungsanforderungen (Change Requests) gestellt
und dann in den Erstellungsprozess eingebracht
• Katastrophal: Änderungen direkt in die Softwareentwicklung einfließen
lassen
• Schlecht: Änderungen unmittelbar in die Spezifikation und dann in die
Entwicklung einfließen lassen
• Gut: Änderungen über einen Änderungsprozess (Änderungs- oder CR-
Liste) in die Spezifikation und dann in die Entwicklung einfließen lassen
Der Änderungsprozess ist sehr komplex und wird hier nur kurz gestreift!
Unsere Annahme: die Änderungen kommen (nach und nach) aus einer
zentralen Quelle, z.B. der Änderungs- oder Anforderungsliste.
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 20 von 44RE Die Spezifikation und Änderungen (2/2)
CR nnn
Teilsystem oder
CR 002 Teilapplikation
CR 001 Auslöser: Fachabteilung
0 definiert Prozesse um
2
Testfall n
1 Feinspezifikation
1 Testfall 1
• erstellt durch das
Projektteam Testfall 1
• bindend für die 2
Entwicklung
CR-Liste
3
Benutzerhandbuch
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 21 von 44RE Wortwahl (1/2)
Bei der Wortwahl in der Spezifikation ist zu beachten:
• Den Istzustand zu einem bestimmten Zeitpunkt beschreiben
• Muss unabhängig vom Lesezeitpunkt gültig sein, d.h. insbesondere, dass
nicht vorausgesetzt werden darf, dass ein Alt-System oder Alt-Abläufe
bekannt sind
• Immer „Ist“-Formulierungen verwenden (kein „könnte“ und kein „sollte“)
• Zielpublikum beachten
• Wichtig: Die Spezifikationen müssen klar, vollständig, testbar, korrekt und
eindeutig sowie umsetzbar (verstehbar) sein!
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 22 von 44RE Wortwahl (2/2)
Verbindlichkeit Schlüsselwort Keyword
Pflicht muss shall
Wunsch sollte should
Absicht wird will
Kommentar - -
/Rupp14/
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 23 von 44RE Von der Spezifikation zur Abnahme (1/2)
Alle Anforderungen müssen testbar sein, damit sie abgenommen werden
können.
Auftraggeber Erstellen von
Spezifikation
(Kunde) Abnahmekriterien
(Anforderungen)
Änderungen
Auftragnehmer
Abnahmekatalog
(Entwickler)
(Kriterien)
Fragen &
Antworten
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 24 von 44RE Von der Spezifikation zur Abnahme (2/2)
Benutzer-
anforderungen
Requirements
Tester
Engineer
Funktionale vergleichen Testfälle und
Anforderungen und
Testszenarien
Analysemodelle
Benutzeroberflächen- vergleichen Testprozeduren und
und technische Designs Testskripte
nach /Wiegers05/
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 25 von 44Struktur der Anforderungsspezifikation RE (IEEE 830-1998) Die Anforderungsspezifikation sollte gemäß der Norm IEEE 830-1998 folgendermaßen aufgebaut sein: 1. Einführung 2. Glossar 3. Spezifikation der Kundenanforderungen 4. Systemarchitektur 5. Spezifikation der Systemanforderungen 6. Systemmodelle 7. Evolution des Systems 8. Anhänge 9. Index Peterjohann Consulting 1.50 – 20.12.2016 Requirements Engineering: Spezifikationen Seite 26 von 44
Die Gliederung einer Spezifikation
RE (eigenes Modell)
Deckblatt, (Vorwort,) Inhaltsverzeichnis, Abbildungsverzeichnis,
Tabellenverzeichnis
1. Einleitung mit Zielgruppe, Sprech- und Schreibweisen, Aufbau, Top-10-
Glossar
2. Analyse der Prozesse / Systeme (grundsätzlich); Top-5-Prozesse
3. Beschreibung der neuen Prozesse
4. Beschreibung der Bedienoberfläche
…
X-3. Die Schnittstellen
X-2. Das Objekt- und das Datenmodell (soweit relevant)
X-1. Berichte (auch wenn keine vorhanden sind)
X. Anhang mit Literatur, Historie (der Applikation), Glossar
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 27 von 44RE Der Start
So sollte mit der Spezifikationserstellung begonnen werden:
• Verwenden der Spezifikations-Schablone
• Ausfüllen der Grundinformationen (Dauer: etwa 10 Minuten)
• Aufbau der Gliederung (mit einem erfahrenen Partner)
• Statische Teile einbringen (Literatur, Historie, Mengen- und
Wachstumsgerüst, Zielgruppe, Benutzer und Berechtigungen, Kontexte)
• Menü- und Fensterliste einbringen
• Screenshots der Fenster einbringen und dokumentieren
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 28 von 44RE Was gehört hinein? Mengen- und Wachstumsgerüst, Liste aller Menüpunkte, Liste aller Fenster, Historie, Zielgruppe, Verwendete Schreib- und Sprechweisen, Literatur, Top-3- 5-10-Benutzer, Benutzerrollen und -berechtigungen, Begriffe, Prozesse, Aufbau des Dokuments, Kontext-Verbindung zu anderen Applikationen, Einbettung des Systems (in das übergeordnete Gesamtsystem), Listung aller verwendeten Meldungsfenster, Liste aller Berichte und Schnittstellen, Glossar, Literaturverzeichnis, zugelassene Suchbegriffe, Liste der verwendeten Schlüsseltabellen … und was nicht: komplette Code-Segmente, das Datenmodell in der Komplett-Darstellung, Elemente des Projektplans Peterjohann Consulting 1.50 – 20.12.2016 Requirements Engineering: Spezifikationen Seite 29 von 44
Merkregeln (1/3):
RE Richtige Begriffe, Zeitbezug
• Ist ein Begriff bereits eingeführt, so sollten Alternativen nicht
mehr (in Klammerausdrücken) verwendet werden
• Nur Begriffe verwenden, die man selber kennt
• Nicht zu viele Begriffe auf einmal einführen
• Eine Spezifikation sollte entweder …
a) zeitlos oder
b) zeitpunktsbezogen (in der Zukunft) sein.
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 30 von 44Merkregeln (2/3):
RE Elemente
• Erlaubte Notationen: UML, BPMN, eEPK, ERM,
firmenspezifische Nomenklatur, …
• Sinnvoll auch: Use Cases, Screenshots der Oberfläche,
Blockdiagramme
• Einbinden von Screenshots: über ein definiertes Format, z.B.
JPG oder PNG (mit Tools wie Greenshot und IrfanView zu
erstellen)
• Einbinden von technischen Zeichnungen: nur EMF (Windows
Enhanced Metafile) verwenden (über Export-Funktion)
• Das Datenmodell nur in vereinfachter Darstellung einbringen
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 31 von 44Merkregeln (3/3):
RE Organisation
• Jeder Teilprojektmanager (Entwickler) ist für seine (Teil-)
Applikation verantwortlich (inkl. der Spezifikation)
• Alle „neuen“ Spezifikationen müssen beim Projektmanager
angemeldet werden -> der Projektmanager hält die
Spezifikationen zusammen
• Pro (Teil-)Applikation nur eine Spezifikation
• Die Aufwandsschätzung zur Umsetzung erfolgt separat (in
einem eigenen Schätzprozess)
Zur Aufwandsschätzung gibt es eine eigenständige Präsentation des
Autors, die ebenfalls auf der Website unter https://www.peterjohann-
consulting.de/_pdf/peco-pm-schaetzen.pdf frei herunterladbar ist.
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 32 von 44RE Der Publikationsprozess
Ein einfacher Publikationsprozess für eine Spezifikation könnte
folgendermaßen aufgebaut sein:
• Freigeben (und Verteiler bestimmen)
• In das pdf-Format konvertieren; eine Version hiervon als pdf-Datei mit
Version und Datum im entsprechenden Verzeichnis ablegen
z.B. EP1-Benutzerhandbuch.doc -> EP1-Benutzerhandbuch-V1.00-
161220.pdf
• In die entsprechende Publikationsliste eintragen und Projektmitarbeiter
sowie den Projektmanager informieren (automatisiert oder persönlich)
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 33 von 44RE Die Status der Spezifikation (1/2)
Deleted
Abschließend
Reviewen
Published
Freigeben
PjM PjM
PjM RE
Dokument Vorversion
Erweitern Abschließend
erzeugen „freigeben“
Initial Draft Reviewen Archived
PjM Freigeben Zurückziehen PjM
Erweitern Erweitern
RE RE PjM PjM
Zur Bearbeitung Rejected
freigeben
PjM
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 34 von 44RE Die Status der Spezifikation (2/2)
Über Nummern können einzelne Status indirekt codiert werden:
• 0.XX (unter Version 0.50): Initial – nur für Projekt-Interne
(„Ideensammlung“)
• 0.XX (> 0.50 bis 0.99) Draft („Entwurf“) – intern und an ausgewählte
Benutzer und Entwickler
• 1.00: Published („Freigegeben“)
• > 1.00: entweder
a) Rejected („Zurückgezogen“)
b) Draft („in Überarbeitung“)
c) erneut Published
• Nach Abschluss des Projekts: entweder
a) Deleted (wenn sie keine Relevanz mehr hat – dürfte bei Spezifikationen
nicht auftreten) oder
b) Archived (in nicht mehr veränderbarer Form mit abschließender
Versionsnummer)
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 35 von 44Aufgaben und Verantwortlichkeiten des
RE Projektmanagers
Folgende Aufgaben sollte der Projektmanager bei dem Management der
Spezifikationen wahrnehmen:
• Zusammen-/Gegenhalten aller Spezifikationen (z.B. über
Namensvorgaben/Listen)
• Erstellung des Projekt- und Release-Plans der Spezifikationen in
Abhängigkeit der Produktentwicklung
• Koordinierung der Qualitätssicherung (QS) der Spezifikationen
• Koordinierung der QS der Applikationen (mit den erstellten
Testhandbüchern)
• Generieren/Erstellen der Benutzer-Handbücher
• Koordinierung des Reviews aller Spezifikationen (zu einem definierten
Zeitpunkt)
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 36 von 44RE Fragen zu den Spezifikationen
1. Was ist eine Spezifikation?
2. Wer ist für die Spezifikationen im Projekt verantwortlich?
3. Welche Arten von Spezifikation kennen Sie?
4. Wer schätzt den Aufwand zur Umsetzung der Anforderungen?
Wann findet dies statt?
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 37 von 44RE Spezifikationen und Agilität
In dem agilen Kontext gibt keine „klassischen“ Spezifikationen, die einem
Prozess erstellt werden müssten. Stattdessen werden Anforderungen
typischerweise über User Stories erfasst und dann umgesetzt.
Sind aber bereits Spezifikationen vorhanden, so können diese über User
Stories in den (Software-)Erstellungsprozess eingebracht werden.
Kunde Product Owner Entwickler
User Stories im
Idee Product Backlog Umsetzung Lösung
Zum Agilen Requirements Engineeríng gibt es eine eigenständige Präsentation des
Autors, die ebenfalls auf der Website unter https://www.peterjohann-
consulting.de/_pdf/peco-agile-agiles-re.pdf frei herunterladbar ist.
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 38 von 44Checkliste:
RE Ist die Spezifikation formal korrekt?
Frage Ja Nein Offen Maßnahmen
Ist das Deckblatt korrekt ausgefüllt? Produkt- und
Projektangaben, Autor, Version, Datum, Freigabeinfo
Sind die Angaben in den Kopfzeilen korrekt?
Firmenlogo, Titel, Version, Format, Rechtschreibung
Sind die Angaben in den Fußzeilen korrekt?
Dateiname, Datum, Seitenzahlangaben
Ist die Änderungshistorie korrekt gepflegt?
Ist die Rechtschreibung korrekt?
Ist das Dokument vollständig bezüglich der
Beschreibungen und Bilder?
Ist für alle Anforderungen die Identifikation (ID)
eindeutig vergeben?
Sind für alle Anforderungen der Name, die
Beschreibung, die Version und der Status angegeben?
nach /Grande14/
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 39 von 44RE Anhang
• Literatur
• Weblinks
• Meine Dienstleistungen – Das kann ich für Sie tun
• Kontakt zum Autor
Anhang
Seite
40-44
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 40 von 44RE Literatur
/Balzert08/ Helmut Balzert: Lehrbuch der Softwaretechnik: Softwaremanagement, Spektrum
Akademischer Verlag, Heidelberg 2. Auflage 2008, ISBN 978-3-8274-1161-7
/Balzert09/ Helmut Balzert: Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements
Engineering, Spektrum Akademischer Verlag, Heidelberg 3. Auflage 2009, ISBN 978-3-8274-
1705-3
/Ebert14/ Christof Ebert: Systematisches Requirements Engineering. Anforderungen ermitteln,
dokumentieren, analysieren und verwalten, dpunkt, Heidelberg 5. Auflage 2014, ISBN 978-3-
86490-139-3
/Grande14/ Marcus Grande: 100 Minuten für Anforderungsmanagement: Kompaktes Wissen nicht
nur für Projektleiter und Entwickler, Springer Vieweg, Wiesbaden 2. Auflage 2014, ISBN 978-3-
658-06434-1
/IREB15/ Klaus Pohl, Chris Rupp: Basiswissen Requirements Engineering: Aus- und Weiterbildung
nach IREB-Standard zum Certified Professional for Requirements Engineering Foundation
Level, dpunkt, Heidelberg 4. Auflage 2015, ISBN 978-3-86490-283-3
/Rupp14/ Chris Rupp: Requirements-Engineering und -Management. Aus der Praxis von klassisch
bis agil, Hanser, München 6. Auflage 2014, ISBN 978-3-446-43893-4
/Schien01/ Bruno Schienmann: Anforderungsmanagement: Prozesse – Techniken – Werkzeuge,
Addison-Wesley, München 2001, ISBN 978-3-8273-1787-2
/Wiegers13/ Karl E. Wiegers, Joy Beatty: Software Requirements, Microsoft Press, Redmond,
Washington 3rd Edition 2013, ISBN 978-0-7356-7966-5
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 41 von 44RE Weblinks
/Wiki-d/ Deutsche Wikipedia: https://de.wikipedia.org; eingesehen am
20.12.2016
/#Wiki-Spezifikation/ Spezifikation in der deutschen Wikipedia:
https://de.wikipedia.org/wiki/Spezifikation; eingesehen am 20.12.2016
Legende:
/ / Verweis auf Website generell
/*/ Verweis auf eine Website, die als Buch-Ergänzung dient
/#/ Verweis auf einzelnes Thema auf einer Website
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 42 von 44Meine Dienstleistungen –
RE Das kann ich für Sie tun
IT, Organisation
Agilität
Scrum, Kanban
Führung, Change
Prozess- Digitali- Controlling
management sierung Risikomanagement
Software Requirements Coaching
Engineering Engineering Beratung
Training
Projekt- Moderation
management Realisierung
Peterjohann Consulting 1.50 – 20.12.2016
Requirements Engineering: Spezifikationen Seite 43 von 44RE Kontakt zum Autor Sie benötigen noch weitere Informationen? Kontaktieren Sie mich! Peterjohann Consulting Dipl.-Inform. Horst Peterjohann PMP, PMI-PBA, CPRE, CTFL, PSM I, ITILv2 Kattenvenner Straße 24 49549 Ladbergen Telefon: 0 54 85 / 830 17 29 Mobil: 0 162 / 977 47 65 E-Mail: kontakt@peterjohann-consulting.de Website: https://www.peterjohann-consulting.de Peterjohann Consulting 1.50 – 20.12.2016 Requirements Engineering: Spezifikationen Seite 44 von 44
Sie können auch lesen
