Previous Next V-Model Official Homepage by IABG  
Mail 0432  

1996-1997-1998-1999-2000-2001-2002

Contents  
  • Title
  • From
  • Date
  •  
  • History
  • Content
  • Links to V-Model
  • Title

    Re: Produktmuster Anwenderforderungen (432)

    From

    Beckmann, M.

    Date

    Tuesday, 14. December 1999 14:57

    History

    Mail 0428

    Mail 0429

    Mail 0430

    Mail 0431

    Mail 0432

    Content

    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

    Links to V-Model

    not defined

    Previous Next GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster