software-design

Software design

Dependency specification

#[[file:../rules/review-base.md]] #[[file:../rules/git-workflow.md]] #[[file:../rules/project-structure.md]] #[[file:frontend-design.md]] #[[file:backend-design.md]]

Purpose

Transform requirements into an executable module design plan, clarifying module boundaries, interfaces, and UI interactions.

Input

• Requirements document: requirements list + scope boundary description, or conversation context

Steps

For each step, output the title first, then output the result

• Phased design: divide the design into batches, complete module boundaries, interfaces, and interaction flows in each batch, review and confirm with developers, and record design decisions
• Document splitting: according to the project architecture, follow frontend-design and backend-design specifications to output the corresponding design documents separately
• Module dependencies: after all module designs are completed, annotate the dependencies between modules
• Write to documents: one separate file per module, create an entry document referencing all design files (paths follow the project-structure document storage specification)
• Execute review: comply with review-base, and only proceed to the next step after passing

Output

• Module division plan: responsibilities, boundaries
• Module dependencies: annotate the dependencies between modules; modules without dependencies do not need to be listed
• Frontend design document: output according to the frontend-design specification (when frontend is involved)
• Backend design document: output according to the backend-design specification (when backend is involved)

Review checklist

• Module responsibilities: single, clear boundaries, no overlapping responsibilities
• Frontend design: complies with the frontend-design specification (when frontend is involved)
• Backend design: complies with the backend-design specification (when backend is involved)
• Module dependencies: dependencies have been annotated, no circular dependencies
• Requirements coverage: covers all confirmed requirements, no omissions
• Common modules: identified, no duplicate design
• Sensitive information: design documents do not contain sensitive information such as real passwords, keys, tokens, etc.; use placeholders instead

Phase end

Next phase:dev-planning

#[[file:../rules/stage-gate.md]]