Anforderungen an Softwareprodukte klar definieren Requirements Engineering für Projektleiter

Teil 1:
Leistungsumfang und Rahmenbedingungen festlegen
Requirements Engineering für Projektleiter

Viele Projektleiter müssen im Rahmen Ihrer Tätigkeit Software beauftragen – z.B. weil diese Bestandteil einer Prozessoptimierung ist. Ob die Software am Ende ihren Zweck erfüllt, hängt davon ab, wie gut der Projektleiter Vorgaben in die "IT-Sprache" der Entwickler übersetzt. Fehlt die nötige Erfahrung, sollte er sich mit den grundlegenden Regeln des Requirements Engineerings auseinandersetzen. Bettina Zastrow und Elisabeth Wagner beschreiben, wie auch Projektleiter ohne tief gehende IT-Kenntnisse Schritt für Schritt zu einem guten Ergebnis kommen – und so kostspielige Umwege und Change Requests vermeiden.

Management Summary

Download PDFDownload PDF
Download EPUBDownload EPUB

Anforderungen an Softwareprodukte klar definieren Requirements Engineering für Projektleiter

Teil 1:
Leistungsumfang und Rahmenbedingungen festlegen
Requirements Engineering für Projektleiter

Viele Projektleiter müssen im Rahmen Ihrer Tätigkeit Software beauftragen – z.B. weil diese Bestandteil einer Prozessoptimierung ist. Ob die Software am Ende ihren Zweck erfüllt, hängt davon ab, wie gut der Projektleiter Vorgaben in die "IT-Sprache" der Entwickler übersetzt. Fehlt die nötige Erfahrung, sollte er sich mit den grundlegenden Regeln des Requirements Engineerings auseinandersetzen. Bettina Zastrow und Elisabeth Wagner beschreiben, wie auch Projektleiter ohne tief gehende IT-Kenntnisse Schritt für Schritt zu einem guten Ergebnis kommen – und so kostspielige Umwege und Change Requests vermeiden.

Management Summary

Viele Projektleiter sind für die Beauftragung von Software verantwortlich. Das gilt keineswegs nur für reine Softwareprojekte, sondern auch für Organisationsprojekte, die auf Prozessentwicklung oder -optimierung abzielen und dabei eben auch die Entwicklung und Einführung einer neuen Software zum Gegenstand haben. Ob am Ende tatsächlich die Software herauskommt, die benötigt wird, und zwar ohne kostspielige Umwege und Change Requests, hängt entscheidend davon ab, ob es dem Projektleiter gelingt, realistische, eindeutige und vollständige Anforderungen zu formulieren.

Unabhängig davon, ob die Software intern oder extern entwickelt wird – der Projektleiter nimmt hier die oft ungewohnte Rolle des Auftraggebers wahr. Selbst wenn er über tiefes fachspezifisches Know-how verfügt und eine genaue Vorstellung hat, wie die Software aussehen soll, fehlt oft die Erfahrung, wie die Vorgaben in die "IT-Sprache" der Entwickler zu übersetzen sind. Dann ist es sinnvoll, sich mit den grundlegenden Regeln eines professionellen Requirements Engineering auseinanderzusetzen, um realistische, eindeutige und vollständige Anforderungen zu erstellen.

Bettina Zastrow und Elisabeth Wagner stellen in diesem dreiteiligen Beitrag die wesentlichen Elemente eines professionellen Requirements Engineerings vor und beschreiben, wie auch Projektleiter ohne tief gehende IT-Kenntnisse Schritt für Schritt zu einem guten Ergebnis kommen. Ein durchgängiges Beispiel erläutert die verschiedenen Schritte und gibt einen Überblick über die strukturellen Inhalte, die im Rahmen einer Softwareentwicklung zu definieren sind.

Dieser erste Teil zeigt, wie Sie eine eindeutige und vollständige Definition des Systems erstellen, indem Sie die Merkmale des Produkts und dessen Systemumgebung festlegen. Dazu gehören z.B. der fachliche Inhalt, der Systemkontext und die Stakeholder.

Ausgehend von diesen Vorgaben können Sie die Definition, wie im zweiten und dritten Teil beschrieben, immer weiter verfeinern, indem Sie das System aus der Nutzerperspektive beschreiben und das Ergebnis in "Use Cases" (Anwendungsfälle) und schließlich in Anforderungen "übersetzen", die für SW-Entwickler gut verständlich sind.

Ziel: Das angestrebte System definieren

Bevor das Projekt oder Teilprojekt „Softwareentwicklung“ starten kann, gilt es, das angestrebte Ergebnis grundlegend zu definieren, also eine "Systemdefinition" zu erstellen. Sie legt fest, was das Produkt können soll, wer damit arbeitet, wofür es eingesetzt werden soll, welche Einflussfaktoren berücksichtigt werden müssen und welche Personen an der Systemdefinition beteiligt sind. Der Begriff "System" bezeichnet hier das zu entwickelnde Gesamtsystem, das Hardware-, Software- und Infrastrukturkomponenten enthalten kann.

Die Systemdefinition umfasst folgende Dokumente:

  • Produktdefinition
  • Leistungsumfang
  • Systemkontext, bestehend aus Einflussfaktoren und Rahmenbedingungen
  • Stakeholderliste
  • Begleitdokumente

Der Einfachheit halber werden die Begriffe "Software" und "System" hier synonym verwendet.

Die Produktdefinition erarbeiten

Zweck der Produktdefinition ist, Klarheit über das Ergebnis der Produktentwicklung zu erhalten. Eine Produktdefinition beantwortet die Fragen: "Wofür dient diese Software?" und "Warum soll diese Software realisiert werden?" Damit eignet sie sich sehr gut als Kurzdefinition, um andere Beteiligte über das Vorhaben zu informieren.

Die Produktdefinition ist der erste Schritt zur Gestaltung eines neuen Systems. Da das Produkt zu diesem frühen Zeitpunkt noch im Ideenstadium ist, ist es notwendig, die Idee zu konkretisieren und festzulegen, was die zu entwickelnde Software können soll und was der Auftraggeber damit erreichen möchte. Natürlich kann die Idee auch als Vorgabe von einer Fachabteilung, der Bereichsleitung oder der Geschäftsführung kommen – an der prinzipiellen Vorgehensweise ändert sich dadurch nichts. Im Folgenden wird davon ausgegangen, dass der Produktmanager als interner Auftraggeber die Software in Auftrag gibt.

Fortsetzungen des Fachartikels

Teil 2:
Mit Use Cases den Funktionsumfang beschreiben
Mit der in Teil 1 erstellten Systemdefinition sind die Merkmale der neuen Software festgelegt. Um konkrete Anforderungen für die Entwickler abzuleiten, muss diese allerdings noch verfeinert werden.
Teil 3:
Anforderungen für die Software-Entwicklung ableiten

Die Merkmale der neuen Software sind festgelegt, der Funktionsumfang ist in Form von Use Cases modelliert. Als nächstes geht es darum, die Use Cases weiter zu detaillieren und daraus klare, für die Entwickler verständliche Anforderungen …

Alle Kommentare (5)

Guest

Ich stimme zu, dass professionelles Requirement Management ein wichtiger Erfolgsfaktor ist. Was mich jedoch irritiert, ist das Rollenverständnis. Ist tatsächlich der Projektleiter verantwortlich, den Nutzen und die Notwendigkeit eines Projektgegenstandes zu bewerten, dessen Umfang festzulegen und eine Risikoabschätzung zu treffen, wenn man es nicht umsetzt? Sind das nicht klassische Aufgaben des Auftraggebers? Ich würde Requirement Management deshalb eher auf Seiten des Auftraggebers sehen: Der Auftraggeber muss sich Klarheit verschaffen, was er möchte und wozu. Nicht selten treffe ich auf Situationen, in denen eine vage Idee an einen Projektleiter übergeben wird als Projektauftrag. Ich kenne sogar Fälle, in denen der Projektleiter sowohl das Lastenheft als auch gleich das Pflichtenheft schreibt. Ich bin mir im Klaren, dass eine Geschäftsleitung in vielen Fällen nur eine Idee oder Vision in die Organisation tragen. Vielleicht müssten wir deshalb unterscheiden zwischen Ideen und Aufträgen. Vielleicht müsste der Ideengeber oder Sponsor einen Auftraggeber nominieren, der die Interessen des Ideengebers bis in Detailfragen gegenüber dem Projekt vertritt. Dann hätten wir eine Kunden-Dienstleister-Beziehung mit einer klaren Abtrennung von Interessen. Dann werden Projekte wegen der Interessentrennung vielleicht nicht mehr zum Selbstzweck durchgeführt.

 

Gabriela
Will

Professionelles Requirement Engingeering (RE) erscheint mir sehr wichtig für den Erfolg eines Projektes. Jedoch ist die Durchführung von RE nicht automatisch die Aufgabe eines Projektleiters. Hierfür gibt es Rollen wie z.B. den Requirement Engineer oder den Business Analysten. Gleichwohl sollte der Projektleiter die Arbeitsschritte von RE hinreichend kennen, damit entsprechende Arbeitspakete im Projektplan vorgesehen werden.

 

Bettina
Zastrow

Die Definition des gewünschten Systems obliegt dem Auftraggeber. Hier liegen verallgemeinernd drei mögliche Konstellationen vor: Systementwicklung im Auftrag, Systementwicklung für den freien Markt, Systementwicklung zur Nutzung im eigenen Unternehmen. Im ersten Fall sind zwei verschiedene Firmen involviert, es gibt beim Auftraggeber und beim Auftragnehmer einen Projektleiter. Im zweiten Fall ist der Kunde intern und es gibt in der Regel einen Produktmanager auf der Auftraggeberseite und einen Projektleiter auf der Auftragnehmerseite. Im dritten Fall ist der Auftraggeber ebenfalls intern und es gibt einen Projektverantwortlichen auf Auftraggeberseite und einen Projektleiter auf Auftragnehmerseite. Im ersten und dritten Fall ist auf der Auftraggeberseite meist wenig Erfahrung vorhanden, wie Anforderungen korrekt, verständlich und umsetzbar definiert werden können, so dass einerseits "Selbstverständlichkeiten" mit aufgenommen werden, aber andererseits keine technischen Einschränkungen für die Realisierung vorgegeben werden.
Hierfür ist die strukturierte Vorgehensweise im Requirements Engineering eine sehr gut geeignete Methode. Nicht nur der Projektleiter auf Auftraggeberseite profitiert davon. Auch der Projektleiter auf Auftragnehmerseite, sei es intern oder extern, kann seinen Kunden dabei unterstützen, klare und gut verständliche Anforderungen zu erarbeiten. Der Ankauf von Leistungen eines Requirements Engineers kann auch eine Budgetfrage sein, gerade bei kleinen Firmen, insofern ist der Auftraggeber in jedem Fall gut beraten, sich mit der Thematik Requirements Engineering auseinanderzusetzen. Dies gilt um so mehr, wenn es (noch) keine Vertragssituation gibt, sondern die Leistung ausgeschrieben wird.

 

Gerrit
Weber

Als Nicht-ITler und Projektleiter bin ich auf der Suche nach zertifizierten Fortbildungsmaßnahmen um die "IT-Sprache" besser sprechen zu können. Können Sie mir hierbei weiterhelfen?

 

Hartmut
Goetze

Die Beispiele verdeutlichen die Konzepte sehr gut.