Dr. Beatrice Amrhein
Requirements Engineering
Anforderungen ermitteln, analysieren und verwalten
2
Kurs Überblick
1. Einführung, Grundlagen, Definitionen
2. Requirements ermittelnStakeholder, Visionen, Kontext
3. Requirements spezifizierenTemplates, Kapitel‐Raster, Mind Maps, …
4. Requirements analysieren und modellierenUse‐Cases, Daten‐, Aktivitäts‐, Zustandsmodell, …
5. Requirements prüfenQualitätskriterien, Prüftechniken
6. Requirements verwaltenNachverfolgung, Change Management
3
Viele der Ideen und Aufgabenbeispiele stammen aus dem Skript von André‐Claude Godet, welches er mir freundlicherweise als Ausgangspunkt für dieses Skript zur Verfügung gestellt hat. Herzlichen Dank!
1. Einführung
1. Einführung
Motivation, Grundlagen und Definitionen
41. Einführung
Lernziele
Die Vorgehensweise, Standards und Methoden des Requirements Engineering.
Requirements erheben, analysieren und diese vollständig, korrekt und präzise dokumentieren.
5
Unzureichendes Requirements Engineering ist einer der Hauptgrund dafür, das viele IT‐Projekte zu spät fertig werden, zu hohe Kosten verursachen oder sogar scheitern (www.standishgroup.com).
RE: Die Beteiligten einigen sich auf ein gemeinsames Ziel.
Prozessfähigkeit: Die Ziele konnten nicht erreicht werdenOrganisationsmanagement: Fehler bei Projektleitung und Management
1. Einführung
Motivation
Nur wer ein klares Ziel hat, findet den richtigen Weg.
Aus: Christoph Ebert: Systematisches Requirements Engineering
Studie der Standish Group, 2010
61. Einführung
Schwierigkeiten/Probleme
Verschiedene, sich widersprechende (An‐)Sichten
Jeder Beteiligte (Geldgeber, Administration, Benutzer, Marketing, Entwickler…) hat eine eigene Vorstellung/Vision
Unklare Ansprüche
Benutzer wissen nicht (genau), wie sie am besten durch eine IT Lösung unterstützt werden könnten
Schnell wechselndes Umfeld (Markt, Standards, Gesetze, …)
Rasch wechselnde Ansprüche an IT Lösungen
Politische Einflüsse
Organisatorische oder «Hintergrund»‐Einflüsse, die nicht offen ausgesprochen werden (dürfen)
Mögliche Wünsche/Vorstellungen… des Geldgebers: tiefer Preis der Administration: möglichst keine Änderungen der Benutzer: einfache Handhabung bei grösstmöglichem Nutzen des Marketing: werbetechnisch möglichst wirkungsvoll
Marktumfeld ist sehr kurzlebig: Software/Hardware Produkte veralten schnell.
Widerstände von Mitarbeitenden: Angst vor Veränderungen/Jobverlust
7
Dokumentieren: • Wie sind die Informationen zu Stande gekommen (Quelle)?• Wer hat welche Anforderung wann formuliert (Autor)?• …
Spezifizieren: • Was bedeutet die Anforderung exakt?• Welche Daten sind involviert?• Welche Abläufe, Prozesse müssen abgebildet werden?• Welche Ergebnisse müssen geliefert werden?• …
1. Einführung
Definitionen
Eine Anforderung (Requirement) ist: Eine dokumentierte Bedingung, Fähigkeit oder Eigenschaft, welche
von einem Benutzer (Person oder System) zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.
Eine dokumentierte Bedingung, Fähigkeit oder Eigenschaft, welche ein System erfüllen muss, um einen Vertrag, eine Norm oder andere, formell vorgegebene Dokumente zu erfüllen.
Alle Anforderungen an ein System werden gesammelt, dokumentiert und spezifiziert.
8
Wichtig: Nicht mischen von • was
Anforderungen, Lastenheft und • wie
konzeptuelle Lösungsbeschreibung, Pflichtenheft
Üblicherweise wird zuerst das Lastenheft fertig gestellt und erst dann mit dem Pflichtenheft begonnen. Andernfalls besteht die Gefahr, dass die Lösung vorschnell definiert und damit Kundenwünsche übergangen werden. Die Trennung/Grenze zwischen dem Kundenwunsch und der angestrebten Lösung ist allerdings oft unscharf.
Zum Lastenheft gehören die Anforderungen, zum Beispiel in Form von Use‐Cases, User‐Stories (Szenarien), Aktivitätsdiagrammen, …
Zum Pflichtenheft gehört die Lösungsbeschreibung, zum Beispiel Komponenten oder Architektur‐Diagramme, Datenbank‐ oder Fachklassen‐Diagramme, Sequenzdiagramme, …
1. Einführung
Definitionen
Lastenheft Liste der Anforderungen des Auftraggebers, Kunden (was) Wünsche, Absichtserklärung
Anforderungsspezifikation, Anforderungskatalog, Produktskizze, Requirements Specification
Pflichtenheft Die Beschreibung der Problem‐Lösung des Auftragnehmers (wie, womit)
Lösungsvorschlag, Realisierung, Design
Lösungsspezifikation, Fachkonzept, Funktionale Spezifikation, Implementierungs‐Spezifikation, Feature Specification.
9
Stakeholder können Personen sein, aber auch Personengruppen (vertreten durch eine spezielle Person), aber auch Reglemente, Standards, Bestimmungen, Prozessdiagramme, …
1. Einführung
Definitionen
Stakeholder sind die Informationslieferanten für Ziele, Anforderungen und Randbedingungen an ein zu entwickelndes System oder Produkt.
Stakeholder sind alle Personen, Institutionen und Dokumente, die von der Entwicklung und vom Betrieb eines Systems in irgendeiner Weise betroffen sind, also auch die Personen, welche das neue System benutzen, in Betrieb halten oder schulen.
101. Einführung
Definitionen
Die Software Requirements Specification (SRS) ist ein vom IEEE (erstmals 1984) veröffentlichter Standard zur Spezifikation von Software.
Das IEEE hat die Spezifikation mehrmals überarbeitet. Der aktuelle Standard ist 830‐1998.
Die SRS definiert die Inhalte des Lastenhefts und des Pflichtenhefts.
Auszug aus der WebSite
111. Einführung
Definitionen
Requirements Engineering ist ein kooperativer, iterativer und inkrementeller Prozess, um sicher zu stellen dass alle relevanten Anforderungen bekannt und verstanden sind,
alle involvierten Stakeholder ausreichend zu den bekannten Anforderungen einig sind,
alle Anforderungen klar und präzise dokumentiert und spezifiziert werden.
Die Ziele des Requirements Engineering sind:• Ein von allen Beteiligten abgesegnetes Lastenheft.• Die Liste der Priorisierten (funktionalen und nicht funktionalen) Anforderungen.• Eine Basis zum Einholen verschiedener Offerten für das neue Produkt schaffen.
Agiler Managementprozess
RE findet zu Beginn und während des ganzen Projekt‐Verlaufs statt (iterativ).
131. Einführung
RE Aktivitäten
Requirements Engineering
Einholen
Dokumentieren
Prüfen
Verwalten
InterviewFragebogenEinarbeitungVideoanalyse
ProsaTemplates Use CasesAktivitäts-
Diagramme
ReviewTestfälle
erstellenValidierenKonsolidieren
ReleasesVersionenTools
verwenden
Einholen Kapitel 2Dokumentieren Kapitel 3/4Prüfen Kapitel 5Verwalten Kapitel 6
141. Einführung
Fähigkeiten eines RE
Analytisches Denken
Abstraktionsvermögen
Empathie, Einfühlungsvermögen
Kommunikations‐Fähigkeit
Konfliktlösungs‐Fähigkeit
Moderations‐Fähigkeit
Selbstbewusstsein
Überzeugungs‐Fähigkeit
Analytisches Denken: Schnelles Einarbeiten in neue Fachgebiete, Problemstellungen und Zusammenhänge. Abstraktionsvermögen: Abstrahieren vom Beispiel zur konkreten Anforderung Empathie, Einfühlungsvermögen: Verstehen, was der Stakeholder tatsächlich will, erkennen von gruppendynamischen Effekten. Kommunikations‐Fähigkeit: Die richtigen Fragen stellen und zuhören! Konfliktlösungs‐Fähigkeit: Konflikte erkennen und zwischen den verschiedenen Meinungen/Parteien vermitteln.Moderations‐Fähigkeit: Diskussionen leiten in Einzel‐ oder Gruppenbefragungen oder Workshops. Selbstbewusstsein: Der RE steht oft im Mittelpunkt und wird häufig kritisiert. Überzeugungs‐Fähigkeit: Konsolidieren der verschiedenen Meinungen, eine Entscheidung herbeiführen und diese überzeugend vertreten.
152. Requirements ermitteln
2. Requirements ermitteln
Das Ziel oder den Nutzen des neuen Produktes herausfinden
16
Dazugehörende Themen im Kurs Informatik Projekt‐Management:‐ Termin‐Planung‐ Priorisierung‐ Risiken‐ Aufwandschätzung‐ Ressourcen Management
1. Einführung
Lerninhalte
Glossar
Stakeholder
Ermittlungs‐Techniken
Funktionale/nicht funktionale Anforderungen
Kano‐Modell
Randbedingungen/System‐Grenzen
Methodische Anfoderungsermittlung
Checkliste
172. Requirements ermitteln
Kommunikation Glossar
Fachgebiet, Umfeld RE muss Fachgebiet des Auftraggebers kennen (lernen)
Begriffswelt klären
Fachbegriffe
Rückfragen, ob der Begriff korrekt verstanden wurde
Medium Mündlich Befragung, Interviews, …
Schriftlich Fragebogen
In verschiedenen fachlichen Gebieten können die gleiche Namen/Begriffe eine völlig andere Bedeutung haben.Beispiel: Karte• ein geographisches Bildwerk• EC, oder Kredit‐Klarte• Identitätskarte• Kundenkarte• Postkarte• Speisekarte• . . .
182. Requirements ermitteln
Ermittlungstechniken
Befragung Interview oder Fragebogen
Brainstorming Normal (5‐10 Personen, möglichst gemischte Gruppen)
Brain‐Writing (jeder schreibt drei Ideen auf und gibt den Zettel weiter)
Perspektiven‐Wechsel (verschiedene Sichtweisen/Rollen einnehmen)
Analogien (ähnliche Probleme/Situationen) erörtern.
Beobachtung Arbeits‐Prozesse begleiten ( hinterfragen, optimieren)
Apprenticing RE wird angelernt und arbeitet im Prozess mit.
Dokumentenzentriert Dokumente von alten oder Konkurrenz‐Systemen studieren
• Durch Befragungen wird versucht, von den Stakeholder möglichst exakte Aussagen über die Anforderungen zu erlangen. Der RE gibt die Fragen vor, dadurch wird alles Wissen der Stakeholder zu den befragten Themen gesammelt. Der Nachteil von Befragungen: nur das erfragte Wissen wird gesammelt.• Durch Brainstorming Techniken werden ev. nicht alle Anforderungen gefunden, dafür werden ev. viele Ideen gesammelt und es ist möglich auch neue, nicht offensichtliche Lösungen zu entdecken.• Besonders wenn Fachspezialisten keine Zeit haben, ist es möglich durch Beobachtung und Dokumentation der Arbeitsschritte zu den Anforderungen an das System zu gelangen. Der RE kann dabei die Prozesse hinterfragen und ev. bessere Abläufe finden.
192. Requirements ermitteln
Unterstützende Techniken
Mindmap Im Zusammenhang mit Brainstorming
Workshop Zum Beispiel für die Anforderungen an das GUI
CRC Karten Daten und deren Beziehungen
Eigenschaften, die zu Anforderungen führen
Video‐Aufzeichnungen Bei Beobachtungs‐Techniken
Use Cases Aussensicht an das System funktionale Anforderungen
Prototypen GUI Prototyp zum finden funktionaler Anforderungen
Insbesondere wenn die Anwender Mühe haben, sich ein (klares) Bild des Systems zu machen, kann ein Prototyp sehr hilfreich sein. Allerdings ist das Erstellen davon aufwändig und die Anwender haben ev. die Erwartung, ein Bild des Zielsystems zu erhalten.
202. Requirements ermitteln
Arten von Anforderungen
Funktionale Anforderungen Welche Funktionalität stellt das System zur Verfügung?
Wie reagiert das System auf Benutzereingaben?
…
Qualitäts‐Anforderungen Wie schnell beantwortet das System eine Anfrage?
Wie sicher ist das System?
Randbedingungen Welche gesetzlichen Vorgaben oder Standards müssen eingehalten
werden?
Grundsätzlich müssen wir unterscheiden zwischen • Funktionalen Anforderungen und• Nicht funktionalen Anforderungen d.h.
Qualitäts‐Anforderungen oder Randbedingungen
212. Requirements ermitteln
Funktionale Anforderungen
Eine funktionale Anforderung ist eine Anforderung an ein Ergebnis/Resultat, welches von einer Funktion des Systems bereitgestellt wird (Funktionalität).
Externe Sicht Anwendungsfälle
Dienstleistungen
Benutzerschnittstellen
Interne Sicht Gespeicherte Daten
Architektur
Zustände
Die Funktionalen Anforderungen stammen entweder vom Benutzer Externe Sicht, oder von der Administration , bzw. aus Dokumenten (Standards, Reglemente, Umsysteme, …)
22
Auch Qualitäts‐Anforderungen stammen aus zwei Bereichen. Die Benutzer erwarten Effizienz, Ergonomie und Zuverlässigkeit.Die Administration oder Entwickler wollen Sicherheit, Wartbarkeit, Portierbarkeit, Langlebigkeit.
2. Requirements ermitteln
Qualitäts‐Anforderungen
Eine Qualitäts‐Anforderung ist eine Anforderung, welche sich auf ein Qualitäts‐Merkmal bezieht
Externe Sicht Performance, Effizienz
Sicherheits‐Anforderungen, Verfügbarkeit, Zuverlässigkeit
Benutzbarkeit, Fehlertoleranz, Ergonomie
Interne Sicht Prüfbarkeit, Stabilität
Einhaltung von Standards
Wartbarkeit, Austauschbarkeit, Erweiterbarkeit, Interoperabilität
Portabilität, Skalierbarkeit, Installierbarkeit
232. Requirements ermitteln
Qualitäts‐Anforderungen
Exakte Abnahme‐Kriterien
Aus: Systematisches Requirements Engineering,
Christoph Ebert
Qualitäts‐Anforderungen werden oft unpräzise formuliert. Qualitäts‐Anforderungen müssen aber messbar sein!
Darum: • Das Auffinden von xy benötigt auf der Benutzeroberfläche höchstens 4 Maus‐
Klicks.• Das Liefern der Kundeninformationen benötigt in 90% der Anfragen nicht mehr
als 3 Sekunden.• Fehlerhafte Benutzereingaben werden abgefangen und durch eine
entsprechende Fehlermeldung in der Statuszeile angegeben.• Das System ist höchstens eine Stunde pro Monat wegen Wartungsarbeiten nicht
verfügbar.
242. Requirements ermitteln
Rand‐ / Rahmenbedingungen
Infrastruktur
System‐Umfeld, Schnittstellen
Organisation, Prozesse
Dokumentation
Gesetze, Standards
Termine, Ressourcen, Kosten
Marktanalyse
Randbedingungen werden typischerweise in bereits vorhandenen Dokumentationen gefunden und können von den am Projekt beteiligten nicht beeinflusst werden. • Die zu benutzende Infrastruktur (Betriebssystem, Web‐Server, Datenbank‐System,
…)• Schnittstellen zu anderen Systemen (Format‐Angaben, ev. Klassendiagramme)• Prozess‐ oder Ablauf‐Diagramme• Standards oder Vorschriften• Ev. Marktanalysen ( Chancen für das Produkt)• Maximal vertretbare Kosten für das Produkt • Termin‐ oder Ressourcen‐Vorgaben
25
Im besten Fall entsteht durch den RE Prozess auch eine klare Produkt Vision.Diese hilft auch als Motivations‐Grundlage für alle Beteiligten.
2. Requirements ermitteln
Ziel: Produkt‐Vision
Was wird das Produkt verändern?
Warum ist das Produkt für die Kunden nützlich oder nötig?
Wie wird durch das Produkt Geld gespart oder verdient?
Welchen Kontext deckt das Produkt ab? (Zielpublikum)
26
Eine Produkt‐Vision dient nicht nur dazu, ein klares Ziel vor sich zu haben, sondern auch der Motivation für das Team. Je unklarer das Ziel, desto weniger motivierend ist die Arbeit.Der Kontext des Produkt definiert auch dessen Abgrenzung (was soll nicht umgesetzt werden).Das Ziel des RE sind die exakt, sauber und unmissverständlich spezifizierten Anforderungen (was kann das Produkt genau).Das Lastenheft ist dann die Ausgangsbasis für die weiteren Schritte (Offerten einholen, Zeitplanung, Pflichtenheft, …)
2. Requirements ermitteln
Ergebnisse der Ermittlung
Vision, Produkt‐Idee, Kundenbedürfnis Motivation für das Projekt
Kontext des Produkts Umfeld, konkreter Einsatz
Bedürfnisse und Erwartungen an das Projekt
Spezifizierten Anforderungen
Gemeinsame Ausgangsbasis für das Marketing, die Entwicklung und den Kunden
2. Requirements ermitteln
Stakeholder /
Anforderungskategorisierung
282. Requirements ermitteln
Relevante Stakeholder und Entscheidungsträger
Kunden
Marketing, Vertrieb
Geschäftsleitung, Produkt‐Manager
Entwicklung
Qualitäts‐Sicherung
Administration
Projekt‐Manager
…
Sammeln aller beteiligter Personen mit Name, Verantwortlichkeit, Telefonnummer, Email‐Adresse,…
Mit diesen Personen werden zuerst Workshops oder Interview‐Termine vereinbart.
292. Requirements ermitteln
Wer alles hat Einfluss oder ist interessiert am Produkt?
Stakeholder
Je umfangreicher/schwieriger das Projekt, desto mehr Stakeholder sind beteiligt Auswahl der „wichtigen“ (oder geeigneten) Stakeholder
Problem: Wichtige Stakeholder haben oft keine Zeit ( Interesse), da ihr Terminplan bereits gefüllt ist mit anderen Terminen.Darum Frühzeitig Interview‐Termine abmachen!
302. Requirements ermitteln
Pflichten der Stakeholder
Einführen ins Fachgebiet/in das Problem‐Umfeld
Kommunizieren der Anforderungen
Setzen von Prioritäten
Einhalten von Terminen
Treffen von Entscheidungen
Überprüfen der vom RE formulierten Anforderungen
Kommunizieren von Änderungen in den Anforderungen
Respektieren von anderen Meinungen und Entscheidungen
Problem: Stakeholder sind sich nicht einig, da sie verschiedene Bedürfnisse haben.Darum Klären, wer für welchen Bereich verantwortlich, bzw. entscheidungsbefugt ist. Integrieren/regelmässig Informieren aller beteiligten Personen. Feedback‐Runden einbauen, um Verständnisfragen zu klären (hat der RE die Anforderung korrekt verstanden/erfasst) Stakeholder mit‐verantwortlich machen
Ev. muss schriftlich vereinbart werden, welches Stakeholder im Projekt welche Aufgaben und Verantwortungsbereiche hat.
312. Requirements ermitteln
Pflichten des Requirements Engineers
Arbeitet sich in das Problem‐Umfeld ein
Erlernt/spricht die Sprache der Stakeholder
Erstellt/Formuliert die Anforderungen
Respektiert die Meinungen der Stakeholder
Erklärt/präsentiert die Ergebnisse (z.B. anhand von Graphiken/Prototypen/Diagrammen)
Sorgt dafür, dass die funktionalen und qualitativen Ansprüche der Stakeholder erfüllt werden.
Informiert die Stakeholder regelmässig über den Stand des RE‐Prozesses.
Der RE sorgt dafür, dass sich alle Stakeholder ernst genommen fühlen und deren Bedürfnisse nach Möglichkeit erkannt und (fair) respektiert werden.
322. Requirements ermitteln
Anforderungskategorisierung, das Kano‐Modell
Bedeutung der Anforderungen
Basisfaktoren selbstverständlich vorausgesetzte Merkmale
Leistungsfaktoren explizite geforderte Merkmale
Begeisterungsfaktoren angenehme nützliche Überraschung (ev. erst während der Benutzung entdeckt)
Benutzer sehr zufrieden
BasisfaktorenErfüllungsgradunzureichend
Erfüllungsgrad über Erwartung
Zeit
Benutzer sehr unzufrieden
Begeisterungsfaktoren
Leistungsfaktoren
• Basisfaktoren werden als selbstverständlich vorausgesetzt, das Fehlen dieser Funktionalitäten führt zu Unzufriedenheit bei den Benutzern, sogar wenn diese nicht explizit als Anforderung formuliert wurden.• Leistungsfaktoren werden von den Stakeholder als Anforderung formuliert. Die Benutzer erwarten, dass diese erfüllt sind.• Begeisterungsfaktoren dienen als positiver Motivator für die Benutzung des Systems.
2. Requirements ermitteln
System‐Grenzen /
System‐Kontext
342. Requirements ermitteln
System‐Kontext abgrenzen
Abgrenzen des Systems von dessen Kontext, sowie des Kontexts zur irrelevanten Umgebung
Der Systemkontext ist der Teil der Umgebung des Systems, welcher für die Definition und das Verständnis der Anforderungen relevant ist.
Nur der Ausschnitt der „Realität“, welcher für das System relevant ist (einen Einfluss auf das System und damit auf die Anforderungen hat) gehört zum Systemkontext. Für die korrekte und vollständige Erfassung der Anforderungen ist es wichtig, die Beziehungen (Schnittstellen) des Systems mit dessen Kontext zu identifizieren.
352. Requirements ermitteln
System‐Grenze
Definieren der Umgebung mit seinen Schnittstellen
Die System‐Grenze separiert das geplante System von seiner Umgebung. Die Umgebung ist gegeben und kann durch den Entwicklungsprozess nicht verändert werden.
362. Requirements ermitteln
Kontext‐Grenze
Die Kontext‐Grenze separiert den relevanten Teil der Umgebung eines geplanten Systems von der irrelevanten Umgebung, also von dem Teil der Umgebung, welcher keinen Einfluss auf das geplante System, bzw. auf dessen Anforderungen hat.
372. Requirements ermitteln
Grauzonen
Die System‐Grenze ist häufig erst gegen Ende des RE Prozesses konkret festgelegt.
Der System‐Umfang ist oft zu Beginn noch nicht klar und ändert sich im Verlauf des RE‐Prozesses.
System‐Kontext dokumentieren
Zur Dokumentation des System‐Kontextes dienen entweder Use‐Case‐Diagramme oder Datenfluss‐Diagramme.
System-Grenze
2. Requirements ermitteln
Methodische Anforderungs‐Ermittlung in zehn Schritten
Systematisches Requirements Engineering
Christoph Ebert, Kap 3.4
402. Requirements ermitteln
1. Relevante Stakeholder und Entscheidungsträger klären
Sammeln aller beteiligter Personen mit Kontaktdaten Name, Funktion (Rolle)
Telefonnummer, Email‐Adresse
Stellvertretung, Mitarbeiter, …
Verfügbarkeit (zeitlich/räumlich)
Wissensgebiet‐/Umfang, Ziele, Interessen
Verantwortlichkeiten klären
Workshop‐ und/oder Interview‐Termine vereinbaren.
Kontakt‐/ Beziehungs‐Netze beim Auftraggeber nutzen.
41
Es muss auch dokumentiert werden, wer genau welche Anforderungen und Wünsche vorbringt, damit diese priorisiert werden können.Mit beliebig viel Zeit und Geld lässt sich fast beliebig viel machen, bloss ist beides nie vorhanden.
Wichtig: Trennen zwischen Anforderungen und Lösungen!
2. Requirements ermitteln
2. Kritische Erfolgsfaktoren
Was ist dem Kunden, für das Unternehmen, dem Benutzer, … wirklich wichtig?
Wie viel Mehrwert bringt welche Funktionalität?
Welcher Stakeholder will was (und warum)?
Worin liegt der grösste Nutzen (Hauptanwendung)?
Wie viel darf das Produkt maximal kosten?
Priorisieren der Anforderungen
42
Der System‐Kontext grenzt den Projekt‐Umfang ab: was gehört dazu und was ist schon vorhanden, welche Aspekte werden berücksichtigt, welche weggelassen, was wird umgesetzt, was ist schon vorhanden und was wird absichtlich fallengelassen.
2. Requirements ermitteln
3. Umfang, Kontext
Kosten (Obergrenze)
Plattform‐Vorgaben (Ziel‐Plattform)
Qualitäts‐Anforderungen
Randbedingungen (Richtlinien, Standards, …)
System‐Kontext, System‐Grenzen, Schnittstellen
Use Cases, Datenflussdiagramme
43
Die Anforderungen werden aus verschiedensten Quellen auf verschiedene Arten entwickelt. Für End‐User ist es oft am ergiebigsten, den Benutzungs‐Prozess konkret durchzuspielen, um zu definieren, was sie vom System erwarten.
Persona meint einen hypothetischen, typischen Benutzer und seine Ziele, mit Hilfe dessen die wichtigsten Anwendungsfälle spezifiziert werden können (z.B. ein «typischer» Vertreter einer Benutzergruppen).
2. Requirements ermitteln
4. Quellen für Anforderungen
Marktforschung, Marktstudien, Marketing
Bestehende Benutzergruppen Brainstorming, Fragebögen, Interviews
Kundeninterviews, Seminare, Workshops Prototyping, Persona, Simulationen, Experimente
Lastenhefte bestehender Systeme Anforderungen aus bestehenden Systemen extrahieren, Glossar
Konkurrenz‐Systeme (mit ähnlichen Anforderungen)
Dokumente, Vorschriften, Normen, Standards
44
Im Kapitel 3 wird die systematische Dokumentation ausführlich behandelt.
2. Requirements ermitteln
5. Dokumentieren/Strukturieren
Systematische Erfassung Identifizierbar
Eindeutige Codes (z.B. FA‐15.4)
Wiederauffindbar
Standardisierte Kapitelstruktur, Verlinkung
Nachverfolgbar
Change‐Management
Tabelle, Datenbank, Case Tool
452. Requirements ermitteln
6. Modellieren
Use Cases OOAD
User‐Stories (Szenarien)
(Rudimentärer) GUI Prototyp OOAD
Komponenten‐Diagramm OOAD
Aktivitäts‐ und Zustandsdiagramme OOAD
CRC‐Karten
ERM Datenbank‐Struktur OOAD
…
Im Kapitel 4 wird das Modellieren von Anforderungen behandelt.
46
Anforderungen, welche einen geringen Nutzen aber einen grossen Aufwand bedeuten, sollten möglichst aus dem Projekt gestrichen (anders angegangen/gelöst) werden. Das Behandeln aller Spezialfälle ist selten sinnvoll und macht das Produkt unnötig teuer und die Anwendung unnötig kompliziert.
2. Requirements ermitteln
7. Analysieren
Meta‐Betrachtungen Welche Anforderungen verursachen welchen Aufwand?
Welche Anforderungen ermöglichen Wiederverwendung?
Wie beeinflussen sich die Anforderungen gegenseitig (positiv, negativ, konkurrierend, widersprechend)?
Gibt es unnötige Hemmschuhe?
80/20 Regel
472. Requirements ermitteln
8. Prüfen
Qualitätsprüfung der Dokumentation
Checklisten zu Verständlichkeit
Vollständigkeit
Widerspruchsfreiheit
Validierbarkeit
Erreichbarkeit
Im Kapitel 5 wird behandelt, wie die Dokumentation verifiziert werden kann.
Verifikation ist der Prozess, der für ein System oder eine Dokumentation sicherstellt, dass es zu einer Spezifikation konform ist (z.B. entspricht die Dokumentation denAnforderungen der IEEE Spezifikation?).Im Gegensatz dazu steht die Validierung, d.h. die dokumentierte Plausibilisierung (der Testbericht), dass das System die Anforderungen erfüllt (Erfüllt das Produkt die Anforderungen des Lastenhefts?)
482. Requirements ermitteln
9. Priorisieren
Welche Anforderungen sind für den Kunden erfolgsentscheidend?
weniger zentral?
Wie viel darf das Produkt kosten? Termin / Ressourcen
Ist der Kunde bereit, die (für den optimalen Einsatz des Produktes) nötigen Änderungen in der Firma durchzusetzen?
Die Priorisierung muss mit Hilfe der wichtigsten Stakeholder geschehen und sollte möglichst frühzeitig (bereits in den Interviews) angesprochen werden.
49
Frühe Entscheide vereinfachen den Prozess.Späte Entscheide verursachen Terminprobleme.
Die gesetzlichen und reglementarischen Vorgaben müssen als erstes abgeklärt werden. Andernfalls werden Dinge versprochen, die dann später widerrufen werden müssen ( demotivierend).
2. Requirements ermitteln
10. Entscheiden
Randbedingungen als erstes klären Regeln müssen eingehalten werden
Iterative Entscheidungen Ziele im Auge behalten
Je früher desto besser
Doppelspurigkeiten vermeiden
Termine einhalten Änderungsvorschlage sind einzureichen bis …
Change Management definieren
Checkliste für die Ermittlung von Requirements
Die Checkliste kann als Grundlage für Interview‐Fragen mit den verschiedenen Stakeholder benutzt werden.Wichtig dabei ist zu beachten, dass die Frage‐Kataloge für die verschiedenen Stakeholder angepasst werden müssen.
2. Requirements ermitteln
512. Requirements ermitteln
Checkliste
Basis für mögliche Interview‐Fragen:
Was ist das Zielpublikum (Kunde, Benutzer)?
Was ist das Geschäftsmodell (womit verdient der Kunde sein Geld)?
Welches Problem soll das neue System (besser) lösen?
Welcher Nutzen erwartet der Kunde vom neuen System?
Welche Anforderungen haben die verschiedene Benutzer an das System?
522. Requirements ermitteln
Checkliste
Welche Randbedingungen (Regeln, Standards, Vorschriften) muss das System erfüllen?
Welche Risiken werden mit der Lösung auftreten?
Welche Kriterien bestimmen die Auswahl verschiedener Lösungen?
Welche Funktionen und Eigenschaften sind dem Kunden an den verschiedenen Lösungen/Produkten am wichtigsten?
Welche Interessengruppen spielen für den Erfolg des Produktes eine Rolle?
532. Requirements ermitteln
Checkliste
Sind die Anforderungen bekannt, verständlich, messbar, prüfbar?
Sind die Qualitätsanforderungen spezifiziert und priorisiert?
Was ist, wenn gewisse der Anforderungen nicht realisierbar sind?
Wie viel Zeit/Geld/Ressourcen stehen für das Projekt zur Verfügung?
Was passiert, wenn der Budget‐Rahmen vor dem Ende erreicht wird?
Wie wird sich die System‐Umgebung im Verlauf der Projekts ändern?
542. Requirements ermitteln
Checkliste
Welche zusätzlichen Anforderungen könnten zu einem späteren Zeitpunkt wichtig werden?
Sind alle relevanten Stakeholder befragt worden, wer könnte noch fehlen?
Haben wir alles besprochen, oder fehlt noch ein Bereich?
Jedes Interview endet üblicherweise mit der Frage nach • Zukunfts‐Perspektiven• Ev. Weiteren Interessengruppen oder möglichen Interview‐Partnern• Offenen, noch nicht angesprochenen Punkten.