This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
Software–ProjektWS 2009/10, SS 2010
Anforderungsspezifikation
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.
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
Software–ProjektWS 2009/10, SS 2010
Anforderungsspezifikation
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
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
Software–ProjektWS 2009/10, SS 2010
Anforderungsspezifikation
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!).
Software–ProjektWS 2009/10, SS 2010
Anforderungsspezifikation
Seite 11KAPITEL 2. ALLGEMEINE BESCHREIBUNG
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, . . .
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
Software–ProjektWS 2009/10, SS 2010
Anforderungsspezifikation
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
Software–ProjektWS 2009/10, SS 2010
Anforderungsspezifikation
Seite 13KAPITEL 2. ALLGEMEINE BESCHREIBUNG
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
Software–ProjektWS 2009/10, SS 2010
Anforderungsspezifikation
Seite 15KAPITEL 3. DETAILLIERTE BESCHREIBUNG
3.2. ANWENDUNGSFALLE
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
Software–ProjektWS 2009/10, SS 2010
Anforderungsspezifikation
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.
Software–ProjektWS 2009/10, SS 2010
Anforderungsspezifikation
Seite 17KAPITEL 3. DETAILLIERTE BESCHREIBUNG
3.2. ANWENDUNGSFALLE
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.
Seite 18KAPITEL 3. DETAILLIERTE BESCHREIBUNG3.2. ANWENDUNGSFALLE
Software–ProjektWS 2009/10, SS 2010
Anforderungsspezifikation
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.
Software–ProjektWS 2009/10, SS 2010
Anforderungsspezifikation
Seite 19KAPITEL 3. DETAILLIERTE BESCHREIBUNG
3.2. ANWENDUNGSFALLE
3. Bibi prasentiert eine Erfolgsmeldung, dass das Buch angelegt wurde
Seite 20KAPITEL 3. DETAILLIERTE BESCHREIBUNG3.2. ANWENDUNGSFALLE
Software–ProjektWS 2009/10, SS 2010
Anforderungsspezifikation
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.
Fehler-/Ausnahmefalle
• 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.
Software–ProjektWS 2009/10, SS 2010
Anforderungsspezifikation
Seite 21KAPITEL 3. DETAILLIERTE BESCHREIBUNG
3.2. ANWENDUNGSFALLE
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.
Seite 22KAPITEL 3. DETAILLIERTE BESCHREIBUNG3.2. ANWENDUNGSFALLE
Software–ProjektWS 2009/10, SS 2010
Anforderungsspezifikation
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.
Software–ProjektWS 2009/10, SS 2010
Anforderungsspezifikation
Seite 23KAPITEL 3. DETAILLIERTE BESCHREIBUNG
3.3. AKTIONEN
Fehler-/Ausnahmefalle
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
Software–ProjektWS 2009/10, SS 2010
Anforderungsspezifikation
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
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.
Software–ProjektWS 2009/10, SS 2010
Anforderungsspezifikation
Seite 25KAPITEL 3. DETAILLIERTE BESCHREIBUNG
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.