Als IT ist man stets gefordert, die Anforderungen des Unternehmens zu verstehen und mit den eigens erbrachten Leistungen in Einklang zu bringen. Gleiches gilt bei Umsetzung von Projekten oder Softwareentwicklungen. Doch allein die bloße Erkenntnis führt noch nicht zu einem harmonisierenden Konsens bei derartigen Herausforderungen. Mit Requirements Engineering können auftretende Hürden wie beispielsweise Kommunikationsprobleme, ungleiches Verständnis, oder mangelnde Dokumentation systematisch bewältigt werden.
Businessanforderungen verstehen
Nicht selten findet man sich in diversen Rollen des IT Service Managements als Vermittler zwischen Technikern oder Entwicklern und dem Business. Beispiele dafür sind Business Relationsship Manager, Service Delivery Manager, Service Level Manager, Demand Manager, und sicherlich noch viele mehr.
Jeder dieser Rolleninhaber wird die Herausforderung kennen, dass die Anforderungen des Business mit dem, was nachher aus der IT geliefert wird, anfangs nicht annähernd deckungsgleich sind. Ob dabei ein agiles oder ein klassisches Vorgehensmodell gewählt wird, ist dabei erst einmal zweitrangig, dies wird allenfalls den Zeitpunkt des Eintretens dieses Risikos verändern.
Doch welches Ziel verfolge ich genau mit Requirements Engineering? Hierzu zitiere ich gerne folgende Definition aus der Publikation „Basiswissen Requirements Engineering“ von Klaus Pohl und Chris Rupp:
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 konform zu vorgegebenen Standards zu dokumentieren und die Anforderungen systematisch zu managen.
- Die Wünsche und Bedürfnisse der Stakeholder zu verstehen, zu dokumentieren und die Anforderungen zu spezifizieren und zu managen, um das Risiko zu minimieren, dass das System nicht den Wünschen und Bedürfnissen der Stakeholder entspricht.
Was ist eine Anforderung?
Desweiteren ein Blick auf die Definition einer einzelnen Anforderung, um gleich einmal selbst der Anforderung dieses Artikels gerecht zu werden; was verstehe ich als Author unter einer Anforderung und was verstehen Sie als Leser darunter?
Nach IEEE Std. 610.12-1990 definiert sich eine Anforderung anhand von 3 Kriterien:
- Eine Bedingung oder Fähigkeit, die vom Benutzer (Person oder System) zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.
- Eine Bedingung oder Fähigkeit, die ein System oder Teilsystem erfüllen oder besitzen muss, um einen Vertrag, eine Norm, einer Spezifikation oder andere, formell vorgegebene Dokumente zu erfüllen.
- Eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft gemäß 1. oder 2.
Soweit die Definition. Doch wie gehe ich vor, wie geht es weiter zur kontrollierten Aufnahme von Anforderungen, beziehungsweise anders gefragt, fängt es nicht erst einmal dort an herauszufinden, wen ich überhaupt Fragen muss? Dazu sollten die richtigen Stakeholder für das identifizierte Problem, Projekt, o.Ä. identifiziert werden. Dazu habe ich bereits einen Blogartikel verfasst: Stakeholder Management – Die richtige Information, zur richtigen Zeit, an die richtige Person. Hier finden sich einige nützliche Tipps und Ideen zum Vorgehen der Stakeholderanalyse nach ITIL.
Anforderungen richtig aufnehmen
Generell wird das Vorgehen im Requirements Engineering in die vier folgenden Haupttätigkeiten eingeteilt:
- Ermitteln
- Dokumentieren
- Prüfen und abstimmen
- Verwalten
Ermitteln:
– Identifizieren von Anforderungsquellen (Stakeholder, Dokumente, Systeme in Betrieb
– Ermitteln der Stakeholdererwartungen und -fähigkeiten (Input/Output)
– Aufnehmen der Anforderungen nach den drei Faktorentypen nach Kano:
– Basisfaktoren (vorausgesetzte Systemmerkmale) wie z.B. ein CRM System muss Kundendatensätze abspeichern können.
– Leistungsfaktoren (explizit geforderte Systemmerkmale) wie z.B. ein CRM System muss mindestens 500 Kundendatensätze abbilden können.
– Begeisterungsfaktoren (unbekannte Systemmerkmale) wie z.B. das CRM System funktioniert auch auf dem Smartphone, oder Kundendatensätze können auch verknüpft werden
– Anwendung von unterschiedlichen Ermittlungstechniken wie Befragungstechniken (Interview/Fragebogen), Kreativitätstechniken (Brainstorming/Perspektivenwechsel), dokumentenzentrierte Techniken (perspektivenbasiertes Lesen/Wiederverwendung), Beobachtungstechniken (Feldbeobachtung/Apprenticing) oder unterstützenden Techniken (Mindmapping, Workshops, Use Case Modellierung oder Prototyping)
Anforderungen können dabei immer aus den drei Perspektiven „Strukturperspektive“ (z.B. Infrastrukturlandschaft), „Funktionsperspektive“ (z.B. Datenflussdiagramm) und „Verhaltenperspektive“ (Reaktion bei bestimmten Trigger) betrachtet werden. Ein ähnliches Pedant bieten die bekannten „W-Fragen“.
Egal welcher Art der Ermittlung eine Anforderung entspringt, sollte diese folgenden Qualitätskriterien (ISO 29148:2011) entsprechen: eindeutig, notwendig, konsitent, prüfbar, realisierbar, verfolgbar, und vollständig.
Dokumentieren:
Das zu erstellende Anforderungsdokument stellt anschließend eine systematische Sammlung der zuvor ermittelten Anforderungen da. Das Dokument unterliegt dabei einigen Qualitätskriterien, wie Eindeutigkeit und Konsistenz, Klare Struktur, Modifizierbarkeit und Erweiterbarkeit, Vollständigkeit und Verfolgbarkeit.
Die Wahl des Formats der Dokumentation entscheidet sich nach Belieben, respektive der zuvor gewählten Perspektive der Anforderungsbetrachtung. Je nach Ziel der Anforderungsdokumentation kann ein Protokoll, eine offene Punkte Liste, Dokumentation in natürlicher Sprache oder (Use Case-, Klassen-, Aktivitäts- oder Zustands-)Diagramme dem Zweck am dienlichsten sein.
Ebenfalls nach Bedarf ist die Aufteilung der Anforderungsdokumentation in Lasten- und Pflichtenheft (nach V-Modell) zu verfolgen. Dabei stellt das Lastenheft für gewöhnlich das „Was“ und das „Wofür“ und wird vom Auftraggeber erstellt. Methodisch unterstützt jedoch der Requirements Engineer bei Bedarf den Auftraggeber bei dessen Formulierung. Mit dem Pflichtenheft formuliert dieser dann anschließend auf Basis der zuvor aufgeführten Techniken und der Inputs der identifizierten Stakeholder (Achtung, auch Umsetzer, nicht nur Anforderer!) die Anforderungen für eine Umsetzung des Lastenhefts, also das „wie“.
Die Einhaltung dieser groben Parameter unterstützt das schnelle Auffinden oder Ändern von Anforderungen. Bewährt hat sich hierzu der Einsatz von angepassten Dokumentenvorlagen. Diese werden mit einer Kombination aus natürlicher Sprache und kreativen- oder konzeptionellen Anforderungsmethoden vervollständigt.
Prüfen und abstimmen
Die zuvor festgelegten Anforderungen müssen den ebenfalls formulierten Qualitätsanforderungen nachkommen. Um dies sicherzustellen, bieten sich nun einige Techniken zur Sicherstellung dieser Zielsetzung an. Durch Prüfung und Abstimmung, beziehungsweise Review der Anforderungen, können jederzeit Abweichungen zwischen den ursprünglich dokumentierten Anforderungen und dem „Status Quo“ der Anforderung bzw. der Ergebnis-Erwartungshaltung der Stakeholder aufgedeckt und somit berücksichtigt werden. Dies ist besonders bei agilem Vorgehen unumgänglich, da sich hier schnell durch die ersten prüfbaren Deliveries auch wiederum die Anforderungen ändern können (iteratives Anforderungsmanagement).
Ein einzurichtender Review kann die Anforderungen dabei nach drei Qualitätskriterien beurteilen:
- Inhalt: Wurden alle relevanten Anforderungen ermittelt und im erforderlichen Detaillierungsgrad erfasst?
- Dokumentation: Wurden die Anforderungen gemäß der festgelegten Dokumentations- und Spezifikationsvorschriften dokumentiert?
- Abgestimmtheit: Stimmen alle Stakeholder mit den dokumentierten Anforderungen überein und sind alle bekannten Konflikte ausgelöst?
Für die Durchführung der Prüfung ist mit den passenden Stakeholdern ein angemessener Turnus zu vereinbaren und mit (ggfs. auch weiteren Stakeholdern) die Prüfung gemeinsam, nach o.g. Kriterien und unter folgenden Prinzipien durchzuführen:
– Beteiligung der richtigen Stakeholder
– Trennung von Fehlersuche und Fehlerkorrektur
– Prüfung aus unterschiedlichen Sichten
– Geeigneter Wechsel der Dokumentationsform
– (Re-)Konstruktion von Entwicklungsergebnissen zu Anforderungen
– Wiederholte Prüfung
Verwalten
Von nur wenigen einzelnen Anforderungen, bis hin zur gesamten Anforderungsdokumentation ist eine strukturierte Verwaltung von großer Wichtigkeit. Anforderungen können attributisiert, priorisiert, nummeriert sowie versioniert werden. Die Tiefe der Verwaltung ist nach Bedarf der Verfolgbarkeit, ergo der Menge an Anforderungen oder der Anzahl daran beteiligter Stakeholder zu identifizieren.
Bei einer bloßen Liste von 10 Elementen wird eine einfache Nummerierung ausreichen. Bei mehreren hundert Anforderungen, bspw. bei Einführung einer ITSM Suite, sind die Anforderungen mit einer bloßen Nummerierung irgendwann schwer aufzufinden. Mithilfe weiterer Attribute (Kurztitel, Identifier, Kategorie,…) kann der Komplexität Einhalt geboten werden und durch verbesserte Filtermöglichkeiten ein schnelleres Auffinden und besseres Verwalten der Anforderungen gewährleistet werden.
Um weitere Komplexitätsreduzierung bzw. Informationsgewinn zu gewährleisten, kann die Anfertigung von verdichtenden Sichten (Reporting) auf die vorhandenen Daten bzw. die zuvor vergebenen Attribute angefertigt werden. Werkzeuge wie die Excel Pivot Charts oder Tools wie Crystal Reports können bei der Aufbereitung der gewünschten Informationen unterstützen. Aus den generierten Charts lassen sich ggfs. erneute Anforderungen oder auch im Rahmen einer verbesserten Prüf- und Abstimmmöglichkeit Mehrwerte generieren.
Fazit
Mit diesen ersten Grundlagen kann das Ziel, eine zufriedenstellende Entwicklung zwischen Kundenanforderungen und dem entstehenden System oder Projekt zu gewährleisten, erreicht werden. Wichtig ist, denkt man an das allseits bekannte 4-Seiten Modell nach Schulz von Thun, dass man mit dem Requirements Engineering eine gemeinsame Kommunikationsbasis und vor allem einen gemeinsamen Konsens zwischen der Erwartungshaltung des Kunden und des Zielverständnisses der Entwickler oder Projektmitarbeiter schaffen kann. Ist das Arbeitsergebnis für beide Seiten gleichermaßen verständlich und interpretierbar formuliert, steht einer erfolgreichen Umsetzung gleich viel weniger im Weg.
Jan Kahmann