16 Analyse und Spezifikation

Präsentation zum Thema: "16 Analyse und Spezifikation"—  Präsentation transkript:

1 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

2 Stellenwert der Anforderungen
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 Die Anforderungen des Kunden an die Software sind die wichtigsten Informationen in einem Software-Projekt.

3 16.1 Die Bedeutung der Spezifikation im Entwicklungsprozess

4 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.

5 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.

6 Der Nutzen der Spezifikation
In der Praxis gibt es viele schlechte Spezifikationen; oft gibt es gar keine. Die Spezifikation ist aber notwendig für die Abstimmung mit dem Kunden bzw. mit dem Marketing, den Entwurf und die Implementierung, das Benutzungshandbuch, die Testvorbereitung, die Abnahme, die Wiederverwendung, die Klärung späterer Einwände, Regressansprüche usw., eine spätere Re-Implementierung.

7 Nachteile bei fehlender Spezifikation - 1
Die Anforderungen bleiben ungeklärt, sie werden darum auch nicht erfüllt. 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. Die Basis für das Handbuch fehlt, es wird darum phänomenologisch, d.h. experimentell, verfasst. Ein gutes Handbuch ist ein umformulierter Auszug aus der Spezifikation! Darum taugt es auch als Spezifikation. 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.

8 Nachteile bei fehlender Spezifikation - 2
Wenn bei der Abnahme nicht entschieden werden kann, ob das System richtig arbeitet, wird die Korrektheit zur Glaubensfrage. Oft zeigen sich echte oder vermeintliche Mängel der Software erst nach längerem Gebrauch. Ohne Spezifikation kann diese Unterscheidung aber nicht getroffen werden. Wer eine Software(-Komponente) wiederverwenden will, muss wissen, was sie leistet. Das ist in der Spezifikation dokumentiert. Wenn ein System ausgemustert und ersetzt wird, ist Aufwärtskompatibilität gefordert (vgl. Heninger et al., 1978).  „Spezifikation im Kopf“ gibt es nicht!

9 16.2 Die Analyse

10 Analyse und Jewish motherhood
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)

11 Grundbegriffe der Analyse
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

12 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.

13 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!

14 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.

15 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!

16 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“? ...

17 Die Soll-Analyse Gefahr: 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.

18 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.

19 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!

20 Techniken der Analyse - 1

21 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!

22 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“!

23 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.

24 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.

25 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.

26 16.3 Begriffslexikon und Begriffsmodell

27 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“

28 Informationen im Begriffslexikon
Begriff und Synonyma (im Sinne der Spezifikation) Bedeutung (Definition, Erklärung) Abgrenzung (wo ist dieser Begriff nicht anzuwenden?) Gültigkeit (zeitlich, räumlich, sonst) Fragen der Bezeichnung, Eindeutigkeit u. A. Unklarheiten, die noch nicht beseitigt werden konnten 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.

29 Beispiel 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

30 Hinweis Im Begriffslexikon klar unterscheiden zwischen
Objekten der realen Welt, Rollen oder Typen der realen Welt und Daten der Software.

31 Begriffsmodell Durch 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.

32 16.4 Anforderungen

33 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!

34 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.

35 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!

36 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.“

37 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!

38 Beispiele 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. angemessenes Handbuch Das Benutzungshandbuch wird gemäß Richtlinie ABC aufgebaut. Es wird vom Gutachter N.N. geprüft.

39 Anforderungen zur Benutzbarkeit - 1
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.

40 Anforderungen zur Benutzbarkeit - 2
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. Weitere Themen zur Benutzbarkeit: Methoden zur Verbesserung der Usability Personas

41 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.

42 16.5 Die Spezifikation im Überblick

43 Spezifikationsbegriffe - 1
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

44 Spezifikationsbegriffe - 1
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 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.

45 Angestrebte Eigenschaften
Die Spezifikation ist im Idealfall inhaltlich zutreffend: Sie gibt die Vorstellungen des Kunden richtig wieder. vollständig: Jede (in einem Kopf oder in einem Dokument) vorhandene Anforderung ist in der Spezifikation enthalten. 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. neutral (oder abstrakt): Die Spezifikation schränkt die Realisierung nicht über die wirklichen Anforderungen hinaus ein. nachvollziehbar: Die Quellen der Anforderungen sind dokumentiert, die Anforderungen sind eindeutig identifizierbar. objektivierbar: Das realisierte System kann gegen die Spezifikation geprüft werden. auch (missverständlich) „testbar“.

46 Darstellung und Form Eine ideale Spezifikation ist
leicht verständlich: Alle Interessenten sind in der Lage, die Spezifikation zu verstehen. präzise: Die Spezifikation schafft keine Unklarheiten und Interpretationsspielräume. leicht erstellbar: Die Anfertigung und Nachführung der Spezifika­tion sind einfach und erfordern keinen nennenswerten Aufwand. 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.

47 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.

48 Abgrenzung Spezifikation-Entwurf - 2
Die geforderte Neutralität der Spezifikation ist als Ideal sinnvoll, aber praktisch nicht durchzuhalten. Dafür gibt folgende Gründe: Vorhandene Komponenten sind einzubeziehen. Vorgaben von außen betreffen die Struktur und Details Die Beschreibung des Lösung ist einfacher. Erst das gegliederte System ist überschaubar. Die Konsistenz der Spezifikation wird erst durch die Realisierung geklärt. Die Fragen an die Spezifikation entstehen erst im Entwurf. 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“.

49 16.6 Die Darstellung der Spezifikation

50 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..

51 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.

52 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.

53 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.

54 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.

55 Einige Sprachregeln - 1 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?

56 Einige Sprachregeln - 2 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).

57 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.

58 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).

59 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.

60 16.7 Konzepte und Komponenten der Spezifikation

61 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.

62 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!

63 Spezifikation der Funktion - 2
Die 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.

64 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.

65 Anwendungsfälle (Use Cases)
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) 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.

66 Beispiel: Use Case - 1 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 Nachbedingung im Sonderfall Der Zugang wird verweigert, die Karte wird entweder zurückgegeben oder einbehalten, die Willkommen-Botschaft wird angezeigt Akteure Kunde (Hauptakteur), Banksystem

67 Beispiel : Use Case - 2 Normalablauf
1. 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ü

68 Beispiel : Use Case - 3 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 Sonderfall 2a Die Karte kann nicht gelesen werden 2a.1 Der BA42 zeigt die Meldung »Karte nicht lesbar« (4 s) 2a.2 Der BA42 gibt die Karte zurück 2a.3 Der BA42 zeigt die Willkommen-Botschaft Sonderfall 2b Die Karte ist lesbar, aber keine BA42-Karte 2b.1 Der BA42 zeigt die Meldung »Karte nicht akzeptiert« (4 s) 2b.2 Der BA42 gibt die Karte zurück 2b.3 Der BA42 zeigt die Willkommen-Botschaft Sonderfall 2c Das Banksystem ist nicht erreichbar 2c.1 Der BA42 zeigt die Meldung »Banksystem nicht erreichbar« (4 s) 2c.2 Der BA42 gibt die Karte zurück 2c.3 Der BA42 zeigt die Willkommen-Botschaft Sonderfall 3a Die Karte ist nicht gültig oder gesperrt 3a.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 ein 3a.4 Der BA42 zeigt die Willkommen-Botschaft

69 Beispiel : Use Case - 4 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 Sonderfall 5a Der Kunde bricht den Vorgang ab 5a.1 Der BA42 zeigt die Meldung »Vorgang wird abgebrochen« (2 s) 5a.2 Der BA42 gibt die Karte zurück 5a.3 Der BA42 zeigt die Willkommen-Botschaft Sonderfall 5b Der Kunde reagiert nach 5 Sekunden nicht 5b.1 Der BA42 zeigt die Meldung »Keine Aktivität, Abbruch« (2 s) 5b.2 Der BA42 gibt die Karte zurück 5b.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 falsch 7a.1 Der BA42 zeigt die Meldung »Falsche PIN« (4 s) → Schritt 4 Sonderfall 7b Die dritte eingegebene PIN ist falsch 7b.1 Der BA42 zeigt die Meldung »PIN dreimal falsch« (5 s) → Schritt 3a.2

70 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)

71 Beispiel: Use-Case-Diagramm

72 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.

73 Aktivitäten - 1 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.

74 Aktivitäten - 2 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.

75 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

76 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.

77 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

78 16.8 Muster und Normen für die Spezifikation

79 Vorlagen: IEEE Std 830 (1998) Recommended Practice for Software Requirements Specifications. Sie sieht die folgenden drei Kapitel vor. Einleitung Allgemeine Beschreibung 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 .

80 Struktur nach IEEE Std 830 (1998) - 1
1. Einleitung 1.1 Zweck Beschreibt den Zweck und den Leserkreis der Spezifikation. 1.2 Einsatzbereich und 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 Referenzierte Dokumente 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.

81 Struktur nach IEEE Std 830 (1998) - 2
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 und Abhä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.

82 16.9 Regeln für Analyse und Spezifikation

83 Zehn Regeln - 1 Die wichtigsten Punkte dieses Kapitels sind nachfolgend in zehn Regeln zusammengefasst: Ein Begriffslexikon anlegen und entwickeln Von der Aufgabe ausgehen, nicht von ihrer Lösung Nach den Daten (Objekten) suchen, nicht die (vermuteten) Programmabläufe beschreiben Die Abstraktionsebene nicht innerhalb derselben Darstellung wechseln

84 Zehn Regeln - 2 Die Spezifikation nach Aspekten organisieren und Checklisten verwenden, die dabei weiterentwickelt werden Ein Mengengerüst bilden Den Kunden (Anwender) einbeziehen Sprachen und Werkzeuge verwenden, die die Regeln unterstützen Die Spezifikation der Konfigurationsverwaltung unterstellen und so bald wie möglich prüfen, z.B. durch Reviews oder Prototypen Die Spezifikation intensiv verwenden