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 44
RE 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 44
RE 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 44
RE 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 44
RE 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 44
RE 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 44
RE 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 44
RE 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 44
Motivation (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 44
Motivation (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 44
Motivation (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 44
Problemkreise (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 44
Problemkreise (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 44
RE 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 44
RE 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 44
RE 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 44
RE 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 44
RE 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 44
RE 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 44
RE 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 44
RE 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 44
RE 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 44
Struktur 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 44
RE 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 44
RE 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 44
Merkregeln (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 44
Merkregeln (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 44
RE 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 44
RE 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 44
RE 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 44
Aufgaben 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 44
RE 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 44
RE 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 44
Checkliste: 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 44
RE 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 44
RE 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 44
RE 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 44
Meine 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 44
RE 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