Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert

Transkript

1 Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert

2 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 3. Requirements spezifizieren 3

4 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

5 2. Requirements ermitteln

6 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

7 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

8 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

9 3. Requirements spezifizieren 9

10 3. Requirements spezifizieren 10

11 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

12 Verschachtelte Sätze mit und/oder-verknüpfungen müssen gut strukturiert werden, damit man diese besser verstehen kann. 3. Requirements spezifizieren 12

13 Durch den konsistenten Einsatz von Struktur, Farbe und Spezial-Schriften werden auch komplexe Sachverhalten einfach(er) verständlich. 3. Requirements spezifizieren 13

14 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

15 2. Requirements ermitteln

16 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

17 Weitere Unterkapitel für 1.7 Definitionen, Akronyme, Abkürzungen, Glossar sind Fachbegriffe Informatik-Begriffe Prozess-Wörter Logische Operatoren Raster für Anforderungen 3. Requirements spezifizieren 17

18 18

19 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 3. Requirements spezifizieren 19

20 20

21 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 3. Requirements spezifizieren 21

22 Das Kapitel 3 ist üblicherweise das längste Kapitel, da hier alle Anforderungen exakt spezifiziert u 22

23 3. Requirements spezifizieren 23

24 Mit Hilfe von Mind Maps können während der Diskussion auf einfachste Art und Weise notiert und strukturiert werden. 24

25 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

26 3. Requirements spezifizieren 26

27 3. Requirements spezifizieren 27

28 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

29 Die Checkliste kann dazu benutzt werden, um eine erste Prüfung der Spezifikation (der Anforderu 2. Requirements ermitteln

30 2. Requirements ermitteln 30

31 2. Requirements ermitteln 31

32 2. Requirements ermitteln 32

33 2. Requirements ermitteln 33