Anforderungen an Softwareprodukte klar definieren Requirements Engineering für Projektleiter

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 abzuleiten. Wie Sie dazu vorgehen, erklären Bettina Zastrow und Elisabeth Wagner in diesem dritten und abschließenden Teil der Artikelfolge.

Download ZIPDownload ZIP
Download PDFDownload PDF

Anforderungen an Softwareprodukte klar definieren Requirements Engineering für Projektleiter

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 abzuleiten. Wie Sie dazu vorgehen, erklären Bettina Zastrow und Elisabeth Wagner in diesem dritten und abschließenden Teil der Artikelfolge.

Wir empfehlen zum Thema Anforderung
<1 Tag
28.03.2024
395,-
KI im Projektmanagement: Revolutionieren Sie Ihre Arbeitsweise

In diesem Seminar vermitteln wir Ihnen, wie KI Ihr Projektmanagement-Vorgehen grundlegend verändern kann. Sie bekommen einen Einblick in die unterschiedlichen Methoden der KI und wie Sie KI-Tools zur Datenanalyse, Risikoeinschätzung sowie Entscheidungsfindung in Ihre Projekte integrieren können. Der Kurs vermittelt tiefgreifende Kenntnisse in der Anwendung von KI zur Steigerung von Effizienz und Effektivität und befähigt die Teilnehmenden, KI-basierte Lösungen in ihre eigenen Projekte einzubinden. Mehr Infos

Die Formulierung realistischer, eindeutiger und vollständiger Anforderungen hilft dem Projektleiter, der eine Software in Auftrag gibt, tatsächlich das System zu bekommen, das er will. Der erste Teil dieser Serie zeigt, wie die Software und die Rahmenbedingungen aus der Perspektive der Nutzer definiert werden. Der zweite Teil beschreibt die Formulierung der Use Cases: Was will welcher Akteur mit dem System tun? In diesem dritten und letzten Teil der Artikelfolge geht es darum, das Ziel der Softwareentwicklung aus Sicht der Entwickler zu beschreiben.

Sind die Use Cases fertig modelliert und zu Features zusammengefasst, lassen sich daraus die Anforderungen ableiten. Jedem Use Case werden dabei üblicherweise eine oder mehrere Anforderungen zugeordnet.

Mit Anforderungen sind hier standardisierte Sätze gemeint, die Ansprüche und Wünsche der Benutzer an die Funktionalitäten einer Software beschreiben. Auch Schnittstellen zu angrenzenden Systemen und eigenständige Systemprozesse sind zu berücksichtigen. Darüber hinaus können Vorgaben von außen existieren, z.B. aus firmeninternen Regelwerken, die ebenfalls als Anforderungen formuliert werden.

Definition: funktionale und nichtfunktionale Anforderungen

Ein Use Case beschreibt Funktionen, die ein Akteur mithilfe des Systems ausführen möchte. Daraus abgeleitete Anforderungen werden als "funktionale Anforderungen" bezeichnet. Sie beschreiben jeweils einen der folgenden drei Fälle:

  • eine Interaktion zwischen dem Benutzer und dem System,
  • eine Interaktion zwischen dem System und einem anderen System oder
  • eine selbstständige Systemaktion aufgrund eines zeitlichen oder ereignisgesteuerten Auslösers.

Darüber hinaus ergeben sich weitere Anforderungen, z.B. rechtlicher, kultureller, sicherheitstechnischer Art, usw., die für die Anwendungsentwicklung bekannt sein müssen. Diese Anforderungen außerhalb der Use Cases werden als "nichtfunktional" bezeichnet (siehe Abschnitt "Nichtfunktionale Anforderungen berücksichtigen").

Funktionale Anforderungen ermitteln

Wünsche und Vorgaben der Stakeholder lassen sich am besten in Einzelinterviews ermitteln. Als Diskussionsgrundlage kann eine Liste der Use Cases dienen. Projektleiter und Stakeholder nehmen dabei die gleiche Perspektive auf das System ein und erarbeiten gemeinsam die Anforderungen aus der Nutzerperspektive, z.B. indem sie die Workflows zu den jeweiligen Use Cases durchgehen: Was sind z.B. für den Use Case "Nutzer registriert sich am System" die Voraussetzungen, was passiert im Hintergrund und was ist das Ergebnis?

Die Schwierigkeit ist hier häufig, exotische Anforderungen einzudämmen und die maßgeblichen Aspekte im Auge zu behalten, wie z.B. bei obigem Beispiel "Systemregistrierung" die Regeln für die Kennwortsicherheit.

Das Arbeitsergebnis ist eine Liste von Anforderungen aus dieser Nutzerrolle. Soweit möglich, sind die Anforderungen direkt im Format der SOPHIST® Satzschablone zu erfassen (siehe Abschnitt "Qualitätskriterien"). Anderenfalls reichen auch komplette Sätze aus, welche die Rolle, die Aktion und ggf. die Bedingung für die Ausführung beschreiben. Das Augenmerk ist dabei auf die vollständige Erfassung aller Anforderungen zu richten, die sich aus dem jeweiligen Use Case ergeben. Geschulte SW-Entwickler können hier gut unterstützen. Prüfung, Konsolidierung und Ergänzungen erfolgen in einem späteren Schritt.

Um die Nachvollziehbarkeit zu gewährleisten, ist es ratsam, jede Anforderung bei der Erfassung mit einer Quellenangabe zu versehen. Dies ist auch später nützlich bei der Vergabe von Prioritäten.

Ein typischer Stolperstein ist die Schwierigkeit, Anforderungen am Rande des Spektrums zu erkennen und einzubeziehen. Am unteren Ende sind dies die banal erscheinenden Anforderungen, wie z.B. die Druckfunktion oder die Onlinehilfe, die so selbstverständlich sind, dass vergessen wird, sie explizit zu erwähnen. Am oberen Ende steht die Bedienbarkeit, auch als "Usability" bezeichnet. Zur Usability gehört es, die Benutzeroberfläche nach den Gesetzen der visuellen Wahrnehmung aufzubauen und effiziente Funktionen zu gestalten, die mit wenigen Schritten ausführbar sind.

Requirements Engineering für Projektleiter


Gleich kostenlos weiterlesen!

  • Zum Newsletter anmelden und diesen Artikel freischalten

  • Jede Woche neue Inhalte, Tipps und Tools per E-Mail
Gratis Newsletter bestellen & sofort weiterlesen

 

Hiermit melde ich mich zum Newsletter an. Ich habe die Datenschutzrichtlinien gelesen und akzeptiere diese. Ihre Daten nutzen wir ausschließlich zum Newsletter-Versand. Sie können sich jederzeit abmelden, indem Sie auf den Link in der Fußzeile unserer E-Mails klicken. Informationen zu unserem Datenschutz finden Sie hier.

Fortsetzungen des Fachartikels

Teil 1:
Leistungsumfang und Rahmenbedingungen festlegen

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 …

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.

Alle Kommentare (1)

Guest

Ich möchte mich bei den Autorinnen ganz herzlich für die klare, strukturierte Beeschreibung der Vorgehensweise zum Requirements Engineering (RE) bedanken. Dies ist ein sehr wertvoller Beitrag für mich als Projektleiter, da meine Auftraggeber (intern und extern) meist nicht in der Lage sind Anforderungen und das daraus zu schaffende Produkt konsistent und vollständig zu formulieren. Häufig ist auch gar nicht bekannt, dass es für RE eine anwendbare Methodik gibt. Wenn ich als Projektleiter das mache dann habe ich auch noch den Riesenvorteil, dass ich über das Produkt, das da entstehen soll sehr gut Bescheid weiss und mir keiner was vormachen kann. Wenn es schwierig wird bei den Entwicklern dann wird auch gerne mal was unterschlagen. Also nochmal Danke dafür.