8.2 Produkte des Submodells SE
		8.2.1 Anwenderforderungen (AFo)

  User Requirements

Inhalt		Einleitung Inhalt des Dokuments Aufbau des Dokuments Produktfluß Verknüpfungen mit der V-Modell Mailingliste

Einleitung

Um Anforderungen zu kennzeichnen, muß ein Formalismus eingeführt werden, der es erlaubt, jede Anforderung eindeutig zu identifizieren, damit eine eindeutige Referenzierung aus den Architektur- und Entwurfsdokumenten heraus möglich ist (Quittierungs-Prinzip).

Bei der Formulierung der Anforderungen ist darauf zu achten, daß nur das "WAS" einer gestellten Aufgabe zu beschreiben ist und nicht das "WIE". Weiterhin ist zu beachten, daß Anforderungen prüfbar, eindeutig, widerspruchsfrei und frei von versteckten Entwurfsentscheidungen sein sollen.

Der Begriff "System" umfaßt im folgenden auch den Begriff "Verfahren".

Inhalt des Dokuments

Aufbau des Dokuments

1. Allgemeines

2. Ist-Aufnahme und Ist-Analyse

• bereits ein System dieser Art existiert und durch ein neues ersetzt werden soll (im Ausnahmefall auch für umfangreiche SWPÄ-Maßnahmen) oder
• das zu entwickelnde System in existierende ablauforganisatorische oder technische Gegebenheiten eingebunden werden soll.

Im einzelnen sind im Rahmen der Ist-Aufnahme und Ist-Analyse beispielsweise folgende Punkte relevant:

• Erfassen der Anwender-/Nutzerumwelt (Aufbau- und Ablauforganisation, Dienstvorschriften, Erlasse, Gesetze, Richtlinien und ähnliches mehr)
• Aufnehmen existierender Datenbestände, Programme
• Erfassen der vorhandenen IT-Ausrüstung
• Erfassen von Zeit- und Mengengerüst (derzeitige Bearbeitungszeiten, Durchlaufzeiten, Antwortzeiten, Wartezeiten, Datenmengen)
• Erfassen nicht beeinflußbarer fachlicher und technischer Faktoren
• Darstellen der Bedrohung und der Ausrüstungslücke,
• Feststellen von Schwachstellen
• Ermitteln der Ursachen der festgestellten Schwachstellen

3. IT-Sicherheitsziel

4. Bedrohungs- und Risikoanalyse

5. IT-Sicherheit

In den Anforderungen an die IT-Sicherheit wird festgelegt, welche Wirkung von der Gesamtheit solcher Maßnahmen erwartet wird. Die Bedrohungen aus der Bedrohungs- und Risikoanalyse müssen den Anforderungen zugeordnet werden. Es muß klargestellt sein, daß die Maßnahmen zur IT-Sicherheit den Bedrohungen entgegenwirken.

6. Fachliche Anforderungen

6. 1. Grobe Systembeschreibung

• Es muß klar werden, welche fachlichen Aufgaben durch das System unterstützt werden sollen. Daher muß die Einordnung des Systems in die Organisation bzw. sein Integrationsumfeld beschrieben werden.
• Sie muß erkennbar machen, welche Gesamtfunktionalität im Endausbau abgedeckt werden soll und welche Prioritäten dabei im weiteren Verlauf erwartet werden.
• Sie muß das Einsatzkonzept soweit beeinhalten, daß daraus die technische und organisatorische Einsatzumgebung und die Randbedingungen (im Rahmen von SE1.4 - Randbedingungen definieren) ableitbar sind.
• Sie muß quantitative Abschätzungen enthalten, die es ermöglichen, grundsätzliche technische Entscheidungen in der richtigen Größenordnung zu treffen (Netzauslegung, Rechnerkapazitäten, usw.)
• Sie muß so präzise erfolgen, daß im weiteren Verlauf jederzeit entscheidbar ist, wann dieser Gesamthorizont verlassen wird und dementsprechend technische Entscheidungen neu überdacht werden müssen.
• Die Verwendung vordefinierter fachlicher Bausteine (Standardthemenbereiche) ist zu berücksichtigen. Mögliche Kandidaten zur Wiederverwendung auf der Ebene der Anwenderforderungen im Rahmen der beabsichtigten Entwicklung sind zu benennen.

6. 2. Organisatorische Einbettung

6. 3. Nutzung

6. 4. Kritikalität des Systems

6. 5. Externe Schnittstellen

Anforderungen hinsichtlich der Ergonomie sind hier zu berücksichtigen. Die technische Ausgestaltung der Nutzeroberfläche wird im Rahmen der Technische Anforderungen definiert.

6. 6. Beschreibung der Funktionalität

• Die Funktionalität des Systems wird unter Berücksichtigung der vom System zu erfüllenden Aufgabe beschrieben.
• Zur Festlegung der geforderten Systemfunktionalität werden Geschäftsprozesse definiert. Diese sind ganzheitlich, d. h. vollständig zu betrachten, auch wenn das geforderte System nur Ausschnitte davon unterstützt. Die Nutzer werden zum integralen Teil der Beschreibung. Das System wird zusammen mit seiner Umgebung (Mensch, verbundene Systeme) als Ganzes gesehen.
• Es erfolgt eine fachliche Strukturierung der Funktionalität in Bereiche. Diese Strukturierung dient
  • als Basis für die Entscheidung über eine Verwendung bereits an anderer Stelle vordefinierter Bereiche (Standardthemenbereiche)
  • als Grundlage der Abgrenzung von Systemteilen zur Erarbeitung und Untersuchung von Lösungsvorschlägen,
  • als Anhaltspunkt für die Vergabe von Entwicklungsaufträgen,
  • als Grundlage für eine stufenweise (inkrementelle) Entwicklungsstrategie für die schnelle Verfügbarkeit operationell einsetzbarer Systeme (durch frühe Rückkopplungen aus dem Einsatz kann das Entwicklungsrisiko deutlich vermindert werden),
  • als Planungsgrundlage und Leitfaden für den schrittweisen Ausbau des Systems,
  • ls Eingangsinformation für die Gestaltung oder Optimierung der Organisation beim Anwender.
• Beispiele für Standardthemenbereiche sind
  • Mailing und Kommunikation,
  • Daten- und Dokumentenhaltung,
  • IT-Sicherheit,
  • Mensch-Maschine-Schnittstelle (wie Lagedarstellung, Meldungserstellung und -verarbeitung),
  • Bürofunktionen.
• Im Rahmen der Beschreibung der Funktionalität werden Kritikalitätseinstufungen vorgenommen. Die Kritikalitätsstufenzuordnung erfolgt auf die Bereiche und die darunter liegenden Strukturelemente
• Der Informationsbedarf des Anwenders ist klar, aber unabhängig von technischen Vorgaben zu definieren. Gegebenenfalls erfolgt hier auch die Beschreibung der Daten, soweit sie auf dieser Ebene schon bekannt sind.

Anmerkungen:

• Die Ordnung der fachlichen Anforderungen an die Funktionalität wird nicht über die geforderte Bereichseinteilung hinaus als Regelungselement vorgegeben. Die fachliche Ordnung ist jedoch immer unabhängig von der technischen Architektur zu beschreiben.
• Wesentliches Element der fachlichen Beschreibung ist die Bezugnahme auf gegebenenfalls vordefinierte Bereiche
• Werden als Folge der Ist-Aufnahme und Ist-Analyse parallel zur Systementwicklung Aufbau- und Ablauforganisation beim Anwender optimiert, ist für Informationssysteme bei der Vorgabe der angestrebten Geschäftsprozesse und bei der fachlichen Strukturierung des Systems in Bereiche unbedingt auf die Ergebnisse dieser Optimierungen zurückzugreifen.
• Entwicklungen auf dem Gebiet der Informationstechnik können zu neuen Einsatzfeldern mit entsprechendem Einfluß auf die Organisationsgestaltung führen. Umgekehrt stellen Aufbau- und Ablauforganisation primäre Randbedingungen für eine Unterstützung durch IT-Systeme dar. Organisationsentwicklung und Systemerstellung stehen deshalb in enger Wechselwirkung zueinander. Sie sind folglich eng aufeinander abzustimmen.

6. 7. Qualitätsforderungen

• Zuverlässigkeit,
• Nutzerfreundlichkeit,
• Effizienz,
• Wartbarkeit,
• Übertragbarkeit,
• Wiederverwendbarkeit,
• statische und dynamische Leistungsdaten, usw.

7. Randbedingungen

7. 1. Technische Randbedingungen

• Technische Anforderungen an Schnittstellen,
• Vorgaben für die technische Realisierung von Schnittstellen,
• Hinweise und Vorgaben für den technischen Ablauf,
• Vorgabe von Fertigprodukten,
• Einhaltung von technischen Standards,
• Vorgaben aus der technischen Entwicklungs-, SWPÄ- oder Einsatzumgebung.

Zusätzlich können hier auch technische Anforderungen an die Umgebung vermerkt werden (z. B. für Hardware: erforderliche Klimatisierung, Vibrationsdämpfung, usw.).

7. 2. Organisatorische Randbedingungen

• Verteilung fachlicher Aufgaben (Funktionen) innerhalb der Aufbauorganisation,
• Bedarf an Kommunikation, Kooperation und Koordinierung zwischen Stellen innerhalb der Ablauforganisation beim Anwender,
• Informationsbedarf bei der Abwicklung von Geschäftsprozessen,
• Ausführungsrhythmus und Wiederholfrequenz der Geschäftsprozesse,
• geographische Verteilung der Anwender innerhalb des Einsatzgebietes,
• Vorgaben aus der Organisationsentwicklung zum Personalstand, Stellenpläne, Arbeitsplatzbeschreibungen,
• Vorgaben aus Personalgesetzgebung (Beamtengesetz, Betriebsverfassungsgesetz, Mitbestimmung, Tarifverträge),
• Zusammenarbeit mit externen Dienststellen und Behörden (überbehördliche Kooperation, Amtshilfe),
• Vergabe von fachlichen Aufgaben (Funktionen) an externe Auftragnehmer u. a. durch "Outsourcing".

7. 3. Sonstige Randbedingungen

Produktfluß

Verknüpfungen mit der V-Modell Mailingliste

This page online  •  GDPA Online  •  Last Updated 04.Mar.2004 by C. Freericks