← Zurück zu libGDX · Projektplanungspaket

Skill · Version 1.0.0

Anforderungen nachverfolgen

Verknüpft angenommene Spielregeln mit ihrer Implementierung und Prüfung. Zeigt abgedeckte und ungeprüfte Anforderungen sowie Änderungen ohne vereinbarten Zweck.

requirement-to-code-traceability

Agenten mit diesem Skill

Entdecke, wie der Skill hilft

Wann ist der Skill hilfreich?

Nutze ihn beim Abgleich einer Lieferung mit dem Briefing oder bei Prüfung jeder Zusage auf Code und aussagekräftige Tests.

Wobei hilft er dir?

  • Ordnet jedem Abnahmekriterium Umsetzung und Tests zu.
  • Verfolgt geänderten Code zu begründeten Anforderungen zurück.
  • Prüft Erfolgs-, Fehler- und Grenzfallnachweise ohne neuen Umfang.

Das könntest du fragen

Verfolge die Anforderung, dass ein Kontrollpunkt Gesundheit wiederherstellt, aber gesammelte Questgegenstände nicht neu erzeugt. Ordne jeden Teil Respawn-Code, Speicherdaten und Tests zu. Berücksichtige Tod beim Einsammeln und alte Spielstände und benenne fehlende Belege, ohne neue Rücksetzregeln zu erfinden.

Ausführliche Dokumentation

Hier findest du die ursprüngliche Anleitung, Beispiele und Prüfschritte des Skills in ihrer Originalsprache.

Details…Weniger anzeigen

Requirement-to-Code Traceability

Use this skill to verify that the implemented code actually fulfills the accepted specification — neither dropping required business rules nor introducing unrequested behavior changes.

The Three-Way Traceability Matrix

For every work item, map each requirement across three columns: $$\text{Requirement / Acceptance Criterion} \longrightarrow \text{Implementing Code Path(s)} \longrightarrow \text{Verifying Test(s)}$$

Workflow

  1. Map every acceptance criterion to its exact implementation:
    • Walk through the brief and specification item by item:
      • Fully implemented: Identify the exact functions, handlers, UI states, and database queries enforcing the rule.
      • Partially implemented: E.g., enforced in the UI button state, but missing from the backend API endpoint or background worker.
      • Missing / Stubbed: Left unimplemented, hardcoded, or behind an unreachable branch.
  2. Trace reverse from the diff back to requirements:
    • For every non-trivial behavioral change in the diff, ask: "Which accepted requirement or bugfix requires this change?"
    • Flag unrequested behavioral changes (silent changes to existing defaults, altered API response shapes, modified sorting/filtering semantics, or weakened validation) that were not authorized by the specification.
  3. Verify happy, error, and boundary paths in code:
    • Confirm the code handles not only the nominal path, but also the specified rejection paths, permission denials, empty states, and boundary values.
  4. Link each requirement to its verification evidence:
    • Check whether each acceptance criterion has a corresponding test assertion that exercises the real code path and would fail if that requirement were broken.
    • Explicitly list any acceptance criterion that is implemented in code but currently lacks automated test coverage.

Enthaltene Dateien 1

  • SKILL.md