Bedarfsanalyse fachlicher Metadaten - Universität St.Gallen
Bedarfsanalyse fachlicher Metadaten - Universität St.Gallen
Bedarfsanalyse fachlicher Metadaten - Universität St.Gallen
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
16 Grundlagen<br />
Abb. 2: Vorgehensmodell für die <strong>Bedarfsanalyse</strong> <strong>fachlicher</strong> <strong>Metadaten</strong><br />
Setzt man die Ergebnisse der einzelnen Aktivitäten in Beziehung zueinander, erhält<br />
man das Informationsmodell (bzw. Metamodell) des Vorgehensmodells aus Abb. 2<br />
[Gutzwiller 1994: 12-14]. Dieses Informationsmodell dient als Bezugsrahmen für die<br />
vorliegende Dissertation und wird in Abschnitt 3.5 näher betrachtet.<br />
2.4 Anforderungen im IS-Design<br />
In diesem Abschnitt werden Anforderungen aus Sicht des AM und des EE diskutiert.<br />
Die Beschränkung dieser Diskussion auf diese beiden Disziplinen erfolgt hinsichtlich<br />
ihrer Bedeutung für die <strong>Bedarfsanalyse</strong>, die im Fokus dieser Dissertation steht. Beide<br />
Disziplinen stellen Techniken zur Identifikation und Dokumentation von Anforderungen<br />
bereit, die in der <strong>Bedarfsanalyse</strong> während der Phase „Identifikation Handlungsbedarf“<br />
Anwendung finden können (im Detail Abschnitt 3.4).<br />
Zunächst werden Anforderungen aus der Perspektive des AM in Abschnitt 2.4.1 und<br />
danach aus der Perspektive des EE in Abschnitt 2.4.2 erörtert. Abschließend wird ein<br />
konsolidiertes Begriffsverständnis vorgestellt.<br />
2.4.1 Anforderungsmanagement<br />
Das AM ist eine Subdisziplin im Systems und Software Engineering, das sich damit<br />
auseinandersetzt, die Ziele, Funktionen und Einschränkungen für das Design von<br />
Hardware- und Softwaresystemen zu bestimmen [Laplante 2009]. In diesem Zusammenhang<br />
ist eine Anforderung eine „condition or capability needed by a user to solve a<br />
problem or achieve an objective“ [IEEE 1990: 62]. Hierbei schlagen einige Autoren/Autorinnen<br />
vor, dass Anforderungen alleine das „Was“ eines Systems beschreiben<br />
sollen und weniger das „Wie“ [Kotonya, Sommerville 1998: 4], um strikt IT-Bedarf