Schlagwortarchiv für: Requirementmanagement

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.

Schlagwortarchiv für: Requirementmanagement

ZA054 - Dann kann ich auch Zeitungsartikel in DOORS stopfen

25.06.2013 00:00:00.000 Stunden 00:00:00.000 Minuten



On Air in dieser Episode

Zusammenfassung

Diese Aussage habe ich vor ein paar Wochen in einem Streitgespräch zwischen einer Requirements-Ingenieurin und einem Software-Ingenieur gehört und zum Anlass genommen, eine Episode zu gestalten zu der Frage: Warum werden Spezifikationen erstellt und nie gelesen? Ich werde meine Gedanken dazu im Rahmen dieser Episode mit Euch teilen und ein paar Tipps und Tricks geben.

Der Inhalt dieser Episode:

  1. Warum schaffen wir eigentlich Ergebnisse wie Lastenhefte, Systemanforderungen oder Systemarchitekturen?
  2. Die Sicht der System- oder Requirements-Ingenieure und was wir besser machen können.
  3. Die Sicht der Entwickler (Konstruktion, Hardware, Software) und was wir besser machen können
  4. Was sind die typischen Situationen? Was ist die Ursache? Welche Tipps und Tricks gibt es?

Themen:  Der Prozess gibt es uns vor, Es geht um das Verstehen, Es geht um Kommunikation, Die Spezifikationen sind wichtig, aber nicht das, was später der Kunde in seinem Alltag nutzt, Keine Zeit, Keine Lust, Kein Verständnis, Mit Respekt kommunizieren, Reviews nutzen, Das Handeln des Managements

Hinweise auf andere Episoden:

Aus der Praxis eines Troubleshooters:

Subscription link

Wenn Euch der Podcast gefällt, abonniert Ihn und erhaltet zukünftig kostenlos alle neuen Episoden direkt auf Eurer Smartphone:

iTunes | Zune | RSS

Euer Feedback

Wenn Ihr eine Idee habt für den Podcast oder eine Frage für eine der zukünftigen Episoden, schreibt mir eine Mail an feedback@zukunftsarchitekten-podcast.de

Wenn Euch die Episode gefallen hat, bitte bewertet sie bei iTunes und schreibt eine ehrliche Meinung. Das würde sehr helfen, die Commuity zu erweitern! Danke.

ZA052 - Wie kann ich mein Anforderungsmanagement neu ausrichten?

28.05.2013 00:00:00.000 Stunden 00:00:00.000 Minuten



On Air in dieser Episode

Zusammenfassung

Ich habe eine Hörerfrage von Martin Bruntsch erhalten. Er hat die Situation, dass er in einem bestehenden, langfristigen Entwicklungsprojekt das Anforderungsmanagement neu ausrichten muss. Er schaut sich gerade Polarion an und hat dazu ebenfalls Fragen.

Im Fokus steht das Bewerten von Lastenheften, das Erstellen von Pflichtenheften sowie das kontinuierliche Spezifizieren von Change-Requests in langfristigen Softwareentwicklungsprojekten (10-30 Mitarbeiter über eine Laufzeit von 10 Jahre).

Der Inhalt dieser Episode:

  1. Umgang mit vielen Anforderungen über eine lange Zeit
  2. Eine gute Strukturierung von Dokumenten bzw. Spezifikationen
  3. Der Einsatz von Requirementsmanagement Tools

Themen:  Doors, Polarion,Lastenhefte mit 40.000 Anforderungen, Anforderungsgrammatik, Stories und Epics, Meta-Ebene, Releases und Baselines, Einsatz von Scripten, Tracebility, Aufräumen, Festlegung von Begrifflichkeiften, Abbildung der verschiedenen Ebenen und Sichten, Detaillierung auf der richtigen Ebene halten, Attribute nutzen.

Hinweise auf andere Episoden:

Aus der Praxis eines Troubleshooters:

Subscription link

Wenn Euch der Podcast gefällt, abonniert Ihn und erhaltet zukünftig kostenlos alle neuen Episoden direkt auf Eurer Smartphone:

iTunes | Zune | RSS

Euer Feedback

Wenn Ihr eine Idee habt für den Podcast oder eine Frage für eine der zukünftigen Episoden, schreibt mir eine Mail an feedback@zukunftsarchitekten-podcast.de

Wenn Euch die Episode gefallen hat, bitte bewertet sie bei iTunes und schreibt eine ehrliche Meinung. Das würde sehr helfen, die Commuity zu erweitern! Danke.