Mail 0439

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

Contents		Title From Date		History Content Links to V-Model

Title

From

Date

History

Content

From:          markus.reinhold@t-online.de (Markus Reinhold)

Lassen sie mich als ehemaligen Mitarbeiter der IABG und Mitwirkender bei
der Weiterentwicklung des V-Modell 92 auf den 97er Standard einige
Aussagen bzgl. Anwenderforderungen vs Technische Anforderungen
kommentieren.

> >Wo ist die Trennlinie zwischen Nuzeranforderungen (früher Systemanforderungen)
> >und Technischen Anforderungen?
> Da, wo das (zu realisierende) System anfängt?!? (s.u.)
Comment:
Diese Aussage ist mit Vorsicht zu genießen. Sollte hiermit gemeint sein,
daß die Anwenderforderungen nur die konzeptionellen funktionalen
Anforderungen enthalten, so ist dies sicher nicht richtig.
Anwenderforderungen beinhalten (u.a.):
a) konzeptionelle funktionale Requirements aus Sicht des
Anwenders/Kunden
b) nichtfunktionale Requirements wie z.B. Qualitätsanforderungen und
Construction Constraints (Technische Randbedingungen)
Grundsätzlich ist bei der Erstellung des Dokumentes davon auszugehen,
daß die Systemarchitektur der noch zu erstellenden Lösung nicht bekannt
ist. Sollte es sich jedoch um ein bereits existierendes System handeln,
welches erweitert werden soll, so können tech. Details dieses
"Alt-Systems" durchaus in den Anwenderforderungen auftauchen. Z.B bei
der Beschreibung des Ist-Zustandes, der bestimmte Probleme aufzeigen
soll. Ebenso könnten hier technische Randbedingungen (Construction
Constraints) auftauchen, da eben bestimmte Dinge bereits im Vorfeld
festliegen und nicht als Designentscheidung erbracht werden. 

> 
> >Ich dachte, die Nutzeranforderungen beschreiben vollständig das vom Benutzer
> >beobachtbare Verhalten des Systems.
> Das kann man wohl so sagen.
Comment:
Aber eben nicht nur (s.o.). Die techn. Randbedingungen sind z.B. auch
ein Teil der Anwenderforderungen, sind jedoch nichtfunktionale
Requirements, d.h. beschreiben keine Funktionalität (Verhalten) des
Systems aus Kundensicht. VORSICHT, man "darf" hier nur unveränderbare
Constraints beschreiben, keine Entwurfentscheidungen.

>Die Trennlinie zwischen den Anwenderforderungen und den Technischen Anforderungen
>liegt, meiner Meinung nach,  in der Perpektive auf das System.
>Der Häus´le Bauer wird dem Architekten sagen, wie er aus seiner Sicht gerne das
>Haus gestaltet hätte ohne technische Details z.B über die Tragfähigkeit der Wände
>zu nennen.
>Die Anwenderforderungen beschreiben somit das System aus der Sicht des Anwenders,
>d.h. es kann u.a. aus objektorientierter Sicht über Anwendungsszenarien (Use Cases
>oder Event Trace Diagramme) und Anforderungen beschrieben werden ("Die große Was
>passiert Dann Maschine").
>Der Architekt wird die Anwenderforderungen des Häus´le Bauers in technische
>Anforderugen oder in einen Entwurf umsetzen.
Comment:
Über den Einsatz von den verschiedenen UML Beschreibungstechniken kann
man unterschiedlicher Auffassung sein. Das V-Modell gibt ja hierzu
Hinweise im Bereich des AU 251 (Methodenzuordnung). Ich teile die
Auffassung nicht in allen Punkten. Die Diskussion würde hier jedoch zu
weit führen. Im Zweifelsfall empfehle ich den Besuch meines Seminars
"Objektorientierte Analyse und Design mit UML und V-Modell'97" (siehe
www.cocoo.de)
Der letzte Satz im obigen Absatz "Der Architekt wird die
Anwenderforderungen des Häus´le Bauers in technische Anforderungen oder
in einen Entwurf umsetzen." möchte ich jedoch kurz kommentieren. Was
mich hier stört ist das Wort "oder". Aus Anwenderforderungen wird
erstmal die Systemarchitektur (Designaktivität). Aus Anwenderforderungen
+ System Architektur entstehen die technischen Anforderungen (pro
Element der Systemarchitektur). Aus Anwenderforderungen +
Systemarchitektur + Technischen Anforderungen entstehen ein Dokument
SW-Architektur (pro kleinstem Element der
Systemarchitektur=SW-Einheit)(Designaktivität).
 
> >Bestehen die Technischen Anforderungen dann nur aus den Benutzeroberflächen?
> Das sicher nicht! Ein wesentlicher Teil sind Anforderungen an die
> Schnittstellen des Systems - intern und extern. Diese können ggf.
> bis auf Bit-Ebene definiert sein, bevor das System auch nur ent-
> worfen ist - zum Beispiel durch die Schnittstellenspezifikation
> eines anderen Systems. Daneben kann es Anforderungen an die in-
> terne Struktur bzw. an Komponenten geben, die zum Beispiel aus
> Firmenstandards resultieren.
Comment:
Nachdem man sich Gedanken (SE2) über die Zerlegung (statisch +
dynamisch) des Systems in Teile (hier z.B. SW-Einheiten) gemacht hat,
gibt es nun eine Menge von technischen Bausteinen (SW-Einheiten), die in
ihrer Summe die Anwenderforderungen erfüllen müssen. Die Technischen
Anforderungen beschreiben die Anforderungen an jeden dieser Bausteine
mit einem Black Box Approach(!!!), d.h. es wird spezifiziert, was von
jedem Baustein erwartet wird. Dies dient dazu, um ggf. eine Vergabe des
Entwicklungsauftrages durchführen zu können. 
Man sollte sich jedoch wirklich im Klaren sein, welche Info man in
welches Dokument schreibt. Ich betrachte die Technischen Anforderungen
als Requirementsdokument bzgl. des Systemarchitekturdokumentes unter
Berücksichtigung des Anwenderforderungsdokumentes. Solle jemand diese
Funktionalitätsbeschreibung pro Baustein bereits in der
Systemarchitektur abgewickelt haben, hat er im Prinzip einen "Fehler"
bei der Erstellung der System Architektur gemacht, da nun ein
Redundanzproblem auftaucht. 
Ein Redundanzproblem kann auch bzgl. der oben erwähnten
Schnittstellenbeschreibungen auftauchen. Das hierfür vorgesehene
Dokument ist eigentlich die Schnittstellenbeschreibung. 
Auf Basis der Technischen Anforderungen pro SW-Einheit (Black Box
Construction constraint) kann dann im nächsten Schritt die Architektur
(White Box) pro SW-Einheit definiert werden (SE 4)
> 
> Vielleicht kann man sagen, dass die Technischen Anforderungen die
> Anwender-(!)forderungen in dem Punkt technische Randbedingungen
> präzisieren. Man könnte nun fragen, warum man dann überhaupt die
> technischen Randbedingungen zu den Anwenderforderungen packt.
Comment:
Der Ursprung der Technischen Randbedingungen in den Anwenderforderungen
liegt in der real existierenden, nicht veränderbaren technischen
Gegebenheiten. Es handelt sich hierbei somit nicht um
Designentscheidungen. Die Technischen Anforderungen entstehen maßgeblich
aus der getroffenen Entscheidung bzgl. der Systemarchitektur (d.h.
Zerlegung des Systems bis auf die Ebene von SW-Einheiten) und den
Anwenderforderungen (alle Requirements! aus diesem Dokument).

> Ein System entsteht - auch aus Anwendersicht - in der Regel nicht
> im luftleeren - sprich technikfreien - Raum. Daher ist es sinn-
> voll, dass der Anwender auch entsprechende Dinge fordern kann.
> Die technische Auslegung des Systems in _detaillierten_ Anfor-
> derungen ist dann eher ein zweiter Schritt, der ggf. nicht mehr
> vom Anwender selber vollzogen wird.
> 
> Trotzdem kann man vielleicht als "Daumenregel" sagen, dass bei
> der Erhebung der Anwenderforderungen das System erst einmal
> als (die berühmte) Black Box betrachtet werden kann, bei der
> auch egal ist, ob dahinter/daran noch -zig andere Systeme
> hängen.
Comment:
Ist auch meine Meinung. Spätestens jedoch, wenn Sie die
nichtfunktionalen Requirements im Dokument Anwenderforderung beschreiben
wollen, muß dieser Standpunkt jedoch aufgegebene werden.

> >Gruss
> >Norbert Müler
> >Dornier GmbH
> 
Grüsse
M. Reinhold - www.cocoo.de -

Links to V-Model

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