Publisher's Synopsis
Studienarbeit aus dem Jahr 2005 im Fachbereich Informatik - Angewandte Informatik, Note: 1,3, Universität Duisburg-Essen (Institut für Informatik & Wirtschaftsinformatik - Software Systems Engineering), Sprache: Deutsch, Abstract: Dieses erste Kapitel soll einen Überblick und eine Einführung in die Problemstellung dieser Seminararbeit geben. Dabei ist zu klären, 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 zählt 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 ähnlich. 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, während 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 lässt sich schlussfolgern, dass eine genauere Untersuchung der Verwendung von Szenarien notwendig ist. Eine Grundlage für einen Vergleich zwischen der Szenarien bietet das CREWSFramework in Rolland et al. (1998). Mit Hilfe des CREWS-Frameworks wurden auch schon mehrere Szenarien im Requirements Engineering klassifiziert (siehe
