Anforderungen für die Entwicklung

Anforderungen beschreiben, was die Projektbeteiligten vom Produkt erwarten.Sie sollten die Anforderungen so formulieren, dass sie problemlos mit den Projektbeteiligten unter Verwendung des Vokabulars und der Konzepte der Geschäftssparte erörtert werden können.Anforderungen dürfen die Implementierung weder in Frage stellen noch von ihr abhängen.Anforderungen beinhalten nicht nur die Erwartungen der Benutzer an Verhalten und Servicequalität, sondern auch gesetzliche Einschränkungen und gewerbliche Normen.

Das Aufzeichnen von Anforderungen in Visual Studio Team Foundation Server mithilfe der Anforderungsarbeitsaufgabe bietet Ihnen die folgenden Vorteile:

• Überprüfen Sie, ob Anforderungen erfüllt wurden, indem Sie sie mit Testfällen verknüpfen.

• Überwachen Sie den Implementierungsstatus der Anforderungen, indem Sie sie mit Arbeitsaufgaben für eine Aufgabe verknüpfen.

• Gliedern Sie die Anforderungen in allgemeine und detailliertere Anforderungen, damit Sie sie leichter verwalten können und damit die Informationen in Statusberichten zusammengefasst werden können.

• Modellieren Sie die Anforderungen in Visual Studio Ultimate, und verknüpfen Sie in Team Foundation Server Modellelemente mit Anforderungen.

In diesem Thema wird nicht versucht, die umfangreiche Literatur zum Bestimmen von Anforderungen zu referieren.Stattdessen liegt der Schwerpunkt auf den Aspekten, die für die CMMI-konforme Verwendung der Visual Studio-Tools wichtig sind. Weitere Informationen zur CMMI finden Sie unter Hintergrundinformationen zu CMMI.

Die in diesem Thema beschriebenen Aktivitäten müssen wie alle Entwicklungsaktivitäten in keiner festen Reihenfolge ausgeführt werden.Entwickeln Sie ein Domänenmodell, während Sie Szenarien schreiben, da eine Aktivität durch die jeweils andere Aktivität verbessert wird.Entwickeln Sie die Szenarien kurz vor dem Zeitpunkt, zu dem sie codiert werden müssen.Nutzen Sie die Erfahrung mit bereits geschriebenem und in Demonstrationen verwendetem Code für die Szenarien, die noch implementiert werden müssen.

In diesem Thema

Zeitpunkt für das Entwickeln von Anforderungen

Schreiben einer Zielsetzung

Schreiben von Szenarien

Modellieren der Geschäftssparte

Entwickeln von Servicequalitätsanforderungen

Überprüfen von Anforderungen

Validierung

Untersuchen und Bearbeiten der Anforderungen

Zeitpunkt für das Entwickeln von Anforderungen

Team Foundation Server unterstützt ein iteratives Vorgehen. Diese Arbeitsweise ist am effektivsten, wenn die ersten Iterationen dazu verwendet werden, Feedback von potenziellen Benutzern und anderen Projektbeteiligten einzuholen. Anhand des Feedbacks können Sie die Anforderungen verbessern, die für zukünftige Iterationen festgelegt wurden.Dies führt zu einem Produkt, dessen letztendliche Installation weitaus erfolgreicher ist als die Installation eines im gleichen Zeitraum ohne Benutzertests entwickelten Produkts.Wenn das Projekt eine von vielen Komponenten in einem größeren Programm ist, ermöglicht die frühe Integration in andere Komponenten den Programmarchitekten das Verbessern des Gesamtprodukts.

Diese Flexibilität muss gegen die Anforderung von verlässlichen Festlegungen gegenüber Kunden oder Partnern in parallelen Projekten abgewogen werden.

Daher werden Anforderungen während des gesamten Projekts in einem bestimmten Ausmaß entwickelt und verfeinert.Da sich die detaillierten Anforderungen wahrscheinlich während des Projekts ändern, verursacht das vollständige Bestimmen der Anforderungen vor der entsprechenden Implementierung mit hoher Wahrscheinlichkeit unnötigen Aufwand.

• Entwickeln Sie in Iteration 0 einen Satz von Anforderungen, die die Hauptfunktionen beschreiben und deren Details gerade ausreichen, um einen Produktplan zu bilden.Im Produktplan werden Iterationen Anforderungen zugewiesen, und es wird angegeben, welche Anforderung am Ende jeder Iteration erfüllt ist.Erstellen Sie ein Domänenmodell der Hauptkonzepte und -aktivitäten, und definieren Sie das Vokabular, das sowohl bei der Diskussion mit den Benutzern als auch bei der Implementierung für diese Konzepte verwendet wird.Bestimmen Sie allgemeine Anforderungen, die für jede Funktion gelten, z. B. Sicherheit und andere Anforderungen an die Servicequalität.

• Entwickeln Sie zu Beginn oder kurz vor Beginn jeder Iteration die Anforderungen für diese Funktionen mit größerer Detailgenauigkeit.Bestimmen Sie die Schritte, die von den Benutzern ausgeführt werden, und definieren Sie sie mithilfe von Aktivitäts- oder Sequenzdiagrammen.Definieren Sie, was in Ausnahmefällen geschieht.

• Überprüfen Sie so oft wie möglich alle Anforderungen, die implementiert wurden.Für alle Bereiche geltende Anforderungen, z. B. Sicherheit, müssen mit Tests überprüft werden, die für jede neue Funktion erweitert werden.Automatisieren Sie nach Möglichkeit die Tests, da automatische Tests kontinuierlich ausgeführt werden können.

Verwalten von Anforderungsänderungen

Mithilfe der folgenden Richtlinien können Sie einen inkrementellen Prozess ausführen, während Sie ihn auf die Erfüllung von CMMI-Anforderungen überwachen.

• Ändern Sie die für eine Iteration festgelegten Anforderungen nicht.Im seltenen Fall einer abrupten Änderung der Umstände müssen Sie eventuell eine Iteration abbrechen, den Produktplan überprüfen und eine neue Iteration starten.

• Suchen Sie nach Ungewissheiten in den Anforderungen.Versuchen Sie, den Plan so zu organisieren, dass die Benutzererfahrung in frühen Iterationen Informationen liefert, mit denen die Ungewissheiten verringert werden.

• Verwenden Sie Arbeitsaufgaben für Änderungsanforderungen, um bereits implementiertes Verhalten zu ändern, sofern die angeforderte Änderung nicht bereits Teil des Plans ist.Verknüpfen Sie jede Änderungsanforderung mit den entsprechenden Anforderungsarbeitsaufgaben.Weitere Informationen finden Sie unter Änderungsanforderung (CMMI).

• Überprüfen Sie Änderungsanforderungen, wenn Sie vor jeder Iteration das Produkt überprüfen.Untersuchen Sie die Auswirkungen der Anforderung auf abhängige Projekte und Benutzer, und schätzen Sie die Kosten in Hinsicht auf Änderungen im Code.Wenn eine Änderungsanforderung akzeptiert wird, aktualisieren Sie die Anforderung.

• Aktualisieren Sie die Tests entsprechend jeder Anforderungsänderung.

• Legen Sie einen Stichtag (z. B. nach Iteration 2 oder 3) fest, nach dem die Notwendigkeit von Anforderungänderungen eine viel stärkere Begründung erfordert.Wenn das Projekt für einen zahlenden Kunden entwickelt wird, ist dies das Datum, an dem der Kunde einen Basissatz von Anforderungen bestätigen muss und ab dem die Bezahlung nicht mehr auf Stundenbasis, sondern zu einem Festpreis erfolgt.

• Verwenden Sie Fehlerarbeitsaufgaben, um implementiertes Verhalten aufzuzeichnen, das von den expliziten oder impliziten Anforderungen abweicht.Erstellen Sie ggf. einen neuen Test, mit dem der Fehler abgefangen wird.

Schreiben einer Zielsetzung

Erörtern Sie mit dem Team eine Zielsetzung, und zeigen Sie sie im Webportal des Projekts für Team Foundation Server an.

Eine Zielsetzung ist eine kurze Zusammenfassung der von dem Produkt gebotenen Vorteile.Welche Aktionen können die Benutzer ausführen, die Sie zuvor nicht ausführen konnten?Die Zielsetzung hilft, den Aufgabenbereich des Produkts zu bestimmen.

Wenn das Produkt bereits vorhanden ist, schreiben Sie eine Zielsetzung für diese Version.Welche Aktionen können die Benutzer des Produkts ausführen, die Sie zuvor nicht ausführen konnten?

Schreiben von Szenarien

Erstellen Sie gemeinsam mit dem Kunden und anderen Projektbeteiligten Szenarien, und geben Sie sie als Anforderungsarbeitsaufgaben ein, wobei das Feld Anforderungstyp auf Szenario festgelegt ist.

Ein Szenario oder ein Anwendungsfall beschreibt eine Sequenz von Ereignissen, zeigt, wie ein bestimmtes Ziel erreicht wird, und beinhaltet i. d. R. Interaktionen zwischen Personen oder Organisationen und Computern.

Weisen Sie dem Szenario einen aussagekräftigen Titel zu, mit dem es sich eindeutig von anderen Szenarien unterscheiden lässt, wenn die Szenarien in einer Liste angezeigt werden.Stellen Sie sicher, dass der Hauptakteur oder die Hauptakteure angegeben werden und dass ihr Ziel eindeutig beschrieben wird.Beispiel für einen guten Titel:

Kunde kauft eine Mahlzeit.

Sie können ein Szenario in den folgenden Formen schreiben.Manchmal ist es hilfreich, mehrere Formen zu verwenden:

• Ein oder zwei Sätze in der Arbeitsaufgabenbeschreibung:

  Ein Kunde bestellt eine Mahlzeit auf einer Website und bezahlt mit einer Kreditkarte.Die Bestellung wird an ein Restaurant weitergeleitet, das die Mahlzeit zubereitet und liefert.

• Nummerierte Schritte in der Arbeitsaufgabenbeschreibung:

  Ein Kunde besucht die Website und erstellt die Bestellung einer Mahlzeit. Die Website leitet den Kunden auf eine Zahlungswebsite um, auf der die Zahlung durchgeführt wird. Der Arbeitsliste des Restaurants wird die Bestellung hinzugefügt. Das Restaurant bereitet die Mahlzeit zu und liefert sie.

• Storyboard.In einem Storyboard wird die Story als Bildgeschichte erzählt.Sie können diese in PowerPoint zeichnen.Fügen Sie die Storyboarddatei an die Anforderungsarbeitsaufgabe an, oder laden Sie die Datei in das Teamportal hoch, und fügen Sie der Arbeitsaufgabe einen Link hinzu.

  Ein Storyboard eignet sich besonders zum Darstellen von Benutzerinteraktionen.Für ein Geschäftsszenario wird jedoch empfohlen, einen Entwurfsstil zu verwenden, der deutlich macht, dass es sich nicht um den endgültigen Entwurf für die Benutzeroberfläche handelt.

• Anforderungsdokumente.Anforderungsdokumente bieten Ihnen die Möglichkeit, jede Anforderung mit dem entsprechenden Detailgrad zu beschreiben.Wenn Sie sich für die Verwendung von Dokumenten entscheiden, erstellen Sie für jede Anforderung ein Word-Dokument, und fügen Sie das Dokument an die Anforderungsarbeitsaufgabe an, oder laden Sie die Datei in das Teamportal hoch, und fügen Sie der Arbeitsaufgabe einen Link hinzu.

• UML (Unified Markup Language)-Sequenzdiagramm.Ein Sequenzdiagramm ist besonders nützlich, wenn mehrere Parteien interagieren.Beispielsweise müssen zum Bestellen der Mahlzeit der Kunde, die DinnerNow-Website, das Zahlungssystem und das Restaurant in einer bestimmten Reihenfolge interagieren.Zeichnen Sie das Sequenzdiagramm in einem UML-Modell, checken Sie es in Team Foundation Server ein, und geben Sie in der Anforderungsarbeitsaufgabe einen Link ein.Weitere Informationen finden Sie unter UML-Sequenzdiagramme: Richtlinien.

Spezifische Szenarien

Schreiben Sie zunächst spezifische Szenarien, die an einem bestimmten Satz von Akteuren in einer spezifischen Reihenfolge ausgerichtet sind.Beispiel: "Carlos bestellt auf der DinnerNow-Website eine Pizza und ein Knoblauchbrot.Die Website leitet Carlos an den Zahlungsdienst der Woodgrove Bank um.Die Pizza wird von Fourth Coffee zubereitet und geliefert."

Mithilfe spezifischer Szenarien können Sie sich das System in Betrieb vorstellen, und sie sind äußerst hilfreich, wenn Sie zunächst eine Funktion untersuchen.

Sie können auch nützlich sein, um benannte Personas zu erstellen, die Hintergrundinformationen und weitere Aktivitäten von Personen und Organisationen beschreiben.Carlos ist ohne festen Wohnsitz und nutzt ein Internetcafe. Wendy lebt in einer geschlossenen Wohnanlage. Sanjay bestellt Mahlzeiten für seine Frau an ihrem Arbeitsplatz. Contoso besitzt weltweit 2.000 Restaurants. Die Betreiber von Fourth Coffee sind ein Paar, das per Fahrrad ausliefert.

Allgemeinere Szenarien, in denen Begriffe wie "ein Kunde", "eine Menüposition" usw. verwendet werden, können bequemer sein, jedoch ist die Wahrscheinlichkeit geringer, dass sie zur Ermittlung nützlicher Funktionen führen.

Detailgrad

Schreiben Sie in Iteration 0 einige wichtige Szenarien mit einer gewissen Detailgenauigkeit, schreiben Sie jedoch die meisten Szenarien als allgemeine Szenarien.Wenn eine Iteration bevorsteht, in der ein bestimmtes Szenario vollständig oder teilweise implementiert werden soll, fügen Sie weitere Details hinzu.

Wenn Sie das erste Mal über ein Szenario nachdenken, kann es nützlich sein, den Geschäftskontext und sogar Aspekte zu beschreiben, in denen das Produkt nicht enthalten ist.Beschreiben Sie z. B. die DinnerNow-Methode der Lieferung: Organisiert jedes Restaurant die eigenen Lieferungen, oder betreibt DinnerNow einen Lieferdienst?Die Antworten auf solche Fragen bieten nützlichen Kontext für das Entwicklungsteam.

Die ausführlicheren Szenarien, die Sie zu Beginn einer Iteration entwickeln, können Benutzeroberflächeninteraktionen beschreiben, und Storyboards können Benutzeroberflächenlayout darstellen.

Organisieren der Szenarien

Sie können Szenarien mit den folgenden Methoden organisieren:

• Zeichnen Sie Anwendungsfalldiagramme, in denen jedes Szenario als Anwendungsfall dargestellt wird.Diese Methode wird empfohlen, da auf diese Weise die Szenarien sehr einfach dargestellt und erörtert werden können.Weitere Informationen finden Sie unter UML-Anwendungsfalldiagramme: Richtlinien.

  • Verknüpfen Sie jeden Anwendungsfall mit der Arbeitsaufgabe, die das Szenario definiert.Weitere Informationen finden Sie unter Verknüpfen von Modellelementen und Arbeitsaufgaben.

  • Zeichnen Sie Erweiterungsbeziehungen, um zu zeigen, dass ein Szenario eine Variante eines anderen Szenarios ist.Beispielsweise ist "Kunde gibt unterschiedliche Rechnungs- und Lieferadresse an" eine Erweiterung des grundlegenden Anwendungsfalls "Kunde führt eine Bestellung aus".Erweiterungen sind besonders nützlich, um Szenarien auszusondern, die in einer späteren Iteration implementiert werden.

  • Zeichnen Sie Einschlussbeziehungen, um z. B. die Prozedur "Kunde meldet sich an" auszusondern, die mehreren Anwendungsfällen gemeinsam ist.

  • Zeichnen Sie Verallgemeinerungsbeziehungen zwischen allgemeinen Szenarien, z. B. "Kunde zahlt", und spezifischen Varianten, z. B. "Kunde zahlt mit Kreditkarte".

• Erstellen Sie in Team Foundation Server Links zwischen übergeordneten und untergeordneten Arbeitsaufgaben des Szenarios. In Team Explorer können Sie die Hierarchie anzeigen.Weitere Informationen finden Sie unter Einfügen von Anforderungen in einen Produktplan.

Modellieren der Geschäftssparte

Erstellen Sie ein UML-Modell, in dem die wichtigsten Aktivitäten und Konzepte für die Verwendung des Produkts beschrieben werden.Verwenden Sie die in diesem Modell definierten Begriffe als "universelle Sprache" in den Szenarien, in Diskussionen mit den Projektbeteiligten, auf der Benutzeroberfläche, in Benutzerhandbüchern und im Code selbst.

Viele Anforderungen werden nicht explizit vom Kunden angegeben, und das Verständnis der impliziten Anforderungen hängt vom Verständnis der Geschäftssparte ab, d. h. vom Kontext, in dem das Produkt ausgeführt wird.Das Erfassen der Anforderungen in einer unbekannten Sparte umfasst daher das Sammeln von Kenntnissen zu diesem Kontext.Nachdem diese Kenntnisse erlangt wurden, können sie in mehreren Projekten verwendet werden.

Speichern Sie das Modell in der Versionskontrolle.

Weitere Informationen finden Sie unter Modellieren von Benutzeranforderungen.

Modellieren von Verhalten

Zeichnen Sie Aktivitätsdiagramme, um Szenarien zusammenzufassen.Verwenden Sie Verantwortlichkeitsbereiche, um die Aktionen zu gruppieren, die von unterschiedlichen Akteuren ausgeführt werden.Weitere Informationen finden Sie unter UML-Aktivitätsdiagramme: Richtlinien.

Obwohl ein Szenario normalerweise eine bestimmte Sequenz von Ereignissen beschreibt, werden in einem Aktivitätsdiagramm alle Möglichkeiten dargestellt.Das Zeichnen eines Aktivitätsdiagramms kann Sie dazu motivieren, über alternative Sequenzen nachzudenken und die Geschäftskunden zu fragen, was in diesen Fällen geschieht.

In der folgenden Abbildung ist ein einfaches Beispiel für ein Aktivitätsdiagramm dargestellt.

Wenn der Austausch von Nachrichten wichtig ist, ist es eventuell sinnvoller, ein Sequenzdiagramm zu verwenden, das für jeden Akteur und jede wichtige Produktkomponente eine Lebenslinie enthält.

Mit Anwendungsfalldiagrammen können Sie die unterschiedlichen Aktivitätsflüsse zusammenfassen, die von dem Produkt unterstützt werden.Jeder Knoten im Diagramm stellt eine Reihe von Interaktionen zwischen den Benutzern und der Anwendung dar, mit denen ein bestimmtes Benutzerziel erreicht werden soll.Sie können auch allgemeine Sequenzen und optionale Erweiterungen in getrennte Anwendungsfallknoten zerlegen.Weitere Informationen finden Sie unter UML-Anwendungsfalldiagramme: Richtlinien.

In der folgenden Abbildung ist ein einfaches Beispiel für ein Anwendungsfalldiagramm dargestellt.

Modellieren von Konzepten

Zeichnen Sie Domänenklassendiagramme, um die wichtigen Entitäten und ihre Beziehungen zu beschreiben, die in den Szenarien genannt werden.Im DinnerNow-Modell werden z. B. Restaurant, Menü, Bestellung, Menüposition usw. dargestellt.Weitere Informationen finden Sie unter UML-Klassendiagramme: Richtlinien.

Bezeichnen Sie die Rollen (Enden) der Beziehungen mit Namen und Kardinalitäten.

In einem Domänenklassendiagramm fügen Sie normalerweise keine Vorgänge an die Klassen an.Im Domänenmodell beschreiben die Aktivitätsdiagramme das Verhalten.Das Zuweisen von Zuständigkeiten zu Programmklassen ist Teil der Entwicklungsarbeit.

In der folgenden Abbildung ist ein einfaches Beispiel für ein Klassendiagramm dargestellt.

Statische Einschränkungen

Fügen Sie den Klassendiagrammen Einschränkungen hinzu, die die Attribute und Beziehungen regeln.Beispielsweise müssen alle Positionen einer Bestellung aus demselben Restaurant stammen.Diese Typen von Regeln sind für den Entwurf des Produkts wichtig.

Modellkonsistenz

Stellen Sie sicher, dass das Modell und die Szenarien konsistent sind.Eine der wirkungsvollsten Verwendungsmöglichkeiten eines Modells ist das Auflösen von Mehrdeutigkeiten.

• In den Szenariobeschreibungen werden die Begriffe verwendet, die im Modell definiert sind, und sie sind mit den im Modell definierten Beziehungen konsistent.Wenn im Modell Menüpositionen definiert sind, dürfen diese in den Szenarien nicht als Produkte bezeichnet werden.Wenn das Klassendiagramm zeigt, dass eine Menüposition zu genau einem Menü gehört, darf in den Szenarien nicht die gemeinsame Verwendung einer Position in mehreren Menüs beschrieben werden.

• Jedes Szenario beschreibt eine Reihe von Schritten, die in den Aktivitätsdiagrammen zugelassen werden.

• Szenarien oder Aktivitäten beschreiben, wie jede Klasse und jede Beziehung im Klassendiagramm erstellt und zerstört wird.Beispiel: In welchem Szenario wird eine Menüposition erstellt?Wann wird eine Bestellung zerstört?

Entwickeln von Servicequalitätsanforderungen

Erstellen Sie Arbeitsaufgaben, die Servicequalitätsanforderungen angeben.Legen Sie das Feld Anforderungstyp auf Servicequalität fest.

Servicequalitätsanforderungen oder nicht auf Funktionen bezogene Anforderungen umfassen Leistung, Benutzerfreundlichkeit, Zuverlässigkeit, Verfügbarkeit, Datenintegrität, Sicherheit, Erschwinglichkeit, Betriebstauglichkeit und Aktualisierbarkeit, Lieferbarkeit, Wartbarkeit, Design und Verarbeitungsqualität.

Erwägen Sie jede dieser Kategorien für jedes Szenario.

Der Titel jeder Servicequalitätsanforderung sollte ihre Definition wiedergeben, indem ein Kontext, eine Aktion und ein Maß dargestellt werden.Sie können z. B. die folgende Anforderung erstellen: "Während einer Katalogsuche Suchergebnisse in weniger als drei Sekunden zurückgeben".

Außerdem ist es sinnvoll, weitere Details zu erfassen, die erläutern, warum die Anforderung notwendig ist.Beschreiben Sie, warum die Anforderung für die Persona von Nutzen ist und warum dieser Servicelevel erforderlich ist.Stellen Sie Kontext und eine Begründung bereit.Diese Erläuterung kann nützliche Risikomanagementinformationen enthalten, z. B. Daten aus einer Marktumfrage, einer Kundenfokusgruppe oder einer Nutzbarkeitsstudie; Helpdeskberichte/-tickets oder andere Einzelnachweise.

Verknüpfen Sie die Servicequalitätsanforderung mit jedem Szenario (Anforderungsarbeitsaufgabe), das von der Servicequalität betroffen ist.Durch das Verknüpfen von verwandten Arbeitsaufgaben können Benutzer von Team Foundation Server abhängige Anforderungen nachverfolgen.Abfragen und Berichte können zeigen, wie sich Servicequalitätsanforderungen auf die Funktionsanforderungen auswirken, die als Szenarien erfasst werden.

Überprüfen von Anforderungen

Wenn die Anforderungen geschrieben oder aktualisiert wurden, sollten sie von den entsprechenden Projektbeteiligten überprüft werden, um sicherzustellen, dass sie alle Benutzerinteraktionen mit dem Produkt hinreichend beschreiben.Zu den Projektbeteiligte können im Allgemeinen ein Experte, ein Business Analyst und ein Benutzeroberflächenarchitekt zählen.Die Szenarien werden auch überprüft, um sicherzustellen, dass sie ohne Wirren und Probleme im Projekt implementiert werden können.Wenn Probleme entdeckt werden, müssen die Szenarien korrigiert werden, damit sie beim Abschluss dieser Aktivität gültig sind.

Erstellen Sie eine Überprüfungsarbeitsaufgabe, um die Überprüfung nachzuverfolgen.Dieses Element bietet einen wichtigen Nachweis für eine SCAMPI (Standard CMMI Appraisal Method for Process Improvement)-Bewertung und dient möglicherweise in der Zukunft als gute Informationsquelle für die Fehlerursachenanalyse.

Überprüfen Sie jedes Szenario auf die folgenden Eigenschaften:

• Beim Schreiben des Szenarios wurde berücksichtigt, welche Aufgabe Benutzer ausführen müssen, über welche Kenntnisse sie bereits verfügen und welche Interaktion mit dem Produkt sie erwarten.

• Das Szenario beschreibt ein Problem, und seine Aussagefähigkeit wird nicht durch vorgeschlagene Lösungen des Problems verringert.

• Alle relevanten Interaktionen der Benutzer mit dem Produkt werden genannt.

• Der Experte, der Business Analyst und der Benutzeroberflächenarchitekt überprüfen jedes Szenario im Kontext des Projekts, um sicherzustellen, dass alle Szenarien erfolgreich implementiert werden können.Wenn ein Szenario nicht gültig ist, wird es überarbeitet, damit es gültig ist.

• Das Szenario kann mit den verfügbaren Verfahren, Tools und Ressourcen und innerhalb des vorhandenen Budgets und Zeitplans implementiert werden.

• Das Szenario kann nur auf eine einzige, leicht verständliche Weise interpretiert werden.

• Das Szenario führt zu keinem Konflikt mit anderen Szenarien.

• Das Szenario ist testfähig.

Validierung

Planen Sie die Bereitstellung von Betaversionen des Produkts in dessen Arbeitsumgebung vor der endgültigen Version des Produkts.Planen Sie das Aktualisieren der Anforderungen auf Grundlage des Feedbacks der Projektbeteiligten von dieser Bereitstellung.

Mit der Validierung wird sichergestellt, dass das Produkt den vorgesehenen Zweck in seiner Betriebsumgebung erfüllt.In MSF for CMMI erfolgt die Validierung, indem während des gesamten Projekts am Ende jeder Iteration die funktionsfähige Software den Projektbeteiligten vorgeführt wird.Der Zeitplan wird so erstellt, dass gegenüber den Entwicklern geäußerte Bedenken aus frühen Demonstrationen im Plan für die verbleibenden Iterationen berücksichtigt werden können.

Um eine echte Validierung zu erreichen, darf das Produkt nicht nur in einer Demonstration oder in einem simulierten Kontext ausgeführt werden.Es sollte nach Möglichkeit unter realen Bedingungen getestet werden.

Untersuchen und Bearbeiten der Anforderungen

Die Szenario- und Servicequalitätsanforderungen, die Grundlage der meisten Entwicklungsaufgaben sind, können mit der Kundenanforderungsabfrage überprüft werden.Wenn Sie alle Anforderungen anzeigen möchten, können Sie eine Abfrage schreiben, die alle Arbeitsaufgaben vom Anforderungsarbeitsaufgabentyp zurückgibt.Legen Sie die Ergebnisspalten so fest, dass sie den Iterationspfad anzeigen.Weitere Informationen finden Sie unter Freigegebene Abfragen (CMMI).

Zusätzlich zum direkten Anzeigen der Abfrage in Team Explorer oder Team Web Access können Sie sie in Office Excel oder Office Project öffnen.Diese Tools eignen sich besser zum Bearbeiten und Hinzufügen von Arbeitsaufgaben als Batch.Weitere Informationen finden Sie unter Arbeiten in Microsoft Excel und Microsoft Project, die mit Team Foundation Server verbunden sind und Durchführen einer Top-Down-Planung mithilfe einer Strukturliste der Arbeitsaufgaben (in Excel).

Das Team sollte die meisten Anforderungen in den frühen Iterationen des Projekts erstellen.Das Hinzufügen neuer Anforderungen und das Anpassen anderer Anforderungen erfolgt, wenn Feedback aus frühen Versionen erhalten wird.

Zusätzliche Ressourcen

Weitere Informationen finden Sie in den folgenden Webressourcen:

• A Practical Guide to Feature Driven Development von Stephen R.Palmer and Malcolm J.Felsing; Prentice-Hall PTR, 2002.

• Streamlined Object Modeling: Patterns, Rules and Implementation von Jill Nicola, Mark Mayfield und Mike Abney, Prentice Hall PTR 2001.

• Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process von Scott Ambler, Wiley 2002.

• Domain Driven Design: Tackling Complexity in the Heart of Software von Eric Evans, Addison Wesley Professional 2003.

• Object Design: Roles, Responsibilities and Collaborations von Rebecca Wirfs-Brock und Alan McKean, Addison Wesley Professional 2002.