Software Engineering PS (WS2000/2001)

Schwaiger Roland

Home

Vorbesprechung

Organisation

Thema

Gruppen

Aufgaben

Präsentation

Abschluss

Material

Risk Analysis

Aufgabe 2

1. Führen Sie die erste Iteration der Problembeschreibung aufgrund der Besprechung des project leaders durch (Ergebnis: Verfeinerte Problembeschreibung). Grundlage dafür ist das Gruppenergebnis von Aufgabe 1. Erstellen Sie aus der Problembeschreibung eine Anforderungsdefinition, die dem unten angeführten Aufbau entspricht. Unter Kapitel Ausgangssituation und Zielsetzung fügen Sie die Problembeschreibung ein.
2. Führen Sie eine Risikoabschätzung durch. Benutzen Sie dazu die angeführten Referenzen. Fügen Sie ein eigenes Kapitel mit dem Titel "Risikoabschätzung" in Ihre Anforderungsdefinition ein.
3. Optional: Machen Sie sich mit COCOMO/COCOMOII vertraut: Reference 1, Reference 2, Reference 3, Reference 4,

Zusatzinformation

Wie sie aus dem Übersichtsdiagramm in "The Unified Method in a Nutshell" sehen befinden wir uns derzeit in der Inception Phase. Wir haben in Aufgabe 1 eine erste Iteration durchgeführt. In dieser ersten Iteration waren nur Business Modeling und Requirements relevante Schritte in dem mini-project. Wir haben erkannt, dass weitere Besprechungen notwendig sind, daher führen wir eine zweite Iteration in der Inception Phase durch, die als Ergebnis eine verfeinerte Problembeschreibung und eine erste Anforderungsdefinition bringt. Basierend auf den erstellten Dokumenten werden wir weitere Iterationen durchführen.

In Aufgabe 3 werden wir sehen, wie man die Anforderungen erweitern kann. Prinzipiell wir es nicht möglich sein alle Anforderungen in Gesprächen zu lokalisieren. Wir werden dazu Use Cases und Story Boards einsetzen, eine Alternative dazu wäre entsprechende Prototypen zu erstellen.

Eine allgemein anerkannte Definition des Begriffs Anforderungsdefinition (Systemspezifikation) exisitert nicht (7). Für die als Anforderungsdefinition bezeichnete Phase werden mehrere Begriffe synonym verwendet: requirements definition, requirements specification, concepts definition, functional specification, bzw. im deutschen Sprachraum Anforderungsdefinition, Systemdefinition, Aufgabendefinition. Andererseits bezeichnet der Begriff Anforderungsdefinition (Systemspezifikation) auch das Ergebnis dieser Phase, synonym dafür sind die Begriffe Pflichtenheft und Lastenheft.

Prinzipiell soll unter Anforderungsdefinition (Systemspezifikation) lt. (7) die Erarbeitung eines Kontrakts zwischen Auftraggeber und Software-Entwickler sein, der genau beinhaltet, was das geplante SW-System leisten soll und welche Randbedingungen für dessen Realisierung gelten.

In Anlehnung an den ANSI/IEEE Guide to Software Requirements Specification (SRS) [ANSI 830-1984] wird in (7) folgende Gliederung der Anforderungsdefinition vorgeschlagen.

• Ausgangssituation und Zielsetzung: Problembeschreibung mit Bezug auf Istzustand, Projektziele und Abgrenzung dieser Ziele zur Systemumgebung.
• Systeemeinsatz und Systemumgebung: Beschreibt Voraussetzungen, die für den Systemeinsatz gegeben sein müssen.
• Benutzerschnittstellen: Einer der wichtigsten Teile der Systemspezifikation. Es wird die Mensch-Maschine Schnittstelle dem Benutzer so dargestellt, wie der Benutzer sie später beim Einsatz vorfinden soll (Prototypen). Für die Aufgabe 2 wird dieser Punkt ausgelassen. Wir werden uns in Aufgabe 3 mithilfe der Story Board Technik dieser Problematik nähern.
• Funktionale Anforderungen: Definiert die vom Benutzer erwarteten Systemfunktionen. Ein Vorschlag zur systematischen Beschreibung lautet(1.1):
  • <Anforderung> ::= <Anforderungsname> : <Anforderungstext> . Anforderungstyp : <Anforderungstyp> . Priorität : <Priorität> . Anforderungsbegründung : <Anforderungsbegründung>
  • <Anforderungsname> ::= <Text>
  • <Anforderungstyp> ::= MUSS|SOLL|DARF NICHT
  • <Priorität> ::= 1|2|3|4|5|6|7|8|9|10
  • <Anforderungsbegründung> ::= <Text>
  • <Text> ::= <Zeichen><Text>|<Zeichen>
  • <Zeichen> ::= a|...|z|A|..|Z|0|..|9|"|.|..|;
  Bei den Prioritäten bezeichnet 1 die nöchste Priorität und 10 die niedrigste.

  Beispiele für Anforderungsbeschreibungen:

  • Perf1: Der Dialog zur Erfassung eines Artefakts muss spätestens 0.8 Sekunden nach seinem Aufruf durch den Benutzer am Bildschirm erscheinen.
  • Priorität: 2
  • Rationale: Das bisher verwendete System garantiert die angegebene Antwortszeit. Eine Verschlechterung würde die Akzeptanz durch die Anwender gefährden.

  Zum strukturierten Vorgehen, klassifizieren sie die Anforderungen nach Anforderungsgruppen, z.B. Schnittstellen, Business Logic, Datenbank.

  Darf nicht-Anforderungen werden auch als inverse Anforderungen bezeichnet, sie weisen auf Lücken in der Anforderungsanalyse hin (1.1).

• Nicht funktionale Anforderungen: Enthält alle Anforderungen nicht funktionaler Art, wie z.B. Zuverlässigkeit, Portabilität, gewünschte Antwortzeiten, etc.
• Fehlverhalten: Soll die Auswirkungen der verschiedenen Fehlerarten und das geforderte Systemverhalten nach Auftreten eines Fehlers diskutieren.
• Dokumentationsanforderungen: Legt den Umfang und die Art der Dokumentation fest (Grundlage für Benutzerhandbuch und Systempflege)..
• Abnahmekriterien: Legt fest unter welchen Bedingungen die Systemabnahme erfolgen soll. Dieses Kriterium bezieht sich auf funktionale und nicht funktionale Anforderungen. Idealerweise sollte für jede Anforderung ein entsprechendes Abnahmenkriterium festgelegt werden.
• Glossar und Index: Es ist zweckmässig ein Glossar über die verwendeten Begriffe und einen ausführlichen Index anzulegen.

Bevor die Anforderungsdefinition zum Kontrakt zwischen Auftraggeber und SW-Entwickler gemacht wird, muss sichergestellt werden, dass die Definition vollständig (bzgl. der ersten Phase unseres Projektes) und korrekt ist und dass die Anforderungen auch technisch und ökonomisch realisierbar sind. Daher die abschliessende Durchführbarkeitsstudie:

• Vollständigkeit der Anforderungen: Der Auftraggeber muss bestätigen, dass alle funktionalen/nichtfunktionalen Anforderungen und Nebenbedingungen enthalten sind.
• Konsistenz der Anforderungen
• Prüfung der technischen Durchführbarkeit
• Prüfung der personellen Voraussetzungen
• Ökonomische Rechtfertigung

Zur Erstellung der ökonomische Rechtfertigung, bzw. als eine der Entscheidungsgrundlagen, sollte eine Risiko Analyse durchgeführt werden. Als Grundlagen finden Sie Referenzen im Ordner unter A2 im Sekretariat (8.1, 8.2)