TRS System Feature Design Document

Problem

Enterprise TRS feature design documents often share the same failure modes: requirements stay at “support” or “optimize” level, fields and workflows lack verifiable acceptance criteria, interface contracts are pasted as raw JSON, and traceability, peripherals, audit, and rollback boundaries are missing. This Skill narrows the gap between product intent and engineering review.

Workflow and Boundaries

It first selects a working mode: verbal requirements use 5W1H clarification, while HTML, image, or Figma prototypes use a prototype-driven flow. The output must cover scope, user value, business process, functional breakdown, detailed design, non-functional requirements, risks, dependencies, and release acceptance. Key constraints include:
- Minimal question set: traceability granularity, key nodes, scanning points, integrated systems, and audit trails must be asked first
- Value-list five elements: data source, cascade rules, default rules, display rules, and search behavior
- Self-check scoring: completeness, ambiguity, traceability, consistency, and data-item completeness are evaluated
- Interface contract: use operation summary tables and field-meaning tables instead of raw HTTP, URL, or JSON payloads

It is not intended for pure implementation design, architecture documentation, or backend API specifications. Unknown information should be marked as assumptions, not invented.