Requirementsmanagement

Heute geht es mir um das Requirements Management, da ich gesehen habe, dass dieses Thema viele Leser interessiert. Zunächst befasse ich mich kurz mit der Frage, was Requirements sind, wie man sie formuliert, und wie man den Requirementsprozess verbessert. Dann werde ich einige Tools einführen, die Unterstützung für den Requirementsprozess bieten.

Requirements

Wie es Wikipedia ausdrückt, versteht man in der Informatik unter dem Begriff der Anforderung, eine Aussage über die zu erfüllende Leistung oder Funktion eines Softwaresystems (siehe Wikipedia → Anforderung (Informatik)). Es gibt mehrere Arten von Anforderungen, wie zum Beispiel die Kann- und die Mußanforderungen (im erstgenannten Fall sollte die Software ein bestimmtes Feature bieten, während es essentiell ist, daß es die Mußanforderungen abdeckt).

Weiterhin lassen sich funktionale Anforderungen von den nicht-funktionalen Anforderungen unterscheiden, wie die folgenden Beispiel zeigen:

• Der Report muss die gespeicherten Datensätze in Form einer Tabelle und einer Grafik ausgeben (Funktional)
• Die Antwortzeit sollte unter 1 Sekunde liegen (Nicht Funktional)

Anforderungen definieren sehr entscheidende Dinge, wie zum Beispiel die Kosten einer Software und deren Leistungsfähigkeit aus Kundensicht. In der betrieblichen Praxis ist es daher wichtig, daß Anforderungen bestimmten Ansprüchen genügen. So sollte sich eine Anforderung auf ein gegebenes (Geschäfts-)problem beziehen, und einen möglichst detaillierten betriebswirtschaftlichen Lösungsweg angeben. Weiterhin sollte eine Anforderung ein konkretes Abnahmekriterium enthalten, das angibt, ab wann eine Anforderung als so implementiert anzusehen ist, dass die die Erwartungen erfüllt.

Gut formulierte Anforderungen genügen daher den folgenden Kriterien:

• Korrektheit (technisch, rechtlich, ethisch,.. möglich und umsetzbar)
• Komplettheit, d.h lückenlos formuliert
• Klarheit (einfach und verständlich, sowie widerspruchsfrei)
• Konsistent (ohne Konflikte zu anderen Anforderungen)
• Nachprüfbar (Messkriterien vorhanden, anhand derer die Systemleistung geprüft werden kann)
• Nachvollziehbar (Verstehbar/ Anforderungsquelle ist definiert)
• Realistisch (und umsetzbar)
• Abgeschlossenheit (Abgegrenzt, und ohne Einfluss auf andere Anforderungen)
• Unabhängigkeit von der Architektur

Letztendlich bilden Anforderungen die Kundenwünsche möglichst präzise ab, d.h sie erfassen die Erwartungen, die Kunden an eine Software stellen. Es ist daher entscheidend, wie man zu den notwendigen Kundeninformationen gelangt, und wie transparent man diese Anforderungen in Endprodukt abbilden kann. Dies ist eine wichtige Aufgabe des Produktmanagements.

Um den Anforderungsprozess möglichst effizient zu gestalten, sollte man als Produktmanager den Prozess in zwei Richtungen professionell gestalten:

• Rollin (d.h die Aufnahme von Kundenwünschen und -problemen)
• Rollout (d.h die Formulierung inclusive der Priorisierung und der Einlastung der Entwicklungen in das Entwicklerteam)

In der folgenden Beschreibung der Firma IBM finden Sie hierzu einige weitere Informationen → Ten steps to better requirements management (IBM)

Tools

Verschiedene Tools helfen im weitesten Sinne beim Requirements Management:

• IBM → Rational DOORS Tool
• Atlassian → JIRA – Issue and Project Tracking
• Ravenflow → Visual Requirements Engineering
• Micro Focus → Caliber – Requirements Definition and Management

Ich persönlich kenne das JIRA Tool, das insbesondere die Agile Softwareentwicklung (siehe → hier) unterstützt. Daneben bietet das Tool auch Funktionen für verwandte Themen, wie für das Bug Tracking (d.h. Nachverfolgung von Fehlern), die Projektverwaltung oder die kollaborative Entwicklung von Software.

In einem der nächsten Artikel werde ich mich genauer mit den Features dieser Tools befassen.

Weitere Informationen

Weitere Informationen zum Thema finden Sie in folgenden Beiträgen

• → Anforderungen müssen konkret formuliert werden
• → Markets or Communities? The Best Ways to Manage Outside Innovation
• → Bewertung von Produktideen
• → Concept Prototyping (Teil 2) Konzepterstellung und -bewertung
• → Concept Prototyping

Hey! Sie haben den Artikel ganz bis zum Ende gelesen. Sie sollten meinen Blog abonnieren! Tragen Sie sich → hier in den Mailverteiler ein, oder bookmarken Sie diesen Artikel über die unten angegebenen Links.

Tags: Agile Development, Anforderungen, PM Role, Product-Concept | Comments Off