Schlagwortarchiv für: Anforderungsmanagement

Bild zu Rollen im RE

Die Rollen im Anforderungsmanagement

Neben den Anforderungsdokumenten haben wir auch noch die verschiedenen Rollen bei der Erstellung von Spezifikationen.

Auf der einen Seite haben wir den Kunden, der in seinem Lastenheft ein Problem beschreibt, das er gelöst haben will. Zusätzlich haben wir die Interessensgruppen, die ebenfalls ein Problem beschreiben, das sie allgemeingültig gelöst haben wollen.

Auf der anderen Seite haben wir das Projektteam mit jemandem, der sich mit dem ganzen Thema Requirements Engineering beschäftigt und versucht, überhaupt das Problem zu begreifen. Dann gibt es jemanden, der sich mit dem ganzen Systemdesign beschäftigt. Das ist jemand, der versucht, aus den Anforderungen eine Lösung zu definieren. Und dann haben wir einen Projektmanager, der halt in diesem ganzen Kontext noch versucht, das Team zum Erfolg zu führen.

Das zusammen ist genau die Schnittstelle, und wir sehen auch da: Auf der einen Seite liegen die Lastenhefte und auf der anderen Seite die Pflichtenhefte nach der klassischen Beschreibung.

Rollen im Anforderungsmanagement

Rollen im Anforderungsmanagement

Am Ende bilden die Rollen auch die Arbeitsergebnisse ab. Ein Requirements Engineer wird also die Anforderungsspezifikation (SRS) erschaffen. Ein Systemdesigner oder ein Systemarchitekt wird die Architekturspezifikation (SAS) schreiben, und der Projektmanager beschreibt in der Regel in seinem Projekthandbuch all die nichttechnischen Anforderungen an ein System.

Je komplexer Systeme werden oder je dynamischer ihre Funktion ist, desto wichtiger wird es, sich intensiv mit diesen Dokumenten und Spezifikationen zu beschäftigen. Ein System, das einen relativ einfachen Aufbau hat und auch keine großartige Dynamik besitzt, muss nicht in aller epischer Breite sämtliche oben beschriebenen Spezifikationen besitzen, wenn eigentlich klar ist, was wichtig ist. Das bedeutet aber, sie nicht komplett wegzulassen, sondern mit Sinn und Verstand nur das, was gebraucht wird, umzusetzen.

Je komplexer ein System wird oder gar je mehr Unterlieferanten dabei sind, also je mehr Menschen auch in diesem Projekt eingebunden sind, desto wichtiger werden Spezifikationen. Denn Spezifikationen sind am Ende nichts anderes als eine Dokumentation von Wissen.

Wie detailliert soll ich Anforderungen beschreiben?

In Pflichtenheften für komplexe Systeme ergibt es mit Sicherheit keinen Sinn, die letzten Controller-PINs oder den Variablennamen im Quellcode zu beschreiben.  Wichtig ist, dass ich das, was ich konzeptionell erwarte, z.B. ein Geschwindigkeitssignal in einer gewissen Auflösung in einem gewissen Wertebereich, beschreibe.  Wie das Software-Team das unten auf deren Ebene in seine Spezifikation und in seine Lösung umsetzt und dass da irgendwelche Coding-Styleguides berücksichtigt werden usw. usw., das werde ich oben auf Systemebene schon gar nicht beschreiben.

Das tue ich schlicht aus dem Grund, dass ich dem Team auch einen Lösungsraum bereithalte, mit dem es arbeiten kann. Das macht es gerade dann besonders schwierig, und das ist häufig auch meine Erfahrung, wenn Kunden versuchen, im Pseudocode im Lastenheft Funktionen zu beschreiben. Dann bin ich auf der Systemebene immer gefordert, davon wieder zu abstrahieren, um klar zu verstehen, was will der Kunde eigentlich will. In der Regel nehme ich dann SysML, um ein Verhalten als Diagramm darzustellen. Ein Pseudocode im Lastenheft geht nämlich schon fast bis zu Variablennamen herunter. Damit ist es a) schwer verständlich und b) schränkt es den Lösungsraum auf 0 ein.

Das mag zwar ganz nett sein, aber wir haben immer bei komplexen Systemen das Problem, dass wir zwischen verschiedenen Lösungsmöglichkeiten abwägen müssen. Wenn ich keinen Handlungsspielraum mehr habe, werde ich an der Stelle dermaßen fixiert, dass ich möglicherweise das gesamte System überhaupt nicht lösungs- und zielorientiert umsetzen kann. Bei all diesen Spezifikationen gilt für einen pragmatischen Einsatz: Je einfacher ein System und je weniger Anforderungen vorhanden sind, desto weniger müssen Sie sich mit komplexen Spezifikationsstrukturen herumschlagen.
Bei manchen reicht aus meiner Erfahrung heraus die Architekturspezifikation (SAS) völlig aus. Man soll in Verbindung mit dem System Footprint auf der Lastenheftebene (= Kundenebene = „Wünsch-dir-was“ des Kunden oder Produktmanagements) einfach pragmatisch bleiben.

Wichtig: Weglassen heißt nicht komplett weglassen, sondern nur, das, was sie mit Sinn und Verstand als nutzlos nicht brauchen. Aber definitiv lassen sie nicht diese gesamte Ebene weg, sonst kommen sie in Situationen, dass sie nachher nicht mehr nachvollziehen können, was sie da eigentlich wollten, und der Kunde nicht das Gewünschte bekommt.

Was ist ein Pflichtenheft?

Wie immer gibt es wunderschöne Normen, und gemäß der DIN 69901-5 enthält das Lastenheft „die vom Auftraggeber festgelegte Gesamtheit der Anforderung an die Lieferung und Leistungen eines Auftragnehmers innerhalb eines Auftrags“. So kann man es bezeichnen. Ich würde einfach das Ganze mal ein bisschen pragmatischer sehen: Das Lastenheft beschreibt in der Regel, womit und wofür etwas gemacht werden soll. Mit anderen Worten, es ist am Ende des Tages das „Wünsch-dir-was“ des Kunden aus seiner Sicht.

Aber auch über das Pflichtenheft sagt die DIN 69901-5 etwas: „die vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes“.  Schön, oder einfacher gesagt, das Pflichtenheft beschreibt, wie und womit etwas realisiert wird. Das ist dann die Antwort auf das Lastenheft des Kunden. Er schreibt sein Wünsch-dir-was, und im Pflichtenheft schreibe ich, wie ich das Problem verstanden habe und was ich davon umsetzen kann.

Ich habe ja einigen Episoden schon darüber referiert. Mir gefallen aus der heutigen Sicht die Begriffe „Lastenheft“ und „Pflichtenheft“ nicht mehr. Sie sind aus meiner Sicht zu allgemein. Wir müssen es gerade bei komplexeren Projekten detaillierter und differenzierter sehen. Und gerade beim Thema Systempflichtenhefte gibt es eben zwei Dokumente, die zusammen das Bild eines Pflichtenhefts ergeben. Auf der einen Seite das Dokument Systemanforderungsspezifikation (SRS), also die Beschreibung des Problembereichs. Das Ziel dieses Dokuments ist, die definierten Kundenanforderungen in einen Satz von technischen Systemanforderungen zu übertragen, die das System begleiten.

Dann gibt es noch ein zweites Dokument, die Systemarchitekturspezifikation (SAS). Das ist eigentlich der Lösungsbereich. Hier beschreibe ich, wie ich die Lösung entwerfen will, denn hier entstehen nochmals andere Anforderungen. Nicht alle Systemanforderungen werde ich erfassen, sondern ich muss mir auch auf der Architekturseite Gedanken über die Vollständigkeit der Anforderung machen. Das Ziel dieses Dokumentes ist die Identifikation, welche Anforderungen, welche Komponenten dann welchen Elementen des Systems zugeordnet werden müssen.

Diese beiden Dokumente sind zusammen ist eigentlich das, was im allgemeinen Sprachgebrauch Pflichtenheft genannt wird. Als Systemingenieur rede ich natürlich auch von dem Systempflichtenheft oder Systemspezifikationen, das heißt, beide Dokumente sind konzeptionell gehalten.

Aus der Praxis für die Praxis

 

Schlagwortarchiv für: Anforderungsmanagement

ZA221 - 11 Kriterien die Dein Werkzeug für Anforderungsmanagement erfüllen sollte

02.07.2024 50 Minuten



Zusammenfassung

In dieser Episode des Zukunftsarchitekten Podcasts wird ausführlich besprochen, welche Kriterien bei der Auswahl eines Anforderungsmanagement-Tools entscheidend sind. Ziel ist es, eine fundierte und objektive Auswahl zu treffen, die den spezifischen Bedürfnissen eines Projektes gerecht wird.

Bewertungskriterien für RM-Werkzeuge:

1. Anforderungen editieren:
– Dokumentation und Bearbeitung von Anforderungen, inklusive Attributierung und Anhänge.
– Frei konfigurierbare Metadaten und automatisierte Prozesse zur Verwaltung der Anforderungen.

2. Traceability:
– Aufbau und Verwaltung der Rückverfolgbarkeit von Anforderungen über den gesamten Projektlebenszyklus und ggf. darüber hinaus.
– Verlinkung von Anforderungen mit Tests, Änderungsanträgen und anderen relevanten Projektdokumenten.

3. Kommunikation:
– Unterstützung für E-Mail-Benachrichtigungen und Reviews.
– Flexibel konfigurierbare Workflows, um die Anforderungen an die spezifischen Projektbedürfnisse anzupassen.

4. Konfigurations- und Änderungsmanagement:
– Nachverfolgbarkeit aller Änderungen an Anforderungen.
– Unterstützung für Baselines und die Verwaltung von Änderungen durch Änderungsanträge.

5. Sichtenbildung:
– Möglichkeit zur Filterung und Darstellung von Anforderungen für verschiedene Nutzergruppen.
– Unterstützung für kumulierte Ansichten und Suchfunktionen.

6. Import / Export:
– Funktionen zum Import und Export von Anforderungen aus und in andere Tools, z.B. über Word- oder Excel-Dokumente.
– Unterstützung für Roundtrip-Engineering mit Office-Programmen.

7. Reporting:
– Umfangreiche Berichtsoptionen zur Darstellung des Fortschritts bei der Anforderungsdokumentation und -umsetzung.
– Unterstützung für Release- und Iterationsplanung.

8. Administrative Sicht:
– Benutzerverwaltung, z.B. Integration in Active Directory oder LDAP.
– Unterstützung für Datenmigration und einfache Installation sowie Wartung des Tools.

9. Testmanagement Sicht:
– Erstellung und Verwaltung von Testfällen, deren Parametrisierung und Verknüpfung mit Anforderungen.
– Unterstützung für Test-Sets und die Dokumentation von Testversionen.

10. Lizenzmodell & Kosten & Support:
– Bewertung der Kostenstrukturen, einschließlich Lizenzkosten und jährlicher Wartungsgebühren.
– Betrachtung der Verbreitung und des Supports der Tool-Anbieter.

11. Erweiterte Funktionen:
– Unterstützung für Offline-Bearbeitung und Cloud-basierte Nutzung.
– Integration von Glossaren und speziellen Austauschformaten, wie OSLC oder RIF.

Weiteres Vorgehen:

1. Bewertungsmethodik auswählen:
– Eine geeignete Methodik zur Bewertung der Tools festlegen.

2. Kriterien aufstellen und Bewertungsmetrik festlegen:
– Für jedes Kriterium eine Bewertungsmatrix entwickeln und ggf. Demos der Tools durchführen lassen.

3. Objektiv bewerten:
– Eine fundierte und nachvollziehbare Bewertung der Tools durchführen, um die beste Wahl für das spezifische Projekt zu treffen.

Zusammenfassung:

Vor der Auswahl eines Anforderungsmanagement-Tools sollte eine detaillierte Liste von Kriterien erstellt werden. Es ist wichtig, diese Kriterien objektiv zu bewerten und die Auswahlmethodik sorgfältig zu dokumentieren, um eine fundierte und nachvollziehbare Entscheidung treffen zu können. Dies hilft nicht nur bei der aktuellen Tool-Auswahl, sondern kann auch zukünftige Diskussionen und Überprüfungen unterstützen.

 

###############

Meine Mailadresse: feedback@zukunftsarchitekten-podcast.de

Die Bewertungskriterien: Kriterienkatalog in der SE-Online-Bibliothek (Registrierung per Email notwendig)

 

###############

Brauchst Du Unterstützung bei der Erstellung eines Lastenheftes oder hast eine Frage dazu, dann findest Du meine Email in den Shownotes. Klicke darauf oder kopiere sie in Dein Emailprogramm und schicke mir eine Mail und wir sprechen darüber.

Dann kannst Du Dir in meinem Online-Kalender auch gerne direkt einen Termin buchen: https://kalender.bjoernschorre.de

 

###############

P.S.: Mein Buch zum Thema Lastenhefte ist da. Du findest es auf der Verlagsseite von tredition

On Air in dieser Episode

avatar
Björn Schorre

ZA207 - Lastenheft Rütteltest

24.05.2023 17 Minuten



Zusammenfassung

Aus vielerlei Gründen ist es notwendig, ein Lastenheft-Review durchzuführen. Dazu gehört zum Beispiel, dass der Autor die Qualität überprüft haben will, um vor der Weitergabe des Dokuments sicher zu sein. Daneben werden Reviews aber auch zu Zwecken der Qualitätssicherung eingesetzt. Und zu guter Letzt ist es notwendig ein Review durchzuführen, weil es der Prozess so vorsieht.

Je nach Anwendungsfall gibt es verschiedene Methoden und Techniken, die eingesetzt werden können. Welche das sind und was ich Dir mit meinem Lastenheft Rütteltest als Service anbiete, erfährst Du in dieser Podcast-Episode.

Mein Vorgehen zum Lastenheft Rütteltest habe ich hier zusätzlich dokumentiert: https://lastenhefterstellen.de/vorgehen-lhreview/?utm_source=zukunftsarchitekten-podcast.de&utm_medium=podcast&utm_campaign=zap207

 

###############

Meine Mailadresse: feedback@zukunftsarchitekten-podcast.de

 

###############

Du brauchst Hilfe bei der Definition der Anforderungen an Dein Produkt?

Dann kannst Du Dir in meinem Online-Kalender gerne einen Termin buchen: https://kalender.bjoernschorre.de

 

###############

P.S.: Mein Buch zum Thema Lastenhefte ist da. Du findest es auf der Verlagsseite von tredition

 

On Air in dieser Episode

avatar
Björn Schorre

ZA198 - Traceability zwischen Anforderungen, Design und Implementierung - Was ist das beste Vorgehen?

30.08.2022 30 Minuten



Zusammenfassung

Traceability wird immer noch als ein schwer zu implementierendes Puzzelstück im Systems-Engineering angesehen. Außerdem wird es damit immer die Nutzung eines Tools assoziiert. Und der Mythos hat weiter Stilblüten: Denn so soll das Tool dann auch noch am Besten alle Entwicklungsdisziplinen auf einmal vereinbaren können.
Ich gebe in dieser Episode Denkimpulse, wie die Traceability mit wenigen, aber sinnvoll ausgewählten Schritten und Tools aufgebaut werden kann.

Wenn Du Fragen hast oder Anregungen, kannst Du mich gerne über die Emailadresse hoererfrage@zukunftsarchitekten-podcast.de anschreiben.

Hinweise und Links aus der Episode:

Mein Buch ist da: Erfolgreich Lastenhefte schreiben – Eine Schritt-für-Schritt-Anleitung für den Mittelstand

On Air in dieser Episode

avatar
Björn Schorre