1996-1997-1998-1999-2000-2001-2002
Re: Produktmuster Anwenderforderungen (432)
Beckmann, M.
Tuesday, 14. December 1999 14:57
Mail 0428

Mail 0429

Mail 0430

Mail 0431

Mail 0432
From: Uta.Birk@t-online.de (Markus Beckmann)
On Fri, 10 Dec 1999 17:57:57 +0100, you wrote:
>So ganz bin ich da aber noch nicht "zufrieden". IUh hab jedoch das
>Gefühl das hier ein Punkt ist, bei dem Theorie und Praxis ein wenig
>auseinandergehen.
> Mein Hauptproblem bei diesem Produktmuster ist irgendwie,
>das ich das Gefühl habe das alles und jedes da zum Ergebnis
>Anwenderforderungen führen soll.
Ich weiß nicht, ob ich das jetzt richtig verstanden habe, aber
die Anwenderforderungen haben m.E. die zentrale Bedeutung in
einem Projekt. Je besser, klarer, dataillierter, vollständiger
u.s.w. die formuliert sind, desto besser nachher für das Pro-
jekt.
> Ich habe diverse Methoden angeguckt, die
>dieses Produkt erzeugen. Dazu gehört im objekorientierten Umfeld auch, die
>Klassenmodellierung. Ich finde es da schon ein wenig schwierig dieses
>Prinzip der Quitierbarkeit einzubauen (denn auch hier können Anforderungen
>lauern).
Klassenmodelle (-diagramme) können einen ganz wesentlichen Teil
der Anwenderforderungen definieren, nämlich eine statische Be-
schreibung des Anwendungsgebietes (as-is). Das kann zum einen
einzelne Klassen betreffen: "Im Anwendungsgebiet gibt es XYs
(Klasse), die werden beschrieben durch a, b und c (Attribute)
und können m und n (Methoden)." Zum anderen können Anwenderfor-
derungen hinsichtlich 'Multiplizitäten' bestehen: "Jedes XY
besitzt immer genau ein AB; ein AB gehört immer maximal einem
XY."
So kann man zu jeder Klasse, jedem Attribut, jeder Methode und
jeder Beziehung eine oder mehrere Anforderungen formulieren.
Diese per Text zu beschreiben, ist dann wichtig, wenn 'Kunden'
die Klassenodelle nicht lesen können - oder nicht lesen (kön-
nen) wollen.
Und auch zu solchen Anforderungen müssen Testfälle definiert
werden - nicht nur zu den Use-Cases, die im "Betrieb" des fer-
tigen nachvollzogen werden können (da Use-Case). So ist es
zum Beispiel wichtig, zu überlegen, wie man die Multiplizitä-
ten von Beziehungen zur Laufzeit überprüft. In jedem Fall ist
es wichtig, zwischen einer Anwenderforderung und dem Abnahme-
kriterium bzw. Testfall jederzeit die richtige Verbindung zu
finden.
> Bei der UseCase-Modellierung ist es einfacher. Da könnte ich mir
>auch vorstellen, es auf die Art zu lösen, wie Sie es vorgeschlagen haben.
>Für mich stellt sich auch die Frage, ob es nicht sinnvoll einen Link auf die
>Anforderungen in den sog. Datenkatalog aufzunehmen.
Das geht so in die Richtung der statischen Beschreibung!?!
> Sind irgendwo
>Erfahrungen mit Werkzeugen zur Anforderungsarchivierung vorhanden. Mit
>unseren diversen Systeme (Continuus, Ramedy, .. ) bin ich da von der
>Ausrichtung her nicht so zufrieden.
>
>Danke
>
>F. Götz
Mit freundlichen Grüßen,
Markus Beckmann
not defined
 |
 |
GDPA Online
Last Updated 01.Jan.2002
Updated by Webmaster
Last Revised 01.Jan.2002
Revised by Webmaster
 |
|