Der Weg zu qualitativ hochwertiger und kostengünstiger Software
Requirements – wie baue ich das richtige Produkt?
von Ralf Demmer
Fachliche Requirements als Ausdruck der funktionalen und nichtfunktionalen Erfordernisse an eine zu erstellende Software bilden naturgemäß die Basis, auf der der gesamte Softwareentwicklungsprozess aufsetzt. Zum Erstellen einer im Sinne des Auftraggebers guten Software ergeben sich aufgrund der Vielzahl der am Softwareentwicklungsprozess beteiligten Rollen und Personen hohe Ansprüche an die strukturelle und inhaltliche Qualität der Requirements. Dieser Artikel beschäftigt sich mit den Unzulänglichkeiten, die im Softwareentwicklungsprozess häufig auftreten und ihre Ursache in unzureichenden Requirements haben. Zudem werden Qualitätsmerkmale beschrieben, deren konsequente Berücksichtigung ein gutes Gesamtergebnis erreichen lässt.
DIE REALITÄT: ENTWICKLUNGSSCHNELLIGKEIT VS. FEHLERKOSTEN
Die Erfahrung aus der Praxis zeigt, dass anfordernde Stellen einen frei formulierten Text entwerfen und darauf basierend – oftmals auch ohne Anforderungsreview – das Umsetzen der Anforderung erfolgt. Dieses gerne mit dem Schlagwort „schlank“ versehene Verhalten wird zumeist gerechtfertigt mit dem Hin-weis auf den bestehenden Zwang, Software zeitnah liefern zu müssen oder zu wollen. Abhängig von Umfang und Qualität der vorgesehenen Testaktivitäten wird dann nur mit viel Glück ein hinreichender Prozentsatz der bestehenden Mängel aufgedeckt. In der Regel wird das jedoch nicht der Fall sein. Die Folge ist eine fehlerhafte produktive Software. Das Problemdabei: Fehlerbehebung wird teurer, je später Fehler entdeckt werden. Darum lohnt sich eine frühzeitige Qualitätssicherung, da die durch fehlerhafte produktive Software entstehenden Kosten um einiges höher sind als die auf den ersten Blick reizvollen Ein-Mit zunehmender Reife des Produkts wird das Beheben der Fehler immer komplexer und damit exponentiell immer teurer. Die Gründe für das Ansteigen der Fehler- bzw. Fehlerbehebungskosten werden deutlich, wenn wir uns vor Augen führen, dass jeder vorhergehende Prozessschritt zur Fehlerbehebung mindestens einmal erneut durchlaufen werden muss. Als besonders dramatischer Kostentreiber gelten die im Produktionsbetrieb gefundenen Fehlerzustände. Neben den Fehlerbehebungskosten treten hier zusätzlich unmittelbare finanzielle Schäden durch Fehler im vom Kunden verwendeten Produkt und damit regelmäßig auch Reputationsschäden auf. Ziel muss es also sein, möglichst früh im Softwareentwicklungsprozess eine hohe Qualität der produzierten Artefakte sicherzustellen. Damit fällt der optimalen Qualität der Requirements eine besonders relevante Rolle zu.
QUALITY-GATES IM SOFTWAREENTWICKLUNGSPROZESS
Ein optimaler Software-Entwicklungsprozess betrachtet vom ersten bis zum letzten Prozessschritt die Qualität sämtlicher erstellter Artefakte an vereinbarten Prüfpunkten (Quality- Gates). Ungeachtet der gewählten Softwareentwicklungsmethode ergeben sich vier sinnvolle Quality-Gates. Kommunikationswege und Eskalationsmechanismen müssen für jede beteiligte Rolle an jeder Stelle des Prozesses definiert und bekannt sein. Ganz wichtig dabei: Eine Eskalation muss jedem am Projekt Beteiligten ausdrücklich zugestanden werden. Unerlässlich ist es, die beteiligten Rollen mit den passenden Personen zu besetzen. Auch muss die zur Verfügung stehende Zeit ausreichen, das Endergebnis „in time“ erreichen zu können. Die Summe aller Unzulänglichkeiten, die in den Requirements vorhanden sind, werden zusammen mit daraus in den Prozessfolgeschritten resultierenden Fehlern zu Fehlern in der produktiven Anwendung. Es zeigt sich erneut: Je früher im Softwareentwicklungsprozess mit einer Qualitätssicherung begonnen wird, desto besser. Besonders wichtig ist damit der erste Prozessschritt, also das Erstellen der Requirements. Das für Requirements definierte Quality-Gate Q1 sollte nicht passiert werden dürfen, bevor nicht die geforderten Qualitätsmerkmale nachweislich erfüllt sind.
WAS ZEICHNET EIN HOCHWERTIGES REQUIREMENT AUS?
Die Inhalte aller Requirements müssen sich an den Interessen aller am Softwareentwicklungsprozess beteiligten Rollen orientieren. Darum ist ein hochwertiger konzeptioneller Bezugsrahmen notwendig, der in einem gemeinsamen Workshop zu entwickeln ist. Die Verantwortung dafür liegt üblicherweise beim Qualitätsmanagement. Der formale Rahmen wird gesetzt durch das Erfüllen folgender Qualitätsmerkmale:
Ein inhaltlicher Rahmen für Requirements ist definiert.
Der Aufbau der Requirements folgt einer inhaltlichen Struktur, die als erstes festzulegen ist. Sie gibt die zu hinterlegenden Inhalte und dieArt ihrer Verwendung vor (beispielsweise durch Definition zulässiger Einträge).
Akzeptanzkriterien sind definiert.
Das Erstellen eindeutiger Akzeptanzkriterien bewegt den Ersteller des Requirements dazu, sich erneut mit den Inhalten des Requirements zu beschäftigen. Bei diesem Review fallen regelmäßig vorhandene Unzulänglichkeiten in der Formulierung des Requirements auf. Die Akzeptanzkriterien spiegeln wider, was genau geliefert werden muss, damit das Requirement als erfüllt angesehen wird. Sie müssen daher vollständig und in sich schlüssig sein. Besonderes Augenmerk ist auf unmissverständliche Formulierungen zu legen. Als sehr hilfreich hat es sich in der Praxis erwiesen, die Akzeptanzkriterien einem Review mindestens durch das Testmanagement zu unterziehen.
Querverweise auf andere relevante Requirements (falls vorhanden) sind gesetzt.
Hinweise auf evtl. vorhandene Requirements mit Einfluss auf das Requirement helfen allen Beteiligten, den Gesamtkontext, in dem sich das Requirement bewegt, besser zu verstehen.
Die gewählten Formulierungen sind eindeutig und abschließend.
Formulierungen mit Interpretationsspielraum führen dazu, dass eigenständige Deutungen, dessen was gemeint sein könnte, vorgenommen werden. Deshalb sind eindeutige Formulierungen von Anfang an ein Muss. Die Formulierungen dürfen keine „losen Enden“ hinterlassen. Das Verwenden von Formulierungen wie „usw.“, „z. B.“ oder „…“ führen zwangsläufig zu Unsicherheiten im weiteren Softwareentwicklungsprozess. Alle am Softwareentwicklungsprozess beteiligten Rollen sind frühzeitig involviert. Bevor das Requirement das Quality Gates 1 passiert, sollten alle am Entwicklungsprozess beteiligten Rollen die Möglichkeit haben, Verständnisfragen zu stellen und rollenspezifische Unklarheiten auszuräumen.
Die nichtfunktionalen Anforderungen sind definiert.
Unter nichtfunktionalen Anforderungen werden solche Teile des Requirements verstanden, die beschreiben, in welchem Maße das System die geforderte Leistung erbringen soll. Hier werden beispielsweise Angaben zu geforderten Antwortzeiten oder zum Layout der Benutzeroberfläche gemacht. Werden keine nichtfunktionalen Anforderungen gestellt, dürfen die weiteren am Umsetzungsprozess Beteiligten davon ausgehen, dass die Art und Weise der Umsetzung ihrem Ermessen überlassen ist.
Es existiert eine inhaltliche Abgrenzung des Requirements.
Die Beschreibung, was das Requirement nicht bezweckt, schärft das Verständnis für das, was bezweckt wird. Diese auch als „in scope“/“out of scope“ bezeichnete Unterscheidung hilft den Entwicklern, ihre Aktivitäten auf das Umzusetzende zu konzentrieren. X Der Zeitansatz muss ausreichend sein. Werden Requirements aus Zeitmangel nicht vollständig formuliert und/oder nicht dem empfohlenen Review unterzogen, ist es unmöglich, die hier beschriebenen Qualitätsmerkmale hinreichend erfüllen zu können.
Die richtige Person für das richtige Requirement.
Die Person oder die Personengruppe, die das Requirement erstellt, muss sachverständig sein. Sie muss das fachliche Umfeld vollständig überblicken. Sie muss den Wunsch des Auftraggebers und das, was er damit bezwecken will, verstehen. Andernfalls entspricht das Endergebnis zwar den formulierten Bedürfnissen, geht aber am eigentlich benötigten Zweck vorbei. Negative Auswirkungen auf angrenzende Geschäftsbereiche müssen erkannt und verhindert werden.
Allgemeines Wording schlägt gruppenspezifisches Wording.
Beim Erstellen des Requirements soll kein personengruppenspezifisches Wording verwendet werden, denn Unklarheiten und Missverständnisse sind so bei Drittbeteiligten vorprogrammiert.
Es existieren keine subjektiven Selbstverständlichkeiten.
Ein jeder bewegt sich in seinem persönlichen Erfahrungsumfeld. Daher muss der Ersteller des Requirements bei seinen Aktivitäten eine Art Vogelperspektive einnehmen. Er berücksichtigt die evtl. vorhandenen Unterschiede zwischen seinem eigenen Wissensstand und dem der anderen handelnden Personen. Das Fehlen dieses Soft Skills manifestiert sich häufig in späteren Hinweisen auf ein „das weiß man doch“. Grundsätzlich sind die Auswirkungen unzureichender Requirements allen Beteiligten hinreichend klar. Dennoch stößt man bei ihrer Erstellung inklusive der Anwendung aller Qualitätsmerkmale auf Widerstände bei handelnden Personen. Für diesen Fall bietet es sich an, auf die zu erwartenden negativen Folgen hinzuweisen. Ziel muss es sein, dass alle Personen, die am Entwicklungsprozess beteiligt sind, ein klares gesichertes Bild von der Erwartungshaltung haben, die der Auftraggeber hat. Zusätzlich können firmen- oder projektspezifische zusätzliche Erfordernisse an Requirements entstehen. Auf diese und aus Gesetzen resultierende Erfordernisse konnte dieser Artikel jedoch nicht eingehen.
FAZIT
Schwachstellen im Produkt resultieren häufig aus fehlender Erfüllung erforderlicher Qualitätsmerkmale, die sich früh im Softwareentwicklungsprozess ergeben. Die Erstellung qualitativ hochwertiger Requirements ist elementar. Sind die Requirements auf einem qualitativ hohen Niveau, ist die GrundlageBefür gute Ergebnisse bei den nachgelagerten Prozessschritten und damit dem zu entwickelnden Produkt gelegt. Maßgeschneiderte Funktionalitäten, die zudem „in time“ und „in budget“ sind, sind wahrscheinlich und tragen zu einem gelungenen Gesamtergebnis bei.
