Sie müssen entscheiden, welche Arbeitsergebnisse verwendet werden sollen und wie. Außerdem müssen Sie jedes
Arbeitsergebnis so anpassen, dass es den Anforderungen des Projekts entspricht.
Die folgende Tabelle enthält eine Liste der empfohlenen und optionalen (die nur in bestimmten Fällen verwendet werden
können) Arbeitsergebnisse aus der Disziplin Anforderungen. Weitere Hinweise zur Anpassung finden Sie im Abschnitt
"Anpassen" auf der Seite mit der Beschreibung des jeweiligen Arbeitsergebnisses.
Arbeitsergebnis
|
Zweck
|
Anpassen (optional, empfohlen)
|
Arbeitsergebnis: Anwendungsfallmodell (Arbeitsergebnis: Akteur, Arbeitsergebnis: Anwendungsfall, Arbeitsergebnis: Anwendungsfallpaket)
|
Anwendungsfälle werden verwendet, um funktionale Anforderungen zu definieren.
|
Empfohlen für die meisten Projekte.
Anwendungsfälle sind die empfohlene Methode für die Erfassung funktionaler Anforderungen.
|
Arbeitsergebnis: Storyboard
|
Projekte mit Verhaltensanforderungen, die nicht klar verständlich sind, sollten Storyboarding als
Mittel für die Sondierung von Anforderungen verwenden.
|
Optional
Es können auch anderen Techniken für die Sondierung von Anforderungen verwendet werden.
|
Arbeitsergebnis: Glossar
|
Stellen sicher, dass jeder am Projekt Beteiligte dasselbe Vokabular verwendet.
|
Empfohlen für die meisten Projekte.
|
Arbeitsergebnis: Anforderungsattribute
|
Eine Datenbank mit Anforderungsattributen hilft sicherzustellen, dass Anforderungen ordnungsgemäß
priorisiert, überwacht und verfolgt werden.
|
Optional
In Projekten mit relativ wenig Anforderungen ist eine Datenbank mit Anforderungsattributen jedoch
nicht unbedingt erforderlich.
|
Arbeitsergebnis: Anforderungsmanagementplan
|
Beschreibt die zu erfassenden Informationen und Kontrollmechanismen, die für die Bewertung,
Berichtserstellung und Kontrolle von Änderungen an den Produktanforderungen zu verwenden sind. Wenn das
Anforderungsmanagement sehr komplex ist und die Erkennbarkeit für Kunden gewährleistet sein muss, ist
unter Umständen ein separates Dokument erforderlich.
|
Optional
Projekte mit relativ wenig Anforderungen können einen schlanken Ansatz für das
Anforderungsmanagement wählen und die Anforderungen direkt im Softwareentwicklungsplan
dokumentieren.
Andere Projekte können einen strengeren Ansatz wählen und verfolgen, aber nur wenig oder keine
formalen Beschreibungen produzieren. Die zu erfassenden Anforderungsattribute können beispielsweise
implizit durch die Konfiguration von Tools dokumentiert werden.
|
Arbeitsergebnis: Spezifikation für
Softwareanforderungen
|
Sammelt alle Anforderungen in einem formal Dokument, das dem Kunden bereitgestellt wird.
|
Optional
In weniger formalen Projekten ist ein formales Dokument nicht unbedingt erforderlich.
|
Arbeitsergebnis: Stakeholder-Anfragen
|
Erfasst alle Anforderungen, die an das Projekt gestellt werden, sowie Informationen dazu, wie diese
Anforderungen berücksichtigt wurden.
|
Empfohlen für die meisten Projekte.
Um ein System zu erstellen, das den Anforderungen der Stakeholder genügt, ist es wichtig, die
Anforderungen der Stakeholder sorgfältig zu sondieren und zu prüfen.
Viele Projekte verwalten Stakeholder-Anfragen lediglich als Kategorie von Änderungsanfragen. Andere
Projekte erfassen Stakeholder-Anfragen nur formlos.
|
Arbeitsergebnis: Ergänzende Spezifikationen
|
Erfasst nicht funktionale Anforderungen.
|
Empfohlen für die meisten Projekte.
|
Arbeitsergebnis: Vision
|
Erfasst Anforderungen und Designvorgaben auf sehr hoher Ebene, um dem Leser das zu entwickelnde System
nahezubringen.
|
Empfohlen für die meisten Projekte.
|
Welche Berichte verwendet werden, richtet sich nach den Berichtstools, die dem Projekt zur Verfügung stehen. Wenn Tools
für Berichterstellung verfügbar sind, wird empfohlen, Berichte für modellorientierte oder datenbankorientierte
Arbeitsergebnisse wie Anwendungsfälle und Akteure zu generieren. Vorhandene Berichte in Ihrer RUP-Konfiguration werden
auf den Beschreibungsseiten für Arbeitsergebnisse bereitgestellt und unter dem jeweiligen Arbeitsergebnis im
Baumstrukturbrowser gruppiert.
Dieser Abschnitt ist nur anwendbar, wenn Anforderungen in einem formalen Vertrags-, Standard- oder
Spezifikationsdokument an das Anforderungsmanagement herangetragen werden. Dieses Dokument wird als "eingereichte
Anforderungsspezifikation" bezeichnet.
Während der Sondierung der Anforderungen erfassen Sie die Anforderungen in den folgenden Dokumenten: Arbeitsergebnis: Vision, Arbeitsergebnis: Stakeholder-Anfragen, Arbeitsergebnis: Anwendungsfallmodell, Arbeitsergebnis: Ergänzende Spezifikationen.
Legen Sie fest, ob die eingereichte Anforderungsspezifikation verwaltet wird oder nicht. Beantworten Sie hier die Frage
"Soll die eingereichte Anforderungsspezifikation aktualisiert werden, wenn festgestellt wird, dass eine Anforderung
schlecht, falsch oder fehlerhaft ist?". Außerdem müssen Sie entscheiden, wie Traces oder
Referenzen zwischen der eingereichten Anforderungsspezifikation und dem Anwendungsfall verwaltet werden sollen.
Wählen Sie eine oder eine Kombination der folgenden Strategien:
-
Die eingereichte Anforderungsspezifikation nicht aktualisieren. Legen Sie die weitere Vorgehensweise des Systems in
Anwendungsfällen und ergänzenden Spezifikationen fest.
-
Die eingereichte Anforderungsspezifikation nicht aktualisieren, aber die Rückverfolgbarkeit ausgehend von den Anwendungsfällen verwalten.
-
Die eingereichte Anforderungsspezifikation mit allen Arbeiten und Kosten aktualisieren.
-
Die eingereichte Anforderungsspezifikation in eine ergänzende Spezifikation umwandeln, die Anforderungen enthält.
Die funktionalen Anforderungen können leicht in die Anwendungsfälle übertragen werden.
Die meisten Projekte finden, dass die Anzahl der schlechten, fehlerhaften oder falschen Anforderungen so hoch ist, dass
es keinen Sinn macht, die ursprüngliche eingereichte Anforderungsspezifikation zu verwalten. Sehr wenige Projekte haben
Kunden, die bereit sind, die Kosten für die Aktualisierung der eingereichten Anforderungsspezifikation mit neuen
Informationen, die während der Anwendungsfallmodellierung entdeckt werden, zu übernehmen.
Legen Sie nicht zu früh zu viel Gewicht auf dieses Thema. Zu Beginn eines Projekts glauben die Personen noch an die
erste Anforderungsspezifikation, aber nachdem sie sich in einem Anwendungsfall eine Weile mit dem Problembereich
beschäftigt haben, revidieren die meisten Personen ihre Meinung.
Legen Sie fest, wie die Anwendungsfälle genehmigt werden sollen. Es kann viel Zeit eingespart werden, wenn die Anzahl
der Anwendungsfälle beschränkt wird, die vom Kunden formal geprüft werden
müssen. Möglicherweise können Sie mit dem Kunden übereinkommen, dass nur ein Teil aller Anwendungsfälle formal geprüft
wird.
Wählen Sie eine oder mehr der folgenden Strategien:
-
Alle Anwendungsfälle müssen formalen Prüfungen unterzogen werden, an denen Vertreter projektexterner Parteien
teilnehmen.
-
Einige sekundäre Anwendungsfälle können auf vereinfachtem Wege genehmigt werden, durch formlose oder eine interne
formale Prüfung.
Sekundäre Anwendungsfälle sind Anwendungsfälle, die zwar für das System, aber nicht für die Aufgaben des primären
Benutzers wichtig sind. Dies sind beispielsweise Anwendungsfälle, die sich auf die Administration und Pflege des
Systems beziehen (z. B. Benutzer zum System hinzufügen, Berechtigungen ändern und Sicherungen erstellen). Obwohl das
System ohne diese Anwendungsfälle nicht funktioniert, sind sie jedoch nicht von primärem Interesse für die wichtigen
Benutzer.
Welche Strategie gewählt wird, richtet sich nach der Beziehung zum Kunden. Vertraut der Kunde Ihnen, dass Sie die
unterstützenden Anwendungsfälle auch ohne formales Genehmigungsverfahren korrekt realisieren? Auch wenn Sie mit diesem
Verfahren Zeit einsparen, erreichen Sie trotzdem die erwartete Qualität des Anwendungsfallmodells?
Anmerkung: Eine Lösung für dieses Problem kann das Einbeziehen des Kunden in das Umfeld "Anforderungen" sein.
Die einbezogenen Kundenvertreter können die Anwendungsfälle genehmigen, anderen Kunden Empfehlungen geben, und das
gesamte Projekt gewinnt an Glaubwürdigkeit.
Weitere Informationen finden Sie in der Anleitung:
Prüfebenen.
|