Modellieren von Benutzeranforderungen

Microsoft Visual Studio Ultimate hilft Ihnen dabei, die Anforderungen der Benutzer zu verstehen, zu erläutern und zu vermitteln, indem Sie Diagramme über die Aktivitäten der Benutzer und die Rolle, die das System beim Erreichen der Ziele der Benutzer spielt, zeichnen. Ein Anforderungsmodell ist ein Satz dieser Diagramme, wobei sich jedes auf einen anderen Aspekt der Benutzeranforderungen konzentriert.

Unter Modellieren der Geschäftsdomäne finden Sie eine Videodemonstration.

Ein Anforderungsmodell hilft Ihnen:

• sich auf das externe Verhalten des Systems, unabhängig von seinem internen Entwurf, zu konzentrieren.

• die Anforderungen der Benutzer und Projektbeteiligten viel eindeutiger zu beschreiben, als dies mit natürlicher Sprache möglich ist.

• ein einheitliches Begriffsglossar zu definieren, das von Benutzern, Entwicklern und Testern verwendet werden kann.

• Lücken und mangelnde Übereinstimmungen in den Anforderungen zu reduzieren.

• die Arbeit, die bei der Änderung der Anforderungen anfällt, zu verringern.

• die Reihenfolge, in der Funktionen entwickelt werden, zu planen.

• Verwenden Sie die Modelle als eine Grundlage für Systemtests, um die Beziehung zwischen den Tests und den Anforderungen genau darzustellen. Wenn sich die Anforderungen ändern, ermöglicht Ihnen diese Beziehung, die Tests ordnungsgemäß zu aktualisieren. Auf diese Weise wird sichergestellt, dass das System die neuen Anforderungen erfüllt.

Ein Anforderungsmodell bietet den größten Vorteil, wenn Sie es bei Diskussionen mit den Benutzern oder ihren Vertretern gezielt einsetzen und zu Anfang jeder Iteration erneut betrachten. Sie müssen es nicht im Detail fertigstellen, bevor Sie mit dem Schreiben von Code beginnen können. Eine teilweise funktionierende Anwendung, auch wenn sie sehr vereinfacht ist, bildet im Allgemeinen eine äußerst anregende Diskussionsgrundlage, um die Anforderungen der Benutzer zu ermitteln. Das Modell ist eine effektive Möglichkeit, die Ergebnisse solcher Diskussionen zusammenzufassen. Weitere Informationen finden Sie unter Verwenden von Modellen im Entwicklungsprozess.

Allgemeine Aufgaben

Sie können verschiedene Ansichten der Anforderungen der Benutzer erstellen. Jede Ansicht stellt einen bestimmten Informationstyp bereit. Wenn Sie diese Ansichten erstellen, empfiehlt es sich, häufig von der einen zur anderen zu wechseln. Sie können mit jeder beliebigen Ansicht beginnen.

Beachten Sie, dass die meisten Diagrammtypen auch für andere Zwecke verwendet werden können. Eine Übersicht über die Diagrammtypen finden Sie unter Entwickeln von Modellen für den Softwareentwurf. Grundlegende Informationen zum Zeichnen von Diagrammen finden Sie unter Gewusst wie: Bearbeiten eines UML-Modells und Bearbeiten von Diagrammen.

Beschreiben, wie das System verwendet wird

Erstellen Sie Anwendungsfalldiagramme, um zu beschreiben, wer das System verwendet und wozu. Ein Anwendungsfall stellt ein Ziel eines Benutzers dar, der das System verwendet, und die Prozedur, die er zum Erreichen dieses Ziels durchführt.

Ein Beispiel hierfür ist ein System, mit dem online Mahlzeiten verkauft werden. Das System muss es den Kunden ermöglichen, aus einer Speisekarte auszuwählen, und muss den beteiligten Restaurants Gelegenheit geben, die Speisekarte zu aktualisieren. Sie können diese Anforderungen in einem Anwendungsfalldiagramm zusammenfassen:

Sie können auch darstellen, wie sich ein Anwendungsfall aus kleineren Fällen zusammensetzt. Das Bestellen einer Mahlzeit umfasst beispielsweise auch das Kaufen einer Mahlzeit, beinhaltet also auch Zahlung und Lieferung:

Sie können außerdem darstellen, welche Anwendungsfälle in den Bereich des Systems fallen, das sie entwickeln. Das System in der Abbildung ist zum Beispiel nicht an dem Anwendungsfall des Mahlzeiten-Lieferservice (Deliver Meal) beteiligt. Dies hilft Ihnen dabei, den Kontext für die Entwicklungsarbeit festzulegen. (In einem Anwendungsfalldiagramm können Subsystemcontainer verwendet werden, um das System oder seine Komponenten darzustellen.)

Außerdem unterstützt es Ihr Team bei der Diskussion darüber, was in nachfolgende Versionen aufgenommen werden soll. So können Sie zum Beispiel diskutieren, ob in der ersten Version des Systems die Bezahlung der Mahlzeit (Pay for Meal) direkt zwischen dem Restaurant und dem Kunden abgewickelt werden soll statt über das System. In diesem Fall könnten Sie die Bezahlung des Gerichts (Pay for Meal) für die erste Version aus dem Rechteck für das Dinner Now System verschieben.

Ein Anwendungsfalldiagramm bietet nur eine Zusammenfassung der Anwendungsfälle. Um ausführlichere Beschreibungen bereitzustellen, können Sie die Anwendungsfälle im Diagramm mit separaten Dokumenten und anderen Diagrammen verknüpfen. Informationen hierzu finden Sie unter Gewusst wie: Verknüpfen eines Anwendungsfalls mit Dokumenten und Diagrammen.

Ein Anwendungsfalldiagramm zu zeichnen hilft dem Team:

• sich darauf zu konzentrieren, was die Benutzer von der Verwendung des Systems erwarten, ohne von Details der Implementierung abgelenkt zu werden.

• den Umfang des Systems oder bestimmter Versionen des Systems zu diskutieren.

Weitere Informationen finden Sie unter den folgenden Themen:

Definieren von Begriffen, die zum Beschreiben der Anforderungen verwendet wurden

Sie können anhand von UML-Klassendiagrammen ein einheitliches Vokabular der Geschäftskonzepte erstellen, das für folgende Zwecke verwendet werden kann:

• von den Benutzern selbst zur Diskussion des Geschäfts, in dem das System Anwendung findet.

• um die Anforderungen der Benutzer zu beschreiben, z. B. bei der Beschreibung von Anwendungsfällen, Geschäftsregeln und Benutzertextabschnitten.

• Informationstypen, die an der API des Systems oder durch die Benutzeroberfläche ausgetauscht werden.

• Beschreibungen von System- oder Akzeptanztests.

Wenn es für diesen Zweck verwendet wird, wird der Inhalt eines UML-Klassendiagramms ein konzeptionelles Klassendiagramm genannt. (Es wird auch als Domänenmodell oder Analyseklassenmodell bezeichnet.)

In einem konzeptionellen Klassendiagramm stellen Sie nur die Klassen dar, die für die Beschreibung der Anforderungen benötigt werden, ohne Details des internen Entwurfs des Systems zu zeigen. Das Diagramm zeigt keine Details des internen Entwurfs des Systems. Sie zeigen in konzeptionellen Klassen normalerweise keine Vorgänge oder Benutzeroberflächen.

Sie könnten zum Beispiel die folgenden konzeptionellen Klassen für das Dinner Now-System zeichnen:

Ein konzeptionelles Klassendiagramm stellt das Vokabular von Begriffen bereit, die Sie im gesamten Anforderungsmodell verwenden. So könnten Sie zum Beispiel in der ausführlichen Beschreibung des Anwendungsfalls Bestellung eines Gerichts (Order a Meal) Folgendes schreiben:

Der Kunde wählt eine Speisekarte (Menu), aus der er eine Bestellung (Order) erstellt, und erstellt anschließend Bestellpositionen (Order Items) in der Bestellung (Order), indem er Gerichte (Menu Items) aus der Speisekarte (Menu) auswählt.

Beachten Sie, dass die in der Beschreibung verwendeten Begriffe die Namen der Klassen im Modell sind. Durch das Diagramm entstehen keine Mehrdeutigkeiten bezüglich der Beziehungen zwischen diesen Klassen. So zeigt das Diagramm zum Beispiel eindeutig, dass jeder Bestellung (Order) nur eine Speisekarte (Menu) zugeordnet ist.

Missverständnisse hinsichtlich der Benutzeranforderungen lassen sich häufig auf Missverständnisse bezüglich der genauen Bedeutung von Wörtern zurückführen. So werden sich zum Beispiel die meisten Restaurants beim Verständnis der Begriffe Speisekarte (Menu) und Bestellung (Order) einig sein, wohingegen der Unterschied zwischen einer Position (Item) auf einer Bestellung und einem Gericht (Item) auf der Speisekarte weniger eindeutig ist. Wenn die Anforderungen mit den Geschäftsprojektbeteiligten besprochen werden, ist es wichtig, diese Unterschiede deutlich zu machen. Das Klassendiagramm ist ein nützliches Tool, um die Begriffe und ihre Beziehungen zu klären.

Das konzeptionelle Klassenmodell kann das grundlegende Vokabular bilden, mit dem die Geschäftslogik des Systems beschrieben werden kann. Die Klassen in der Software müssen in der Regel viel komplexer sein als das konzeptionelle Modell, da bei der Implementierung auch Aspekte wie die Leistung, Verteilung, Flexibilität usw. beachtet werden müssen. Ein System verfügt häufig über verschiedene Implementierungen einer konzeptionellen Klasse.

Bestellungen können z. B. in XML, SQL, HTML und C# in anderen Teilen des Systems und in anderen Benutzeroberflächen zwischen den Teilen dargestellt werden. Die Zuordnung zwischen einer Bestellung (Order) und einer Speisekarte (Menu) kann auf sehr verschiedene Weise dargestellt werden, z. B. als Verweise innerhalb des C#-Codes, als Relationen in einer Datenbank oder als Querverweis-IDs in XML. Trotz dieser Variationen bietet das konzeptionelle Modell wichtige Informationen, die für jeden Teil der Software Gültigkeit haben. Das im Beispiel aufgeführte Klassendiagramm zeigt, dass bei jeder Implementierung einer Bestellung (Order) immer nur eine Speisekarte (Menu) zugeordnet ist.

Ein Anforderungen-Klassendiagramm zu zeichnen hilft dem Team:

• die bei der Diskussion der Benutzeranforderungen verwendeten Grundbegriffe zu definieren und zu standardisieren.

• die Beziehungen zwischen diesen Begriffen zu klären.

Weitere Informationen finden Sie unter den folgenden Themen:

In einem konzeptionellen Klassendiagramm ist es in der Regel nicht sinnvoll, zur Darstellung der Navigierbarkeit Pfeile auf den Zuordnungen zu platzieren. Dies liegt daran, dass das Diagramm keine Implementierung darstellt. Die Zuordnungen stellen Beziehungen zwischen realen Objekten dar. Mit der folgenden Visual Studio-Erweiterung werden nicht direktionale Pfeile als Standardeinstellung festgelegt: Beispiel: Funktionen der UML-Domänenmodellierung.

Anzeigen von Geschäftsregeln

Eine Geschäftsregel ist eine Anforderung, die nicht einem bestimmten Anwendungsfall zugeordnet ist und im gesamten System beachtet werden muss.

Viele Geschäftsregeln stellen Einschränkungen für die Beziehungen zwischen den konzeptionellen Klassen dar. Sie können diese statischen Geschäftsregeln als Kommentare schreiben, die den relevanten Klassen in einem konzeptionellen Klassendiagramm zugeordnet sind. Beispiel:

Dynamische Geschäftsregeln schränken die zulässigen Ereignisfolgen ein. Sie zeigen zum Beispiel mithilfe eines Sequenzdiagramms oder eines Aktivitätsdiagramms, dass sich ein Benutzer vor dem Ausführen anderer Vorgänge beim System anmelden muss.

Viele dynamische Regeln können jedoch effektiver und allgemeiner angegeben werden, indem sie durch statische Regeln ersetzt werden. Sie können einer Klasse im konzeptionellen Klassenmodell zum Beispiel ein boolesches Attribut 'Logged In' hinzufügen. Sie würden Logged In als Nachbedingung für den Anmelde-Anwendungsfall und als Vorbedingung für die meisten anderen Anwendungsfälle hinzufügen. Mit diesem Ansatz können Sie vermeiden, alle möglichen Kombinationen von Ereignisfolgen definieren zu müssen. Er ist auch flexibler, wenn Sie dem Modell neue Anwendungsfälle hinzufügen müssen.

Beachten Sie, dass Sie hier wählen können, wie Sie die Anforderungen definieren möchten, und dass dies unabhängig davon ist, wie Sie die Anforderungen im Programmcode implementieren.

Weitere Informationen finden Sie unter den folgenden Themen:

Beschreiben von Servicequalitätsanforderungen

Die Servicequalitätsanforderung lässt sich in verschiedene Kategorien unterteilen. Sie umfassen:

• Leistung

• Sicherheit

• Verwendbarkeit

• Zuverlässigkeit

• Stabilität

Sie können einige dieser Anforderungen in die Beschreibung bestimmter Anwendungsfälle einschließen. Andere Anforderungen sind nicht spezifisch für Anwendungsfälle und werden am effektivsten in einem separaten Dokument aufgeführt. Wenn möglich, sollten Sie sich an das Vokabular halten, das durch das Anforderungsmodell definiert wird. Beachten Sie im folgenden Beispiel, dass die in der Anforderung verwendeten Hauptwörter die Titel von Akteuren, Anwendungsfällen und Klassen in den vorangehenden Abbildungen sind:

Wenn ein Restaurant ein Gericht auf einer Speisekarte (Menu Item) löscht, während ein Kunde (Customer) ein Gericht bestellt (Ordering a Meal), wird jede Bestellposition (Order Item), die sich auf dieses Gericht auf der Speisekarte bezieht, in Rot angezeigt.

Weitere Informationen finden Sie unter den folgenden Themen:

Darstellen des Arbeitsablaufs zwischen Benutzern und dem System

Sie können den Arbeitsablauf zwischen verschiedenen Anwendungsfällen mithilfe eines Aktivitätsdiagramms darstellen. Es ist häufig nützlich, beim Erstellen eines Anforderungsmodells zunächst ein Aktivitätsdiagramm zu zeichnen, in dem die Hauptaufgaben dargestellt sind, die von den Benutzern ausgeführt werden, sowohl im System als auch außerhalb davon.

Beispiel:

Sie können Anwendungsfalldiagramme und Aktivitätsdiagramme zeichnen, um andere Ansichten der gleichen Informationen darzustellen. Mit dem Anwendungsfalldiagramm kann die Schachtelung der kleineren Aktionen innerhalb der größeren Aktivität effektiver gezeigt werden, wobei es jedoch nicht den Arbeitsablauf darstellt. Beispiel:

Beachten Sie, dass Sie mit Aktivitätsdiagrammen auch die Algorithmen in der Software darstellen können. Wenn Sie die Diagramme jedoch für den Geschäftsprozess verwenden, konzentrieren Sie sich auf die Aktionen, die außerhalb des Systems sichtbar sind.

Weitere Informationen finden Sie unter den folgenden Themen:

Darstellen der Interaktion zwischen Benutzern und dem System

Sie können den Austausch von Meldungen zwischen dem System und externen Akteuren oder zwischen Teilen des Systems mithilfe eines Sequenzdiagramms anzeigen. Hierdurch wird eine Ansicht der Schritte in einem Anwendungsfall bereitgestellt, mit der die Abfolge der Interaktionen verdeutlicht wird. Sequenzdiagramme sind besonders nützlich, wenn in einem Anwendungsfall mehrere Beteiligte interagieren und wenn das System über eine API verfügt.

Beispiel:

Ein Vorteil von Sequenzdiagrammen besteht darin, dass sich einfach erkennen lässt, welche Meldungen in das System eingehen, das Sie erstellen. Um das System zu entwerfen, können Sie die einzelne Systemlebenslinie durch eine separate Lebenslinie für die einzelnen Komponenten ersetzen und dann die Interaktionen zwischen ihnen als Reaktion auf jede eingehende Nachricht anzeigen.

Weitere Informationen finden Sie unter den folgenden Themen:

Reduzieren von mangelnden Übereinstimmungen mithilfe eines Modells

Durch die Erstellung eines Modells lassen sich mangelnde Übereinstimmungen und Mehrdeutigkeiten bezüglich der Benutzeranforderungen deutlich reduzieren. Verschiedene Projektbeteiligte haben häufig auch verschiedene Sichtweisen im Hinblick auf das Geschäftsumfeld, in dem das System zum Einsatz kommt. Daher besteht die erste Aufgabe darin, diese Unterschiede zwischen den Kunden zu lösen.

Sie werden feststellen, dass beim Erstellen eines Modells viele Fragen hinsichtlich der Geschäftsdomäne von selbst auftauchen. Indem Sie den Benutzern diese Fragen stellen, können Sie vermeiden, dass zu einem späteren Zeitpunkt im Projekt zu viele Änderungen vorgenommen werden müssen. Nachfolgend sind einige konkrete Fragen aufgeführt, die Sie zunächst selbst beantworten sollten. Anschließend können Sie die Projektbeteiligten fragen, ob die Antworten unklar sind:

• Stellen Sie für jede Klasse im Anforderungsmodell die folgende Frage "Von welchem Anwendungsfall werden Instanzen dieser Klasse erstellt?" Bei einem Online-Essensbringdienst wäre z. B. die Frage "Welcher Anwendungsfall erstellt Instanzen der Restaurantmenü-Klasse?" denkbar. Dies würde zu einer Diskussion darüber führen, wie ein neues Restaurant beim Bringdienst registriert und in das Menü eingebunden wird. Sie können ähnliche Fragen darüber stellen, was Attribute und Zuordnungen erstellt oder ändert.

• Versuchen Sie für jeden Anwendungsfall im Anforderungsmodell das Endergebnis oder die Nachbedingung der einzelnen Anwendungsfälle mit den Wörtern zu beschreiben, die von den Klassendiagrammen bereitgestellt werden. Es ist häufig nützlich, die Auswirkungen eines Anwendungsfalls darzustellen, indem Sie die Instanzen der Klassen vor und nach dem Auftreten des Anwendungsfalls skizzieren. Wenn die Nachbedingung des Anwendungsfalls beispielsweise "ein Speisekarteneintrag (Menu Item) wird der Bestellung (Order) des Kunden hinzugefügt" lautet, skizzieren Sie Instanzen der Klassen Order und Menu Item. Stellen Sie die Auswirkungen des Anwendungsfalls, z. B. einen neuen Link oder ein neues Objekt, in einer anderen Farbe oder einer neuen Zeichnung dar. Dies führt häufig zu Diskussionen darüber, welche Informationen im Modell notwendig sind. Obwohl Anforderungsklassen nicht direkt mit der Implementierung zu tun haben, beschreiben sie die Informationen, die das System speichern und senden muss.

• Erkundigen Sie sich nach den Einschränkungen für Attribute und Zuordnungen, insbesondere Einschränkungen, die mehr als ein Attribut oder eine Zuordnung umfassen.

• Fragen Sie nach gültigen und ungültigen Abfolgen von Anwendungsfällen, und zeichnen Sie Sequenz- oder Aktivitätsdiagramme, um sie zu illustrieren.

Indem Sie die Beziehungen zwischen den Ansichten untersuchen, die verschiedene Diagramme bereitstellen, können Sie die Hauptkonzepte, mit denen die Benutzer arbeiten, schnell verstehen. Auf diese Weise können Sie den Benutzern dabei helfen zu verstehen, was das System ihnen bieten muss. Darüber hinaus können Sie auch besser verstehen, hinsichtlich welcher Anforderungen die Projektbeteiligten sich noch sehr unsicher sind. Sie können dann planen, diese Funktionen zu einem frühen Zeitpunkt im Projekt zumindest in vereinfachter Form zu entwickeln, sodass die Benutzer mit ihnen experimentieren können.

Siehe auch

Konzepte

Gewusst wie: Bearbeiten eines UML-Modells und Bearbeiten von Diagrammen

Entwickeln von Tests aus einem Modell

Verwenden von Modellen im Entwicklungsprozess

Modellieren der Architektur eines Softwaresystems

Weitere Ressourcen

Beispiel für VS-Erweiterung: Funktionen der UML-Domänenmodellierung

Beispiel für VS-Erweiterung: UML-Farbelemente nach Stereotyp

Beispiel für VS-Erweiterung: Verknüpfen von UML-Elementen mit Diagrammen, Dateien und anderen Elementen

Beispiel für VS-Erweiterung: Ausrichten von Formen in einem UML-Diagramm

Video: Modellieren der Geschäftsdomäne