ANFORDERUNGSANALYSE UND SPEZIFIKATION

Größe: px
Ab Seite anzeigen:

Download "ANFORDERUNGSANALYSE UND SPEZIFIKATION"

Transkript

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

2 1 Sie verstehen, warum der Anforderungsprozess wichtig ist. Sie lernen die verschiedenen Arten von Anforderungen kennen. Sie lernen, welche Tätigkeiten zum Anforderungsprozess gehören. Sie lernen, welche Personen an der Anforderungsphase beteiligt sind. Ihnen sind Anforderungs- vokabeln geläufig.

3 2 1. Einführung 2. Begriffe 3. Erheben und Analysieren 4. Dokumentieren 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

4 Weg der Anforderungen (vereinfacht) 3 Spezifikation Entwurf Anforderungssammlung Code Kunde Entwickler

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

6 Anforderung: Definition 5 Eine Anforderung (requirement) ist: 1. Bedingung bzw. Fähigkeit, die ein Anwender stellt bzw. benötigt, um ein Problem zu lösen oder ein Ziel zu erreichen 2. Bedingung oder Fähigkeit, die ein System erfüllen bzw. besitzen muss, um einem Vertrag, einem Standard, einer Spezifikation oder einem anderen formalen Dokument zu genügen 3. Eine dokumentierten Darstellung einer Bedingung oder Fähigkeit aus 1. oder 2. IEEE-Std

7 Anforderungen - Arten 6 o Funktionale Anforderung (auch: Verhaltensanforderung) definiert eine vom System oder einer Systemkomponente bereitzustellende Funktion bzw. Service. engl.: functional requirements, FR o Qualitätsanforderung definiert eine qualitative Eigenschaft des Systems, einer Systemkomponente oder einer Funktion. Synonym: nicht- funktionale Anforderung engl.: non- functional requirements, NFR o Randbedingung ist eine organisatorische oder technologische Anforderung, die die Art und Weise einschränkt, wie ein Produkt entwickelt wird. engl.: constraint Pohl, Rupp: Basiswissen Requirements-Engineering, 2009

8 Funktionale vs. nicht- funktionale Anforderungen 7 o Die Abgrenzung zwischen nicht- funktionalen und funktionalen Anforderungen ist nicht scharf. o Aus einer nicht- funktionale Anforderung o Das System muss den unautorisierten Zugriff auf die Kundenstammdaten verhindern. wird durch Verfeinerung eine funktionale Anforderung Der Zugriff auf die Kundenstammdaten muss über eine Login- Prozedur mit Passworten geschützt werden.

9 Nicht- funktionale Anforderungen 8 Quelle: ISO FDIS (2010) Qualitätsmodell der ISO (Nachfolger der ISO 9126)

10 Randbedingungen 9 o Organisatorische Anforderungen Zu berücksichtigende Abläufe beim Kunden (Produkteinsatz) Entwicklungsvorgaben, z.b. Prozess, Programmiersprache Einsatzvorgaben, z.b. Betriebssystem, Datenbank kann der Kunden festgelegen o Externe Anforderungen Regularien, z.b. FDA, Basel Gesetze Ethische Regeln sind vom Kunden und vom Entwickler zu berücksichtigen

11 Inhalt Einführung 2. Begriffe 3. Dokumentation 4. Erhebung von Anforderungen 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

12 11 o Vision o Ziel Informell, oft sehr abstrakt SMART n S n M n A n R n T pezifisch essbar ttraktiv ealistisch erminbezogen Vision vs. Ziele Ziele sind hilfreich, um die Absichten der Stakeholder zu verstehen (=Grundlage, um Anforderungen zu verstehen).

13 Inhalt Einführung 2. Begriffe 3. Dokumentation Systemkontext Natürliche Sprache Szenario/Use Case Drei Perspektiven Atomare Anforderungen Templates/Gliederungen 4. Erhebung von Anforderungen 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

14 Systemkontext (1) 14 Systemgrenze Kontextgrenze Irrelevante Umgebung nach Pohl, Rupp: Basiswissen Requirements-Engineering, 2009

15 Systemkontext (2) 15 o Systemkontext besteht aus Geschäftsprozessen Technischen Prozessen Personen Organisationsstrukturen IT- Infrastruktur (z.b. Datenbanken) o System Quellen Senken o Grauzone der Systemgrenze Die Systemgrenze ist zunächst nicht klar n breiter grauer Strich Im Verlauf des RE wird klar, welche Funktionen im SW- System realisiert werden sollen

16 Systemkontext (3) 16 o Darstellung des Kontext: Kontext- Diagramme alternativ: use case Glinz, Vorlesung RE, Uni Zürich

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

18 Inhalt Einführung 2. Begriffe 3. Dokumentation Systemkontext Natürliche Sprache Szenario/Use Case Drei Perspektiven Atomare Anforderungen Templates/Gliederungen 4. Erhebung von Anforderungen 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

19 Art der Darstellung der Anforderungen 19 Darstellung mit unterschiedlichem Formalitätsgrad. o Texte in natürlicher Sprache o Strukturmodelle o Interaktionsmodelle Graphisch, angereichert mit natürlicher Sprache o Formale Modelle auf der Grundlage mathematisch- logischer Formalismen.

20 Natürliche Sprache 20 Die Qualität natürlich- sprachiger Anforderungsspezifikation lässt sich systematisch verbessern durch: geeignete Strukturierung des Dokuments n Gliederung, kommt später Regeln zur sprachlichen Formulierung von Anforderungen n Satztemplate (1- Satz- Anforderung, Begründung), n shall/should bzw. muss/sollte. kontrollierten Umgang mit Redundanz konsequente Verwendung eines Glossars n (Fach- )Termini erklären. n Im Glossar Software/Software- Engineering- Begriffe vermeiden.

21 Diskussion 21 Was halten Sie von folgendem Text Beschreibt er klar und deutlich, was zu entwickeln ist? Begründen Sie Ihre Ansicht mit entsprechenden Textstellen.

22 Anforderungsbeschreibung 22 Der Bediener drückt eine Wahltaste und bezahlt den geforderten Betrag. Sobald die Summe der eingeworfenen Münzen den geforderten Betrag übersteigt, wird das Getränk zubereitet und ausgegeben. Ferner wird das Wechselgeld berechnet und ausgegeben. Der Bedienvorgang endet, wenn das Getränk entnommen wird und wenn die Bedienung für länger als 45s unterbrochen wird. Mit einer Annulliertaste kann der Bedienvorgang jederzeit abgebrochen werden. Bereits eingeworfenes Geld wird beim Drücken der Annulliertaste zurückgegeben. Nach dem Drücken einer Wahltaste kann entweder bezahlt oder eine andere Wahltaste gedrückt werden. Die zuletzt getätigte Auswahl gilt.

23 Anforderungsbeschreibung 23 Der Bediener drückt eine Wahltaste und bezahlt den geforderten Betrag. Sobald die Summe der eingeworfenen Münzen den geforderten Betrag übersteigt, wird das Getränk zubereitet und ausgegeben. Ferner wird das Wechselgeld berechnet und ausgegeben. Der Bedienvorgang endet, wenn das Getränk entnommen wird und wenn die Bedienung für länger als 45s unterbrochen wird. Mit einer Annulliertaste kann der Bedienvorgang jederzeit abgebrochen werden. Bereits eingeworfenes Geld wird beim Drücken der Annulliertaste zurückgegeben. Nach dem Drücken einer Wahltaste kann entweder bezahlt oder eine andere Wahltaste gedrückt werden. Die zuletzt getätigte Auswahl gilt.

24 24 Kern der Anforderung: <Prozesswort> Satztemplate (1) Das System tut etwas selbständig Das System reagiert auf Benutzereingaben Verbindlichkeit: bindend/ empfohlen/ zukünftig Das System reagiert auf Daten oder Signale Pohl, Rupp: Basiswissen Requirements-Engineering, 2009

25 Satztemplate (2) 25 o Prozessworte z.b. drucken, berechnen, speichern, übertragen o Prozessworte benötigen i.d.r. Objekt und Ergänzung z.b. übertrage Temperaturdaten vom Sensor zur Datenbank n (3 Objekte) z.b. drucke Rechnungsdaten in formatierter Form (Vordruck 7b) n (1 Objekt, eine Ergänzung) o Anforderungen können Bedingungen enthalten z.b. falls die Temperatur unter 1 C fällt, n konditional: falls n temporal: sobald vermeide wenn (kann konditional oder temporal sein)

26 Diskussion 26 Schreiben Sie zwei Anforderungen für Getränkeautomaten unter Verwendung des erweiterten Templates

27 27 Der Bediener drückt eine Wahltaste und bezahlt den geforderten Betrag. Sobald die Summe der eingeworfenen Münzen den geforderten Betrag übersteigt, wird das Getränk zubereitet und ausgegeben. Ferner wird das Wechselgeld berechnet und ausgegeben. Der Bedienvorgang endet, wenn das Getränk entnommen wird und wenn die Bedienung für länger als 45s unterbrochen wird. Mit einer Annulliertaste kann der Bedienvorgang jederzeit abgebrochen werden. Bereits eingeworfenes Geld wird beim Drücken der Annulliertaste zurückgegeben. Nach dem Drücken einer Wahltaste kann entweder bezahlt oder eine andere Wahltaste gedrückt werden. Die zuletzt getätigte Auswahl gilt. Einleitung Begriffe Dokumentation Erheben Management Qualitätssicherung

28 Inhalt Einführung 2. Begriffe 3. Dokumentation Systemkontext Natürliche Sprache Szenario/Use Case Drei Perspektiven Atomare Anforderungen Templates/Gliederungen 4. Erhebung von Anforderungen 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

29 Szenario 29 o Beschreibt ein konkretes Beispiel für die Erfüllung bzw. Nichterfüllung eines oder mehrerer Ziele. o Enthält typischerweise eine Folge von Interaktionsschritten und setzt diese in Bezug zum Systemkontext. o Meist in natürlicher Sprache. o Sind gut geeignet um Information über den Kontext zu dokumentieren. Personen oder andere Systeme, die mit dem System interagieren. Vorbedingungen, die zu Beginn des Szenarios erfüllt sein müssen. Reale oder imaginäre Örtlichkeiten, in der die Ausführung eines Szenarios stattfindet.

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

31 Arten von Szenarien 31 o o o Ist- Szenarien beschreiben die Situation mit dem gegenwärtigen System zum Beispiel, um es gegen zukünftige Anforderungen abzugrenzen. Visionäre Szenarien beschreiben ein künftiges System Kommunikationsmedium, "preiswerter Prototyp. Bewertungsszenarien dienen der (späteren) Evaluierung des Systems Status- Bewertung, Usability, Akzeptanztest, Bewertung der Architektur.

32 Regeln zur Formulierung von Szenarien (1) 32 o Sprache/Grammatik 1. Schreiben Sie Szenarien in der Gegenwartsform. 2. Schreiben Sie Szenarien in der Aktivform. 3. Schreiben Sie in einfachen Sätzen. 4. Vermeiden Sie Modalverben (z.b. müssen, können, sollen, wollen, mögen, dürfen). o Struktur 5. Trennen Sie jede Interaktion deutlich von anderen Interaktionen. Pohl, Requirements Engineering Grundlagen, Prinzipien, Techniken, 2008

33 Regeln zur Formulierung von Szenarien (2) 33 o Inhalt 6. Beschreiben Sie aus dem Blickwinkel eines Außenstehenden. 7. Benennen Sie explizit die Akteure. 8. Benennen Sie das Ziel des Szenarios explizit. 9. Fokussieren Sie bei der Szenariobeschreibung auf die Erfüllung des Ziels.

34 Fragen zur Erstellung (visionärer) Szenarien 34 o Welches Ziel verfolgt der Akteur? o Was sind die Aufgaben, die der Akteur vom System erwartet? o Auf welche Informationen greift der Akteur zu? Wer generiert diese Informationen? o Über welche externen Änderungen muss der Akteur das System informieren? o Über welche Ereignisse muss das System den Akteur unterrichten?

35 Use Case 35 o Deutsch: Anwendungsfall o Zur strukturierten Dokumentation der Funktionalität existierender oder geplanter Systeme durch Interaktionsfolgen o Besteht aus Use Case- Diagramm Übersichtsbild Use Case- Spezifikation Tabelle

36 Beispiel: Use Case- Diagramm 36 o UML Use Case- Diagramme zeigen, welche Anwendungsfälle (= welche Funktionalität) ein System bietet und wer diese in Anspruch nehmen kann

37 37 Beispiel: Use Case HebeGeldAb (1) Anwendungsfallname Geld abheben Akteure Ziel Kunde Geld vom Konto abheben Hauptablauf 1. Der Kunde meldet sich mit seiner Kontonummer/PIN am Geldautomaten an. 2. Das System überprüft die Identität. 3. Der Kunde gibt einen Betrag ein und wählt eine Währung aus. 4. Das System überprüft, ob die Währung vorrätig und der Betrag auf dem Konto verfügbar ist;; es zeigt den Auszahlungsbetrag sowie die Belastung des Kontos an 5. Der Kunde 5a. bestätigt die Angaben. 6a. Das System bucht den Betrag ab und zahlt ihn aus. 5b. bricht den Vorgang ab 6b. Das System bestätigt den Abbruch. 7. Der Kunde meldet sich ab. 8. Das System gibt eine Anmeldungsseite aus.

38 38 Beispiel: Use Case HebeGeldAb (2) Ausnahmeabläufe Anfangsbedingungen Abschlussbedingungen Qualitätsanforderungen Ausnahme in 2.: Kontonummer unbekannt 101. Das System gibt die Fehlermeldung Kto-Nr. unbekannt aus;; weiter mit 8. Ausnahme in 4.: Währung nicht verfügbar 201. Das System gibt die Fehlermeldung Währung nicht verfügbar aus;; weiter mit 3. Ausnahme in 4.: Konto hat keine ausreichende Deckung 301. Das System gibt die Fehlermeldung Betrag nicht verfügbar aus;; weiter mit 3. Ausnahme in 3/5/7: längere Zeit keine Aktion durch Kunde (timeout) 401. Das System meldet den Kunden ab. weiter mit 8. Kunde hat ein Konto bei dem Geldinstitut Der Kunde hat den gewünschten Betrag erhalten ODER er bekam eine Meldung, warum die Auszahlung nicht möglich war Ein Nutzer der häufiger am Automaten Geld abhebt soll von Beginn der Aktion bis zur erfolgreichen Auszahlung von Geldes nicht länger als 90 s benötigen.

39 Elemente von Use Case- Diagrammen 39 Name Use Case Objekte «extend» A Beziehungen inkludiert B A Name Akteur (Person) erweitert B «include» A Akteur (System) generalisiert «system» Name B Name System mit Systemgrenze Name kommuniziert Name

40 Beispiel für include 40 Geld abheben Kunden authentif. «include» 1. Include: Kunden authentif. 2. Kunde gibt Währung und Betrag ein 3. System prüft Kunden authentif. 1. Kunde gibt Kontonummer an 2. Kunde authentifiziert sich per PIN authentif. per mtan authentif. 1. Kunde gibt Kontonummer an 2a. System generiert TAN und sendet SMS 2b. Kunde gibt TAN ein

41 Anleitung für Use Cases (1) 41 o Use Cases sollen mit Verbalphrasen beschrieben werden. Der Name sollte anzeigen, was der Anwender bewirken möchte. z.b. MeldeVorfall EröffneVorfall o Akteure sollen mit Nominalphrasen benannt werden. z.b. Außenbeamter Dienstleiter

42 Anleitung für Use Cases (2) 42 o Bzgl. dem Ereignisfluss: Die Systemgrenzen sollen klar sein. n Arbeitsschritte des Akteurs und Arbeitsschritte des Systems sollen gekennzeichnet sein. n z.b. Der Dienstleiter. Das System Die einzelnen Schritte im Ereignisfluss sollten im Aktivstil geschrieben sein, um deutlich zu machen, wer diese vollzieht n z.b. Der Dienstleiter überprüft Der Außenbeamte hat... empfangen... Das System berechnet Einrücken der Systemarbeitsschritte Die ursächliche Beziehung zwischen aufeinander folgenden Schritten soll klar sein.

43 Anleitung für Use Cases (3) 43 o Ein Anwendungsfall soll die vollständige Transaktion eines Anwenders schildern. o Ein Anwendungsfall sollte im Idealfall nicht länger als eine Seite sein. Use case vs. Szenario Rolle vs. Name Akteur-initiiert/ vs. beliebiger (Teil-)Ablauf Transaktion vollst. Aufgabe vs. spezieller Ablauf eine Aufgabe vs. viele Aufgaben

44 Diskussion 44 Schreiben Sie das Beispiel des Getränkeautomaten zu einem Use Case Getränk kaufen um! Benutzen Sie das verteilte Schema!

45 45 Der Bediener drückt eine Wahltaste und bezahlt den geforderten Betrag. Sobald die Summe der eingeworfenen Münzen den geforderten Betrag übersteigt, wird das Getränk zubereitet und ausgegeben. Ferner wird das Wechselgeld berechnet und ausgegeben. Der Bedienvorgang endet, wenn das Getränk entnommen wird und wenn die Bedienung für länger als 45s unterbrochen wird. Mit einer Annulliertaste kann der Bedienvorgang jederzeit abgebrochen werden. Bereits eingeworfenes Geld wird beim Drücken der Annulliertaste zurückgegeben. Nach dem Drücken einer Wahltaste kann entweder bezahlt oder eine andere Wahltaste gedrückt werden. Die zuletzt getätigte Auswahl gilt.

46 Fragerunde 46 Welche Unterschiede sehen sie zwischen Szenarien und Use Cases? Wann setzen Sie Szenarien, wann Use Cases ein?

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

48 Inhalt Einführung 2. Begriffe 3. Dokumentation Systemkontext Natürliche Sprache Szenario/Use Case Drei Perspektiven Atomare Anforderungen Templates/Gliederungen 4. Erhebung von Anforderungen 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

49 49 Ein-/Ausgabe- Daten Nutzungsbeziehungen System/ Systemkontext Systemverhalten/ zustandsbasiert, z.b. Reaktion auf Signale von außen 3 Perspektiven Zweck: verfeinern von Use Cases Aufzeigen von Zusammenhängen zwischen Use Cases Anforderungen Funktion Informationsfluss zwischen System und Systemkontext

50 zur Funktion: Datenflussdiagramme (DFD) 50 o... zeigen den Datenfluss eines Prozesses oder einer Tätigkeit (z. B. die Datenverwendung und Veränderung bei der Angebotserstellung in einem Handelsunternehmen). o... geben eine funktionale Perspektive des Systems wieder. o... sind nützlich um die Abfolge von Aktionen zu verdeutlichen. vom Input (Eingabe des Anwenders) bis zum Output (Ausgabe des Systems)

51 Beispiel DFD 51

52 Datenflussdiagramme - Notation 52 Name Input/Output (Terminator) Name Funktion (Prozess) Name Datenbank (File) Name Datenfluss

53 Diskussion 53 Zeichnen sie das Datenflussdiagramm einer Insulin- Pumpe. Sie enthält einen Sensor, der den Blutzucker bestimmen kann und injiziert automatisch die richtige Dosis Insulin.

54 Insulin- Pumpe 54 Blood Blood Sugar Sensor Blood Parameters Blood Sugar Analysis Blood Sugar Level Insulin Insulin Pump Pump Control Commands Insulin Delivery Controller Insulin Requirement Computation Insulin Requirement Sommerville, Software Engineering, 2010

55 Fragerunde 55 Welche Notationen kennen Sie, um Verhalten Struktur in der Anforderungsphase zu verdeutlichen?

56 56 Ein-/Ausgabe- Daten Nutzungsbeziehungen System/ Systemkontext Systemverhalten/ zustandsbasiert, z.b. Reaktion auf Signale von außen 3 Perspektiven Statecharts Zustandsdiagramm E/R-Diagramm Klassendiagramm Anforderungen Datenflussdiagramm Aktivitätsdiagramm Funktion Informationsfluss zwischen System und Systemkontext

57 Inhalt Einführung 2. Begriffe 3. Dokumentation Systemkontext Natürliche Sprache Szenario/Use Case Drei Perspektiven Atomare Anforderungen Templates/Gliederungen 4. Erhebung von Anforderungen 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

58 58 Beispiel: Atomare Anforderungen / Snow Card FR Anforderungsnummer: 75 o Typ der Anforderung: Funktionale Anforderung o Beschreibung: Das Produkt löst einen Alarm aus, wenn die Wetterstation die eingelesenen Daten nicht übertragen kann. o Rational: Fehler bei der Übermittlung von Daten können ein Hinweis auf einen Defekt in der Wetterstation sein, die evtl. Wartung benötigt. Die Daten zur Vorhersage des Straßenlage können aus diesem Grund unvollständig sein. o Quelle: Karl- Heinz Müller o Fit Kriterium: Für mindestens eine Wetterstation soll die Anzahl der pro Stunde übermittelten Daten unterhalb des durch den Hersteller definierten Wertebereiches liegen. o Event/Use Case: UC 3.4 WerteÜbertragen o Priorität: Hoch o Konflikte: Keine o Andere Materialien: Herstelleranleitung der Wetterstation IN34.67 Robertson & Robertson, Mastering the Requirements Process, 2008

59 Atomare Anforderungen 59 Sollten folgende Information beinhalten: o Anforderungsnummer: ein eindeutiger Identifier, zur Zuordnung/Verfolgbarkeit über den gesamten Life- Cycle. o Typ der Anforderung: Constraint, Funktionale Anforderung, Nicht- funktionale Anforderung. o Beschreibung: der Inhalt der Anforderung. o Rational: Die Motivation/Begründung hinter der Anforderung. o Quelle: Person, die die Anforderung zum ersten Mal erwähnt hat. o Fit Kriterium: Die messbare Beschreibung der Anforderung, die erlaubt zu überprüfen, ob die Anforderung erfüllt ist. o Event/Use Case: Verweis auf den Geschäftsvorfall, aus dem die Anforderung erwachsen ist. o Priorität: Wie wichtig ist die Anforderung im Hinblick auf das gesamte Produkt? o Konflikte: Gibt es Anforderungen, denen die Anforderung widerspricht? o Andere Materialien: Verweis auf Dokumente oder andere Artefakte, die für diese Anforderung von Bedeutung sind.

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

61 Regeln zur Formulierung von NFRs Formulieren Sie NFRs kurz und prägnant. 2. Verwenden Sie Aktivformulierung. 3. Formulieren Sie überprüfbare NFRs. 4. Verfeinern Sie nicht überprüfbare NFRs. 5. Formulieren Sie den Mehrwert einer NFR. 6. Geben Sie eine Begründung für die NFR an. 7. Vermeiden sie Lösungsansätze.

62 Diskussion 62 Welche Regel wird mit dem folgenden NFRs verletzt? Finden sie eine bessere Formulierung. 1. Das geplante System soll intuitiv benutzbar sein 2. Das geplante System soll besser sein als sein Vorgängersystem 3. Die Dauer für die Erstellung von Quartalsberichten soll im Vergleich zum Vorgängersystem halbiert werden. 4. Durch komplexe Datenübertragung soll das geplante System um 10% kürzere Antwortzeiten aufweisen als sein Vorgängersystem

63 63 Beispiel: Atomare Anforderungen / Snow Card NFR Anforderungsnummer: 43 o o o o o o o o o Typ der Anforderung: Nicht- Funktionale Anforderung Beschreibung: Das System ist von 10- jährigen Kindern zu bedienen Rational: das System ist für Kinder vorgesehen, die die Grundschule absolviert haben Quelle: Karl- Heinz Müller Fit Kriterium: 80% der Testgruppe von 10- jährigen können sich innerhalb 2 Minuten erfolgreich registrieren; 90% der Testgruppe Event/Use Case: UC 1/Registrierung; UC 3/ Priorität: Hoch Konflikte: Keine Andere Materialien: keine Robertson & Robertson, Mastering the Requirements Process, 2008

64 Fragerunde 64 Wir haben über Use Cases, Perspektiven und atomare Anforderungen gesprochen beschreiben wir alle Anforderungen mehrfach?

65 Inhalt Einführung 2. Begriffe 3. Dokumentation Systemkontext Natürliche Sprache Szenario/Use Case Drei Perspektiven Atomare Anforderungen Templates/Gliederungen 4. Erhebung von Anforderungen 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

66 Rahmenwerke für Anforderungsdokumente 66 o VDI/VDE Standard 3694: Referenzstruktur für Lasten- und Pflichtenheft o IEEE Standard : Referenzstruktur für Systems Requirements Spezifikationen o IEEE Standard für Software Requirements Spezifikationen o Volere Template von Robertson & Robertson o Template von Sören Lauesen 07.doc

67 Qualitätskriterien für Anforderungsartefakte 67 o eindeutig / verständlich klar o vollständig komplett o konsistent o korrekt Clarity Completeness Consistency Correctness + o nachvollziehbar o überprüfbar o bewertet / abgestimmt o modifizierbar / erweiterbar / verfolgbar Gilt für einzelne Anforderungen das ganze Dokument!

68 Glossar 70 o Zweck o Inhalt konsistente Terminologie aller Beteiligten kontextspezifische Fachbegriffe n ggf. Alltagsbegriffe mit spezieller Bedeutung n Bsp.: Medien bei techn. Betriebsleitung Abkürzungen/Akronyme Synonyme/Homonyme

69 Regeln für Glossar 71 o zentral verwaltet o eine Person verantwortlich o projektbegleitend gepflegt o allgemein zugänglich o verbindlich verwendet o Quelle der Begriffe angegeben o abgestimmt mit allen Stakeholdern o einheitlich strukturiert Glossar ist zwingend notwendig

70 Personas (1) 72 Zur Beschreibung der Zielgruppe/Nutzergruppe

71 Personas (2) 73 o Individualisierung Foto, Name o Biographie Geographisch n Region, Klima, Stadt/Land, Demographisch n Geschlecht, Alter, Familienstand, Generation, Ausbildung, Beruf, Einkommen, Psychographisch Persona enthält nur für das Projekt relevante Informationen n Klasse, soziale Rolle, Herangehensweisen, Lifestyle, Hobbies,

72 Personas (3) 74 o Beziehung zum Produkt Bedeutung (im Vergleich zu anderen Personas) Ziele n Motivation, versteckte Ziele, Einstellung zur Aufgabe, Fähigkeiten n Anwendungsdomäne, Computernutzung, Internetnutzung, Nutzungskontext n Nutzungsrolle, Umgebung, besondere Anforderungen (Sicherheit, Verfolgbarkeit, Genauigkeit) Einstellung/Stimmung n Aktiv/passiv, modern/traditionell,

73 Geschäftsprozesse (1) 75 o Kunden möchten keine Software, sondern Lösungen. o Lösungen helfen Kunden, ihre Aufgaben effektiver/effizienter zu erfüllen. o Lösungen (hier: Software- Lösungen) werden mit Anforderungen beschrieben. o Wie kommen wir von Aufgaben zu Anforderungen? (wie wir von Anforderungen zu Software- Lösungen kommen wissen Sie [demnächst])? Geschäftsprozesse

74 Geschäftsprozesse (2) 76 Notation: BPMN

75 Geschäftsprozesse (3) 77 Übergang zu Systemanforderungsbestimmung und analyse Aufgaben / Aktivitäten markieren, die mit Systemunterstützung ablaufen sollen Geschäftsprozessmodellierung Anforderung Antragsdaten erfassen Schufa-Ausk. einholen Konto einrichten «system support» Antragsdaten erfassen Schufa-Ausk. einholen «system support» Konto einrichten 1. Antragsdaten eingeben 2. Daten prüfen 3. Zulässigkeit bestätigen 4. Konto einrichten

76 Inhalt Einführung 2. Begriffe 3. Dokumentation Systemkontext Natürliche Sprache Szenario/Use Case Drei Perspektiven Atomare Anforderungen Templates/Gliederungen 4. Erhebung von Anforderungen 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

77 Inhalt Einführung 2. Begriffe 3. Dokumentation 4. Erhebung von Anforderungen Quellen Methoden 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

78 RE- Prozess: Anforderungsbestimmung 80 Durchführbarkeitsstudie Bestimmung und Analyse der Anforderungen Spezifikation der Anforderungen Durchführbarkeitsbericht Benutzer- und Systemanforderungen Systemmodelle Validierung der Anforderungen Pflichtenheft nach [Som01]

79 Anforderungsbestimmung und analyse im Detail 81 Anforderungssammlung Anforderungsspezifikation und dokumentation Verstehen des Anwendungsbereichs Anforderungsüberprüfung (Validierung) Prozessbeginn Setzen von Prioritäten Konfliktlösung Pflichtenheft Klassifizierung

80 Anforderungsbestimmung: was ist zu beachten? 82 Es gibt keinen idealen RE- Prozess. à Zuschneidenauf konkrete Projektsituation. Zuberücksichtigende Faktoren: Zugrunde liegendesprozessmodell (linearesoderinkrementellesvorgehen)? Muss die Spezifikation wasserdicht sein (Vertrag; Realisierung durch Dritte)? Sind die Kunden/Benutzer bekannt und können sie in die Erstellung der Spezifikation einbezogen werden? Wird das zu spezifizierende System im Kundenauftrag oder für den Markt entwickelt? Soll Standardsoftware zum Einsatz kommen?

81 Erhebung von Anforderungen (1) 83 o Der schwierigste Schritt der Anforderungsphase. o Geht über das Abfragen von Wissen hinaus. o Die Quellen sind zu Beginn der Anforderungsphase oft nicht bekannt. o Beinhaltet häufig auch die Generierung einer neuen Idee (insbesondere bei innovativen/neuen Produkten).

82 Abbilden oder Gestalten? 84 o Weder dem Kunden genau das liefern, was er wünscht. o Noch wir wissen schon, was gut für den Kunden ist. Innovation initiieren! n Den Beteiligten innovative Lösungen vorschlagen. n Kreativität der Beteiligten anregen n n n Zukunftsszenarien entwerfen und durchspielen. Beschränkungen in Frage stellen und sich von alten Zöpfen verabschieden. Metaphern suchen und explorieren.

83 Erhebung von Anforderungen (2) 85 o Wissen sammeln über Beteiligte Stakeholder und ihre Ziele Nutzeraufgaben Gegenwärtige Situation (Ist- Situation) Erwartungen Wissen über die Domäne

84 86 Anforderungsquellen o Stakeholder Beobachten Interviews Workshops o Dokumente Allgemeine, z.b. Normen, Gesetze, Branchenstandards Spezifische, z.b. alte Anforderungsdokumente, Fehlerberichte o Laufende Systeme Alt- /Vorgängersystem Konkurrenzsystem

85 87 Probleme bei der Erhebung (1)

86 Probleme bei der Erhebung (2) 88 o o o o o Kommunikation Stakeholder sind oft nicht in der Lage genau zu beschreiben, was sie tun, warum sie es tun oder was sie gerne tun würden. Berücksichtigung aller Stakeholder Aufzeigen neuer Möglichkeiten Stakeholder verhaften gerne an alten Gewohnheiten und Vorgängen. Konflikte Zwischen Stakeholdern mit unterschiedlichen Interessen. Widerstand gegen Veränderungen. Prioritäten & Veränderungen Stakeholder wollen zu viel. Stakeholder ergänzen ständig.

87 89 Stakeholders Stakeholder sind alle, die ein Interesse an dem Produkt haben. Sie bezahlen es. Sie bauen es. Sie nutzen es (heute, morgen). Sie verwalten es. Sie sind durch das Produkt in irgendeiner Weise betroffen.

88 Alle Stakeholder berücksichtigen 90 o Wer verwendet die Services, die das System zur Verfügung stellt? o Wer stellt Services zur Verfügung, die im System benötigt werden? o Welche Systeme haben direkte Schnittstellen zum zu spezifizierenden System? o Welche Personen sind an der Entwicklung und Wartung beteiligt? o Wer kennt die Marktbedürfnisse? o Wer kennt/verantwortet das externe Image der Organisation?

89 Fragerunde 91 Denken Sie an den Getränkeautomaten: Wer sind Stakeholder?

90 Inhalt Einführung 2. Begriffe 3. Dokumentation 4. Erhebung von Anforderungen Quellen Methoden 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

91 Erheben von Anforderungen 94 o Interview o Fokus- Gruppe o Beobachtung

92 Weg der Anforderungen (vereinfacht) 95 Spezifikation Entwurf Anforderungssammlung Code Kunde Entwickler

93 Kommunikation 96 Kunde / Anwender Requirements Engineer Wahrnehmung Darstellung Interpretation Objektive Realität Persönliche Realität Linguistischer Ausdruck Ergebnis

94 Arten von Interviews: Grad der Formalität (1) 97 Offenes Interview n Offene Fragen. n Analyse der Daten ist schwierig. n Erfordert gute Interview- Fähigkeiten. n Persönlichkeit hat Einfluss auf das Ergebnis. Halb- strukturiertes Interview n Wird durch vorformulierte Interviewfragen geleitet. n Wird an Hand von Themen gegliedert. n Lässt Raum für spontane Abschweifungen /Ergänzungen.

95 Arten von Interviews: Grad der Formalität (2) 98 Strukturiertes Interview n Hohes Maß an Objektivität. n Erlaubt den einfachen Vergleich zwischen verschiedenen Interviews. n Erlaubt quantitative Auswertung. n Keine Freiheiten in der Interviewführung, enge Führung.

96 Interview Durchführung Vorbereitung Vorliegende Dokumente studieren. Fragen vorbereiten. 2. Durchführung Wenn möglich mit zwei Interviewenden. Evtl. Aufnahme des Interviews auf Band. 3. Eröffnung des Interviews Wofür ist das Interview. Was passiert mit den Antworten. 4. Die Fragen Am Anfang eher allgemein, später spezifischer. Eine Mischung aus offenen und geschlossenen Fragen Aktives Zuhören. Achtung: Auch nonverbale Kommunikation ist von Bedeutung. 5. Abschluss Wie geht es weiter. Die interviewte Person hat das letzte Wort.

97 Beispiel: Nach dem WARUM fragen (1) 100 Neurologische Diagnostik - Interview o Das System soll ein Mini- Keyboard haben mit Start und Stop Knopf. o WARUM? o Man soll es mit der linken Hand bedienen können o WARUM? o Beide Hände sind in der Nähe des Patienten o WARUM? o Schmerzhaft für den Patienten, Elektroden,.. o

98 101 Beispiel: Nach dem WARUM fragen (2) Neurologische Diagnostik - Anforderungsdokument o Kontext: Neurologische Messungen sind schmerzhaft für den Patienten. Die Elektroden müssen während der Messung fixiert bleiben. Beide Hände müssen während der Messung in der Nähe des Patienten sein. o WAS - Anforderung: Beginn und Ende der Messung müssen bedient werden können, während beide Hände in der Nähe des Patienten sind. o WIE - Anforderung: Start und Stopp werden mit einem Fußpedal oder mittels Sprachsteuerung angesteuert.

99 102 Interview- Effekte Wechselwirkung zwischen Befragtem und Fragendem.

100 Interview- Effekte Soziale Erwünschtheit 103 o Soziale Erwünschtheit liegt vor,. wenn Befragte Antworten geben, von denen sie glauben, sie träfen eher auf Zustimmung als die korrekte Antwort, bei der sie soziale Ablehnung befürchten. Ähm... 2 x pro Woche ein Glas! Durchschnittlich viel! Wie oft trinken sie Alkohol?

101 104 Interview- Effekte Halo Effekt o Beim Halo- Effekt erzeugen einzelne Eigenschaften einer Person einen Gesamteindruck, der die weitere Wahrnehmung der Person "überstrahlt". Attraktiv = reich = intelligent

102 105 Recency- Effekt o Der Recency- Effekt ist ein psychologisches Gedächtnisphänomen, welches dazu führt, dass später (recency) erfasste Information gegenüber anderer eingehender Information bevorteilt wird.

103 Fokus Gruppe (1) 106 hier: Stakeholder (insbesondere Nutzer) Quelle: Krueger & Mary, 2003, Focus Groups, Sage Publ., London Krueger & Mary,, Focus Groups, Sage Publ., London, 2003

104 Fokus- Gruppe (2) 107 o Mit Problemen beginnen Flipchart, Kartenabfrage Gründe sammeln o Dann auf Lösung fokussieren Gruppierung der gesammelten Punkte n ca. 40 Punkte Priorisierung n Bspw. 10 Punkte kleben n Bspw. in Gruppen je nach Stakeholder- Rolle o Abschluss mit einer Zusammenfassung der Ergebnisse

105 Fokus- Gruppe (3) 108 o Geeignete Methode, wenn: noch zu wenig Informationen über die Nutzer, deren Aufgaben, den Kontext und die Domäne vorhanden ist. sehr viele Ideen vorhanden sind und diese bewertet werden müssten. verschiedene Perspektiven und Standpunkte besser verstanden werden sollen. weitere Eigenschaften einer Fokus- Gruppe genutzt werden sollen, z.b. Vertrauensbildung, Kundenorientierung o Mögliche Nachteile Diskussionen schwer zu analysieren/leicht fehl- zu- interpretieren. Teilnehmer zu freundlich /nicht realistisch.

106 109 o Anwender im Kontext beobachten. o Arbeitsumgebung, Kommunikationswege, Geräte. o Arbeitsartefakte. Beobachtung (1)

107 Beobachtung (2) Site Visits 110 o Idee o Ziele Site Visits Beobachtung der Stakeholder in ihrer realen Umgebung (evtl. auch Kamera, Computer Monitoring) Erfassen von implizitem Wissen Identifikation versteckter Anforderungen Besseres Verständnis des Kontextes o Geeignete Methode für die Entwicklung neuer Produkte oder in neuen Marktsegmenten

108 Inhalt Einführung 2. Begriffe 3. Dokumentation 4. Erhebung von Anforderungen 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

109 112 Verwalten von Attributen o Attributierung / Sichten Management Attribute: Nr, Id, Name, Version, Quelle, Verantwortlicher, Stabilität, Priorität, Validierungsstatus, Abstimmungsstatus, Release Sichten: Auswahl von Anforderungen nach Attribut- Wert o Priorisierung o Verfolgung o Versionierung Version einzelner Anforderungen Konfiguration aller Anforderungen à im Folgenden à im Folgenden n zusammenpassende Versionen der Anforderungen o Verwaltung von Änderungen à im Folgenden

110 Inhalt Einführung 2. Begriffe 3. Dokumentation 4. Erhebung von Anforderungen 5. Management von Anforderungen 1. Priorisierung 2. Verfolgung 3. Verwalten von Änderungen 6. Qualitätssicherung von Anforderungen

111 114 Priorisierung Ist nötig bei o o o o o harten Terminen. harten Preisobergrenzen. Beschaffung. Zeitliche und finanzielle Restriktionen erlauben es meist nicht, alle Anforderungen mit der gleichen Intensität zu beachten. Festlegen von Inhalt und Umfang der Inkremente bei inkrementeller Entwicklung. Releaseplanung bei der Weiterentwicklung bestehender Systeme.

112 Techniken zur Priorisierung: IEEE o Eine Kriterien- Klassifikation Mandatory n Anforderungen müssen umgesetzt werden, um den Erfolg zu gewährleisten. Optional n Anforderungen, die zwar wichtig sind, deren vereinzeltes Fehlen im System den Erfolg nicht gefährdet. Nice- to- have n Anforderungen, deren Fehlen im System den Erfolg des Systems nicht gefährdet. Beobachtung: Meist starke Häufung in der Klasse Mandatory

113 Inhalt Einführung 2. Begriffe 3. Dokumentation 4. Erhebung von Anforderungen 5. Management von Anforderungen 1. Priorisierung 2. Verfolgung 3. Verwalten von Änderungen 6. Qualitätssicherung von Anforderungen

114 Nachvollziehbarkeit von Anforderungen (1) 119 o Ziel Beherrschen der Evolution der Anforderungen. n Anforderungen stabil halten. n Veränderung kontrolliert zulassen. o Maßnahme Konfigurationsmanagement für Anforderungen n Anforderungen einzeln identifizierbar machen. n Geordneter Änderungsprozess. n Klare Zuständigkeiten und Verantwortlichkeiten. n Rückverfolgbarkeit aller Entscheidungen und Änderungen. engl.: Traceability

115 120 Nachvollziehbarkeit von Anforderungen (2) o Im Entwicklungsprozess nachvollziehen des Ursprungs der Anforderungen der Verwendung der Anforderung In- Traceability Vorgelagerte Artefakte Anforderungen Nachgelagerte Artefakte Pre-Traceability Post-Traceability

116 Nachvollziehbarkeit von Anforderungen (3) 121 Quelle: Robert Brcina: Arbeiten zur Verfolgbarkeit und Aspekte des Verfolgbarkeitsprozesses, 2006 (vereinfacht) Horizontale Verfolgbarkeit (zwischen verschiedenen Obj.) Vertikale Verfolgbarkeit (zwischen gleichartigen Obj.)

117 Nachvollziehbarkeitsmatrizen 123 U: uses, benutzt R: relates, bezieht sich auf

118 Inhalt Einführung 2. Begriffe 3. Dokumentation 4. Erhebung von Anforderungen 5. Management von Anforderungen 1. Priorisierung 2. Verfolgung 3. Verwalten von Änderungen 6. Qualitätssicherung von Anforderungen

119 125 Bearbeitung von Änderungsanträgen / Change Request Change control board Projekt manager Auswirkungsanalyse Auslöser: CR (change request) Aufwandsermittlung Beurteilung der Änderung Kosten/Nutzen- Analyse [Annahme der Änderung] [Ablehnung der Änderung] Priorisierung der Anforderungsänderung Zuordnung der Änderung zu Änderungsprojekt Kommunikation der Ablehnung Pohl, Rupp: Basiswissen Requirements-Engineering, 2009 Folgeaktivität: Umsetzung (oder nichts!)

120 Inhalt Einführung 2. Begriffe 3. Dokumentation 4. Erhebung von Anforderungen 5. Management von Anforderungen 6. Qualitätssicherung von Anforderungen

121 Qualitätssicherung von Anforderungen 127 o Abweichungen von der geforderten Qualität der Spezifikation feststellen. o Möglichst viele Fehler, Lücken, Unklarheiten, Mehrdeutigkeiten etc. finden und beheben. o Konflikte zwischen den Wünschen / Forderungen verschiedener beteiligter Personen erkennen und lösen. o Verdeckte Wünsche / Erwartungen / Befürchtungen erkennen und thematisieren.

122 Anforderungsprüfung 128 o Einbeziehen aller Stakeholder o Zeitpunkt(e): Fortlaufend, d.h. begleitend zur Erstellung der Spezifikation, z. B. Autor- Kritiker- Zyklus. Wenn die Spezifikation fertig ist (aber noch genug Zeit bleibt, die gefundenen Mängel zu beheben).

123 129 Anforderungsprüfung o Review Stellungnahme: Expertise einer3. Person. Walkthrough: Autor führtdurch dasreview. Inspektion: Gutachter prüfen eigenständig, tragen in Sitzung Befunde zusammen. Autor- Kritiker- Zyklus: Kunde liestund kritisiert, bespricht Befunde mit Autor. o Prototyp Kunden wirdablauf (grafisch) vorgeführt. o Prüf- und Analysemittel in Werkzeugen Einsatz bei werkzeuggestützter Erstellung der Spezifikation n Auffinden von Lücken undwidersprüchen. Das Mittel der Wahl zur Prüfung von Spezifikationen

124 Prototyping 130 o Wofür? o Wie? bei interaktiven Systemen Horizontaler Prototyp o Warum? Fördert die Kommunikation mit dem Benutzer Fehlende Anforderungen werden identifiziert Missverständnisse werden entdeckt Reduziert Entwicklungsrisiko

125 Paper Prototyping Low Fidelity 131 o Eingabemasken auf Papier Keine/Wenig Ähnlichkeit zum fertigen Produkt o Vorteile Preiswert, schnell, technisch einfaches Verfahren Kommunikativ Änderungsvorschläge können direkt umgesetzt werden o Nachteile Ohne Funktionalität Nicht weiter nutzbar Nicht alle Ideen technisch umsetzbar

126 Computer- gestütztes Prototyping High Fidelity 132 o Hohe Ähnlichkeit zum fertigen Produkt z.b. pidoco.com o Vorteile Mehr Funktionalität User kann mit Prototyp interagieren o Nachteile Teuer, aufwändig Änderungen nur mit größerem Aufwand mögliche Verwechslung mit Zielsystem

127 7 Sünden der Anforderungsspezifikation nach Myers 133 o Irrelevante Information o Unvollständigkeit o Über- Spezifikation ( Design- Entscheidungen) o Inkonsistenzen o Mehrdeutigkeit o Vorwärts- Referenzen o Nicht testbare Anforderungen

128 134

129 User Stories 135 o Funktionale Beschreibung was für den Benutzer/Auftraggeber des (Software) Systems nützlich ist. o Eine Schilderung, wie die Benutzer mit der Software interagieren, die erstellt werden soll. Beschreibung aus der Sicht des Kunden. Beschreibt, was die Software für den Kunden tut. o User Stories setzen sich aus 3 Aspekten zusammen: Beschreibung der Story für die Planung und als Erinnerung. Gespräche über die Story, um die Details der Story herauszuarbeiten. Tests, welche Details beschreiben und dokumentieren und die hergenommen werden können, um entscheiden, on die Story vollständig ist. Confirmation Card Conversation

130 User- Stories: Was sollten sie sein und was nicht. 136 o Sie sollten... genau eine Sache beschreiben, die die Software für den Kunden erledigen soll.... in einer für den Kunden verständlichen Sprache geschrieben sein.... vom Kunden selbst formuliert werden.... kurz sein (max. 3 Sätze) o Sie sollten nicht... in lange Erläuterungen ausarten.... Fachbegriffe enthalten, mit denen der Kunde nichts anfangen kann... Bezug nahmen auf spezifische Technologien.

131 User Story: Beispiele 137 o BigMoneyJobs: Eine Web- Seit zum Anbieten und Suchen von Jobs. Titel: Lebenslauf veröffentlichen. Beschreibung: Der Benutzer kann seinen Lebenslauf über die Web-Site veröffentlichen. Titel: Job suchen. Beschreibung: Der Benutzer kann über die Web-Site nach einem Job suchen. Titel: Jobs anbieten. Beschreibung: Ein Unternehmen kann über die Web-Site einen Stelle anbieten. Titel: Lebenslauf veröffentlichen. Beschreibung: Der Benutzer kann über die Web-Site festlegen, wer seinen Lebenslauf einsehen darf.

132 User Stories: zu wenige Details? 138 o Der Benutzer kann über die Web- Site nach einem Job suchen. Kann man allein damit beginnen zu programmieren und zu testen? Wo sind die Details? Was ist mit den folgenden Fragen: n Nach welchen Werten kann der Benutzer suchen? n Region? Stadt? Berufsbezeichnung? Schlüsselwörter? n Muss sich der Benutzer auf der Web- Site registrieren? n Können Suchparameter gespeichert werden? n Welche Informationen werden bei passenden Job- Angeboten angezeigt? Viele dieser Details lassen sich durch weitere User Stories beschreiben: Mehr User Stories sind zu langen User Stories vorzuziehen. Beispiel: Die gesamte BigMoneyJobs- Seite kann man die 2 Stories zerlegen: n Ein Benutzer kann nach einem Job suchen. n Ein Unternehmen kann ein Jobangebot veröffentlichen.

133 User Stories: wie umfangreich? 139 o Faustregel: User Stories sollten sich in ½ Tag bis 2 Wochen von einem Programmierer (- paar) programmieren und testen lassen. o Zu große Stories werden als Monumentalwerke (epics) bezeichnet und lassen sich leicht aufteilen: o Beispiel: Ein Benutzer kann nach einem Job suchen. n Ein Benutzer kann nach Jobs suchen über Attribute wie Ort, Angabe eines Gehaltsbereichs, Firmenname und Datum, zu dem das Stellenangebot veröffentlicht wurde. n Ein Benutzer kann Informationen zu jeder Stelle, die zu den angegeben Kriterien passt, ansehen. n Ein Benutzer kann zu jedem Unternehmen, das ein Stellenangebot veröffentlicht hat, detaillierte Informationen ansehen.

134 User Stories: wie detailliert? 140 o o o o Stories werden nicht bis ins letzte Detail verfeinert. o Ein Benutzer kann Informationen zu jeder Stelle, die zu den angegeben Kriterien passt, ansehen. Das ist eine vernünftige und realistische Story, die nicht weiter zerlegt wird. Weitere Informationen ergeben sich durch die Kommunikation mit dem Kunden. Wie umfangreich muss eine Story sein? è Ergibt sich aus Hinweisen zu (Akzeptanz- )Tests (à Rückseite der Story- Card) o Versuch mit leerer Job- Beschreibung. o Versuch mit ganz langer Job- Beschreibung. o Versuch ohne Gehaltsangabe. o Versuch mit sechsstelliger Gehaltsangabe. o Die Tests können jederzeit ergänzt oder entfernt werden. Sie sind ein ergänzender Hinweis auf die Erwartungen des Kunden.

135 Customer Team 141 o Idealfall: Der Product Owner (ein Mitarbeiter des Auftraggebers) ist während der gesamten Projektlaufzeit mit dabei und erledigt die folgenden Aufgaben: Priorisiert die Aufgaben für die Entwickler (Sprint Backlog). Beantwortet allwissend alle Fragen der Entwickler. Verwendet (quasi als Tester ) den jeweiligen Stand der Software. Schreibt alle User Stories. Paradies o Realität (auch im SEP): Customer Team Dazu gehören alle, die sicherstellen, dass die Software die beabsichtigten Benutzeranforderungen erfüllt. Tester + Produkt Manager + (echte) Anwender + Interaktions- Designer

136 Customer Team: Aufgabe 142 o Schreibt die Stories, weil die Sprache der Story die Domänen- Sprache ist und kein Technikjargon. das Customer- Team am besten das Produktverhalten beschreiben kann.

137 Priorisierung von Stories 143 o Für Customer- Team Wichtigkeit eines Features für eine breite Basis von Benutzern/Kunden. Wichtigkeit eines Features für eine schmale Basis von wichtigen Benutzern/Kunden. Zusammenhang der Story mit anderen Stories o Für Entwickler Technisches Risiko. Ergänzung einer anderen Story. è Das Customer- Team entscheidet nach Rücksprache mit den Entwicklern und unter Berücksichtigung der Kosten.

138 Story- Points 144 o Kosten einer Story werden von den Entwicklern geschätzt. o Die Schätzung wird in Story- Points gemessen. o Story- Point: beschreibt die Größe und die Komplexität einer Story im Vergleich zu anderen Stories also keine absolute Angabe in beispielsweise einem Geldbetrag. o Maß der Entwicklungsgeschwindgkeit = Story- Points

Herkunft von Anforderungen

Herkunft von Anforderungen Herkunft von Verhaltensanforderungen (funktionale ) definieren die Dienste, die das System zur Verfügung stellen soll, die Reaktionen des Systems auf bestimmte Eingaben und das Verhalten in besonderen

Mehr

Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert Vgl. Kapitel 4/5 aus Basiswissen Requirements Engineering, Klaus Pohl,

Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert Vgl. Kapitel 4/5 aus Basiswissen Requirements Engineering, Klaus Pohl, Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert Vgl. Kapitel 4/5 aus Basiswissen Requirements Engineering, Klaus Pohl, Chris Rupp Nachdem die Projekt-Vision und die Stakeholder

Mehr

9 Anforderungsspezifikation mit natürlicher Sprache

9 Anforderungsspezifikation mit natürlicher Sprache 9 Anforderungsspezifikation mit natürlicher Sprache 9.1 Vorteile und Probleme + Leicht erstellbar + Von allen Beteiligten ohne vorgängige Schulung lesbar + Ausdrucksmächtig Fehlerträchtig mehrdeutig unklar

Mehr

Requirements Engineering I

Requirements Engineering I Martin Glinz Requirements Engineering I Kapitel 3 Der Spezifikationsprozess Universität Zürich Institut für Informatik 2006 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe sind für den

Mehr

Requirements Engineering

Requirements Engineering Klaus Pohl Chris Rupp Basiswissen Requirements Engineering Aus- und Weiterbildung zum»certified Professional for Requirements Engineering«Foundation Level nach IREB-Standard 4., überarbeitete Auflage dpunkt.vertag

Mehr

6 Requirements Engineering Prozesse. 6.1 Hauptprozesse. Spezifikationsprozess Anforderungen... gewinnen analysieren und dokumentieren prüfen

6 Requirements Engineering Prozesse. 6.1 Hauptprozesse. Spezifikationsprozess Anforderungen... gewinnen analysieren und dokumentieren prüfen 6 Requirements Engineering Prozesse 6.1 Hauptprozesse Spezifikationsprozess... gewinnen analysieren und dokumentieren prüfen Verwaltungsprozess ( Kapitel «Verwaltung von»)... freigeben ändern rückverfolgen

Mehr

Anwendungsfall. Das Anwendungsfall-Diagramm (Use-Cases/Use-Case Diagramm) Die Anwendungsfall-Beschreibung. Dr. Beatrice Amrhein

Anwendungsfall. Das Anwendungsfall-Diagramm (Use-Cases/Use-Case Diagramm) Die Anwendungsfall-Beschreibung. Dr. Beatrice Amrhein Anwendungsfall Das Anwendungsfall-Diagramm (Use-Cases/Use-Case Diagramm) Die Anwendungsfall-Beschreibung Dr. Beatrice Amrhein Kundenbedürfnisse Fertigungs-System 2 Erste Schritte: Kundenbedürfnisse erfassen

Mehr

Testen mit Use Cases. Chris Rupp Dr. Stefan Queins

Testen mit Use Cases. Chris Rupp Dr. Stefan Queins Testen mit Use Cases Chris Rupp Dr. Stefan Queins Das Problem Requirements- Engineering Was kann passieren? Was ist das gewünschte Verhalten? Was soll ich testen? Welche Eingaben benötigt mein Testpfad?

Mehr

Prüfung und Unterstützung 26 Prüfung und Abnahme 26.1 Prüfen von Anforderungen. Worum geht es?

Prüfung und Unterstützung 26 Prüfung und Abnahme 26.1 Prüfen von Anforderungen. Worum geht es? Teil IV: Prüfung und Unterstützung 26 Prüfung und Abnahme 26.1 Prüfen von Anforderungen Worum geht es? Abweichungen von der geforderten Qualität der Spezifikation feststellen Möglichst viele Fehler, Lücken,

Mehr

ANFORDERUNGSANALYSE UND SPEZIFIKATION TEIL 2

ANFORDERUNGSANALYSE UND SPEZIFIKATION TEIL 2 3. Kapitel ANFORDERUNGSANALYSE UND SPEZIFIKATION TEIL 2 Software Engineering Prof. Dr. Wolfgang Schramm Übersicht 1 1. Einführung in das Software Engineering 2. Softwareprozesse 3. Anforderungsanalyse

Mehr

Nicht-funktionale Anforderungen

Nicht-funktionale Anforderungen Juristisches IT-Projektmanagement Michael Braun Nicht-funktionale Anforderungen 12.1.2016 Nicht-funktionale Anforderungen 12.1.2016 Folie 1 Unterscheidung Anforderungen an ein Software System Funktionale

Mehr

SOFTWARE ENGINEERING BESPRECHUNG ÜBUNG2. Anforderungsspezifikation und GWT Tutorien

SOFTWARE ENGINEERING BESPRECHUNG ÜBUNG2. Anforderungsspezifikation und GWT Tutorien SOFTWARE ENGINEERING BESPRECHUNG ÜBUNG2 Anforderungsspezifikation und GWT Tutorien TEACHING TEAM Paul Muntean muntean@ifi.uzh.ch Martina Rakaric martina.rakaric@gmail.com 2 ABGABE Abgabe OLAT Erlaubte

Mehr

Die Foundation-Phase Kombination von RE-Techniken zum Projektstart. Martin Kleckers, Agile Coach Berlin, 26. SEPTEMBER 2018

Die Foundation-Phase Kombination von RE-Techniken zum Projektstart. Martin Kleckers, Agile Coach Berlin, 26. SEPTEMBER 2018 Die Foundation-Phase Kombination von RE-Techniken zum Projektstart Martin Kleckers, Agile Coach Berlin, 26. SEPTEMBER 2018 440 m Umsatz in 2017 + 2.500 Glückliche Kunden 1992 Gegründetes Familienunternehmen

Mehr

Anwendungsfalldiagramm UseCaseDiagramm

Anwendungsfalldiagramm UseCaseDiagramm Anwendungsfalldiagramm UseCaseDiagramm Notation und Beispiele Prof. DI Dr. Erich Gams htl wels.e.gams@eduhi.at UML Seminar HTL-Wels 2010 Anwendungsfall und SE Prozess Ein Anwendungsfalldiagramm ist ein

Mehr

DGQ Regionalkreis Hamburg Anforderungsmanagement ins SW-Projekten. 08. Juni 2011

DGQ Regionalkreis Hamburg Anforderungsmanagement ins SW-Projekten. 08. Juni 2011 DGQ Regionalkreis Hamburg Anforderungsmanagement ins SW-Projekten 08. Juni 2011 1 Heinrich Dreier hd@3er-consult.de +49 (0)176 62635052 DGQ- Mitglied Q-Manager Navigationsentwicklung freiberuflicher technischer

Mehr

Objektorientierte Analyse (OOA) Inhaltsübersicht

Objektorientierte Analyse (OOA) Inhaltsübersicht Inhaltsübersicht Einführung Anforderungen an die UML-Diagramme Verhalten: Use-Case-Diagramm Verhalten: Aktivitätsdiagramm Verhalten: Zustandsautomat Struktur: Klassendiagramm Seite 1 Einführung In der

Mehr

Abläufe bei der Anforderungsanalyse. Grundlagen des Software Engineerings

Abläufe bei der Anforderungsanalyse. Grundlagen des Software Engineerings Abläufe bei der Anforderungsanalyse Grundlagen des Software Engineerings Lernziele } Die prinzipiellen Aufgaben bei der Anforderungsanalyse und deren Zusammenhänge verstehen } Mit einigen Techniken der

Mehr

Requirements Engineering I. Anforderungsspezifikation mit natürlicher Sprache

Requirements Engineering I. Anforderungsspezifikation mit natürlicher Sprache Martin Glinz Requirements Engineering I Kapitel 5 Anforderungsspezifikation mit natürlicher Sprache Universität Zürich Institut für Informatik 2006 Martin Glinz. Alle Rechte vorbehalten. Speicherung und

Mehr

Benuterdokumentation als Anforderungsspezifikation der Versuch einer konstruktiven Provokation

Benuterdokumentation als Anforderungsspezifikation der Versuch einer konstruktiven Provokation Benuterdokumentation als Anforderungsspezifikation der Versuch einer konstruktiven Provokation SOPHIST GROUP Vordere Cramergasse 11 13 90478 Nürnberg Germany Phone: +49(911) 40 900 0 Fax: +49(911) 40 900

Mehr

Software Engineering

Software Engineering Software Engineering Besprechung zur Uebung 2 (Anforderungsspezifikation) Reinhard Stoiber HS 07 Allgemeines Gruppen 3er Gruppen: 12 2er Gruppen: 0 1er Gruppen: 5 Weitere 3er Gruppen könnten noch geformt

Mehr

22. Januar Gruppe 2: TOPCASED

22. Januar Gruppe 2: TOPCASED 22. Januar 2008 Aufgabenstellung Modellgetriebene Softwareentwicklung auf Basis von am Beispiel eines Seminarverwaltungssystems Ziel Entwicklungsprozess Anforderungen & Codegenerierung Modellierung & Templates

Mehr

Software Engineering. 3. Anforderungsanalyse. Franz-Josef Elmer, Universität Basel, WS 2006/07

Software Engineering. 3. Anforderungsanalyse. Franz-Josef Elmer, Universität Basel, WS 2006/07 Software Engineering 3. Anforderungsanalyse Franz-Josef Elmer, Universität Basel, WS 2006/07 Software Engineering: 3. Anforderungsanalyse 2 Definitionen Anforderungen (Requirements): Beschreibung aller

Mehr

Softwareentwicklung und Projektmanagement

Softwareentwicklung und Projektmanagement Softwareentwicklung und Projektmanagement Fr. Hauser, WS 2018/2019 Wiederholung 2 5 6 Agenda 1. Einführung in die Softwareentwicklung 7 1. Einführung in die Softwareentwicklung Softwaretechnik / Software

Mehr

Requirements Engineering I. Verwalten von Anforderungen

Requirements Engineering I. Verwalten von Anforderungen Martin Glinz Requirements Engineering I Kapitel 14 Verwalten von Anforderungen Universität Zürich Institut für Informatik 2006-2010 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für

Mehr

Requirements Engineering

Requirements Engineering Lill, Meitner, Föhrweiser, Spisländer FAU Erlangen-Nürnberg Requirements Engineering 1 / 13 Requirements Engineering Raimar Lill Matthias Meitner David Föhrweiser Marc Spisländer Lehrstuhl für Software

Mehr

Mit den 5 Prinzipien der Lebendigkeit für Anforderungen komplexe Systeme meistern. Dr.-Ing. Thaddäus Dorsch, HOOD GmbH,

Mit den 5 Prinzipien der Lebendigkeit für Anforderungen komplexe Systeme meistern. Dr.-Ing. Thaddäus Dorsch, HOOD GmbH, Mit den 5 Prinzipien der Lebendigkeit für Anforderungen komplexe Systeme meistern Dr.-Ing. Thaddäus Dorsch, HOOD GmbH, 29.03.2017, REConf2017 2 KLASSISCHES REQUIREMENTS ENGINEERING Kundenanforderungen

Mehr

Requirements Engineering

Requirements Engineering Requirements Engineering Josef Adersberger Marc Spisländer Lehrstuhl für Software Engineering Friedrich-Alexander-Universität Erlangen-Nürnberg 10. Dezember 2008 Adersberger, Spisländer FAU Erlangen-Nürnberg

Mehr

Lehrplan: Business Analyse/ Requirements Engineering (BA- RE)

Lehrplan: Business Analyse/ Requirements Engineering (BA- RE) Lehrplan: Business Analyse/ Requirements Engineering (BA- RE) Gliederung 1 Grundlagen der industriellen So@ware Entwicklung 2 Unternehmens- und Geschä@sprozessmodellierung 3 Grundlagen und Begriffe des

Mehr

Requirements Engineering I. Der Spezifikationsprozess!

Requirements Engineering I. Der Spezifikationsprozess! Norbert Seyff Requirements Engineering I Zusammenfassung und Erweiterung Der Spezifikationsprozess! 2009, 2012 Martin Glinz und Norbert Seyff. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den

Mehr

Anforderungen. Was ist eine Anforderung? Formulierungsschablonen Das Anforderungsdiagramm Glossar. Dr. Beatrice Amrhein

Anforderungen. Was ist eine Anforderung? Formulierungsschablonen Das Anforderungsdiagramm Glossar. Dr. Beatrice Amrhein Anforderungen Was ist eine Anforderung? Formulierungsschablonen Das Anforderungsdiagramm Glossar Dr. Beatrice Amrhein Was ist eine Anforderung? 2 Anforderungen an ein System Funktionale Anforderungen o

Mehr

Softwaretechnik 2015/2016

Softwaretechnik 2015/2016 Softwaretechnik 2015/2016 PST Lehrstuhl Prof. Dr. Matthias Hölzl HAUPT-/ BACHELOR- SEMINAR ADAPTIVE SYSTEME PST Joschka PROF. DR. Rinke WIRSING 14. JUNI 2009 VORNAME NAME AGENDA Übung 11: 14.01.2016 Schon

Mehr

Softwareanforderungsanalyse

Softwareanforderungsanalyse Softwareanforderungsanalyse Vorgehen, Modellstruktur und Spezifikationsdokument - Ein Fazit Burkhardt Renz THM, Fachbereich MNI Wintersemester 208/9 Übersicht Vorgehen Struktur des Modells Metamodell Generierung

Mehr

Inhaltsverzeichnis. Business Analysis und Requirements Engineering

Inhaltsverzeichnis. Business Analysis und Requirements Engineering sverzeichnis zu Business Analysis und Requirements Engineering von Peter Hruschka ISBN (Buch): 978-3-446-43807-1 ISBN (E-Book): 978-3-446-43862-0 Weitere Informationen und Bestellungen unter http://www.hanser-fachbuch.de/978-3-446-43807-1

Mehr

Gute User Stories schreiben reicht nicht Requirements Engineering-Bedarf in agilen Projekten. Olga Boruszewski,

Gute User Stories schreiben reicht nicht Requirements Engineering-Bedarf in agilen Projekten. Olga Boruszewski, Gute User Stories schreiben reicht nicht Requirements Engineering-Bedarf in agilen Projekten Olga Boruszewski, 23.11.2017 http://www.continental.de Tires Division Einführung Erfahrungsbericht zu Requirements

Mehr

Das diesem Dokument zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkennzeichen

Das diesem Dokument zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkennzeichen Das diesem Dokument zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkennzeichen 1OH2100 gefördert. Die Verantwortung für den Inhalt dieser Veröffentlichung

Mehr

1.1 Spezifikation und Entwurf im Software-Lebenslauf Lineares Prozessmodell:

1.1 Spezifikation und Entwurf im Software-Lebenslauf Lineares Prozessmodell: 1 Einführung und Überblick 1.1 Spezifikation und Entwurf im Software-Lebenslauf Lineares Prozessmodell: Anstoß Auftrag Projekt planen Anforderungen spezifizieren Lieferung Architektur entwerfen System

Mehr

Lastenheft (Universität Paderborn, Softwaretechnikpraktikum SS2006)

Lastenheft (Universität Paderborn, Softwaretechnikpraktikum SS2006) Lastenheft (Universität Paderborn, Softwaretechnikpraktikum SS2006) Alles, was in dieser Schriftart gesetzt ist, dient nur zur Erläuterung und sollte im fertigen Lastenheft nicht mehr auftauchen! Der Umfang

Mehr

Requirements Engineering

Requirements Engineering Seite 1 Requirements Engineering Seite 2 Zielsetzung Systematischer Ansatz, Anforderungen zu Ermitteln Analysieren Organisieren Dokumentieren Mittel, um gemeinsame Basis zwischen Kunde und Entwickler zu

Mehr

7 Gewinnung von Anforderungen. 7.1 Voraussetzungen. Beteiligte kennen

7 Gewinnung von Anforderungen. 7.1 Voraussetzungen. Beteiligte kennen 7 Gewinnung von Anforderungen 7.1 Voraussetzungen Beteiligte kennen Beteiligtenanalyse (stakeholder analysis): Wer hat in welcher Rolle hat mit dem zu erstellenden System zu tun? Wer kann/soll/darf/muss

Mehr

Usability. Katja Fuhrmann FG Software Engineering Leibniz Universität Hannover

Usability. Katja Fuhrmann FG Software Engineering Leibniz Universität Hannover Usability Katja Fuhrmann katja.fuhrmann@inf.uni-hannover.de FG Software Engineering Leibniz Universität Hannover 21.12.2016 Katja Fuhrmann Wissenschaftliche Mitarbeiterin am FG Software Engineering Usability

Mehr

Tamagotchi-Spezifikation in UML

Tamagotchi-Spezifikation in UML Tamagotchi-Spezifikation in UML Christian Becker Steffen Glomb Michael Graf Gliederung Grundlagen Notation Werkzeug Modellierung Details der Spezifikation Erfahrungen Beurteilung von Notation und Werkzeug

Mehr

Software- und Systementwicklung

Software- und Systementwicklung Software- und Systementwicklung Seminar: Designing for Privacy 11.11.2009 Moritz Vossenberg Inhalt Vorgehensmodelle Wasserfallmodell V-Modell Phasen (Pflichtenheft) UML Klassendiagramm Sequenzdiagramm

Mehr

SCRUM DIE GRUNDLEGENDE AGILE METHODE

SCRUM DIE GRUNDLEGENDE AGILE METHODE 17.03.2016 CONTRACT KG / All rights reserved Seite 1 SCRUM DIE GRUNDLEGENDE AGILE METHODE reserved Seite 2 Ziele der Anwendung von Scrum Höhere Reaktionsfähigkeit auf sich ändernde Kundenanforderungen

Mehr

Software Engineering Projekt. Pflichtenheft

Software Engineering Projekt. Pflichtenheft Software Engineering Projekt Pflichtenheft Ziele eines Pflichtenheftes Eine Festsetzung der Leistung und des Umfangs der Software Anforderungen Zugesicherter Funktionsumfang Zugesicherter Produktumgebung

Mehr

Requirements Engineering

Requirements Engineering Ident-Nr styp (z.b. Performance, GUI,..) Titel der Beschreibung identifizieren Messkriterien zur Erfüllbarkeit Komplexität in der Realisierung/Abnahme Aufwand bewerten Priorität (hoch, mittel, klein) Realisierungstermin

Mehr

Übungsaufgaben Softwaretechnologie

Übungsaufgaben Softwaretechnologie HTW Dresden Fakultät Elektrotechnik Übungsaufgaben Softwaretechnologie Gudrun Flach February 21, 2017 - Aufgaben aus : Übungen zur Vorlesung Softwaretechnologie (WS 2014/15), Uni Bonn Aufgabe 1 (Klassendiagramm)

Mehr

Software Engineering. 5. Architektur

Software Engineering. 5. Architektur Software Engineering 5. Architektur Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz Implementierung Konfigurationsmanagement

Mehr

Usability Engineering. Kapitel 3. Usability Engineering Lebenszyklus & Methoden der Usability Evaluation

Usability Engineering. Kapitel 3. Usability Engineering Lebenszyklus & Methoden der Usability Evaluation Fachhochschule Schmalkalden, Prof. Dr. rer. pol. Thomas Urban Kapitel 3 Lebenszyklus & Methoden der Usability Evaluation Gliederung 1 Einführung 2 Wahrnehmungspsychologie 3 Lebenszyklus 3.1 3.1.1 Nutzerprofile

Mehr

Inhaltsverzeichnis. 1 Einführung Warum dieses Buch? Struktur und Aufbau Dankeschön Feedback 5

Inhaltsverzeichnis. 1 Einführung Warum dieses Buch? Struktur und Aufbau Dankeschön Feedback 5 1 Einführung 1 1.1 Warum dieses Buch? 2 1.2 Struktur und Aufbau 3 1.3 Dankeschön 5 1.4 Feedback 5 2 Beispiel: Scrumcoaches.com 7 2.1 Das Projekt 8 2.2 Der Entwicklungsprozess 9 2.3 Die Beteiligten 10 2.4

Mehr

Vorlesung Software-Engineering I

Vorlesung Software-Engineering I Vorlesung Software-Engineering I im 3. und 4. Semester 09. SW-Architektur - Dokumentation Architektur-Review Wir treten einen Schritt zurück und betrachten nochmal das Ganze. Sind wir noch auf dem richtigen

Mehr

8 Grundsätze der Darstellung von Anforderungen

8 Grundsätze der Darstellung von Anforderungen 8 Grundsätze der Darstellung von Anforderungen Darzustellende Aspekte Funktionalität Attribute: Leistungen, Qualitäten, Randbedingungen Freiheitsgrade in der Darstellung Wahl der Mittel Art der Gliederung

Mehr

Informatik IIa: Modellierung

Informatik IIa: Modellierung Informatik IIa: Modellierung Frühlingssemester 2014 Übung 6: Petrinetze, Interaktionsmodelle, Systemmetaphern, Abstraktion Kapitel 7, 10, 11, 12 Ausgabe: 02.05.2014 Abgabe: 16.05.2014 Name: Matrikelnummer:

Mehr

Business Analysis Body of Knowledge BABOK v3. Konzepte Scope Struktur. Ursula Meseberg microtool GmbH Berlin

Business Analysis Body of Knowledge BABOK v3. Konzepte Scope Struktur. Ursula Meseberg microtool GmbH Berlin Business Analysis Body of Knowledge BABOK v3 Konzepte Scope Struktur Ursula Meseberg microtool GmbH Berlin 1980 Mach mal Systemanalyse Tom DeMarco, Structured Analysis and System Specification, 1978, p

Mehr

Vom Störer zum Vermittler

Vom Störer zum Vermittler Vom Störer zum Vermittler Der Mensch im Mittelpunkt REConf 01. März 2016 Amin Soesanto, Jesko Schneider Agenda Wir stellen Folgendes vor 1. Der Mensch als Anforderungsquelle 2. Anforderungsvermittlung

Mehr

Projektmanagement. Das Scrum - Framework. Version: 5.0 Stand: Autor: Dr. Olaf Boczan

Projektmanagement. Das Scrum - Framework. Version: 5.0 Stand: Autor: Dr. Olaf Boczan Projektmanagement Das Scrum - Framework Version: 5.0 Stand: 28.05.2017 Autor: Dr. Olaf Boczan Lernziel Sie können mit eigene Worten das Framework Scrum beschreiben. Sie können die Rollen, Aktivitäten und

Mehr

MDRE die nächste Generation des Requirements Engineerings

MDRE die nächste Generation des Requirements Engineerings MDRE die nächste Generation des Requirements Engineerings Tom Krauß, GEBIT Solutions GmbH Copyright 2007 GEBIT Solutions Agenda Requirements Engineering heute eine Bestandsaufnahme Modell-Driven Requirements

Mehr

Mobile Momente: Die Zukunft des Requirements Engineering. Ursula Meseberg microtool GmbH, Berlin

Mobile Momente: Die Zukunft des Requirements Engineering. Ursula Meseberg microtool GmbH, Berlin Mobile Momente: Die Zukunft des Requirements Engineering Ursula Meseberg microtool GmbH, Berlin 1984 Strukturierte Analyse & ER-Modellierung UML /SysML UML /SysML sind noch kein Requirements Engineering

Mehr

Unified. Copyright Adriano Gesué UML 2.0 UML 1.4 UML 1.3 UML 1.2 UML 1.1 UML 1.0 UML 0.9. Method 0.8

Unified. Copyright Adriano Gesué UML 2.0 UML 1.4 UML 1.3 UML 1.2 UML 1.1 UML 1.0 UML 0.9. Method 0.8 Literatur Martin Fowler and Kendall Scott: UML Distilled: Applying the Standard Object Modeling Language. Addison-Wesley 1997. James Rumbaugh, Ivar Jacobson, and Grady Booch: The Unified Language Reference

Mehr

WARUM SICH S SCHWER MACHEN, WENN ES AUCH EINFACH GEHT? Dr. Sebastian Adam, Özgür Ünalan München,

WARUM SICH S SCHWER MACHEN, WENN ES AUCH EINFACH GEHT? Dr. Sebastian Adam, Özgür Ünalan München, WARUM SICH S SCHWER MACHEN, WENN ES AUCH EINFACH GEHT? Dr. Sebastian Adam, Özgür Ünalan München, 02.03.2016 KOMPLEXITÄT IM REQUIREMENTS ENGINEERING 2 zunehmende Kompliziertheit von RE-Methoden KOMPLIZIERT

Mehr

Software-Engineering

Software-Engineering FH Wedel Prof. Dr. Sebastian Iwanowski SWE44 Folie 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 4: Systemanalyse Teil 4: ARIS FH Wedel Prof. Dr. Sebastian Iwanowski SWE44 Folie 2 CASE-Tools

Mehr

Basiswissen Requirements Engineering

Basiswissen Requirements Engineering Klaus Pohl Chris Rupp Basiswissen Requirements Engineering Aus- und Weiterbildung zum»certified Professional for Requirements Engineering«Foundation Level nach IREB-Standard Г5 I dpunkt.verlag Inhalt Die

Mehr

Drei Kennzeichen eines Projekts

Drei Kennzeichen eines Projekts Drei Kennzeichen eines Projekts Erreichen eines vorher festgesetzten Ziels in einem bindenden Zeitplan mit bestimmten Ressourcen Budget Mitarbeitern Hilfsmitteln 2/ 3/ Ziel Zeitplan Ressourcen Ein Projekt

Mehr

WARUM SICH S SCHWER MACHEN, WENN ES AUCH EINFACH GEHT? Dr. Sebastian Adam, Özgür Ünalan München,

WARUM SICH S SCHWER MACHEN, WENN ES AUCH EINFACH GEHT? Dr. Sebastian Adam, Özgür Ünalan München, WARUM SICH S SCHWER MACHEN, WENN ES AUCH EINFACH GEHT? Dr. Sebastian Adam, Özgür Ünalan München, 02.03.2016 KOMPLEXITÄT IM REQUIREMENTS ENGINEERING 2 zunehmende Kompliziertheit von RE-Methoden KOMPLIZIERT

Mehr

MEHR REQUIREMENTS, WENIGER ENGINEERING! WIE REQSUITE HILFT DAS RE ZU VERSCHLANKEN

MEHR REQUIREMENTS, WENIGER ENGINEERING! WIE REQSUITE HILFT DAS RE ZU VERSCHLANKEN Monitoring R eqsuite -AdminClient Prozessverantwortlicher Konfiguration Anforderungen R eqsuite -Backend Import / Export Arbeitsassistenz Projektbeteiligte R eqsuite -UserClient MEHR REQUIREMENTS, WENIGER

Mehr

Das diesem Dokument zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkennzeichen

Das diesem Dokument zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkennzeichen Das diesem Dokument zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkennzeichen 16OH21005 gefördert. Die Verantwortung für den Inhalt dieser

Mehr

UML (Unified Modelling Language) von Christian Bartl

UML (Unified Modelling Language) von Christian Bartl UML (Unified Modelling Language) von Inhaltsverzeichnis Inhaltsverzeichnis... 2 1 UML Unified Modelling Language... 3 2 Diagrammtypen... 3 2.1 Aktivitätsdiagramm... 3 2.1.1 Notation... 4 2.1.2 Beispieldiagramm...

Mehr

Projektmanagement und Softwareentwicklung. Nina Stodolka, WS2017/2018

Projektmanagement und Softwareentwicklung. Nina Stodolka, WS2017/2018 Projektmanagement und Softwareentwicklung Nina Stodolka, WS2017/2018 Organisatorisches Montags, 13:30-15 Uhr, alle zusammen Heute, 23.10., 06.11. - 27.11. Montags, gruppenweise Ab 04.12., 11.12., 18.12.,

Mehr

Requirements Engineering (Anforderungstechnik)

Requirements Engineering (Anforderungstechnik) 5 Requirements Engineering Einführung 5.1 Was ist Requirements Engineering? Erste Näherung: Requirements Engineering (Anforderungstechnik) ist das systematische, disziplinierte und quantitativ erfassbare

Mehr

Low-Fidelity-Prototypen erstellen. Dr. Tobias If you're not failing, you're not going to innovate Jeremy Jackson

Low-Fidelity-Prototypen erstellen. Dr. Tobias If you're not failing, you're not going to innovate Jeremy Jackson Low-Fidelity-Prototypen erstellen Dr. Tobias Günther @elaspix If you're not failing, you're not going to innovate Jeremy Jackson Definitionen User Story: Beschreibung einer Funktion aus Sicht des Kunden

Mehr

OO-Design. Klausur FHF * WI1 / WI2 * SS Name:.../ Semester:...

OO-Design. Klausur FHF * WI1 / WI2 * SS Name:.../ Semester:... OO-Design Klausur FHF * WI1 / WI2 * SS 2000 Name:.../ Semester:... Lineares Benotungsschema: 90 Punkte = Note 1, 30 Punkte = Note 4 Aufgabe 1: (28 Punkte) - Ergänzen Sie zum Fallbeispiel "Seminaranmeldung"

Mehr

Prototyping der Schnittstellenstandards

Prototyping der Schnittstellenstandards 3.2.2.2 Prototyping der Prototypen unterstützen die Evaluierung der Schnittstellen- Standards Evaluierung von Design-Ideen auf abstraktem Niveau durch die Nutzer unterstützt das Verstehen und die Berücksichtigung

Mehr

Softwaremodellierung innerhalb eines SAP ABAP Projekts im agilen Umfeld

Softwaremodellierung innerhalb eines SAP ABAP Projekts im agilen Umfeld Softwaremodellierung innerhalb eines SAP ABAP Projekts im agilen Umfeld 1. Die Kosten der Softwareentwicklung Warum es manchmal sinnvoll ist, am Anfang mehr zu tun, als nötig ist. Modellgetrieben Software-Entwicklung

Mehr

SAP CHANGE MANAGEMENT IM BUSINESS KONTEXT

SAP CHANGE MANAGEMENT IM BUSINESS KONTEXT REALTECH Kundenforum SAP CHANGE MANAGEMENT IM BUSINESS KONTEXT AGENDA SAP Change Management 1. Herausforderungen für unsere Kunden 2. Anforderungen an SAP Change Management 3. Umsetzungsmöglichkeiten 4.

Mehr

30 Multiple Choice-Fragen - pro Frage gibt es immer 1-4 richtige Antworten

30 Multiple Choice-Fragen - pro Frage gibt es immer 1-4 richtige Antworten SCRUM Foundation MUSTERPRÜFUNG Closed Book, d.h. keine Hilfsmittel zulässig Dauer: 60 Minuten 30 Multiple Choice-Fragen - pro Frage gibt es immer 1-4 richtige Antworten Beispiel für die Bewertung Annahme

Mehr

UML fürs Pflichtenheft

UML fürs Pflichtenheft UML fürs Pflichtenheft Sebastian Fischmeister Department of Computer Science University of Salzburg, Austria Sebastian.Fischmeister@cs.uni-salzburg.at Overview Use-Case Diagramm State-Machine Diagramm

Mehr

Dr.-Ing. Thaddäus Dorsch, HOOD GmbH , REConf2018. Die digitale Transformation braucht ein RE2.0 Herausforderungen und Lösungsansätze

Dr.-Ing. Thaddäus Dorsch, HOOD GmbH , REConf2018. Die digitale Transformation braucht ein RE2.0 Herausforderungen und Lösungsansätze Die digitale Revolution braucht ein RE2.0 Herausforderungen und Lösungsansätze Dr.-Ing. Thaddäus Dorsch, HOOD GmbH Mittwoch, 07.03.2018,15:40 Uhr - REConf2018 1 Das klassische Requirements Engineering

Mehr

Ergonomisches UI Design. Das lass mal den Grafiker machen

Ergonomisches UI Design. Das lass mal den Grafiker machen Ergonomisches UI Design Das lass mal den Grafiker machen Werbung Alexander Klein Senior Consultant bei BeOne Stuttgart GmbH Consulting für Prozesse, Engineering und IT http://www.beone-group.com Committer

Mehr

SOFTWAREPROJEKT (WI) Anforderungsanalyse. Projektveranstaltung im Wintersemester 2012/13 FG System- und Softwareengineering Dr.-Ing.

SOFTWAREPROJEKT (WI) Anforderungsanalyse. Projektveranstaltung im Wintersemester 2012/13 FG System- und Softwareengineering Dr.-Ing. SOFTWAREPROJEKT (WI) Anforderungsanalyse Projektveranstaltung im Wintersemester 2012/13 FG System- und Softwareengineering Dr.-Ing. Ralph Maschotta Inhalt Das Pflichtenheft Das UML-Modellierungswerkzeug

Mehr

Vorgehensmodell. Der Weg zum benutzerzentrierten, optimalen Bediensystem

Vorgehensmodell. Der Weg zum benutzerzentrierten, optimalen Bediensystem Vorgehensmodell Der Weg zum benutzerzentrierten, optimalen Bediensystem Benutzer-zentriertes Bediensystem User centered design Die Benutzer stehen im Fokus nicht mehr die Maschine! welcher Benutzer benötigt

Mehr

Memoiren eines Requirements. Dr. Anne Kramer, sepp.med gmbh

Memoiren eines Requirements. Dr. Anne Kramer, sepp.med gmbh Memoiren eines Requirements Dr. Anne Kramer, sepp.med gmbh Über uns Mittelständischer IT-Service Provider 30 Jahre Industrieerfahrung Unsere Referenzen Medizintechnik Pharma Automotive Expertise: Komplexe

Mehr

ANFORDERUNGSANALYSE UND SPEZIFIKATION TEIL 3

ANFORDERUNGSANALYSE UND SPEZIFIKATION TEIL 3 3. Kapitel ANFORDERUNGSANALYSE UND SPEZIFIKATION TEIL 3 Software Engineering Prof. Dr. Wolfgang Schramm Übersicht 1 1. Einführung in das Software Engineering 2. Softwareprozesse 3. Anforderungsanalyse

Mehr

Welche der folgenden Voraussetzungen werden von agilen Methoden gefordert?

Welche der folgenden Voraussetzungen werden von agilen Methoden gefordert? 1/7 1) 2) 3) 4) Welche der folgenden Phasen gehören zum Wasserfall-Modell? Analyse Testen Planung Design Welche der folgenden Voraussetzungen werden von agilen Methoden gefordert? Das Team darf selbständig

Mehr

12 Nicht-funktionale Anforderungen

12 Nicht-funktionale Anforderungen 12 Nicht-funktionale Anforderungen Nicht-funktionale Anforderungen (non-functional requirements) Anforderungen an die Umstände, unter denen die geforderte Funktionalität zu erbringen ist. Gesamte Anforderungen

Mehr

Jochen Ludewig Horst Lichter. Software Engineering. Grundlagen, Menschen, Prozesse, Techniken. dpunkt.verlag

Jochen Ludewig Horst Lichter. Software Engineering. Grundlagen, Menschen, Prozesse, Techniken. dpunkt.verlag Jochen Ludewig Horst Lichter Software Engineering Grundlagen, Menschen, Prozesse, Techniken dpunkt.verlag Inhaltsverzeichnis 1 Modelle und Modellierung 1.1 Modelle, die uns umgeben 1.2 Modelltheorie 1.3

Mehr

Sie ITMC i. Requirements MANAGEMENT Die ADVANCED Level von CPRE Vorteile und Nutzen. Vortrag. Wien

Sie ITMC i. Requirements MANAGEMENT Die ADVANCED Level von CPRE Vorteile und Nutzen. Vortrag. Wien Sie ITMC i Requirements MANAGEMENT Die ADVANCED Level von CPRE Vorteile und Nutzen Vortrag Wien 13.06.2017 1 Inhalt Geschichten / Fallstudien zum Thema Requirements Engineering Requirements Engineering

Mehr

Grundlagen Software Engineering

Grundlagen Software Engineering Grundlagen Software Engineering Rational Unified Process () GSE: Prof. Dr. Liggesmeyer, 1 Rational Unified Process () Software Entwicklungsprozess Anpassbares und erweiterbares Grundgerüst Sprache der

Mehr

Semantisches Geschäftsprozessmanagement Übung 1

Semantisches Geschäftsprozessmanagement Übung 1 Matthias Dräger 0.05.20 Markus Bischoff Semantisches Geschäftsprozessmanagement Übung Aufgabe : ) Vorteile von BPM und Modellierung - Modellierung zum besseren Verständnis eines Systems / eines Geschäftsprozesses

Mehr

Einführung in Software Engineering

Einführung in Software Engineering Einführung in Software Engineering Die Katze auf der Terrasse Mit Python-Objekten ist es wie mir der Katze, die du irgendwann schlafend auf deiner Terrasse vorfindest. Ganz wie ein Python-Objekten kann

Mehr

Softwaretechnik 2015/2016

Softwaretechnik 2015/2016 Softwaretechnik 2015/2016 PST Lehrstuhl Prof. Dr. Matthias Hölzl HAUPT-/ BACHELOR- SEMINAR ADAPTIVE SYSTEME PST Joschka PROF. DR. Rinke WIRSING 14. JUNI 2009 VORNAME NAME AGENDA Übung 4: 05.11.2015 Fragen

Mehr

Scrum in Theorie und Praxis.

Scrum in Theorie und Praxis. Scrum in Theorie und Praxis bernd_bettermann@web.de 1 Zur Person... Softwareentwicklung seit 1988 Anfänge mit COBOL und ISAM-Datenbank später Clipper und Visual Objects Scrum im.net- und WEB-Umfeld Sartorius

Mehr

Das agile Requirements Board Ein Tool zur Unterstützung des agilen Requirements-Engineerings

Das agile Requirements Board Ein Tool zur Unterstützung des agilen Requirements-Engineerings Das agile Requirements Board Ein Tool zur Unterstützung des agilen Requirements-Engineerings Johannes Bergsmann Berater, Trainer, Eigentümer Software Quality Lab www.software-quality-lab.com Über Software

Mehr

1.1 Softwareintensive Systeme Bedeutung des Requirements Engineering... 8

1.1 Softwareintensive Systeme Bedeutung des Requirements Engineering... 8 ix Teil I Grundlagen und Rahmenwerk 1 1 Motivation 5 1.1 Softwareintensive Systeme................................... 5 1.2 Bedeutung des Requirements Engineering........................ 8 2 Anforderungen

Mehr

DOORS Schema IBM Rational DOORS Start-Up Training - Teil 3

DOORS Schema IBM Rational DOORS Start-Up Training - Teil 3 DOORS Schema IBM Rational DOORS Start-Up Training - Teil 3 Inhalt: Anforderungen an ein Schema Design eines Schemas Schrittweises Vorgehen Strukturierung und Design der Daten in DOORS Voraussetzung für

Mehr

Scrum Musterprüfung. Musterprüfung (Fragen) zum SCRUM Product Owner - TÜV. Anleitung

Scrum Musterprüfung. Musterprüfung (Fragen) zum SCRUM Product Owner - TÜV. Anleitung Scrum Musterprüfung Musterprüfung (Fragen) zum SCRUM Product Owner - TÜV Anleitung Bitte beantworten Sie die nachfolgenden Fragen. Es sind keine Hilfsmittel zulässig (closed book). Die Dauer der Prüfung

Mehr

Requirements Engineering in der Systementwicklung

Requirements Engineering in der Systementwicklung Requirements Engineering in der Systementwicklung SOPHIST GmbH Vordere Cramergasse 13 Fon: +49 (0)911 40 900-0 www.sophist.de 90478 Nürnberg, Deutschland Fax: +49 (0)911 40 900-99 heureka@sophist.de SOPHIST

Mehr

Software Engineering Projekt. Pflichtenheft

Software Engineering Projekt. Pflichtenheft Software Engineering Projekt Pflichtenheft Ziele eines Pflichtenheftes Festsetzung der Leistung und des Umfangs der Software Anforderungen Zugesicherter Funktionsumfang Zugesicherte Produktumgebung Risikovorbeugungsmaßnahme

Mehr

Dokumentation nach IEEE Empfehlungen

Dokumentation nach IEEE Empfehlungen Inhalte einer Anforderungsspezifikation Einleitung (Introduction) allgemeine Beschreibung Produktumgebung, Funktionen, Eigenschaften, Randbedingungen Spezifische funktionale Anforderungen beschreiben,

Mehr

Requirements Engineering für die agile Softwareentwicklung

Requirements Engineering für die agile Softwareentwicklung Johannes Bergsmann Requirements Engineering für die agile Softwareentwicklung Methoden, Techniken und Strategien Unter Mitwirkung von Markus Unterauer dpunkt.verlag Inhaltsverzeichnis 1 Einleitung 1 1.1

Mehr

Probe-Klausur Software Engineering Fachbereich BW, für WINFO

Probe-Klausur Software Engineering Fachbereich BW, für WINFO Probe-Klausur Software Engineering Fachbereich BW, für WINFO Dipl.-Ing. Klaus Knopper 17.04.2007 Hinweis: Bitte schreiben Sie auf das Deckblatt und auf jede Seite Ihren Namen und Ihre Matrikelnummer, bevor

Mehr