Software Engineering

© Ludewig, J., H. Lichter: Software Engineering – Grundlagen, Menschen, Prozesse, Techniken. 2. Aufl., dpunkt.verlag, 2010.

16 Analyse und Spezifikation

16.1 Die Bedeutung der Spezifikation im Entwicklungsprozess

16.2 Die Analyse

16.3 Begriffslexikon und Begriffsmodell

16.4 Anforderungen

16.5 Die Spezifikation im Überblick

16.6 Die Darstellung der Spezifikation

16.7 Konzepte und Komponenten der Spezifikation

16.8 Muster und Normen für die Spezifikation

16.9 Regeln für Analyse und Spezifikation

Stellenwert der Anforderungen

Die Anforderungen des Kunden an die Software sind die wichtigsten Informationen in einem Software-Projekt.

2

The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as

difficult as establishing the detailed technical requirements … No other part of the work so cripples the resulting system if done wrong.

No other part is as difficult to rectify later.

Fred Brooks, 1987

16.1 Die Bedeutung der Spezifikation im Entwicklungsprozess

Kunde und Anforderungen

Der Kunde erwartet, dass ihm die Software über einen gewissen Zeitraum hinweg als williger und billiger Diener zur Verfügung steht, ihm also

● bestimmte Leistungen erbringt,

● ohne von ihm umgekehrt erhebliche Leistungen (in Form von Kosten, Aufwand, Mühe, Arger) zu fordern. Die Software soll ihm dienen, nicht umgekehrt.

Werden die Erwartungen, die Anforderungen des Kunden, nicht vollständig und präzise erfasst, ist damit zu rechnen, dass das entwickelte Produkt die Anforderungen nicht (vollständig) erfüllt.

Die vollständige und präzise Erfassung der Anforderungen ist die allerwichtigste technische Voraussetzung für eine erfolgreiche Software-Entwicklung.

4

Analyse und Spezifikation im Überblick

Die Anforderungen werden erhoben, in der Spezifikation formuliert, geprüft und anschließend in den Entwurf umgesetzt. Schließlich wird implementiert, auf verschiedenen Ebenen geprüft und korrigiert. Das Resultat geht zurück an den Klienten.

Der Klient bekommt nur dann, was er haben will, wenn seine Anforderungen sorgfältig erhoben und unterwegs nicht verfälscht wurden.

5

Der Nutzen der Spezifikation

In der Praxis gibt es viele schlechte Spezifikationen; oft gibt es gar keine.

Die Spezifikation ist aber notwendig für

1. die Abstimmung mit dem Kunden bzw. mit dem Marketing,

2. den Entwurf und die Implementierung,

3. das Benutzungshandbuch,

4. die Testvorbereitung,

5. die Abnahme,

6. die Wiederverwendung,

7. die Klärung späterer Einwände, Regressansprüche usw.,

8. eine spätere Re-Implementierung.

6

Nachteile bei fehlender Spezifikation - 1

1. Die Anforderungen bleiben ungeklärt, sie werden darum auch nicht erfüllt.

2. Den Entwicklern fehlt die Vorgabe, darum fragen sie „auf dem kurzen Dienstweg“ Bekannte, die beim Kunden arbeiten, oder sie legen mangels Kontakten die eigenen Erfahrungen und Erwartungen zu Grunde.

3. Die Basis für das Handbuch fehlt, es wird darum phänomenologisch, d.h. experimentell, verfasst.

4. Ein gutes Handbuch ist ein umformulierter Auszug aus der Spezifikation! Darum taugt es auch als Spezifikation.

5. Ein systematischer Test ist ohne Spezifikation unmöglich, denn es ist nicht definiert, welche Daten das System akzeptieren muss und welche Resultate es liefern soll.

7

Nachteile bei fehlender Spezifikation - 2

6. Wenn bei der Abnahme nicht entschieden werden kann, ob das System richtig arbeitet, wird die Korrektheit zur Glaubensfrage.

7. Oft zeigen sich echte oder vermeintliche Mängel der Software erst nach längerem Gebrauch. Ohne Spezifikation kann diese Unterscheidung aber nicht getroffen werden.

8. Wer eine Software(-Komponente) wiederverwenden will, muss wissen, was sie leistet. Das ist in der Spezifikation dokumentiert.

9. Wenn ein System ausgemustert und ersetzt wird, ist Aufwärtskompatibilität gefordert (vgl. Heninger et al., 1978).

 „Spezifikation im Kopf“ gibt es nicht!

8

16.2Die Analyse

Analyse und Jewish motherhood

10

Introspection showed three main techniques that were applied beyond normal common sense:

abstract data typing, strong typing, Jewish motherhood.

D. M. und O. Berry (1980)

Grundbegriffe der Analyse

11

requirement — (1) A condition or capability needed by a user to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. (3) A documented representation of a condition or capability as in (1) or (2).

requirements analysis — (1) The process of studying user needs to arrive at a definition of system, hardware, or software requirements. (2) The process of studying and refining system, hardware, or software requirements.

IEEE Std 610.12-1990

Lastenheft /Anforderungssammlung

Die Analyse ist die Vorarbeit und Voraussetzung der Spezifikation; ihr Ergebnis wird auch als Lastenheft bezeichnet.

Obwohl es Definitionen für diesen Begriff gibt (z.B. in DIN 69905), bleibt er in der Praxis unscharf, weil der Inhalt des Lastenhefts von Firma zu Firma stark variiert.

Wir sprechen nachfolgend nicht vom Lastenheft, sondern von der Anforderungssammlung.

● Beschreibt die fachlichen Anforderungen aus Klientensicht.

● Lücken, Unklarheiten und Widersprüche sind darin normal.

Erst die Anforderungsspezifikation sollte vollständig, klar und konsistent sein.

12

Das Begriffslexikon

Bei der Analyse wird auch das Begriffslexikon angelegt; dieses wird während der gesamten Software-Entwicklung verwendet und ergänzt.

Oft kommt während der Entwicklung oder bei der Abnahme die Frage auf, woher eine Anforderung gekommen ist. Konsequent dokumentieren, welcher Klient hinter welcher Anforderung steht!

Diese Zuordnung bei Besprechungen regelmäßig überprüfen!

 

 

13

Die Ist-Analyse - 1

Ziel der Analyse: Soll-Zustand feststellen

Es sollte also genügen, die Klienten nach ihren Wünschen zu fragen.

Aber: Die Klienten konzentrieren sich auf das, was ihnen derzeit nicht gefällt.

Wir sind also bei jeder Umstellung auf die Schwachpunkte des bestehenden Systems fixiert

● Seine Stärken nehmen wir erst wahr, wenn sie uns fehlen.

Implizit erwarten die Klienten, dass alles, was bisher akzeptabel oder gut war, unverändert bleibt oder besser wird. Die Anforderungen an das neue System bestehen also nur zum kleinsten Teil aus Änderungswünschen, die allermeisten Anforderungen gehen in Richtung Kontinuität.

14

Die Ist-Analyse - 2

Darum hat die Ist-Analyse, also die Feststellung des bestehenden Zustands, große Bedeutung für die erfolgreiche Projektdurchführung.Bei Widersprüchen ist der Ist-Zustand zudem ein sicherer Halt!

Der Analytiker muss sich also gut einfühlen und genau beobachten, um vom Kunden zu erfahren, welche Aspekte des Ist-Zustands für ihn wichtig sind und beibehalten werden sollten.

Die Ist-Analyse ist eine undankbare Tätigkeit!

15

Beispiel

Sie öffnen also morgens das Schloss am Haupteingang?

Ja, habe ich Ihnen doch gesagt.

Jeden Morgen?

Natürlich.

Auch am Wochenende?

Nein, am Wochenende bleibt der Eingang zu.

Und während der Betriebsferien?

Da bleibt er natürlich auch zu.

Und wenn Sie krank sind oder Urlaub haben?

Dann macht das Herr X.

Und wenn auch Herr X ausfällt?

Dann klopft irgendwann ein Kunde ans Fenster, weil er nicht reinkommt.

Was bedeutet „morgens“? ...

16

Die Soll-AnalyseGefahr: Der Analytiker wird zum Prellbock zwischen

● den Klienten (mit großen Wünschen) und

● den Entwicklern (mit der Sorge, die Wünsche nicht erfüllen zu können, und dem Wunsch, eigene Vorstellungen zu realisieren).

Aber der Analytiker sollte sich nicht als deus ex machina fühlen, der die unlösbaren Probleme löst.

Sinnvoll:

● Alle Wünsche sammeln, nicht kritisieren („Wunschzettel“)

● Widersprüche offenlegen

Wünsche sind technisch nicht realisierbar oder zu teuer: →

● Anforderungen müssen reduziert oder Mittel aufgestockt werden.

Konflikte zwischen Wünschen der Klienten: →

● Probleme vor Klienten ansprechen und auf Einigung drängen.

17

Die Spielräume der Soll-Analyse

In aller Regel haben die Kunden kein absolut festes Bild des Produkts. Das verschafft dem Analytiker Spielräume.

● Ein System, das nicht völlig autonom arbeitet, kann seine Benutzer mehr oder minder stark in Anspruch nehmen. Wenn eine bestimmte Funktion schwierig zu implementieren ist, aber nur selten gebraucht wird, kann man sie auch von Hand ausführen.

● Die zentrale Komponente des Systems hat Vorrang; andere Teile werden nicht sofort benötigt. → Entwicklung in Ausbaustufen. Vorteile: Zentrale Funktion steht schnell zur Verfügung, und die weitere Entwicklung kann auch erste Erfahrungen und neue Fakten berücksichtigen.

● Wenn käufliche (oder vorhandene) Komponenten integriert werden, sinken die Kosten und die Entwicklungszeit. Der Kunde muss den Preis „handgeschmiedeter“ Lösungen kennen.

18

Regeln für die Analyse

Die Ausgangslage der Analyse ist extrem unterschiedlich:

● Anwendungsgebiet der Software

● Umgebung des Zielsystems

● Aufgabenstellung

● Vorkenntnisse des Analytikers

● Verständnis der Gesprächspartner usw.

Folge: Es gibt kaum allgemeine Regeln für die Analyse.

Immer wichtig und richtig:

● Die Analyse als Tätigkeit wahr- und ernst nehmen!

● Aufwand und Personal dafür im notwendigen Maße einplanen!

● Resultate in eine (auch dem Kunden) verständliche Form bringen!

19

Techniken der Analyse - 1

20

Techniken der Analyse - 2

Natürlich sollte der Analytiker sollte die einschlägigen Vorschriften und Regeln kennen und beachten.

● Auswertung der Dokumente

Wenn möglich, direkt am Alltag derer teilnehmen, die später mit der Software umgehen werden oder deren Funktion später von der Software übernommen wird.

● Über die Schulter schauen oder, besser noch, selbst mitarbeiten.

Dann kann der Analytiker die Klienten systematisch befragen

● geschlossene und strukturierte, auch offene Fragen

● Gespräch bringt mehr als Fragebogen-Versand!

21

Techniken der Analyse - 2

Wenn die abstrakte Vorstellung vom Zielsystem nicht ausreicht, muss etwas ausprobiert oder gezeigt werden.

● Modell-Entwicklung

● Experiment

● ausführbarer Prototyp

Bei der partizipativen Entwicklung wird die Trennung zwischen Analyse und Entwicklung bewusst aufgehoben. Die neue Software wächst in den sozialen Kontext hinein.

● Vergleiche auch die Ansätze der „agilen Software-Entwicklung“!

22

Schwierigkeiten der Analyse - 1

● Der Klient kann sehr viele Anforderungen nicht nennen, weil er sie nicht hat. Er hat nur Wünsche und Ziele, die sich im Gespräch mit dem Analytiker auf Anforderungen abbilden lassen.

● Der Analytiker hat (bewusst oder unbewusst) eigene Interessen, die er durchsetzen möchte (eine „hidden agenda“).

● Der Klient hat Anforderungen, die er nicht sagen will (also auch eine hidden agenda)

● Der Klient hat Anforderungen, die ihm so selbstverständlich scheinen, dass er sie nicht erwähnt.

Am Ende der Analyse und Spezifikation sollte eine Vision entstanden sein, in der

● der Kunde die Erfüllung seiner (reduzierten) Wünsche,

● der Entwickler ein realisierbares Produkt sieht.

Beschrieben durch ein Dokument evtl. auch durch einen Prototypen.

23

Schwierigkeiten der Analyse - 2

Warum wird die Analyse (und besonders die Ist-Analyse) in der Praxis oft vernachlässigt oder falsch fokussiert?

● Wo die Spezifikation keine Rolle spielt, wird auch die Analyse keine Bedeutung haben.

● Der Kunde will keine Veränderung, sondern eine Verbesserung. Entwickler, die das nicht begreifen, vernachlässigen die Ist-Analyse.

● Entwickler sind oft der (grundfalschen) Überzeugung, bereits zu wissen, was gewünscht oder benötigt wird.

● Kunden legen der Analyse Steine in den Weg:

● Den Analytikern stehen die Klienten (insbesondere die Fachleute auf Kundenseite) nicht zur Verfügung.

● Die Analyse-Aktivität wird als unproduktiv denunziert.

● Kunden sabotieren den Prozess durch späte Änderungen.24

Aus einem Praxisbericht

● Analyse wird vom Kernteam durchgeführt (ca. 3-4 Leute). Die Mitglieder kommen teilweise aus der Anwendung, teilweise handelt es sich um Entwickler. Die Anforderungen an diese Leute sind sehr hoch.

● An der Analyse müssen Entscheidungsträger, Fachleute und Anwender beteiligt sein. Die Anwender werden typisch durch Interviews beteiligt. (Zwei Leute befragen eine Person ca. 90 min lang).

● Abstimmung der Analyse in „Workshops“ mit 6 bis 10 Teilnehmern, ein halber bis ganzer Tag.

● Es ist aussichtslos, den Kunden mit formalen Darstellungen zu kommen.

● Resultat der Analyse ist ein Begriffslexikon.

25

16.3 Begriffslexikon und Begriffsmodell

Das Begriffslexikon

In der Analyse wird ein Begriffslexikon angelegt.

In den frühen Phasen wird dieses Dokument aufgebaut und weiterentwickelt.

Das Begriffslexikon enthält solche Begriffe, die

● wichtig sind und

● von verschiedenen Leuten, v.a. von Klienten, Analytikern und Entwicklern, unterschiedlich ausgelegt werden könnten.

Dazu gehören häufig Begriffe, die auf den ersten Blick völlig klar zu sein scheinen.

Beispiel: Informationssystem für die Prüfungsdaten von Studenten

● „Student“, „Prüfung“, „Note“, „Erstprüfung“

27

Informationen im Begriffslexikon

a) Begriff und Synonyma (im Sinne der Spezifikation)

b) Bedeutung (Definition, Erklärung)

c) Abgrenzung (wo ist dieser Begriff nicht anzuwenden?)

d) Gültigkeit (zeitlich, räumlich, sonst)

e) Fragen der Bezeichnung, Eindeutigkeit u. A.

f) Unklarheiten, die noch nicht beseitigt werden konnten

g) verwandte Begriffe (Querverweise)

Die Angaben werden aus den Gesprächen und Interviews abgeleitet oder, wenn sie von den Analytikern kommen, sorgfältig mit den Klienten überprüft.

Typische Quellen sind im genannten Beispiel die Angestellten in der Verwaltung, die Juristen der Uni, die Gesetze und Ordnungen der Universität.

28

Beispiel

29

Begriff Student, synonym Studentin, Studierender, Studierende

Bedeutung Eine Person, die an der Universität Stuttgart immatrikuliert ist und noch nicht exmatrikuliert wurde, die folglich legal einen Studentenausweis der Universität Stuttgart hat oder haben könnte.

Abgrenzung Gasthörer und Studierende anderer Hochschulen sind im Sinne dieses Systems keine Studenten.

Gültigkeit Mit der Immatrikulation an der Universität Stuttgart entsteht ein neuer Student; er existiert bis zur Exmatrikulation, gleichgültig, wie sie zustande kommt. Ein Fachwechsel oder eine Namensänderung implizieren keine Exmatrikulation.Hat sich eine Person im Laufe ihres Lebens mehrfach an der Universität Stutt-gart immatrikuliert, so handelt es sich um mehrere, nicht identische Studenten.

Bezeichnung Ein Student ist durch die Matrikelnummer und einen Zeitpunkt (zu dem die Matrikelnummer gültig war oder ist) eindeutig bestimmt, alle anderen Attribute, insbesondere der Name, können mehrfach vorkommen.

Unklarheiten Es ist noch ungeklärt, wie Namen aus anderen Schriftsystemen (z.  B. Russisch, Arabisch, Chinesisch) dargestellt werden.

Querverweise Gasthörer, Matrikelnummer, Studentenausweis

Hinweis

Im Begriffslexikon klar unterscheiden zwischen

● Objekten der realen Welt,

● Rollen oder Typen der realen Welt und

● Daten der Software.

30

BegriffsmodellDurch Vernetzung der Begriffe entsteht ein anwendungsfachliches Begriffsmodell. Darin gibt es allgemeine Assoziationen, Generalisierungs- und Kompositionsbeziehungen.

Begriffsmodell (Ausschn.) eines Prüfungsdaten-Verwaltungssystems

Begriffsmodelle helfen, den Anwendungsbereich zu erfassen und die Begriffe im Kontext zu verstehen.

31

16.4Anforderungen

Offene, latente Anforderungen

Allgemein kann man die Anforderungen am Qualitätenbaum festmachen. Jede Forderung nach einer bestimmten Qualität ist eine Anforderung.

In der Praxis kommen die Wartbarkeit kaum und die Prozessqualität gar nicht vor (in diesem Dokument!).

Offene und latente Anforderungen, Entwickler-Optionen

● Offene Anforderungen: vom Kunden selbst brauchbar formuliert

● Latente Anforderungen: dem Kunden nicht bewusst.

● Entwickler-Optionen: Der Kunde hat den Punkt offengelassen, es ist ihm gleich. Auch das dokumentieren!

Hier kann „Kunde“ ggf. durch „Klient“ ersetzt werden!

33

Harte und weiche Anforderungen

Lehrbuchbeispiele enthalten typisch harte Anforderungen.

• Beispiele: Resultat einer Kontostandsberechnung, Obergrenze für den Umfang der installierbaren Software.

In der Praxis sind fast alle Anforderungen weich.

Weiche Anforderungen sind schwer zu erheben und ebenso schwer zu formulieren.

Prinzipiell möglich: Kosten- oder Nutzenfunktionen.

34

Weitere Arten von Anforderungen

Objektivierbare und vage Anforderungen

● Anforderungen dienen nicht zuletzt als Referenz bei der Prüfung der Software.

● Dazu müssen die Anforderungen objektivierbar sein.

● Harte Anforderungen sind typisch objektivierbar, weiche nicht.  

Funktionale und nichtfunktionale Anforderungen

● Funktion der Software = Beziehung zwischen Ein- und Ausgaben, im weiteren Sinne auch das Zeitverhalten.

● Alle Anforderungen, die sich auf diese Funktion beziehen, sind funktionale Anforderungen, alle anderen sind nichtfunktionale Anforderungen (non-functional requirements, NFRs).

● Achtung, das Wort „funktional“ ist mehrdeutig!

35

Funkt. vs nichtfunktionale Anforderungen

Die Kurzbeschreibung eines Systems, also eine auf wenige Worte reduzierte Spezifikation, ist stets eine grobe Charakterisierung der Funktion.

● Beispiel: „Das System sichert nachts die Inhalte aller Festplatten.“

Die Abgrenzung funktional – nichtfunktional ist unscharf; Anforderungen, die zwar die Funktion betreffen, aber nicht präzise formuliert werden können, werden vielfach als nichtfunktional eingeordnet.

● Beispiele: Robustheit, Bedienbarkeit

● Auch das Zeitverhalten wird meist als NFR behandelt.

Funktionale und nichtfunktionale Anforderungen werden gebraucht.

Praktisch alle Aussagen zur Wartbarkeit sind nichtfunktional.

● „Das System muss leicht portierbar sein.“

 

36

Nichtfunktionale Anforderungen

Die Formulierung nichtfunktionaler Anforderungen bereitet uns große Probleme. Die NFRs werden entsprechend stiefmütterlich behandelt, meist ganz weggelassen oder nur durch Schlagwörter ausgedrückt. Das ist aber ihrer großen Bedeutung nicht angemessen.

NFRs lassen sich am besten mit Hilfe von Normen spezifizieren.

Vgl. DIN EN ISO 9241

● Teile 1 bis 9: Ergonomie, Technik der Dialoggestaltung

● Teil 10: Grundsätze der Dialoggestaltung

● Teile 11 bis 17: Details der Dialoggestaltung

Allerdings bietet keiner der Standards harte Vorschriften, deren Einhaltung einfach und objektiv zu prüfen wäre.

In keinem Falle sollte man auf einen Versuch zur Präzision verzichten!

37

Beispiele

38

Schlagwort bessere Anforderung

einfach bedienbar Das Programm soll auch von Laien ohne weitere Einweisung benutzt werden können.

robust Eine Bedienung über die Tastatur darf unter keinen Umständen zu einem irregulären Abbruch des Programms führen.

portabel Das Programm muss von einem Entwickler in höchstens 6h von Windows XP auf Linux portiert werden können.

übersichtlich kommentiert

Die Module des Programms müssen einen Kopfkommentar nach Std. xyz enthalten.

plattformunabhängig Alle prozessorspezifischen Teile des Programms müssen in einem speziellen Modul liegen.

nicht zu große Module

Module dürfen max. 300 Zeilen ausführbaren Code enthalten.

angemessenesHandbuch

Das Benutzungshandbuch wird gemäß Richtlinie ABC aufgebaut. Es wird vom Gutachter N.N. geprüft.

Anforderungen zur Benutzbarkeit - 1

39

Aspekt Erklärung Beispiel

Metapher, Benutzungs-modell

Das System sollte dem Benutzer eine bekannte Metapher anbieten, die es gestattet, die Operationen am System und Änderungen im System nachzuvollziehen. Die Operationen müssen so realisiert werden, dass sie mit der Metapher konsistent sind.

Informationen, die der Nutzer verwaltet, werden als logische Objekte behandelt, die eingegeben, angezeigt und gelöscht werden können (Prinzip des Zettelkastens). Der Nutzer hat jederzeit eine Vorstellung, wo sich die Information befindet, z. B. im Arbeitsbereich oder in der Datenbank.

Übersicht-lichkeit

Die Benutzungsoberfläche sollte so gestaltet sein, dass der Nutzer alle rele-vanten Informationen leicht erkennt.

Irrelevante Informationen werden nicht angezeigt; alle angezeigten Informationen sind logisch gruppiert.

Konsistenz Gleiche oder ähnliche Operationen sollten auch mit gleichen oder ähnlichen Eingaben ausgelöst werden; ähnliche Inhalte sollten ähnlich dargestellt werden.

Eine bestimmte Tastenkombination hat stets die gleiche Bedeutung, z. B. Löschen der markierten Information. Die geschätzte Ausführungszeit längerer Operationen wird stets mit den gleichen Symbolen angezeigt.

Sicherheit Die Bedienung sollte so angelegt sein, dass der Nutzer irrtümlich keinen Schaden anrichtet.

Operationen, die den internen Zustand verändern, werden erst wirksam, wenn der Nutzer die Änderung bestätigt hat.

Anforderungen zur Benutzbarkeit - 2

Weitere Themen zur Benutzbarkeit:

● Methoden zur Verbesserung der Usability

● Personas

40

Aspekt Erklärung Beispiel

Ästhetik Die Benutzungsoberfläche sollte nach dem Empfinden des Nutzers schön (angenehm) sein.

Unangenehme Kontraste (z. B. durch gelbe Schrift auf blauem Grund) werden nicht erzeugt, es sei denn, sie signalisieren eine besonders kritische Situation.

Effizienz Der Aufwand für die Bedienung sollte so gering wie möglich sein.

Es genügt, wenn der Nutzer einmal sein Passwort eingibt, um eine Folge von Operationen auszulösen, die jeweils ein Passwort erfordern.

Erlernbarkeit Dem Nutzer sollte es leicht fallen, die Bedienung des Systems zu erlernen.

Das System verhält sich ähnlich wie andere Systeme, die dem Nutzer bereits vertraut sind. Alle Unklarheiten des Nutzers werden durch Hilfe-Funktionen geklärt.

Praktischer Umgang mit Anforderungen

Wie man es nicht machen sollte!

Stark vereinfachtes Bild von den Anforderungen in der Praxis:

● Wenn der Klient eine Anforderung nicht von selbst genannt hat, dann hat er diese Anforderung nicht.

● Wenn eine Anforderung funktional oder quantifizierbar ist, wird sie dokumentiert.

● Alle anderen Anforderungen werden pauschal als nichtfunktionale Anforderungen bezeichnet und kaum erwähnt. Das gilt auch für

● die Gebrauchsqualität (z.B. der Bedienbarkeit)

● die Wartungsqualität (z.B. der Erweiterbarkeit).

Empfehlung:

● Anforderungen nicht „vergessen“, nur weil sie Mühe machen.

41

16.5 Die Spezifikation im Überblick

Spezifikationsbegriffe - 1

43

specification — A document that specifies, in a complete, precise, verifiable manner, the requirements, design, behavior, or other characteristics of a system or component, and, often, the procedures for determining whether these provisions have been satisfied.

specification language — A language, often a machine-processible combination of natural and formal language, used to express the requirements, design, behavior, or other characteristics of a system or component. For example, a design language or requirements specification language.Contrast with: programming language; query language.

IEEE Std 610.12-1990

Spezifikationsbegriffe - 1

44

Aus den Definitionen zu specification und SRS folgt:

● Die Anforderungsspezifikation dokumentiert die wesentlichen Anforderungen an eine Software und ihre Schnittstellen, und zwar präzise, vollständig und überprüfbar.

 

requirements specification language — A specification language with special constructs and, sometimes, verification protocols, used to develop, analyze, and document hardware or software requirements.

software requirements specification (SRS) — Documentation of the essential requirements (functions, performance, design constraints, and attributes) of the software and its external interfaces.

IEEE Std 610.12-1990

Angestrebte Eigenschaften

Die Spezifikation ist im Idealfall inhaltlich

1. zutreffend: Sie gibt die Vorstellungen des Kunden richtig wieder.

2. vollständig: Jede (in einem Kopf oder in einem Dokument) vorhandene Anforderung ist in der Spezifikation enthalten.

3. widerspruchsfrei (oder konsistent): Jede Anforderung ist mit allen anderen Anforderungen vereinbar. Eine inkonsistente Spezifikation ist nicht realisierbar, denn kein System kann widersprüchliche Anforderungen erfüllen.

4. neutral (oder abstrakt): Die Spezifikation schränkt die Realisierung nicht über die wirklichen Anforderungen hinaus ein.

5. nachvollziehbar: Die Quellen der Anforderungen sind dokumentiert, die Anforderungen sind eindeutig identifizierbar.

6. objektivierbar: Das realisierte System kann gegen die Spezifikation geprüft werden. auch (missverständlich) „testbar“.

45

Darstellung und Form

Eine ideale Spezifikation ist

1. leicht verständlich: Alle Interessenten sind in der Lage, die Spezifikation zu verstehen.

2. präzise: Die Spezifikation schafft keine Unklarheiten und Interpretationsspielräume.

3. leicht erstellbar: Die Anfertigung und Nachführung der Spezifika tion sind einfach und erfordern keinen nennenswerten Aufwand.

4. leicht verwaltbar: Die Speicherung der Spezifikation und der Zugriff darauf sind einfach und erfordern keinen nennenswerten Aufwand.

Diese Merkmale konkurrieren!

Auch hier suchen wir also einen Kompromiss.

46

Abgrenzung Spezifikation-Entwurf - 1

Die Forderung nach Neutralität war in der Frühzeit des Software Engineerings radikal:

Idee: Die Spezifikation soll aussagen, was das System leistet, aber nicht, wie diese Leistung erbracht wird („What, not how!“).

Beispiel: Programm zur Ermittlung der Nullstellen einer Funktion kann ohne Aussagen zum Algorithmus spezifiziert werden.

Inzwischen wurde die Forderung nach Neutralität aufgeweicht.

Als Ideal bleibt sie aber gültig. Denn in der Praxis kann man immer wieder beobachten, dass eine Spezifikation gefordert, aber ein Entwurf geliefert wurde. Auf diese Weise wird (evtl.) die optimale Lösung ausgeschlossen.

47

Abgrenzung Spezifikation-Entwurf - 2

Die geforderte Neutralität der Spezifikation ist als Ideal sinnvoll, aber praktisch nicht durchzuhalten. Dafür gibt folgende Gründe:

1. Vorhandene Komponenten sind einzubeziehen.

2. Vorgaben von außen betreffen die Struktur und Details

3. Die Beschreibung des Lösung ist einfacher.

4. Erst das gegliederte System ist überschaubar.

5. Die Konsistenz der Spezifikation wird erst durch die Realisierung geklärt.

6. Die Fragen an die Spezifikation entstehen erst im Entwurf.

7. Die reale Welt ist strukturiert, die Software am besten ebenso.

Darum kann eine abstrakte Spezifikation nur unter Idealbedingungen entstehen: Das Problem ist gut verstanden, sicher lösbar, stabil und relativ „flach“.

48

16.6 Die Darstellung der Spezifikation

Formal, graphisch, natürlichsprachlich

Eine Spezifikation soll einerseits präzise und einer Bearbeitung mit Werkzeugen zugänglich, andererseits auch für Laien handhabbar, mindestens aber verständlich sein.

Da die Informatik starke Wurzeln in der Mathematik hat, war es naheliegend, für die Spezifikation formale Notationen zu entwickeln.

Mit diesen Notationen verwandt sind grafische Darstellungen der Spezifikation.

● Dabei steht aber weniger die formale Präzision als die Anschaulichkeit im Vordergrund.

Wer weder formal noch grafisch spezifiziert, bedient sich der natürlichen Sprache.

● Diese hat den Vorteil, für jeden Menschen verständlich zu sein und ganz ohne spezielle Regeln und Werkzeuge auszukommen..

50

Formale Spezifikation

Vorteile:

● Unklarheiten und Missverständnisse sind ausgeschlossen

● Eine Implementierung kann mit mathematischen Methoden (und das heißt automatisch) auf Konsistenz mit der Spezifikation, also auf Korrektheit, geprüft werden.

Selbst wenn sich die formalen Techniken nicht auf jede Software anwenden ließen, wäre es eine erhebliche Verbesserung, wenn sie für größere Bereiche der Software-Entwicklung tauglich würden.

● Beispielsweise könnten viel benutzte Modul- oder Klassenbibliotheken formal spezifiziert, verifiziert und dann risikolos in andere Software eingebunden werden.

51

Probleme der Formalen Spezifikation

Erstellung, Prüfung und Verwendung formaler Spezifikationen

● Formale Beschreibungen sind schwer zu erstellen und zu prüfen. Sie taugen damit nicht für die Kommunikation mit Kunden und Anwendern.

Die Beschränkung auf funktionale Anforderungen

● Funktionalen Anforderungen lassen sich formal spezifizieren. Für die vielen anderen Anforderungen stehen uns keine formalen Modelle zur Verfügung, sie lassen sich darum – mit unserem heutigen Wissen – nicht formalisieren.

52

Grafische Darstellungen der Spezifikation

Pionier war Douglas Ross mit der »Structured Analysis and Design Technique« (SADT); SADT hatte jedoch keinen anhaltenden Erfolg.

»Structured Analysis« von Tom DeMarco beruht auf den Konzepten aus SADT.

● SA war bis zum Aufkommen der Objektorientierung sehr populär und wurde durch viele Werkzeuge unterstützt.

Anfang der Neunzigerjahre wurde eine Vielzahl von Notationen für die »objektorientierte Analyse« vorgestellt.

Heute sind die meisten dieser Notationen vergessen, weil sie durch UML-Notationen verdrängt wurden.

● UML bietet Notationen, die in der Analyse verwendet werden können, insbesondere die Anwendungsfalldiagramme.

53

Natürlichsprachliche Spezifikation

Wegen der oben beschriebenen Probleme mit formalen und grafischen Spezifikationen sind Texte meist das beste oder einzige Mittel zur Kommunikation mit den Klienten.

Wie kann man die Nachteile der Verwendung natürlicher Sprachen vermindern oder beseitigen?

Die Firma SOPHIST hat ein Regelwerk entwickelt, das diese Probleme

● Es definiert einige besonders wichtige Regeln.

● Dabei geht es immer darum, Lücken und Unschärfen zu vermeiden und deutlich zu machen, wer wann was tut.

54

Einige Sprachregeln - 1

55

Regel Erläuterung, Beispiel

R1 Formulieren Sie jede Anforderung im Aktiv.

Der Akteur wird angegeben, und es wird sichtbar, ob das System oder der Benutzer etwas tut. Fordert man, dass etwas »gelöscht wird«, so bleibt das unklar.

R2 Drücken Sie Prozesse durch Vollverben aus.

Vollverben (wie »liest«, »erzeugt«, nicht »ist«, »hat«) verlangen weitere Informationen (Objekte, Ergänzungen), die den Prozess genauer beschreiben. Nicht: »Wenn die Daten konsistent sind«, sondern »Wenn Programm ABC die Konsistenz der Daten geprüft hat«. Und natürlich muss auch spezifiziert sein, was geschehen soll, wenn sie nicht konsistent sind (R4).

R3 Entdecken Sie unvoll-ständig spezifizierte Prozesswörter (Verben).

Fehlen Angaben (Objekte), dann wird nach diesen Angaben gesucht, um vollständige Aussagen zu erhalten. Wenn eine Komponente einen Fehler meldet, fragt sich, wem.

R4 Ermitteln Sie unvollständig spezifizierte Bedingungen.

Für Bedingungen der Form »Wenn-dann-sonst« müssen sowohl der Dann- als auch der Sonst-Fall beschrieben sein (vgl. das Beispiel für R2).

R5 Bestimmen Sie die Universalquantoren.

Sind Sätze mit »nie«, »immer«, »jedes«, »kein«, »alle« wirklich universell gültig, oder gibt es Einschränkungen? Sind »alle Personen« wirklich alle Personen, oder nur die Anwesenden, die Mitarbeiter, die Besitzer einer Eintrittskarte?

Einige Sprachregeln - 2

56

Regel Erläuterung, Beispiel

R6 Überprüfen Sie Nominalisierungen.

Nomen (z.  B. »Generierung«, »Datenverlust«) weisen oft auf einen komplexen Prozess hin, der beschrieben werden muss. Verwendet man das Substantiv »Anmeldung«, dann fehlen meist die Ergänzungen, die beim Verb »anmelden« erwartet werden: Wer meldet sich wo und wofür an?

R7 Erkennen und präzisieren Sie unbestimmte Substantive.

Oft bleibt unklar, ob es sich um einen generischen Begriff oder um ein bestimmtes Objekt handelt. Ist vom »Bediener« die Rede, so fragt es sich, ob es nur einen gibt oder welcher gemeint ist. Ähnliches gilt für viele Begriffe (Gerät, Meldung).

R8 Klären Sie die Zuständigkeiten bei Möglichkeiten und Notwendigkeiten.

Ein Zwang muss realisiert werden. Steht in einer Anforderung, dass etwas möglich oder unmöglich ist, passieren kann, darf oder muss, so ist zu klären, wer dies erzwingt oder verhindert.

R9 Erkennen Sie implizite Annahmen.

Begriffe in den Anforderungen (»die Firewall«), die nicht erläutert sind, deuten oft auf implizite Annahmen (hier vermutlich auf die, dass es eine Firewall gibt).

Beispiel

»Es soll geprüft werden, dass neben Autor und Titel des Dokuments auch immer der Aufbewahrungsort eingegeben wird.«

● R1: Die Anforderung ist im Passiv formuliert (»... soll geprüft werden«, »... eingegeben wird«), die Akteure fehlen.

● R7: Es muss klar sein, welcher Autor gemeint ist. Ähnliche Fragen gibt es zum Aufbewahrungsort.

● R3: Die Prozesswörter »prüfen« und »eingeben« sind unvoll-ständig spezifiziert. Wer prüft wann, wer gibt wann etwas ein?

● R4: In der Anforderung steckt eine unvollständig spezifizierte Bedingung. Was soll geschehen, wenn der Aufbewahrungsort nicht eingegeben wurde?

● R5: Es muss nachgefragt werden, ob der angegebene Sachverhalt auch wirklich immer gelten soll.

57

Sprachschablonen

Die SOPHISTen geben dafür das Schema A B C D E F vor:

● A klärt, wann und unter welchen Bedingungen die Aktivität stattfindet.

● B ist MUSS (Pflicht), SOLL (Wunsch) oder WIRD (Absicht).

● C ist immer »das System« oder eine konkrete Nennung des Systems.

● D ist eine von drei Möglichkeiten: Die erste beschreibt eine selbständige Systemaktivität (»tut«), die zweite eine vom System angebotene Funktion (»bietet jemandem die Möglichkeit, zu tun«), die dritte die Inanspruchnahme einer von Dritten angebotenen Funktion (»ist fähig zu tun, wenn bestimmte Voraussetzungen gegeben sind«).

● E enthält Ergänzungen, insbesondere ein Objekt.

● F ist das eigentliche Prozesswort (was passiert).

58

Beispiel

Nach Ende der Bürozeiten (=A) soll (=B) das System (=C) dem Operator die Möglichkeit bieten (=D), alle neuen Anmeldungen auf einem externen Datenträger (=E) zu sichern (=F).

Bei einem automatischen Backup fiele Teil D (und das Wort »zu«) weg.

Natürlich ist zu prüfen, ob im Satz noch implizite Annahmen stecken; beispielsweise scheint es definierte Bürozeiten zu geben.

Ebenso ist der Allquantor »alle« zu prüfen.

59

16.7 Konzepte und Komponenten der Spezifikation

Die Ausrichtung auf die Anforderungen

Sehr oft enthält ein Dokument, das als Spezifikation bezeichnet wird, tatsächlich eine Beschreibung der Realisierung auf mehr oder minder hohem Niveau, also einen Entwurf.

● Wenn Programmierer ohne entsprechende Ausbildung eine Spezifikation verfassen, kommt dabei meist ein schlecht getarnter Entwurf heraus.

● Denn sie sind daran gewöhnt, in Lösungen zu denken,

Auch wenn eine strikte Trennung zwischen Spezifikation und Entwurf unmöglich ist, sollte man versuchen, in der Spezifikation die Anforderungen zu sammeln, also die Perspektive des Klienten beizubehalten.

61

Spezifikation der Funktion - 1

Die Funktion einer Software ist die in der Zeit ablaufende Transformation von Eingabedaten in Ausgabedaten.

Die Funktionsbeschreibung sagt also aus,

● wann welche Daten benötigt werden,

● wann welche Daten erzeugt werden,

● welche Mittel in welcher Menge dazu beansprucht werden.

Ist der Zeitpunkt der Ausführung oder die zeitliche Ordnung der Ausgabe irrelevant, so wird der Zeitaspekt auf die Reihenfolge beschränkt oder ganz weggelassen. Dabei wird unterstellt, dass die Effizienz insgesamt ausreicht.

Nicht leichtfertig auf den Zeitaspekt verzichten!

 

62

Spezifikation der Funktion - 2Die Daten, um die es bei einem Software-System letztlich geht, sind die Ausgaben des Systems.

Die Eingaben sind erforderlich, um die Ausgaben zu erzeugen, sie sind kein Selbstzweck.

● Wenn eine Eingabe nicht zur Erzeugung der Ausgabe benötigt wird, sollten wir sie auch nicht spezifizieren.

Wir gehen also von den Daten aus, die unser System liefern soll.

● Natürlich schließt der Begriff der Daten alle Außenwirkungen des Systems ein.

Die Kommunikation zwischen dem zu entwickelnden System und seiner Umgebung steht darum am Anfang aller Überlegungen, wie Anforderungen formuliert und formalisiert werden können.

● Es ist sinnvoll, von idealer Technologie auszugehen, also Systemaspekte, die nicht aufgabenbezogen sind, auszuklammern.

63

Beispiele

● Context Diagram von Structured Analysis

● Use-Case-Diagramme in UML

● Actigrams und Datagrams in SADT, wobei auch die Betriebsmittel erfasst werden

● Vernetzungsphase in Jackson System Development (JSD)

● Die Vernetzungsphase folgt in JSD auf die Modellierungsphase, in der der Ist-Zustand erfasst wird.

In jedem Fall gilt:

Eine genaue Übersicht der Daten, die aus dem System kommen oder in das System fließen, mit ihren logischen Zusammenhängen ist der Kern jeder Spezifikation.

64

Anwendungsfälle (Use Cases)

65

Wesentliche Merkmale eines Anwendungsfalls (AF) sind:

● Neben dem System ist immer mind. ein Akteur (actor) beteiligt. (=Rolle eines mit dem System interagierenden Benutzers oder eines externen Systems)

● Anstoß durch ein spezielles Ereignis (einen Trigger), das ein Akteur – der Hauptakteur – auslöst.

● Ein AF ist zielorientiert, der Akteur möchte das Ziel erreichen.

● Ein AF beschreibt alle Interaktionen zwischen dem System und den beteiligten Akteuren.

● Ein AF endet, wenn das angestrebte Ziel erreicht ist oder wenn klar ist, dass es nicht erreicht werden kann.

use case — A sequence of interactions between an actor (or actors) and a system triggered by a specific actor, which produces a result for an actor.

Jacobson et al. (1992)

Beispiel: Use Case - 1

66

Name Authentifizieren

Ziel Der Kunde möchte Zugang zu einem Bankautomaten BA42 erhalten

Vorbedingung – Der Automat ist in Betrieb, die Willkommen-Botschaft wird angezeigt– Karte und PIN des Kunden sind verfügbar

Nachbedingung – Der Kunde wurde akzeptiert– Die Leistungen des BA42 stehen dem Kunden zur Verfügung

Nachbedingungim Sonderfall

Der Zugang wird verweigert, die Karte wird entweder zurückgegeben oder einbehalten, die Willkommen-Botschaft wird angezeigt

Akteure Kunde (Hauptakteur), Banksystem

Beispiel : Use Case - 2

67

Normalablauf1. Der Kunde führt eine Karte ein

2. Der BA42 liest d. Karte und sendet d. Daten z. Prüfung ans Banksystem

3. Das Banksystem prüft, ob die Karte gültig ist

4. Der BA42 zeigt die Aufforderung zur PIN-Eingabe

5. Der Kunde gibt die PIN ein

6. Der BA42 liest die PIN und sendet sie zur Prüfung an das Banksystem

7. Das Banksystem prüft die PIN

8. Der BA42 akzeptiert den Kunden und zeigt das Hauptmenü

Beispiel : Use Case - 3

68

Sonderfall 2a Die Karte kann nicht gelesen werden2a.1 Der BA42 zeigt die Meldung »Karte nicht lesbar« (4 s)2a.2 Der BA42 gibt die Karte zurück2a.3 Der BA42 zeigt die Willkommen-Botschaft

Sonderfall 2b Die Karte ist lesbar, aber keine BA42-Karte2b.1 Der BA42 zeigt die Meldung »Karte nicht akzeptiert« (4 s)2b.2 Der BA42 gibt die Karte zurück2b.3 Der BA42 zeigt die Willkommen-Botschaft

Sonderfall 2c Das Banksystem ist nicht erreichbar2c.1 Der BA42 zeigt die Meldung »Banksystem nicht erreichbar« (4 s)2c.2 Der BA42 gibt die Karte zurück2c.3 Der BA42 zeigt die Willkommen-Botschaft

Sonderfall 3a Die Karte ist nicht gültig oder gesperrt3a.1 Der BA42 zeigt die Meldung »Karte ungültig oder gesperrt« (4 s)3a.2 Der BA42 zeigt die Meldung »Karte wird eingezogen« (5 s)3a.3 Der BA42 behält die Karte ein3a.4 Der BA42 zeigt die Willkommen-Botschaft

2. Der BA42 liest d. Karte und sendet d. Daten z. Prüfung ans Banksystem3. Das Banksystem prüft, ob die Karte gültig ist

Beispiel : Use Case - 4

69

Sonderfall 5a Der Kunde bricht den Vorgang ab5a.1 Der BA42 zeigt die Meldung »Vorgang wird abgebrochen« (2 s)5a.2 Der BA42 gibt die Karte zurück5a.3 Der BA42 zeigt die Willkommen-Botschaft

Sonderfall 5b Der Kunde reagiert nach 5 Sekunden nicht5b.1 Der BA42 zeigt die Meldung »Keine Aktivität, Abbruch« (2 s)5b.2 Der BA42 gibt die Karte zurück5b.3 Der BA42 zeigt die Willkommen-Botschaft

Sonderfall 6a Das Banksystem ist nicht erreichbar→ Schritt 2c.1

Sonderfall 7a Die erste oder zweite eingegebene PIN ist falsch7a.1 Der BA42 zeigt die Meldung »Falsche PIN« (4 s)→ Schritt 4

Sonderfall 7b Die dritte eingegebene PIN ist falsch7b.1 Der BA42 zeigt die Meldung »PIN dreimal falsch« (5 s)→ Schritt 3a.2

5. Der Kunde gibt die PIN ein6. Der BA42 liest die PIN und sendet sie zur Prüfung an das Banksystem7. Das Banksystem prüft die PIN

Merkmale / Use Case Diagramme

Anwendungsfälle beschreiben also aus der Außensicht, was das System leisten soll und welche Interaktionen dazu notwendig sind.

● Jeder Anwendungsfall muss das Systemverhalten für eine konkrete Situation vollständig spezifizieren (inkl. Ausnahmefälle).

Charakteristisch

● Aufbau auf Basis eines Formulars mit bestimmten Feldern

● Normalablauf (normal = Ziel wird erreicht)

● Sonder- und Ausnahmefälle

● Klarheit über den aktiven Teil (Akteur oder System)

Use-Case-Diagramme mit

● Generalisierungsbeziehung zwischen Use Cases bzw. Akteuren

● Benutzt-Beziehung (include)

● Erweitert-Beziehung (extend)

70

Beispiel: Use-Case-Diagramm

71

Strukturierung von Use Cases

Aus fachlicher Sicht hat es sich bewährt, zwischen Hauptfunktionen und Basisfunktionen zu unterscheiden.

● Hauptfunktionen beschreiben die geforderte fachliche Funktionalität des Systems.

● Beispiele: »Kontostand abfragen«, »Auszug drucken«,

● Basisfunktionen werden typisch in Hauptfunktionen verwendet und liefern dort einen Beitrag zur Funktionalität.

● Beispiel: »Authentifizieren«

Die Akteure stehen außerhalb des modellierten Systems.

Die Anwendungsfälle sind als Pakete gruppiert und durch Beziehungen (include und extend) miteinander verknüpft.

72

Aktivitäten - 1

73

Aktivität Anmerkungen

Bestimme alle Akteure und alle Ein- und Ausgaben

Dazu sind die folgenden Fragen hilfreich: – Welche äußeren Ereignisse gibt es?– Wer nutzt oder verwaltet das System?– Wer liefert Eingaben?– Wer verwendet die Ausgaben und Resultate?

Lege die Systemgrenzen fest

Die Systemgrenzen definieren, welche Komponenten und -Funktionen zum System gehören und welche nicht.

Identifiziere und formuliere die Anwendungsfälle der Hauptfunktionen

Die Anwendungsfälle der identifizierten Hauptfunktionen werden grob formuliert. Es muss sichergestellt werden, dass die Anwendungsfälle die Funktionalität vollständig abdecken.

Strukturiere die Anwendungsfälle und die Akteure

Die Beziehungen zwischen Akteuren und Anwendungsfällen sowie zwischen den Anwendungsfällen selbst werden identifiziert. Die Anwendungsfälle werden, wenn sinnvoll, in Pakete gruppiert.

Aktivitäten - 2

74

Aktivität Anmerkungen

Beschreibe den Normalablauf der Anwendungsfälle

Der Normalablauf, also der Weg zum angestrebten Ziel des Hauptakteurs, sollte zuerst formuliert werden.

Beschreibe alle Sonderfälle und Alternativabläufe

Es ist zu klären, welche Sonderfälle und welche Alternativabläufe auftreten können und wie diese vom Normalablauf abweichen.

Extrahiere gleiche Interaktionssequenzen

Gleiche Interaktionssequenzen können als Basisfunktionen definiert und an mehreren Stellen verwendet werden. Mit Hilfe der Generalisierungsbeziehung können Abläufe generisch spezifiziert, dann spezialisiert und wiederverwendet werden.

Prüfe zusammen mit dem Klienten die Anwendungsfälle

Die Anwendungsfälle werden vom Klienten in Reviews geprüft und, nachdem alle Korrekturen und Verbesserungen eingearbeitet sind, freigegeben.

Zusammenfassung: Anwendungsfälle

● werden durch Use-Case-Diagramme im Überblick dargestellt

● werden iterativ

● identifiziert

● modelliert

● formuliert

● geprüft

● können nur in enger Zusammenarbeit mit dem Klienten erstellt werden. Sie sind als Kommunikationsmedium besonders geeignet, um die Ist- und Soll-Abläufe mit den Fachleuten zu diskutieren und abzustimmen

● helfen den Entwicklern, die Welt der Anwendung zu verstehen (und Kandidaten für das Begriffslexikon zu erkennen)

● sind eine gute Grundlage für Prototypen, Testfälle und die Benutzungsdokumentation

75

Das Mengengerüst

Jede Lösung (eine Datenstruktur oder ein Algorithmus) hat ein bestimmtes Einsatzspektrum, auch hinsichtlich der Problemgröße.

Darum ist das Mengengerüst, die Angabe der Mengen und Größen, die für die Software Bedeutung haben, ein wesentlicher Bestandteil der Spezifikation.

Ebenfalls im Mengengerüst: Leistungsmerkmale

Alternative: Geforderte Leistungsmerkmale eines Systems (Antwortzeiten, Speicherbedarf usw.) als nichtfunktionale Anforderungen.

 

Alle Angaben definieren die Obergrenzen; eventuell sind aber auch Untergrenzen oder typische Werte von Bedeutung.

 76

Mengengerüst - Beispiel

Ein Depot, in dem viele Objekte, die durch eine Nummer und eine Bezeichnung identifiziert sind, einzeln gelagert sind.

Der aktuelle Lagerbestand wird auf einem Bildschirm angezeigt.

Im Mengengerüst sollten folgende Angaben definiert sein:

● Zahl der Lagerplätze

● Länge der Artikelnummern

● Länge der Artikelbezeichnungen

● Zahl gleicher Objekte

● Veränderungsrate (bewegte Objekte pro Stunde)

● Dauer bis zur Aktualisierung der Anzeige

 

77

16.8 Muster und Normen für die Spezifikation

Vorlagen: IEEE Std 830 (1998)

Recommended Practice for Software Requirements Specifications.

Sie sieht die folgenden drei Kapitel vor.

1. Einleitung

2. Allgemeine Beschreibung

3. Einzelanforderungen

Die Einzelanforderungen müssen sinnvoll gegliedert sein. Sie muss die folgenden Informationen enthalten:

● Funktionale Anforderungen

● Qualitätsanforderungen

● Leistungsanforderungen

● Einschränkungen des Entwurfs

● Definition der externen Schnittstellen zu anderen Systemen

.

79

Struktur nach IEEE Std 830 (1998) - 1

80

1. Einleitung

1.1 Zweck Beschreibt den Zweck und den Leserkreis der Spezifikation.

1.2 Einsatzbereichund Ziele

Gibt an, wo X eingesetzt werden soll und welche wesentlichen Funktionen es haben wird. Wo sinnvoll, sollte definiert werden, was X nicht leisten wird. Beschreibt die mit X verfolgten Ziele.

1.3 Definitionen Dokumentiert alle verwendeten Fachbegriffe und Abkürzungen.

1.4 ReferenzierteDokumente

Verzeichnet alle Dokumente, auf die in der Spezifikation verwiesen wird. (Alternative: Liste im Anhang)

1.5 Überblick Beschreibt, wie der Rest der Spez. aufgebaut ist, insbesondere, wie Kapitel 3 strukturiert ist.

Struktur nach IEEE Std 830 (1998) - 2

81

2. Allgemeine Beschreibung

2.1 Einbettung Beschreibt, wie X in seine Umgebung eingebettet ist und wie X mit den umgebenden Komponenten und Systemen zusammenspielt. Dazu werden die Schnittstellen, Kommunikationsprotokolle etc. definiert.

2.2 Funktionen Skizziert die wichtigsten Funktionen von X.

2.3 Benutzerprofile Charakterisiert die Benutzergruppen von X und die Voraussetzungen, die diese jeweils mitbringen (Ausbildung, Know-how, Sprache, ...).

2.4 Einschränkungen Dokumentiert Einschränkungen, die die Freiheit der Entwicklung reduzieren (z.B. Prozessmodell, Basis-Software, Ziel-Hardware).

2.5 Annahmen undAbhängigkeiten

Nennt explizit die Annahmen und externen Voraussetzungen, von denen bei der Spezifikation ausgegangen wurde.

3. Einzelanforderungen

3.i Anforderung i Beschreibt die Anforderung i so genau, dass bei der Verwendung der Spezifikation (im Entwurf usw.) keine Rückfragen dazu notwendig sind.

16.9 Regeln für Analyse und Spezifikation

Zehn Regeln - 1

Die wichtigsten Punkte dieses Kapitels sind nachfolgend in zehn Regeln zusammengefasst:

 

1.Ein Begriffslexikon anlegen und entwickeln

2.Von der Aufgabe ausgehen, nicht von ihrer Lösung

3.Nach den Daten (Objekten) suchen, nicht die (vermuteten) Programmabläufe beschreiben

4.Die Abstraktionsebene nicht innerhalb derselben Darstellung wechseln

83

Zehn Regeln - 2

5. Die Spezifikation nach Aspekten organisieren und Checklisten verwenden, die dabei weiterentwickelt werden

6. Ein Mengengerüst bilden

7. Den Kunden (Anwender) einbeziehen

8. Sprachen und Werkzeuge verwenden, die die Regeln unterstützen

9. Die Spezifikation der Konfigurationsverwaltung unterstellen und so bald wie möglich prüfen, z.B. durch Reviews oder Prototypen

10.Die Spezifikation intensiv verwenden

84