Modellbasiertes Requirements Engineering: Von der Anforderung zum ausführbaren Testfall

geschützt.

1 Einleitung

1.1 Motivation zu diesem Buch

Es ist Freitagmittag. Herr Maier denkt bereits genüsslich über seinen baldigen Feierabend nach – da steht sein Chef in der Tür: „Wir haben hier ein neues Thema auf dem Tisch. In zwei Wochen muss das Fachkonzept „Urlaub beantragen fertig erstellt sein. Bitte übernehmen Sie das. Na super, denkt sich Maier. Und das vor dem Wochenende. Keine Ahnung, was ich da genau machen soll. Jetzt bräuchte man eine Anleitung, wie das konkret funktioniert und die IT-Abteilung auch was damit anfangen kann …

Das ist eine Situation, wie sie in der Praxis sehr häufig in ganz verschiedenen Themengebieten vorkommt. Im Zuge der wachsenden Globalisierung und des enormen Wettbewerbsdrucks sind wir mit ständigen Veränderungen in immer kürzeren Zeiten konfrontiert. Es ist eine große Herausforderung für alle Beteiligten, den Anforderungen gerecht zu werden und dabei die Qualität in ausreichendem Maße sicherzustellen. Das erfahren und erleben wir täglich in unseren Projektaufträgen bei Unternehmen in unterschiedlichen Branchen.

Es ist eine ständige Gratwanderung in der Abwägung zwischen Zeit, Ressourcen und Qualität. In der Regel wird – teils bewusst, teils unbewusst – bereits auf dem kritischen Pfad geplant, ohne jeglichen Puffer. Dabei wissen wir alle aus Erfahrung, dass Projekte niemals zu 100 % von Beginn bis zum Schluss so ablaufen, wie anfangs gedacht. Es passieren immer Dinge auf dem Weg, die nicht absehbar waren, übersehen wurden oder als neue Randbedingung aus aktuellen Gegebenheiten dazu kommen.

Zusätzlich zu alldem wird ein Thema besonders stiefmütterlich behandelt – die Dokumentation. Wir hören oft „das können wir später noch machen – wir wissen alle: Später wird in der Regel nichts mehr dokumentiert. Leider fehlen in der Praxis häufig ganze Fachkonzepte für bestehende Programme, oder Fachkonzepte sind nicht einheitlich strukturiert und archiviert. Vorhandene Dokumentationen liegen an verschiedenen („versteckten) Orten, in unterschiedlichen Formaten. Oft wird nur ein fachliches Grobkonzept erstellt, ein fachliches Feinkonzept – also eine Detaillierung bis auf Datenfeldebene – existiert nicht. Ein Beispiel dazu aus dem Projektalltag:

Ein Unternehmen erteilte den Auftrag, zwei Kernsysteme, die bereits seit über 30 Jahren im Einsatz waren, nachzudokumentieren. Grund dafür war, dass die einzigen beiden Mitarbeiter, die die Systeme noch umfangreich kannten und eine Masse von Informationen dazu im Kopf hatte, in sechs Monaten in Rente gehen würden. Jetzt galt es, soviel wie möglich an Dokumentation zu sichern. Aber jeder kann sich vorstellen, wie eingeschränkt diese Aufgabe zu erfüllen war. Denn die Zeit war beschränkt auf sechs Monate. Es gab nur eine uralte fachliche Dokumentationsbasis. In 30 Jahren wurden massenweise fachliche Änderungen vorgenommen. Und keiner konnte im Detail sagen, wie diese umgesetzt waren. Warum ist das in der Praxis ganz häufig so? Dafür gibt es verschiedene Gründe.

Aus unserer Erfahrung liegt es oft an mangelnder geplanter Zeit und unzureichenden methodischen Kenntnissen. Der Kostenfaktor spielt immer eine entscheidende Rolle. Es wird angenommen, dass ein Projekt Geld sparen könnte, wenn es weniger Zeit in die fachliche Konzeption steckt – ein Irrtum, wie sich in den meisten Fällen herausstellt. Häufig besteht auch ein unterschiedliches Verständnis der Aufgabenabgrenzung zwischen Fachbereich und IT – sprich: Was ist fachliche Beschreibung und was ist IT-Umsetzung?

Der vermeintliche Gedanke, dass alle doch wüssten, worum es geht, beweist sich in der Praxis als absoluter Trugschluss. Aber kaum jemand traut sich zu fragen – denn niemand möchte als unwissend dastehen. Dabei ist die Dokumentation entscheidend wichtig, um im Detail zu klären, was getan werden soll. Niemand kann alles wissen und hat sämtliche relevante Sichtweisen im Fokus. Es braucht die Köpfe und das Know-how aller Beteiligten. Geschieht das nicht, ist ganz viel Raum für Interpretation und genau das wird zum großen Problem.

Das Grobe in der Software funktioniert oft, aber der Teufel steckt im Detail und das bringt häufig hohe zusätzliche Kosten, enorme Zeitverschiebungen, gravierende Mängel in der Qualität, Unzufriedenheit bei den Beteiligten, Akzeptanzprobleme bei den Anwendern und vieles mehr. Jeder von uns kennt das. Um trotz aller dieser Gegebenheiten ein bestmögliches Ergebnis zu erreichen, gibt es praxistaugliche, strukturierte Vorgehensweisen, die durch verschiedene Methoden unterstützt werden. Wir möchten aus unserer Erfahrung einen möglichen Weg aufzeigen, der funktioniert. Das ist Anlass und Motivation zu diesem Buch.

Zum Thema Requirements Engineering und Management gibt es zahlreiche Literatur auf dem Markt, die ausführlich nach verschiedenen Schwerpunkten das Thema analysiert und darstellt. Beispielhaft sei hier genannt das Werk von Chris Rupp u. die SOPHISTen¹, das wir, soweit relevant für unser Buch, referenzieren.

Definierte Standards, wie das Vorgehen nach dem International Requirements Engineering Board (IREB), unterstützen zudem eine Vereinheitlichung des Sprachgebrauchs und sorgen für gemeinsames Verständnis in den Begrifflichkeiten. Das ist in jedem Fall hilfreich, wenn wir bedenken, wie viele unterschiedliche Beteiligte es im Rahmen des gesamten Softwareentwicklungsprozesses geben kann, mit ganz unterschiedlichen Kenntnissen, Sichtweisen, Zielsetzungen, Interpretationen der Geschehnisse und so weiter.

„IREB, das International Requirements Engineering Board, ist eine Non-Profit-Organisation und der Entwickler des CPRE(Certified Professional for Requirements Engineering)-Zertifizierungskonzepts. Die Boardmitglieder sind unabhängige und international anerkannte Experten aus Industrie, Beratung, Forschung und Lehre. Das Board wurde 2006 gegründet. Seine Mitglieder haben sich mit der Vision zusammengeschlossen, Requirements Engineering auf ein professionelles Fundament zu stellen, um dieser Disziplin den Stellenwert und die Ausprägung zu geben, die ihrem Mehrwert für die Industrie entspricht. IREB ist heute zum weltweit anerkannten Expertengremium für die Personenzertifizierung von Fachkräften im Requirements Engineering geworden"².

Unser Buch konzentriert sich speziell auf ein konkretes operatives Vorgehen – eine Handlungsanleitung zum modellbasierten Requirements Engineering. Inhaltlicher Schwerpunkt ist das methodische Vorgehen, basierend auf den praktischen Erfahrungen der Autoren. Es gibt keinen besonderen Branchenbezug.

1.2 Zielgruppen des Buchs

Alle Leser sind herzlich eingeladen, die sich für unser Buch interessieren!

Besonders spannend ist es für alle Beteiligten, die das Fachkonzept erstellen bzw. es als Basis für die weiterführenden Aufgaben im Rahmen der Softwareentwicklung verwenden. Das betrifft Fachabteilungen, IT-Bereiche, Testverantwortliche, aber auch Projektmanager und organisatorische Bereiche, die aus dem Umfang der Fachkonzeption die entsprechenden Zeit-, Budget- und Ressourcenplanungen ableiten und umsetzen.

Die namentliche Definition der einzelnen Konzepte, Rollen und Aufgaben sind nach unserer Erfahrung in den Unternehmen sehr unterschiedlich. Am Ende ist aber nicht entscheidend, ob es „Fachliche Beschreibung, „Fachliches Feinkonzept oder anders heißt. Egal, ob die Rolle Anforderungsmanager, Koordinator oder anders heißt, es kommt auf das sinnvolle methodische Vorgehen im Rahmen des gesamten Softwareentwicklungsprozesses und die Richtigkeit und Vollständigkeit der Inhalte an, um am Ende das Ergebnis zu erzielen, das vom Auftraggeber angefordert ist – in Qualität, Zeit und Budget.

1.3 Gliederung des Buchs

Der „rote Faden" dieses Buchs zeigt einen praktischen Weg von der Idee zur fachlichen Beschreibung mit Hilfe der Methoden im Requirements Engineering – differenziert betrachtet nach klassischem und agilem Vorgehen. Es wird erläutert, wie durch das modellbasierte Requirements Engineering mit Hilfe von UML eine strukturierte Dokumentation erarbeitet wird, die Anforderungen nachvollziehbar macht und die Basis zur gezielten Umsetzung liefert.

Zum praktischen Verständnis verwenden wir das durchgängige Beispiel „Urlaubsantrag". Darauf kommen wir immer wieder zurück und verdeutlichen das methodische Vorgehen.

Im ersten Teil beschäftigen wir uns mit dem gedanklichen Weg von der Idee hin zu weiter detaillierten Anforderungen – mit methodischer Unterstützung. Es wird das klassische Requirements Engineering kurz vorgestellt und einer der wichtigsten Ergebnistypen, das Fachkonzept, detailliert erläutert. Das konkrete Vorgehen ist in den einzelnen Kapiteln mit Schritten versehen. Am Ende jedes Schritts ist das Ergebnis formuliert, die in der Zusammenfassung nochmals im Sinne einer Checkliste aufgeführt sind. Daran anschließend wird das Requirements Engineering in agilen Projektkontexten betrachtet.

Der zweite Teil beschreibt eine Methodik, wie das Requirements Engineering durch modellbasierte Ansätze unterstützt und professionalisiert werden kann. Dabei wird unter anderem die Modellierungssprache UML verwendet. Gezeigt werden auch die vielfältigen Einsatzmöglichkeiten von Modellierungswerkzeugen für ein modellbasiertes Requirements Engineering.

In diesem zweiten Teil kommen verstärkt Programmierbeispiele zum Einsatz. Der Leser, der mit dem Thema Programmierung nicht vertraut ist, kann diese Programmierabschnitte bedenkenlos überspringen. Leser, die sich mit der Programmiersprache C# gut auskennen, mögen die teilweise naive Implementierung entschuldigen, aber bei dem Beispielcode geht es darum, die Ideen zu verdeutlichen und die dargestellte Programmierung sollte eher als Pseudocode verstanden werden, denn als perfekte C#-Implementierung.

Abgeleitet daraus erfolgt in einem dritten Teil die Betrachtung des Nutzens für den Test bzw. das Test Engineering. Es werden die grundlegenden Testbegriffe und Teststufen erläutert und diese mit dem modellbasierten Requirements Engineering verbunden. Daraus ergeben sich dann elegante Möglichkeiten, aus fachlichen Modellen Testfälle automatisiert zu generieren.

Ein weiteres wichtiges Kapitel beschäftigt sich mit dem Aufbau der Projektstruktur, dem Teamaufbau und den notwendigen Rollen, die beim modellbasierten Requirements Engineering erforderlich sind. In diesem Zusammenhang wird auch betrachtet, welche Rahmenbedingungen für dieses Vorgehen geschaffen werden müssen, beispielsweise die Unterstützung durch das Management oder die ausreichende Vermittlung von entsprechenden methodischen Kenntnissen für die Beteiligten.

Modellbasiertes Requirements Engineering ist ein spannendes Thema, dass die Herausforderungen unserer heutigen Zeit in der Softwareentwicklung aufgreift und einen konstruktiven Weg zeigt, damit effizient umzugehen und gleichermaßen das Ziel einer hohen Qualität und Zufriedenheit bei den Beteiligten zu verfolgen. Lassen Sie sich ein auf neue Wege – es lohnt sich, das können wir aus eigener Erfahrung berichten.

1.4 Danksagungen

Die Autoren sprechen allen Mitwirkenden an diesem Buch ihren herzlichen Dank aus.

Insbesondere bedanke ich, Alexander Ritter, mich sehr bei meiner Frau Yvette für die Unterstützung und die Verbesserungsvorschläge, während ich an meinen Texten schrieb. Nicht zuletzt wurde während dieser Zeit unser erstes Kind geboren – wofür ich ihr ebenfalls sehr zu Dank verpflichtet bin.

Dank gilt insbesondere unseren vier Reviewern, ohne deren Hinweise dieses Buch nicht diese Kohärenz erhalten hätte, die bei drei Autoren zwangsläufig schnell verloren geht: Birgit Bruchmüller, Sven Dockter, Stefan Petersen und Heinz Scheeres.³

Dank auch an die Unterstützung durch den entwickler.press-Verlag, hier namentlich erwähnt, als Stellvertreterin für ihre Kollegen und Kolleginnen: Martina Raschke. Ohne ihren Einsatz wären wir gar nicht auf die Idee gekommen, dieses Buch zu publizieren.

Die Autoren erreichen Sie unter der E-Mail Adresse: mReqEng@gmx.de.

1 Siehe Rupp, C. (2012) und Rupp, C. (2014).

2 https://www.ireb.org/de/about/basics/

3 In alphabetischer Reihenfolge.

2 Requirements Engineering

2.1 Grundsätzliches zum Requirements Engineering

2.1.1 Der Begriffswald

Zu Beginn hatten wir unseren Herrn Maier vorgestellt. Der kämpft nach wie vor mit seiner Aufgabe zur Fachkonzepterstellung und denkt sich: „Man sieht den Wald vor lauter Bäumen nicht. Wovon reden die hier eigentlich alle?" Gehen wir gemeinsam mit Herrn Maier diesen Unklarheiten nach.

Wenn wir in Unternehmen die Frage nach dem Requirements Engineering stellen, sind die Ausprägungen der damit verbundenen Begriffe, Konzepte, Vorgehensweisen, Rollen und Aufgaben oft sehr unterschiedlich. Es gibt eine gewisse Bandbreite, was darunter verstanden wird, wo Requirements Engineering, häufig auch mit dem deutschen Begriff Anforderungsmanagement, anfängt bzw. aufhört. Aus dem Grund ist es hilfreich, zu Beginn eines Projektauftrages unter allen Beteiligten ein gemeinsames Verständnis herzustellen, um Missverständnissen vorzubeugen und Erwartungshaltungen abzugleichen. Dokumentiert in einem Glossar sind die Festlegungen dazu nachhaltig und können auch von neuen Projektmitarbeitern ohne zusätzlichen Aufwand nachvollzogen werden.

Zur Orientierung dienen auch hier wieder Standards:

Definition des Requirements Engineerings laut dem IREB¹:

Das Requirements Engineering ist ein systematischer und disziplinierter Ansatz zur Spezifikation und zum Management von Anforderungen mit den folgenden Zielen:

Die relevanten Anforderungen zu kennen, Konsens unter den Stakeholdern über die Anforderungen herzustellen, die Anforderungen konform zu vorgegebenen Standards zu dokumentieren und die Anforderungen systematisch zu managen.

Die Wünsche und Bedürfnisse der Stakeholder zu verstehen und zu dokumentieren.

Die Anforderungen zu spezifizieren und zu managen, um das Risiko zu minimieren, ein System auszuliefern, das nicht den Wünschen und Bedürfnissen der Stakeholder entspricht.

Definition der Anforderung nach IEEE²:

Eine Anforderung ist

eine Eigenschaft oder Fähigkeit, die von einem Benutzer (Person oder System) zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.

eine Eigenschaft oder Fähigkeit, die ein System oder Teilsystem erfüllen oder besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere, formell vorgegebenen Dokumente zu erfüllen.

eine dokumentierte Repräsentation einer Eigenschaft oder Fähigkeit gemäß (1) oder (2).

Herr Maier, hier ein praktischer Tipp für Sie:

Legen Sie ein Glossar mit einheitlich definierten Begriffen an in dem Maß, wie es in Ihrer Situation sinnvoll und erforderlich ist. Unterstützung liefert auch der Standard:

CPRE Glossar – Die Grundlage für die RE Begriffswelt³

Ergebnis: Glossar liegt vor.

2.1.2 Die Beteiligten

Wer sind eigentlich „die Beteiligten", die frühzeitig mit einzubinden sind? Das ist die Kernfrage der sogenannten Stakeholderanalyse.

„Ein Stakeholder eines Systems ist eine Person oder Organisation, welche (direkt oder indirekt) Einfluss auf die Anforderungen des betrachteten Systems hat."⁴

Dazu gehören beispielsweise Vertreter des Auftraggebers, Entscheider, Fachexperten, Architekten, Entwickler, Tester und Endanwender, um nur einige zu nennen. Werden wichtige Stakeholder zu Beginn vergessen und damit wesentliche Sichten nicht mit eingebunden, kann das später zu aufwendigen und teuren Änderungen führen. Deshalb ist die gewissenhafte Analyse von großer Bedeutung.

Nach dem IREB sollten mindestens folgende Stakeholderinformationen erfasst werden:

Name

Funktion (Rolle)

weitere Personen- und Kontaktdaten

zeitliche und räumliche Verfügbarkeit während der Projektlaufzeit

Relevanz des Stakeholders

sein Wissensgebiet und -umfang

seine Ziele und Interessen bezogen auf das Projekt

Herr Maier, hier ein praktischer Tipp für Sie:

Erstellen Sie sich eine Tabelle mit den in IREB genannten Kriterien. Bitten Sie bereits bekannte Stakeholder darum zu überlegen, wer noch mit beteiligt werden müsste. Auf diese Art decken Sie einen großen Kreis der Sichtweisen ab und werden die wesentlichen Beteiligten gemeinsam identifizieren.

Ergebnis: Übersicht über die Stakeholder liegt vor.

2.1.3 Die Nutzer des Fachkonzepts

Das Fachkonzept stellt grundsätzlich die Basis für den Fachbereich, die IT, den Test und das Projektmanagement dar.

Der Fachbereich erstellt das Fachkonzept zur konkreten und detaillierten Beschreibung seiner Anforderungen.

Gleichzeitig ist es die Grundlage für vertragliche Vereinbarungen im Fall externer Umsetzung.

Die IT benötigt das Fachkonzept zur gezielten Realisierung der Anforderungen.

Der Test verwendet das Fachkonzept zur strukturierten Ableitung von Testfällen.

Das Projektmanagement nutzt das Fachkonzept zur Überprüfung und ggf. Anpassung des geplanten Aufwands, der Zeit und des Budgets.

Wichtig ist die durchgängige Betrachtung und Nachvollziehbarkeit der Anforderungen über die verschiedenen Nutzergruppen und deren spezifischen Konzepte hinweg. Bedeutet: Eine Anforderung ist nachvollziehbar von der Anforderungsliste, über das Fachkonzept, das DV-Konzept, das Testkonzept bis hin zur Abnahme. Nur so kann sichergestellt werden, dass das Ergebnis aussieht, wie gewünscht.

Herr Maier, hier ein praktischer Tipp für Sie:

Erstellen Sie sich eine Tabelle mit Namen, Kontaktdaten und Rollen der einzelnen Nutzer des Fachkonzeptes. Wichtig ist, dass es auch immer benannte Vertreter im Fall von Abwesenheiten gibt, damit Abstimmungen zu jeder Zeit möglich sind und nicht wertvolle Zeit verloren geht.

Ergebnis: Übersicht über die Nutzer liegt vor.

2.1.4 Die fachliche Beschreibung

Warum ist das alles eigentlich so wichtig? Das kann doch die IT machen. Ich verstehe davon nichts, das ist nicht mein Job. Diese und ähnliche Aussagen begegnen uns in der Praxis immer wieder. Teilweise ist das auch durchaus nachvollziehbar. Denn in der Regel wird auf der sogenannten Fachseite niemand eingestellt mit der Kernaufgabe, Fachkonzepte zu schreiben.

Das denkt sich wohl auch unser Herr Maier, aber es hilft ihm nichts. Also helfen wir ihm schrittweise weiter.

Im Kern geht es darum, Anforderungen zu sammeln, zu strukturieren und verständlich zu dokumentieren. Und genau dafür sind Mitarbeiter der Fachseite zwingend notwendig, denn das sind die Anwender und die „Kenner" der fachlichen Abläufe, die durch IT-Systeme sinnvoll unterstützt werden sollen. Genau das Wissen wird gebraucht.

Grundsätzlich kann man sagen: Solange es um Was-Fragen geht (Was soll umgesetzt werden?), handelt es sich um fachliche Beschreibungen, die im Fachkonzept dargestellt werden. Alle Wie-Fragen (Wie soll etwas umgesetzt werden?) beschreibt die IT im DV-Konzept. Welche Namen dabei die einzelnen Konzepte haben, ist individuell sehr unterschiedlich und am Ende nicht entscheidend.

Abbildung 2.1: Fach- und DV-Konzepte im Softwareentwicklungsprozess

Wichtig ist, dass alle notwendigen fachlichen und technischen Inhalte vollständig, eindeutig verständlich, nachvollziehbar und nicht über diverse Dokumente verlinkt beschrieben sind, so dass sie auch gefunden werden können. Leider ist das oft nicht der Fall.

Eines der größten Probleme im Requirements Engineering und in der Softwareentwicklung ist die Interpretation aufgrund unzureichend detaillierter Beschreibung. Es wird (zu) häufig davon ausgegangen, dass Dinge für alle Beteiligten gleichermaßen klar sind, zum Beispiel aktuelle Prozesse und Abläufe, Vorgehensweisen oder Softwaresysteme. Und oft trauen sich Mitarbeiter auch nicht zu fragen, wenn sie etwas nicht verstanden haben und etwas unklar ist. In der Rolle als externer Berater können und müssen wir nachfragen und stellen darüber oft fest, dass es sehr unterschiedliche Kenntnisstände der Beteiligten gibt. Wenn dann noch die Situation dazukommt, dass die Entwicklung und der Test an externe Firmen ausgelagert werden, die über keine internen Kenntnisse der Abläufe verfügen und sich ausschließlich an das Fachkonzept halten, gewinnt die interpretationsfreie Beschreibung der Anforderungen zusätzlich an Bedeutung. Aus dem Grund bedarf Requirements Engineering eines strukturierten und methodischen Vorgehens.

Ein ganz wichtiger Punkt ist, und das soll an dieser Stelle nochmals ausdrücklich erwähnt werden, dass die späteren Anwender frühzeitig mit eingebunden werden. Sonst besteht das Risiko, dass Softwarefunktionen konzipiert und umgesetzt sind, die später niemand nutzt. Das verschwendet Zeit, Budget, Ressourcen und mindert die Akzeptanz der Software bei den Anwendern, eine schlechte Voraussetzung für die Produktivsetzung.

2.1.5 Die Anforderungsarten

Wichtig für die Vollständigkeit der Beschreibung im Fachkonzept ist die Berücksichtigung der unterschiedlichen Anforderungsarten.

Anforderungen lassen sich nach Rupp⁵ in ihrer Art unterscheiden und damit auch geeignet in Gruppen sortieren:

funktionale Anforderungen

technologische Anforderungen

Qualitätsanforderungen

Anforderungen an die Benutzeroberfläche

Anforderungen an sonstige Lieferbestandteile

Anforderungen an durchzuführende Tätigkeiten

rechtlich-vertragliche Anforderungen

Das IREB definiert eine funktionale Anforderung wie folgt:

„Eine funktionale Anforderung ist eine Anforderung bezüglich des Ergebnisses eines Verhaltens, das von einer Funktion des Systems (oder einer Komponente eines Service) bereitgestellt werden soll."⁶

Oft werden allerdings nur die funktionalen Anforderungen beschrieben, andere werden vergessen oder (fälschlicherweise) ausschließlich in der Verantwortung der IT gesehen. Das betrifft vielfach die sogenannten nicht-funktionalen Anforderungen wie beispielsweise Performance, Antwortzeiten, Mengengerüste oder Anforderungen an Sicherheit. Die generellen Anforderungen dazu sind fachlich begründet. Je nachdem, um welches konkrete Thema es sich im Fachkonzept handelt, stellen sich Fragen wie:

Wie viele Anwender werden grundsätzlich mit dem System arbeiten?

Wie viele Anwender werden maximal parallel in dem System arbeiten?

Wie kritisch bzw. vertraulich/geheim sind die Daten, die im System verarbeitet werden?

Wie lange darf das System zwischenzeitlich ausfallen?

Muss die Verarbeitung im System in Echtzeit laufen?

Ist eine Hochverfügbarkeit des Systems erforderlich?

Wie lange dürfen bestimmte Antwortzeiten des Systems dauern? Was kann dem Anwender „zugemutet" werden und ist wirtschaftlich vertretbar?

Aus den Aussagen des Fachbereiches dazu leitet die IT entsprechende Maßnahmen für die Umsetzung ab. Gegebenenfalls muss zusätzliche Hardware gekauft oder es müssen neue Sicherheitsstufen eingebaut werden. Vielleicht ist auch eine Systemspiegelung notwendig. In jedem Fall sind es IT-seitig angepasste Maßnahmen, die häufig mit zusätzlichen Kosten verbunden sind und damit geplant und genehmigt werden müssen. Der Nachweis der fachlichen Notwendigkeit ist dafür zwingend erforderlich, um die Ausgaben entsprechend zu begründen.

Auch technische Anforderungen stellen eine wichtige Rahmenbedingung für die fachliche Konzeption dar und werden, sofern vorhanden, von der IT zugeliefert. Sie können die fachliche Konzeption wesentlich beeinflussen, beispielsweise wenn es Änderungen in der technischen Architektur gibt oder auf neue (moderne) Verfahren umgestellt wird. Aus dem Grund ist es wichtig, sich frühzeitig mit dem IT-Bereich abzustimmen, damit später auch der Weg fachlich beschrieben wird, der auf der IT-Seite grundsätzlich umgesetzt werden kann.

Herr Maier, hier ein praktischer Tipp für Sie:

Klären Sie frühzeitig, wer erster Ansprechpartner für Sie und Ihr