VAK 03-901 - Uni Bremen · Anforderungsspezi kation xxxxxx xxxxxxx [email protected] 1234567 xxxx xxxxxxxx [email protected] 2345678 Abgabe: 01. Januar 2010 | Version 1.1. Inhaltsverzeichnis

Universitat BremenFB 3 – Informatik

Prof. Rainer KoschkeTutor: Thilo Mende

Software–Projekt 2009/10VAK 03-901.01

Anforderungsspezifikation

xxxxxx xxxxxxx [email protected] 1234567xxxx xxxxxxxx [email protected] 2345678

Abgabe: 01. Januar 2010 — Version 1.1

Inhaltsverzeichnis

1 Einleitung 51.1 Zweck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Rahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Definitionen, Akronyme und Abkurzungen . . . . . . . . . . . . . . . . . 51.4 Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.5 Ubersicht uber das Dokument . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Allgemeine Beschreibung 72.1 Ergebnisse der Ist-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Erstes Kundengesprach vom 23.11.2009 . . . . . . . . . . . . . . . 72.1.2 Interview mit einem Mitarbeiter der Uni-Bibliothek . . . . . . . . 7

2.2 Produktperspektive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.1 Systemschnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 Benutzerschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.3 Hardwareschnittstellen . . . . . . . . . . . . . . . . . . . . . . . . 82.2.4 Softwareschnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.5 Kommunikationsschnittstellen . . . . . . . . . . . . . . . . . . . . 92.2.6 Speicherbeschrankung . . . . . . . . . . . . . . . . . . . . . . . . 92.2.7 Operationen (Betriebsmodi) . . . . . . . . . . . . . . . . . . . . . 92.2.8 Moglichkeiten der lokalen Anpassung . . . . . . . . . . . . . . . . 9

2.3 Anwendungsfalle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.1 AF1 Gesamtbestand anschauen . . . . . . . . . . . . . . . . . . . 92.3.2 AF2 Buch anlegen . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.3 AF3 Buch ausleihen . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Charakteristika der Benutzer . . . . . . . . . . . . . . . . . . . . . . . . . 102.5 Einschrankungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5.1 Rahmenbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . 122.5.2 Gesetzliche Rahmenbedingungen . . . . . . . . . . . . . . . . . . 122.5.3 Sicherheitskritische Aspekte . . . . . . . . . . . . . . . . . . . . . 12

2.6 Annahmen und Abhangigkeiten . . . . . . . . . . . . . . . . . . . . . . . 122.7 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Detaillierte Beschreibung 143.1 Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Anwendungsfalle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.1 AF1 Gesamtbestand anschauen . . . . . . . . . . . . . . . . . . . 16

2

Software–ProjektWS 2009/10, SS 2010


Seite 3Inhaltsverzeichnis

3.2.2 AF2 Buch anlegen . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.3 AF3 Buch ausleihen . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3 Aktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.4 Entwurfseinschrankungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.5 Softwaresystemattribute . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.5.1 Zuverlassigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.5.2 Verfugbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.5.3 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.5.4 Wartbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.6 Weitere Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 Anhang 26

Version und Anderungsgeschichte

Die aktuelle Versionsnummer des Dokumentes sollte eindeutig und gut zu identifizierensein, entweder hier oder auf dem Titelblatt.

Version Datum Anderungen1.0 11.11.2009 Projektplan als LATEXVorlage kopiert.1.1 12.11.2009 Erste Anpassungen an Bibi.

4

1 Einleitung

Dieses Dokument dient als Beispiel fur Eure Anforderungsspezifikation. Um den Text desBeispiels von den Meta-Kommentaren zur Anforderungsspezifikation unterscheiden zukonnen, sind letztere kursiv gesetzt. Die Gliederung dieses Dokuments ist an die Strukturdes IEEE-Standards 830.1998 angelehnt, weicht jedoch an einigen Stellen davon etwasab. Beachtet hierzu die Anmerkungen auf der Web-Seite zu dieser Abgabe.

1.1 Zweck

Was ist der Zweck dieser Anforderungsspezifikation? Wer sind die Leser?

Diese Anforderungsspezifikation enthalt die genaue Spezifikation des in diesem Projektzu erstellenden Produkts. Es bildet die Grundlage fur alle folgenden Projektphasen.Daher wird besonderer Wert auf eine hohe Qualitat gelegt. Auch stellt es einen Vertragzwischen Auftraggeber und -nehmer dar.

...

1.2 Rahmen

Dieser Abschnitt soll einen groben Uberblick uber die zu erstellende Software geben:Welche Produkte sind zu erstellen (mit Namen)? Was tut die Software? Auch: Wastut sie nicht? Wozu soll die Software verwendet werden? (Ziele etc.)

Das Bibliothekssystem “Bibi“ soll Kunden beim Verwalten eines Handapparates, alsoeiner kleinen Bibliothek, unterstutzen. Dabei soll zum einen der Bestand erfasst werden,zum anderen Studenten die Moglichkeit gegeben werden, den Bestand zu durchsuchenund Ausleihanfragen zu erstellen. Weder Mahn- noch Bezahlsystem sind fur Bibi vorge-sehen.

...

1.3 Definitionen, Akronyme und Abkurzungen

Hier geht es vor allem um Begriffe aus der Anwendungsdomane, d.h. aus der Weltdes Kunden. Aber auch Begriffe, die dem Kunden evtl. fremd oder unklar sind, sollten

5

Seite 6Literaturverzeichnis1.4. REFERENZEN



erlautert werden.

Client Anwendung, die Dienste eines Servers in Anspruch nimmt.

Handapparat Eine kleine Bibliothek fur einen Hochschullehrer. Aus diesem konnen sichStudenten und Mitarbeiter Bucher ausleihen.

Server Anwendung, die Dienste fur Clients zur Verfugung stellt.

. . . . . .

1.4 Referenzen

Neben sonstigen Quellen, die Ihr verwendet habt, konnen dies z.B. dasSkript, dieses Beispieldokument, der zugrunde liegende IEEE-Standard sein etc.(Bauhaus Software Technologies 2009)

[Anonymous 1999] Anonymous (1999). Code Conventions for the Java ProgrammingLanguage. http://java.sun.com/docs/codeconv/. Abruf am 10. November 2009.

[Bauhaus Software Technologies 2009] Bauhaus Software Technologies(2009). Projektplan.

[IEEE 830 1998] IEEE 830 (1998). IEEE Recommended Practice for Software Requi-rements Specifications, IEEE Standard 830.1998 .

1.5 Ubersicht uber das Dokument

Was enthalt die Anforderungsspezifikation? Wie ist das Dokument organisiert?

Kapitel 2 enthalt die allgemeine Beschreibung. Diese gibt einen groben Uberblick uberdie Anforderungen, die in Kapitel 3 weiter verfeinert werden...

http://java.sun.com/docs/codeconv/

http://java.sun.com/docs/codeconv/

2 Allgemeine Beschreibung

2.1 Ergebnisse der Ist-Analyse

Hier sollten die Ergebnisse Eurer Ist-Analyse kurz zusammengefasst werden. Diese Be-schreibung ist hilfreich, um die Motivation fur die Anforderungen zu verstehen und umsie spater nachzuvollziehen (z.B. dann wenn Anforderungen uberarbeitet werden sollen,wenn sich ihre Rahmenbedingungen geandert haben).

Mogliche Inhalte:

• Interview/Beobachtung des Kunden oder der Benutzer

• Analyse des bisherigen Systems und dessen Probleme

• Analyse ahnlicher Systeme

• Auswertung der Benutzerbefragung

• Wie sollen die identifizierten Probleme vom neuen System adressiert werden?

N.B.: Dieser Abschnitt ist im IEEE-Standard nicht vorgesehen, aber dennoch sinnvoll.

2.1.1 Erstes Kundengesprach vom 23.11.2009

Im ersten Kundengesprach am 23.11.2009 erlauterte Prof. Dr. Rainer Koschke die bishe-rige Organisation seines Handapparates. Dieser umfasst zur Zeit etwa 100 verschiedeneBucher. Diese werden von Studenten und Mitarbeitern vor Ort ausgeliehen, wobei dieAusgabe der Bucher immer durch Herrn Koschke personlich oder durch einen seinerMitarbeiter erfolgt. Dabei wird auf einer Karteikarte fur das entsprechende Buch derAusleiher und das aktuelle Datum festgehalten.

Das aktuelle System hat eine Reihe von Nachteilen:

• Man kann sich den Gesamtbestand nur vor Ort anschauen.

• Es ist nicht leicht moglich herauszufinden, welche Bucher ein Student zur Zeitausgeliehen hat.

• . . .

2.1.2 Interview mit einem Mitarbeiter der Uni-Bibliothek

. . .

7

Seite 8KAPITEL 2. ALLGEMEINE BESCHREIBUNG2.2. PRODUKTPERSPEKTIVE



2.2 Produktperspektive

Die im vorherigen Abschnitt definierten Schwachstellen der bisherigen Losung sollendurch eine computer-gestutzte Bibliotheksverwaltung adressiert werden. Dabei wird be-sonders auf die folgenden Aspekte Wert gelegt:

• Es soll ein entfernter Zugriff auf den Katalog ermoglicht werden.

• Ausleihvorgange sollen protokolliert werden, so dass fur den Bibliothekar zu jederZeit erkennbar ist, wer welche Bucher ausgeliehen hat.

• . . .

2.2.1 Systemschnittstellen

Schnittstellen zu anderen Systemen, z.B. Datenimport/-export, Konfigurationsdateien,anzubindende externe Dienste und deren Schnittstelle, Anbieten der eigenen Funktiona-litat als API o.a.

. . .

2.2.2 Benutzerschnittstelle

GUI-Design-Richtlinien und Interaktionsmechanismen (nicht Screenshots aller Dialoge— das gehort nach Kapitel 3 — aber evtl. ein Screenshot, der einen groben Uberblickund Eindruck des GUI-Designs gibt). Bei Web-Anwendungen: Aussagen zu HTML/CSSund/oder Browser-Versionen.

. . .

2.2.3 Hardwareschnittstellen

Schnittstellen zu vorgegebenen Hardwarekomponenten (Name, Version).

. . .

2.2.4 Softwareschnittstellen

Softwarebibliotheken und -rahmenwerke, die benutzt werden sollen, mit Versionsnummer,Hersteller, Quelle etc. Dazu gehoren auf jeden Fall Java und MySQL.

Name Version Hersteller QuelleJava Runtime 1.6.0 Sun Microsystems http://java.sun.com

. . .

http://java.sun.com



Seite 9KAPITEL 2. ALLGEMEINE BESCHREIBUNG

2.3. ANWENDUNGSFALLE

2.2.5 Kommunikationsschnittstellen

Anforderungen+Bandbreite an Kommunikationsnetzwerke, offentliche oder auch privateIPs?

2.2.6 Speicherbeschrankung

min./max. verfugbarer Hauptspeicher und Festplattenplatz, wie geschatzt

2.2.7 Operationen (Betriebsmodi)

Welche Betriebsmodi gibt es? Warum? Welche Benutzerklasse darf was in welchem Be-triebsmodus (Rechte)? Was ist der Zusammenhang zwischen Betriebsmodus und Siche-rung/Wiederherstellung von Daten?

Der Client wird, je nachdem ob sich ein Mitarbeiter oder Student angemeldet hat, Bedie-nungselemente verstecken, die nicht fur die jeweilige Gruppe nutzbar sind. Dies ist vorallem das Anlegen, Verandern und Loschen von Buchern, welches fur Studenten nichterlaubt ist.

Der Server unterstutzt nur einen Betriebsmodus, sorgt aber uber ein Rechtemanagementdafur, dass nur autorisierte Anfragen Anderungen am Datenbestand nach sich ziehen.

2.2.8 Moglichkeiten der lokalen Anpassung

Was kann bei Auslieferung des Systems alles konfiguriert werden? Z.B. Pfade, Daten-bankname usw. Hier ist nicht Internationalisierung gemeint!

. . .

2.3 Anwendungsfalle

Auflistung und kurze Beschreibung aller relevanten Anwendungsfalle. Dies soll einenUberblick uber alle Anwendungsfalle geben, die in 3.2 detailliert beschrieben werden.

2.3.1 AF1 Gesamtbestand anschauen

Um einen schnellen Uberblick uber den Gesamtbestand zu bekommen, konnen Nutzersich eine Auflistung aller Bucher anzeigen lassen, die die wichtigsten Informationen aufeinen Blick enthalt.

Seite 10KAPITEL 2. ALLGEMEINE BESCHREIBUNG2.4. CHARAKTERISTIKA DER BENUTZER



Benutzer anmelden

Buch vormerken

Benutzer löschenBenutzerdaten ändern

neuen Benutzerregistrieren

Anmeldung

Buch löschen

Buch hinzufügen

Buch anmahnen

Buch zurückgebenBuch ausleihen

Neue Titelsuchen

Titel suchen

Autorensuchen

Suche

Leihwesen

Buchverwaltung

Amazon

Bibi

MitarbeiterStudent

BibliothekarLeiher

<<Include>>

<<Include>>

<<Include>>

<<Include>>

<<Include>>

<<Include>> <<Include>>

<<Include>>

<<Include>>

<<Include>>

<<Include>>

<<Include>>

<<Include>>

<<Include>>

<<Include>><<Include>>

Abbildung 2.1: Geschaftsprozesse

2.3.2 AF2 Buch anlegen

Der Bibliothekar kann uber eine Maske die wichtigsten Daten uber ein Buch eintragenund so dem Bestand hinzufugen.

2.3.3 AF3 Buch ausleihen

Mitarbeiter konnen sich selber Bucher ausleihen.

2.4 Charakteristika der Benutzer

Beschreibt hier Eure typischen Benutzer. Benutzt dazu die in der Vorlesung vorgestelltenPersonas. Zur Erinnerung: Ihr beschreibt konkrete Personen, die Reprasentanten derverschiedenen Benutzertypen sind (mit Name, evtl. Wohnort, Tatigkeit, Alter, Bild, ...).Diese sollten eine gewisse Motivation haben, bestimmte Anwendungsfalle durchzufuhren(und dort auch eingesetzt werden!).




2.5. EINSCHRANKUNGEN

Name Bernd Bib Suse Studi Michael MitRolle Bibliothekar Leiherin VerleiherBeruf Bibliothekar Studentin wiss. MitarbeiterMotto Bucher sind mein Le-

benLernen ist meine Lei-denschaft

Worte sagen mehr alsBilder

Ziele effizient den Uberblickbehalten

ab und zu schnell einBuch ausleihen

Spezialliteratur ver-tiefen

Aufgaben Fugt neue Bucherhinzu, mahnt nichtzuruckgegebeneBucher an, . . .

Verleiht Bucher anStudenten

Wunsche Schnelle Benutzbar-keit uber Tastatur-Shortcuts

Moglichst einfache Be-dienung, da das Sy-stem nur sehr seltengenutzt wird

Anpassbarkeit anverschiedne Aufgaben(Suche & Ausleihe)

2.5 Einschrankungen

Dinge, die die Entwurfsfreiheit einschranken, z.B.

• feste Vorgaben (z.B. Policies)

• Hardwarebeschrankungen

• festgelegte Schnittstellen zu anderen Anwendungen

• parallele Operationen (z.B. Multithreading)

• Prufungs- und Steuerungsfunktionen

• Verlasslichkeitsanforderungen

• Kritikalitat der Anwendung

• Sicherheit

Beispiele:

• es muss MySQL und JDK 1.x benutzt werden

• Vorgaben wie Trennung von GUI und Anwendungslogik

• bei Webanwendung: kein PHP, Flash usw.

Die Umgebung des Kunden verlangt den Einsatz einer leichtgewichtigen Datenbank aufdem Server, die ohne Installation eingesetzt werden kann.

Außerdem ist der Zugriff auf den Server auch von nicht-offentlichen IP-Adressen erfor-derlich.

Seite 12KAPITEL 2. ALLGEMEINE BESCHREIBUNG2.6. ANNAHMEN UND ABHANGIGKEITEN



2.5.1 Rahmenbedingungen

Das Projekt untersteht den Rahmenbedingungen und Einschrankungen des Software-Projektes 2009/10 und den allgemeinen Rahmenbedingungen der Studienordnung furden Studiengang Informatik der Universitat Bremen.

2.5.2 Gesetzliche Rahmenbedingungen

Das Projekt unterliegt dem deutschen Recht. Dies betrifft insbesondere Haftung- undGewahrleistung fur das Produkt. Weiterhin unterliegt es den europaischen Datenschutz-richtlinien. Die Benutzerfuhrung muss der Bildschirmarbeitsplatzverordnung nach deut-schem Recht genugen.

2.5.3 Sicherheitskritische Aspekte

Das Rechtemanagement muss wirkungsvoll verhindern, dass Studenten unerlaubte Ande-rungen, wie zum Beispiel Bucher hinzufugen, durchfuhren konnen. Die Verbindung zwi-schen Client und Server muss verschlusselt sein. Sie muss gegen Angriffe durch Eindring-linge geschutzt sein.

2.6 Annahmen und Abhangigkeiten

Faktoren, deren Anderung zwangslaufig zu Anderungen an der Anforderungsspezifikationfuhren wurde.

Der Kunde und seine Ansprechpartner werden bis zur Auslieferung der Software gleichbleiben. Nach Abnahme der Anforderungsspezifikation werden sich die Anforderungenallerhochstens verringern. Dies kann geschehen, wenn Mitarbeiter aus dem Projekt aus-scheiden. In diesen Fallen kann mit dem Kunden nochmals uber den Umfang der An-forderungen verhandelt werden.

Der Abgabetermin ist nicht veranderbar.

2.7 Ausblick

Beschreibt hier knapp, welche Anderungen und Erweiterungen zukunftig (d.h. nach Aus-lieferung des Systems) zu erwarten sind. Diese Information ist wichtig fur den Entwurf,um mogliche Anderungen fruhzeitig im ersten Entwurf berucksichtigen zu konnen. DerEntwurf kann dann so gestaltet werden, dass die zukunftigen Anforderungen leicht rea-lisierbar sind. Die zukunftigen Anforderungen sollten realistisch sein, ansonsten konnteein unnotig allgemeiner und damit zu komplizierter Entwurf die Folge sein. Auch dieser




2.7. AUSBLICK

Abschnitt ist im IEEE-Standard nicht vorgesehen – zumindest nicht explizit in Form ei-nes eigenstandigen Abschnitts. Dennoch handelt es sich um wertvolle Information, vonder der Entwurf profitieren kann.

Zur Zeit ist ein Offline-Modus explizit nicht gefordert, wird aber als Anforderung inZukunft nicht ausgeschlossen. Dies hat vor allem Einfluss auf . . .

3 Detaillierte Beschreibung

Die externen Schnittstellen werden grob in Abschnitt 2 beschrieben. Wenn die grobeBeschreibung dort nicht genugt, kann sie hier detaillierter ausgefuhrt werden (wie vomIEEE-Standard vorgesehen).

3.1 Datenmodell

Das Datenmodell im Kontext des Pflichtenhefts ist “die Darstellung von Informationenund deren Beziehungen in einem fachlogischen Konzept“. Es soll hier gezeigt werden,welche Einheiten fur das existierende System relevant sind und welche Beziehungen zwi-schen diesen Einheiten gelten. Es handelt sich hierbei noch nicht um ein Datenbanksche-ma oder eine Spezifikation von Klassen fur die Implementierung (Entwurf), sondern umdie Modellierung der realen Welt. Dennoch kann dieses Datenmodell als Basis fur denEntwurf dienen.

Das Datenmodell soll als UML-Klassendiagramm angegeben werden. Wichtig ist hierbeidie korrekte Verwendung der UML: Klassen, Attribute, Generalisierung, Assoziation,Aggregation, Komposition, Multiplizitaten. Außerdem sollte das Diagramm sinnvoll undgut lesbar sein. Dazu gehort weiterhin eine kurze Beschreibung des Modells mit erganzen-den Informationen, insbesondere wenn die Relationen durch ihren Namen nicht selbst-erklarend sind. Gebt unbedingt ein Mengengerust fur die Daten an: Wie viele Instanzender wichtigsten Klassen werden erwartet? Erwartet Ihr Anderungen im Datenvolumenin der Zukunft?

+Titel : string+Erscheinungsjahr : int

Leihobjekt

+EMailAdresse : string

Ausleiher

+Datum : date

Ausleihe

+Datum : date

Reservierung+Name : string+Ort : string

Standort

Bibliothekar

+Vorname : string+Nachname : string

Person

Mitarbeiter StudentVerlagsobjekt

+Auflage : in+Ausgabe : int

Buch

Diplomarbeit

Dissertation

Autor

+Name : string+Adresse : string

Verlag

+Nummer : int

ISBN

ISBN-10 ISBN-13 alle int >= 0

+Name : string

Buchreihe

0..*

0..1

0..*

1..*1..*

1

0..*

10..1

0..*0..*

Abbildung 3.1: Datenmodell

14



Seite 15KAPITEL 3. DETAILLIERTE BESCHREIBUNG


Momentan enthalt der Handapparat circa 100 Bucher und wird in absehbarer Zeit nichtdramatisch wachsen. Allerdings sollten, um die Software auch in anderen Abteilungennutzen zu konnen, auch 1.000 Bucher kein Problem darstellen. Benutzer gibt es zur Zeitcirca 20, wobei von einem jahrlichen Zuwachs von mindestens 10 Benutzern auszugehenist.. . .

3.2 Anwendungsfalle

Dieser Teil enthalt die funktionalen Anforderungen an das System. Diese werdendurch Anwendungsfalle beschrieben. Insofern mussen die Anwendungsfalle die Funktio-nalitat des Systems vollstandig abdecken. Daher mussen auch Varianten von Standarda-blaufen sowie das Verhalten im Fehlerfall behandelt werden.

In den Anwendungsfallen beschreibt Ihr, wie Eure Personas mit dem System interagie-ren, wenn sie ein bestimmtes Ziel erreichen wollen. Dabei sollte der Anwendungsfallzum Profil der Persona passen, also eine typische Anwendung seiner Personengruppesein. Ihr solltet die Anwendungsfalle textuell beschreiben (im unten aufgefuhrten Sche-ma) und zusatzlich Sequenzdiagramme verwenden, um durch graphische Darstellung dasVerstandnis zu erleichtern. Sequenzdiagramme als alleinige Darstellung waren unzurei-chend, da sie meist nicht alle moglichen Ablaufe erfassen und nicht ausdrucksmachtiggenug sind, um Aktionen und Bedingungen hinreichend zu erfassen. Stellt sicher, dassdie Mindestanforderungen auf jeden Fall erfasst sind. Weiterhin sollen hier noch keineImplementierungsdetails festgelegt werden, um keine Entwurfsentscheidungen vorwegzu-nehmen.

Verwendet die Screenshots oder digitalisierten Bilder Eures Papierprototypen, um dieBenutzungsfuhrung in den Anwendungsfallen zu illustrieren und die konkrete Benutze-roberflache, die es zu implementieren gilt, zu spezifizieren. Die Bilder sollten im Textan der entsprechenden Stelle referenziert werden, um das Verstandnis fur die Ablaufezu gewahrleisten (das fehlt in den folgenden Beispielen). Die Beschreibung muss so ge-nau sein, dass klar ist, wie welche Aktionen ausgelost werden und was das fur Folgenhat (Beispiel:

”Benutzer startet die Suche“ – wie macht er das?

”...durch Drucken des

Buttons’Suche’“). Hilfreich ist auch ein Zustandsubergangsdiagramm, das die mogliche

Navigation durch die GUI beschreibt.

Die Struktur der textuellen Beschreibung sollte sein:

1. eindeutiger Name des Anwendungsfalls, am besten auch eindeutige Nummer

2. Akteure: welche externen Instanzen interagieren mit dem System in diesem An-wendungsfall?

3. Vorbedingungen: Ausgangszustand, der vor Beginn des Anwendungsfalls geltenmuss; hier sollte auch das Ziel des Akteurs genannt werden.

4. Regularer Ablauf: Abfolge von Aktionen der Akteure und Reaktionen des Systems.

Seite 16KAPITEL 3. DETAILLIERTE BESCHREIBUNG3.2. ANWENDUNGSFALLE



5. Varianten: mogliche Abweichungen vom regularen Ablauf, z.B. Auslassen oderWiederholen von Aktionen.

6. Nachbedingung: Endzustand und dann mogliche Folgeaktionen

7. Fehler-/Ausnahmefalle mit deren Nachbedingung; z.B. wie wird auf ungultige Ein-gaben reagiert?

3.2.1 AF1 Gesamtbestand anschauen

Akteure

Susi Stud

Vorbedingungen

Der Server ist gestartet. Susi hat Bibi gestartet und mochte einen Uberblick uber alleim Katalog registrierten Bucher bekommen.

Regularer Ablauf

1. Susi gibt ihren Benutzernamen und ihr Passwort ein undklickt auf “Anmeldung“, welches die Aktion “Login“ auslost.





2. Bibi ladt uber die Aktion “Katalog laden“ alle Bucherim Katalog in eine Tabelle und zeigt diese Susi an.

3. Susi kann sich in dieser Tabelle Bucher anschauen und bei Interesse an MichaelMit wenden, um sich das Buch auszuleihen (siehe AF XY).

Varianten

Keine.

Nachbedingungen

Bibi ist gestartet und zeigt alle im Bestand registrierten Bucher in einer Tabelle an.

Fehler-/Ausnahmefalle

Wenn Susi nicht registiert ist oder ein falsches Passwort eingibt, erscheint als 2. Dialogeine Warnung. Durch die Auswahl von “OK“ kann Sie es dann noch einmal versuchen.




3.2.2 AF2 Buch anlegen

Akteure

Bernd Bib

Vorbedingungen

Der Server ist gestartet. Bernd hat seinen Client gestartet und sich angemeldet. Ermochte dem Bestand ein neues Buch hinzufugen.

Regularer Ablauf

1. Bernd klickt auf den Tab “Buch Hinzufugen“.

2. Bibi prasentiert eine Eingabemaske, mit der die Daten des Buchs er-fasst werden konnen. Bernd gibt, soweit bekannt, alle Daten ein undklickt auf “Buch anlegen“, welches die Aktion “Anlegen“ ausfuhrt.





3. Bibi prasentiert eine Erfolgsmeldung, dass das Buch angelegt wurde




Varianten

Keine.

Nachbedingungen

Das Buch ist auf dem Server registriert und taucht auf dem Client in der Ubersichtsseiteauf. Bernd Bib hat nun die Moglichkeit, weitere Bucher hinzuzufugen oder mit anderenTatigkeiten fortzufahren.


• Ein ahnliches Buch exitiert bereits, wobei die Ahnlichkeit anhand des Titelsund der ISBN-Nummer bestimmt wird. Der Client prasentiert einen Dialog, indem der Nutzer gefragt wird, ob das Buch dennoch hinzugefugt werden soll.





Hier sollte man naturlich noch spezifizieren, was “ahnlich” in diesem Kontextgenau bedeutet.

• Es fehlen Pflichtdaten fur dieses Buch. Die Eingabemaske wirderneut angezeigt und fehlende Felder werden rot umrandet.




3.2.3 AF3 Buch ausleihen

Akteure

Michael Mit

Vorbedingungen

Der Server ist gestartet. Michael hat seinen Client gestartet und sich angemeldet. Er hatin der Ubersicht ein Buch gefunden, das er sich ausleihen mochte.

Regularer Ablauf

1. Michael fahrt mit dem Mauszeiger uber die Zeile mit demauszuleihenden Buch. Nach einem Rechtsklick erscheint einPopup-Menu, in dem er den Eintrag “ausleihen“ auswahlt.

2. Bibi markiert mittels der Aktion “Ausleihen“ das Buch als an Michael Mit ausge-liehen.

Varianten

Keine.

Nachbedingungen

Das Buch ist auf dem Server als ausgeliehen markiert.Der Client zeigt den Status des Buches als “verliehen“ an.




3.3. AKTIONEN


3.3 Aktionen

Hier sollten die gleichen Aktionen wie in den Anwendungsfallen genannt und genauerbeschrieben werden. Mit anderen Worten: Die Anwendungsfalle mussen vollstandig durchAusfuhrung von Aktionen aus dieser Liste durchfuhrbar sein. Im Prinzip muss es z.B.fur jeden Button/Menupunkt/Link eine Aktion geben. Dabei ist zu beachten:

• Die Namen sollten sinnvoll und eindeutig sein.

• Die Parameter der Aktionen sollen angegeben werden. Hier sollen sprechende Na-men verwendet werden, eventuell mussen die Parameter auch genauer erlautertwerden.

• Es mussen maximale Ausfuhrungszeiten fur jede Operation angegeben werden.

• Die Gruppierung und Sortierung sollte sinnvoll sein (z.B. alphabetisch).

Dieser Abschnitt ist im Standard im Prinzip vorgesehen, weil hierzu grundsatzlich ei-ne Aussage gemacht werden muss. Die Aktionen sind letztlich die Produktfunktionen,wahrend die Anwendungsfalle die Interaktion zwischen den Akteuren und dem Systembeschreiben. Der Abschnitt “Performanzanforderungen” entfallt, da dieser Abschnitt be-reits alle Aktionen und die geforderte Performanz beschreibt.

3.4 Entwurfseinschrankungen

Wurde bereits in 2.5 behandelt und muss daher hier nicht wiederholt werden. Falls abereine detailliertere Beschreibung notwendig ware, ware hier der geeignete Ort.

Siehe Abschnitt 2.5

Seite 24KAPITEL 3. DETAILLIERTE BESCHREIBUNG3.5. SOFTWARESYSTEMATTRIBUTE



Aktion Beschreibung [s]Login(Benutzername, Passwort) Bibi uberpruft, ob der angege-

bene Benutzername existiert unddas Passwort fur diesen gultig ist.

1

Katalog laden Bibi liefert eine Liste der im Ge-samtkatalog vorhandenen Bucherzuruck.

5

Anlegen(Buch, TrotzAhnlichkeit) Fugt das Buch neu zur Daten-bank hinzu. Wenn der BoolscheParameter TrotzAhnlichkeit wahrist, wird das Buch ohne weite-re Prufung hinzugefugt; andern-falls wird, wenn ein ahnlichesBuch gefunden wird, eine War-nung zuruck gegeben.

2

Ausleihen . . . 1. . . . . .

Abbildung 3.2: Aktionen von Bibi sowie Ausfuhrungszeit in Sekunden

3.5 Softwaresystemattribute

Hier werden die sogenannten”

nichtfunktionalen Anforderungen“ spezifiziert. Dazugehoren beispielsweise:

• Zuverlassigkeit (Korrektheit, Robustheit, Ausfallsicherheit)

• Verfugbarkeit

• Sicherheit

• Wartbarkeit

• Portabilitat

Die spezifizierten Systemattribute mussen hinreichend konkret und uberprufbar formu-liert werden.

3.5.1 Zuverlassigkeit

Die Software darf bei falschen Benutzereingaben auf keinen Fall absturzen oder sichselbst beenden. Sobald die Verbindung zum Server unterbrochen ist, sollte der Anwenderrechtzeitig durch einen Warnhinweis informiert werden. Weiterhin muss gewahrleistetwerden, dass bei Sucheingaben keine falschen Ergebnisse ausgegeben werden.




3.6. WEITERE ANFORDERUNGEN

3.5.2 Verfugbarkeit

Das System muss im Prinzip durchgehend verfugbar sein. Da es sich nicht um ein kriti-sches System handelt und die Suche im Notfall auch vor Ort durchgefuhrt werden kann,braucht nur eine Verfugbarkeit von 95 % erreicht werden.

3.5.3 Sicherheit

Es muss gewahrleistet werden, dass nur Administratoren und gegebenfalls Mitarbeiterauf den Server in der Bibliothek zugreifen konnen, um Anderungen vorzunehmen. Un-erwunschte Zugriffe von außerhalb auf den Server mussen abgeblockt werden. Das Log-ging aller Aktionen sollte gewahrleisten, Zugriffe an Hand von IP-Adressen zu ermittelnund gegebenenfalls einen Fehlerfindungsprozess zu beschleunigen.

Weiterhin muss die Software sicherstellen, dass personenbezogene Daten verschlusseltgespeichert und durch externe Programme Datensicherungen vorgenommen werdenkonnen.

Der Administrator und andere Nutzer durfen Passworter von Nutzern (ausgenommenihr eigenes) nicht einsehen konnen.

3.5.4 Wartbarkeit

Es muss sichergestellt werden, dass die PSA-Software einfach zu warten ist. Dies wirddurch die Implementierung, an Hand der

”Code Conventions for the Java Programming

Language(Anonymous 1999)” und ausfuhrlicher Quellcodedokumentation (in Javadocgehalten) gewahrleistet.

3.6 Weitere Anforderungen

In diesem Abschnitt konnen weitere relevante Anforderungen beschrieben werden, die inkeine der oben genannten Abschnitte passen.

4 Anhang

Hier konnen weitere detailliertere Ergebnisse aus der Ist-Analyse oder andere Infor-mationen, die zur Erstellung der Spezifikation gedient haben (z.B. Papierprototypen),angefugt werden.

26

Documents

VAK 03-901 - Uni Bremen · Anforderungsspezi kation xxxxxx xxxxxxx [email protected] 1234567 xxxx xxxxxxxx [email protected] 2345678 Abgabe: 01. Januar 2010 | Version 1.1. Inhaltsverzeichnis