3. Requirements spezifizieren. Templates, Kapitel-Raster Mind Maps

Transkript

1 3. Requirements spezifizieren Templates, Kapitel-Raster Mind Maps

2 Ablauf des Requirements Engineering Nachdem die Projekt-Vision und die Stakeholder bekannt sind, können die Geschäfts-Prozesse und die Anforderungen erfasst werden. Die Erkenntnisse aus den Befragungen, Workshops, müssen laufend dokumentiert und spezifiziert werden. 2

3 Motivation für Anforderungsdokument Gemeinsames, einheitliches Basisdokument für alle Beteiligten Referenz für alle Interessengruppen Ausgangsdokument für weitere Dokumente Design, Architektur, Pflichtenheft, Projektplan, Test, Abnahme, Basisdokument für den Auftrag Basis für den Vertrag / die Kosten Testbare Beschreibung der Anforderungen Das Anforderungsdokument ist auch rechtlich relevant, es wird im Streitfall als Grundlage für die Klärung der Situation beigezogen. 3

4 Anforderungs-Dokument Das Anforderungs-Dokument (die Anforderungs-Spezifikation) ist eine systematisch dargestellte Sammlung von Anforderungen. genügt vorgegebenen Kriterien (Struktur, Gliederung, Standards, ) Es gibt verschiedene standardisierte Dokumentstrukturen (RUP, IEEE /SRS, V-Modell Lastenheft/Pflichtenheft, ) 4

5 Die drei Perspektiven auf das System Struktur Daten mit Attributen Funktion Funktionalität, Daten-Verarbeitung Anforderungen Verhalten Zustände, Reaktion auf Ereignisse Die verschiedenen Sichten auf das System helfen bei der Aufteilung/Gliederung der Anforderungen Ordnung ins Chaos. Die Anforderungen können in drei verschiedene Perspektiven gegliedert werden. Das Aufteilen der Anforderungen in die verschiedenen Perspektiven hilft bei deren Analyse und Strukturierung. Strukturperspektive: Die Struktur von Ein- und Ausgabedaten sowie die statisch-strukturellen Aspekte von Nutzungs- und Abhängigkeitsbeziehungen des Systems im Systemkontext. Klassendiagramme Funktionsperspektive: Welche Informationen werden durch das zu entwickelnde System bzw. dessen Funktionen manipuliert. Welche Daten fliessen vom System in den Systemkontext. Aktivitätsdiagramme Verhaltensperspektive: Die Reaktion des Systems auf Ereignisse im Systemkontext, Bedingungen eines Zustandswechsels sowie das zu erwartende Verhalten im Kontext. Zustandsdiagramme 5

6 Dokumentation durch natürliche Sprache Vorteile Keine neue Notation Wird von allen verstanden Vielseitig einsetzbar (für alle Arten von Anforderungen) Nachteile/Gefahren Mehrdeutigkeit Vermischen der verschiedenen Perspektiven Die natürliche Sprache unterstützt den RE nicht bei der Aufteilung der Anforderungen in die verschiedenen Perspektiven. Komplexe Anforderungen sind natürlich-sprachig schwierig zu lesen/verstehen. 6

7 Dokumentation durch Modelle Modellierung durch Use Cases, Klassendiagramme, ER- Diagramme, Aktivitätsdiagramme, Zustandsdiagramme Vorteile Für geübte Leser schnell zu verstehen Exakt, kompakt, eindeutig Leicht überprüfbar, da formalisiert Einfach umsetzbar Je nach Perspektive wird die geeignete Modellierung verwendet Nachteile/Gefahren Für ungeübte Leser schwer verständlich Üblicherweise werden für die Dokumentation Mischformen benutzt: Je nach Leserkreis werden sowohl natürliche Sprache wie (einfache) Modelle kombiniert, um die Vorteile beider Dokumentationsformen nutzen zu können. Auch können Modelle durch Kommentare ergänzt und erläutert und so für einen breiteren Leserkreis verständlich gemacht werden. 7

8 Natürlichsprachige Dokumentation: Schemata, Templates, Operatoren Logische 2. Requirements ermitteln

9 Textuelle Beschreibungen Anforderungstexte müssen vollständig unmissverständlich eindeutig präzise Überprüfbar und messbar sein. Präzision Die textuellen Beschreibungen von Anforderungen sind explizit nicht abwechslungsreich oder spannend zu gestalten. Das einzige was zählt, ist die Präzision. Daher sollten immer die gleichen (vorher im Glossar definierten) Begriffe und Ausdrücke verwendet werden. Sogar der Satzaufbau ist vordefiniert und sollte wenn immer möglich eingehalten werden. 9

10 Allgemeines Schema Formulierungs-Schema für Anforderungen Wer Was Das System Die Komponente Der Service muss sollte wird (Objekt Verb) (wem) die Möglichkeit bieten fähig sein / in der Lage sein Verhalten, Ergänzungen, Attribute Zwingende Anforderungen (oberste, erste Priorität) oder sogenannte Muss -Anforderungen enthalten das Verb muss. Optionale Anforderungen (zweite Priorität) oder sogenannte Kann oder Sollte -Anforderungen enthalten das Verb sollte. Anforderungen, welche zu einem späteren Zeitpunkt umgesetzt werden (welche ein erweiterbares Design erfordern!) sind sogenannte Niceto-Have oder Wird - Anforderungen. 10

11 Allgemeines Schema Formulierungs-Schema für Negativ Anforderungen: Wer Was Das System Die Komponente Der Service darf sollte wird nicht nur keine (Verb) Verhalten, Ergänzungen, Attribute Im Allgemeinen sollte man immer versuchen, Anforderungen als positive Sätze zu formulieren, da diese normalerweise besser verständlich sind. Wo dies nicht möglich ist, gelten die folgenden Regeln: Zwingende Negativ-Anforderungen (oberste, erste Priorität) enthalten den Ausdruck darf nicht, darf nur oder darf keine. Optionale Negativ-Anforderungen (zweite Priorität) enthalten den Ausdruck sollte nicht, sollte nur oder sollte keine. Negativ-Anforderungen, welche zu einem späteren Zeitpunkt umgesetzt werden, enthalten den Ausdruck wird nicht, wird nur, oder wird keine. 11

12 Beispiele von Anforderungen Typ Basis Funktional mit Rolle Funktional mit Randbedingung Funktional Schnittstelle Qualität Qualität Qualität Schnittstelle Beispiel Das System muss in der Lage sein, Noten zu speichern. Das System muss dem Dozenten die Möglichkeit bieten, die Noten seines Kurses einzugeben. Das System muss die Noten bei der Eingabe jeweils sofort validieren. Das System darf keine ungültigen oder nicht validierte Noten abspeichern. Das System muss die Werte auf mindestens drei Nachkommastellen exakt berechnen. Der gerundete Mittelwert sollte spätestens 1 Sekunde nach der Eingabe von neuen Werten wieder korrekt angezeigt werden. Die Sprache der Oberfläche wird vom Benutzer zur Laufzeit umgeschaltet werden können. Negativ-Anforderungen könnten sein: Das System darf einer CAS-Assistentin nicht die Möglichkeit bieten, Kurs- Noten zu ändern. Das System darf bei einem Absturz keine Daten verlieren. 12

13 Bedingte Anforderungen Formulierungs-Schema für bedingte Anforderungen: Wann Wer Was Bedingung muss sollte wird das System die Komponente der Service (Verb) (wem) die Möglichkeit bieten fähig sein / in der Lage sein Verhalten, Ergänzungen, Attribute 13

14 Bedingte Negativ-Anforderungen Formulierungs-Schema für bedingte Negativ-Anforderungen: Wann Wer Was Bedingung darf sollte wird das System die Komponente der Service nicht nur keine Verhalten, Ergänzungen, Attribute 14

15 Beispiele von Anforderungen Typ Funktional mit Rolle Funktional mit Randbedingung Funktional Schnittstelle Qualität Qualität Schnittstelle Beispiel Wenn der Dozent einen Kurs auswählt, dann muss das System die entsprechende Studentenliste zum Eingeben der Noten anzeigen. Falls eine eingegebene Note kleiner als 0 oder grösser als 100 ist, dann muss das System eine Fehlermeldung ausgeben. Wenn ein Dozent neue Noten eingegeben hat, dann muss ihm das System die Möglichkeit bieten, die Noten persistent zu speichern. Wenn sich ein Student im System eingeloggt hat, dann sollte das System alle Noten der von ihm aktuell besuchten CAS anzeigen. Wenn eine eingegebene Note eines Kurses einen Validierungs-Fehler (vgl. xxx) erzeugt, dann darf das System diesen Wert nicht persistent abspeichern. Weitere bedingte Negativ-Anforderungen könnten sein: Wenn ein CAS im Zustand abgeschlossen ist, darf es im System nicht mehr möglich sein, die Noten dieses CAS zu verändern. Wenn ein CAS im Zustand definiert ist, sollte es im System noch nicht möglich sein, Noten dieses CAS zu erfassen. 15

16 Logische Operatoren Jeden Freitag um 20:00 Uhr oder jeden Sonntag um 12:00 Uhr und falls die Artikel-Datei seit mehr als 4 Wochen nicht verändert wurde, dann muss das System die Datenbanken der angeschlossenen Anbieter nach bisher unbekannten Artikeln durchsuchen und, falls diese Menge nicht leer ist, diese Artikel für 4 Wochen als Neuheiten auf dem Web-Client der Kunden ausgeben und den Kunden danach für 2 Wochen die Möglichkeit bieten, diese Artikel als Sonderangebot (mit 15% Rabatt) zu bestellen. Verschachtelte Sätze mit und/oder-verknüpfungen müssen gut strukturiert werden, damit man diese besser verstehen kann. 16

17 Strukturieren von Sätzen (Jeden Freitag um 20:00 Uhr ODER jeden Sonntag um 12:00 Uhr) UND FALLS die Liste der unbekannten Artikel seit mehr als 4 Wochen nicht verändert wurde, DANN MUSS das System die Datenbanken der angeschlossenen Anbieter nach bisher unbekannten Artikeln durchsuchen UND, FALLS diese Menge nicht leer ist, diese Artikel für 4 Wochen als Neuheiten auf dem Web-Client der Kunden ausgeben UND den Kunden danach für 2 Wochen die Möglichkeit bieten, diese Artikel als Sonderangebot (mit 15% Rabatt) zu bestellen. Durch den konsistenten Einsatz von Struktur, Farbe und Spezial-Schriften werden auch komplexe Sachverhalten einfach(er) verständlich. 17

18 Oder als Aktivitätsdiagramm Alternativen dazu (welche allerdings mehr Zeit für die Erstellung brauchen als Texte) sind Aktivitäts-Diagramme oder UND-Oder-Bäume (siehe nächstes Kapitel). Solche haben den Vorteil, dass sie auch Mängel oder Lücken in den Anforderungen aufzeigen (Pfade, die fehlen). 18

19 Das SRS Kapitel-Raster gemäss IEEE Die Basisstruktur des IEEE wird normalerweise an das Projekt-Umfeld adaptiert. Gewisse Teile (wie Zweck, Stakeholder, Glossar, Referenzen, System-Umfeld, Architekturbeschreibung, Funktionalität, Nutzer- bzw. Zielgruppe, Randbedingungen, ) sind aber immer vorhanden. 2. Requirements ermitteln

20 Kapitel-Raster für SRS Grob-Struktur Vorwort Management Summary Kapitel 1 Einleitung Kapitel 2 Gesamt-Übersicht Kapitel 3 Spezifische Anforderungen Kapitel 4 Projekt-Randbedingungen Anhänge Index Kapitel und Unterkapitel, welche nicht benutzt werden, sollen dabei auf keinen Fall gelöscht, sondern jeweils explizit leer gelassen werden (oder mit der Bemerkung keine oder hier nicht relevant ergänzt werden). Dies hat den Vorteil, dass sich die Kapitelstruktur nie ändert und erlaubt es, sich in jedem Projekt wieder schnell im Dokument der SRS zurecht zu finden. 20

21 Kapitel 1: Einleitung 1.1 Konventionen 1.2 Zweck 1.3 Ausgangslage 1.4 Ziele 1.5 Produktumfang 1.6 Stakeholder 1.7 Definitionen, Akronyme, Abkürzungen, Glossar 1.8 Masseinheiten 1.9 Referenzen 1.10 Übersicht über die folgenden Kapitel der SRS Weitere Unterkapitel für 1.7 Definitionen, Akronyme, Abkürzungen, Glossar sind Fachbegriffe Informatik-Begriffe Prozess-Wörter Logische Operatoren Raster für Anforderungen 21

22 Kapitel 1: Einleitung Inhaltlich bedeutet Zweck: Wozu dient dieses Papier und an wen ist es gerichtet. Ausgangslage: das grobe Umfeld, die Motivation oder der Auslöser für das Projekt Ziele: Was ist die Vision, welche Probleme sollen gelöst werden Produktumfang: Grobe Abgrenzung, welche Probleme angegangen werden (und welche nicht) 22

23 Kapitel 2: Gesamt-Übersicht 2.1 Produkt-Umfeld 2.2 Produkt-Funktionalität 2.3 Abgrenzung 2.4 Mengengerüst, Periodizitäten 2.5 Benützer-Charakteristika 2.6 Randbedingungen 2.7 Annahmen und Abhängigkeiten 2.8 Realisierungs-Verschiebung Unter das Produkt-Umfeld gehören dann die Unterkapitel: System-Schnittstelle Benützer-Schnittstelle Hardware-Schnittstelle Software-Schnittstelle Kommunikations-Schnittstelle Betriebssystem-Plattform Speicher-Beschränkungen Operationen Standort-spezifische Anforderungen 23

24 Kapitel 2: Gesamt-Übersicht Nun wird es ein wenig konkreter/spezifischer Produkt-Umfeld: Wo/wie soll das Produkt eingesetzt werden Produkt-Funktionalität: was soll das Produkt können Abgrenzung: Welche Probleme sollen nicht betrachtet, welche Systeme nicht angefasst werden Annahmen und Abhängigkeiten: Dinge, die (ev. noch) geklärt werden müssen. Entscheide, welche noch getroffen werden müssen. Benutzer Charakteristika darf nicht verwechselt werden mit Benutzer Rollen: - Benutzer Charakteristika beschreibt das Vorwissen der verschiedenen Benutzer und die Fähigkeiten und Erfahrungen im Anwendungsbereich. - Benutzer Rollen beschreibt die Rechte der verschiedenen Benutzer (Administrator, Benutzer mit Schreibrechten, nur Leserechte, ) 24

25 Kapitel 3: Spezifische Anforderungen 3.1 Externe Schnittstellen User Interfaces Hardware Interfaces Software Interfaces 3.2 Generelle Anforderungen 3.3 Funktionale Anforderungen 3.4 Nicht-Funktionale Anforderungen Unter die Nicht-Funktionalen Anforderungen gehören: Anforderungen an das Graphische User-Interface Zugriffsschutz- und Sicherheits-Anforderungen Performanz-Anforderungen Design- und Implementations-Anforderungen Rechtliche Anforderungen Lizenzen 25

26 Kapitel 3: Spezifische Anforderungen Hier stehen alle Details möglichst exakt Beschreibung des GUI (ev. schematisch mit Bildern) und der Navigation Spezifikation aller Schnittstellen Alle generellen Anforderungen (welche für alle Anwender, Abläufe, gelten) Alle funktionalen Anforderungen (beschrieben durch Use- Cases, Szenarien, textuell, mit Diagrammen, Alle nicht-funktionalen Anforderungen Das Kapitel 3 ist üblicherweise das längste Kapitel, da hier alle Anforderungen exakt spezifiziert und modelliert werden. 26

27 Kapitel 4: Projekt Randbedingungen 4.1 Technische Randbedingungen Betriebssystem Datenbanksystem 4.2 Dokumentation Benutzer-Handbuch System-Dokumentation 4.3 Zeitplan 4.4 Kosten 4.5 Datenschutz 4.6 Offene Punkte 4.7 Lieferumfang 27

28 Mind Maps Ideen, Anforderungen, Daten sammeln, protokollieren, strukturieren, planen, organisieren, Mit Hilfe von Mind Maps können Ideen während der Diskussion auf einfachste Art und Weise notiert und strukturiert werden. 28

29 Mind Maps Vorteile Informationen in eine strukturierte Form bringen Wichtiges, übergeordnetes Thema steht im Zentrum Zusammenhänge werden sichtbar gemacht Keine Füllwörter, nur Schlüsselbegriffe Nachteile Braucht gewisse Angewöhnung (nicht selbsterklärend) Für Unbeteiligte ev. schwer nachvollziehbar Strukturieren Ideen hemmend Mind Maps können dazu verwendet werden, verschiedene Daten, Ideen, Anforderungen zu sammeln und zu strukturieren. Insbesondere zum Erfassen aller Daten können Mind Maps sehr hilfreich sein. Weniger geeignet sind Mind Maps zum Strukturieren komplexer Abläufe oder Abhängigkeiten. Dies führt oft dazu, dass die gleichen Begriffe in der Mind Map mehrfach aufgeführt werden müssen. 29

30 Vier Schritte 1. Zentrales Thema in die Mitte 2. Alle zugehörigen Begriffe/Ideen sammeln 3. Überbegriffe suchen und alle Schlüsselwörter unter diese Überbegriffe einsortieren 4. Mind Map verfeinern/ergänzen/dokumentieren, so dass es auch nach einiger Zeit noch verständlich ist 30

31 Ein Beispiel Notenerfassungs-System: Übersicht 31

32 Ein Beispiel Notenerfassungs-System Die Daten Mind Maps können nicht für die Spezifikation von Abläufen oder Prozessen eingesetzt werden. Jedoch sind sie zum Beispiel geeignet, um alle (Prozess relevanten) Daten aufzuschreiben. 32

33 Exkurs: User Stories Anforderungen bei agilem Vorgehen 33

34 Schemata Schema in Englisch As a, I want, so that. Schema in Deutsch Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>.

35 Beispiele in Deutsch Fragebogen für das Selektionsverfahren Als HR Manager möchte ich einen Fragebogen erstellen, um mit dessen Hilfe zu entscheiden, ob ich den Kandidaten als möglichen Job-Anwärter zum Abteilungsleiter weiterleite. Antwortbogen sichten Als Manager möchte ich die existierenden Antwortbogen durchblättern, um ihn zu einem späteren Zeitpunkt für eine neue offene Position anzupassen. Backup einschränken Als Benutzer kann ich Folder auswählen, von welchen kein Backup gemacht werden soll, um zu verhindern dass mein Backup mit unnötigen Files gefüllt wird.

36 Beispiele in Englisch Screening Quiz As the HR manager, I want to create a screening quiz so that I can understand whether I want to send possible recruits to the functional manager. Quiz Recall As a manager, I want to browse my existing quizzes so I can recall what I have in place and figure out if I can just reuse or update an existing quiz for the position I need now. Limited Backup As a user, I can indicate folders not to backup so that my backup drive isn't filled up with things I don't need saved.

37 SMART S Spezifisch: Unmissverständlich und eindeutig (Specific/ Significant / Stretching) M Messbar (Measurable / Meaningful) A Ausführbar: Ziele müssen unter den Rahmenbedingungen, Umständen und Ressourcen erreichbar sein (Attainable / Achievable) R Relevant :Ziele müssen dem Projektzweck / Unternehmenszweck dienen (Realistic / Relevant / Reasonable) T Terminiert (Time-bound/ Testable / Trackable) Vgl. Kapitel 5, Prüfen von Anforderungen 37

38 INVEST I N V E S T Independent: Stories should not be dependent on one another to allow arbitrary reordering of the stories by the PO Negotiable : A good story defines WHAT needs to happen, but leaves it up to the Scrum Team to determine HOW Valuable: A reminder that the payoff part of a story ( so that ) is oh so important Estimatable: A story is estimatable if it is small enough so that the team is able to get a good handle on everything that needs to be done. Small: It s hard, if not impossible, to plan sprints around stories that are too big. Testable: If a user story cannot be accompanied by explicit user acceptance criteria it needs to be reworded so that the PO and the Scrum Team will see it in the same light. Investiere in smarte User Stories 38

39 Story Cards Vorderseite Rückseite

40 Checkliste für die Spezifikation von Requirements Die Checkliste kann dazu benutzt werden, um eine erste Prüfung der Spezifikation (der Anforderungen) vorzunehmen. 2. Requirements ermitteln

41 Checkliste Die Anforderungen sollten die folgende Liste von Punkten erfüllen: Beschreibt die Spezifikation ein explizites Produkt-Ziel? Ist dieses Ziel konsistent mit der ursprünglichen Vision? Ist der Anwendungsbereich des Produkts präzise beschrieben? Wird auch beschrieben, was das System nicht erfüllen muss? (System-Grenzen) 2. Requirements ermitteln 41

42 Checkliste Wurden die Bedürfnisse aller Interessengruppen berücksichtigt? Sind die verschiedenen Akteure, welche mit dem System kommunizieren, und deren Aufgaben klar beschrieben? Trennt die Spezifikation zwischen den Kundenwünschen und den Komponenten-Anforderungen (Realisierung)? Trennt die Spezifikation klar zwischen Lastenheft (was muss getan werden) und Pflichtenheft (wie wird es getan)? Existiert ein ausreichend genaues Glossar? 2. Requirements ermitteln 42

43 Checkliste Sind alle beschriebenen Funktionen wirklich nötig (Muss- Kriterien)? Wurde versucht, Komplexität möglichst zu vermieden? Lassen sich Verzierungen/Ausschmückungen streichen? Sind die die Qualitätsanforderungen messbar beschrieben? Sind die nötigen Gesetze, Standards, Vorschriften, physikalische Randbedingungen, genügend berücksichtigt? 2. Requirements ermitteln 43

44 Checkliste Wird der Systemkontext hinreichend beschrieben? Sind die Schnittstellen zu anderen Systemen ausreichend erfasst? Sind Interoperabilitätsszenarien mit anderen Systemen und Komponenten beschrieben? Ist die Ablösung eines etwaigen Vorgängersystems (der Migrationsprozess) ausreichend beschrieben? 2. Requirements ermitteln 44