Bruecke

Anforderungsmanagement Teil II

 

Muss man Anforderungen in verschiedene Arten unterteilen?

Ja, man muss unterscheidet zwischen den verschiedenen Sichten auf Anforderungen und zwischen Anforderungsarten. Bei den Anforderungssichten unterscheidet man zwischen

  • Marktanforderungen
    • Beschreibt die Anforderungen an ein Produkt aus Sicht des Kunden. Sie beschreiben aus Sicht des Kunden, warum ein Projekt überhaupt durchgeführt wird. Marktanforderungen werden im Lastenheft dokumentiert.
  • Produktanforderungen
    • Produktanforderungen beschreiben Anforderungen an ein Produkt aus Sicht der Lösungsrealisierung. Produktanforderungen beschreiben die Eigenschaften aus Lösungssicht. Sie werden daher häufig auch als Funktionen, Eigenschaften, oder Systemanforderungen bezeichnet. Produktanforderungen werden im Pflichtenheft dokumentiert.
  • Komponentenanforderungen
    • Wie der Name schon erahnen lässt, beschreiben Komponentenanforderungen die Anforderungen an eine Komponente des zu realisierenden Produkts. Sie beschreibt, wie die Produktanforderungen durch eine Komponente des Produktes realisiert wird. Komponentenanforderungen werden häufig auch im Pflichtenheft, oder aber in den Feinspezifikationen, oder Fachkonzepten dokumentiert.

 

Bei der Darstellung der Sichten auf Anforderungen, habe ich bewusst darauf Bezug genommen, wo diese in der Regel zu dokumentieren ist. Ich erlebe in der Praxis immer wieder eine gewisse Unsicherheit was nun in einem Lastenheft- und was nun in einem Pflichtenheft zu dokumentieren ist. Diese Unsicherheit geht soweit, dass ich erlebe, dass Lasten- und Pflichtenheft synonym behandelt werden- und genauso sehen dann die Dokumente aus.

 

Lassen Sie mich an einem kleinen Beispiel verdeutlichen, wie man Lasten- und Pflichtenhefte inhaltlich voneinander differenzieren kann. Ich möchte dazu einen kleinen Ausflug in eine andere Branche machen. Ich nehme an, sie alle haben ein Auto, oder kennen sich zumindest halbwegs damit aus. Angenommen ich möchte mir ein Auto bauen lassen und eine meiner beispielhaft formulierten Anforderungen lautet:

Requirement 001: „Der Fahrer muss während der Fahrt, blendungsfrei, den rückwärtigen Verkehr beobachten können, ohne dass er dafür den Kopf drehen muss.“

Dann könnten die Pflichten dazu wie folgt aussehen:

  • Pflicht 001: Es wird ein Innenspiegel an der Windschutzscheibe montiert, der eine automatische Abblendfunktion hat.
    • Bezug: Requirement 001
  • Pflicht 002: Es wird ein linker Außenspiegel montiert der elektrisch beheizbar und vom Fahrersitz aus fernbedient elektrisch verstellbar ist
    • Bezug: Requirement 001
  • Pflicht 003: Es wird ein rechter Außenspiegel montiert der elektrisch beheizbar und vom Fahrersitz aus fernbedient elektrisch verstellbar ist
    • Bezug: Requirement 001

 

Das ganze würden wir jetzt noch weiter herunterbrechen, indem wir in den Feinspezifikationen des Innenspiegels und der Außenspiegel die technischen Details der Spiegel beschreiben. Also die Servomotoren der elektrischen Spiegelverstellung und die Mechanik. Das Gehäuse und die Art der Spiegel usw.

 

Alle Automobilbauer mögen mir an dieser Stelle hoffentlich meine Laienhafte Darstellung verzeihen, aber ich finde diesen konstruierten Anforderungsbaum sehr leicht verständlich um die Unterschiede zwischen Lastenheft, Pflichtenheft und Feinspezifikationen darzustellen.

 

Aber nun zurück zu den Anforderungsarten. Bei den Arten von Anforderungen unterscheidet man zwischen

  • Funktionalen Anforderungen
      • Funktionale Anforderungen aus Anwendersicht
        • Beispiele dafür sind Benutzeroberfläche, Anwendungsfälle oder Verarbeitungsergebnisse
      • Funktionale Anforderungen aus interner Sicht
        • Beispiele dafür sind Architektur, Anforderungen die wiederverwendete Komponenten stellen, verwendete Datenbanken, verwendete Programmschichten, Betriebssystem oder Verschlüsselungen.
      • Funktionale Anforderungen sind konkrete Funktionen und Ablaufszenarien die beschreiben, wie ein System auf bestimmte Eingangsparameter zu reagieren hat. Dazu zählen auch Geschäftsprozesse, Workflows und Anwendungsfälle (Usecases).

 

  • Qualitätsanforderungen
    • Eine Qualitätsanforderung beschreibt eine qualitative Eigenschaft, die das betrachtete System, oder einzelne Funktionen des Systems aufweisen müssen. Sie werden manchmal auch als „nicht-funktionale Anforderungen“ bezeichnet.
    • Auch bei Qualitätsanforderungen unterscheidet man zwischen
      • Qualitätsanforderungen aus Anwendersicht
        • Beschreibt in der Regel den Zusatznutzen aus Auftraggeber Sicht. Beispiele dafür sind Anforderungen an Informations- und Datensicherheit, Erfüllung von Normen und Standards, oder Benutzbarkeit aus Sicht des späteren Anwenders.
      • Qualitätsanforderungen aus interner Sicht
        • Dies sind Anforderungen, die vor allem aus Entwicklersicht eine Rolle spielen. Dazu gehören beispielsweise konkrete Anforderungen an Architektur oder Stromverbrauch, aber auch Codequalität, Dokumentation und Validierbarkeit.

 

  • Randbedingungen
    • Dabei handelt es sich um organisatorische, oder technische Anforderungen die sich auf die Systemrealisierung auswirken. Sie ergänzen funktionale Anforderungen und Qualitätsanforderung.
    • Beispiele dafür sind zu beachtende Gesetze, Normen, Geschäftsprozesse, Richtlinien usw.

 

Das Problem vieler Anbieter ist, dass viel zu häufig Funktionen und zu wenig Visionen verkauft werden. Steve Jobs war mit Appel an dieser Stelle ganz sicher eine glanzvolle Ausnahme. Als Ingenieure und Techniker sind wir es gewohnt in technischen Problemlösungen zu denken. Wir finden Lösungen und implementieren diese. Allerdings führen diese Lösungen nicht automatisch zum Markterfolg. Das überrascht uns dann, wo diese Lösung doch so viele spannende und interessante Feature hat. Dann muss man sich fragen, ob man die Lösung wirklich am Bedarf ausgerichtet wurde, oder wurden wir da nicht einfach vom „Machbaren“ angespornt- egal ob es jemand braucht?

 

Schaffen wir Visionen einer besseren Zukunft für den Anwender oder erstickt dieser lediglich in Komplexität und Funktionalität?

Ein Projekt ist dann erfolgreich, wenn es den Bedürfnissen seiner Benutzer und seiner Umgebung gerecht wird.

 

Anforderungen formulieren diese Bedürfnisse und das Anforderungsmanagement ist die Disziplin, welche die Behandlung von Anforderungen über den kompletten Projektzyklus hinweg steuert.

 

Zu einer Anforderung gehört allerdings auch immer die Perspektive aus der sie beschrieben wurde dazu. Bei der Formulierung von Anforderungen ist es daher immer ratsam, diese aus dem Kontext heraus auch zu begründen. Nur so ist es bei komplexen Anforderungskatalogen und Projekten die sich über einen längeren Zeithorizont hinweg ziehen möglich, zu verstehen warum diese Anforderung einst so formuliert wurde wie sie ist, was der Anforderer damit bezwecken wollte und welche Auswirkung eine potenzielle Änderung dieser Anforderung auf die ursprüngliche Intension hätte.

 

Aber bei aller Kritik, es gibt auch genügend Projekte die ganz hervorragende Arbeit leisten, hervorragend gemanagte werden und ihre Ziele erreichen. Erfolg ist machbar! Das haben viele Unternehmen erkannt und haben ihre Projektmanagementprozesse optimiert oder ganz neu ausgerichtet. In vielen Unternehmen gab es keinen gelebten Projektmanagementprozess. Doch das Verständnis, was mit exzellentem IT Projektmanagement an Produktivitätssteigerung und Effizienz erreicht werden kann, wird immer größer. Sicherlich leistet dazu auch die Deutsche Gesellschaft für Projektmanagement (GPM) mit ihrem alljährlichen „Deutschen Project Excellence Award“ einen wesentlichen Beitrag. Dieser Preis wird an Unternehmen und deren Projekte vergeben, die sich durch exzellentes Projektmanagement auszeichnen. Ich habe die Ehre für die GPM schon seit einigen Jahren als Projektmanagement Assessor zusammen mit meinen Kollegen die Bewerberprojekte zu auditieren und kann nur bestätigen, dass in Deutschland großartige Projektmanagement Arbeit geleistet wird.

 

Zusammenfassend möchte ich noch einmal auf die Praxistipps aus Christof Eberts Buch „Requirements Engineering“ hinweisen und abschließend zur letzten und zur heutigen Folge wie folgt resümieren:

  • Trennen Sie bei der Anforderungsentwicklung zwischen der internen Sicht und der externen Sicht
  • Anforderungsmanagement ist sowohl bei der Entwicklung neuer Produkte, als auch bei der Änderung bestehender Produkte anzuwenden.
  • Anforderungsmanagement erfolgt bereits vor Projektstart und über den gesamten Projektzeitraum hinweg.
  • Betrachten Sie die drei Typen von Anforderungen nämlich Produktanforderungen, Marktanforderungen und Komponentenanforderungen. Vermischen Sie diese Anforderungen niemals.
  • Vermischen Sie auch niemals das Was und das Wie.
  • Beginnen Sie nicht zu früh mit der Lösung, solange noch nicht klar ist, was die wesentlichen Elemente sind.
  • Modellieren Sie vom Lasten- hin zum Pflichtenheft sowohl die Systemumgebung, als auch die zu entwickelnde Systemarchitektur. Letztere muss ausreichend detailliert sein, bevor man mit den Feinspezifikationen beginnt.
  • Betrachten Sie bei Änderungswünschen immer die Auswirkungen auf Terminplan, Kosten und bereits realisierte Komponenten. Tappen Sie niemals in die Falle, einen Änderungswunsch isoliert von deren Auswirkungen zu betrachten.
  • Berücksichtigen Sie alle Anforderungen. Fragen Sie die relevanten Interessensvertreter, ob etwas übersehen wurde. Machen Sie dabei klar, dass die Ermittlung von Anforderungen noch keine Garantie für deren Lieferung ist. Geliefert wird nur, was vereinbart und bezahlt ist.

 

Soviel für heute zum Thema Anforderungsmanagement. Ich hoffe es hat Ihnen genauso viel Spaß gemacht wie mir und es war das ein- oder andere Neue für sie dabei. Ich freue mich schon auf die nächste Folge und wünsche Ihnen bis dahin lauter grüne Meilensteine. Ihr Andreas Haberer.

 

Podcast abonnieren und bewerten

Um meinen Podcast zu abonnieren und zukünftig keine Folge mehr zu verpassen, klicken Sie auf die folgenden Links:

 

Hier klicken, um den Podcast über iTunes zu abonnieren.

Hier klicken, um den Podcast für RSS Feed zu abonnieren.

 

Wie hat Ihnen diese Folge gefallen? Ich freue mich über ehrliches Feedback und konstruktive Anregungen. Hinterlassen Sie mir doch bitte einen Kommentar auf unserer Homepage www.Bundesvereinigung-ITPM.net- Ich würde mich auch sehr freuen, wenn Sie den Podcast in iTunes bewerten. Das hilft mir den Podcast bekannter zu machen.