Anforderungen & Anforderungsquellen
Von Stefan Jung | 25. Mai 2013 | Kategorie: Anforderungsmanagement | 1 KommentarZu Beginn eines jeden Projektes steht die Aufnahme der Anforderungen. Die Methodik (Agil vs. Wasserfall) spielt in der ersten Iteration eine untergeordnete Rolle und kommt in der nachfolgenden Projektphase zum Tragen. Wo kann man also starten?
Anforderungstypen
Zum Einstieg möchte ich kurz eine Auswahl an Anforderungstypen als notwendigen Input für die Wahl der Quellen beleuchten.
- Architektonische Anforderungen
… behandeln insbesondere die Themen System und Systemkontext. Architektonische Anforderungen münden häufig in Integrationen, die zur Vereinfachung hier nicht gesondert geführt werden. - Funktionale Anforderungen
… behandeln Funktionalitäten des Zielsystems. - Nicht-funktionale Anforderungen
… behandeln alle nicht-funktionalen Aspekte wie z.B. Qualität, Usability, Betrieb, Vertragsgestaltung, etc. - Anforderungen an Daten (und Datenqualität)
… behandeln Anforderungen gegenüber Daten und Datenqualität. Ein sehr wesentlicher Aspekt, der in vielen Bereichen leider unterrepräsentiert ist.
Anforderungsquellen
Nun zum eigentlich spannenden Teil – woher erhalte ich verlässliche Anforderungen für die wesentlichen Anforderungstypen? Im Grunde liegen drei große Quellen vor, nämlich
- Dokumente,
- Systeme,
- Personen / Stakeholder
wobei man vor dem Hintergrund eines effektiven Einsatzes der eigenen Arbeitszeit als Requirements Engineers gut beraten ist, im Vorfeld der Erhebung eine Validierung der Quellen durchzuführen.
Bitte beachten Sie dabei, dass die folgende beispielhafte Aufstellung im konkreten Kontext anders aussehen wird.
| Nr. | Anforderungstyp | Anforderungsquelle | Priorität | Bemerkung |
|---|---|---|---|---|
| 1 | Architektonische Anforderungen | Dokumente | hoch | Insbesondere Strategie- und Architekturdokumente und Richtlinien. |
| Systeme | mittel | Die Analyse der bestehenden Systemlandschaft beantwortet Fragen zu Integrationsthemen, birgt aber als ausschließliche Quelle das Risiko, dass man wesentliche Entscheidungen für die zukünftige Ausrichtung nicht berücksichtigt. | ||
| Personen | hoch | Insbesondere Entscheider bezüglich Architekturthemen. | ||
| 2 | Funktionale Anforderungen | Dokumente | mittel | Systemdokumentation, Prozessdokumentation, auch z.B. Organisationscharts. Beschreiben den Ist-Zustand und ermöglichen das 'Einlesen'. Der Soll-Zustand kann nur bedingt entnommen werden (insb. für Themen, in denen keine Änderungen geplant sind). |
| Personen | hoch | Die Stakeholder (insb. spätere User & Entscheider) sind die eigentliche Quelle für die Anforderungen an den Zielzustand. In Kombination mit der Dokumentation des Ist-Zustandes lässt sich eine GAP Analyse durchführen. | ||
| Systeme | hoch | Systeme lassen sich untersuchen. Dies gibt Rückschlüsse auf Funktionalitäten wie auf enthaltene Daten, Bedienkonzepte, etc. | ||
| 3 | Nicht-funktionale Anforderungen | Dokumente | mittel | Gibt es dokumentierte Anforderungen an Oberflächen, Bedienkonzepte, den Betrieb des Systems, etc. ? |
| Personen | hoch | Für nicht-funktionale Anforderungen ist der Kreis der Personen, die Auskünfte geben können und sollten häufig größer als bei funktionalen Anforderungen. | ||
| Systeme | hoch | Insb. für Usability, Betrieb, Sicherheit, Technologien lohnt sich ein Blick in die bestehenden Systeme. | ||
| 4 | Anforderungen an Daten und Datenqualität | Dokumente | niedrig | Wenn Daten in Systemen wohnen erhält man einen aktuellen Stand auch dort. Dokumente (sofern überhaupt vorhanden) spielen dann meist eine eher untergeordnete Rolle. |
| Personen | mittel | User können beispielsweise Auskunft über Datenqualität geben. | ||
| Systeme | hoch | Die zu verarbeitenden Daten findet man im System selbst. |
[…] Anforderungsquellen habe ich schon beschrieben – wie man Anforderungen deutlich und verbindlich dokumentiert bzw. […]