Requirements Engineering - sws.bfh.chamrhein/Skripten/RE/01-REKap01E_L.pdf · Studie der Standish Group, 2010. 1. Einführung 6 Schwierigkeiten/Probleme Verschiedene, sich widersprechende

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


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


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


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.


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.


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


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.


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



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.


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.


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, …)


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


Stakeholder /

Anforderungskategorisierung


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.


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!


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.


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.


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.


System‐Grenzen /

System‐Kontext


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.


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.


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.


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


Methodische Anforderungs‐Ermittlung in zehn Schritten

Systematisches Requirements Engineering

Christoph Ebert, Kap 3.4


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


3. Umfang, Kontext

Kosten (Obergrenze)

Plattform‐Vorgaben (Ziel‐Plattform)


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


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.


5. Dokumentieren/Strukturieren

Systematische Erfassung Identifizierbar

Eindeutige Codes (z.B. FA‐15.4)

Wiederauffindbar

Standardisierte Kapitelstruktur, Verlinkung

Nachverfolgbar

Change‐Management

Tabelle, Datenbank, Case Tool


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.


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


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


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


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.



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?


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?


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?


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.

Documents

Requirements Engineering - sws.bfh.chamrhein/Skripten/RE/01-REKap01E_L.pdf · Studie der Standish Group, 2010. 1. Einführung 6 Schwierigkeiten/Probleme Verschiedene, sich widersprechende