ANFORDERUNGSANALYSE UND SPEZIFIKATION TEIL 1

Transkript

1 3. Kapitel ANFORDERUNGSANALYSE UND SPEZIFIKATION TEIL 1 Software Engineering Prof. Dr. Wolfgang Schramm

2 Übersicht 1 1. Einführung in das Software Engineering 2. Softwareprozesse 3. Anforderungsanalyse und -Spezifikation 4. Softwareentwurf 5. Entwurfsmuster 6. Programmierung 7. Software-Qualitätssicherung und -Prüfung 8. Konfigurationsverwaltung 9. Software-Wartung

3 Lernziele des Kapitels 2 Sie lernen die wichtigsten Begriffe des Requirements Engineering (RE) kennen. Sie verstehen, warum der Anforderungsprozess wichtig ist. Sie lernen die verschiedenen Arten von Anforderungen kennen. Sie lernen, welche Tätigkeiten zum Anforderungsprozess gp gehören und wie der Anforderungsprozess abläuft. Sie lernen, welche Personen an der Anforderungsphase beteiligt sind. Sie lernen welche Dokumente erstellt werden müssen und wie sie aufgebaut sind. Sie lernen wie man mit Anforderungen und mit Kunden umgeht. Sie lernen verschiedene Techniken für die Erhebung der Anforderungen kennen.

4 Inhalt 3 3. Anforderungen 3.1. Einführung / Motivation 3.2. Requirements Engineering (RE) 3.3. Bestandteile der Dokumentation 3.4. Erhebung von Anforderungen 3.5. Zielgruppen der Anforderungen 3.6. Anforderungsarten 3.7. Notation für Anforderungen Dokumentation der Anforderungen 3.9. Aufbau und Inhalt der Spezifikation/ des Pflichtenhefts Erheben der Anforderungen, Techniken der Erhebung Anforderungsmanagement Qualitätssicherung von Anforderungen Änderungsmanagement Anwendungsfälle für die Anforderungsanalyse

5 Die 10 wichtigsten Erfolgsfaktoren bei IT Projekten 4 1. Executive support 18% 2. User involvement 16% 3. Experienced project manager 14% 4. Clear business objectives 12% 5. Minimized scope 10% 6. Standard software infrastructure 8% 7. Firm basic requirements 6% 8. Formal methodology 6% 9. Reliable estimates 5% 10. Other criteria 5% [Quelle: CHAOS Report, Standish Group International, Inc.]

6 Die 10 wichtigsten Erfolgsfaktoren bei IT Projekten 5 1. Executive support 18% 2. User involvement 16% 3. Experienced project manager 14% 4. Clear business objectives 12% 5. Minimized scope 10% 6. Standard software infrastructure 8% 7. Firm basic requirements 6% 8. Formal methodology 6% 9. Reliable estimates 5% 10. Other criteria 5% [Quelle: CHAOS Report, Standish Group International, Inc.]

7 6 Warum Anforderungen? 50 % der im Quellcode gefundenen Fehler sind auf mangelhafte Anforderungen zurückzuführen. Die Beseitigung eines Fehlers der in der Programmierphase gefunden wird, ist um den Faktor 20 teurer als die Beseitigung während der Anforderungsphase. Im Abnahmetest Faktor 100. [Poh08]

8 Warum Anforderungen? 7 Kosten senken: Geringere Herstellungskosten. (Senken der Fehlerkosten!) Weniger Reklamationen und Nachbesserungen. Geringere Pflegekosten. Risiken verkleinern: Kundenerwartungen besser erfüllen. Zuverlässigere Prognosen für Termine und Kosten. Aber : Die wirtschaftliche Wirkung von Requirements Aber : Die wirtschaftliche Wirkung von Requirements Engineering ist immer indirekt; das RE selbst kostet nur!

9 8 Anforderungsanalyse und spezifikation: Wirtschaftlichkeit

10 Requirement 9 Kunde im Mittelpunkt 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 a 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 ofstudying andrefining system, hardware, orsoftware requirements. IEEE Glosar (IEEE Std (1990))

11 Begriffe 10 Eine Anforderung (engl. requirement) ist: Eine Bedingung oder Eigenschaft, die ein System oder eine Person benötigt, um ein Problem zu lösen oder ein Ziel zu erreichen. ih Eine Bedingung oder Eigenschaft, die ein System oder eine Systemkomponente aufweisen muss, um einen Vertrag zu erfüllen oder einem Standard zu genügen.

12 Anforderung 11 Anforderungen allgemein Eine Bedingung oder Fähigkeit, die von einer Person zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird. Software Anforderungen Eine Bedingung oder Fähigkeit, die eine Software erfüllen oder besitzen muss, um einen Vertrag, eine Norm oder ein anderes, formell bestimmtes Dokument zu erfüllen. (IEEE ) Anforderungen an ein System beschreiben die Dienste, die ein Kunde von einem System erwartet, und die Gegebenheiten, unter denen es entwickelt wird und laufen soll.

13 Requirements Engineering Ziel 12 Requirements Engineering Verstehen und beschreiben, was die Kunden wünschen oder brauchen. Eine menschenzentrierte Sicht. Ziel: zufriedene Kunden Was sind Kunden? Warum wünschen oder brauchen? Warum nicht gleich programmieren?

14 13 Requirements Engineering Anforderungsanalyse und spezifikation (Requirements Analysis & Specification) heißt der Prozess des Herausfindens (Elicitation), Analysierens (Analysis), Dokumentierens (Specification) und Überprüfens (Validation) dieser Anforderungen. Anforderungen verwalten (Requirements Management): Freigabe (Baselining) Änderung (Modification) Verfolgung (Traceability) Requirements Engineering = Requirements Specification + Requirements Management

15 Weg der Anforderungen (vereinfacht) 14 Spezifikation Entwurf Anforderungssammlung Code Kunde Entwickler

16 Anforderungsanalyse und spezifikation: Zusammenhang 15 Bestimmung und Analyse der Anforderungen Achtung: in der Literatur werden dieselben Begriffe oft für verschiedene Dinge benutzt. Z.B. wird der Begriff Anforderungsanalyse oft für Analyse und Spezifikation zusammen verwendet. Lastenheft Spezifikation der Anforderungen Pflichtenheft

17 Anforderungsspezifikation 16 Anforderungsspezifikation Die Zusammenstellung aller Anforderungen an ein System. Synonym: Anforderungsdokument. d Der Begriff Spezifikation ist im Alltag nicht immer eindeutig: Dokument oder Prozess. Anforderungs, Lösungs oder Produktspezifikation.

18 Pflichtenheft 17 Wird nicht einheitlich verwendet: Synonym zu Anforderungsspezifikation. Spezifikation + Überblick über Lösung. Spezifikation + Elemente der Projektabwicklung. Also: Pflichtenheft mit Vorsicht verwenden, d.h. vorher klären, was der Kunde darunter versteht.

19 Probleme bei der Anforderungsanalyse und spezifikation 18 Alan Chapman

20 Detaillierungsgrad der Anforderungsbeschreibungen 19 Anforderungen können sehr abstrakt oder sehr detailliert sein (bis hin zu funktionalen Spezifikationen). Anforderungen erfüllen zwei Aufgaben Basis für eine Ausschreibung für eine Software: Die Erledigung der Aufgaben muss interpretierbar sein, d.h. einer Lösung darf nicht vorgegriffen werden. Die Anforderungen müssen so beschrieben werden, dass sich mehrere Interessenten um den Zuschlag bewerben können, die sich zum Beispiel durch verschiedene Lösungsansätze unterscheiden. Basis für einen Vertrag über eine Software Entwicklung: Die Aufgaben der Software müssen detailliert festgelegt sein Anforderungssammlung Lastenheft Anforderungspezifikation Pflichtenheft h ft Beide Dokumente zusammen Anforderungsdokument (Requirements Document) ) des Systems (nach [Dav93])

21 20 Anforderungen versus Entwurf Volksweisheit: WAS = Spezifikation/Anforderung, WIE = Entwurf Aber: Ist folgender Satz eine Anforderung oder eine bereits eine Entwurfsentscheidung? Das System druckt eine wahlweise nach Namen oder Land alphabetisch sortierte Liste von Teilnehmern mit Nummer, Name, Vorname, Mitgliedschaft undland. Auf jeder Seite sinduntenlinks das Erstellungsdatum und unten rechts die Seitenzahl aufgedruckt. WAS vs. WIE ist kontextabhängig und liefert keine brauchbare Abgrenzung zwischen Anforderungen und Entwurfsentscheidungen. Auch in der Anforderungsphase werden Entscheidungen über die Ausgestaltung des Systems getroffen.

22 Lastenheft/Pflichtheft 21 Was? Vision Wie? Was? Wie? Lastenheft Auftrag- geber Pflichtenheft Auftragnehmer nach [Poh08]

23 Was? versus Wie? 22 Sukzessive Einschränkung des Lösungsraums abstrakt konkret Vision Was Wie Was Wie Was Wie Was Wie Fertiges System Anforderungen Entwurf der Entwurf der Architektur Komponenten Implementierung WAS? = Problembeschreibung WIE?= Lösungsbeschreibung nach [Poh08]

24 Vom Benutzerwunsch zum System 23 Benutzeranforderungen Aussagen in natürlicher Sprache, Diagramme zur Beschreibung der Dienste, die das System leisten soll und Randbedingungen, unter denen es betrieben wird. Systemanforderungen, Pflichtenheft Detailliere Festlegung g der Dienste und Beschränkungen. Soll präzise sein. Kann Vertrag zwischen Kunde und Softwareentwickler sein. Spezifikation des Softwareentwurfs Abstrakte, grobe Beschreibung des Softwareentwurfs. Grundlage für den exakten Feinentwurf und dessen Umsetzung. Hier werden weitere Details zu den Systemanforderungen hinzugefügt. nach [Som01]

25 Wer braucht welche Information? 24 Problem- Beschreibung Kunden- Anforderungen Entwickler- Anforderungen System- Entwurf Benutzung Akzeptanztest Ausschreibung: Lastenheft, Benutzeranforderungen Benutztes System Benutzbares System Vertragsgrundlage: Systemtest, IntegrationstestPflichtenheft, Ausführbares funktionale Spezifikation, System Systemanforderungen Komponenten- Anforderungen Reproduktion des Komponententest Pflichtenhefts Ausführbare für den Entwickler-internen Komponente Gebrauch Komponenten- Entwurf Komponenten- Implementierung

26 Zielgruppen für Anforderungen 25 Benutzeranforderungen Manager des Kunden Endbenutzer des Systems Techniker des Kunden Manager des Softwareherstellers Systemarchitekten Systemanforderungen, Pflichtenheft Endbenutzer des Systems Techniker des Kunden Systemarchitekten; Projektmanager Softwareentwickler Spezifikation des Softwareentwurfs f Techniker des Kunden Systemarchitekten Softwareentwickler

27 Ablaufschema der Anforderungsanalyse 26 Durchführbarkeitsstudie Bestimmung und danalyse der Anforderungen Spezifikation der Anforderungen Durchführbar- keitsbericht Systemmodelle Benutzer- und Systemanforderungen Validierung der Anforderungen Pflichtenheft nach [Som01]

28 Aufgaben einer Anforderungsanalyse und spezifikation 27 Anforderungen als Grundlage für Kommunikation Ausschreibung und Vertragsgestaltung Systemintegration, Wartung und Pflege Systemarchitektur Sekundäre Aufgaben Erhöhung der Mitarbeiterzufriedenheit Eröffnung von Rationalisierungs- potenzialen Optimierung des Kundennutzens

29 28 Konkreter Ablauf der Anforderungsanalyse und Systemspezfikation

30 Abstraktionsebenen von Anforderungen 29 Beispiel: Geschäft «Auf dem bestehenden Schienennetz sollen mehr Leute transportiert werden.» System «Die Minimaldistanz zwischen zwei Zügen ist immer größer als der maximale Bremsweg des nachfolgenden Zuges.» Software «Der maximale Bremsweg muss alle 100 ms neu berechnet werden.» Quelle: M.Glinz / Zürich /RE-Vorlesung

31 Beispiele für Anforderungen 30 R1: Die Bedienungsschnittstelle für den Hausbesitzer muss einfach zu handhaben sein. R2: Das Hausinformationssystem soll monatlich eine Aufstellung der erlaubten und verweigerten Zugänge zum Hausinneren generieren. R3: Ist die an der Tastatur des Zugangssystems eingegebene PIN korrekt, hebt das System die Sperre der Zugangstür auf und protokolliert den Zugang mit Datum, Uhrzeit und eingegebener PIN. R4: Das System soll spätestens am 1.Mai 2009 auf dem Markt verfügbar sein. R5: Die Freigabe des Schließungsmechanismus soll bei korrekt eingegebener Pin spätestens nach 0,8 Sekunden erfolgen. aus [Poh08]

32 32 Anforderungsarten 1/2 Funktionale Anforderungen (auch Verhaltensanforderungen) dfii definieren vom System bereitzustellende t Funktionen oder Services. Beispiele: Daten: Struktur,, Verwendung, Erzeugung, g, Speicherung, Übertragung, g, Veränderung. Funktionen: Ausgabe, Ablauf der Verarbeitung, Eingabe von Daten. Verhalten: Sichtbares dynamisches Systemverhalten, Zusammenspiel der Funktionen (untereinander und mit den Daten). Fehler: Normalfall und Fehlerfälle. Qualitätsanforderungen dfii definieren eine qualitative i Eigenschaften des gesamten Systems einer Komponente oder einer Funktion. Beispiele: Benutzerfreundlichkeit, Zuverlässigkeit. Wo immer möglich: messbare Angaben!

33 33 Anforderungsarten 2/2 Rahmenbedingungen (Constraints / Problembereichsanforderungen) sind organisatorische i oder technologische h Anforderungen, welche lh die Art und Weise einschränken, wie ein Produkt entwickelt wird. Beispiele: Einzuhaltende/zu verwendende Schnittstellen. Normen und Gesetze. Datenschutz, Datensicherung. Explizite Vorgaben des Auftraggebers. Leistungsanforderungen Datenmengen (durchschnittlich/im Extremfall). Verarbeitungs /Reaktionsgeschwindigkeit (durchschnittlich/im Extremfall). Verarbeitungszeiten und intervalle. Wo immer möglich: messbare Angaben!

34 35 Funktionale vs. nichtfunktionale Anforderungen Der Begriff nichtfunktionale Anforderung (NFR) ist ein Sammelbegriff für ungenügend spezifizierte funktionale Anforderungen oder qualitative Anforderungen. Die Abgrenzung zwischen nicht funktionalen und funktionalen Anforderungen ist nicht scharf. Eine nicht funktionale Anforderung: Das System muss den unauthorisierten Zugriff auf die Kundenstammdaten verhindern, soweit diestechnischmöglich ist. Durch Verfeinerung werden daraus funktionale Anforderungen: Der Zugriff auf die Kundenstammdaten muss über eine Login Prozedur mit Passworten geschützt t werden. Traditionell: Unterscheidung nur in funktionale vs. nicht-funktionale Anforderungen. Das ist zu ungenau (s.o.). In der Praxis werden weniger klare Anforderungen gerne als NFR eingeordnet, ohne sie zu hinterfragen. Dadurch fließen unterspezifizierte Anforderungen in den Entwicklungsprozess ein.

35 Qualitätsanforderungen Qualitätsmodell nach ISO/IEC 9126

36 Beschreibung von Qualitätsanforderungen 39 Typisches Vorgehen: Fragen stellen: «Wie fehlertolerant soll das System sein?» Antworten quantifizieren mit Maßen und Abnahmebedingungen. direkte Maße: «Die Fehlertoleranz wird in MTTF gemessen und soll grösser als 106 Betriebsstunden sein.» indirekte Maße: «Die Bedienung des System gilt als erlernbar, wenn pro Person nicht mehr als zwei Tage Schulung aufgewendet werden müssen.» «Für jede Hauptfunktion beträgt der Lernaufwand für ihre erfolgreiche Anwendung im Mittel weniger als eine Stunde.»

37 Beispiele für Qualitätsanforderungen 40 Es soll möglich sein, dass die gesamte nötige Kommunikation zwischen der APSE (Entwicklungsumgebung für Ada) und dem Benutzer durch den Ada Standardzeichensatz ausgedrückt wird. Der Systementwicklungsprozess und lieferbare Dokumente sollen dem Vorgehen und den Ergebnissen entsprechen, die in XYZCo SP STAN 95 STAN dfii definiert sind. Das System soll den Benutzern des Systems keine persönlichen Informationenüber Kunden preisgeben, abgesehen vom Namen und der Referenznummer. Zu beachten: (Nicht nur) Qualitätsanforderungen sollen so formuliert werden, dass sie eindeutig geprüft werden können.

38 41 Beispiele für Verhaltensanforderungen Der Benutzer soll die gesamte anfängliche Menge der Datenbanken durchsuchen oder eine Teilmenge davonauswählen auswählen können. Das System soll geeignete Betrachtungswerkzeuge bieten, damit der Benutzer Dokumente aus dem Dokumentenspeicher lesen kann. Jeder Bestellung soll ein eindeutiger Bezeichner (ORDER_ID) zugeordnet werden, undderder Benutzer soll diesen in den permanenten Speicher seines Kontos kopieren können. Zu beachten: genau: Vermeiden von Mehrdeutigkeiten konsistent: keine ki Widersprüche zwischen Anforderungen vollständig: Beschreibung des gesamten Systems In der Praxis (fast) nicht möglich!

39 Beispiele für Problembereichsanforderungen 42 Es sollte eine Standardbenutzungsschnittstelle zu allen Dt Datenbanken geben, die auf dem Z39.50 Standard d basiert. Aus urheberrechtlichen Gründen müssen einige Dokumente direkt bei der Ankunft gelöschtwerden werden. Abhängig von den Anforderungen des Benutzers werden diese Dokumente entweder lokal auf dem Systemserver ausgedruckt, um manuell zum Benutzer verschickt zu werden, oder sie werden an einen Netzwerkdrucker weitergeleitet. Zu beachten: Problembereichsanforderungen ergeben sich aus dem speziellen Anwendungsumfeld, in dem das System eingesetzt werden soll. Sie enthalten oft wesentliche Hintergrundinformationen. Fachleute aus dem Anwendungsumfeld lassen oft "offensichtliche " Fachleute aus dem Anwendungsumfeld lassen oft offensichtliche Informationen weg.

40 44 Das System im Kontext

41 Der Systemkontext 45 ist der Teil der Umgebung eines Systems, der für die Definition und das Verständnis der Anforderungen an das System relevant ist. Irrelevante Umgebung Systemkontext System Systemgrenze Kontextgrenze

42 Bedeutung des Kontexts 46 Anforderungen werden für einen bestimmten Kontext definiert. Erst die Kenntnis des Kontexts macht die Anforderungen interpretierbar ti und bestimmt tden Umfang. Anforderung: Das geplante Beförderungsmittel soll den Reisenden eine sichere und schnelle Reise zum Ziel ermöglichen. Kontext: Personen sollen vom Festland auf eine Insel transportiert werden. Die Insel hat keinen Platz für einen Flughafen. Also: die Dokumentation des Kontexts ist notwendig

43 Darstellung des Systemkontexts 47 Kontext Diagramme Quelle: MGli M.Glinz/ /Züi Zürich/ h/vorlesung RE

44 7 Hauptprobleme bei der Anforderungsbeschreibung 50 Unklare Zielvorstellungen. Hohe Komplexität. Sprachbarrieren. Sich ständig verändernde Anforderungen (requirements creeping). Schlechte Qualität. Unnötige Merkmale. Ungenaue Planung.

45 Gründe für Probleme bei der Analyse 51 Wenn die Spezifikation selbst keine Rolle spielt, dann ist auch die Analyse von sehr geringer Bedeutung. Viele Entwickler sehen nicht, dass der Kunde meist keine Veränderung will, auch wenn er eine Verbesserung will. Entwickler denken oft, dass sie wissen, was der Kunde will oder braucht. Der Kunde lässt den Analytiker verhungern, u.a. weil er nicht versteht, dass so etwas Geld kostet (nur Code darf Geld kosten). Kunden halten Anforderungen bewusst oder unbewusst zurück und präsentieren sie spät. Der Kunde (besser: bestimmte Mitarbeiter des Kunden) sehen ihre Privilegien dahin schmelzen, sie sabotieren die Analyse.

46 52 Anforderungsanalyse und spezifikation: 7 Ideal Merkmale Adäquatheit Vollständigkeit Beschreibt das, was der Kunde will bzw. braucht angemessen. Beschreibt alles, was der Kunde will bzw. braucht. Widerspruchsfreiheit Verständlichkeit it Für alle Beteiligten, t Kunden wie Informatiker. Sonst ist die Spezifikation nicht realisierbar. Eindeutigkeit Prüfbarkeit Risikogerechtheit Vermeidet Fehler durch Fehlinterpretationen. Feststellen können, ob das realisierte System die Anforderungen erfüllt. Umfang umgekehrt proportional zum Risiko, das man eingehen will.

47 Anforderungsanalyse wie geht s weiter? 54 Die Inhalte kennen sie jetzt! aber wie werden sie dokumentiert?

48 Was trifft am besten? 55 Haus Villa

49 Techniken der Analyse 57 Auswertung vorhandener Dokumente und Daten. Beobachtungen Befragung mit geschlossenen strukturierten offenen Fragen Interview Modell Entwicklung Experimente Prototyping Partizipative Entwicklung (Analyseanteil)

50 Was ist zu tun bei der Analyse? 58 Analytiker soll die einschlägigen Vorschriften und Regeln sichten und die Aussagen herausfiltern, fl die seine Arbeit betreffen. Wenn möglich sollte er an der täglichen Arbeit der Betroffenen (die mit der Software arbeiten, deren Funktion durch die Software ersetzt wird) teilnehmen: er wird Dinge sehen und hören, die ihm niemand erzählt. Der Analytiker kann den Kunden systematisch befragen (am besten per persönlichem Gespräch) erkennen von Lücken. Wenn abstrakte Vorstellung vom Zielsystem nicht ausreicht ausprobieren (Experiment, Modell, Prototyp). Partizipative Entwicklung Aufhebung von Analyse und Entwicklung, Software wächst in die Umgebung hinein.

51 Notationsformen für die Anforderungen 59 Schnittstelle Verhalten Struktur Ablauf Natürliche Sprache Standardisierte Formulare Standardisierte Dokumente Formale Sprachen Datenflussgraphen Struktogramme Entity-Relationship- Diagramme Logische Spezifikationen Funktionale Spezifikationen Axiomatische Spezifikationen Entscheidungstabellen Zustandstabellen t Petri-Netze UML

52 60 Anforderungsbeschreibung in natürlicher Sprache Beispiel Der Bediener drückt eine Wahltaste und bezahlt den geforderten Betrag. Sobald die Summe der eingeworfenen Münzen den geforderten Betrag übersteigt, wird das Getränk zubereitet und ausgegeben. Ferner wird das Wechselgeld berechnet und ausgegeben. Der Bedienvorgang Bdi endet, dtwenn das Gtäk Getränk entnommen wird idund wenn die Bedienung für länger als 45s unterbrochen wird. Mit einer Annulliertaste kann der Bedienvorgang jederzeitabgebrochen werden. Bereits eingeworfenes Geld wird beim Drücken der Annulliertaste zurückgegeben. Nach dem Drücken einer Wahltaste kann entweder bezahlt oder eine andere Wahltaste gedrückt werden. Die zuletzt getätigte Auswahl gilt. a) Lesen Sie den Text zügig durch. Fallen Ihnen irgendwelche Probleme auf? b) Lesen Sie den Text nochmals langsam und sorgfältig und markieren Sie alle Problemstellen.

53 61 Anforderungsbeschreibung in natürlicher Sprache Probleme im Beispiel Der Bediener drückt eine Wahltaste und bezahlt den geforderten Betrag. Sobald die Summe dereingeworfeneneingeworfenen Münzendengeforderten Betrag übersteigt, wird das Getränk zubereitet und ausgegeben. Ferner wird das Wechselgeld berechnet und ausgegeben. Der Bedienvorgang endet, wenn das Getränk entnommen wird und wenn die Bedienung für länger als 45s unterbrochen wird. Mit einer Annulliertaste kann der Bedienvorgang jederzeit abgebrochen werden. Bereits eingeworfenes Geld wird beim Drücken der Annulliertaste zurückgegeben. gg Nach dem Drücken einer Wahltaste kann entweder bezahlt oder eine andere Wahltaste gedrückt werden. Die zuletzt getätigte Auswahl gilt. Unklarheit: Reihenfolge von Auswahl und Bezahlung? Fehler: Was ist bei Betragsgleichheit? Mehrdeutigkeit: Ist und und oder oder oder gemeint? Unklarheit: Abbruch während der Ausgabe des Getränks? Widerspruch: Die oben geforderte Möglichkeit der Annullierung wird ausgeschlossen.

54 Natürliche Sprache Vor und Nachteile 62 Vorteile Leicht verständlich. Hilfreich für eine oberflächliche, einführende Beschreibung. Nachteile Mehrdeutig. Überflexibel. Keine Möglichkeit, Vollständigkeit und Konsistenz (automatisch) zu überprüfen. Keine Möglichkeit, formale Verifikation oder Beweise anzuwenden.

55 Natürliche Sprache 63 Die Qualität natürlichsprachiger Anforderungsspezifikation lässt sich systematisch verbessern durch: geeignete Strukturierung des Dokuments, Regeln zur sprachlichen Formulierung von Anforderungen, kontrollierten Umgang mit Redundanz, konsequente Verwendung eines Glossars.

56 Regeln für natürlichsprachliche Anforderungen 64 Sätze mit vollständiger Satzstruktur zum jeweiligen Verb bilden. Anforderung im Aktiv formulieren mit dfii definiertem Subjekt. Nur Begriffe verwenden, die im Glossar definiert sind. Nomen mit unspezifischer Bedeutung (diedaten ( die, der Kunde, die Anzeige,...) hinterfragen und durch spezifische Nomen ersetzen oder mit präzisierenden Zusätzen ergänzen. Für Verben, die Prozesse beschreiben, feste Bedeutungen festlegen. Nominalisierungen hinterfragen; sie können unvollständig spezifizierte Prozesse verbergen. Anforderungen in Hauptsätzen formulieren. Nebensätze nur zur Vervollständigung (wann, mit wem, unter welchen Bedingungen,...). Pro Einzelanforderung ein Satz.

57 Spezifikation mittels Szenarien 69 Ein Szenario beschreibt ein konkretes Beispiel für die Erfüllung bzw. Nichterfüllung eines oder mehrerer Ziele. enthält typischerweise eine Folge von Interaktionsschritten und setzt diese in Bezug zum Systemkontext. wird meist in natürlicher Sprache beschrieben. ist gut geeignet um Information über den Kontext zu dokumentieren: Personen oder andere Systeme, die mit dem System interagieren. Vorbedingungen, die zu Beginn es Szenarios erfüllt sein müssen. Reale oder imaginäre Örtlichkeiten, in der die Ausführung eines Szenarios stattfindet.

58 70 Szenario Beispiel Karl möchte mit seinem PKW zum Potsdamer Platz 1 nach Berlin fahren. Karl benutzt das Navigationssystem des Fahrzeugs, um die kürzeste Wegstrecke zu ermitteln. Er wählt Ziel eingeben. Das Navigationssystem zeigt im Display Bitte Ort nennen oder manuell eingeben an. Karl wähl die Spracheingabe und spricht Berlin. Aufgrund von Hintergrundgeräuschen und der schlechten Aussprache erkennt das System das Wort nicht eindeutig. Es zeigt das wahrscheinlichste Wort an Schwerin. Es zeigt zudem an Ihr Eingabe konnte nicht eindeutig erkannt werden sowie die folgenden Interaktionsmöglichkeiten: Zielort akzeptieren (ja/nein) Neueingabe (neu) Ähnliche Ort anzeigen (ähnlich) Manuelle Eingabe Karl spricht ähnlich, und das System listet die Orte Schwerin, Berlin etc. auf. Karl spricht Berlin und das System wähl Berlin als Zielort aus.

59 Spezifikation mittels Szenarien: Vor und Nachteile 72 + Szenarien können zur Strukturierung von Anforderungsdokumenten verwendet werden. + Szenarien verdeutlichen den Mehrwert von Anforderungen für verschiedene Stakeholder. + Szenarien unterstützen die Kommunikation zu den Stakeholdern und helfen damitweitere Anforderungen zu identifizieren. + Szenarien können zur Validierung eingesetzt werden. Zu viele Szenarien beschreiben denselben Sachverhalt. Szenarien versperren den Blick für das Allgemeingültige.

60 Regeln zur Formulierung von Szenarien 73 Sprache/Grammatik 1. Schreiben sie Szenarien in der Gegenwartsform. 2. Schreiben sie Szenarien in der Aktivform. 3. Schreiben sie in einfachen Sätzen. 4. Vermeiden sie Modalverben (z.b. müssen, können, sollen, wollen, mögen, dürfen). Struktur 5. Trennen sie jede Interaktion deutlich von anderen Interaktionen. 6. Beschreiben sie aus dem Blickwinkel eines Außenstehenden. 7. Benennen sie explizit die Akteure. 8. Benennen sie das Ziel des Szenarios explizit. 9. Fokussieren sie bei der Szenariobeschreibung auf die Erfüllung des Ziels. [Poh08]

61 Spezifikation mit Anwendungsfällen 74 Ein Anwendungsfall (use case) spezifiziert Aktionsfolgen (Szenarien) einschließlich Ausnahmesequenzen, die ein System odereine eine Systemkomponente bei der Interaktion mit externen Objekten ausführt, um einen Mehrwert zu erbringen. Anwendungsfälle gruppieren verschiedene Szenarien. Informal durch Text, z.t. formatiert durch Schlüsselworte. Teilformal, z.b. mit Zustandsautomaten. [RJB05]

62 75 Spezifikation mit Anwendungsfällen: Vor und Nachteile + Modellierung aus Benutzersicht: leicht verstehbar und überprüfbar. + Hilft bei der Abgrenzung zwischen System und Kontext. + Dekomposition möglich. Zusammenhänge / Abhängigkeiten zwischen Senariennicht Szenarien nicht modelliert. Statische Struktur nicht modelliert.

63 Szenario vs. Use Case 76 Ein Szenario ist kontextreicher: Kann mehrere Anwendungsfälle in Beziehung setzen. Kann aber auch eine konkrete Ausgestaltung eines Anwendungsfalls sein. Ein Anwendungsfall ist allgemeiner. Ein Anwendungsfall wird immer von einem Akteur initiiert. Ein Szenario kann das Zusammenspiel mehrerer Akteure darstellen.

64 Datenflussdiagramme (DFD) 77 Geben den Datenfluss eines Prozesses oder einer Tätigkeit wiederzugeben (z. B. die Datenverwendung und Veränderung bei der Angebotserstellung in einem Handelsunternehmen). Gb Geben eine funktionale Perspektive des Systems wieder id Sie nützlich um Sequenz von Aktionen zu verdeutlichen vom Input (i (Eingabe des Anwenders) bis zum Output (Ausgabe des Systems)

65 Beispiel DFD 78 Bild aus:

66 Datenflussdiagramme Notation 79 Name Input/Output (Terminator) Name Funktion (Prozess) Name Datenbank (File) Name Datenfluss

67 Verhaltensspezifikation mit Automaten 82 Modellierung des zeitlichdynamischen Systemverhaltens. Basis: Zustandsautomaten. Teilformales, konstruktives Verfahren. + Leicht nachvollziehbar und simulierbar. + Dekomposition möglich. Aktionen meist nur genannt, aber nicht modelliert. Statische Struktur nicht modelliert.

68 85 Atomare Anforderungen ein wichtiges Qualitätskriterium Eine Anforderung ist atomar, wenn diese Anforderung einen isolierten Sachverhalt beschreibt. Sie kann nicht weiter untergliedert werden. Folgende Information gehören dazu: Anforderungsnummer: ein eindeutiger Identifier, zur Zuordnung/Verfolgbarkeit über den gesamten Life Cycle. Typ der Anforderung: Constraints, Funktionale Anforderung, Nichtfunktionale Anforderung, Beschreibung: der Inhalt der Anforderung. Begründung: Die Motivation hinter der Anforderung. Quelle: Person, die die Anforderung zum ersten Mal erwähnt hat. Fit Kriterium: Die messbare Beschreibung der Anforderung, die erlaubt zu überprüfen, ob die Anforderung erfüllt ist. Event/Use Case: Verweis auf den Geschäftsvorfall aus dem die Anforderung erwachsen ist. Priorität: Wie wichtig ist die Anforderung im Hinblick auf das gesamte Produkt. Konflikte: Gibt es Anforderungen, denen die Anforderung widerspricht. Andere Materialien: Verweis auf Dokumente oder andere Artefakte, die für diese Anforderung von Bedeutung sind.

69 Beispiel: Atomare Anforderungen 86 Anforderungsnummer: 75 Typ der Anforderung: Funktionale Anforderung Beschreibung: Das Produkt soll einen Alarm auslösen, wenn die Wetterstation die eingelesenen Daten nicht übertragen kann. Begründung: Fhl Fehler bei bider Übermittlung von Daten Dt können ein Hinweis i auf einen Defekt in der Wetterstation sein, die evlt. Wartung benötigt. Die Daten zur Vorhersage des Straßenlage können aus diesem Grund unvollständig dgsein. Quelle: Karl Heinz Müller Fit Kriterium: Für jede Wetter Station soll die Anzahl der pro Stunde übermittelten Daten innerhalb des durch den Hersteller definierten Wertebereiches liegen. Event/Use Case: UC 3.4 WerteÜbertragen Priorität: Hoch Konflikte: Keine Andere Materialien: Herstelleranleitung der Wetterstation IN34.67 Beispiel angelehnt an [RR06]

70 Beschreibung NFRs 90 Typisches Vorgehen: Fragen stellen: «Wie fehlertolerant soll das System sein?» Antworten quantifizieren mit Maßen und Abnahmebedingungen direkte Maße: «Die Fehlertoleranz wird in MTTF gemessen und soll grösser als 106 Betriebsstunden sein.» indirekte Maße: «Die Bedienung des System gilt als erlernbar, wenn pro Person nicht mehr als zwei Tage Schulung aufgewendet werden müssen» «Für jede Hauptfunktion der Lernaufwand für ihre erfolgreiche Anwendung im Mittel weniger als eine Stunde beträgt.»

71 Regeln zur Formulierung von NFRs/Zielen Formulieren sie NFRs kurz und prägnant. 2. Verwenden sie Aktivformulierung. 3. Formulieren sie überprüfbare NFRs. 4. Verfeinern sie nicht überprüfbarer NFRs. 5. Formulieren sie den Mehrwert eines NFRs. 6. Geben sie eine Begründung für das NFR an. 7. Vermeiden e sie Lösungsansätze. sät

72 Personas 94 Imaginäre Repräsentation/Beschreibung der Zielgruppe/Nutzergruppe g Sollte so detailliert beschrieben werden, dass jeder im Team das Gefühl hat, diese Person(a) zu kennen. d h ll Für 1 2 der wichtigsten Nutzerrollen. Der Benutzer wird ersetzt durch die Persona.

73 Rahmenwerke für Anforderungsdokumente 95 VDI/VDE Standard 3694: Referenzstruktur für Lasten und Pflichtenheft h f IEEE Standard : Referenzstruktur für Systems Requirements Spezifikationen IEEE Standard für Software Requirementsspezifikationen Volere Template von Robertson & Robertson htm Template von Sören Lauesen dk/people/slauesen/papers/requirementssl 07.doc

74 96 Standard Formular

75 Pflichtenheft [nach IEEE/ANSI ] 1/ Einleitung (introduction) Ziel des Anforderungsdokuments d (purpose) 1.2. Anwendungsbereich des Produkts (scope) 1.3. Definitionen, Akronyme undabkürzungen (definitions) 1.4. Referenzen (references) 1.5. Überblick über den Rest des Dokuments (overview) 2. Allgemeine Beschreibung (description) 2.1. Produktperspektive (perspective) 2.2. Produktfunktionen (functions) Benutzercharakteristika (characteristics) 2.4. Allgemeine Beschränkungen (constraints) 2.5. Voraussetzungen und Abhängigkeiten gg (assumptions and dependencies)

76 Pflichtenheft [nach IEEE/ANSI ] 2/ Spezifische Anforderungen (requirements) funktionale Anforderungen (Stark abhängig von der Art des Softwareprodukts) 3.2. nicht funktionale Anforderungen 3.3 externe Schnittstellen 3.4 Design Constraints 3.5 Anforderungen an Performance 3.6. Qualitätsanforderungen Sonstige Anforderungen 4. Anhänge (appendices) 5. Index

77 Gliederungsrichtlinie: Beispiel sd&m 99 aus: Andreas Birk (2004). Anforderungsspezifikation in großen IT-Projekten. Jahrestagung der GI- Fachgruppe Requirements Engineering, Kaiserslautern.

78 Pflichtenheft [nach DIN 66905] Zielbestimmung 4. Produkt-Funktion 1.1. Muss Kriterien 1.2. Wunsch Kriterien 1.3. Abgrenzungskriterien 2. Produkt Einsatz Anwendungsbereiche 2.2. Zielgruppen 2.3. Betriebsbedingungen 3. Produkt Bedingungen 3.1. Software 3.2. Hardware 3.3. Orgware Produkt Schnittstellen 5. Produkt-Leistungen 6. Benutzer-Schnittstelle 7. Qualitäts-Zielbestimmung 8. Globale Testfälle 9. Ergänzungen

79 Struktur des Pflichtenhefts (nach [Som01]) 1/2 101 Kapitel Vorwort Einleitung Begriffe Definition der Benutzeranforderungen Systemarchitektur Beschreibung Sollte erwartete Leserschaft des Dokuments festlegen und Versionsgeschichte beschreiben. Begründung für die Entwicklung einer neuen Version. Zusammenfassung der Veränderungen durch die Version. Notwendigkeit des Systems. Kurzbeschreibung der Funktionen und Zusammenspiel spe mit anderen e Systemen. Übereinstimmung des Systems mit den Zielen des Unternehmens. Festlegung der verwendeten Fachbegriffe (Annahme: Leser hat keine Erfahrung mit Fachwissen). Dienste für Benutzer. Nichtfunktionalen Anforderungen. Zu befolgende Produkt- und Entwicklungsstandards. Grober Überblick über erwartete Systemarchitekturzeigt die Verteilung der Funktionen auf Systemmodule. Kennzeichnen wiederverwendeter d Komponenten.

80 Struktur des Pflichtenhefts (nach [Som01]) 2/2 102 Kapitel Beschreibung Spezifikation der Systemanforderungen Genauere Beschreibung der funktionalen und nichtfunktionalen Anforderungen. Ggf. weitere Einzelheiten zu nichtfunktionalen Anforderungen (Bsp. Definition iti von Schnittstellen t zu anderen Systemen). Systemmodelle Beziehungen zwischen den Systemkomponenten und dem System und seiner Umgebung g (Klassen-, Datenfluss-, semantische Datenmodelle) Systementwicklung Grundlegende Voraussetzungen, auf denen das System basiert. Erwartete Veränderungen. Anhänge Genauere spezifische Informationen, die sich auf die Anwendung beziehen. Index Fachbegriffe, Diagramme, Funktionen

81 Volere Template 1/3 103 PROJECT DRIVERS: 1. The Purpose of the Product 2. Client, Customer, Stakeholders 3. Users of the Product PROJECT CONSTRAINTS: 4. Mandated dconstraints 5. Naming Conventions and Definitions 6. Relevant Facts and Assumptions FUNCTIONAL REQUIREMENTS: 7. The Scope of the Work 8. The Scope of the Product 9. Functional and Data Requirements

82 Volere Template 2/3 104 NON FUNCTIONAL REQUIREMENTS: 10. Look and Feel 11. Usability and Humanity 12. Performance 13. Operational 14. Maintainability and Support 15. Security 16. Cultural and Political 17. Legal

83 Volere Template 3/3 105 PROJECT ISSUES: 18. OpenIssues 19. Off the shelf Solutions 20. New Problems 21. Tasks 22. Migration to the New Product 23. Risks 24. Costs 25. User Documentation 26. Waiting Room 27. Ideas for Solutions

84 Qualitätskriterien für Anforderungsartefakte 107 Vollständigkeit Nachvollziehbarkeit Korrektheit Eindeutigkeit Verständlichkeit Konsistenz Überprüfbarkeit ba e Bewertet nach Wichtigkeit und Stabilität Für einzelne Anforderungen aber auch für das ganze Dokument!

85 Darstellungsregeln 108 Einzelanforderungen in kleinen Einheiten fassen: eine Kernaussage pro Einzelanforderung. Zu jedem geforderten Resultat die Funktion und die Eingabedaten, welche das Resultat erzeugen, spezifizieren. Mögliche Ausnahmesituationen spezifizieren. Implizite Annahmen aufdecken und explizit formulieren. Leistungs und Qualitätsanforderungen quantitativ spezifizieren. All Quantifizierungen kritisch hinterfragen. Anforderungen strukturieren (zum Beispiel durch Kapitelgliederung). ll Redundanz nur dort, wo für leichtes Verständnis notwendig. Päi Präzise spezifizieren. i

86 Zielgruppen für das Pflichtenheft 109 Systemkunden Festlegen von Anforderungen Überprüfen, ob die Anforderungen geeignet sind Verantwortlich für Änderungen Manager Erstellen des Angebots Planung des Entwicklungsprozesses Systementwickler Verstehen, was für ein System entwickelt werden soll Systemtester Entwickeln von Validierungstests Systemwarter Verstehen des Systems und der Beziehungen zwischen seinen Bestandteilen

87 Beispiel: Lastenheft und Pflichtenheft Die Software muss über Mittel zur Darstellung externer, von anderen Werkzeugen erzeugter Dateien verfügen und auf sie zugreifen können Der Benutzer sollte über Möglichkeiten i zur Definition i i externer Dateitypen verfügen. 1.2 Jeder externe Dateityp kann eine damit verknüpfte Anwendung besitzen, mit der die Datei bearbeitet b t wird. 1.3 Jeder externe Dateityp kann als bestimmtes Symbol auf dem Bildschirm des Anwenders dargestellt werden. 1.4 Es sollten Möglichkeiten zur Definition des externen Symbols für externe Dateitypen durch den Benutzer bereitgestellt werden. 1.5 Wenn ein Benutzer ein Symbol auswählt, das eine externe Datei 1.5 Wenn ein Benutzer ein Symbol auswählt, das eine externe Datei repräsentiert, so soll die durch dieses Symbol dargestellte Datei mit der Anwendung geöffnet werden, die mit dem entsprechenden externen Dateityp verknüpft ist.

88 111 Entwickleranforderung

89 Literatur 113 Klaus Pohl,