Home

Software-Projekt ¨Uberblick I - FB3 - Uni Bremen

1. E Verst ndnis von alkar Verk ufer Anforderungsanalyse En zei Aufgaben i gib artikel0 Ist Analyse EE ee gt Daten ee Ist Zustand Was ee T Den Ablauf der Kommunikation kann man verbal beschreiben oder zu etwas formaleren Notationen greifen Hierf r eignen sich insbesondere die UML Sequenzdiagramme die f r solche Zwecke entworfen wurden Wichtig ist bei allen gew hlten Notationen dass sie einerseits pr zise genug sind was f r stark formalisierte Notationen spricht und dass sie auch vom Kunden verstanden werden was meist gegen stark formalisierte Notationen spricht Sequenzdiagramme sind jedoch ein recht einfach zu erl uterndes Mittel das nach kurzen Erl uterungen auch Nichtinformatikern verst ndlich sein kann F r zustandsbasierte Kommunikation eignen sich auch Zustandsdiagramme Ebenso kann man mit Aktivit tsdiagrammen komplexere Abl ufe gut beschreiben Bsp Das Diagramm hier beschreibt die Kommunikation als eine Abfolge von Nachrichten die sich die Akteure gegenseitig zuschicken Einige davon wie z B gib detail erhalten eine Antwort Es bescheibt dieselbe Abfolge wie der nat rlichsprachliche Text weiter oben Das Sequenzdiagramm muss aber hierf r noch erg nzt werden um die Bedeutung der Nachrichten Ist Zustand Was Verstandnis von Q Q Q Bestandteile Struktur i Dokumente die verwendet und produziert werden Aufgaben o Bezeichnung Ko
2. Wegweiser Analysetechniken Wann wird welche Analysetechnik eingesetzt Rainer Koschke Uni Bremen Software Projekt Analysetechniken Wintersemester 2008 09 62 82 Ist Zustand Soll Zustand Folgen Auswertung vorhandener Daten Dokumente Beobachtungen Befragung geschlossene Fragen offene Fragen hybride Fragen Prototyping partizipative Entwicklung Rainer Koschke Uni Bremen Software Projekt ooo Wintersemester 2008 09 63 82 2008 11 04 2008 11 04 Analysetechniken Software Projekt L A nford eru ngsa na l yse N tea Selb ausen Baten Daten Dokumente 2 Beobachtungen jee ES ng der Techniken eee a offene Fragen ie lysetechniken ee A partizipative Entwicklung Zum Abschluss der Ist und Sollanalyse fassen wir noch einmal die Techniken die wir kennen gelernt haben zusammen und bewerten ihre Eignung f r das Erfassen des Ist Zustands der Planung des Soll Zustands und der Absch tzung mittel und langfristiger Folgen unserer anvisierten Softwarel sung Die folgende Tabelle gibt einen berblick Ist Zustand Soll Zustand Folgen Auswertung vorhandener Daten Dokumente Beobachtungen Befragung geschlossene Fragen o offene Fragen o hybride Fragen o Prototyping partizipative Entwicklung 0 1 Die Auswertung vorhandener Dokumente ist ein Instrument rein fur die Erhebung des Ist Zustands we
3. Beispiel passives Storyboard Screen Auswahl Screen Kaufen TUNGSTEN 145 Euro Wollen Sie diesen Artikel kaufen SATTEL BROOKS MODELL B 120 78 Euro 49 S ttel 228 SATTEL SPECIALIZED BO PRO WOMEN 47 Euro Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 58 82 Beispiel passives Storyboard Software Projekt Screen Auswahl Screen Kaufen E emai eae Be Prototyping Beispiel passives Storyboard 2008 11 04 Bsp Bild 4 Im Kaufdialog wird nur der ausgew hlte Artikel angezeigt und der Kunde wird gefragt ob er den Artikel kaufen m chte Best tigt er mit der Schaltfl che Ja 7 dann wird der Artikel in den virtuellen Warenkorb des elektronischen Verkaufsassistenten gelegt der vom Verk ufer an der Kasse ausgelesen werden kann Mit der Schaltfl che Nein wird der Vorgang abgebrochen und man gelangt zum Auswahldialog zur ck Die Entscheidung maximal vier Artikel anzuzeigen haben wir in der Vorbereitung des Papierprototypen getroffen Wir hatten sehr schnell im ma stabgetreuen Modell feststellen k nnen dass mehr als vier Artikel nicht auf dem kleinen Monitor zu pr sentieren sind Wir haben jedoch vers umt irgendwie kenntlich zu machen dass mehr als vier Artikel als Ergebnis der Suchanfrage geliefert wurden aber nicht alle sichtbar sind Der Kunde fragt uns w hrend der Vorf hrung wie das denn z
4. 2008 11 04 2008 11 04 Anforderungsspezifikation nach IEEE Std 610 12 1990 Software Projekt E Definition Anforderungsanalyse SSE oar ITAA TEE EAA ATEA or achieve an objective L A nfo rd eru ngss p ezifi ka t 10 n specification document that specifies in a complete precise verifiable manner the requirements of a system or component and often the procedures for determining whether these provisions have been satisfied Anforderungsspezifikation nach IEEE Std 610 12 1990 software requirements specification SHS documentation ofthe essential requirements functions performance design constraints and attributes of the software and its external interfaces An die Ist und Sollanalyse schlieBt sich die Formulierung der Anforderungen an Die Sollanalyse ergibt was die Software leisten muss um die Schwachstellen die durch die Ist Analyse offenbar wurden zu beseitigen Die Sollanalyse hat jedoch nur die prinzipiellen Konzepte erarbeitet Diese miissen wir nun prazise ausarbeiten und am besten schriftlich festhalten In diesem Abschnitt setzen wir uns deshalb mit der Frage auseinander wie die Anforderungen formuliert sein sollen Bevor wir jedoch dazu kommen mussen wir uber ein paar grundlegende Begriffe einig werden Was ist denn eine Anforderungsspezifikation genau Im Englischen wird die Anforderungsspezifikation Requirement Specification genannt was sich aus Requirement fir Anforderung und Specification
5. Horizontaler vs vertikaler technischer Prototyp Vertikaler Prototyp realisiert ausgewahlte Aspekte des Softwaresystems vollstandig u ysschnittstelle Netz tenhaltung a Software Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 52 82 Horizontaler vs vertikaler technischer Prototyp S oftwa re P roj e kt Vertikaler Prototyp realisiert ausgew hlte Aspekte des Softwaresystems lt vollst ndig e se L sschnittstelle m 4 Soll Analyse Prototyping a oo HS 9 Horizontaler vs vertikaler technischer Prototyp Ne enhaltung N Software Der vertikale technische Prototyp realisiert ausgew hlte Aspekte des Softwaresystems vollst ndig durch alle Schichten hindurch Er stellt einen Durchstich durch das System dar Mit seiner Hilfe l sst sich die Zusammenarbeit verschiedener Schichten untersuchen Er findet auch bei inkrementeller Entwicklung Einsatz bei der die erste Ausbaustufe funktionst chtig ist wenn auch nicht alle Funktionen implementiert sind Dann wird der Durchstich in die Breite in den weiteren Ausbausstufen ausgedehnt um die restliche Funktionalit t zu implementieren Man geht also zuerst in die Tiefe und dann in die Breite bei diesem Vorgehen Wir setzen solche Prototypen w hrend der Anforderungsanalyse ein wenn wir kritische Anforderungen haben von denen wir nicht sicher sind dass wir sie realisieren k nnen Ansonsten werden sie auch gerne vor Entwurf der
6. Software Projekt Prof Dr Rainer Koschke Fachbereich Mathematik und Informatik Arbeitsgruppe Softwaretechnik Universitat Bremen Wintersemester 2008 09 Uberblick Anforderungsanalyse Anforderungsanalyse Anforderungsanalyse Lernziele o Herausforderungen o Aktivit ten o Ist Analyse Erhebungstechniken o Befragung Beobachtung o Soll Analyse Prototyping Zusammenfassung der Techniken o Anforderungsspezifikation Bedeutung Anzustrebende Eigenschaften Regeln Aufbau und Inhalt o Wiederholungsfragen Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 Lernziele o Ist und Soll Zustand ermitteln k nnen o Anforderungsspezifikation schreiben k nnen o Anforderungsspezifikation begutachten k nnen Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 3 82 5 82 2008 11 04 Lernziele Software Projekt Sea oracnn ngsanalyse z o Ist und Soll Zustand ermitteln k nnen Le rnzi el e o Anforderungsspezifikation schreiben k nnen o Anforderungsspezifikation begutachten k nnen Lernziele Bevor ein System implementiert werden kann m ssen die Anforderungen an das System erhoben werden Dieser Aufgabe widmet sich die Anforderungsanalyse Ihr Ziel ist es einen m glichst genauen und vollst ndigen Katalog von Anforderungen an ein System zu erfassen und zu beschreiben Die Anforderungen beschreiben ein Soll Konzept das V
7. Leistungsfaktoren H fi d o bewusst verlangte Sonderausstattung Leistungsfaktoren e ra u S 0 r e r u n ge n bei Erf llung Kundenzufriedenheit peared sonst Unzufriedenheit nicht erat Begeisternde Faktoren unbewusste W nsche n tzliche angenehme berraschungen steigern Zufriedenheit berproportional Daraus folgt nun nicht dass wir eigene Anforderungen hinzu erfinden sollten von denen wir glauben dass sie den Kunden vom Hocker rei en werden Schlie lich m ssen wir die Anforderungen implementieren und wenn sie vom Kunden nicht bestellt sind m ssen wir daf r bezahlen Wenn es uns aber gelingt solche Anforderungen in der Anforderungsanalyse zu identifizieren und dem Kunden vorzuschlagen so k nnen sie zum Vertragsgegenstand werden f r die er gerne Geld ausgibt Allerdings werden sie so dann schnell zu Leistungsfaktoren die bei Nichterf llung Unzufriedenheit hervor rufen Aber zumindest kann es f r den Kunden den Ausschlag geben sich f r unsere Dienste und nicht f r die unserer Mitbewerber zu entscheiden Wegweiser Erhebung der Anforderungen Was sind die wesentlichen Schritte zur Erhebung der Anforderungen Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 11 82 Softwa re P roj e kt Wegweiser Anforderu ngsanalyse ee ae A ktivitate n Erhebung der Anforderungen gt Was sind die wesentlichen Schritte zur Erhebung der Anforderungen Wegweiser 2003 11
8. lelo Werktags findet diese Operation ca 50 Mal am Tag statt samstags ca 80 Mal Tag Abends findet sie tendenziell Wenn der Kunde nichts Passendes findet oder der Verk ufer ihn unzureichend ber t geht der Kunde ohne zu kaufen Wenn der Kunde nicht komplett bezahlen kann schreibt der Verk ufer an wenn er den Kunden gut genug kennt Ansonsten bergibt ihm der Verk ufer den Artikel nicht Ein Umtausch ist nur m glich wenn ein Artikel vorher gekau wurde K ufer und Verk ufer verhalten sich kooperativ das hei t der Verk ufer ber t nach bestem Wissen und Gewissen und der Kunde liefert ihm hierf r notwendige Hintergrundinformationen zu seinen bereits gekauften Artikeln und seinen W nschen Was benutzt produziert Operation Die Operation berf hrt den Artikel aus dem Besitz des Ladens in den Besitz des K ufers Sie berf hrt den Geldbetr der zu entrichten ist vom Kunden in die Kasse des Verk ufers Ist Zustand Was Verstandnis von Bestandteile o Welche Vorrichtungen und Gelegenheiten zur Kommunikation gibt es im Rahmen welcher o Struktur o Aufgaben o Kommunikation Aufgaben o Dokumenten Laden Telefon o Daten o Wie lauft Kommunikation ab initiiert vom Kunden o Schwachstellen Zu Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 25 82 Ist Zustand Was Software Projekt ies Schwachstellen initiiert vom Kunden Seager nforde
9. 04 In diesem Abschnitt wenden wir uns den einzelnen Aktivit ten der Anforderungsanalyse zu Dazu geh ren die Ist Analyse die Soll Analyse und das Festhalten der Anforderungen in Form einer Anforderungsspezifikation Diese Aktivit ten haben eine nat rlichen Abfolge weil sie voneinander kausal abh ngen Allerdings werden sie in der Praxis meist wiederholt Schritte der Anforderungsanalyse Ist Analyse Ziel Verstandnis der Welt fur die Ist Zustand Softwarel sung angestrebt wird Ist Analyse 71 Bee H ufige Fehler o Entwickler sieht nicht dass Kunde primar keine Ver nderung sondern Verbesserung anstrebt ie o Kunde beschreibt selten was sich nicht ndern soll weil es gut genug ist o Kunde Endbenutzer wei nicht was dieser braucht Folgen von M ngeln Eigentliches Problem wird ignoriert Erforderlich Beobachtungsgabe Einfuhlungsvermogen Kommunikationsfahigkeit Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 12 82 Software Projekt een Aktivit ten en S Schritte der Anforderungsanalyse Ist Analyse a Einf hlungsverm gen Kommunikationsfahigkeit Die Aktivit t Ist Analyse zielt darauf ab den Ausschnitt der Welt zu verstehen f r den eine softwaretechnische L sung angestrebt wird Das hei t wir streben an den Ist Zustand genau zu verstehen und zu analysieren ber die Beschreibung des Ist Zustands hinaus entsteh
10. Angaben m ssen aber hinreichend konkretisiert werden Diese Regeln k nnen auch eine einfache Liste von Dos and Don ts sein wie sich die Schnittstelle dem Benutzer darstellen soll Beispielsweise ob kurze oder lange Fehlermeldungen vorzuziehen sind In jedem Fall gilt auch hier dass die Anforderungen objektivierbar sein m ssen Statt benutzerfreundlich sollte es also besser Persona X kann die Funkti Sortiment einsehen in zwei Minuten ausf hren nach einer Schulung von zehn Minuten hei en Charakteristika der Benutzer werden in Abschnitt 2 3 angegeben Bsp Hier w rden wir z B die Aufl sung des PDA Monitors f r PDAss die Farbtiefe die Eingabem glichkeiten ber Stift und nur wenige Tasten und die minimalen Schriftgr en etc angeben Hardwareschnittstellen Hardwareschnittstellen sind Schnittstellen zu Hardware die das System voraussetzt beziehungsweise bedient Dieser Abschnitt ist insbesondere f r eingebettete Systeme von gro er Bedeutung F r alle Arten von Systemen w rde man hier aber die zu unterst tzenden Prozessortypen beschreiben auf denen die Software sp ter laufen soll Hardware die eher der Benutzungsschnittstelle zuzuordnen ist wird in Abschnitt 2 1 2 beschrieben Inhalt der Anforderungsspezifikation nach IEEE Standard 2 Allgemeine Beschreibung Einbettung in ein Gesamtsystem 2 1 1 Systemschnittstellen 2 1 2 Benutzungsschnittstelle logische Charakteristika z B Monitorformat 2 1 3 Ha
11. Architektur angewandt um einzusetzende Technologien oder geplante Entw rfe zu untersuchen Prototypen fur Interaktion Storyboards Storyboards o dienen zur Implementierung von Prototypen o demonstrieren das zu diskutierende Systemverhalten als Geschichte Typen o passives Storyboard Papierprototyp o aktives Storyboard animierter Prototyp o interaktives Storyboard ausf hrbarer Prototyp Aufwand Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 53 82 Prototypen fiir Interaktion Storyboards Software Projekt L A nford eru ngsa na l yse gt dienen zur Implementierung von Prototypen Typen ee Prototyping re 5 passives Storyboard Papierprototyp Prototypen f r Interaktion Storyboards amp ka Starboard annie Pretty interaktives Storyboard ausf hrbarer Prototyp 2008 11 04 In der Anforderungsanalyse m ssen wir die Interaktion zwischen Benutzer und Anwender festlegen Dieser Interaktion nimmt eine Schl sselrolle ein weil ein Softwaresystem das alle gew nschten Funktionalit ten bietet dennoch unbrauchbar sein kann wenn man es nicht benutzen kann Aus diesem Grunde wollen schon sehr fr h Interaktion ausprobieren k nnen und sie Kunden und Benutzern vorstellen Hier k nnen wir Oberfl chenprototypen entwickeln Oberfl chenprototypen sind horizontale Prototypen bei denen die Interaktion untersucht oder demonstriert werden soll Meist dienen sie wenige
12. Bezug auf die Softwarearchitektur Horizontaler vs vertikaler technischer Prototyp Horizontaler Prototyp realisiert Aspekte einer spezifischen Ebene des Softwaresystems Bsp Oberfl chenprototyp Anwendungslogik Netzwerk Datenhaltung System Software Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 50 82 Horizontaler vs vertikaler technischer Prototyp Horizontaler Prototyp realisiert Aspekte einer spezifischen Ebene des Softwaresystems Bsp Anwendungsprototyp Benutzungsschnittstelle Netzwerk Datenhaltung System Software Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 51 82 Horizontaler vs vertikaler technischer Protot Software Projekt z Horizontaler Prototyp realisiert Aspekte einer spezifischen Ebene des lt Softwaresystems Bsp Anwendungsprototyp E a ngsanalyse I Benutzungsschnittstelle re gt Soll Analyse Prototyping Ee BE Horizontaler vs vertikaler technischer Prototyp Netzwerk Datenhattung N System Software Softwaresysteme k nnen zumindest konzeptionell in verschiedene Schichten eingeteilt werden die jeweils von bestimmten Aspekten abstrahieren Grob kann die Implementierung einteilen in die Schicht der Systemsoftware die durch das Betriebssystem zur Verf gung gestellt wird Schichten mit technischen Diensten wie Netzwerkkommunikation oder Datenhaltung sowie die Schicht die die eigen
13. Bildschirmmasken aufzulisten Es mt auch der Zusammenhang der Dialoge und der anderen Interaktionselementen mit den Anwendungsf llen d h der Funktionalit t im Kontext des Arbeitsflusses der unterst tzt werden soll beschrieben werden F r jede Eingabem glichkeit muss beschrieben sein was damit ausgel st werden kann und welche Ausgabe erfolgt Ebenso muss die Navigation zwischen allen Dialogen und etwaige Zust nde der Schnittstelle beschrieben sein Die Beschreibung soll so genau sein dass man daraus ohne weitere Schritte ein Benutzerhandbuch erstellen kann Die Entscheidung wie die Benutzungsschnittstelle auszusehen hat liegt also nicht beim Programmierer sp ter sondern steht von Anfang an fest 3 1 2 Hardwareschnittstelle 3 1 3 Softwareschnittstelle 3 1 4 Kommunikationsschnittstelle 3 2 Produktfunktionen In diesem Abschnitt werden die Produktfunktionen im Detail beschrieben Dieser Abschnitt bildet in der Regel mit de Benutzungsschnittstelle zusammen den umfangreichsten Teil Deshalb ist eine sinnvolle Glieder unabdingbar Wir werd weiter unten auf alternative Gliederungen eingehen Der Zusammenhang zwischen Benutzungsschnittstellen sowie alld anderen Schnittstellen und der hier beschriebenen Produktfunktionen muss klar gemacht werden Inhalt der Anforderungsspezifikation nach IEEE Standard Software Projekt 830 1998 t 3 Detaillierte Beschreibung Anforderungsanalyse ee ee ee Anforderungsspezifikation nen I oo I
14. Dokumenten o Redundanzen o Daten o Schwachstellen Rainer Koschke Uni Bremen Software Projekt Software Projekt S e mineesnal se E S ersten Was N Bestandteile Wintersemester 2008 09 Ist Zustand Was Verst ndnis von Bestandteile o Struktur Untersuchung auf o Aufgaben M ngel o Kommunikation Unvollstandigkeiten Dokumenten o Daten Redundanzen o Schwachstellen Nachdem wir die oben genannten relevanten Aspekte des Ist Zustands erfasst haben analysieren wir sie auf Schwachstellen und Probleme Dazu geh ren M ngel Unvollst ndigkeiten oder Redundanzen Auf die Schwachstellen werden wir sowohl durch eigene Analyse und Beobachtung der erhobenen Aspekte als auch durch Befragung und Beobachtung der Akteure selbst aufmerksam Zu entsprechenden Techniken der Befragung und Beobachtung kommen wir weiter unten 31 82 Ist Zustand Was Verstandnis von o Struktur EEE j o Abh ngigkeiten und wechselseitige Ausschl sse Q x Aufgaben von Teilen sind nirgendwo dokumentiert Q i a Fi Kommunikation o Verk ufer kennt nicht alle Einschr nkungen Pi Dokumenten Kunde kennt seine Konfiguration nicht Daten o Verk ufer kennt Sortiment nicht vollst ndig Q A Schwachstellen o verschiedene berlappende Teilekataloge o Inventarlisten sind obsolet j Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 32 82 Softwa re P roje kt Ist Zustand Was
15. Unified Modeling Language ist f r einen Kunden und Benutzer nicht ohne Weiteres zumutbar auch wenn manche sie als Notation f r die Kommunikation mit Kunden und Benutzer anpreisen Die Vorteile einer semi formalen Notation ist ihre Pr zision und Pr gnanz Aus diesem Grund w rde man sich ihren Einsatz w nschen Wird eine solche Notation verwendet muss der Kunde aber darin geschult werden ode w rden wir einen Vertrag in Hieroglyphen unterzeichnen pr zise die Anforderungen m ssen unmissverst ndlich formuliert sein sonst besteht die Gefahr dass etwas Falsches implementiert wird Dies schlie t Umgangssprache die sich durch vage Begriffe und Mehrdeutigkeiten auszeichnet au Ebenso sollten sprachliche Weichmacher wie k nnte m sste circa ungef hr etc vermieden werden st inhaltlich A E ce m je la a aie stellun 5 Ladera ngsspezifikation en est Zee 00 i a 5 i ee schlie t Umgangssprache aus rss Eigenschaften der Spezifikation en 9 objektivi ich nich z N Diese Merkmale konkurrieren d h die Erf llung des einen erschwert oder Software Projekt Die Form betreffend Angestrebte Eigenschaften der Spezifikation verhindert die Erf llung des anderen 7 leicht erstellbar die Anforderungsspezifikation ist in vielen F llen ein sehr umfangreiches Dokument Darum ist es wichtig das es leicht erstellt werden kann Somit ist die Auswahl geeigneter Notationen und Modelle bedeutsam H u wird s
16. ae x 3 3 Performanzanforderungen S Inhalt der Anforderungsspezifikation nach IEEE une N St an d a rd 830 y 1 998 en ren Sicherheit Wartbarkeit Portabilit t 3 6 Andere Anforderungen 3 3 Performanzanforderungen Funktionale Anforderungen beschreiben die erwartete Ausgabe auf eine Eingabe hin Bei Echtzeitsystemen mit harten Deadlines muss nicht nur die erwartete Ausgabe angegeben werden sondern auch nach welcher Zeit die Antwort erfolgen muss da sie ansonsten nicht mehr gebraucht wird Bei Systemen ohne Echtzeitanforderungen hingegen werdd zeitliche Aspekte h ufig nicht explizit angegeben Das ist jedoch falsch Denn auch bei interaktiven Systemen erwarte wir eine zeitnahe Reaktion des Systems auf unsere Eingabe hin weil wir das Programm sonst nicht verwenden wollen Erfolgen keine konkreten Angaben zur maximalen Reaktionszeit ist es schwer ber die Vertragserf llung bei der Abga zu diskutieren Deshalb sollte man grunds tzlich Aussagen zur erforderlichen Performanz jeder Funktionalit t machen Dies kann relativ zum Datenvolumen erfolgen oder in absoluten Zeitangaben Im letzteren Fall nimmt das Mengengeri eine noch gewichtigere Stellung ein Denn nur durch das Mengenger st k nnen wir zu absoluten Zeiten kommen die sp ter berpr fbar sind In diesem Abschnitt ist der Platz f r die Beschreibung der Performanzanforderungen aller Produktfunktionen Alterna kann man diese Anforderungen auch bei der Beschreibung der Produktfunktionen angeb
17. die die Entwicklung betreffen werden in diesem Abschnitt aufgef hrt Dazu geh ren sowohl die so genannten nicht funktionalen Produktattribute als auch organisatorische Rahmenbedingungen Hier sind zum Beispiel gesetzliche Rahmenbedingungen weitere Hardwarebeschr nkungen Zwang zur parallelisierten Ausf hrung erforderliche Zuverl ssigkeit sicherheitskritische Aspekte sowie Aspekte des Datenschutzes zu nennen 2 5 Annahmen und Abh ngigkeiten Unsere Entwicklung startet oft mit Annahmen bei denen wir zum gegenw rtigen Zeitpunkt nicht sicher sind ob sie zutreffen Wenn die Entwicklung von solche Annahmen abh ngt stellen die Annahmen ein Risiko dar das wir in diese Abschnitt explizit benennen Der Architekt kann dann versuchen die potentiellen Auswirkungen dieser Risiken im Architekturentwurf zu minimieren Jede Abh ngigkeit von Dritten stellt ein weiteres Risiko dar Sie f hren zur Annahme dass die von denen wir abh ng die von uns erw nschte Leistung erbringen Aus diesem Grund werden alle Abh ngigkeiten hier auch explizit aufgeftihy Inhalt der Anforderungsspezifikation nach IEEE Standard 830 1998 3 Detaillierte Beschreibung 3 1 Externe Schnittstellen 3 1 1 Benutzungsschnittstelle 3 1 2 Hardwareschnittstelle 3 1 3 Softwareschnittstelle 3 1 4 Kommunikationsschnittstelle 3 2 Produktfunktionen 3 3 Performanzanforderungen 3 4 Entwurfseinschr nkungen z B Standards 3 5 Softwaresystemattribute z B Zuverl ssigke
18. die nicht wirklich berechnet sondern nur in Reaktion auf die Eingabe des Benutzers angezeigt werden Die Daten m ssen auch nicht korrekt sein solange es nur um die Demonstration der Interaktion geht Die Funktionalit t kann unter Umst nden auch durch den Analytiker von Hand simuliert werden Interaktive Storyboards erm glichen echte Interaktion des Nutzers mit dem System mit einer gr tm glichen N he zum realen System Dabei muss der Analytiker nicht bei der Demonstration anwesend sein Allerdings kann der Benutzer auch hier nicht selbst eingreifen um eigene Vorstellungen einzubringen und wir haben einen h heren Aufwand bei der Prototyp Erstellung GUI Design Werkzeuge k nnen jedoch einen Teil des Aufwands reduzieren Interaktive Storyboards werden in der Regel in sp teren Phasen des Interaktions Designs entwickelt bei denen man schon genaue Vorstellungen entwickelt hat Sie k nnen f r Nutzertests zur Gebrauchsttauglichkeit des Systems eingesetzt werden indem man verschiedene Nutzer pro Persona mindestens einen mit dem System interagieren lasst und diese Interaktion beobachtet und auswertet Vor und Nachteile des Einsatzes von Prototypen erlauben fruhzeitige Demonstration von Losungsansatzen erlauben fruhzeitige Beteiligung der Benutzer vermeiden das Leere Blatt Syndrom reduzieren Entwicklungsrisiken durch fr hzeitige Diskussion mit Beteiligten geeignete Werkzeuge erm glichen die schnelle Erstell
19. erkannt wird o unbewusstes Wissen lt 40 o Wissen das sich dem Bewusstsein im Moment nicht darbietet aber dennoch handlungsbestimmend ist und potenziell aufgerufen werden kann o unterbewusstes Wissen o unbekannte W nsche die erst von au en herangetragen werden m ssen um als Anforderungen erkannt zu werden Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 9 82 Software Projekt ona Anforderungsanalyse beses Wen 230 Herausforderungen eNet eine DENEN 2008 11 04 Dass Benutzer oft nicht genau wissen was sie wollen beziehungsweise es nicht sagen liegt meist nicht an einem Mangel an Kenntnis Vorstellungsverm gen oder Kooperationsbereitschaft sondern an der Gestalt menschlichen Wissens Menschliches Wissen l sst sich unterteilen in drei ungef hr gleich gro e Bereiche Das bewusste Wissen ist solches Wissen ber das man sich im Klaren ist oder das in seiner vollen Bedeutung klar erkannt wird Fragt man einen Radfahrer danach wie man mit einem Fahrrad eine Kurve f hrt so wird er einem sicherlich antworten dass man hierf r den Lenker einschlagen muss Das bewusste Wissen ist durch direkte Fragen unmittelbar zug nglich Das unbewusste Wissen ist solches Wissen das sich dem Bewusstsein im Moment nicht darbietet aber dennoch handlungsbestimmend ist und potenziell aufgerufen werden kann Wird man denselben Radfahrer darauf aufmerksam machen dass man beobachtet habe dass er seinen K rper
20. graphische Benutzeroberflachen zusammen klicken kann Oder man benutzt Werkzeuge wie Graphikprogramme auch scripting f hige wie Adobe Flash und Pr sentationssoftware Vor und Nachteile des Einsatzes von Prototypen geeignete Werkzeuge erm glichen die schnelle Erstellung von Prototypen Vor und Nachteile des Einsatzes von Prototypen ee rari enka oa due usa Gefahr dass Wegwerf Prototyp Teil des Produkts wird z B aus Zeitdruck Auch wenn Prototypen billiger sind als das Endprodukt so erfordern Prototypen einen erh hten Entwicklungsaufwand durch die zus tzlich Prototyp Entwicklung Je nach Ausbau des Prototypen k nnen die Kosten erheblich sein Bei der Entwicklung von Wegwerfprototypen wird kein gro er Wert auf Qualit t gelegt sie m ssen zeigen was sie zeigen sollen und ansonsten m glichst billig sein Der gr te Nachteil dieser Prototypen ist somit die Gefahr dass sie zum Teil des Produkts werden z B aus Zeitdruck Bei interaktiven Storyboards erhalten Kunde und Projektmanagel den Eindruck dass das System schon beinahe fertig ist Die Versuchung ist gro den Wegwerfprototypen auszubauen statt ihn wie geplant wegzuwerfen Das r cht sich jedoch in der Regel weil die Qualit t des Wegwerfprototypen ein solches Vorgehen nicht unterst tzt Dieser Gefahr kann man durch Papierprototypen oder durch eine Entwicklung mit einer Programmiersprachen die man sp ter f r das Endprodukt nicht benutzen m chte vorbeugen
21. gute Anforderungsspezifikation auszeichnen in diesem Abschnitt noch auseinander setzen Anforderungsspezifikation nach IEEE Std 610 12 1990 Software Projekt Definition Anforderungsanalyse poor papers reper epee area or achieve an objective L A nfo rd eru ngss p ezifi ka t 10 n specification document that specifies in a complete precise verifiable manner the requirements of a system or component and often the procedures for determining whether these provisions have been satisfied Anforderungsspezifikation nach IEEE Std 610 12 1990 was sauiremens mecitcaion SRS documenation of the essential requirements functions performance design constraints and attributes of the software and its external interfaces Der zusammengesetzte Begriff Software Requirements Specification ist wie folgt definiert Software Requirements Specification documentation of the essential requirements functions performance design constrain and attributes of the software and its external interfaces Diese Definition erganzt die einzelnen Definitionen von Anforderung und Spezifikation um den Inhalt der in einer Anforderungsspezifikation aufgefuhrt ist Die Anforderungsspezifikation ist demnach eine Dokumentation der wesentlichen Anforderungen Funktionen Performanz Entwurfseinschrankungen und Attribute einer Software sowie ihrer externen Schnittstellen Diese Inhalte entstammen einer anderen IEEE Norm die beschreibt wie Anforderu
22. k nnen Ob eine erf llte Anforderung den Kunden zur Begeisterung treibt oder ob es f r ihn vielmehr eine Selbstverst ndlichkeit darstellt h ngt jedoch ab von der Art der Anforderung Die erste Kategorie von Anforderungen sind die Basisfaktoren der Software Diese Anforderungen stellen Mindestanforderungen dar die die Software erf llen muss damit sie eingesetzt werden kann Werden sie nicht erf llt ist die Software unbrauchbar Dies f hrt zu massiver Unzufriedenheit Da es sich um Mindestanforderungen handelt werden wir den Kunden selbst mit einer hundertprozentigen Erf llung allenfalls zufrieden aber nicht begeistern k nnen Die Gesamtheit der Leistungsfaktoren ist die bewusst verlangte Sonderausstattung Werden diese Anforderungen erf llt k nnen wir den Kunden mehr als nur zufrieden stellen Werden sie nicht erf llt ist der Kunde entt uscht er hatte sich diese Leistungsfaktoren ja explizit gew nscht Es droht dann Unzufriedenheit Den Kunden begeistern k nnen wir indem wir ihn berraschen Die begeisternde Faktoren erf llen ihm unbewusste W nsche oder stellen n tzliche und angenehme berraschungen dar Mit diesen Faktoren k nnen wir die Zufriedenheit berproportional steigern aber bei Nichterf llen niemals entt uschen weil der Kunde diese Anforderungen nicht explizit verlangt hat Basisfaktoren Software Projekt ee Kano Modell Mangel f hrt zu massiver Unzufriedenheit Anforderungsanalyse Sue ee
23. neigt bevor er den Lenker zur Kurve einschl gt wird er die maBgebende Rolle des K rpergewichtes best tigen An das unbewusste Wissen vermag man durch Beobachtung und Nachfragen zu kommen W hrend sowohl das bewusste als auch das unbewusste Wissen wenigstens indirekt erschlossen werden kann kommt man an die dritte Gestalt menschlichen Wissens kaum oder nur sehr schwer heran Ein Drittel des menschlichen Wissens ist dem Wissenden selbst n mlich gar nicht bewusst Das unterbewusste Wissen besteht aus dem uns nicht bekannten Wissen das dennoch f r unsere Handlungen ma gebend ist Oft sind es Angste unbewusste W nsche oder Triebe die f r uns handlungsbestimmend sind Warum der Radfahrer in bestimmten Situationen es scheut eine Kurve schneller zu nehmen hat vielleicht damit zu tun dass er sich einmal kr ftig durch einen Sturz blamiert hat als er einst versuchte eine Kurve besonders schnittig zu nehmen um seinen Freunden zu imponieren Unbewusste Anforderungen m ssen erst von au en an uns herangetragen werden um als Anforderungen erkannt zu werden Bewusstseinsebenen Software Projekt Anforderungsanalyse ne o Wissen ber das man sich im Klaren ist oder das in seiner vollen I Bedeutung klar erkannt wird m 6 unbewusstes Wissen lt 40 Herausforderungen one I dennoch handlungsbestimmend ist und potenziell aufgerufen werden ke oO B inseh ne Wess oO ewusstseinsebenen Teen Va N TT oO m ssen um als Anforderungen e
24. wahrnehmen kann Interne Eigenschaften betreffen vielmehr den inneren Aufbau Softwaresystemattribute Das System soll portierbar sein versus o Anteil der plattformabh ngigen Komponenten lt 2 o Anteil der plattformabh ngigen Codezeilen lt 5 Verwendung einer portierbaren Hochsprache o Einschr nkung auf portierbare Sprachkonstrukte Verwendung eines verbreiteten Betriebssystems Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 77 82 Software Projekt an S Anforderungsanalyse es e ngsspezifikation el eager S esse resystemattribute ee N Aber auch Anforderungen zu inneren Eigenschaften der Software m ssen hinreichend genau angegeben sein Die Aussage Das System soll portierbar sein die eine innere Qualit t darstellt kann nicht berpr ft werden weil nicht klar ist wohin portiert werden soll und was Portierbarkeit genau bedeuten soll Besser muss angegeben werden auf welcher Hardware und f r welches Betriebssystem die Software portiert werden soll Dann muss der Begriff portierbar konkretisiert werden z B auf die folgende Weise e Der Anteil der plattformabh ngigen Komponenten soll weniger als 2 ausmachen e Der Anteil der plattformabh ngigen Codezeilen soll weniger als 5 sein e Es soll eine Hochsprache als Implementierungssprache verwendet werden die auf allen Plattformen verf gbar ist auf portiert werden soll e Alle verwendeten Konstrukte der Programmierspr
25. wenn sie die spezifizierten Anforderungen richtig erf llt Daraus kann man jedoch noch nicht unmittelbar schlie en dass die Implementierung auch das implementiert was der Kunde tats chlich will Hierzu ist es noch notwendig dass die Anforderungsspezifikation auch die W nsche des Kunden zutreffend wiedergibt vollst ndig alle W nsche des Kunden werden ber cksichtigt widerspruchsfrei oder konsistent damit auch realisierbar die Anforderungen widersprechen sich nicht w rden sie sid widersprechen k nnte man nichts implementieren was alle Anforderungen erf llt neutral d h abstrakt die Anforderungen sind aus Sicht des Kunden formuliert und nehmen keine unn tigen technisch Details vorweg Implementierungsaspekte geh ren nicht in die Anforderungsspezifikation weil sie den Kunden in der Regel nicht interessieren sondern eher verwirren Au erdem bleibt damit dem Architekten beim Entwurf ein gr tm glicher Gestaltungsspielraum Angestrebte Eigenschaften der Spezifikation 9 objektivierbar auch nicht sinnvoll testbar genannt Diese Merkmale konkurrieren d h die Erf llung des einen erschwert oder verhindert die Erf llung des anderen leicht verst ndlich Die Anforderungsspezifikation ist leicht verst ndlich f r alle Zielgruppen Dazu geh ren neben Entwicklern mit technischem Verst ndnis auch Kunden und Benutzer die meist mit formalen Methoden und Notation nichts anzufangen wissen Selbst die Verwendung der
26. zu implementierende System aus Sicht des Kunden Wie das System intern implementiert wird interessiert den Kunden nicht sondern verwirrt ihn eher weil er sich mit Implementierungsfragen in der Regel nicht auskennt Implementierungsfragen geh rd in ein Entwurfsdokument wie z B die Architekturbeschreibung Wir sollten den Gestaltungsraum des Softwarearchitekten durch die Anforderungsspezifikation nicht unn tig einschr nken e Daten suchen nicht Programmabl ufe beschreiben Prim r sind wir an den Daten d h den Objekten der Anwendungsdom ne interessiert Sie ndern sich meist weniger als die Abl ufe in denen sie verarbeitet werden Nat rlich geh ren zur Beschreibung in der Anforderungsspezifikation die Kommunikation zwischen den Objekten und welche Operationen sie prinzipiell beherrschen Die Software muss ja Arbeitsfl sse abbilden Wie aber diese Operation intern implementiert werden der Programmablauf ist ein Detail der Implementierung und sollte erst sp ter im Entw oder in der Implementierungsphase spezifiziert werden e Abstraktionsebene nicht in einer Darstellung wechseln Um den Leser zu f hren statt ihn zu verwirren sollten wir uns Details f r vertiefende Abschnitte aufheben Die Anforderungsspezifikation sollte so gestaltet sein dass der Leser erst einen allgemeinen berblick ber alle Anforderungen an das System erh lt und erst dann einen detaillierten Einblick it die einzelnen Anforderungen Ein Wechsel zwischen diesen E
27. Anforderungsanalyse Interaktive Storyboards Demonstration Prototyp erm glicht dem Benutzer die fr hzeitige Interaktion mit dem m glichen System Funktionalit t kann evtl durch Analytiker von Hand simuliert werden Mittel o ausf hrbares Programm das Teile der Funktionalit t realisiert Bemerkung erm glicht Interaktion des Nutzers mit dem System erlaubt gr tm gliche N he zum realen System erfordert h heren Aufwand bei Prototyp Erstellung Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 60 82 2008 11 04 Software Projekt ne interaktive Storyboards Demonstration L A nford eru ngsa na l yse Prototyp erm glicht dem Benutzer die fr hzeitige Interaktion mit dem m glichen System Funktionalit t kann evtl durch Analytiker von Hand simuliert werden Mittel lee Prototyping ausf hrbares Programm das Teile der Funktionalit t realisiert Bemerkung erm glicht Interaktion des Nutzers mit dem System erlaubt gr tm gliche N he zum realen System erfordert h heren Aufwand bei Prototyp Erstellung Interaktive Storyboards bieten die gr tm gliche Interaktion mit dem System Dazu wird ein ausf hrbares Programm entwickelt was die Eigenschaften der Benutzungsschnittstelle demonstriert Es k nnen einzelne Teile der Funktionalit t bereits prototypisch implementiert sein Meist gen gen aber auch vorbereitete Daten f r bestimmte Szenarien
28. Bu meka selbst fremd Feld gt Labor Statt zu fragen k nnen wir auch beobachten Beobachtungen haben aber viele Facetten aus denen wir die geeignete Beobachtungsart zusammen stellen m ssen Hier m ssen wir zun chst entscheiden ob wir systematisch oder eher anekdotisch vorgehen wollen Wenn wir z B ganz einfach einmal den Fahrradladen betreten und dort eine Stunde verbringen liefert das eher anekdotisches Wissen Bei einem systematischen Vorgehen w rden wir vorher ermitteln wie sich die Kundenbesuche ber die Laden ffnungszeiten verteilen Dann w rden wir zu qualitativ unterschiedlichen Zeiten den Laden betreten z B Montag morgens wenn nicht viel los ist Mittwoch abends wenn mehr los ist und Samstag vormittags wenn der Laden meist voll ist Au erdem m ssen wir entscheiden ob wir bei der Beobachtung teilnehmen Wir k nnten uns also einerseits nur einfach in den Laden stellen und beobachten oder aber k nnten wir selbst Kunde spielen und uns beraten lassen Die Beobachtung kann offen oder verdeckt erfolgen Erfolgt sie offen kann das den Beobachtungsgegenstand beeinflussen Ein Verk ufer wird sich in einer solchen Situation zum Beispiel eher freundlich verhalten als wenn er sich unbeobachtet f hlt Andererseits werfen verdeckte Beobachtungen ethische Fragen auf und sind m glicherweise schlicht verboten Dann m ssen wir uns entscheiden ob wir selbst beobachten oder die Beobachtung Dritten berlassen Wenn wir selbst beobach
29. Da die Anforderungsanalyse bei der Entwicklungsphase des n chsten Inkrements wieder durchlaufen wird kann der Benutzer an vielen Punkten der Entwicklung Einfluss nehmen Diese Idee wird beim Extreme Programming einem agilen Entwicklungsprozess zum Extrem getrieben indem ein Benutzer vor Ort der Entwicklung ist und w chentlich das System testet und Verbesserungsvorschl ge unterbreitet Die Gebrauchstauglichkeit kann auf diese Weise besser sicher gestellt werden Au erdem haben Benutzer die M glichkeit das System das sie sp ter einsetzen sollen mitzugestalten was zu einer h heren Akzeptanz f hren sollte Wegweiser Anforderungsspezifikation Wie halten wir die Anforderungen fest Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 64 82 Anforderungsspezifikation nach IEEE Std 610 12 1990 Definition requirement condition or capability needed by a user to solve a problem or achieve an objective specification document that specifies in a complete precise verifiable manner the requirements of a system or component and often the procedures for determining whether these provisions have been satisfied software requirements specification SRS documentation of the essential requirements functions performance design constraints and attributes of the software and its external interfaces Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 65 82
30. IIE Be Systemgrenzen st An a lyse ji ne o Art und Umfang der Verbindungen innerhalb F rost nder_ Verk uter2 St Sees Verk ufer 1 Kunde 1 Bei der Analyse der Struktur identifizieren wir zun chst alle relevanten Akteure Benutzer und andere Softwaresysteme die miteinander interagieren Im Fahrradladen sind das Kunden und Verkaufer sowie der Ladenbesitzer und seine Lieferanten Dann legen wir die Systemgrenzen fest Mit System ist hier weder das Softwaresystem gemeint das wir implementieren sollen wir kennen ja die Anforderungen daf r noch gar nicht noch etwa ein m glicherweise bereits existierendes Softwaresystem das wir abl sen sollen Vielmehr meinen wir damit den Ausschnitt der Welt f r den wir die softwaretechnische Verbesserung anstreben sollen Diesen Ausschnitt fassen wir als ein System miteinander agierender Akteure auf Wenn wir die Systemgrenzen festlegen bestimmen wir also was alles zu dem Ausschnitt der Welt geh rt der f r uns relevant ist Bsp Nehmen wir an wir sind beauftragt das Verkaufsgespr ch zwischen K ufer und Verk ufer zu optimieren dann geh ren diese beiden Personengruppen zu unserem untersuchten System Ihr Zusammenspiel sollen wir optimieren Ladenbesitzer und Lieferanten hingegen sind au erhalb unseres Systems aber dennoch relevant f r unsere Aufgabenstellung weil der Verk ufer den Ladenbesitzer bei bestimmten Entscheidungen zu Rate ziehen und Lieferanten zu Lieferzeiten befrag
31. Katalog in Papierform Online Katalog in HTML Ordnungsstrukturen Name Hersteller Typ Verarbeitungshaufigkeit wird alle drei Tage einmal verkauft Q Software Projekt Wintersemester 2008 09 29 82 Bestandteile Fortsetzung Art und Erfordernisse der Datensicherung Speicherung verkaufter Waren und des Inventars o Abh ngigkeiten zwischen den Daten passt nur an bestimmte Rahmen Software Projekt Wintersemester 2008 09 30 82 2008 11 04 2008 11 04 Ist Zustand Was Software Projekt Anforderungsanalyse one Bestandteile Fortsetzung o Struktur ee o Art und Erfordernisse der Datensicherung st A na lyse en See verkaufter Waren und des 9 Dokumenten o Abh ngigkeiten zwischen den Daten i Daten passt nur an bestimmte Rahmen Ist Zustand Was 5 o Schwachstellen Wir untersuchen die Dokumente um die Daten zu ermitteln die f r die Ist Analyse relevant sind Oft sind es verschiedene Daten die in den Dokumenten aufgef hrt und verkn pft werden Allerdings sind nicht alle relevanten Daten auf Dokumenten wiedergegeben Im n chsten Schritt untersuchen wir weitere Daten die m glicherweise nur m ndlich ausgetauscht werden Um die Daten pr zise und vollst ndig zu modellieren wird hierzu oft ein Datenmodell aufgestellt Das Datenmodell beschreibt die wesentlichen Daten ihre Eigenschaften ihren Umfang und ihre Beziehungen Zur Repr sentation eignen sich f r eine Rei
32. S Anforderungsanalyse ee Lge reales TE ee T u m ore S Ist Zustand Was 2 Schwachstellen eich 5 N Bsp In unserem Fahrradladen k nnen wir beispielsweise durch unsere Analyse der erhobenen Aspekte und durch Beobachtung im Laden folgende Schwachstellen identifizieren Beispielschwachstellen Die Abh ngigkeiten und wechselseitige Ausschl sse der Bestandteile eines Fahrrads sind nirgendwo dokumentiert Ein Verk ufer kann sie nicht nachschlagen und muss sie alle kennen um einen Kunden zu beraten Nicht alle Verk ufer kennen aber alle Einschr nkungen Dies f hrt dazu dass weniger erfahrene Verk ufer R cksprach halten m ssen mit erfahreneren Verk ufern oder gar Lieferanten und dass Kunden ver rgert ihre falschen Artikel umtauschen m ssen wenn sie falsch beraten wurden Die Verk ufer k nnen die Kunden nicht ausreichend beraten weil der Kunde die bereits gekauften Fahrradbestandteil nicht genau kennt zu denen der neu zu kaufende Artikel passen soll Der Kunde muss in solchen F llen unverrichtetei Dinge den Laden wieder verlassen und die Information besorgen Verk ufer kennen das Sortiment nicht vollst ndig und wissen nicht genau was im Laden selbst oder im Lager noch verf gbar ist Die Fahrradartikel sind in verschiedenen teilweise berlappenden Teilekatalogen beschrieben Dies f hrt zu unn tigen Redundanzen Die Inventarlisten sind obsolet Der Ladenbesitzer wei nicht genau welche Ware noch vorr tig verkau
33. ache m ssen auf allen Zielplattformen verf gbar sein Prasentation der Anforderungen Funktionale Anforderungen geordnet nach o Operationsmodus o z B Kontrollsysteme Training Normal Notfall o Benutzerklassen o z B Fahrzeugsteuerung Fahrer Fahrg ste Wartungstechniker Objekte und Klassen o z B Patientenmonitorsystem Patienten Sensoren Pflegepersonal Raume rztinnen Medizin o jede Klasse wird beschrieben durch ihre Attribute und Methoden o Features oder auch Anwendungsf lle gew nschter nach au en sichtbarer Service o z B Telefonsystem Nahgespr ch Weiterleitung Konferenzgespr ch o Stimuli bei reaktiven Systemen o z B Landesystem eines Flugzeugs Energieverlust Windwechsel Schlingern Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 78 82 Pr sentation der Anforderungen Softwa re P roj e kt Funktionale Anforderungen geordnet nach a Operationsmodus oO A nford eru ngsa na yse ne Sleralkene Training Normal Notfall a f uerung Fahrer Fahrg ste Wartungstechniker i Anforderungsspezifikation Be Fran ee ee CO Se N ird bes n durch ihre Attribute und Methoden fe Prasentation der Anforderungen E aly gig aero O Prieto tetera ihre Weisen Koenkai N Stimuli bei n Systemen z B Landesystem eines Flugzeugs Energieverlust Windwechsel Wie oben erw hnt kommt der Strukturierung des Abschnitts 3 2 Produktfunktionen eine gro e Bedeutung zu Di
34. analyse ist von zentraler Bedeutung f r den Erfolg eines Projektes Passieren hier Fehler entsteht ein System was an den Bed rfnissen des Kunden vorbei entwickelt und damit unbrauchbar wird Fehler in der Anforderungsanalyse k nnen zwar oft noch in sp teren Phasen entdeckt und dann korrigiert werden die Korrektur dieser Fehler ist jedoch meist mit einem erheblichen Mehraufwand verbunden Pressman 2003 berichtet von den relativen Kosten f r Korrekturen von Fehlern in der Anforderungsanalyse in Abh ngigkeit vom Zeitpunkt zu dem diese Fehler bekannt werden Findet man einen Fehler der Anforderungsspezifikation in sp teren Aktivit ten der Entwicklung also beim Entwurf der Implementierung oder dem Test noch vor Auslieferung dann k nnen die Kosten um einen Faktor 1 5 bis 6 h her sein als die Korrekturkosten die entstanden w ren h tte man den Fehler noch w hrend der Anforderungsanalyse gefunden Wird der Fehler noch sp ter gefunden also nach der Auslieferung der Software kann er gar um einen Faktor 60 bis 100 h her sein Es entstehen dann nicht nur zus tzliche Kosten f r die Nachbesserung von Anforderungsspezifikation und Entwurf Fehlerkorrektur und Restrukturierung der Implementierung sowie Wiederholung des Tests Es entstehen dar ber hinaus auch Kosten f r die Beseitigung von Auswirkungen des Fehlers Hat eine eingebettete Software in einem Automobil beispielsweise einen Fehler so m ssen alle Fahrzeuge in der Werkstatt berholt werd
35. as Spielerisches im Entwicklungsprozess das unsere Kreativit t stimulieren kann Wir k nnen gro e Poster unserer Personas aufh ngen und sie betrachten w hrend wir an der Anforderungsspezfikation schreiben Wir leben damit die Idee f r und mit dem Benutzer zu entwickeln Small Business Enterprise aA L i e r chiro icolas or ce rel Persona Poster o Bild fiktiv o Name fiktiv Beruf Motto o Rolle Ziele Aufgaben Ideen W nsche Vorlieben pers nliche Details Software Projekt 5 Wintersemester 2008 09 21 82 Software Projekt Anforderungsanalyse eens 2008 11 04 Die urspr ngliche Idee der Personas f r die Anforderungsaanalyse stammt von Cooper Zur Beschreibung einer Persona gehoren ein fiktives Bild und ein fiktiver Name sowie weitere personliche Eigenschaften wie den Beruf oder ein charakterisierendes Motto Statt von der abstrakten Benutzerklasse Verkaufer sprechen wir also von Herrn Schmidt dem Verk ufer Dann werden die gemeinsamen Eigenschaften der Benutzer die sich hinter der Persona verbergen aufgef hrt Dazu geh ren die Rolle die Herr Schmidt ausf llt die Ziele die Herr Schmidt verfolgt seine Ideen W nsche Vorlieben und weitere pers nliche Details soweit sie von Relevanz f r die Analyse sind Quelle f r das Bild http www research microsoft com research coet Grudin Personas Pruitt Grudin doc Der Artikel erl utert auch wesentliche Ideen Bedeutu
36. auf die Qualit t Deshalb sollte man sich die M he machen die Anforderungen genau zu beschreiben und sie am auch aufzuschreiben Man kann die Auswirkungen einer mangelhaften Anforderungsspezifikation unterscheiden anhand der Zwecke die man mit der Anforderungsspezifikation verfolgt Folge von M ngeln on eigene Vorstellung als Vorgabe menologisch verfasst darum schwer wiederzuverwenden sp tere Reimple Kompatibilit t setzt voraus dass man wei womit mentierung die neue Software kompatibel sein soll Abstimmung Die Anforderungsspezifikation dient der Abstimmung mit dem Kunden M ngel in der Anforderungsspezifikation f hren dazu dass Anforderungen ungekl rt und W nsche des Kunden unber cksichtigt bleiben Ohne eine ausgearbeitete Anforderungsspezifikation kann der Kunde nicht ohne Weiteres in fr hen Phasen de Projekts berpr fen ob er richtig verstanden wurde und seine W nsche wirklich umgesetzt werden Entwurf Der Softwarearchitekt entwirft auf Basis der Anforderungsspezifikation die Softwarearchitektur Bei einer unzureichenden Anforderungsspezifikation fehlt dem Architekten daf r die notwendige Vorgabe Dies f hrt zu einem erh hten Bedarf an Kommunikation Der Architekt muss beim Analytiker beziehungsweise beim Kunden nachfragen Au erdem besteht die Gefahr dass der Architekt seine eigene Vorstellung der Anforderungen entwickelt die von der d Kunden abweichen k nnte Benutzerhandbuch Anhand der Anforde
37. b wie man die Frage stellt Aus diesem Grunde sollte man sich bei der Gestaltung eines Fragebogens die Fragen und die Art der Frage sorgf ltig berlegen und sich ber den Einfluss des Kontextes im Klaren werden Die Sozialwissenschaften haben hierzu umfangreiche Lehrb cher entwickelt Zu unseren Fragen m ssen wir uns selbst folgende Fragen stellen o Art der Frage o Anordnung der Fragen B efra E un E o Erhebungssituation Interviewereinfluss o Gr nde f r die Antwort der Befragten Wird die Frage berhaupt richtig verstanden Benutzen wir Begriffe zu denen der Befragte die gleichen Vorstellungen hat wie der Fragende Bsp Wenn wir Softwaretechniker von Server sprechen und damit einen Prozess meinen dann versteht der Befragte darunter m glicherweise den Rechner auf dem seine Applikation laufen wenn er etwas Hintergrund in Computer Hardware hat oder gar lediglich Diener wenn er Computer Laie ist Was ist der Bezugsrahmen der Befragten Was ist seine Rolle was kann er wissen was sind seine Ziele sowohl beruflicher als auch pers nlicher Art Bsp Es hat keinen Sinn den Besitzer unseres Fahrradladens zum blichen Abla von Verkaufsgespr chen zu fragen wenn er selbst seit langer Zeit das Verkaufen nicht mehr selbst praktiziert hat und lediglich Managementaufgaben wahrnimmt Informationsstand der Befragten Was kann der Befragte berhaupt wissen Fragen wir ihn zu Dingen die er nicht wissen kann wird er keine Antwort abgeb
38. benen verwirrt unn tig Regeln f r Analyse und Spezifikation Software Projekt Ein Begriffslexikon anlegen und entwickeln A nford eru ngsa na yse Von der Aufgabe ausgehen nicht von ihrer L sung Daten suchen nicht Programmabl ufe beschreiben sh a Abstraktionsebene nicht in einer Darstellung wechseln A fi d f k Die Spezifikation nach Aspekten organisieren nroraeru ngsspezi IKation gt Ein Mengenger st bilden er 2 Den Kunden Benutzer einbeziehen Rege n f r A n a yse u n d S p ez l fi ka t l O n o Geeignete Sprachen und Werkzeuge verwenden Die Spezifikation so fr h wie m glich pr fen und dem Konfigurationsmanagement unterstellen Die Spezifikation intensiv verwenden e Die Spezifikation nach Aspekten organisieren Die Spezifikation ist nicht selten ein Dokument mit mehreren hundert Seiten Es kann nicht ohne Unterbrechung gelesen werden Au erdem wird es von Lesern mit sehr unterschiedlichen Interessen gelesen Dazu geh ren auf Kundenseite neben dem Auftraggeber auch hier gibt es meist verschiedene Rolle der Auftraggeber der f r den Inhalt verantwortlich ist und der Auftraggeber der f r die Finanzierung und Termintreu verantwortlich ist die verschiedenen Benutzerklassen Auf der Seite der Hersteller wird das Dokument von den Architekten den Programmierern den Handbuchautoren und den Testern gelesen Alle interessieren sich f r unterschiedliche Belange Um die vielen Arten von Lesern zu unterst tz
39. ch sp testens 20 Sekunden erfolgen nach h chstens 30 Sekunden soll die Ausgabe in 100 aller F lle erfolgen Die Berechnung muss mit maxim 5 MB Hauptspeicher und 100 MB Plattenplatz auskommen Leider ist es nicht immer m glich alle diese Merkmale bei einer Anforderungsspezifikation zu erf llen weil die Merkmale konkurrieren k nnen das hei t die Erf llung des einen erschwert oder verhindert die Erf llung des anderen Pr zise Anforderungen sind in der Regel nur mit Hilfe formaler Spezifikationsprachen zu erreichen die sind aber f r einen Kunden meist nicht verst ndlich Regeln f r Analyse und Spezifikation o Ein Begriffslexikon anlegen und entwickeln o Von der Aufgabe ausgehen nicht von ihrer L sung o Daten suchen nicht Programmabl ufe beschreiben o Abstraktionsebene nicht in einer Darstellung wechseln o Die Spezifikation nach Aspekten organisieren o Ein Mengenger st bilden o Den Kunden Benutzer einbeziehen o Geeignete Sprachen und Werkzeuge verwenden o Die Spezifikation so fr h wie m glich pr fen und dem Konfigurationsmanagement unterstellen o Die Spezifikation intensiv verwenden Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 70 82 2008 11 04 2008 11 04 Regeln fiir Analyse und Spezifikation Software Projekt Ein Begriffslexikon anlegen und entwickeln A nford eru ngsa na yse Von der Aufgabe ausgehen nicht von ihrer L sung Daten suchen nicht Pr
40. che Umgebung Hardware oder Softwareumgebung einschlie en Anpassbarkeit Software an verschiedene festgelegte Umgebungen anpassen Installierbarkeit Aufwand der zum Installieren der Software in einer festgelegten Umgebung notwendig ist Konformit t Grad in dem die Software Normen oder Vereinbarungen zur bertragbarkeit erf llt Austauschbarkeit M glichkeit diese Software anstelle einer spezifizierten anderen in der Umgebung jener Software zu verwenden sowie der daf r notwendige Aufwand A Produktqualitaten nach ISO IEC Standard 9126 2001 Software Projekt Anderbarkeit Zuverl ssigkeit Funktionalita E E E a anion L Produktqualit ten nach ISO IEC Standard 9126 2001 2008 11 04 FrAnpassbarkei fea Diese Kategorien sind immer noch sehr allgemein und m ssen f r die Anforderungen an eine bestimmte Software konkretisiert und gewichtet werden Dabei ist zu beachten dass sich Qualit tsattribute gegenseitig auch negativ beeinflussen k nnen So stehen hohe Performanz und hohe Wartbarkeit meist in einem Spannungsfeld zueinander Die Konkretisierung und Gewichtung der Qualit tsattribute liefert das Qualit tsmodell F r das Qualitatsmodell m ssen dann Pr fkriterien festgelegt werden anhand derer das Vorhandensein der gew nschten Eigenschaften berpr ft werden kann Im ISO IEC Standard 25000 2005 der die Nachfolge von ISO IEC Standard 9126 2001 angetreten hat werden hie
41. d Bei geschlossenen Fragen sind alternative Antworten bereits vorgegeben aus denen der Befragte eine oder gegebenenfalls mehrere ausw hlen kann H ufig findet man solche Fragen f r Aspekte die anhand einer Skala eingesch tzt werden sollen also zum Beispiel die Frage ob einem die GUI sehr gut gut oder nicht gef llt Durch die Vorgabe m glicher Antworten schafft man eine Normierung und kann die Antworten leicht automatisiert statistisch auswerten Diesen Fragentyp kann man gut einsetzen wenn man die m glichen Antworten gut vorwegsehen kann Wenn man also bereits eine bestimmte Hypothese hat kann man sie durch solche Fragen leicht berpr fen In Bereichen in denen man jedoch die Antworten nur schlecht absch tzen kann besteht die Gefahr dass die Antwort die jemand eigentlich geben m chte nicht dabei ist Hier sind solche Fragetypen eher ungeeignet In jedem Falle sollte es bei der Antwort immer m glich sein dass der Befragte die Frage nicht beantworten kann oder will um erzwungene Falschantworten zu vermeiden Fragetypen Offene Fragen Offene Fragen Wie sollte die GUI verbessert werden Antworten in eigenen Worten im eigenen Referenzsystem o erfordert Ausdrucksfahigkeit der Befragten o starker Einfluss des Fragenden wenn pr sent durch Aufschreiben Weglassen o hoher Auswertungsaufwand Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 37 82 Fragetypen Offene Fragen S
42. dass nur solche Schnittstellen interessieren die zu anderen Systemen f hren beziehungsweise f r die der Kunde sorgen muss damit unser System arbeiten kann Ist eine solche Schnittstelle vollst ndig intern und wird von uns mitgeliefert handelt es sich um ein Implementierungsdetail das wir nicht in der Anforderungsspezifikation nennen Bsp Wir wollen den PDA mit dem Ladenrechner ber WLAN kommunizieren lassen Wir setzen voraus dass der Kun f r das WLAN in seinem Laden sorgt Dann w re WLAN mit einem Netzwerkprotokoll wie TCP IP in der Anforderungsspezifikation zu erw hnen Wir d rfen dann in unserer Implementierung voraussetzen dass die Ausf hrungsumgebung diese Komponenten bereit halt Speicherbeschr nkungen Hier nennen wir die mindestens verf gbare Gr e des Hauptspeichers und der Festplatten die das korrekte Funktionier unserer Software voraussetzen darf Anforderungen an die Laufzeit werden im Kontext der Operationen festgelegt Inhalt der Anforderungsspezifikation nach IEEE Standard Software P roj ekt 830 1998 2 Allgemeine Beschreibung Anforderungsanalyse 21 Produkte Einbettung in ein Gesamtsystem Lead san N a ah der Anforderungsspezifikation nach IEEE at Standard 830 1998 ne n oder Men s Regeln f r die Schnittstelle len Netzwerkprotokolle etc 2008 11 04 2 1 7 Betriebsoperationen Neben den eigentlichen Produktfunktionen bietet ein System meist noch eine Menge allgemeiner Opera
43. den System bernehmen beziehungsweise verbessern sollten Erfolgt die Ist Analyse mangelhaft droht die Gefahr dass wir das eigentliche Problem ignorieren F r eine erfolgreiche Durchf hrung der Ist Analyse ben tigen wir Beobachtungsgabe Einf hlungsverm gen und Kommunikationsf higkeit Schritte der Anforderungsanalyse Soll Analyse Ziel Aufdeckung und Verbesserung Ist Zustand bisheriger Schw chen durch Softwarelosung Ist Analyse a Antizipation von nderungen H ufige Fehler Lastenhet Entwickler gleiten in technische Details Soll Analyse Ss ab Kunde hat keine klare Vorstellung bzw kann sie nicht vermitteln Folgen von M ngeln falsche L sung wird a spezifiziert Erforderlich Analytische Fahigkeiten kombiniert mit Wissen uber Machbarkeit von Softwarelosungen Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 13 82 Software Projekt a u ee eng amp Anforderungsanalyse p EE Aktivit ten be tg tet i See E ae eee S Schritte der Anforderungsanalyse Soll Analyse a a a ea Auf Basis der Ergebnisse der Ist Analyse identifiziert die Soll Analyse die bisherigen Schwachen und erarbeitet VerbesserungsmaBnahmen Dabei interessieren uns nicht nur die unmittelbar anstehenden Anforderungen sondern auch jene die in absehbarer Zukunft relevant werden konnen Wahrscheinliche zusatzliche A
44. derungsspezifikation niemals gelesen haben Regeln f r Analyse und Spezifikation Software Projekt Ein Begriffslexikon anlegen und entwickeln A nford eru ngsa na yse Von der Aufgabe ausgehen nicht von ihrer L sung Daten suchen nicht Programmabl ufe beschreiben sh a Abstraktionsebene nicht in einer Darstellung wechseln A fi d f k Die Spezifikation nach Aspekten organisieren nroraeru ngsspezi IKation o Ein Mengenger st bilden Den Kunden Benutzer einbeziehen Le Regel n f r An a yse un d S pezifi kation Geeignete Sprachen und Werkzeuge verwenden Die Spezifikation so fr h wie m glich pr fen und dem Konfigurationsmanagement unterstellen Die Spezifikation intensiv verwenden Nachdem wir wissen welche Qualit ten der Anforderungsspezifikation wir anstreben und welche Regeln wir einhalten sollen werden wir uns nun mit ihrem Inhalt und ihrer Struktur auseinander setzen Gl cklicherweise haben sich dazu bereits viele Spezialisten Gedanken gemacht die sogar in einen Standard gem ndet sind Da wir das Rad nicht neu erfinden wollen und die Orientierung an Standards eine gute Ingenieurstugend ist nehmen wir uns diesen Standard zum Vorbild Wir k nnen diesen Standard als einen Rahmen f r unsere Spezifikation verwenden und laufen so weniger Gefahr etwas zu vergessen Es handelt sich dabei um den IEEE Recommended Practice for Software Requirements Specifications IEEE Standard 830 1998 Er setzt vieles von de
45. die Anforderungen Bed rfnisse und Ziele aller Benutzer ab Wie viele Personas man ben tigt h ngt stark vom Projekt ab In der Regel wird man mit zwischen 5 und 15 verschiedene Personas auskommen Die Personas stehen im Designprozess stellvertretend f r die realen Benutzer und bilden eine kreative und konkrete Alternative zu der relativ anonymen und pauschalen Gr e Benutzer Die Anforderungsspezifikation muss die Anforderungen f r jede Persona beinhalten Sie k nnen aber nicht nur w hrend der Anforderungsanalyse der funktionalen Anforderungen an die Software verwendet werden Die Personas helfen uns auch beim Design der Mensch Maschine Kommunikation und beim Usability Test der Benutzerinteraktion Hier muss die Benutzerinteraktion so gestaltet sein dass alle Personas ihr Anwendungsproblem mit dem Softwaresystem effektiv und effizient l sen k nnen Aus den Personas lassen sich f r den Usability Test der dies berpr fen soll unmittelbar entsprechende Test Benutzer ableiten die das Profil der Personas erf llen Schlie lich k nnen die Personas beim Handbuchschreiben und pr fen sowie beim Akzeptanztest verwendet werden Auch hier helfen sie sicher zu stellen dass die Anforderungen zutreffend und vollst ndig sind indem das Handbuch und System aus allen relevanten Blickwinkeln der Benutzersicht untersucht wird Ist Zustand Was Verstandnis von Bestandteile Umfang und Art der anfallenden Aufgaben Operationen und Besonde
46. e einfachsten Materialien sind Papier und Bleistift Daf r sprechen die besonders einfache und billige Prototyperstellung sowie die M glichkeit zur Interaktion mit den Beteiligten am konkreten Beispiel Der Benutzer selbst kann mit diesen Materialien selbst umgehen und an der Entwicklung des Prototypen direkt mitwirken Softwa ke P roj e kt Passive Storyboards Demonstration Analytiker spielt die Bedienung mit dem System durch indem er A fi d tl A idi Ei be lichkeite d nforderungsanalyse en Mittel cole Anal se Prototypin ae 1 y y p g Bildschirm Masken Screenshots oo o m gliche Systemausgaben A Hi F Bemerkung Beispiel passives Storyboard E O erm glicht Interaktion mit Beteiligten am Beispiel N erfordert Anwesenheit des Analytikers Bsp Unsere Analyse der Schwachstellen in der Ist Analyse zu unserem Fahrradladenbeispiel hat ergeben dass es oft schwierig ist einen Kunden beim Einkauf eines Artikels f r ein Fahrrad das sich schon in seinem Besitz befindet richtig zu beraten weil er nicht wei welche Daten das Fahrrad hat Wenn er einen Flaschenhalter kaufen m chte so muss er zu den Ausma en und Bohrungen sowie der Farbe des Rahmens passen Wenn er sie nicht kennt kann ihm der Verk ufer keine Empfehlung aussprechen Wir haben uns entschlossen einen Einkaufsassistenten auf Basis eines PDAs zu entwickeln Auf diesem tragbaren Kleinrechner sind alle Eink ufe des Kunden erfasst und z
47. e wir in der Ist Analyse gefunden hab4 nennen bersicht ber das Dokument 7 Schlie lich erfolgt hier in diesem Abschnitt eine kurze bersicht f r den Leser ber die weiteren Kapitel und Abschnit dieser Anforderungsspezfikation Inhalt der Anforderungsspezifikation nach IEEE Standard 830 1998 2 Allgemeine Beschreibung 2 1 Produktperspektive Einbettung in ein Gesamtsystem 2 1 1 Systemschnittstellen 2 1 2 Benutzungsschnittstelle logische Charakteristika z B Monitorformat Seiten oder Fensterlayout Inhalt von Berichten oder Menus Verf gbarkeit von Funktionstasten sowie Regeln f r die Schnittstelle 2 1 3 Hardwareschnittstellen 2 1 4 Softwareschnittstellen 2 1 5 Kommunikationsschnittstellen Netzwerkprotokolle etc 2 1 6 Speicherbeschr nkungen 2 1 7 Betriebsoperationen Operationsmodi Dauer interaktiver und nichtinteraktiver Operationen unterst tzende Datenverarbeitungsfunktionen Sicherungs und Wiederherstellungsoperationen 2 1 8 M glichkeiten der lokalen Anpassung Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 73 82 Softwa re P roje kt Se Anforderungsspezifikation nach IEEE Standard S _ Anforderungsanalyse nn 3 ran ngsspezifikation i a vn Daran ele Mea o S H inhalt der Anforderungsspezifikation nach IEEE 2 N Standard 830 1998 Das Kapitel 2 beschreibt Allgemeines sowie die Anforderungen im Einzelnen ohne jedoch gleich alle m glichen Details zu nennen letztere fo
48. edenken Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 44 82 2008 11 04 Wegweiser Software Projekt Anforderungsanalyse aE Soll Analyse soll Analyse Prototyping gt ee ee konkretes Bild vermitteln wie wir das Problem zu essen Durch Analyse von Dokumenten Beobachtungen und Fragen haben wir den Ist Zustand erfasst Die Analyse des Erfassten deckt die Schwachstellen auf die wir mit einer softwaretechnischen L sung beseitigen sollen Der n chste Schritt ist nun auszuarbeiten was die softwaretechnische L sung dazu leisten muss Dieser Aufgabe widmet sich die Soll Analyse Die Soll Analyse muss die Anforderungen an die zu implementierende Software aufstellen Dazu geh rt es auch diese Anforderungen hinsichtlich ihrer Machbarkeit und Folgen einzusch tzen In diesem Abschnitt lernen wir eine Technik kennen mit der wir sowohl Anforderungen berpr fen als auch technische Machbarkeit untersuchen k nnen Beobachtungen setzen den beobachteten Gegenstand voraus Somit zielen Beobachtungen klar auf den Ist Zustand ab Unsere softwaretechnische L sung existiert aber noch nicht Fragen hingegen sind sowohl hilfreiche Mittel f r die Ist Analyse als auch f r die Soll Analyse Wir k nnen z B die Benutzer fragen wie etwas sein soll Auf welche Probleme wir dabei allerdings sto en haben wir schon ganz zu Anfang bei der Einf hrung zur Anforderungsanalyse besprochen Die Benutzer k nne
49. eine grobe Skizze der Fragen haben um dann die Fragen an die Situation spontan anzupassen Ganz zu Anfang wenn man sich ein Gebiet erschlie en m chte ist man oft gar nicht in der Lage pr zise Fragen auszuarbeiten Das Interview hat gegen ber der Befragung durch einen schriftlichen Fragebogen den der Befragte ohne unser Beisein ausf llt den Vorteil dass wir auch Gestik und Mimik des Befragten sehen seine Gegenfragen direkt kl ren k nnen und individuell auf die Situation reagieren k nnen Allerdings kann die Anwesenheit eines Fragenden die Antworten des Befragten beeinflussen Zum einen l sst sich die Anonymit t hier nicht sicher stellen zum anderen fallen die Antworten oft auch abh ngig davon aus inwieweit der Fragende dem Befragten sympathisch ist Au erdem ist das individuelle Interview erheblich zeitaufw ndiger und teurer Bei den schriftlichen Frageb gen verh lt es sich gerade umgekehrt Aus diesem Grunde werden wir meistens sowohl Interviews als auch schriftliche Frageb gen anwenden weil sie sich bestens erg nzen Wir werden meist zu Anfang eine kleinere Zahl von Interviews f hren Sp ter k nnen wir auf Basis dieser Interviews pr zise Frageb gen aufstellen um eine gr ere Datenbasis zu schaffen Ist Zustand Wie Software Projekt Erhebungstechniken E E ce Auswertung vorhandener Dokumente o Befragung schriftlicher Fragebogen Ist Analyse ie Beobachtung anekdotisch systematisch Ist Zustand Wie
50. en Dadurch entstehen hohe direkte Kosten aber auch noch indirekte Kosten durch den Imageverlust des Automobilherstellers wenn sich der Imageverlust auf die Verkaufszahlen auswirkt Pressman 2003 Warum die Anforderungsanalyse so schwer ist e Kunden wissen h ufig nicht was sie genau wollen bzw k nnen es nicht genau auBern Kunden sprechen ihre Sprache die von Entwicklern nicht verstanden wird o unterschiedliche Kundengruppen haben unterschiedliche Anforderungen die sich mitunter widersprechen o politische Entscheidungen k nnen Anforderungen beeinflussen o die Welt ndert sich die Anforderungen an die Software auch auch w hrend der Entwicklung Sommerville 2004 Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 8 82 Softwa re P roje kt Warum die Anforderungsanalyse so schwer ist Anforderungsanalyse en L Herausforderu ngen nz S Warum die Anforderungsanalyse so schwer ist eure N Sommerville 2004 Die Anforderungsanalyse ist schwierig so dass die Wahrscheinlichkeit dass wir Fehler machen recht hoch ist Sommerville 2004 nennt hierfiir eine Reihe von Griinden e Die Kunden wissen haufig nicht genau was sie genau wollen beziehungsweise konnen es nicht genau auBern e Kunden sind Experten in ihrem Anwendungsbereich haben jedoch in der Regel wenig Kenntnisse in der Informatik B den Informatikern verh lt es sich meist umgekehrt Es treffen also Menschen aufeinander die e
51. en muss die Spezifikation uniform nach relevanten Aspekten organisiert werden e Ein Mengenger st bilden Damit der Architekt eine Vorstellung ber die Anforderungen an die Belastbarkeit des Syste erh lt um das System daf r entsprechend auszulegen muss er wissen mit wie vielen Daten er es zu tun haben wird macht einen gravierenden Unterschied ob ein System etwa 10 oder 10 000 Benutzer unterst tzen muss Damit der Architekt das System auch f r zuk nftige Anforderungen skalierbar entwerfen kann sollten neben dem heutigen Mengenger st auch realistische Prognosen gemacht werden wie sich das Mengenger st in Zukunft entwickeln wird e Den Kunden Benutzer einbeziehen Wir entwickeln f r den Kunden der uns daf r bezahlt und f r die Benutzer die unser System sp ter benutzen sollen Ihre Belange sind Ausgangspunkt unseres Projekts Sie k nnen an verschiedenen Stellen im Entwicklungsprozess eingebunden werden nicht nur w hrend der Anforderungsanalyse und am Ende beim Akzeptanztest Beim partizipativen Vorgehen beispielsweise werden wir in kurzen Zeitabst nden Prototypen und verschiedene Inkremente des Systems vorf hren um ihr Feedback einzuholen Ganz besonders ben tigen wir sie aber w hrend der initialen Anforderungsanalyse Um sicher zu stellen dass wir die Anforderungsspezifikation die W nsche d Kunden und der Benutzer treffend widerspiegelt sollte die Anforderungsspezifikation in einem Review mit Kunden und Benutzern abgenommen
52. en k nnen oder schlimmer noch eine Antwort erfinden Art der Frage Ist eine offene geschlossene oder hybride Frage angebracht siehe unten Anordnung der Fragen Die Reihenfolge der Fragen kann das Ergebnis beeinflussen ber jede Frage denkt der Befrag nach Die Assoziationen k nnen einen Kontext herstellen der die Antwort auf die n chste Frage beeinflusst Bsp Um ein krasses Beispiel zu nennen Wenn wir den Verk ufer in unserem Fahrradladen als erstes fragen w rden ob er sich durch den geplanten Einsatz unseres Softwaresystems unn tz f hlen w rde wird das vermutlich Einfluss auf den Verla der weiteren Befragung nehmen Befragung Software Projekt See Fi Fi Anforderungsanalyse EEEE 1 o Wird die Frage verstanden ce Bezugsrahmen der Befragten st An a lyse o Informationsstand der Befragten I o Art der Frage CO o Anordnung der Fragen B fi o Erhebungssituation Interviewereinfluss e ra 8 u n 8 o Gr nde f r die Antwort der Befragten N e Was ist der m gliche Einfluss der Situation in der der Fragebogen erhoben wird Was ist insbesondere der Einfluss dd Interviewers falls die Fragen in einem Interview gestellt werden Bsp Fragt man Menschen die eben aus einem Kinofilm zu einer Naturkatastrophe wie z B einer Flutwelle kommen zum Thema Naturschutz sind andere Antworten zu erwarten wie wenn wir die selben Menschen bei einem Transatlantikflug zu ihrem Urlaubsort fragen Auch de
53. en mit vielen Konjunktiven verzichten Ansonsten kann eine negative Antwort unterschiedliche Ursachen haben die die sich auf den eigentlichen Frageinhalt beziehen oder jene die die Pr missen in Frage stellen Die Frage sollte neutral und nicht suggestiv gestellt werden ansonsten legt man dem Befragten die Antwort bereits in den Mund Man sollte eine gleiche Anzahl negativer und positiver Antwortm glichkeiten vorsehen Eine Disbalance von entweder negativen oder positiven Fragen wirkt suggestiv Au erdem gibt es eine menschliche Tendenz eher positiv zu antworten Auch bei geschlossenen Fragen sollte es stets m glich sein dass der Befragte aussagen kann dass er auf eine Frage nicht antworten kann oder will um erzwungene Falschaussagen zu vermeiden Beobachtung Prinzipien der Ethnographie o Nat rliche Umgebung Aktivit ten in Alltagsumgebung untersuchen o Ganzheitlichkeit Einzelverhalten im Kontext untersuchen o Beschreiben nicht bewerten Ist Verhalten nicht Soll Verhalten o Sicht der Handelnden einnehmen Verhalten beschreiben in Begriffen die f r den Handelnden relevant und bedeutungsvoll sind Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 2008 11 04 Interview im Kontext Software Projekt Se crac nE se EAE RE Beobachtung Prinzipien der Ethnographie o Nat rliche Umgebung Aktivit ten in Alltagsumgebung untersuchen Verhalten b
54. en muss Haben wir die Systemgrenzen gezogen untersuchen wir die Art und den Umfang der Verbindungen innerhalb des Systems und nach au en Wir bestimmen wer innerhalb des System miteinander und welche unserer inneren Akteure mit welchen externen Akteuren interagiert Die Interaktion zwischen externen Akteuren k nnen wir in der Regel vernachl ssigen Das Ergebnis l sst sich als Graph repr sentieren dessen Knoten die Akteure und dessen Kanten die Interaktionen darstellen Ist Zustand relevante Akteure Grundsatz Kenne deinen Benutzer Aber Der Benutzer bzw die Benutzerin ist eine Illusion Es sind individuelle Menschen um die es geht Andererseits Wir k nnen nicht jeden betrachten und m ssen zusammenfassen Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 19 82 Ist Zustand relevante Akteure Software Projekt sr ee Q WA e ru ngsa n a yse Grundsatz Kenne deinen Benutzer m Der Benutzer bzw die Benutzerin ist eine Illusion Es sin Ist Analyse ee Ben CO L Andererseits Wir k nnen nicht jeden betrachten und m ssen S Ist Zustand relevante Akteure Fetches N Nachdem wir alle Akteure bestimmt haben untersuchen wir die menschlichen Akteure weiter im Detail Dies sind die potentiellen Benutzer unseres zuk nftigen Softwaresystems Zum Teil erscheinen sie uns bisher noch recht abstrakt etwa der Verk ufer und der K ufer Diese Rollen definieren bestimmte Klassen v
55. en und dann auf diesen Abschnitt verzichten Das Prinzip der Trennung von Aspekten dem wir bei einer Anforderungsspezifikation folgen leg aber einen eigenen Abschnitt nahe Die Beschreibung kann z B durch einfache Tabellen erfolgen in denen die Produktfunktionen aufgef hrt sind und die maximale Reaktionszeit in Abh ngigkeit der Eingabe angegeben wird 3 4 Entwurfseinschr nkungen Implementierungsdetails geh ren wie schon mehrfach gesagt nicht in die Anforderungsspezifikation Es gibt aber dennoch h ufig Aspekte die beim Entwurf ber cksichtigt werden m ssen Dazu geh ren z B Standards an die sich d Software halten muss In der Luft und Raumfahrt beispielsweise gibt es Codierungsstandards wie MISRA deren Einhaltung zuverl ssigere Systeme verspricht Hersteller von Software m ssen sich an solche Standards halten sonst wird ihr System nicht verwendet In diesem Abschnitt werden aus diesem Grund alle weiteren Einschr nkungen des Entwurfs beschrieben sofern sie aus Kundensicht relevant sind 2008 11 04 2008 11 04 a Inhalt der Anforderungsspezifikation nach IEEE Standard Software Projekt oe sc i 3 Detaillierte Beschreibung L Anforderungsanalyse ne 3 1 2 Hardwareschnittstelle er 4 3 13 Softwareschnittstelle Anforderungsspezifikation em anne 3 3 Performanzanforderungen m Inhalt der Anforderungsspezifikation nach IEEE a Standard 830 1998 I Ta Zuverksigke Verf gbarkeit Sicherheit Warbakt Portab
56. entfernen um ihn aus seiner Konfiguration zu l schen oder ersetzen um ihn durch einen neuen Artikel zu ersetzen Beispiel passives Storyboard TUNGSTEN 4300038 S ttel zes SATTEL SPECIAUZED BG CARBON kann von seiten des Herstellers nicht geliefert w erden 145 Euro 4200044 S ttel 294 SATTEL BROOKS COLT 100 Euro 4200111 S ttel 204 SATTEL BROOKS MODELL amp 130 78 Euro 4300149 S ttel 222 SATTEL SPECIALIZED BG PRO women 47 Euro Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 57 82 Software Projekt ae zes here emai eae Be Prototyping Li ig passives Storyboard 2008 11 04 Bsp Bild 3 Nehmen wir an wir w hlen den Sattel aus und w hlen ersetzen Dann gelangen wir zum n chsten Dialog Als n chstes werden alle S ttel angezeigt die zum Fahrrad des Kunden passen sortiert nach dem Preis Es werden maximal vier Artikel angezeigt Diese Liste kann weiter verarbeitet werden indem wir mit den Stift tippen oder die Tasten bedienen Ber hren wir mit dem Stift das Bild des Sattels 1 den Beschreibungstext 2 oder den Preis dann gelangen wir zum Kaufdialog Bedienen wir auf dem Tastenfeld die Nach Oben 4 beziehungsweise die Nach Unten Taste 5 k nnen wir den sichtbaren Ausschnitt in der Liste der gefundenen Artikel nach oben beziehungsweise nach unten bewegen Mit der Auswahltaste 5 gelangen wir zum Kaufdialog
57. er Darstellung Anforderungsspezifikation ern 6 pr zise schlie t Umgangssprache aus F an 5 in der Form Angestrebte Eigenschaften der Spezifikation E yatta Weil eine Anforderungsspezifikation von so tragender Bedeutung ist streben wir eine hochqualitative an Welche Eigenschaften m ssen wir aber hierzu anstreben Die anzustrebenden Eigenschaften lassen sich wie folgt kategorisieren Den Inhalt betreffend 1 2 3 4 Software Projekt inhaltlich 1 itreffend cht korrekt Anforderungsanalyse 2 eine lt a den W nsche des Kunden 3 widerspruchsfrei oder konsistent damit auch realisierbar 4 neutral d h abstrakt und damit offen f r beliebigen Entwurf ap x in der Darstellung Anforderungsspezifikation ee 6 pr zise schlie t Umgangssprache aus bs pe in der Form Angestrebte Eigenschaften der Spezifikation ee Die Darstellung betreffend 5 6 Angestrebte Eigenschaften der Spezifikation 9 objektivierbar auch nicht sinnvoll testbar genannt Diese Merkmale konkurrieren d h die Erf llung des einen erschwert oder verhindert die Erf llung des anderen zutreffend die Anforderungen des Kunden werden richtig wieder gegeben an manchen Stellen wird f r zutreffend auq der Begriff korrekt synonym verwendet wir werden aber im Folgenden den Begriff korrekt f r das Verh ltnis der Implementierung zur Anforderungsspezifikation reservieren eine Implementierung ist dann korrekt
58. erbesserung f r ein Problem des Kunden schaffen soll Damit dieses Konzept auch wirklich hilft ist es notwendig zuerst einmal zu verstehen was das Problem des Kunden ist Insofern ist die Analyse des Ist Zustands und seiner Probleme Teil einer Anforderungsanalyse Das Ergebnis der Anforderungsanalyse ist der Katalog der Anforderungen In welcher Form dieser Katalog beschrieben ist h ngt vom Vorgehensmodell ab Bei dokumentengetriebenen Vorgehensmodellen wie dem Wasserfallmodell werden die Anforderungen in Form einer Anforderungsspezifikation schriftlich festgehalten In vielen agilen Vorgehensmodellen erfolgt die Anforderungsspezifikation als Zuruf des Kunden Wann und wie oft die Anforderungsanalyse durchgef hrt wird h ngt ebenso stark vom Vorgehensmodell zur Softwareentwicklung ab Beim Wasserfallmodell wird die Anforderungsanalyse nur einmal und ganz zu Anfang durchgef hrt Beim inkrementellen Vorgehen bei dem die Entwicklung in kleinen abgeschlossenen Inkrementen des zu entwickelnden Systems erfolgt wird sie jedes Mal wieder vor der Entwicklung jedes Inkrements durchgef hrt Beim Extreme Programming hat man durch die Pr senz eines Kundenvertreters vor Ort eine fast kontinuierlich stattfindende Anforderungsanalyse In diesem Modul geht es um die Durchf hrung der Anforderungsanalyse Wir streben hier die schriftliche Dokumentation der Anforderungen in Form einer Anforderungsspezifikation an da dies in den meisten F llen eine Rei
59. eschreiben in Begriffen die f r den i und bedeutungsvoll sind In der Befragung adressieren wir hauptsachlich das bewusste Wissen Wir haben weiter oben schon gelernt dass das nur rund ein Drittel des menschlichen Wissens ausmacht Durch Beobachtung k nnen wir uns noch weiteres Wissen erschlie en In der Sozialwissenschaft hat sich die Ethnographie als Technik etabliert Die Ethnographie ist eine teilnehmende Beobachtung Es hat offensichtlich keinen Sinn das Leben von Urv lker zu ergr nden indem man sie ihrer Heimat entrei t und sie im Labor untersucht Eigenschaften von Sozialgemeinschaften sind abh ngig vom Kontext und m ssen deshalb in diesem Kontext untersucht werden Die Ethnographie folgt bei der Beobachtung einer Reihe von Prinzipien e Die soziale Gemeinschaft wird in ihrer nat rlichen Umgebung beobachtet Auf diese Weise werden ihre Aktivit ten in d Alltagsumgebung untersucht e Das Einzelverhalten wird im Kontext untersucht Verhaltensweisen sind meist sehr komplex und lassen sich nur schwe isolieren und kontrollieren wie das f r Laborversuche versucht wird e Im Vordergrund steht das neutrale Beschreiben und nicht die Bewertung Wertung sozialen Handelns orientiert sich a moralischen Ma st ben die jedoch kontextabh ngig sind Setzen wir uns die eigene moralische Brille auf werden wir meist schlechtsichtiger und bersehen wichtige Details Wir sind bei der Ist Analyse am Ist und nicht am Soll Verhalt inter
60. eschrieben sein sollt4 sollten wir in der Anforderungsanalyse pr zise Konzepte entwickeln und sie dem Kunden und Benutzer vorf hren um Konzepte zu evaluieren und zu verbessern Andererseits k nnen wir zu einem so fr hen Zeitpunkt nicht die ganze Applikation bereits entwickeln Darum also Prototypen Prototypen erlauben damit eine fr hzeitige Beteiligung der Benutzer Der Benutzer selbst kann sich ein genaueres Bild des sp teren Systems machen und fr hzeitig korrigierend eingreifen Prototypen vermeiden das Leere Blatt Syndrom das wir von Schriftstellern kennen die die erste Seite ihres neuen Romans schreiben sollen Mit Prototypen k nnen wir direkt loslegen Insbesondere Papierprototypen helfen uns einen schnellen Einstieg zu finden weil sie billig herzustellen und leicht nderbar sind Prototypen reduzieren Entwicklungsrisiken durch fr hzeitige Diskussion mit Beteiligten Wir wissen wie teuer uns sp Anderungen kommen Darum stellen wir durch fr hes Vorzeigen und Einbeziehen der Benutzer sicher dass wir auf de richtigen Weg sind Daf r ist eine Anfangsinvestition notwendig um den Prototypen zu entwickeln die sich aber im Verlaufe des Projekts mit sehr hoher Wahrscheinlichkeit amortisiert weil weniger Fehler in der Anforderungsanalyse gemacht werden Geeignete Werkzeuge erm glichen die schnelle Erstellung von Prototypen so dass sich die Kosten in Grenzen halten Beispielsweise gibt es GUI Builder mit denen man sich rasch
61. eses Kapitel ist sehr umfangreich und alle Leser sollen sich m glichst einfach darin zurecht finden Welche Kategorisierung zu verwenden ist h ngt von der Art der Anwendung ab Bei reaktiven Systemen also z B Steuerungssystemen kann man nach den Stimuli gruppieren auf die die Software reagieren muss Bei einer Software die das Landen eines Flugzeugs steuert k nnte man z B nach pl tzlichem Energieverlust Windwechsel oder Schlingern etc ordnen Zu den allgemeineren Ordnungskriterien die bei sehr vielen Arten von Systemen Anwendung finden k nnen z hlen Operationsmodi Kontrollsysteme haben z B h ufig die Operationsmodi Training Normal und Notfall Ein weiteres allgemeines Kriterium ist das der Benutzerklassen Die Software eines Busses k nnte unterscheiden in Produktfunktionen die Fahrer Fahrg ste oder Wartungstechniker betreffen Bei objektorientiertem Vorgehen ergeben sich in der Analyse Objekte und Klassen nach denen man gruppieren k nnte In einem Patientenmonitorsystem erwarten wir als Klassen z B Patienten Sensoren Pflegepersonal Raume Arztinnen Medizin Jede dieser Klassen wird dann beschrieben durch ihre Attribute und Nachrichten die sie versteht Schlie lich k nnen wir auch nach Anwendungsf llen kategorisieren Bei einem Telefonsystem w ren das zum Beispiel das Nahgespr ch die Weiterleitung und das Konferenzgespr ch Wie immer man sich entscheidet man sollte in jedem Falle die Kategorisierung uniform anwenden E
62. essiert e Wir versuchen die Sicht der Handelnden einzunehmen d h wir beschreiben das Verhalten in Begriffen die f r den Handelnden relevant und bedeutungsvoll sind Die Einhaltung dieser Prinzipien sichert uns einen besseren Einblick ist eine Form der ethnographischen Untersuchung nach dem Meister Lehrling Modell Lernen durch Vormachen und Beobachten sowie Fragen und Kl ren gepr gt durch Bescheidenheit o Neugier o Aufmerksamkeit Q konkrete statt abstrakter Fragen Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 Handelnden relevant 42 82 2008 11 04 Interview im Kontext Software Projekt Anforderungsanalyse ogee Interview im Kontext En Eine spezielle Form der ethnographischen Untersuchung ist das Interview im Kontext Es orientiert sich am Meister Lehrling Modell Lernen findet hier in der Beobachtung des Meisters im aktiven Nachfragen und Zeigen sowie im Mitmachen statt Statt in einem Frontalunterricht im H rsaal zu theoretisieren nimmt der Meister seinen Lehrling mit auf die Baustelle Der Meister arbeitet vor und der Lehrling lernt aus der Beobachtung Der Lehrling fragt nach wenn ihm etwas nicht klar ist und er versucht sich auch selbst Das Meister Lehrling Modell ist gepr gt durch Bescheidenheit Neugier Aufmerksamkeit und konkrete statt abstrakter Fragen des Lehrlings im unmittelbaren Kontext Beispiel eines Ablaufes Einleitung 15 mi
63. ft oder gar gestohlen ist Wegweiser Ist Analyse Welchen Techniken k nnen wir in der Ist Analyse nutzen Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 33 82 Ist Zustand Wie Erhebungstechniken Auswertung vorhandener Dokumente o Befragung o schriftlicher Fragebogen o Interview o Beobachtung anekdotisch lt gt systematisch o teilnehmend nicht teilnehmend o offen gt verdeckt Q selbst gt fremd Feld gt Labor Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 34 82 2008 11 04 2008 11 04 Ist Zustand Wie Software Projekt Erhebungstechniken fra Seinen gt Auswertung vorhandener Dokumente o Befragung schriftlicher Fragebogen Ist Analyse enter gt Beobachtung anekdotisch systematisch Ist Zustand Wie Ae gt selbst fremd Feld e Labor Wir wissen nun was wir erheben sollen aber leider noch nicht wie wir das tun k nnen In diesem Abschnitt lernen wir hierf r verschiedene Erhebungstechniken kennen Die Auswertung der vorhandenen Dokumente ist eine erste offensichtliche Technik Dar ber hinaus k nnen wir jedoch auch die Akteure fragen oder beobachten Um Akteure zu befragen k nnen wir sie selbst interviewen oder ihnen aber einen schriftlichen Fragebogen zuschicken Beim Interview kann man auch mit einem vorher gr ndlich ausgearbeiteten Fragebogen arbeiten oder aber nur
64. g der Benutzung durch eine festgelegte oder vorausgesetzte Benutzergruppe e Verst ndlichkeit Aufwand f r den Benutzer das Konzept und die Anwendung zu verstehen e Erlernbarkeit Aufwand f r den Benutzer die Anwendung zu erlernen z B Bedienung Ein Ausgabe e Bedienbarkeit Aufwand f r den Benutzer die Anwendung zu bedienen Effizienz Verh ltnis zwischen dem Leistungsniveau der Software und dem Umfang der eingesetzten Betriebsmittel unter festgelegten Bedingungen e Zeitverhalten Antwort und Verarbeitungszeiten sowie Durchsatz bei der Funktionsausf hrung e Verbrauchsverhalten Anzahl und Dauer der ben tigten Betriebsmittel f r die Erf llung der Funktionen nderbarkeit Aufwand der zur Durchf hrung vorgegebener nderungen notwendig ist nderungen Korrekturen Verbesserungen oder Anpassungen an nderungen der Umgebung der Anforderungen und der funktionalen Spezifikationen e Analysierbarkeit Aufwand um M ngel oder Ursachen von Versagen zu diagnostizieren oder um nderungsbed rftige Teile zu bestimmen e Modifizierbarkeit Aufwand zur Ausf hrung von Verbesserungen zur Fehlerbeseitigung oder Anpassung an Umgebungs nderungen e Stabilit t Wahrscheinlichkeit des Auftretens unerwarteter Wirkungen von nderungen e Pr fbarkeit Aufwand der zur Pr fung der ge nderten Software notwendig ist bertragbarkeit Eignung der Software von einer Umgebung in eine andere bertragen zu werden Umgebung kann organisatoris
65. ge des Systems f r das die Softwarel sung angestrebt wird e Aufgaben der Umfang und die Art der anfallenden Aufgaben Operationen und Besonderheiten im Ablauf e Kommunikation die Vorrichtungen und Gelegenheiten zur Kommunikation und ihr Ablauf e Dokumenten schriftliche oder elektronische Dokumente die verwendet und produziert werden e Daten Umfang und Art der verarbeiteten Daten in den Dokumenten und ber sie hinaus e Schwachstellen die bestehenden M ngel Unvollst ndigkeiten und Redundanzen des Ist Zustands Wie werden diese Aspekte nun vertiefen und benutzen als illustrierendes Beispiel eine Verkaufssituation in einem Fahrradladen f r die wir eine softwaretechnische Unterst tzung entwickeln sollen Ist Zustand Was Verstandnis von o Struktur Bestandteile organisatorisches Gef ge des Systems f r das o Aufgaben x Softwarel sung angestrebt wird o Kommunikation o relevante Akteure o Dokumenten o Systemgrenzen o Daten 7 gt o Art und Umfang der Verbindungen innerhalb und nach au en o Schwachstellen Ihn Gro h ndler Verk ufer 2 N u ee Kunde 2 Pa Verk ufer 1 Kunde 1 Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 18 82 Ist Zustand Was Software Projekt Verst ndnis von und nach au en Be st Zustand Was 2008 11 04 Ladenbesitzer BERN Bestandteile 3 organisatorisches Gef ge des Systems f r das Anforderungsanalyse
66. he der relevanten Aspekte beispielsweise UML Klassendiagramme Das Datenmodell beschreibt das Volumen und zuk nftig erwartete Wachstum der Daten Dies wird h ufig als das Mengenger st bezeichnet Es ist unerl sslich f r die Absch tzung des Speicherbedarfs und der Anforderungen an die Performanz der Algorithmen Mit der Betrachtung des zuk nftigen Wachstums stellen wir sicher dass unser System skaliert und auch in einigen Jahren noch die notwendige Performanz zur Verf gung stellen wird Die Daten haben einen Typ f r den wir den Wertebereich angeben Sie werden in vielen F llen dauerhaft gespeichert auf Datentr gern die aber nicht notwendigerweise unmittelbar elektronisch verarbeitbar sind z B weil sie von Hand auf Papier geschrieben werden Viele Daten k nnen sortiert werden d h verf gen ber ein oder mehrere Ordnungskriterien Unsere Programme m ssen sie meist nach diesen Ordnungskriterien sortieren k nnen Die H ufigkeit ihrer Verarbeitung ist f r uns wichtig weil wir damit die Zugriffe entsprechend organisieren m ssen H ufig verarbeitete Daten m ssen schnell verf gbar sein Schlie lich interessieren uns die Art und Erfordernisse der Datensicherung sowie die Abh ngigkeiten zwischen den Daten H ufige solche Abh ngigkeiten sind die Teil Von Beziehung in Form der Aggregation und Komposition Andere Beziehungen werden in UML Klassendiagrammen mit allgemeinen Assoziationen modelliert Ist Zustand Was Software Projekt Anf
67. he von Problemen vermeidet Der Inhalt dieses Abschnitts ist jedoch auch f r agiles Vorgehen ohne schriftliche Spezifikation der Anforderungen relevant weil auch orale berlieferung zu allen Aspekten der Anforderungsspezifikation Stellung nehmen muss bersicht Zun chst widmen wir uns der Frage warum die Anforderungsanalyse so wichtig aber leider auch schwierig ist Dann lernen wir die grunds tzlichen Schritte der Anforderungsanalyse kennen Dazu geh ren die Erfassung des Ist Zustands und seiner Probleme durch die Ist Analyse die angestrebte Verbesserung durch ein Soll Konzept durch die Soll Analyse und die genaue und vollst ndige Beschreibung der Anforderungen in Form einer Anforderungsspezifikation Wir vertiefen alle Schritte und lernen Techniken f r diese einzelnen Schritte kennen Wegweiser Herausforderungen Warum sind die Anforderungen so kritisch Warum ist ihre Erhebung so schwer Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 6 82 Kosten fur Anderungen 2008 11 04 Kosten f r nderung 60 100 x 1 5 6x 1x Zeit Definition Entwicklung nach Auslieferung Pressman 2003 Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 Kosten fiir Anderungen Software Projekt Kosten fiir Anderung 60 100 x ee nicrdeminresnal se gsi ren f r nderungen ie 7 82 Zeit Definition Entwicklung nach Auslieferung Die Anforderung
68. higen Systems im Soll Analyse Prototyping ee eu o wird in weiteren Ausbaustufen zum endg ltigen Produkt weiterentwickelt yon von Prototypen in Bezug auf Lebensdauer 2008 11 04 Im Gegensatz zum Wegwerf Prototypen ist es beim evolution ren Prototypen vorgesehen ihn schrittweise zum Endprodukt auszubauen Er dient dazu ein funktionsf higes Systems m glichst schnell bereit zu stellen wobei aber zu Anfang nicht die vollst ndige Funktionalit t erwartet wird Evolution re Prototypen finden ihren Einsatz unter anderem im Rahmen von evolution ren Prozessmodellen zur Softwareentwicklung Der Vorteil dieser inkrementellen Entwicklung ist es dass jede funktionst chtige Ausbaustufe vom Benutzer erprobt werden kann Die Erfahrung und Kritik der Benutzer mit der Ausbaustufe nimmt Einfluss auf die n chste Ausbaustufe Iterativ wird der evolution re Prototyp in weiteren Ausbaustufen zum endg ltigen Produkt weiterentwickelt Bsp Die Ausbaustufen f r die evolution re Entwicklung eines Textverarbeitungssystems k nnten zum Beispiel so aussehen 1 grundlegende Funktionalit t Datei Management Editor Textausgabe 2 erweiterte Funktionalit t Style Files Bearbeitung mathematischer Formeln Einbinden von Graphiken 3 zus tzliche Funktionalit t Rechtschreibpr fung Grammatik berpr fung berarbeitungsmodus 4 erg nzende Funktionalit t Tabellenkalkulation Gesch ftsgraphiken E Mail Web Browser Scanner Anbindung T
69. i Bremen Software Projekt Wintersemester 2008 09 l sen gedenken 45 82 2008 11 04 Prototyping Software Projekt Zielsetzung A fi d o Anforderungen anhand eines Beispiels erheben und berpr fen nrorderu ngsa na yse technische M glichkeiten berpr fen und demonstrieren r o fr hzeitig m gliche L sungsans tze pr sentieren L Soll Analyse P u o na yse rototy pl n 8 rasche und billige Entwicklung eines prototypischen Systems als Diskussionsgrundlage P rototy pi ng Typen unterscheiden sich in o Lebensdauer Wegwerfprototyp evolution rer Prototyp o Zweck technische Machbarkeit Demonstration der Funktionalit t oder Interaktion Prototypen sind Zwischenprodukte in der Entwicklung die dem Endprodukt in bestimmten relevanten Aspekten bereits stark hneln sollen die aber noch nicht vollst ndig sind Eine andere Sichtweise von Prototypen ist es sie als ein kosteng nstigeres Modell f r das Endprodukt zu betrachten Prototypen sind in anderen Ingenieursdisziplinen allgegenw rtig Architekten lassen dreidimensionale ma stabsgetreue kleine Modelle eines Geb udes anfertigen Ein zuk nftiger Bewohner kann auf diese Weise einen wesentlich lebendigeren Eindruck erhalten als es ihm mit einem Bauplan m glich w re Flugzeugbauer erproben an Prototypen den Windwiderstand im Windkanal Diese Idee bernimmt die Softwaretechnik Die Ziele hierbei sind meist die Anforderungen anhand eines Beispiel
70. ichnung der Inhalt der Grad der Formalisierung der Aufbau der Verteiler d h wer das Dokument erh lt die Archivierung des Dokuments sowie die Produzenten und Konsumenten des Dokuments Bsp Im Fahrradladen gibt es beispielsweise den Kassenzettel Sein Inhalt ist die gekaufte Warte der Preis die anrechenbare Mehrwertsteuer das Kaufdatum sowie der Verk ufer Der Kassenzettel muss dem Gesetz gen gen und ist darum recht formalisiert Den Kassenzettel erh lt der Kunde ein Durchschlag bleibt in der Kasse des Ladens Sowohl der Kunde als auch der Laden archivieren den Kassenzettel der Kunde um gegebenenfalls seine Garantieanspr che durchzusetzen der Laden f r das Finanzamt Produziert wird der Kassenzettel von der Kasse des Ladens durch den Verk ufer und verwendet wird er vom Kunden im Falle eines Umtausches beziehungsweise vom Ladenbesitzer f r die Steuererkl rung Ist Zustand Was Verstandnis von o Struktur Aufgaben o Kommunikation Dokumenten Daten Schwachstellen Rainer Koschke Uni Bremen Ist Zustand Was Verstandnis von Struktur Aufgaben o Kommunikation Dokumenten Daten Schwachstellen Rainer Koschke Uni Bremen Bestandteile Umfang und Art der verarbeiteten Daten Q Volumen und Wachstum 41 Flaschenhalter Wertebereiche Radius Halterung Abstand Schrauben versch Farben etc Datentrager
71. ie nicht nur von einem Autoren erstellt so dass die Zusammenarbeit mehrerer Autoren unterst tzt werden musg Die Anforderungsspezifikation muss also modular aufgebaut sein 8 leicht verwaltbar die Anforderungsspezifikation muss durch zweckm ige Strukturierung eindeutige Referenzierbarke und explizite Querbez ge leicht berarbeitet und versioniert werden k nnen Idealerweise ist der Code ber den Entwu hin zu den Anforderungen verkn pft um eine hohe Nachvollziehbarkeit zwischen diesen Dokumenten zu gew hrleisten da die Dokumente nachgef hrt werden m ssen wenn sich Dinge ndern Hierf r wurden eine Reihe von Werkzeugen wie z B Doors entwickelt 9 objektivierbar f r jede Anforderung muss es m glich sein eine Pr fprozedur anzugeben mit deren Hilfe man objektiy entscheiden kann ob das resultierende System die Anforderung erf llt synonym zu objektivierbar wird h ufig auch de Begriff testbar verwendet dieser Begriff suggeriert jedoch dass man das System f r die Pr fung ausf hren k nnen m vgl das Kursmodul Test die meisten Pr fungen lassen sich aber ohne Ausf hrung des Systems durchf hren Die Anforderung Die Programm soll eine hohe Performanz aufweisen ist ein Negativbeispiel f r eine objektivierbare Anforderung Hier ist unklar was hohe Performanz genau bedeutet Statt dessen sollte die Anforderung vielmehr in der folgenden Weise formuliert werden Die Ausgabe soll in mindestens 60 aller F lle na
72. il sie auf Existierendem basiert Befragung und Beobachtung setzen auch etwas Existierendes voraus Man kann sie aber auch einsetzen um Prototypen zu evaluieren Prototypen sind eine Vision des Soll Zustandes die handfest und berpr fbar ist Mit ihnen kann man durch geeignete Evaluierung auch die Folgen des Einsatzes des spaterens Systems absch tzen Man kann also zum Beispiel demonstrieren dass fr here Redundanzen und manuelle Eingriffe nicht mehr existieren werden was die Fehleranf lligkeit reduziert Au erdem kann man nachweisen dass ein Benutzer schneller seine Aufgabe erledigen kann als das vorher der Fall war Analysetechniken Software Projekt L A nford eru ngsa na l yse eae ee Kar wen Daten Dokumente 5 Beobachtungen E a a der Techniken Bam offene Fragen s nal setechniken ae eur y partizipative Entwicklung Die partizipative Entwicklung ist die Softwareentwicklung die die sp teren Benutzer einbezieht wohl gemerkt die Benutzer nicht nur den Kunden Es gibt hierf r verschiedene Auspr gungen Die Benutzer k nnen zu Anfang in der Phase des Interaktions Designs bei der Entwicklung von Prototypen einbezogen werden und gegen Ende beim Akzeptanztest Bei inkrementellen Entwicklungsprozessen bei denen ein System in kleineren funktionst chtigen Inkrementen entwickelt werden werden sie noch st rker einbezogen Dort evaluieren sie jedes einzelne Inkrement also Zwischenprodukt und nicht nur das Endprodukt
73. ilit t 3 6 Andere Anforderungen 3 5 Softwaresystemattribute Neben Performanzanforderungen gibt es noch weitere Systemattribute zu denen die Anforderungsspezifikation Aussag machen muss Dazu geh ren Zuverl ssigkeit Verf gbarkeit Sicherheit Wartbarkeit Portabilit t und weitere Softwarequalit ten oft auch nichtfunktionale Anforderungen genannt Wir werden weiter unten noch darauf zu sprechen kommen dass diese Art Anforderungen konkret beschrieben werden m ssen Die Forderung Das System mu sicher sein ist viel zu allgemein als dass man sie erf llen k nnte 3 6 Andere Anforderungen In diesem Abschnitt k nnen weitere relevante Anforderungen beschrieben werden die in keine der oben genannten Abschnitte passen a Inhalt der Anforderungsspezifikation nach IEEE Standard Software Projekt EME E i J 3 Detaillierte Beschreibung Anforderungsanalyse er 3 1 2 Hardwareschnittstelle a P 3 1 3 Softwareschnittstelle Anforderungsspezifikation messe 3 3 Performanzanforderungen Inhalt der Anforderungsspezifikation nach IEEE nen Standard 830 1998 IS Zuerisighe Verf gbarkeit Sicherheit Warbak Portabilit t 3 6 Andere Anforderungen Erg nzungen zum Standard Die Anforderungsspezifikation nach IEEE Standard 830 1998 verlangt nirgendwo dass die Ergebnisse der Ist Analyse beschrieben werden sollen Diese Ergebnisse sind jedoch wichtig um die Anforderungen zu verstehen und einsch tzen zu k nnen Man sollte deshalb entweder e
74. in der Lage operationale Hypothesen aufzustellen das hei t Hypothesen die wir objektiv durch Frageb gen berpr fen k nnen Frageformulierung einfache Worte kurz und konkret keine doppelten Negationen nur auf einen Sachverhalt bezogen nicht hypothetisch neutral nicht suggestiv Befragten nicht berfordern balanciert negative und positive Antwortm glichkeiten immer eine wei nicht Kategorie bieten Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 40 82 2008 11 04 Frageformulierung Software Projekt L A fi o einfache Worte n orderu ngsana yse o kurz und konkret keine doppelten Negationen nur auf einen Sachverhalt bezogen Ist Analyse a gt neutral nicht suggestiv Befragten nicht berfordern Frageformulierung gt balanciert negative und positive Antwortm glichkeiten o immer eine wei nicht Kategorie bieten Auch ber die Formulierung der Fragen muss man sich vorher sorgf ltig Gedanken machen da sie einen Einfluss auf die Antwort hat Man w hle m glichst einfache klare Worte so dass die Frage sicher verstanden werden kann Die Fragen sollten kurz und konkret sein Lange Fragen beinhalten viele Aspekte auf die man kaum eine klare abgeschlossene Antwort geben kann Auf abstrakte Fragen f llt die Antwort schwer Doppelt negierte Fragen gilt es zu vermeiden um den Befragten nicht zu verwirren Gleicherma en sollte man auf hypothetische Frag
75. in eigenes Dokument hierf r anlegen das in der Anforderungsspezifikation referenziert wird oder aber im Einf hrungskapitel einen entsprechenden Abschnitt verfassen Au erdem weist der Standard an keiner Stelle darauf hin dass auch die m glichen zuk nftigen nderungen der Anforderungen beschrieben sein sollten Diese sind jedoch wichtig damit der Architekt die Architektur so entwerfen kann dass diese Anderungen so sie eintreffen relativ einfach umgesetzt werden k nnen Aus diesem Grunde empfiehlt sich in Kapitel 2 beziehungsweise Kapitel 3 je nach Detaillierungsgrad ein Abschnitt zu zuk nftigen Entwicklungen der Anforderungen Im Datenmodell modellieren wir die Objekte der Anwendungsdom ne die f r die Beschreibung unserer Anforderungen relevant sind Im Standard wird kein Ort explizit genannt an dem das Datenmodell beschrieben werden soll Hier bietet sich ein Unterabschnitt in Abschnitt 2 2 an Softwaresystemattribute Softwaresystemattribute o oft als nicht funktionale Anforderungen bezeichnet o m ssen objektivierbar sein Das System soll sicher sein versus o PGP Verschl sselung wird verwendet o Logging aller Aktionen o Nachrichten d rfen nur ber Verschl sselungskomponente geschehen o Indizierte Zugriffe auf Felder m ssen zur Laufzeit gepr ft werden Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 76 82 Software Projekt PAS aS oa S Anforderun gsanalyse nen ate o
76. ing A Practioner s Approach F nfte Ausgabe McGraw Hill 2003 0 Sommerville 2004 SOMMERVILLE lan Software Engineering Siebte Ausgabe Addison Wesley 2004 Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 82 82
77. irkungen z B die ben tigte Genauigkeit von berechneten Werten e Angemessenheit Eignung der Funktionen f r spezifizierte Aufgaben z B aufgabenorientierte Zusammensetzung von Funktionen aus Teilfunktionen Interoperabilit t F higkeit mit vorgegebenen Systemen zusammen zu wirken e Ordnungsm igkeit Erf llung von anwendungsspezifischen Normen Vereinbarungen gesetzlichen Bestimmungen und hnlichen Vorschriften e Sicherheit F higkeit unberechtigten Zugriff sowohl versehentlich als auch vors tzlich auf Programme und Daten zu verhindern Zuverl ssigkeit F higkeit der Software ihr Leistungsniveau unter festgelegten Bedingungen ber einen festgelegten Zeitraum zu bewahren Reife Geringe Versagensh ufigkeit durch Fehlerzust nde e Fehlertoleranz F higkeit ein spezifiziertes Leistungsniveau bei Softwarefehlern oder Nicht Einhaltung ihrer spezifiziert Schnittstelle zu bewahren e Wiederherstellbarkeit F higkeit bei einem Versagen das Leistungsniveau wiederherzustellen und die direkt betroffener Daten wiederzugewinnen Produktqualitaten nach ISO IEC Standard 9126 2001 Software Projekt Rnderbarket Zuverl ssigkeit Funktionalit t N Stabilit t ra Sorgen E TA E L_Produktqualit ten nach ISO IEC Standard 9126 2001 2008 11 04 bertragbarkei Benutzbarkeit Aufwand der zur Benutzung erforderlich ist und individuelle Beurteilun
78. it Verf gbarkeit Sicherheit Wartbarkeit Portabilitat 3 6 Andere Anforderungen Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 75 82 Inhalt der Anforderungsspezifikation nach IEEE Standard Software Projekt 830 1998 st 3 Detaillierte Beschreibung Anforderungsanalyse ee L 2a See Anforderungsspezifikation en e ieee 3 3 Performanzanforderungen Inhalt der Anforderungsspezifikation nach IEEE le N St an d a rd 8 30 N 1 998 2 En net Sicherheit Wartbarkeit Portabilit t 3 6 Andere Anforderungen Den gr ten Anteil der Anforderungsspezifikation nimmt das Kapitel 3 ein in dem die Anforderungen in gr erem Detail beschrieben werden 3 Detaillierte Beschreibung 3 1 Externe Schnittstellen In den vier folgenden Abschnitten werden die verschiedenen Schnittstellen im Detail beschrieben Auf die Spezifikation der Benutzungsschnittstelle gehen wir an dieser Stelle besonders ein 3 1 1 Benutzungsschnittstelle Die Benutzungsschnittstelle kann durch einen GUI Prototypen beschrieben werden Wenn dieser ausf hrbar is dann werden im Text hier die wesentlichen Interaktionskonzepte beschrieben ansonsten wird auf den ausf hrbaren Prototypen verwiesen der vom Kunden abgenommen sein muss Ist der GUI Prototyp nicht ausf hrbar dann kann man hier die Screenshots und Skizzen einf gen die in der Soll Analyse erstellt wurden um die Benutzungsschnittstelle vorzuf hren Es gen gt jedoch nicht nur
79. keten am Projektende foe 7 Taa p Der 7 Erforderlich Kommunikationsf higkeit Oo Schritte der Anforderungsanalyse Spezifikation Sirenen fe N Abnahme den aBgenommene ao Ko Anforderungs spezifkation Pfichtenheft Typische Fehler bei der Anforderungsspezifikation sind vage Anforderungen z B dass die Software benutzerfreundlich sein soll und dass sie Implementierungsdetails beschreibt statt Anforderungen aus Kundensicht Weil die Anforderungsspezikation den Vertragsgegenstand festlegt fuhren Mangel nicht selten zu Vertragsstreitigkeiten am Ende des Projekts Wenn die Anforderungen nicht genau definiert wurden ist eine gerichtliche Auseinandersetzung sehr m hselig In jedem Falle ist ein solcher Streit f r alle Parteien zum eigenen Schaden Der Kunde hat nicht bekommen was er wollte wir bekommen m glicherweise unser Geld nicht Ein entt uschter Kunde schadet uns denn Entt uschung spricht sich schnell herum Wir werden uns also gro e M hen bei der Anforderungsspezifikation geben In den folgenden Abschnitten werden wir hierzu verschiedene Techniken kennen lernen die uns bei richtiger Ausf hrung vor Schaden bewahren k nnen Es sei auch hier nochmal darauf hingewiesen dass die genannten Schritte der Ist und Soll Analyse sowie das Festhalten der Anforderungen hochgradig iterativ sind und keineswegs so sequentiell wie durch den Datenfluss im Diagramm suggeriert Das muss bei der Planung beachtet werden Wegweiser Ist Analy
80. le ist Man hat also die Chance Neues zu erfahren Aus diesem Grund wendet man diesen Fragetyp an wenn man noch keine rechte Hypothese zu den m glichen Antworten hat Fragetypen Hybride Fragen Hybride Fragen Was stort Sie an der GUI LI lange Reaktionszeit C mangelnde Selbsterklarungsfahigkeit LI fehlendes Undo C umstandliche Dialogf hrung E Kombination von geschlossenen und offenen Fragen Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 38 82 Fragetypen Hybride Fragen Software Projekt Anforderungsanalyse sige selva O umst ndliche Dialogf hrung a ne Fragetypen Hybride Fragen 2008 11 04 Hybride Antworten kombinieren geschlossene und offene Fragen indem eine Menge alternativer Antworten vorgegeben wird es aber dennoch m glich ist durch Freitextfelder eigene Antworten zu formulieren Dies ist in vielen F llen ein guter Kompromiss der leichte Auswertbarkeit und die M glichkeit unvorhergesehene Antworten zu liefern bestm glich vereint solange die vorgegebenen Antworten m glichst viele echte Antworten abdecken Wann welche Erhebungsform weniger strukturiertes Interview stark strukturierter Fragebogen g gebog o unstrukturiertes o vorstrukturiertes Untersuchungsgebiet Untersuchungsgebiet o offene Gespr chsf hrung und gute Kenntnisse des gr ere Antwortspielraume Untersuchungsgebiets o pers nlicher Kontakt m glich o Operationalisierung de
81. lgen im dritten Kapitel 2 1 Produktperspektive Dieser Abschnitt bettet das zu implementierende System in ein Gesamtsystem ein Dazu werden alle seine Schnittstellen zu anderen Systemen und zum Benutzer beschrieben sowie weitere globale Einschr nkungen Wir werden bei der Beschreibung der Schnittstellen feststellen dass es nicht immer einfach ist eine Schnittstelle einer der unten aufgef hrten Kategorien eindeutig zuzuordnen Im Zweifel entscheiden wir uns f r eine und f gen in den anderen Abschnitten einen Querbezug zu dieser Beschreibung ein Prim r ist wichtig dass die Schnittstelle beschrieben ist Durch die Querbez ge stellen wir sicher dass wir diese Beschreibung finden werden egal in welchem Abschnitt wir intuitiv suchen 2 1 1 Systemschnittstellen Uber Systemschnittstellen ist das zu implementierende System mit anderen Systemen verbunden mit denen es zusammen arbeiten soll Dazu geh ren z B Import und Exportschnittstellen f r den Datenaustausch Scripting Schnittstellen ber die sich das System programmieren l sst sowie Application Interfaces API ber das man das System programmatisch steuern kann Bsp Hier k nnten wir f r PDAss fordern dass man die Herstellerkataloge in einem zu definierenden elektronischen XML basierten Format einlesen k nnen soll 2008 11 04 2008 11 04 Software Projekt 830 1998 2 Allgemeine Beschreibung 2 1 Produktperspektive Anforderungsanalyse Sete eet te 2 1 1 System
82. lgenden diese drei Typen n her beschreiben demonstrieren das zu diskutierende Systemverhalten als Geschichte Aa Aufwand IAnforderungsanalyse Passive Storyboards Demonstration Analytiker spielt die Bedienung mit dem System durch indem er entlang eines Anwendungsszenarios Eingabem glichkeiten und Systemreaktionen demonstriert Mittel o Skizzen o Bildschirm Masken Screenshots o m gliche Systemausgaben Bemerkung erm glicht einfache und billige Prototyperstellung erm glicht Interaktion mit Beteiligten am Beispiel erfordert Anwesenheit des Analytikers Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 54 82 Software Projekt ng mit dem System durch indem er Anforderungsanalyse cs Annan genen und soll Analyse Prototypi En Oll AAna yse 5 roto yp ng Bildschirm Masken Screenshots o m gliche Systemausgaben Bemerkung cht einfache und billige Prototyperstellung cht Interaktion mit Beteiligten am Beispiel 2008 11 04 er erfordert Anwesenheit des Analytikers Passive Storyboards erlauben selbst keine Interaktion Statt dessen spielt der Analytiker bei der Demonstration die Bedienung mit dem System durch indem er entlang eines Anwendungsszenarios die Eingabem glichkeiten und Systemreaktionen demonstriert Als Mittel werden Skizzen Bildschirm Masken in Form von Bildschirmabz gen Screenshots und m gliche Systemausgaben verwendet Di
83. m um was wir bislang kennen gelernt haben Wir werden hierzu Konkretisierungen und dar ber hinaus f hrende Erg nzungen kennen lernen Ergebnisse der Soll Analyse Datenmodell und Prognosen f r zuk nftige Anforderungen die auch beschrieben sein sollten Inhalt der Anforderungsspezifikation nach IEEE Standard 830 1998 1 Einf hrung 1 1 Zweck 1 2 Rahmen 3889 1 3 Definitionen Akronyme und Abk rzungen 1 4 Referenzen 1 5 bersicht ber das Dokument 2 Allgemeine Beschreibung 2 1 Produktperspektive 2 2 Produktfunktionen 2 3 Charakteristika der Benutzer 2 4 Einschr nkungen 2 5 Annahmen und Abh ngigkeiten 3 Detaillierte Beschreibung Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 71 82 Softwa re P roje kt I Anforderungsspezifikation nach IEEE Standard sa oO E ce E neal anion sree S he der Anforderungsspezifikation nach IEEE N Standard 830 1998 Der Standard gibt eine dreiteilige Struktur vor eine Einf hrung eine allgemeine Beschreibung und eine detaillierte Beschreibung Er folgt hierin den oben erw hnten Regeln nach Aspekten und Detaillierungsgrad zu ordnen Die Struktur bis in die zweite Gliederungsebene ist wie folgt 1 Einf hrung 1 1 Zweck 1 2 Rahmen 1 3 Definitionen Akronyme und Abk rzungen 1 4 Referenzen 1 5 Ubersicht ber das Dokument 2 Allgemeine Beschreibung 2 1 Produktperspektive 2 2 Produktfunktionen 2 3 Charakteristika der Benutzer 2 4 Ein
84. men vorgeben Einfache Pr fungen auf Vollst ndigkeit werden damit m glich e Die Spezifikation so fr h wie m glich pr fen und dem Konfigurationsmanagement unterstellen Die Anforderungsspezifikation sollte wir selbst mit internen Reviews berpr fen Nach Fertigstellung der Anforderungsspezifikation sollte mindestens eine Pr fung mit dem Kunden und den Benutzern stattfinden Weitere na fr here Pr fungen kann man mit Hilfe von Prototypen erreichen Die Anforderungsspezifikation wird sich ndern weil in Pr fungen und auch sp ter Fehler und L cken gefunden werdd Au erdem k nnen sich bei einer l ngeren Projektlaufzeit Anforderungen auch noch w hrend der Entwicklung ndern aufgrund ge nderter Rahmenbedingungen Zudem arbeiten meist mehrere Personen an der Anforderungsspezifikation Aus diesem Grund muss die Anforderungsspezifikation von Anbeginn unter das Konfigurationsmanagement gestellt werden e Die Spezifikation intensiv verwenden Die Anforderungsspezifikation ist der Ausgang f r alle weiteren Entwicklungen wird nicht nur benutzt beim Vertragsabschluss von Auftragnehmer und geber sondern f r eine Reihe weiterer Persong die f r die Entwicklung verantwortlich sind Dazu geh ren Architekten Programmierer Tester und Handbuchautoren sollte eine Selbstverst ndlichkeit sein dass diese Menschen die Spezifikation intensiv nutzen Leider hat die Praxis gezeigt dass z B viele Programmierer Fehler deshalb machen weil sie die Anfor
85. mmunikation Kassenzettel Dokumenten Sinha Daten gekaufte Ware Preis MWST Datum Schwachstellen Verk ufer o Grad der Formalisierung Aufbau gen gt Gesetz o Verteiler Kunde und Laden Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 27 82 Ist Zustand Was Verstandnis von Bestandteile Fortsetzung o Struktur o Archivierung o Aufgaben als Papier beim Kunden elektronisch in der Kommunikation Ladenkasse o Dokumenten o von wem produziert verwendet o Daten produziert von Kasse Verk ufer verwendet von Kunde beim Umtausch o Schwachstellen e Steuererkl rung Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 28 82 Softwa re P rojekt Ist Zustand Was S Anforderungsanalyse GE Deren Ist Ana lys e atone a ws Papier beim Kunden elektronisch in der amp L Penna Ist Zustand Was ence N Eine wichtige Informationsquelle bei der Ist Analyse liefern existierende Dokumente die verwendet und produziert werden Meist m ssen sie bei einer softwaretechnischen L sung im Rechner nachgebildet werden Dokumente k nnen eher formalisiert sein wie z B der Kassenbons im Fahrradladen oder eher informell sein wie z B der Notizzettel des K ufers auf dem er sich aufgeschrieben hat was er einkaufen m chte und zu welchem Fahrrad in seinem Besitz der neue Artikel passen soll Bei diesen Dokumenten interessieren uns die Beze
86. n Vorstellung Ziele Dank Zustimmung zu Aufzeichnung Vertraulichkeit Arbeit nicht Person wird betrachtet Meinungen zu technischer Unterst tzung berblick gewinnen 8 Ubergang 1 min o Regeln Rollen Beziehung o ich frage Sie d rfen abwehren Erhebung im Kontext 2 Std o Beobachtung und Nachfragen o Notizen machen mitlaufen sich unsichtbar machen o Pausen nach Wunsch Zusammenfassung 15 min o was die Besch ftigte tut ihre Rolle was wichtig ist o Erg nzungen Korrekturen Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 43 82 Beispiel eines Ablaufes Software Projekt Einleitung 15 min o Vorstellung Ziele Dank t o Zustimmung zu Aufzeichnung Vertraulichkeit oO Anforderungsanalyse a ee l 2 ehe zu technischer Unterst tzung bergang 1 min Ist Analyse ee ee i T EER CO Erhebung im Kontext 2 Std ri rt o Beobachti id Nachfr oO Beispiel eines Ablaufes gen C gt o Pausen nach Wunsch Zusammenfassung 15 min N was die Besch ftigte tut ihre Rolle o was wichtig ist o Erg nzungen Korrekturen Ein Interview im Kontext dauert in der Regel zwei Stunden plus direkte Vor und Nachbearbeitung Es k nnte wie folgt ablaufen 1 In einer Einleitung 15 min stellt sich der Fragende kurz vor und erl utert das Ziel der Befragung Er vergisst nicht sich ausdr cklich f r das Interview zu bedanken Er sichert absolute Vert
87. n oft auf Problem hinweisen sie tun sich oft aber schwerer eine geeignete L sung zu ersinnen Insbesondere fehlt ihnen dazu meist die realistische Einsch tzung zur technischen Machbarkeit f r die sie einen softwaretechnischen Hintergrund br uchten Zudem richten sich Fragen an das bewusste Wissen und wir k nnen damit nur eingeschr nkt relevante Aspekte erfassen Wenn aber Beobachtungen ausscheiden und Fragen nicht hinreichend sind wie k nnen wir dann vorgehen Es gibt das gefl gelte Wort des Benutzers know it when I see it Ich wei was ich will sobald ich es sehe Dieses Prinzip k nnen wir umsetzen Wir f hren dem Benutzer unsere L sung vor zu der er dann Stellung nehmen kann Nat rlich k nnen wir uns es nicht leisten gleich das gesamte System zu implementieren denn der Schaden w re gro wenn diese L sung dann doch nicht das war was der Benutzer haben m chte Statt dessen implementieren wir einen so genannten Prototypen Prototyping Zielsetzung o Anforderungen anhand eines Beispiels erheben und berpr fen o technische M glichkeiten berpr fen und demonstrieren o fr hzeitig m gliche L sungsans tze pr sentieren Idee o rasche und billige Entwicklung eines prototypischen Systems als Diskussionsgrundlage Typen unterscheiden sich in Lebensdauer Wegwerfprototyp evolutionarer Prototyp o Zweck technische Machbarkeit Demonstration der Funktionalit t oder Interaktion Rainer Koschke Un
88. n siner obaeeutaiba skin Systeme rhalkens Mittel Film Diashow Sol I An a yse P rototypi ng o selbstablaufende PowerPoint Pr sentation Bemerkung erm glicht einfache automatisierte Darstellung von typischen Anwendungsszenarien erfordert nicht unbedingt die Anwesenheit von Analytikern erlaubt keine Interaktion w hrend der Pr sentation 2008 11 04 W hrend passive Storyboards durch den Analytiker demonstriert werden m ssen sind aktive Storyboards Pr sentationen des Systemverhaltens die von selbst ablaufen Sie laufen wie ein Film ab Dazu kann man tats chlich kontinuierliche Sequenzen wie in einem Film darstellen z B mit Werkzeugen wie Macromedia Flash oder Camtesia oder aber Einzelbilder der Dialoge z B mit einer Pr sentationssoftware wie OpenOffice oder Powerpoint anzeigen Typische Anwendungsszenarien k nnen automatisiert dargestellt werden Weil ein aktives Storyboard von allein abl uft ist die Anwesenheit von Analytikern nicht unbedingt erforderlich Damit k nnen solche Demos an eine Vielzahl von m glichen Benutzern verschickt und deren Meinung eingeholt werden Allerdings erlauben aktive Storyboards keine Interaktion w hrend der Pr sentation was gerade in der fr hen Phase des Interaktions Designs w nschenswert ist Aktive Storyboards eignen sich besonders in einer fortgeschritteneren Phase des Interaktions Designs in der man ein ausgearbeitetes Konzept sehr vielen Benutzern vorstellen m chte I
89. ne dern ngsspezifikation Bug S Softwaresystemattribute Fr N o Indizierte Zugriffe auf Felder m ssen zur Laufzeit gepr ft werden Wie oben beim Abschnitt 3 5 Softwaresystemattribute erw hnt sind neben den funktionalen Anforderungen auch die so genannten nicht funktionalen Anforderungen wie Portierbarkeit etc zu beschreiben Wie wir auch schon oben diskutiert haben sollen alle Anforderungen berpr fbar sein Das hei t die Aussagen zu den nicht funktionalen Eigenschaften m ssen so genau und konkret sein dass man eine Pr fprozedur angeben kann um bei Auslieferung berpr fen zu k nnen ob die Anforderung erf llt wurde Die Forderung Das System muss sicher sein gen gt diesem Anspruch nicht weil nicht klar ist wogegen das System gesichert werden soll Konkreter sollte man also etwa fordern e Alle Netzwerktransaktionen werden mit PGP verschl sselt e Alle Operationen des Administrators werden aufgezeichnet e Alle Benutzer m ssen sich mit einem mindestens acht Zeichen langen Passwort authentifizieren Diese Aussagen sind berpr fbar Interessanterweise stellen wir an dieser Stelle fest dass aus den so genannten nicht funktionalen Eigenschaften durch die Konkretisierung funktionale Eigenschaften werden k nnen Die Trennung in funktionale und nicht funktionale Eigenschaften ist also etwas k nstlich bei allen Eigenschaften die externe Eigenschaften betreffen Externe Eigenschaften sind solche die der Benutzer direkt
90. nforderungen an das System die in der Zukunft eintreffen werden sollen beschrieben werden damit die Softwarel sung so strukturiert werden kann dass diese Anderungen sp ter einfach zu realisieren sind Das Ergebnis der Soll Analyse ist das Lastenheft in dem wir aus Sicht des Kunden beschreiben was die Probleme der bisherigen Situation sind und was die neue Software verbessern soll H ufig wird in der Soll Analyse der Fehler gemacht dass wir in technische Details der L sung abgleiten obwohl es doch zun chst um grobe Konzepte zur Verbesserung geht Wir sto en auch auf das oben bereits angef hrte Problem dass der Kunde nicht notwendigerweise eine klare Vorstellung von der m glichen softwaretechnischen Verbesserung hat beziehungsweise sie nicht vermitteln kann M ngel in der Soll Analyse f hren dazu dass eine falsche L sung spezifiziert wird Am Ende entsteht ein Softwaresystem das nicht die relevanten Probleme beseitigt und damit unn tz ist Um eine gute Soll Analyse machen zu k nnen brauchen wir neben analytischen F higkeiten bei der Problemsuche auch softwaretechnisches Wissen um abzusch tzen ob und mit welchem Aufwand anvisierte softwaretechnische L sungen machbar sind Schritte der Anforderungsanalyse Spezifikation Ziel Anforderungen genau beschreiben Ist Zustand H ufige Fehler Ist Analyse Es Glossar o Anforderungen bleiben vage o Implementierungsdetails statt Lastenheft Anfo
91. ng von Personas o archetypische Benutzerbeschreibungen o typisch f r Zielgruppen o decken deren Anforderungen Bed rfnisse und Ziele ab o stehen im Designprozess stellvertretend f r die realen Benutzer statt der relativ anonymen und pauschalen Gr e Benutzer o k nnen bei Design und beim Usability Test der Benutzerinteraktion verwendet werden o k nnen beim Handbuchschreiben und pr fen sowie Akzeptanztest verwendet werden Astrid Beck FHT Esslingen Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 22 82 Bedeutung von Personas Software Projekt sa o archetypische Benutzerbeschreibungen Anforderungsanalyse gt typisch fr Zielgruppen 1 o decken deren Anforderungen Bed rfnisse und Ziele ab re stehen im Designprozess stellvertretend fiir die realen Benutzer statt par st An a lyse der relativ anonymen und pauschalen Gr e Benutzer 1 o k nnen bei Design und beim Usability Test der Benutzerinteraktion 00 verwendet werden 5 k nnen beim Handbuchschreiben und pr fen sowie Akzeptanztest oO Bedeutung von Personas er N Astrid Beck FHT Esslingen Astrid Beck von der Fachhochschule f r Technik in Esslingen fasst die Bedeutung von Personas in der Softwaretechnik wie folgt zusammen Personas sind archetypische Benutzerbeschreibungen und beschreiben typische Zielgruppen durch deren gemeinsame Eigenschaften Die Gesamtheit der Anforderungen aller Personas deckt
92. ngsspezifikation aufgebaut sind und welche Inhalte sie haben Mit dieser Norm werden wir uns hier noch auseinander setzen Anforderungen Anforderungen sind gleichbedeutend mit Minimalbedingungen hinsichtlich Funktion und Qualitat Wir m ssen also die Funktion und Qualit t definieren Definition Funktion in der Zeit ablaufende Transformation o von Eingabedaten o in Ausgabedaten o unter Verwendung von Ressourcen Rainer Koschke Uni Bremen Software Projekt Software Projekt ee nicrdeminpesnal se E aeran 2008 11 04 Wintersemester 2008 09 66 82 Anforderungen sind gleichbedeutend mit Minimalbedingungen hinsichtlich Qualit t sen also die Funktion und Qualit t definieren Anforderungen legen die Minimalbedingungen hinsichtlich Funktion und Qualit t fest Was aber sind Funktionen und wie definiert man Qualit t f r Software W hrend sich Funktionen ber den Zusammenhang von Eingaben des Benutzers und darauf hin erwartete Ausgaben unter Verwendung einer maximalen Menge von Ressourcen definieren lassen ist der Begriff Softwarequalit t weniger offensichtlich Produktqualitaten nach ISO IEC Standard 9126 2001 Anderbarkeit Zuverlassigkeit Funktionalit t Ordnungsm igkeit Stabilit t Reife Angemessenheit x Fehler toleranz Pr fbarkeit Interoperabilitat Sicherheit Richtigkeit Analysierbarkei
93. nm Erwartungen sonst Unzufriedenheit nicht erf llt Basisfaktoren Begeisternde Faktoren Kunde unzufrieden unbewusste W nsche entt uscht n tzliche angenehme berraschungen steigern Zufriedenheit berproportional Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 10 82 2008 11 04 2008 11 04 Software Projekt Besten Minimalanforderungen Kano Modell Mangel f hrt zu massiver Unzufriedenheit Anforderungsanalyse a rn mehr als Zufriedenheit ist nicht m glich begeistert Leistungsfaktoren L H erau sfo rd erun ge n o bewusst verlangte Sonderausstattung bei Erf llung Kundenzufriedenheit Leistungstaktoren Erf lungsgrad Erwartungen sonst Unzufriedenheit richt ert Begeisternde Faktoren gt unbewusste W nsche n tzliche angenehme berraschungen ent usch steigern Zufriedenheit berproportional Eine gute Anforderungsanalyse ist der Grundstock f r den Erfolg Dazu muss es uns gelingen den Kunden mit unserem Produkt zu begeistern indem wir auf alle seine Anforderungen eingehen und diese sp ter auch umsetzen Der Zusammenhang zwischen dem Erf llungsgrad der Anforderungen und der Begeisterung die wir damit beim Kunden wecken k nnen wird durch das Kano Modell Kano 1984 beschrieben Generell gilt offensichtlich dass wir mit einem h heren Erf llungsgrad der Anforderungen auch eine h here Zufriedenheit erreichen
94. oftware Projekt 3S ER terdenun sanalyse Gianoli 1 g y Wie sollte die GUI verbessert werden rd I Ist Ana lyse NE ren Ji o erfordert Ausdrucksf higkeit der Befragten 0 0 o starker Einfluss des Fragenden wenn pr sent durch Aufschreiben oO Fragetypen Offene Fragen Wegen oO o hoher Auswertungsaufwand N Offene Fragen sind solche bei denen keine Antwort vorgegeben wird Der Befragte beantwortet die Frage mit seinen eigenen Worten Dazu kann er seine eigene Terminologie benutzen Dies erfordert vom Befragten dass er sich selbst ausdr cken kann Da jede Antwort m glich ist kann der Befragte in seiner Formulierung stark durch den anwesenden Fragenden beeinflusst werden Dies gilt umso mehr wenn nicht der Befragte die Antworten aufschreibt sondern der Fragende wie das meist blich ist Dadurch werden die Aussagen vom Fragenden oft gefiltert und aufbereitet statt nur w rtlich wiedergegeben Das Mindeste was man dann tun sollte ist es dem Befragten das Protokoll seiner Antworten nochmals zur Kontrolle vorzulegen um sicher zu stellen dass man seine Aussagen korrekt wieder gegeben hat Da die Antworten nicht vorgegeben sind muss ein Mensch sie durchlesen verstehen und einordnen Damit ist die Auswertung erheblich aufw ndiger als bei geschlossenen Fragen Dem hohen Auswerteaufwand steht als Vorteil gegen ber dass man die Antworten nicht schon beim Entwurf des Fragebogens vorwegsehen muss wie das bei geschlossenen Fragen der Fal
95. oftware Projekt Wintersemester 2008 09 20 82 j Ist Zustand relevante Akt Softwa re P roje kt st Zustan levante Akteure Persona E A nfi or d erun gs ana l ys e in archetypischer Psychologie die Maske oder Erscheinung die man der Welt pr sentiert in der Softwareergonomie erz hlerische Beschreibung charakterischer Eigenschaften und Verhalten eines Benutzers oder Kunden die spezifische 2 Ist Analyse ee Ist Zustand relevante Akteure 2008 11 04 Es ist die Aufgabe des Analysten eine angemessene Menge von Benutzerklassen zu finden die die richtige Balance zwischen abstrakten Rollen und individuellen Benutzern wahrt Zur Beschreibung dieser Benutzerklassen kann man sich der so genannten Personas bedienen Die Persona ist urspr nglich eine im griechischen Theater von den Schauspielern verwendete Maske die die Rolle typisierte und als Schallverst rker benutzt wurde In der archetypischen Psychologie ist es die Maske oder Erscheinung die man der Welt pr sentiert In der Anforderungsanalyse der Softwaretechnik steht eine Persona f r eine Benutzerklasse Sie beschreibt deren gemeinsamen Eigenschaften gibt ihnen aber ein konkretes Bild Sie ist in der Softwareergonomie eine erz hlerische Beschreibung charakterischer Eigenschaften und Verhalten eines Benutzers oder Kunden die spezifische Details nennt statt nur Verallgemeinerungen Neben der Konkretisierung statt Verallgemeinerung geben uns die Personas etw
96. ogrammabl ufe beschreiben Se 3 Abstraktionsebene nicht in einer Darstellung wechseln A nfo rd eru ngss p ezi fi ka tion gt Die Spezifikation nach Aspekten organisieren Ein Mengengeriist bilden o Den Kunden Benutzer einbeziehen Rege n f r A n a yse u n d S p ez ifi ka t i O n o Geeignete Sprachen und Werkzeuge verwenden o Die Spezifikation so fr h wie m glich pr fen und dem Konfigurationsmanagement unterstellen Die Spezifikation intensiv verwenden Um eine gute Anforderungsspezifikation zu erreichen ist es ratsam einige Regeln zu befolgen e Ein Begriffslexikon auch Glossar anlegen und entwickeln Das Begriffslexikon beschreibt alle Begriffe die der Kunde und wir ben tzen die nicht unmittelbar offensichtlich sind Die schriftliche Niederlegung der Bedeutung aller Begriffe zwingt uns und den Kunden zur notwendigen Pr zision in unserem Dialog und hilft damit Missverst ndnisse zu vermeiden Hier sollten auch alle Synonyme aufgez hlt werden Im eigentlichen Inhalt der schriftlichen Anforderungsspezifikation sollten wir aber Synonyme vermeiden und immer nur dasselbe Wort benutzen Die Anforderungsspezifikation ist kein literatisches Werk das durch hohe Sprachvariation gefallen will sondern soll ein pr zises leicht verst ndliches technisches Dokument sein Unterschiedliche Worte f r denselben Sachverhalten verwirr nur e Von der Aufgabe ausgehen nicht von ihrer L sung Die Anforderungsspezifkation beschreibt das
97. olle und worauf ist bei ihrer Spezifikation zu achten Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 80 82 Anforderungsanalyse 1 EN ISO 9241 10 1995 1995 Ergonomische Anforderungen f r B rot tigkeiten mit Bildschirmger ten Teil 10 Grunds tze der Dialoggestaltung Europ ische Norm ISO Standard 1995 2 IEEE Standard 830 1998 1998 IEEE Recommended Practice for Software Requirements Specifications IEEE Standard 830 1998 1998 3 IEEE Std 610 12 1990 1990 IEEE Standard Glossary of Software Engineering Terminology IEEE Standard 610 12 1990 1990 4 ISO 9241 11 1998 1998 Ergonomic requirements for office work with visual display terminals VDTs Part 11 Guidance on usability ISO Standard 1998 5 ISO IEC Standard 25000 2005 ISO IEC 25000 2005 Software Engineering Software product Quality Requirements and Evaluation SQuaRE 2005 umgesetzt in DIN 66272 6 ISO IEC Standard 9126 2001 ISO IEC 9126 1 2001 Software engineering Product quality 2001 umgesetzt in DIN 66272 Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 81 82 Anforderungsanalyse 7 Kano 1984 KANO N Attractive Quality and Must be Quality In Journal of the Japanese Society for Quality Control 4 1984 S 39 48 8 Ludewig 2003 LUDEWIG Jochen Einf hrung in die Softwaretechnik Vorlesungs Skriptum 2003 9 Pressman 2003 PRESSMAN Roger Software Engineer
98. on Benutzern mit unterschiedlichen Aufgaben und Zielen in unserem Systemgef ge Diese Rollen abstrahieren aber von den Eigenschaften konkreter Benutzer So k nnen wir sicherlich ganz unterschiedliche K ufer in unserem Fahrradladen ausmachen die sich in Erfahrungen Vorlieben W nschen Alter Geschlecht und Finanzkraft unterscheiden Alle wollen ein Fahrrad oder ein Fahrradbestandteil kaufen aber ihre Auswahl und ihre Interaktion mit dem K ufer wird wesentlich durch ihre pers nlichen Eigenschaften bestimmt Es reicht also nicht aus nur funktionale Rollen zu identifizieren Da das Softwaresystem von konkreten Menschen benutzt werden wird m ssen wir deren Eigenheiten genau kennen damit wir ein n tzliches Softwaresystem f r sie entwickeln k nnen Andererseits k nnen wir auch nicht jedes m gliche Individium einzeln betrachten da die Anzahl der Benutzer meist sehr hoch ist und uns nicht alle Benutzer bekannt sind Aus konomischen Gr nden m ssen wir also mehrere Individuen mit hnlichen Eigenschaften zu Klassen zusammenfassen Ist Zustand relevante Akteure Persona in archetypischer Psychologie die Maske oder Erscheinung die man der Welt prasentiert in der Softwareergonomie erzahlerische Beschreibung charakterischer Eigenschaften und Verhalten eines Benutzers oder Kunden die spezifische Details nennt statt Verallgemeinerungen ac oa ss WY 078 5 F 5 A N Er oee 5 lt 57 Rainer Koschke Uni Bremen S
99. orderungsanalyse ee Bestandteile Fortsetzung o Struktur A en Bee Erfordernisse ie Bignelsiniu ad she ki id de st na yse aor ane aun erung verkaufter Waren und des o Dokumenten Abh ngigkeiten zwischen den Daten J o Daten passt nur an bestimmte Rahmen Ist Zustand Was o Schwachstellen Bsp In unserem Fahrradladen gibt es beispielsweise 41 Flaschenhalter in f nf verschiedenen Typen von drei verschiedenen Herstellern Ein Flaschenhalter wird beschrieben durch die Attribute Radius der Halterung gemessen in Zentimetern der Abstand der Schrauben gemessen in Zentimetern die Farben in rot gr n gelb blau sowie der Preis im Bereich von 5 bis 25 Euro Die Datentr ger zu den Flaschenhaltern sind die Herstellerkataloge in Papierform als auch als Online Kataloge in HTML Name Hersteller Typ und Preis bilden die Ordnungsstrukturen Von den Flaschenhaltern wird im Durchschnitt alle drei Tage einer verkauft Dies bildet die Verarbeitungsh ufigkeit Die verkauften und im Lager befindlichen Flaschenhalter werden in einer Datenbank des Ladenbesitzers gespeichert Die Flaschenhalter passen nur an bestimmte Rahmen dies h ngt vom Schraubenabstand und dem Radius ab Eine weitere weiche Abh ngigkeit ist die Farbe des Rahmens zu der der Flaschenhalter passen soll Ist Zustand Was Verstandnis von o Struktur Untersuchung auf o Aufgaben a o M ngel o Kommunikation a ERAT o Unvollst ndigkeiten
100. r Ortsbegehung m glich Hypothesen m glich Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 Kombination von geschlossenen und offenen Fragen 39 82 2008 11 04 Wann welche Erhebungsform Software Projekt aaa ngsanalyse weniger strukturiertes Interview stark strukturierter Fragebogen unstrukturiertes vorstrukturiertes Untersuchungsgebiet Untersuchungsgebiet Ist Analyse offene Gespr chsf hrung und o gute Kenntnisse des gr ere Antwortspielr ume ee pers nlicher Kontakt m glich ESEE er I Wa nn wel C h e E fe h e b un gsform o Ortsbegehung m glich Hypothesen m glich Welche Form der Erhebung ob stark oder weniger strukturiertes Vorgehen nun angemessen ist h ngt im Wesentlichen davon ab wie gut wir unser Untersuchungsgebiet bereits durchdrungen haben In einer fr hen Phase in der wir uns noch wenig auskennen und m gliche Antworten nicht vorweg sehen k nnen werden wir eher ein weniger strukturiertes Interview durchf hren Das Gespr ch kann offen gef hrt werden und der Befragte hat einen gr eren Spielraum bei Antworten Der Fragende kann spontaner auf die Situation reagieren Der pers nliche Kontakt und die Ortsbegehung werden uns weitere Einblicke gew hren Ist unser Untersuchungsgebiet bereits gut vorstrukturiert dann kommt auch ein strukturierteres Vorgehen in Frage Da wir bereits ber gute Kenntnisse des Untersuchungsgebiets verf gen sind wir
101. r Erhebung und Analyse von Anforderungen Soll Analyse Prototyping rs Funkti lit t di it Stakeholdern diskutiert 0 a se at ied die gezeigte Funktionalitat Ty p en von P rototyp en n B ez ug a uf Le be n sd auer o ist als Komponente f r das Endprodukt ungeeignet weil billig erstellt N Der Wegwerfprototyp hat eine sehr begrenzte Lebensdauer Er wird in keinem Fall zum Endprodukt werden Sein Ziel ist es einen Aspekt sei es Funktionalit t oder Interaktion exemplarisch zu untersuchen oder zu demonstrieren Dazu wird der relevante Aspekt mit m glichst billigen Mitteln realisiert nicht notwendigerweise immer dadurch dass tats chlich Code geschrieben wird siehe unten Alle anderen Aspekte sind nicht realisiert Weil der Prototyp unvollst ndig ist und mit billigen Mitteln erstellt wird ist er fur das Endprodukt ungeeignet daher sein Name Hat er den Aspekt demonstriert wird er weggeworfen Typen von Prototypen in Bezug auf Lebensdauer Evolutionarer Prototyp o dient zur schnellen Bereitstellung eines funktionsf higen Systems im Rahmen von evolutionaren Prozessmodellen zur Softwareentwicklung o wird in weiteren Ausbaustufen zum endg ltigen Produkt weiterentwickelt Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 47 82 Typen von Prototypen in Bezug auf Lebensdauer Software Projekt ala ngsanalyse Evolution rer Prototyp dient zur schnellen Bereitstellung eines funktionsf
102. r Fragende hat einen m glichen Einfluss auf die Antworten Ob uns jemand sympathisch oder unsympathisch i beeinflusst wie kooperativ wir in einem Interview sind Fatal ware es wenn der Befragte vor dem Fragenden etwas zu bef rchten h tte Bsp So w re der Ladenbesitzer eher ungeeignet Fragen zum Thema Auslastung und Schw chen d Verk ufer zu stellen wenn sie zu bef rchten haben dass ihnen aus ehrlichen Antworten negative Konsequenzen erwachsen k nnten e Was sind die m glichen Gr nde f r die Antwort der Befragten Der Befragte k nnte uns einen Gefallen tun wollen od will uns sabotieren Er k nnte bewusst oder unbewusst falsche Antworten liefern weil er hinter den Fragen ein bestimmtes Ziel vermutet mit dem er nicht einverstanden ist Fragetypen Geschlossene Fragen Geschlossene Fragen Welche Qualit t hat die GUI Bitte ankreuzen L sehr gut Ll gut C schlecht C wei nicht o Antwortalternativen vorgegeben o auch Mehrfachantworten Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 36 82 2008 11 04 Fragetypen Geschlossene Fragen Software Projekt Anforderungsanalyse Geschlossene Fragen la EE hat die GUI Bitte ankreuzen Ist Analyse 0 sheet O wei nicht I Fragetypen Geschlossene Fragen en Fragen k nnen in drei unterschiedlichen Formen verfasst sein geschlossene offene oder hybride Fragen Sie unterscheiden sich durch die Form der Antworten die auf sie m glich sin
103. r der technischen Machbarkeit sondern vielmehr der konzeptionellen Angemessenheit und Schl ssigkeit Wir untersuchen damit ob der Benutzer sp ter mit unserem System effizient und effektiv interagieren kann Dem Oberfl chenprototypen kommt unter den Prototypen eine Sonderstellung zu weil es die Oberfl che ist die der Benutzer sp ter sehen und bedienen wird Alle anderen Schichten sind f r ihn unsichtbar Wenn wir die von uns einzusetzenden Implementierungsechnologien bereits sicher beherrschen k nnen wir auf solche technische Prototypen tieferer Schichten verzichten Weil wir aber in der Anforderungsspezifikation auch die Benutzungsschnittstelle beschreiben m ssen und die Qualit t einer Software aus Benutzersicht steht und f llt mit ihrer Benutzbarkeit sind Oberfl chenprototypen f r die Anforderungsanalyse unerl sslich Aus diesem Grunde genie en Oberfl chenprototypen hier unser Hauptaugenmerk Wir unterscheiden dabei die folgenden Typen e passives Storyboard Papierprototyp e aktives Storyboard animierter Prototyp e interaktives Storyboard ausf hrbarer Prototyp Alle Typen von Storyboards beschreiben die zuk nftige Interaktion mit dem System als eine Art Drehbuch daher ihr Name Sie unterscheiden sich jedoch im Grad ihrer Interaktivit t Das interaktive Storyboard bietet dabei die h chste Interaktivit t Mit dem Grad der Interaktivit t steigen aber auch die Kosten f r die Entwicklung des Storyboards Wir werden im Fo
104. raulichkeit zu und vergewissert sich ber das Einverst ndnis des Befragten Er weist darauf hin dass die Arbeit betrachtet werden soll und nicht die Person Man kann technische Hilfen f r das Interview mitbringen wie z B ein Audio oder Videoaufnahmeger t Wenn das der Fal ist holt man sich sp testens jetzt noch das Einverst ndnis des Beobachteten ein 2 Im bergang zur Erhebung im Kontext 1 min bespricht man die Regeln Rollen und die Beziehung zwischen Beobachter und Beobachtetem Die Rolle des Beobachters ist es zu beobachten und Fragen zu stellen Die Rolle des Beobachteten ist es sich m glichst wie gew hnlich zu verhalten Eine Grundregel lautet dass der Beobachtete Fragen auch abwehren darf 3 Der Hauptteil ist die Erhebung im Kontext die zwei Stunden m glichst nicht berschreiten sollte weil sp testens da die Konzentration auf beiden Seiten nachgelassen hat In der Erhebung beobachtet man und fragt nach Man macht sich Notizen l uft mit macht sich aber m glichst unsichtbar um das beobachtete Geschehen so wenig wie m glich z beeinflussen Pausen k nnen nach Wunsch gemacht werden 4 In der Zusammenfassung 15 min erl utert man was man beobachtet hat und l sst den Beobachteten korrigieren u erg nzen Der Beobachtete erl utert sein Tun und seine Rolle und weist auf Wichtiges hin Wegweiser Soll Analyse Wie k nnen wir dem Benutzer fr hzeitig ein konkretes Bild vermitteln wie wir das Problem zu l sen g
105. rderungen gt Soll Analyse Ss Folgen von Mangeln Anforderungs spezifikation g Erforderlich Kommunikationsfahigkeit Spezifikation der Anforderungen o Vertragsstreitigkeiten am Projektende Abnahme durch Kunden dbgenommene Anforderungs spezifikation Pflichtenheft Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 14 82 Schritte der Anforderungsanalyse Spezifikation Software Projekt i ae e een Anforderungsanalyse en e L ie i Soa An Aktivit ten FAnosennar Yeragsstrtigleten am Pretend amp P en 7 SER A Erforderlich Kommunikationsf higkeit Oo Schritte der Anforderungsanalyse Spezifikation een oO G SE nen strona Pflichtenheft Die Ist Analyse untersucht die Anwendungsdom ne f r die eine softwaretechnische L sung angestrebt wird Diese Analyse ist rein deskriptiv Die Soll Analyse untersucht die Schw chen des Ist Zustands und formuliert daraus Anforderungen an eine softwaretechnische L sung die diese Schw chen ausgleichen sollen Die Soll Analyse muss Priorit ten setzen nicht alle Anforderungen sind gleich wichtig und m gliche Konflikte aufl sen Anforderungen k nnen sich widersprechen z B Performanz versus Sicherheit Bei der Soll Analyse m ssen eventuell auch Folgen von softwaretechnischen L sungen abgesch tzt werden Diese Absch tzung k nnte dazu f hren eine andere softwa
106. rdwareschnittstellen 2 1 4 Softwareschnittstellen ee len 1 2 1 5 Kommunikationsschnittstellen Netzwerkprotokolle etc Inhalt der Anforderungsspezifikation nach IEEE Bele ige 2 1 7 Betriebsoperationen Operationsmodi Dauer interaktiver und S d d 830 1 998 nichtinteraktiver Operationen unterst tzende tandar EE E Scheie Wiederherstellungsoperationen 2 1 8 M glichkeiten der lokalen Anpassung Softwareschnittstellen Softwareschnittstellen sind Schnittstellen zu Software die Bestandteil des System werden soll Dazu geh ren Betriebssysteme h here Dienste wie z B Datenbanken sowie wiederverwendbare Bibliotheken die eingebunden werde sollen Wir erinnern uns dass Implementierungsdetails eigentlich nicht in die Anforderungsspezifikation geh ren Insofern d rfi wir nur solche Softwareschnittstellen hier aufz hlen die tats chlich von Interesse f r den Kunden sind z B dann wen er diese Software bereits einsetzt und in diesem Kontext wieder verwenden m chte bzw wenn sich aus ihrer Verwendu weitere lizenzrechtliche Aspekte f r den Kunden ergeben w rden Bsp Der Ladenverk ufer hat eine MySQL Datenbank der Version 4 1 bereits im Einsatz und besteht darauf dass unsere Software alle persistenten Daten darin speichern soll Kommunikationsschnittstellen Sofern das System mit anderen Systemen ber ein Netzwerk kommuniziert beschreiben wir hierf r die Kommunikationsschnittstelle sowie Netzwerkprotokolle etc Auch hier gilt wieder
107. retechnische L sung zu finden beziehungsweise im Extremfall eine softwaretechnische L sung ganz auszuschlie en Mit L sung ist hier nicht die Implementierung gemeint sondern lediglich der Anforderungskatalog an die Implementierung Es geht hier noch nicht darum sich zu berlegen wie die Anforderungen implementiert werden Das Lastenheft beschreibt die W nsche des Kunden aus dessen Sicht Es ist h ufig noch unscharf oder unstimmig Erst die Anforderungsspezifikation auch Pflichtenheft beschreibt genau was zu implementieren ist Obwohl die Anforderungsspezifikation nur beschreiben soll was implementiert und nicht wie implementiert werden soll sind berlegungen zu der generellen Machbarkeit notwendig Eine Anforderungsspezifikation muss auch realisierbar sein Dennoch sollten diese berlegungen lediglich dazu f hren m glicherweise die Anforderungen abzu ndern M gliche Wege die Anforderungen zu implementieren geh ren in ein Entwurfsdokument und nicht in die Anforderungsspezifikation Die Anforderungsspezifikation stellt den Vertrag zwischen Kunde und Entwickler dar und muss entsprechend genau gepr ft werden Meist geschieht dies durch ein Review mit dem Kunden Schritte der Anforderungsanalyse Spezifikation Software Projekt ae Ziel Anforderungen genau beschreiben Be inne Anforderungsanalyse M m L Dex L a Re m A ktivit te n Ants Veragsrlig
108. rf r Metriken angegeben Metriken sind ein numerisches Ma das beschreibt inwieweit eine bestimmte Qualit t vorliegt Durch Einsatz der Metriken wird die Qualit t messbar Uber die wesentlichen Qualit tsattribute und sinnvolle Metriken zu ihrer Messung herrscht jedoch nicht immer Konsens Auch die Kategorisierung der Qualit tsattribute ist nicht immer gleich Ludewig 2003 beispielsweise unterscheidet auf oberster Ebene nach inneren und u eren Qualit ten u ere Qualit ten sind solche die f r den Benutzer direkt sp rbar sind Innere Qualit ten richten sich prim r an den Entwickler sind jedoch zumindest indirekt auch f r den Benutzer sp rbar durch den Aufwand und die Dauer f r Anderungen an der Software um sie an neue und ge nderte Anforderungen anzupassen Die folgende Grafik zeigt die Aufteilung nach Ludewig 2003 Prifbarkeit lt Wartbarkeit Aner Si Portabilit t lt Integrierbarkeit lt innere Erstellbarkeit lt Produktqualit t Wiederverwendbarkeit lt Zuverl ssigkeit N tzlichkeit u ere tzlichkeit lt Robustheit lt oe Bedienbarkeit lt Sicherheit lt Bedeutung einer Anforderungsspezifikation Zweck Abstimmung mit Die Anforderungen bleiben ungekl rt W nsche des Kunden Kunden bleiben unber cksichtigt Entwurf Entwerfer fehlt Vorgabe darum mehr Kommunikati Benutzerhandbuch Basis f r das Handbuch fehlt es wird darum ph no Te
109. rheiten im Ablauf o Struktur o Aufgaben o Kommunikation o Was wird gemacht Dokumenten Kundenberatung o Daten o Wer oder was f hrt Operation aus o Schwachstellen Kunde Verk ufer o Wann und wie haufig werktags 50 Mal Tag samstags 80 Mal Tag Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 23 82 Ist Zustand Was Verstandnis von Bestandteile Forts o Struktur o Zu welchem Zweck 2 UBER Kauf eines Artikels AEON Nach welchen Regeln wirken Operationen Dokumenten zusammen o Daten Beratung vor Kauf Operation aber optional o Schwachstellen o Was benutzt produziert Operation Zeit und Wissen des Verk ufers Auswahl des K ufers J Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 24 82 Software Projekt as S e mineesnal se E S sen Was N Nachdem wir uns durch die Personas einen berblick verschafft haben welche Benutzerklassen zu beachten sind untersuchen wir als n chstes die Aufgaben der einzelnen Akteure die im untersuchten System vorkommen Die Aufgaben k nnen wir als Operationen der Akteure auffassen Hier interessiert uns was eine Operation macht wer sie ausf hrt wann und wie h ufig die Operation ausgef hrt wird zu welchem Zweck sie durchgef hrt wird welche Regeln der Ausf hrung der Operation selbst und welche dem Zusammenwirken der Operationen zu Grunde liegen sowie was eine Operation benutzt und prod
110. rkannt zu werden N Folgt f r den Informatiker der eine Anforderungsanalyse durchf hrt nun daraus dass er besser eine Ausbildung als Psychoanalytiker absolvieren sollte Wenngleich das sicherlich helfen k nnte so ist es f r unsere Zwecke meist ausreichend sich ber diese Formen des Wissens im Klaren zu sein und passende Techniken anzuwenden um an m glichst viel Wissen und Anforderungen zu kommen Mit reinen Fragetechniken wird man zum berwiegenden Teil allein das bewusste Wissen erschlieBen k nnen Mit Beobachtungen und Nachfragen kann man noch den Bereich des unbewussten Wissens erfassen Bei der Einsch tzung der Aussagen eines Benutzers sollte man sich aber auch Gedanken machen warum er eine Antwort in einer bestimmten Weise geben k nnte oder warum er sich auf eine bestimme Art und Weise verh lt Es k nnten zum Beispiel Angste vor der Umstellung durch die softwaretechnische L sung sein die einen Menschen unbewusst umtreiben seien es berechtigte Angste um den m glichen Verlust des Arbeitsplatzes oder einfach nur die allgemeine Angst durch die Neuerungen berfordert zu werden Anforderungsanalyse Basisfaktoren o Minimalanforderungen Kano Modell Mangel f hrt zu massiver Unzufriedenheit Kunde sehr zufrieden mehr als Zufriedenheit ist nicht m glich begeistert Begeisternde Faktoren Leistungsfaktoren bewusst verlangte Sonderausstattung Kesiungsiakipian bei Erf llung Kundenzufriedenheit
111. rst zu einer gemeinsam Sprache und einem gemeinsamen Verst ndnis finden m ssen e Es gibt meist nicht den Kunden oder Benutzer sondern sehr viele mit recht unterschiedlichen Anforderungen die sich nicht selten widersprechen Bei der Anforderungsanalyse m ssen also Konflikte aufgedeckt und Kompromisse geschlossen werden e Die Anforderungen werden nicht selten durch politische Entscheidungen beeinflusst Das aus organisatorischer und technischer Sicht bestm gliche Soll Konzept kann dann immer noch aus rein politischen Gr nden scheitern Beispielsweise sieht der Abteilungsleiter durch eine Anderung im Arbeitsfluss dank softwaretechnischer Unterst tzung pl tzlich seinen Einfluss gef hrdet und boykottiert die angestrebte L sung e Die Welt ist einem st ndigen Wandel unterworfen Weil sich die Welt ndert ndern sich notwendigerweise auch die Anforderungen an die Software die einen Arbeitsfluss dieser Welt automatisiert Das geschieht sicherlich in der Zeit nach Auslieferung der Software in der so genannten Wartungsphase d h w hrend ihres Einsatzes aber nicht selten au schon w hrend der Entwicklung Mit der Anforderungsanalyse ist man also selten fertig Man sollte deshalb idealerwei wahrscheinliche zuk nftige Anderungen vorwegsehen und schon in der initialen Entwicklung ber cksichtigen Bewusstseinsebenen bewusstes Wissen 20 30 o Wissen ber das man sich im Klaren ist oder das in seiner vollen Bedeutung klar
112. rungsanalyse A 1 Bestandteile m LL a min Welche Vorrichtungen und Gelegenheiten zur o Aufgaben K kation gibt es im Rahi Ich Ist Analyse A un Roman tm an wer men gt Laden Telefon Daten o Wie l uft Kommunikation ab oO Ist Zustand Was oO N Wenn wir die Kommunikation untersuchen interessieren wir uns f r die Vorrichtungen f r die Kommunikation die Gelegenheit zu der die Kommunikation stattfindet sowie den Ablauf der Kommunikation Bsp Beim Verkaufsgespr ch wie oben dargestellt verwenden die Akteure im Laden schlicht die menschliche Stimme wenn das Gespr ch im Laden stattfindet Alternativ kann der Kunde sich aber auch ber das Telefon vom Verk ufer beraten lassen und erst sp ter den Laden betreten um den passenden Artikel zu besorgen Die Kommunikation findet w hrend der Laden ffnungszeiten statt und wird vom Kunden initiiert Wenn der Verk ufer frei ist spricht er jedoch auch Kunden an wenn er den Eindruck hat dass sie seine Hilfe ben tigen Ist Zustand Was Verst ndnis von volker Verk ufer o Struktur klara Kundin o Aufgaben gib artikel o Kommunikation gib detail a HB ei cea ee gt Dokumenten Detail o Daten eat Auswahl o Schwachstellen gib geld Geld Artikel Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 26 82 2008 11 04 Ist Zustand Was Software Projekt
113. rungsspezifikation wird das Benutzerhandbuch geschrieben Ohne Anforderungsspezifikation fehlt die Basis f r das Handbuch Dies f hrt dazu dass es ph nomenologisch erfasst wird d der Autor des Benutzerhandbuchs schreibt auf was er beim lauff higen System beobachtet Das ist oft unzureichend weil er nicht alle M glichkeiten kennt und damit beobachten kann Testvorbereitung Ohne pr zise und vollst ndige Anforderungen ist ein systematischer Test unm glich Vertrag und Abnahme In der Regel bildet die Anforderungsspezifikation die vertragliche Grundlage f r den Auftrag A Ende des Projekts wird bei der Abnahme berpr ft ob die Anforderungen erf llt sind Damit wird die berpr fung dq Korrektheit subjektiv und Streit ist unvermeidbar Das f hrt zur Unzufriedenheit des Kunden und h ufig zu Vertragsstreitigkeiten Da aber die Anforderungen nicht vollst ndig und pr zise beschrieben sind ist ein Streit um dag Recht m hsam Bedeutung einer Anforderungsspezifikation Software Projekt Zweck Abstimmung mit Die Anforder Kunden K Anforderungsanalyse Entwurf Anforderungsspezifikation Benutzerhandbuch Bast fir d Testvorbereitung syst Bedeutung einer Anforderungsspezifikation 2008 11 04 sp tere Reimple Kompatibilit t setzt voraus dass man wei womit tierung die neue Software kompatibel sein soll e Wiederverwendung Ohne eine Beschreibung was die Software leistet kann man nicht ohne Weiteres be
114. s zu erheben und berpr fen technische M glichkeiten zu berpr fen und demonstrieren oder fr hzeitig m gliche L sungsans tze zu pr sentieren letztere Prototypen werden auch als Demonstratoren bezeichnet Die Idee der Prototypen in der Softwaretechnik ist dieselbe wie bei anderen Ingenieursdisziplinen die rasche und billige Entwicklung eines prototypischen Systems zur Erprobung Unter dem Begriff Prototypen versammeln sich in der Softwaretechnik aber sehr unterschiedliche Formen Man kann sie unterscheiden anhand zweier unterschiedlicher Merkmale zum einen anhand der Lebensdauer Wegwerfprototyp evolution rer Prototyp zum anderen anhand des Zwecks berpr fung der technischen Machbarkeit oder Demonstration der Funktionalit t oder Interaktion Wir werden sie im Folgenden n her kennen lernen Typen von Prototypen in Bezug auf Lebensdauer Wegwerf Prototyp Q Q beschreibt ein Softwaresystem exemplarisch dient zur Erhebung und Analyse von Anforderungen demonstriert die Funktionalit t die mit Stakeholdern diskutiert werden soll implementiert nicht notwendigerweise die gezeigte Funktionalitat z B GUI Prototyp ist als Komponente f r das Endprodukt ungeeignet weil billig erstellt Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 46 82 Typen von Prototypen in Bezug auf Lebensdauer Software Projekt 5 EN sa Wegwerf Prototyp Anforderungsanalyse Se ate ans o dient zu
115. s kann dennoch sinnvoll sein Kategorien zu kombinieren was kein Widerspruch zur Uniformit t sein muss Dem Ziel der Uniformit t gen gend k nnte man z B auf erster Ebene nach Benutzerklassen ordnen und auf zweiter Ebene nach Anwendungsf llen Wiederholungsfragen o Was ist an der Erhebung der Anforderungen so schwierig o Erlautern Sie das Kano Modell Was folgt daraus f r die Anforderungsspezifikation o Wozu dient die Anforderungsspezifikation und welche Folgen haben ihre Mangel o Was sind die Schritte der Anforderungsspezifikation o Was sind Personas und welches Ziel wird mit ihnen verfolgt o In welchen Phasen des Entwicklungsprozesses k nnen Personas verwendet werden o Was ist das Ziel der Ist Analyse und aus welchen Schritten besteht sie o Erlautern Sie Techniken zur Ist Analyse Bewerten Sie sie o Insbesondere Auf welchen Prinzipien basiert das Interview im Kontext und wie wird es durchgef hrt Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 79 82 Wiederholungsfragen II o Welche Arten des Prototypings gibt es und wozu dienen sie o Wegwerf technischer und evolution rer Prototyp o horizontaler versus vertikaler Prototyp o passive aktive interaktive Storyboards o Welche Eigenschaften der Anforderungsspezifikation streben wir an o Welche Bestandteile hat eine Anforderungsspezifikation o Welche Systemattribute spielen in der Anforderungsspezifikation eine R
116. schnittstellen Ber z 2 1 2 Benutzungsschnittstelle logische Charakteristika z B Monitorformat Seiten oder Fensterl it Inhalt Berichte der Mi a Anforderungsspezifikation Varin wn Fan owe er de ia 2 1 3 Hardwareschnittstellen 4 z 2 1 4 Softwareschnittstellen 2 1 5 Ke ikat hi lle Ne ki koll Inhalt der Anforderungsspezifikation nach IEEE Fe ee aera replete A 2 1 7 Betriebsoperationen Operationsmodi Dauer interaktiver und htinterakti Ol ti unterst tzend Standard 830 1998 en Wiederherstellungsoperationen 2 1 8 M glichkeiten der lokalen Anpassung 2 1 2 Benutzungsschnittstelle 2 1 3 Software Projekt 830 1998 _ Anforderungsanalyse 21 Produiperpltie 2 1 4 2 1 5 2 1 6 Be ee 1 Seiten oder Fensterlayout Inhalt von Berichten oder Meniis Anforderungsspezifikation an Inhalt der Anforderungsspezifikation nach IEEE Standard Eine besondere Schnittstelle ist die die dem Benutzer angeboten wird Die detaillierte Beschreibung dieser Schnittstel erfolgt in Abschnitt 3 1 1 Hier werden lediglich die logischen Charakteristika der Schnittstelle erl utert z B das Monitorformat das Seiten oder Fensterlayout den Inhalt von Berichten oder Men s oder die Verf gbarkeit von Funktionstasten Au erdem werden alle relevanten Regeln f r das Design der Schnittstelle genannt wie z B die allgemeinen in aller Regel ohnehin verbindlichen Richtlinien der Norm EN ISO 9241 10 1995 1995 f r die Gebrauchstauglichkeit von Software Die
117. schr nkungen 2 5 Annahmen und Abh ngigkeiten 3 Detaillierte Beschreibung Wir werden diese Abschnitte nun im Einzelnen im Detail kennen lernen Ein Beispiel f r eine ausf hrliche Anforderungsspezifikation finden Sie unter lt lt hier erg nzen gute Spec vom ersten SWP zu PDA hinzuf gen gt gt Inhalt der Anforderungsspezifikation nach IEEE Standard 830 1998 1 Einf hrung 1 1 Zweck o Zweck der Spezifikation o adressierte Leser 1 2 Rahmen o herzustellende Software mit Name o was die Software tut und nicht tut o Anwendung der Software mit Nutzen und Zielen 1 3 Definitionen Akronyme und Abk rzungen 1 4 Referenzen 1 5 bersicht ber das Dokument Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 72 82 Software Projekt nn S E ngsanalyse ee E neal anion S inhalt der Anforderungsspezifikation nach IEEE oe N Standard 830 1998 ee Das Ziel der Einf hrung ist es den Kontext und Rahmen der Anforderungsspezifikation abzustecken Sie hat folgende Struktur 1 1 1 2 1 3 1 4 1 5 Zweck Dieser Abschnitt beschreibt den Zweck der Spezifikation und an welche Leser sie sich wendet Meist geschieht dies durch eine kurze Beschreibung des Projektkontextes und der Ziele des Projekts Dann folgt der Hinweis dass in diesel Dokument die Anforderungen dieses System spezifiziert werden sollen und oft die Aussage dass dieses Dokument die vertragliche Grundlage bildet F r die adre
118. se Was ist das Ziel und der Gegenstand der Ist Analyse Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 15 82 Soziotechnisches System Definition Soziotechnisches System organisierte Menge von Menschen und Technologien die in einer bestimmten Weise strukturiert sind um eine Aufgabe zu erf llen Umgebung Technisches Aufgaben gt Technologien Eingabe Ausgabe a S ETEA e Menschen gt Rolle Struktur Soziales Emery Thorsrud amp Trist 1964 Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 16 82 Ist Zustand Was Verstandnis von o Struktur Aufgaben o Kommunikation Dokumenten Daten Schwachstellen aus allen relevanten Blickwinkeln Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 17 82 Ist Zustand Was Software Projekt a Verst ndnis von lt y o Struktur L Anforderu ngsanalyse en rd o Dokumenten LL Ist Analyse ee CO D A an Ist Zustand Was ean S l N In diesem Abschnitt lernen wir Analysetechniken f r die Ist Analyse kennen Zun chst untersuchen wir was wir bei der Ist Analyse berhaupt analysieren sollen Durch die Ist Analyse streben wir ein Verst ndnis folgender Aspekte des Ist Zustands aus allen relevanten Blickwinkeln an e Struktur das organisatorische Gef
119. ssierten Leser werden mindestens die konkreten Namen der Kunden und Vertreter m glicher Benutzer genannt Rahmen Hier geben wir der zu erstellenden Software einen Namen und beschreiben ganz kurz was die herzustellende Software leisten soll und auch was wir explizit nicht von ihr erwarten um gleich zu Anfang falschen Vorstellungen Einhalt zu gebieten Es folgt die Beschreibung der Anwendung der Software mit ihrem Nutzen und ihren Zielen Dieser Abschnit soll nur einen ersten Uberblick vermitteln was die Software genau machen soll folgt in den zwei nachfolgenden Kapitel Bsp Der PDA basierte Einkaufsassistent den wir als laufendes Beispiel verwenden soll den Namen PDAss tragen Definitionen Akronyme und Abk rzungen Hier ist er der Ort an dem Begriffe definiert und Akronyme und Abk rzungen eingef hrt werden k nnen die im weiteren Dokument benutzt werden Damit wird der Standard unserer oben ge u erten Forderung gerecht ein Begriffslexikon Glossar zum Ausschluss von Missverst ndnissen zu verwenden Bsp Wir w rden hier beispielsweise das Akronym PDA f r Personal Digital Assistant erl utern Referenzen Hier k nnen weitere Dokumente aufgef hrt werden die f r das Verst ndnis der Anforderungsspezifikation hilfreich sin und im folgenden Text referenziert werden Dazu sollte auch z B der IEEE Standard f r diese Anforderungsspezifikati geh ren Bsp Hier k nnten wir die Fahrradherstellerkataloge und weitere Dokumente di
120. stvorbereitung systematischer Test ist unm glich Abnahme Korrektheit ist subjektiv Streit ist unvermeidbar Wiederverwendung nicht spezifizierte Systeme sind kaum durchschaubar sp tere Reimple Kompatibilit t setzt voraus dass man wei womit mentierung die neue Software kompatibel sein soll Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 68 82 Bedeutung einer Anforderungsspezifikation Softwa re P ro e kt Zweck Folge von P s Abstimmung mit Die Anforderungen bleiben ungekl rt W nsche des oO S A nford eru ngsa na l yse Kunden Kunden bleiben unber cksichtigt I Be Entwurf Sa a es N Kommunikati re aie 4 on eigene Vorstellung als Vorgabe re A nfo rd e ru ngss p eZ I fi ka t l O n Benutzerhandbuch a fehlt es wird darum ph no amp gt ae 3 Testvorbereitung systematischer Test ist unm glich oO Bedeutun g einer Anforderun gsspezi fikation Mirana Ee E a O Wiederverwendung nicht spezifizierte Systeme sind kaum durchschaubar N darum schwer wiederzuverwenden Die Anforderungsspezifikation ist von zentraler Bedeutung f r die Entwicklung Sie wird von vielen Personen die am Entwicklungsprozess beteiligt sind als Grundlage ihrer Arbeit verwendet Eine minderwertige Anforderungsspezifikation f hrt zwangsl ufig zu M ngeln aller davon abh ngiger weiterer Arbeitsprodukte Da alle weiteren Arbeitspakete von der Anforderungsspezifikation abh ngig sind haben solche M ngel also eine nachhaltige Auswirkung
121. t nalysierbarkeit 5 derher Modifizierbarkeit stellbarkeit Software qualitat Austauschbarkeit Verst ndlichkeit 4 Verbrauchs Installierbarkeit verhalten Erlernbarkeit Konformit t Zeitverhalten Bedienbarkeit Anpassbarkeit oe Ubertragbarkeit Benutzbarkeit Effizienz Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 67 82 Produktqualitaten nach ISO IEC Standard 9126 2001 Software Projekt Anderbarkeit Zuverl ssigkeit Funktional hatte nena E E pce anion L Produktqualitaiten nach ISO IEC Standard 9126 2001 fF Konfe 2008 11 04 Fennpashurke Bedinbaket Der Begriff Softwarequalitat ist sehr vielschichtig Im Allgemeinen bedeutet Qualitat lediglich zu welchem Grad ein Gegenstand bestimmte Attribute aufweist Wahrend die Qualitat einer Schraube recht einfach durch die Attribute Festigkeit Gewicht Material Preis etc festgelegt werden kann sind die wesentlichen Attribute bei Software nicht ohne Weiteres offensichtlich Im internationalen Standard ISO IEC Standard 9126 2001 werden typische Softwarequalitaten in Form allgemeiner Kategorien und Subkategorien wie folgt aufgef hrt Funktionalit t Vorhandensein von Funktionen mit festgelegten Eigenschaften die die definierten Anforderungen erf llen e Richtigkeit Liefern der richtigen oder vereinbarten Ergebnisse oder W
122. t in dieser Phase ein Glossar Begriffslexikon in dem wir die Begriffe aus der Anwendungsdom ne definieren die der Kunde verwendet Das Begriffslexikon ist notwendig um Unklarheiten und Missverst ndnisse auszuschlie en In der Regel sind Softwareentwickler mit den Begriffen der Anwendungsdom ne nicht vertraut genug oder haben eine etwas falsche Vorstellung Besonders problematisch sind die F lle in denen wir meinen zu wissen was vermeintlich gemeint ist aber leider daneben liegen ohne es zu merken Dieses Glossar wird vom Kunden gelesen und verifiziert Es wird ber die Projektdauer gepflegt und angepasst Ein h ufiger Fehler bei der Ist Analyse ist es dass wir uns nicht bewusst werden dass der Kunde prim r keine Ver nderung sondern eine Verbesserung anstrebt Das bedeutet dass der Kunde mit vielen Dingen so wie sie sind bereits zufrieden ist und die auch weiterhin so bleiben sollen Der Kunde beschreibt aber selten was sich nicht ndern soll weil es gut genug ist Er konzentriert sich vielmehr darauf was sich ndern soll Nichtsdestotrotz m ssen wir auch die Anforderungen kennen die bernommen werden sollen Wenn es darum geht ein existierendes Softwaresystem abzul sen bietet sich uns eine gro e Chance vom existierenden System zu lernen Viele Informatiker machen jedoch den Fehler das existierende Systeme allerh chstens oberfl chlich zu untersuchen Dabei k nnten wir den Kunden gezielt danach fragen was wir vom existieren
123. ten haben wir ein unmittelbareres Bild Andererseits sind wir m glicherweise unge bt und ausgebildete und erfahrene dritte Beobachter sehen mehr als wir Schlie lich m ssen wir uns zwischen einer Feld oder Laborbeobachtung entscheiden Im Labor k nnen wir viel st rker beeinflussende Faktoren kontrollieren um so spezielle Situationen und den Einfluss der Faktoren durch deren Variation genauer zu studieren So k nnten wir z B eine stressige Ladensituation im Labor nachbilden indem wir sehr viele Menschen unzufriedene Kunden schauspielern lassen Das nat rlichere Bild ergibt sich aber durch die Feldbeobachtung Hier lassen sich aber keine Situationen nachstellen Auch hier gilt wieder dass man F r und Wider anhand der konkreten Ausgangslage und des Ziels abw gen muss Eine Feldbeobachtung ist jedoch immer vern nftig Im Labor kann man dann bestimmte Situationen nachstellen und n her untersuchen Befragung Fragen zu Fragen o Wird die Frage verstanden o Bezugsrahmen der Befragten o Informationsstand der Befragten o Art der Frage Anordnung der Fragen Erhebungssituation Interviewereinfluss o Gr nde f r die Antwort der Befragten Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 35 82 Software Projekt SEE Anforderungsanalyse Be eee Analyse ee 2003 11 04 Die Antwort auf eine Frage h ngt nicht nur vom Inhalt der Frage selbst sondern auch vom Kontext und von der Art und Weise a
124. tionen die f r den Betrieb der Software notwendig oder hilfreich sind Dazu geh ren beispielsweise unterst tzende Datenverarbeitungsfunktionen wie z B Konsistenzpr fungen oder allgemeine Statistiken ber die Datenvolumen sow Sicherungs und Wiederherstellungsoperationen Au erdem unterst tzen viele Systeme verschiedene Operationsmodi denen unterschiedliche Produktfunktionen und Betriebsoperationen verf gbar beziehungsweise nicht verf gbar sind Beispielsweise bietet eine Bank Software einen Wartungsmodus w hrend dessen Kunden keine Transaktionen veranlassen k nnen weil Jahresabschl sse berechnet werden In diesem Abschnitt werden diese allgemeinen Betriebsoperationen die relevanten Operationsmodi und die Dauer und H ufigkeit interaktiver und nichtinteraktiver Operationen aufgef hrt 2 1 8 M glichkeiten der lokalen Anpassung Systeme bieten h ufig die M glichkeit dass Benutzer lokale Anpassungen vornehmen k nnen Diese werden hier beschrieben Bsp Der Ladenbesitzer soll beispielsweise einstellen k nnen wie viele Benutzer maximal gleichzeitig auf den Ladenrechner zugreifen d rfen Die Norm ISO 9241 11 1998 1998 weist Individualisierbarkeit als anzustrebendes Qualit tsmerkmal aus Beispielswei sollen Schriftgr en einstellbar sein M glichkeiten der lokalen Anpassung der Benutzungsschnittstelle werden jedoch i Abschnitt 2 3 beschrieben Inhalt der Anforderungsspezifikation nach IEEE Standard 830 1998 2 2 Produktf
125. tlich anwendungsspezifische Logik implementiert und die Schicht der Benutzungsschnittstelle die die Interaktion mit dem Benutzer bernimmt Hinsichtlich dieses konzeptionellen Aufbaus kann man technische Prototypen weiter in horizontale und vertikale Prototypen unterscheiden Der horizontale technische Prototyp realisiert Aspekte einer spezifischen Ebene des Softwaresystems Der Anwendungsprototyp implementiert zum Beispiel die Anwendungslogik und der Oberfl chenprototyp die Benutzungsschnittstelle Hiermit untersucht oder demonstriert man die Funktionalit t einer ausgesuchten Schicht Da eine Schicht auf die andere aufbaut aber nur eine Schicht implementiert wird ben tigen wir neben der Implementierung der relevanten Schicht selbst noch einen Simulator f r die Schicht auf die sich die relevante Schicht st tzt Man kann diese als Stumpf implementieren Ein Stumpf bietet nicht die volle Funktionalit t sondern liefert auf die Anfragen der h heren Schicht einfach nur vorgefertigte Ergebnisse Oberfl chenprototypen k nnen zum Beispiel so implementiert werden dass die Anwendungsschicht alle Daten die in der Oberfl che f r bestimmte Anwendungsszenarien sichtbar sein sollen in internen Tabellen abgespeichert hat und sie ohne weitere Berechnungen einfach als Ergebnis einer aufgerufenen Operation zur ck liefert Damit zeigt der Oberfl chentyp m glicherweise falsche Daten an aber zumindest die Interaktion l sst sich demonstrieren
126. u erkennen sei Der Kunde nimmt dann einen roten Farbstift zeichnet daf r rote Pfeile nach oben beziehungsweise unten ber dem ersten beziehungsweise letzten angezeigten Element ein und sagt uns dass er das gerne so h tte W hrend wir dem Kunden diesen Prototypen vorf hren bemerkt dieser au erdem dass wir im Auswahldialog keine M glichkeit vorgesehen haben den Dialog durch einen anderen Weg als zum Kaufdialog zu verlassen Uns ist also gl cklicherweise fr h genug vom Kunden klar gemacht worden dass wir in der Dialogf hrung einige Dinge bersehen haben Die berarbeitung unseres Papierprototypen ist aber einfach So einfach dass es der Kunde gleich selbst bernehmen konnte Passive Storyboards eignen sich besonders in der fr hen Phase des Interaktions Designs in der man den Benutzer aktiv in den Design Prozess einbeziehen m chte Anforderungsanalyse Aktive Storyboards Demonstration Abspielen einer selbstablaufenden Prasentation des Systemverhaltens Mittel o Film Diashow o selbstablaufende PowerPoint Prasentation Bemerkung erm glicht einfache automatisierte Darstellung von typischen Anwendungsszenarien erfordert nicht unbedingt die Anwesenheit von Analytikern erlaubt keine Interaktion w hrend der Pr sentation Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 59 82 Softwa re P roje kt Aktive Storyboards Demonstration Lo A nford eru ngsa na l yse Asgatib
127. ung von Prototypen erfordern erh hten Entwicklungsaufwand durch zus tzliche Prototyp Entwicklung Gefahr dass Wegwerf Prototyp Teil des Produkts wird z B aus Zeitdruck Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 61 82 2008 11 04 2008 11 04 Software Projekt erlauben fr hzeitige Demonstration von L sungsans tzen Anforderungsanalyse etaben F hsige Bligung dr Bentz vermeiden das Leere Blatt Syndrom reduzieren Entwicklungsrisiken durch fr hzeitige Diskussion mit Soll Analyse Prototyping Beteligten Zum Ende des Abschnitts ber Prototypen fassen wir die Vor und Nachteile von Prototypen zusammen Vorteile Software Projekt erlauben fr hzeitige Demonstration von L sungsans tzen Anforderungsanalyse Me Baliga dr Basra vermeiden das Leere Blatt Syndrom reduzieren Entwicklungsrisiken durch fr hzeitige Diskussion mit Soll Analyse Prototyping Beteiigten Nachteil Vor und Nachteile des Einsatzes von Prototypen geeignete Werkzeuge erm glichen die schnelle Erstellung von Prototypen ee und Nachteile des Einsatzes von Prototypen Sysco cosine Ea tne se ae Gefahr dass Wegwerf Prototyp Teil des Produkts wird z B aus Zeitdruck Prototypen erlauben eine fr hzeitige Demonstration von L sungsans tzen mit vertretbaren Kosten Gerade weil der Interaktion eine hohe Bedeutung zukommt und sie auch in der Anforderungsspezifikation genau b
128. unktionen o Zusammenfassung der Funktionen 2 3 Charakteristika der Benutzer o Bildungsstand Erfahrung technische Kenntnisse 2 4 Einschr nkungen Beispiele Gesetzliche Rahmenbedingungen Hardwarebeschr nkungen parallelisierte Ausf hrung erforderliche Zuverl ssigkeit sicherheitskritische Aspekte Datenschutzaspekte oe 2 5 Annahmen und Abh ngigkeiten o z B Betriebssystem ist auf Hardware verf gbar Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 74 82 Inhalt der Anforderungsspezifikation nach IEEE Standard Software P roj ekt 830 1998 s Produktfunktionen L Anforderungsanalyse vane att re ae s o Bildungsstand Erfahrung technische Kenntnisse EAEn ngsspezifikation AE ee ees Est der Anforderungsspezifikation nach IEEE 3 N Standard 830 1998 ie und Abh ngigkeiten z B Betriebssystem ist auf Hardware verf gbar 2 2 Produktfunktionen Hier werden alle Produktfunktionen die unterst tzt werden sollen kurz zusammengefasst Ihre Detaillierung folgt in Kapitel 3 2 3 Charakteristika der Benutzer In diesem Abschnitt werden die Charakteristika der Benutzer beschrieben Dies kann in Form der oben eingef hrten Personas geschehen Alle f r uns als Entwickler relevanten Details sollten erw hnt werden Dazu geh ren meist der Bildungsstand die Erfahrung und vorhandene technische Kenntnisse 2 4 Einschr nkungen Alle ma gebenden Einschr nkungen
129. urteilen ob man die Software wiederverwenden kann Nicht spezifizierte Systeme sind kaum durchschaubar darum schwer wiederzuverwenden e Sp tere Reimplementierung Soll das System sp ter gegen ein neues System ersetzt werden muss man wissen was amp tut Kompatibilit t setzt voraus dass man wei womit die neue Software kompatibel sein soll Angestrebte Eigenschaften der Spezifikation inhaltlich 1 zutreffend nicht korrekt 2 vollst ndig relativ zu den W nschen des Kunden 3 widerspruchsfrei oder konsistent damit auch realisierbar 4 neutral d h abstrakt und damit offen f r beliebigen Entwurf in der Darstellung 5 leicht verst ndlich f r alle Zielgruppen 6 pr zise schlie t Umgangssprache aus in der Form 7 leicht erstellbar was die Notationen und Modelle betrifft 8 leicht verwaltbar also auch zweckm ig strukturiert 9 objektivierbar auch nicht sinnvoll testbar genannt Diese Merkmale konkurrieren d h die Erf llung des einen erschwert oder verhindert die Erf llung des anderen Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 69 82 2008 11 04 2008 11 04 Software Projekt inhaltlich 1 zutreffend ht korrekt Anforderungsanalyse 2 van rts dr W nschen des Kunden 3 widerspruchsfrei oder konsistent damit auch realisierbar 4 neutral d h abstrakt und damit offen f r beliebigen Entwurf fel cht in d
130. uziert Ist Zustand Was Software Projekt Verstandi A Anforderungsanalyse an ox l Roke Zu welchem Zweck m oaa Kauf eines Artikels Ist Analyse o Kommunikation Nach welchen Regeln wirken Operationen 1 Dokumenten Bierman CO o Daten Beratung vor Kauf Operation aber optional o Schwachstellen o Was benutzt produziert Operation Ist Zustand Was ar des K ufers N Betrachten wir diese Fragen zu den Aufgaben an unserem Beispiel des Fahrradladens Wir untersuchen hier die besondere Aufgabe des Einkaufes Dies ist eine Operation unter vielen in einem Fahrradladen Die Reparatur oder der Umtausch sind weitere Beispiele f r Operationen in einem Fahrradladen Bsp Der Einkauf folgt im Wesentlichen dem folgenden Ablauf Der Kunde betritt den Laden und u ert seinen Wunsch gegen ber dem Verk ufer Der Verk ufer fragt nach den Details und ber t den Kunden Der Kunde w hlt aus dem Angebot aus kauft und bezahlt wenn er etwas Passendes gefunden hat Der Verk ufer bergibt den Artikel und den Kassenzettel sobald der Betrag durch den Kunden beglichen wurde De Wer oder was f hrt Operation aus Die Ausf hrenden sind Kunde und Verk ufer in den oben beschriebenen Rollen Wann und wie h ufig lelo h ufiger statt als morgens Zu welchem Zweck Der K ufer ben tigt einen Fahrradartikel Der Verk ufer m chte Umsatz erzielen Nach welchen Regeln wirken Operationen zusammen
131. war branchen bergreifend also Fahrradteile genauso wie Computer Hardware etc Wir m chten dem Benutzer die zuk nftige Interaktion mit einem solchen PDA demonstrieren Die Interaktion mit einem PDA hat besondere Herausforderungen weil die darstellbare Fl che sehr begrenzt und typische Eingabeger te wie Maus und Tastatur nicht vorhanden sind Bild 1 Wir fertigen einen Papierprototypen an indem wir einen realen PDA hernehmen und die dargestellten Elemente zeichnen und auf das Display legen Das Bild zeigt die Einstiegsmaske mit den Produktgruppen des K ufers die mit dem PDA verwaltet werden Im Fahrradladen w hlt er das Fahrradsymbol aus wenn er einen Artikel f r sein Fahrrad kaufen m chte Dadurch gelangt er zum n chsten Dialog Beispiel passives Storyboard TUNGSTEN abfragen ndern entfernen ersetzen Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 56 82 Software Projekt E emai eae selleamalkes Prototyping Li ig passives Storyboard 2008 11 04 Beispiel passives Storyboard abfragen ndern entfemen ersetzen Bsp Bild 2 Im n chsten Dialog wird sein Fahrrad angezeigt Er kann dann mit dem Stift auf ein Bestandteil seines Rades tippen Darauf hin wird ein Men eingeblendet in dem er die n chste Aktion ausw hlen kann Er kann einen Artikel abfragen um Daten ber ihn abzufragen ndern um den Artikel in seinen Eigenschaften zu ndern
132. werden 2008 11 04 2008 11 04 Regeln fiir Analyse und Spezifikation Software Projekt Ein Begriffslexikon anlegen und entwickeln A nford eru ngsa na yse o Von der Aufgabe ausgehen nicht von ihrer L sung Daten suchen nicht Programmabl ufe beschreiben Se 7 Abstraktionsebene nicht in einer Darstellung wechseln A nfo rd e ru ngss p eZ l fi ka t l O n Die Spezifikation nach Aspekten organisieren o Ein Mengengeriist bilden z En A o Den Kunden Benutzer einbeziehen E Regeln f r Anal d Spezifik ihc E ege n tur na yse un pezi ikation Die Spezifikation so fr h wie m glich pr fen und dem Konfigurationsmanagement unterstellen Die Spezifikation intensiv verwenden e Geeignete Sprachen und Werkzeuge verwenden Die Anforderungsspezifikation sollte m glichst pr zise aber eben auch verst ndlich sein Hierzu kann man Diagrammen benutzen Die UML beispielsweise enth lt eine Reihe von Diagrammtypen mit deren Hilfe man bestimmte Aspekte verst ndlich und genau beschreiben kann F r das Datenmodell eignen sich zum Beispiel Klassendiagramme Es versteht sich von selbst dass wir dem Kunden unsere Notation erkl ren m ssen Zur Erstellung des Dokuments bedient man sich am besten spezieller Werkzeuge Neben herk mmlicher Editierfunktionen k nnen uns hierbei Werkzeuge helfen Anforderungen eindeutig zu nummerieren sow Verweise einzuf gen zu verfolgen und zu pr fen Diese Werkzeuge k nnen uns auch einen festen Rah
133. ypen von Prototypen in Bezug auf Zweck Technischer Prototyp o zeigt die technische Umsetzbarkeit von Ans tzen zur Probleml sung o implementiert einen kleinen Ausschnitt der Funktionalit t des Systems o wird eher zur Machbarkeitsabschatzung und demonstration eingesetzt Rainer Koschke Uni Bremen Software Projekt Wintersemester 2008 09 48 82 Typen von Prototypen in Bezug auf Zweck Software Projekt Anforderungsanalyse Then Dre zeigt die technische Umsetzbarkeit von Ans tzen zur Probleml sung inen kleinen Ausschnitt der Funktionalit t des Bee Prototyping 5 wird eher zur Machbarkeitsabsch tzung und demonstration eingesetzt gan von Prototypen in Bezug auf Zweck 2008 11 04 Wegwerfprototypen und evolutionare Prototypen unterscheiden sich anhand ihrer Lebensdauer Ein vollig anderes Unterscheidungsmerkmal ist der Zweck den man mit dem Prototypen verfolgt Technische Prototypen zielen auf die technische Umsetzbarkeit von Ans tzen zur Probleml sung Dazu implementiert der Prototyp einen kleinen Ausschnitt der Funktionalit t des Systems Technische Prototypen werden somit eher zur Machbarkeitsabsch tzung und demonstration eingesetzt Sie gleichen dem Crash Test Stand mit dessen Hilfe man das Verhalten von Karosserien im Automobilbau untersucht Technische Prototypen k nnen sowohl f r den Wegwurf oder den evolution ren Ausbau vorgesehen sein Sie k nnen sich des Weiteren unterschieden in
134. zusammen setzt Das Software Engineering Glossar IEEE Std 610 12 1990 definiert Requirement wie folgt Requirement condition or capability needed by a user to solve a problem or achieve an objective Zu Deutsch eine Anforderung ist eine Bedingung oder Fahigkeit die von einem Benutzer benotigt wird um ein Problem zu losen oder ein Ziel zu erreichen Eine Spezifikation ist wie folgt definiert Specification document that specifies in a complete precise verifiable manner the requirements of a systen or component and often the procedures for determining whether these provisions have been satisfied Eine Spezifikation ist ein Dokument das vollst ndig pr zise und berpr fbar die Anforderungen an ein System oder eine Komponente spezifiziert und oft auch die Pr fprozeduren nennt um festzustellen ob diese Forderungen tats chlich erf llt sind Diese Definition erl utert nicht nur den Begriff Spezifikation sondern stellt auch eine Reihe von Forderungen f r Spezifikation auf Sie sollen vollst ndig pr zise und berpr fbar sein Vollst ndig bedeutet dass die Spezifikation alle relevanten Anforderungen nennt Pr zise hei t dass keine Anforderung missverstanden werden kann berpr fbar bedeutet dass man f r jede Anforderung eine Pr fprozedur angeben kann anhand derer man objektiv nachweisen kann dass eine Anforderung erf llt ist Wir werden uns mit diesen Eigenschaften und mit weiteren Qualit ten die eine

Software-Projekt ¨Uberblick I - FB3 - Uni Bremen

Contents

Download Pdf Manuals

Related Search

Related Contents

Software-Projekt &uml;Uberblick I - FB3 - Uni Bremen

Contents

Download Pdf Manuals

Related Search

Related Contents

Software-Projekt ¨Uberblick I - FB3 - Uni Bremen