Studienarbeit aus dem Jahr 2005 im Fachbereich Informatik - Angewandte Informatik, Note: 1,3, Universitat Duisburg-Essen (Institut fur Informatik & Wirtschaftsinformatik - Software Systems Engineering), 21 Quellen im Literaturverzeichnis, Sprache: Deutsch, Abstract: Dieses erste Kapitel soll einen Uberblick und eine Einfuhrung in die Problemstellung dieser Seminararbeit geben. Dabei ist zu klaren, was Szenarien sind (dazu werden Definitionen angegeben) und wie sich diese klassifizieren respektive charakterisieren lassen, was Architektur ist und wie diese evaluiert werden kann. Szenarien werden in vielen Bereichen des Software Engineerings genutzt. Dazu zahlt auch das Requirements Engineering und die Architekturevaluierung. Im Requirements Engineering werden Szenarien wie folgt definiert: A scenario is a concrete description of system usage which provides a clear benefit for the actor of the system (nach Pohl et al. 2005) In der Architekturevaluierung wird ein Szenario definiert als eine kurze Aussage, die die Interaktion von Stakeholdern mit dem System beschreibt (nach Clements et al. 2001). Auf den ersten Blick sich die beiden Definitionen ahnlich. Beide Definitionen legen fest, dass es sich bei einem Szenario um eine Beschreibung der Benutzung eines Systems (also einer Interaktion) handelt. Bei genauerem Lesen der Definitionen fallen jedoch Unterschiede auf: - in der Architekturevaluierung wird von einer kurzen Aussage gesprochen, wahrend im Requirements Engineering von einer konkreten Beschreibung die Rede ist - im Requirements Engineering muss der Akteur des Szenarios einen klaren Nutzen von diesem System haben, in der Architekturevaluierung hingegen nicht. Daraus lasst sich schlussfolgern, dass eine genauere Untersuchung der Verwendung von Szenarien notwendig ist. Eine Grundlage fur einen Vergleich zwischen der Szenarien bietet das CREWSFramework in Rolland et al. (1998). Mit Hilfe des CREWS-Frameworks wurden auch schon mehrere Szenarien im Requiremen
