Wozu das gut ist
Damit die eingesetzte Technik zu den Geschäftsprozessen passt und nicht umgekehrt. Requirements Engineering ist das Werkzeug, mit dem Technik, Prozesse und die Bedürfnisse der Benutzer abgeglichen werden, bevor eine Entscheidung fällt.
Ohne diesen Schritt wird beschafft, was in der Demo überzeugt hat, und danach angepasst, was sich anpassen lässt.
Wie das abläuft
Systematisch und in Workshops. Wir unterstützen dabei, sämtliche relevanten Anforderungen und Kenngrössen zu definieren und zu erfassen: funktionale wie nichtfunktionale, und insbesondere die Zahlen, die später über die Architektur entscheiden.
Dazu gehört eine Analyse der heutigen Systemnutzung und ein Ausblick auf die nächsten fünf Jahre als Massstab für die Skalierung. Anforderungen, die mehrere Services teilen, werden einmal erfasst. Das Ergebnis trägt auch einen Budgetantrag.
Was in den Workshops behandelt wird
Nicht alles auf einmal, aber diese Themen kommen in jedem Projekt vor:
- Verfügbarkeitsanforderungen, also RPO und RTO
- Kapazität und Leistung, heute und für den geplanten Zeitraum
- System- und Storage-Performance
- Security
- Rechenzentrumsstandorte
- Datenschutz
- Applikatorische Gegebenheiten und Legacy-Systeme
Der letzte Punkt ist der, der am häufigsten fehlt und am teuersten nachgereicht wird. Eine Anwendung, die eine bestimmte Datenbankversion braucht, entscheidet über die Architektur mit, ganz gleich was sonst geplant war.
Warum es zuerst kommt
Weil andere Dienstleistungen darauf aufbauen. Ein Data-Management-Konzept ohne bekannte Zugriffsmuster und Aufbewahrungsfristen ist ein Ratespiel, und ein Disaster-Recovery-Design ohne RPO und RTO ist keins.
Requirements Engineering ist deshalb selten das Projekt, für das jemand anruft, und häufig das, mit dem das Projekt anfangen sollte.
