Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.pdf
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. 3. Requirements spezifizieren 2
3. Requirements spezifizieren 3
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. 3. Requirements spezifizieren 4
2. Requirements ermitteln
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 Nice-to-Have oder Wird - Anforderungen. 3. Requirements spezifizieren 6
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. 3. Requirements spezifizieren 7
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. 3. Requirements spezifizieren 8
3. Requirements spezifizieren 9
3. Requirements spezifizieren 10
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. 3. Requirements spezifizieren 11
Verschachtelte Sätze mit und/oder-verknüpfungen müssen gut strukturiert werden, damit man diese besser verstehen kann. 3. Requirements spezifizieren 12
Durch den konsistenten Einsatz von Struktur, Farbe und Spezial-Schriften werden auch komplexe Sachverhalten einfach(er) verständlich. 3. Requirements spezifizieren 13
Alternativen dazu (welche allerdings mehr Zeit für die Erstellung brauchen als Texte) sind Aktivitäts-Diagramme. Diese haben aber den Vorteil, dass sie auch Mängel oder Lücken in den Anforderungen aufzeigen. 3. Requirements spezifizieren 14
2. Requirements ermitteln
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 ändern und erlaubt es, sich in jedem Projekt wieder schnell im Dokument der SRS zurecht zu finden. 3. Requirements spezifizieren 16
Weitere Unterkapitel für 1.7 Definitionen, Akronyme, Abkürzungen, Glossar sind 1.7.1 Fachbegriffe 1.7.2 Informatik-Begriffe 1.7.3 Prozess-Wörter 1.7.4 Logische Operatoren 1.7.5 Raster für Anforderungen 3. Requirements spezifizieren 17
18
Unter das Produkt-Umfeld gehören dann die Unterkapitel: 2.1.1 System-Schnittstelle 2.1.2 Benützer-Schnittstelle 2.1.3 Hardware-Schnittstelle 2.1.4 Software-Schnittstelle 2.1.5 Kommunikations-Schnittstelle 2.1.6 Betriebssystem-Plattform 2.1.7 Speicher-Beschränkungen 2.1.8 Operationen 2.1.9 Standort-spezifische Anforderungen 3. Requirements spezifizieren 19
20
Unter die Nicht-Funktionalen Anforderungen gehören: 3.4.1 Anforderungen an das Graphische User-Interface 3.4.2 Zugriffsschutz- und Sicherheits-Anforderungen 3.4.3 Performanz-Anforderungen 3.4.4 Design- und Implementations-Anforderungen 3.4.5 Rechtliche Anforderungen 3.4.6 Lizenzen 3. Requirements spezifizieren 21
Das Kapitel 3 ist üblicherweise das längste Kapitel, da hier alle Anforderungen exakt spezifiziert u 22
3. Requirements spezifizieren 23
Mit Hilfe von Mind Maps können während der Diskussion auf einfachste Art und Weise notiert und strukturiert werden. 24
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. 3. Requirements spezifizieren 25
3. Requirements spezifizieren 26
3. Requirements spezifizieren 27
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. 3. Requirements spezifizieren 28
Die Checkliste kann dazu benutzt werden, um eine erste Prüfung der Spezifikation (der Anforderu 2. Requirements ermitteln
2. Requirements ermitteln 30
2. Requirements ermitteln 31
2. Requirements ermitteln 32
2. Requirements ermitteln 33