nicht funktionale anforderungen bei der inbetriebnahme von anwendungen

80 HMD 265

Georg Disterer, Matthias Rose

Nicht funktionale Anforderungen bei der Inbetriebnahme von Anwendungen

In der Vergangenheit wurde der Fokus bei derEntwicklung von Anwendungen in der Anfor-derungsanalyse stark auf funktionale Anforde-rungen gelegt. Nicht funktionale Anforderungenwurden zu spät identifiziert, teilweise übergan-gen und im Entwurf und bei der Entwicklung vonAnwendungen nicht hinreichend berücksichtigt.Mitarbeiter des IT-Betriebs konnten ihre Anfor-derungen an Anwendungen nicht ausreichend indie Entwicklung einbringen.

Dies liegt auch daran, dass nicht funktionaleAnforderungen schwer zu identifizieren, zu spezi-fizieren und zu erfüllen sind. Daher ist für einereibungslose Inbetriebnahme von Anwendungendie Handhabung nicht funktionaler Anforde-rungen zu verbessern. Ein entsprechender Pro-zess für die Überleitung von Anwendungen inden Betrieb systematisiert die frühzeitige Identi-fizierung und Erfüllung nicht funktionaler Anfor-derungen und unterstützt damit die reibungs-lose Inbetriebnahme von Anwendungen.

Inhaltsübersicht1 Einleitung2 Systematisierung nicht funktionaler

Anforderungen2.1 Systembetrieb2.2 Methoden2.3 Produkt

3 Berücksichtigung nicht funktionaler Anforderungen bei der Entwicklung

4 Ausblick5 Literatur

1 EinleitungEine kritische Phase in einem Entwicklungs-projekt ist die Ermittlung der Anforderungen

(Requirements), die eine Anwendung zu erfül-len hat [Chung et al. 1999, S. 1; Ebert 2005, S. 2;Partsch 1998, S. 13-14; Sommerville 2007, S. 148].Werden bei dieser Analyse Anforderungen nichtoder nicht richtig identifiziert, spezifiziert unddokumentiert, so führt dieses in späteren Ent-wicklungsphasen zu erheblichem Aufwand(Kosten und Zeit) oder gar zum Projektabbruch.Weiterhin können bei der Inbetriebnahme vonAnwendungen Probleme und Störungen auf-treten, sodass die Anwendung nur einge-schränkt oder gar nicht nutzbar ist.

Eine Definition für den Begriff Anforde-rungen liefert die Fachterminologie der IEEE[IEEE 1990]: Eine Anforderung ist eine Bedin-gung oder eine Fähigkeit, die ein Benutzer be-nötigt, um ein Problem zu lösen oder um einZiel zu erreichen. Anforderungen sind danachBedingungen oder Fähigkeiten, die ein Systemoder eine Komponente erfüllen muss, um einenKontrakt, einen Standard, eine Spezifikationoder ein anderes formales Dokument zu erfül-len.

Die Ermittlung der Anforderung ist eineder Hauptaufgaben des Anforderungsmanage-ments (Requirements Management), das imSoftware-Engineering aufgegriffen wird. Dabeiumfasst das Anforderungsmanagement »alleProzesse, die zur Erhebung, Strukturierung undVerwaltung von Anforderungen notwendigsind« [Ebert 2005, S. 17]. Dazu gehören vor allemdie Teilaufgaben der Identifikation, Analyse,Spezifikation und Verwaltung/Verfolgung vonAnforderungen, um sicherzustellen, dass neueoder geänderte Anwendungen friktionsfrei inden IT-Betrieb überführt und dort anforde-rungsgemäß, stabil und wirtschaftlich betrie-ben werden können.

Nicht funktionale Anforderungen

HMD 265 81

Anforderungen sind in funktionale undnicht funktionale Anforderungen zu unter-scheiden [Sommerville 2007, S. 154; Ebert 2005,S. 11; Partsch 1998, S. 22-26], um deren Charakte-ristika besser zu verstehen. Funktionale Anfor-derungen (functional requirements) beschrei-ben funktionale Aspekte von Anwendungeni.S.v. »… was soll die Anwendung leisten«. DieseAnforderungen hängen direkt vom angestreb-ten Nutzen und vom Einsatzzweck der zu ent-wickelnden Anwendung ab. Sie werden in derRegel von den Fachabteilungen gestellt, umdie dortigen Geschäftprozesse bestmöglich zuunterstützen, und umfassen die Erfassung, Auf-bereitung, Verarbeitung, Speicherung und Wei-tergabe von Informationen. Mit den funktio-nalen Anforderungen werden die Forderungenan die zu erstellende Anwendung aus Sicht derzukünftigen Benutzer beschrieben.

Nicht funktionale Anforderungen legentechnische und methodische Bedingungen ei-ner Anwendung fest, damit diese später imBetrieb störungsfrei, stabil und wirtschaftlichbetrieben werden kann. So sind bei der Anwen-dungsentwicklung zum Beispiel Anforderun-gen bezüglich der Wartbarkeit, Skalierbarkeitund Benutzbarkeit sowie des Datenschutzes zuerfüllen. Nicht funktionale Anforderungen be-ziehen sich häufig nicht auf einzelne Funktio-nen der Anwendungen, sondern legen aus tech-nischer Sicht fest, wie eine Anwendung diefunktionalen Anforderungen erfüllen soll[Chung et al. 1999, S. 6]. Nicht funktionaleAnforderungen werden daher auch als»Constraints«, »Qualitätsattribute« oder »Ma-nagement and Operational Requirements« be-zeichnet.

In der Vergangenheit wurde im Anforde-rungsmanagement der Fokus häufig auf funk-tionale Anforderungen gelegt; nicht funktio-nale Anforderungen wurden übergangen undbei der Entwicklung nicht hinreichend berück-sichtigt:

»However, too many organizations spendtoo much time focusing on the functional

requirements of the new service and appli-cation, and insufficient time is spent desig-ning the management and operational re-quirements (non-functional requirements)of the service« [OGC 2007a, S. 180].»… nichtfunktionale Anforderungen, die imVorfeld oft übergangen worden sind …«[Ebert 2005, S. 98].»… nichtfunktionale Anforderungen wer-den … im Design nicht beachtet … [und] fastimmer übersehen …« [Ebert 2005, S. 99].

Diese Vernachlässigung nicht funktionaler An-forderungen ist (teilweise) damit zu begründen,dass sie schwer zu identifizieren, zu spezifizie-ren und zu erfüllen sind. Sie werden meist vage,verschwommen und allgemein formuliert undmit ungenauen Adjektiven beschrieben [Chunget al. 1999, S. 6; Ebert 2005, S. 13 und S. 98;Sommerville 2007, S. 6 und S. 156]. Beispiel: »DasSystem soll schnell sein und nicht abstürzen«,weiterhin soll es »portierbar, wartbar und zu-verlässig« sein.

Doch lassen sich nicht funktionale Anforde-rungen teilweise tatsächlich schwer beschrei-ben, nicht eindeutig und objektiv definierensowie nicht hinreichend präzise spezifizieren[Ebert 2006, S. 13; Rupp 2007, S. 26]. Eigen-schaften wie Stabilität, Korrektheit, Benutz-barkeit oder Wartbarkeit einer Anwendung sindschwierig präzise zu beschreiben. Sie stellenAbstrahierungen von unmittelbaren Anfor-derungen dar und stehen oft in nicht wi-derspruchsfreien Beziehungen untereinander;somit wird mit ihnen der Anwendungsentwick-lung ein beachtliches Maß an Komplexität auf-gebürdet [Kruchten 1998, S. 140-141].

In der Folge können nicht funktionale An-forderungen oftmals nur unvollständig undsubjektiv überprüft werden. Damit verbleibtRaum für (Fehl-)Interpretationen der Anforde-rungen während der Entwicklung [Chung et al.1999, S. 6; Sommerville 2007, S. 157]. Metrikenfür die unmissverständliche Formulierung undspätere objektive Überprüfung nicht funktio-


82 HMD 265

naler Anforderungen liegen in vielen Fällennicht vor. So ist zwar die Performanz einer An-wendung zu messen, indem die zulässigeReaktionszeit auf bestimmte Benutzeraktionenfestgelegt und überprüft wird. Für andere An-forderungen wie Skalierbarkeit oder Wartbar-keit ist jedoch eine ähnlich präzise Beschrei-bung schwer möglich; damit ist auch die hinrei-chende Umsetzung und genaue Überprüfungdieser Anforderungen problematisch.

Anders als bei funktionalen Anforderungenist es bei nicht funktionalen Anforderungennicht immer offensichtlich, wer die Anfor-derungen aufstellen und überprüfen sollte. Sosind etwa Skalierbarkeit und Wartbarkeit Ei-genschaften einer Anwendung, die vielfältigenEinflussgrößen aus verschiedenen Verantwor-tungsbereichen des IT-Betriebs unterliegen. Zu-sätzlich stellen andere Bereiche wie z. B. Risiko-management, Portfoliomanagement, Daten-schutz und Personalvertretung Anforderungen,um ihre Ansprüche an die Entwicklung einerAnwendung zu richten. Damit liegen für nichtfunktionale Anforderungen oft »sehr hetero-gene[n] Interessengruppen mit divergierendenPartikularinteressen« [Ebert 2006, S. 101] vor.

Vagheit und Unschärfe bei der Formulie-rung nicht funktionaler Anforderungen könnenauch dazu führen, dass diese Anforderungenwährend der Anwendungsentwicklung oppor-tunistisch interpretiert werden, um geänderteoder erweiterte Anforderungen zu proklamie-ren.

Aufgrund dieser vielfältigen Probleme beider Handhabung nicht funktionaler Anforde-rungen werden sie heute oftmals bei der Ent-wicklung von Anwendungen nicht ausreichendbeachtet [Ebert 2005, S. 98; OGC 2007a, S. 180]oder »vergessen« [Rupp 2007, S. 257] und daherauch als »Falle« [Ebert 2005, S. 98; Chung et al.1999, S. 7] bezeichnet.

Eine mangelhafte Berücksichtigung nichtfunktionaler Anforderungen bei der Entwick-lung verursacht, dass Anwendungen durch dieBenutzer nur eingeschränkt einsetzbar sowie

vom IT-Betrieb nicht effizient und stabil zu be-treiben sind. Daher wird im Folgenden eineSystematisierung nicht funktionaler Anforde-rungen vorgestellt und ein prozessorientierterLösungsansatz zur besseren Identifizierung undErfüllung nicht funktionaler Anforderungen inEntwicklungsprojekten vorgestellt.

2 Systematisierung nicht funktionaler Anforderungen

Eine Systematisierung nicht funktionaler Anfor-derungen kann während der Anwendungsent-wicklung und bei der folgenden Überleitungvon Anwendungen in den Betrieb deren Identi-fikation, Analyse, Spezifikation, Abstimmungund Verwaltung/Verfolgung unterstützen. Inder Literatur hat sich dazu kein einheitlicher An-satz zur Systematisierung durchgesetzt. Daherwird aus verschiedenen Quellen eine Systemati-sierung nach den Kategorien Systembetrieb,Methoden und Produkt abgeleitet. Der Ansatzist in Abbildung 1 wiedergegeben; zu den Kate-gorien sind als Beispiele jeweils prägnante nichtfunktionale Anforderungen aufgeführt.

2.1 SystembetriebIn der Kategorie Systembetrieb sind jene nichtfunktionalen Anforderungen zusammengefasst,die bei der Integration einer Anwendung in dievorhandene Systemumgebung zu beachtensind. Hierzu ist z. B. die Performanz von Anwen-dungen zu zählen, die u. a. mit dem Durchsatz– Transaktionen pro Zeiteinheit – zu beschreibenist. Die Forderung des IT-Betriebs nach der Per-formanz einer Anwendung nimmt Bezug aufderen Verbrauch technischer Ressourcen undsoll sicherstellen, dass die Performanz andererSysteme nicht durch übermäßigen Ressourcen-verbrauch nachteilig beeinflusst wird.

Die Anforderung nach Stabilität zielt auf dieEigenschaften der Ausfallsicherheit und Feh-lertoleranz einer Anwendung. Da der IT-Betriebetwa nach ITIL zur Sicherung einer kontinuier-lichen IT-Unterstützung der Geschäftsprozesse


HMD 265 83

nicht funktionaleAnforderungen

Systembetrieb Methoden Produkt

Performance (Transaktionen…)

Stabilität (Ausfallsicherheit, Fehlertoleranz)

Skalierbarkeit (Ressourcen)

Kapazitäten (CPU-Geschwindigkeit, RAM…)

Schnittstellen

Wartbarkeit

Monitoring

Backup (Verfahren)

Portierbarkeit (Systeme, Service Provider)

Abhängigkeiten (Systeme/-komponenten)

Standards (Codierung, Design, Prozesse…)

Dokumentation / Information

Nachvollziehbarkeit

Tests

Abnahmen

Implementierung

Antwortzeit

Zuverlässigkeit

Korrektheit

Benutzbarkeit

Datenschutz

Datensicherheit

Gesetze

Kontrollierbarkeit (Monitoring, Reporting)

…

…

…

gemäß den Service Level Agreements (SLA) ver-pflichtet ist, können Ausfälle Vertragsstrafenzur Folge haben, wenn mit Kunden vereinbarteSLA nicht eingehalten werden. Ebenso zählt dieEigenschaft der Wiederherstellbarkeit zur An-forderung nach Stabilität: Wiederherstellungeiner Anwendung nach einem Systemausfallauf ein definiertes Leistungsniveau innerhalbeiner festgelegten Zeit. Auch der IT-Betrieb istan einer hohen Stabilität interessiert, weil jederSystemausfall oder Systemfehler zu erhöhtemArbeitsaufwand führt.

Die Eigenschaft der Skalierbarkeit beziehtsich auf die Möglichkeit, einen umfangreiche-ren Einsatz einer Anwendung (z. B. mehr Benut-zer oder mehr Transaktionen) durch Hinzufügenvon Ressourcen effizient abfangen zu können,ohne dass andere funktionale oder nicht funk-tionale Anforderungen verletzt werden.

Weitere nicht funktionale Anforderungender Kategorie Systembetrieb beschreiben tech-nische Vorgaben, die bei der Entwicklung einerAnwendung zu beachten sind:

! Kapazitäten: Richtwerte zur Verarbeitung(CPU-Geschwindigkeit, Größe des Arbeits-speichers), Übertragung (Bandbreite) undSpeicherung von Daten (Speichervolumen,Zugriffszeiten von Speichermedien)

! Schnittstellen: Beschränkungen des Betriebsauf Schnittstellen, die genutzt werden sollen

! Wartbarkeit: Vorgaben zu etablierten Verfah-ren, um Anwendungen anzupassen oder zukorrigieren

! Monitoring: Konventionen zu Vorgehenswei-sen der Überwachung von Anwendungen imlaufenden Betrieb

! Backup: Vorgaben zu Vorgehensweisen desBackups von Anwendungen im Betrieb

! Portierbarkeit: Vorschriften zur Möglichkeitder späteren Verlagerung einer Anwendungin eine andere Systemumgebung (z. B. Wech-sel des DBMS, Wechsel des Providers)

! Abhängigkeiten: Beziehungen zu Systemenund Systemkomponenten, die bei der Anwen-dungsentwicklung zu beachten sind

Abb. 1: Nicht funktionale Anforderungen


84 HMD 265

Damit sind alle nicht funktionalen Anforderun-gen dieser Kategorie vornehmlich durch Ver-antwortliche des IT-Betriebs zu vertreten.

2.2 MethodenUnter der Kategorie Methoden werden Forde-rungen nach Standards und Verfahren zusam-mengefasst, die bei der Entwicklung einer An-wendung einzuhalten sind. Die Standards um-fassen Vorgaben für den Entwurf und dieImplementierung von Anwendungen sowie dasVorgehen in Entwicklungsprozessen. Zu denVerfahren zählen die Dokumentation undNachvollziehbarkeit. Unter Nachvollziehbarkeit(Traceability) wird die Forderung verstanden,dass die Ausgangspunkte und die Zusammen-hänge von Anforderungen und Entscheidungenzurückverfolgt werden können.

Weiterhin werden Konventionen vorge-schrieben, wie Tests und Abnahmen einer An-wendung bezüglich der Anforderungen zu er-folgen haben, und angegeben, welche Maß-nahmen zur Vorbereitung und Durchführungder Inbetriebnahme einer Anwendung vorge-sehen sind. So ist etwa die Beachtung unter-nehmensinterner Change-Prozeduren, Release-kalender und Supportregeln einzufordern.

Damit sind die Anforderungen dieser Kate-gorie primär von Verantwortlichen aus denBereichen Qualitätssicherung und Software-Engineering zu vertreten.

Dem Betrieb gegenüber besteht für dasEntwicklungsprojekt eine Informationspflichtzu Eigenschaften einer Anwendung, die für denzukünftigen Betrieb der Anwendung relevantsind. Dies umfasst etwa Erwartungswerte fürdie Beanspruchung von Ressourcen zur Ver-arbeitung, Übertragung und Speicherung vonDaten durch eine Anwendung. Informationendazu sind dem Betrieb so früh mitzuteilen,dass dieser rechtzeitig Vorkehrungen zur Be-reitstellung ausreichender Kapazitäten treffenkann.

2.3 ProduktIn der Kategorie Produkt sind die nicht funktio-nalen Anforderungen zusammengefasst, diedas angestrebte systemtechnische Verhaltender Anwendung festlegen. So wird mit der Ant-wortzeit vorgegeben, mit welcher Geschwin-digkeit eine Anwendung auf Aktionen der Be-nutzer reagieren soll. Mit der Eigenschaft derZuverlässigkeit wird eine Fehlerquote vorgege-ben, die von einer Anwendung nicht überschrit-ten werden darf. Zu dieser Eigenschaft zähltauch die Konsistenz von Datenbeständen, z. B.dass ein Ausfall der Anwendung, Fehlbedie-nungen von Benutzern oder Wartungsarbeitenkeine Inkonsistenzen verursachen können.

Mit der Anforderung der Korrektheit wirdabgedeckt, dass die Ergebnisse der Anwendungden erwarteten Ergebnissen entsprechen sol-len. Damit sind auch entsprechende gesetzlicheVorgaben ordnungsgemäß zu erfüllen (z. B. da-tenschutzrechtliche Vorgaben und gesetzlicheDokumentationspflichten). Bei Echtzeitsyste-men steht die Forderung nach Korrektheit in en-gem Zusammenhang mit den Anforderungennach Zuverlässigkeit und ausreichender Ant-wortzeit. So ist die Anforderung nach Korrekt-heit nicht zu erfüllen, wenn ein Produktions-steuerungssystem Daten zur Montage vonKomponenten zwar richtig, aber nicht schnellgenug ermittelt. Diese mangelnde Korrektheitkann zu wirtschaftlichen Schäden führen.

Mit dem Einsatz einer Anwendung sollenBenutzer definierte betriebswirtschaftlicheZiele erreichen können. Die Benutzbarkeit(Usability) einer Anwendung beeinflusst mit,ob Benutzer diese Ziele effektiv und effizient er-reichen, und ist wichtiger Faktor der Benutzer-akzeptanz. Für die Benutzbarkeit ist die Ergono-mie einer Anwendung entscheidend, also z. B.das Design der Benutzeroberfläche (etwa un-ternehmensweit einheitliche Benutzeroberflä-che) und die Anzahl der Bedienschritte, die aus-zuführen sind, um ein bestimmtes Ergebnis zuerzielen. Anwendungen sollten einfach zu nut-zen und für den Benutzer weitestgehend


HMD 265 85

selbsterklärend sein. Ein mögliches Maß für dieBenutzbarkeit einer Anwendung ist der Schu-lungsbedarf der Benutzer. Die Benutzbarkeiteiner Anwendung ist bei der Entwicklung früh-zeitig durch Tests mit Prototypen zu ermitteln.

Bei der Entwicklung von Anwendungensind Vorgaben bezüglich des Datenschutzesund der Datensicherheit zu erfüllen. Im Rah-men des Datenschutzes sind u. a. Kriterien be-züglich Zugriffsberechtigungen und Authen-tifizierung von Benutzern zu beachten. An-forderungen der Datensicherheit erfordernFestlegungen zum Recovery einer Anwendung.Gesetzliche Vorschriften können Pflichten zurArchivierung elektronischer Unterlagen enthal-ten. Ferner sind Anforderungen bezüglich derKontrollierbarkeit einer Anwendung mittelsMonitoring und Reporting zu beachten, damitder Nachweis der Einhaltung der SLA geführtwerden kann und ggf. frühzeitig Mängel undFehler erkannt und behoben werden können.

3 Berücksichtigung nicht funktionaler Anforderungen bei der Entwicklung

Nicht funktionale Anforderungen sind kritischfür die Sicherstellung eines stabilen und wirt-schaftlichen Betriebs von Anwendungen. Wer-den sie bei der Entwicklung nicht adäquat be-rücksichtigt, werden bei der Inbetriebnahme ei-ner Anwendung Störungen auftreten. Daher isteine systematische Verwaltung und Verfolgungnicht funktionaler Anforderungen zu etablieren,damit deren rechtzeitige und vollständige Be-rücksichtigung bei der Entwicklung gesichert ist.

Dabei ist eine Eigenschaft nicht funktio-naler Anforderungen zu nutzen: Da sie nichtspezielle Forderungen an eine Anwendung be-schreiben, sondern die Betriebsumgebung, inder Anwendungen ablaufen sollen, sind sie beider Entwicklung verschiedener Anwendungenwiederverwendbar: »Allen nicht-funktionalenAnforderungen ist gemein, dass sie sich deut-lich besser wiederverwenden lassen als funktio-nale Anforderungen« [Rupp 2007, S. 259].

Daher wird vorgeschlagen, nicht funktio-nale Anforderungen für ein Unternehmen odereine Betriebsumgebung in einem allgemein-gültigen Katalog zusammenzufassen, um dieWiederverwendbarkeit auszunutzen. Dazudient der Prozess »Nicht funktionale Anforde-rungen planen, steuern und kontrollieren«. Füreinzelne Entwicklungsprojekte ist der Anforde-rungskatalog dann jeweils an deren Spezifikaanzupassen. Damit werden nicht funktionaleAnforderungen nicht für jedes Entwicklungs-projekt neu erhoben und beschrieben, sondernaus dem Katalog nicht funktionaler Anforde-rungen projektspezifisch abgeleitet.

Bei einer Ausrichtung nach ITIL (V3) werdendie Aufgaben der Vorbereitung der Inbetrieb-nahme von Anwendungen dem Prozess»Transition Planning and Support« und die Auf-gaben der Durchführung dem Prozess »Releaseand Deployment Management« zugeordnet.Damit verbunden ist die Überprüfung der Ein-haltung nicht funktionaler Anforderungen fürAnwendungen, die vor der Inbetriebnahme ste-hen [OGC 2007b, S. 16-19]. Daher müssen beiden Verantwortlichen dieser Prozesse die not-wendigen Kenntnisse und Erfahrungen vorlie-gen, nicht funktionale Anforderungen initial ineinem allgemeinen Katalog zu erfassen und sie(später) projektspezifisch anzupassen. Dazu istder Prozess »Nicht funktionale Anforderungenplanen, steuern und kontrollieren« im vor-genannten ITIL-Prozess »Transition Planningand Support« einzupassen. Mit diesem Prozesswird über eine projektspezifische Liste nichtfunktionaler Anforderungen erreicht, dass einefrühzeitige Einbindung (»Involvement«) undBerücksichtigung dieser Anforderungen im Ent-wicklungsprozess sicher ist.

Insgesamt wird mit dem Prozess »Nichtfunktionale Anforderungen planen, steuernund kontrollieren« erreicht, dass die Erfüllungnicht funktionaler Anforderungen nicht erst beider Übergabe der Anwendung an den Betriebüberprüft, sondern frühzeitig eine Abstim-mung herbeigeführt wird. Dafür ist der Prozess


86 HMD 265

Prozess starten

Prozess beenden

Katalognicht funktionaler

Anforderungen initial erstellen


Anforderungen pflegen und verwalten


Anforderungen projektspezifisch

anpassen

Erfüllungnicht funktionaler

Anforderungen prüfen

einmalig laufend pro Projekt

in folgende Teilprozesse zu gliedern (sieheAbb. 2):! Katalog nicht funktionaler Anforderungen

initial erstellen! Katalog nicht funktionaler Anforderungen

pflegen und verwalten! Katalog nicht funktionaler Anforderungen

projektspezifisch anpassen! Erfüllung nicht funktionaler Anforderungen

prüfen

In dem Teilprozess »Katalog nicht funktionalerAnforderungen initial erstellen« sind alle Anfor-derungen eines Unternehmens (oder einer Be-triebsumgebung) zu erheben und zu dokumen-tieren. Dafür sind die beteiligten Stellen zu be-fragen sowie möglichst geeignete Metrikenund Prüfzeitpunkte für die Anforderungen fest-zulegen. Die Erhebungsergebnisse sind zu er-gänzen mit einer Analyse abgeschlossener Ent-wicklungsprojekte auf Anforderungen, die dort

Abb. 2: Nicht funktionale Anforderungen planen, steuern und kontrollieren


HMD 265 87

Prozess starten

Änderungen erforderlich?

Verantwortliche identifizieren

Matrix nicht funktionaler Anforderungen

Verantwortliche befragen

Projekte analysieren

Katalog nicht funktionaler Anforderungen

erstellen

Katalog durch Verantwortliche

verifizieren


finalisieren

Änderungen einpflegen

Prozess beenden

Projektdoku-mentationen

Aufstellung nicht funktionaler Anforderungen

Matrix nicht funktionaler Anforderungen

Aufstellungnicht funktionaler Anforderungen

Katalog nicht funktionaler AnforderungenAufstellung

nicht funktionaler Anforderungen

Matrixnicht funktionaler Anforderungen

Nein

Ja

wesentlich waren. Die in Tabelle 1 wiedergege-bene Matrix nicht funktionaler Anforderungenenthält eine Struktur für den zu erstellendenKatalog, die auf der Systematisierung aus Ab-schnitt 2 basiert. Zugleich sind in den Spaltenjene Bereiche genannt, die nach ITIL (V3) für dienicht funktionalen Anforderungen zuständigsind. In den Zellen der Matrix sind dann die je-

weils Verantwortlichen zu nennen. Die Matrixkann somit als Vorlage zur Erstellung einesKatalogs nicht funktionaler Anforderungen die-nen. Der Prozess zur Erstellung des Katalogs istin Abbildung 3 dargestellt.

Der Teilprozess »Katalog nicht funktionalerAnforderungen pflegen und verwalten« um-fasst die Dokumentation von Änderungen an

Abb. 3: Katalog nicht funktionaler Anforderungen initial erstellen


88 HMD 265

Prozess beenden

Änderungen identifizieren

Change-Doku-mentationen

Änderungen identifizieren

Change-Doku-mentationen

Änderungen an Entwicklungs-

projekte melden

Liste nichtfunktionaler Anforderungen

Änderungen an Entwicklungs-

projekte melden

Liste nicht funktionaler Anforderungen

Änderungen erfassen

Katalog nichtfunktionaler Anforderungen

Änderungen erfassen


Change Management

einer Betriebsumgebung, die Änderungen nichtfunktionaler Anforderungen zur Folge haben(Abb. 4). Der Prozess ist daher an das ChangeManagement zu koppeln.

Für ein bestimmtes Entwicklungsprojekt istder Katalog im Rahmen der Anforderungsanaly-se an spezifische Merkmale der zu entwickeln-den Anwendung anzupassen. Hierbei ist zu prü-fen, ob die im Katalog enthaltenen Anforde-rungen für das Entwicklungsprojekt relevantsind und zu welchem Prüftermin die Erfüllungder Anforderungen zu prüfen ist. Gegebenen-falls sind projektspezifische Anforderungen an-zufügen. Somit wird aus dem allgemeinen Ka-talog nicht funktionaler Anforderungen eineprojektspezifische Liste abgeleitet (siehe Teil-prozess in Abb. 5).

Die Kontrolle, ob nicht funktionale Anforde-rungen in einem bestimmten Entwicklungspro-jekt erfüllt werden, wird über den Teilprozess»Erfüllung nicht funktionaler Anforderungenprüfen« gesteuert. Geeignete Koordinations-

maßnahmen müssen sicherstellen, dass ggf.frühzeitige Signale für eine Abweichung derEntwicklung von nicht funktionalen Anforde-rungen erhalten werden, um rechtzeitig gegen-steuern und damit spätere kostenintensiveNacharbeiten und Korrekturen vermeiden zukönnen [Disterer & Rose 2008]. Dabei muss diefrühzeitige Identifizierung, Analyse, Spezifika-tion und Abstimmung nicht funktionaler An-forderungen kein zusätzlicher Aufwand fürdie Entwicklungsteams sein, sondern sie erfah-ren Unterstützung durch Verantwortliche ausder IT.

4 Ausblick

Nicht funktionalen Anforderungen kommt beider Entwicklung von Anwendungen eine ähn-lich hohe Bedeutung zu wie funktionalen An-forderungen. Jedoch werden nicht funktionaleAnforderungen häufig zu spät aufgegriffenoder vernachlässigt, ihre mangelhafte Berück-

Abb. 4: Katalog nicht funktionaler Anforderungen pflegen und verwalten


HMD 265 89

Prozess starten


erstellen

Liste nicht funktionaler Anforderungen mit Verantwortlichen

abstimmen

Liste nicht funktionaler Anforderungen an

Projektteam übergeben

Prüftermine für nicht funktionale

Anforderungen mit Verantwortlichen

festlegen

Prozess beenden



Projektplan

Liste nicht funktionaler Anforderungen Liste

nicht funktionaler Anforderungen

Änderungen erforderlich?

Liste nicht funktionaler

Anforderungen überarbeiten

Nein

Ja

sichtigung führt zu erheblichen Friktionen beider Inbetriebnahme von Anwendungen.

Um nicht funktionalen Anforderungen aus-reichende Aufmerksamkeit zu sichern und de-ren Erfüllung zu unterstützen, wird die Auf-stellung eines Katalogs aller nicht funktiona-len Anforderungen eines Unternehmens oder

einer Betriebsumgebung vorgeschlagen. Die-ser Katalog ist dann für Entwicklungsprojektewiederverwendbar, indem aus ihm die jeweilsrelevanten Anforderungen zu Projektbeginnabgeleitet werden. Diese Aufgaben könnenmit dem Prozess »Nicht funktionale Anforde-rungen planen, steuern und kontrollieren«, der

Abb. 5: Katalog nicht funktionaler Anforderungen projektspezifisch anpassen


90 HMD 265

IT-B

etri

eb

Kun

de

Ser

vice

S

trat

egy

Ser

vice

D

esig

n S

ervi

ce T

rans

itio

n (P

roze

sse)

S

ervi

ce O

per

atio

n (o

rgan

isat

iona

l un

its)

Co

ntin

ual

S

ervi

ce

Imp

rove

-m

ent

Dri

tte

N

icht

fun

ktio

nale

A

nfo

rder

ung

en

Transition Planning &

Support

Change Mgmt

Asset and Configuration

Mgmt SACM

Release & Deploy-

ment Mgmt

Validation & Testing

Evaluation Mgmt

Knowledge Mgmt

Service Desk

Technical Mgmt

IT Opera-tion Mgmt

Application Mgmt

Service Reporting,

Service Measure-

ment

Per

form

anc

e (T

ran

sakt

ion

en …

)

S

tabi

lität

S

kalie

rbar

keit

(Res

sou

rcen

)

K

apaz

itäte

n (C

PU

-Ges

chw

ind

igke

it, R

AM

…)

Sch

nitt

stel

len

W

artb

arke

it

M

onito

ring

Bac

kup

(Ver

fah

ren

)

P

ortie

rbar

keit

(Sys

tem

e, S

ervi

ce P

rovi

der

)

Systembetrieb

Abh

ängi

gkei

ten

(Sys

tem

e/-k

omp

one

nten

)

S

tand

ards

(C

odie

rung

, D

esi

gn,

Pro

zess

e …

)

D

okum

enta

tion

/ In

form

atio

n

Nac

hvol

lzie

hbar

keit

Tes

ts

Abn

ahm

e

Produkt

Impl

em

entie

rung

A

ntw

ortz

eite

n

Z

uver

läss

igke

it

K

orre

kthe

it

Ben

utzb

arke

it

Dat

ensc

hutz

D

aten

sich

erh

eit

Ges

etze

Methoden

Kon

tro

llier

bark

eit

(Mon

itorin

g, R

epor

ting

…)

Tab.

1: M

atrix

nich

t fun

ktio

nale

r Anf

orde

rung

en u

nd V

eran

twor

tlich

er g

emäß

ITIL

(V3)


HMD 265 91

ITIL-konform innerhalb von »Transition Plan-ning and Support« anzusiedeln ist, und seinenTeilprozessen bewältigt werden.

Damit kann sichergestellt werden, dass beider Entwicklung von Anwendungen nicht funk-tionale Anforderungen frühzeitig und rechtzei-tig bekannt, bei der Entwicklung berücksichtigtund durch die Anwendungen erfüllt werden.Die frühzeitige Überprüfung der Erfüllung istdurch geeignete Koordinationsmechanismenzu sichern. Insgesamt kann damit nach derInbetriebnahme neuer Anwendungen ein stö-rungsfreier, stabiler und wirtschaftlicher IT-Be-trieb besser gewährleistet werden.

5 Literatur[Chung et al. 1999] Chung, L.; Nixon, B. A.; Yu, E.;

Mylopoulos, J.: Non-Functional Requirements inSoftware Engineering. Kluwer, Boston u. a.,1999.

[Disterer & Rose 2008] Disterer, G.; Rose, M.: Über-gang aus Entwicklungsprojekten in den Be-trieb. In: Höhn, R.; Petrasch, R.; Linssen, O.(Hrsg.): Vorgehensmodelle und der ProductLife-Cycle – Projekt und Betrieb von IT-Lö-sungen. Proc. 15. Workshop der FachgruppeWI-VM der Gesellschaft für Informatik GI. Aa-chen, Shaker, 2008, S. 19-30.

[Ebert 2005] Ebert, C.: Systematisches Require-ments Management. dpunkt.verlag, Heidel-berg, 2005.

[Ebert 2006] Ebert, C.: Trends im Requirements Ma-nagement. In: HMD – Praxis der Wirtschafts-informatik, Heft 248, 2006, S. 92-106.

[IEEE 1990] IEEE (Hrsg.): Standard 610.12-1990, IEEEStandard Glossary of Software Engineering Ter-minology. IEEE, New York, 1990.

[Kruchten 1998] Kruchten, P.: The Rational UnifiedProcess – An Introduction. Addison-Wesley,Reading u. a., 1998.

[OGC 2007a] OGC Office of Government Commerce(Hrsg.): Service Design. TSO, London, 2007.

[OGC 2007b] OGC Office of Government Commerce(Hrsg.): Service Transition. TSO, London, 2007.

[Partsch 1998] Partsch, H.: Requirements-Enginee-ring systematisch. Springer-Verlag, Berlin u. a.,1998.

[Rupp 2007] Rupp, C.: Requirements-Engineeringund -Management. 4. Aufl., Hanser, München,2007.

[Sommerville 2007] Sommerville, I.: Software Engi-neering. 8. Aufl., Pearson, München u. a., 2007.

Prof. Dr. Georg DistererFachhochschule HannoverFakultät für Wirtschaft und InformatikDipl.-Wirt.-Inf. (FH) Matthias RoseFachhochschule HannoverKompetenzzentrum Information Technology and Management (CC_ITM)Ricklinger Stadtweg 12030459 Hannover{georg.disterer, matthias.rose}@fh-hannover.dewww.fakultaet4.fh-hannover.de

nicht funktionale anforderungen bei der inbetriebnahme von anwendungen

Documents