Wissen / Anforderungen und Funktionsprüfung

Software-Anforderungen: Funktionen prüfbar beschreiben

Kurz gesagt: Eine Softwarefunktion lässt sich sinnvoll beauftragen, wenn Nutzeraufgabe, Eingaben, Regeln und erwartetes Ergebnis klar sind. Ergänzen Sie konkrete Beispiele sowie erlaubte und unerlaubte Abläufe. Abnahmekriterien beschreiben beobachtbares Verhalten unter benannten Bedingungen. So können Unternehmen und Entwicklung dieselbe Funktion beurteilen, bevor zusätzliche Wünsche, technische Annahmen oder ungeklärte Ausnahmefälle den Umfang verändern.

Veröffentlicht am / Redaktion: Ruhrstack / 9 Minuten Lesezeit

01 / NUTZERAUFGABE

Mit einem Arbeitsschritt beginnen, nicht mit einem Bildschirm.

Der Zweck einer Funktion erklärt, welches Ergebnis tatsächlich gebraucht wird.

„Wir brauchen eine Freigabefunktion“ klingt zunächst eindeutig. Im Betrieb kann damit jedoch gemeint sein, einen Entwurf intern zu prüfen, eine Bestellung verbindlich weiterzuleiten oder nur eine Nachricht an die zuständige Person zu schicken. Diese Unterschiede verändern Daten, Zugriffsrechte und Fehlerfolgen. Eine Skizze mit einem Freigabeknopf beantwortet sie noch nicht.

Notieren Sie deshalb zuerst, wer die Funktion in welcher Situation benutzt und was danach anders sein soll. Verwenden Sie die Wörter aus Ihrem eigenen Betrieb. Eine fiktive Aufgabe könnte lauten: Die Teamleitung bestätigt einen vollständig vorbereiteten Materialauftrag, damit das Einkaufsteam nur geprüfte Aufträge erhält. Das beschreibt einen Geschäftsvorgang und lässt die technische Umsetzung zunächst offen.

Das GOV.UK Service Manual ordnet User Stories über handelnde Person, Aufgabe und Ziel ein. Wir nutzen diese Planungsidee hier für Entwicklungsaufträge; die Anleitung für britische öffentliche Dienste ist keine verbindliche Vorgabe für Ihr Unternehmen. Eine kurze verständliche Beschreibung genügt, wenn sie den tatsächlichen Bedarf erkennen lässt.

Wer gerade die gesamte neue Website vorbereitet, kann zunächst das Website-Briefing verwenden. Dieser Artikel vertieft die Spezifikation einer einzelnen eigenen Funktion, etwa in einem Plugin, Script oder internen Werkzeug.

02 / FACHREGELN

Die Regeln festhalten, die heute in Köpfen oder Tabellen stehen.

Auch scheinbar selbstverständliche Ausnahmen brauchen eine bewusste Entscheidung.

Listen Sie die benötigten Eingaben und ihre Bedeutung auf. „Datum“ ist nicht präzise genug, wenn Versanddatum, gewünschter Liefertermin und Bearbeitungsdatum verschiedene Dinge sind. Ebenso können Menge, Einheit, Währung oder Status im bestehenden System anders verwendet werden als im neuen Werkzeug. Eine Begriffsliste verhindert, dass gleiche Feldnamen unbemerkt unterschiedliche Inhalte transportieren.

Danach folgen die fachlichen Regeln: Wann darf der Vorgang beginnen? Welche Angaben sind erforderlich? Wer darf ihn ausführen? Welche Werte sind zulässig? Welcher Zustand entsteht danach? Beschreiben Sie auch, welche bestehende Information erhalten bleiben muss. Das ist besonders relevant, wenn mehrere Personen denselben Vorgang bearbeiten oder eine externe Anwendung beteiligt ist.

Trennen Sie bestätigte Regeln von offenen Fragen. „Vermutlich darf jede Teamleitung alle Aufträge freigeben“ ist eine Annahme, keine brauchbare Berechtigungsvorgabe. Halten Sie die zuständige Person und den benötigten Klärungsschritt fest. Eine offene Frage verschwindet nicht dadurch, dass sie in einem technischen Dokument als feststehende Wahrheit formuliert wird.

Die Methode Example Mapping von Cucumber unterscheidet Regeln, erläuternde Beispiele, offene Fragen und weitere mögliche Aufgaben. Diese Trennung lässt sich auch in einer gewöhnlichen Projektnotiz nutzen. Ein bestimmtes Werkzeug oder ein Workshopformat ist dafür nicht erforderlich.

03 / KONKRETE BEISPIELE

Aus einer Regel mehrere überprüfbare Fälle machen.

Die folgende Matrix ist ein eigenes fiktives Beispiel für einen internen Materialauftrag.

Für die fiktive Funktion gilt: Nur die zugeordnete Teamleitung darf einen vollständig ausgefüllten Auftrag aus dem Zustand „Entwurf“ freigeben. Die Freigabe macht ihn für das Einkaufsteam sichtbar. Ein zweiter Klick soll keinen zweiten Auftrag erzeugen. Ob eine Benachrichtigung sofort erfolgen muss, wird als getrennte Anforderung vereinbart.

Voraussetzung, Aktion und erwartetes Ergebnis
AusgangslageAktionErwartetes Ergebnis
Vollständiger Entwurf, zuständige TeamleitungFreigabe auslösenDer Auftrag steht genau einmal als freigegeben in der Einkaufsliste.
Lieferort fehltFreigabe auslösenDer Entwurf bleibt erhalten; eine Textmeldung benennt den fehlenden Lieferort.
Person ohne FreigaberechtFreigabe versuchenKeine Statusänderung und kein Zugriff auf fremde Auftragsdetails.
Auftrag bereits freigegebenDie Aktion erneut ausführenKeine zweite Bestellung und kein zusätzlicher Freigabevorgang.
Entwurf währenddessen verändertÄlteren Stand freigebenDie Funktion weist auf die Änderung hin und verlangt eine erneute Prüfung.

Welche dieser Ergebnisse für ein reales Projekt richtig sind, entscheidet der tatsächliche Ablauf. Eine zweite Freigabe könnte in einem anderen Betrieb bewusst vorgesehen sein. Das Beispiel zeigt die Form der Beschreibung, keine universelle Bestellregel. Für Rollen und Zugriffsschutz hilft die vertiefende Berechtigungsmatrix für Webanwendungen.

Die Gherkin-Referenz beschreibt Beispiele aus Ausgangskontext, auslösender Aktion und erwartetem Ergebnis. Solche Fälle können automatisiert werden, wenn passende Testschritte implementiert sind. Eine in Alltagssprache geschriebene Tabelle wird durch ihre Form allein noch nicht zu einem laufenden Softwaretest.

04 / FEHLERFÄLLE

Ein Abbruch darf kein ungeklärtes Ergebnis hinterlassen.

Neben dem normalen Ablauf zählen Wiederholung, Verzögerung und verlorene Rückmeldungen.

Eine Funktion kann ihren Auftrag bereits ausgeführt haben, obwohl die Rückmeldung im Browser ausbleibt. Wenn die Person anschließend erneut klickt, ist die fachliche Frage: Wird derselbe Vorgang wiedererkannt oder entsteht ein zweiter? Schreiben Sie das erwartete Verhalten ausdrücklich auf. Ein bloßer Ladeindikator beantwortet die Frage nach dem tatsächlichen Ergebnis nicht.

Bei einer Verbindung zu einem anderen System unterscheiden sich „nicht gesendet“, „gesendet, aber keine Antwort erhalten“ und „bestätigt verarbeitet“. Legen Sie fest, welcher Zustand für die verantwortliche Person sichtbar ist und wer einen unklaren Vorgang prüfen kann. Ein erneuter Versuch ist nicht für jede Aktion automatisch zulässig; er muss zur Bedeutung des Vorgangs passen.

Beschreiben Sie auch fachlich abgelehnte Eingaben, fehlende Berechtigungen, abgelaufene Sitzungen und zeitgleiche Änderungen. Nicht jedes technische Detail gehört in die Nutzeroberfläche. Die Person muss jedoch wissen, ob sie einen Wert korrigieren, sich neu anmelden oder die Betreuung kontaktieren soll. Ein Fehlercode ohne verständliche Einordnung reicht für diesen Zweck oft nicht aus.

Beim fiktiven Materialauftrag könnte der Abnahmetest den Versand einer Benachrichtigung vorübergehend unterbrechen. Erwartet wird dann, dass die Freigabe weiterhin eindeutig sichtbar bleibt und der ausstehende Hinweis gesondert bearbeitet werden kann. Das setzt eine entsprechende technische Lösung voraus und wird gemeinsam vereinbart. Zur umfassenderen Übertragung zwischen Anwendungen gehört die Planung einer API-Schnittstelle.

05 / QUALITÄTSKRITERIEN

„Schnell und einfach“ in konkrete Bedingungen übersetzen.

Bedienung, Datenprüfung und Laufzeit brauchen einen passenden Maßstab.

Eine Formulierung wie „Die Suche ist schnell“ lässt verschiedene Erwartungen zu. Bestimmen Sie stattdessen die zu prüfende Datenmenge, den Vorgang, die Testumgebung und einen vereinbarten Grenzwert. Ein Suchtest mit zehn Datensätzen belegt kein brauchbares Verhalten bei hunderttausend Einträgen. Umgekehrt sollte ein kleiner interner Auftrag nicht mit unbegründeten Lastanforderungen überladen werden.

Für die Bedienung können konkrete Abläufe geprüft werden: Ein Vorgang lässt sich mit der Tastatur durchführen, notwendige Angaben sind bezeichnet und ein Fehler ist dem passenden Feld zugeordnet. Die W3C-Erläuterung zur Fehlererkennung beschreibt, dass automatisch erkannte Eingabefehler in Text benannt und dem betroffenen Element zugeordnet werden. Ein einzelnes erfülltes Kriterium belegt noch keine vollständige Barrierefreiheit.

Die technische Prüfung muss auch unzulässige Eingaben berücksichtigen. OWASP unterscheidet syntaktische und semantische Eingabevalidierung. Für unser Beispiel ist sowohl ein zulässiges Zahlenformat als auch die fachlich erlaubte Menge wichtig. Browserprüfungen unterstützen die Bedienung; die verarbeitende Anwendung muss ihre Regeln selbst zuverlässig durchsetzen.

Weitere Qualitätskriterien können nachvollziehbare Zustände, begrenzte Datenzugriffe oder ein dokumentierter Wiederanlauf sein. Wählen Sie sie nach der tatsächlichen Funktion. Eine allgemeine Forderung „alles sicher“ ist schwer abzunehmen; ein bestimmter unerlaubter Zugriff mit eindeutig erwarteter Ablehnung lässt sich als Teil eines Schutzkonzepts konkret prüfen.

06 / KRITERIENVORLAGE

Ein kleines Funktionsblatt als gemeinsame Arbeitsgrundlage.

Diese eigene Vorlage verbindet Beschreibung, Beispiele und prüfbare Nachweise.

Funktion und Zweck
Welcher einzelne Arbeitsschritt soll für welche Person möglich werden?
Voraussetzungen
Benötigte Daten, Ausgangszustand, beteiligte Systeme und erlaubte Rolle.
Fachregeln
Erlaubte Werte, Statuswechsel, Grenzen und ausdrücklich ausgeschlossene Aktionen.
Beispiele
Mindestens ein normaler Ablauf und die für diese Aufgabe wichtigen Grenz- und Fehlerfälle.
Nachweis
Testdaten, beobachtbares Ergebnis, geprüfte Fassung und verantwortliche Prüfung.
Offene Fragen
Was noch entschieden werden muss, von wem und vor welchem Arbeitsschritt.

Vergeben Sie kurze Kennungen, etwa F-01 für die Freigabefunktion und F-01-03 für den fehlenden Lieferort. So können Rückfragen, Tests und spätere Änderungen auf dieselbe Beschreibung zeigen. Halten Sie Testdaten ohne unnötige reale Kundeninformationen bereit. Ein benanntes Beispiel lässt sich wesentlich leichter erneut prüfen als eine Erinnerung an einen erfolgreichen Bildschirmklick.

Erfassen Sie bei der Prüfung nicht nur „bestanden“. Notieren Sie die getestete Fassung, die verwendeten Daten und relevante Abweichungen. Wurde ein anderer Fall ausprobiert oder eine Voraussetzung geändert, muss das erkennbar bleiben. Ein Nachweis für eine ältere Regel kann nicht stillschweigend eine später erweiterte Funktion bestätigen.

Automatisierte Tests können wiederkehrende technische und fachliche Prüfungen übernehmen. Welche Fälle sinnvoll automatisiert werden und welche eine gemeinsame Sichtprüfung brauchen, entscheidet die Aufgabe. Das Funktionsblatt dient beiden Formen als Bezugspunkt. Es ersetzt weder die Entwicklung solcher Tests noch eine vertragliche Regelung über Umfang, Abnahme oder Mängelbehandlung.

07 / UMFANG UND ÄNDERUNGEN

Die erste brauchbare Funktion von weiteren Wünschen trennen.

Zusätzliche Ideen bleiben sichtbar, ohne den begonnenen Auftrag unbemerkt zu verändern.

Beim Beschreiben der Freigabe können sofort neue Wünsche entstehen: Vertretungsregeln, Mehrfachfreigaben, Erinnerungen oder eine mobile Sammelansicht. Notieren Sie diese Ideen gesondert. Fragen Sie, welche Funktion für den ersten tatsächlichen Einsatz nötig ist und welche sinnvoll danach folgen kann. Eine kleine Entwicklung muss nicht alle denkbaren Geschäftssituationen vorwegnehmen.

Wird eine Fachregel geändert, prüfen Sie auch ihre Beispiele und Auswirkungen. Aus „eine Freigabe genügt“ kann „zwei unterschiedliche Personen müssen freigeben“ werden. Dann ändern sich Berechtigungen, Zustände und Rückmeldungen gemeinsam. Eine kleine sichtbare Ergänzung kann deshalb mehr Arbeit auslösen als ihr einzelner Bildschirmbestandteil vermuten lässt.

Die allgemeine Website-Abnahmecheckliste behandelt die fertige Website als Ganzes. Das Funktionsblatt bleibt die detaillierte Grundlage für das Verhalten einer einzelnen Softwarefunktion. Beide Ebenen können nebeneinander bestehen, ohne dieselben Punkte auf jeder Liste vollständig zu wiederholen.

08 / ZUSAMMENARBEIT

Fachwissen und technische Planung gemeinsam prüfen.

Sie müssen keinen technischen Entwurf liefern, um einen Entwicklungsauftrag gut vorzubereiten.

Sie können den heutigen Arbeitsschritt erklären, anonymisierte Beispiele sammeln und die zuständigen Personen benennen. Die Entwicklung klärt daraus technische Voraussetzungen, mögliche Lösungen und noch offene Risiken. Besonders wertvoll ist ein kurzer gemeinsamer Durchgang durch einen normalen und einen problematischen Fall. Dabei werden Widersprüche oft vor der eigentlichen Umsetzung sichtbar.

Auf der Leistungsseite Entwicklung beschreibt Ruhrstack Plugins, Schnittstellen, Scripts und individuelle Webfunktionen. Anforderungen, vereinbarte Testfälle und nachvollziehbare Übergabe gehören zur dort dargestellten Planung. Welche Funktion sinnvoll ist und wie detailliert sie geprüft werden soll, wird anhand Ihrer Systeme und Abläufe festgelegt.

Bringen Sie eine konkrete Aufgabe mit, statt zunächst eine vollständige Wunschliste auszuarbeiten. Ein prüfbares Beispiel ist ein guter Start: Wer macht was, mit welchen Daten, und welches Ergebnis soll danach sichtbar sein? Daraus lässt sich der nächste sinnvolle Entwicklungsauftrag ableiten.

09 / QUELLEN

Quellen und redaktioneller Stand.

Die Quellen wurden am 8. Oktober 2026 geprüft. Funktionsblatt und Materialauftrag sind eigene redaktionelle Arbeitshilfen. Die Methodenhinweise ersetzen weder eine Projektvereinbarung noch eine vollständige fachliche oder technische Prüfung.

  1. GOV.UK Service Manual: Writing user stories, abgerufen am 8. Oktober 2026.
  2. Cucumber: Example Mapping, abgerufen am 8. Oktober 2026.
  3. Cucumber: Gherkin Reference, abgerufen am 8. Oktober 2026.
  4. W3C: Understanding Error Identification, WCAG 2.2, abgerufen am 8. Oktober 2026.
  5. OWASP: Input Validation Cheat Sheet, abgerufen am 8. Oktober 2026.

Redaktioneller Hinweis: Dieser Beitrag dient der allgemeinen Information und ersetzt keine Einzelfallprüfung. Trotz sorgfältiger Recherche wird keine Gewähr für Vollständigkeit und fortdauernde Aktualität übernommen. Eine Haftung nach zwingenden gesetzlichen Vorschriften bleibt unberührt. Redaktionelle Einordnung.

Welche Funktion soll Ihre Arbeit erleichtern?

Beschreiben Sie einen Arbeitsschritt und das gewünschte Ergebnis. Mit Ihren Beispielen klären wir die technische Aufgabe und passende Kriterien für ihre Prüfung.

Funktion und Anforderungen besprechen