PRD Checklist - Development Process for Preventing Requirement Document Omissions
Why This Process Is Needed
Long requirement documents (hundreds to thousands of lines) contain a large number of functional details: page layout, interaction behaviors, calculation formulas, data fields, color rules, permission control, etc. If you start writing code immediately after reading the document, your attention will shift from "requirement details" to "code logic", resulting in a large number of functional points being omitted. The longer the document, the more serious the omissions.
The core idea of this process is: Do not rely on memory, but create a structured external checklist, and check items one by one against it while writing code.
Process Overview
Read complete document → Generate Checklist file → User confirms no omissions → Implement module by module → Check off each item upon completion → Scan unchecked items after module completion
Strictly follow the following three phases, skipping the first phase to directly write code is prohibited.
Phase 1: Read Document + Generate Checklist
1. Read the Requirement Document in Full
- Must read every line of the document, cannot start summarizing after only reading the first few hundred lines
- If the document exceeds 2000 lines, read in sections to ensure full coverage
- During reading, build a module structure tree of the document in your mind
2. Generate Checklist File
Create
<original-filename>-checklist.md
in the same directory as the requirement document.
Checklist writing rules (these rules directly determine the completeness of the final code):
Granularity Requirement — One checkbox corresponds to one independently verifiable implementation point:
- Each UI element as a separate item (a card, a button, a chart)
- Each interaction behavior as a separate item (hover prompt, click jump, expand/collapse)
- Each data field as a separate item (each column of a table, each indicator of a card)
- Each calculation formula/business rule as a separate item
- Each color/style rule as a separate item
- Each permission control point as a separate item
- Each non-functional requirement (performance, security, compatibility) as a separate item
Structure Requirement:
- Strictly organize according to the chapter hierarchy of the original document (e.g., 3.1 → 3.1.1 → 3.1.2)
- Each chapter title is consistent with the original document for easy backtracking
- Under each sub-chapter, group by UI area (e.g., "Page Top", "Indicator Card Area", "Chart Area")
Content Requirement:
- Each checkbox must contain sufficient implementation details, cannot only use vague descriptions
- Poor: "Display indicator card"
- Good: "School average score card: Weighted average of total scores of all students, data source: exam_scores, display month-on-month change arrow (up/down) and change value"
- If the original document contains calculation formulas, write them completely into the checkbox (do not omit as "see document")
- If the original document has ASCII prototypes, extract each UI element as an independent checkbox
End Statistics:
- Add a statistics table at the end of the file, listing the number of functional points for each module and the total
Checklist Template
markdown
# [System Name] Functional Checklist
> Source: [Original Filename] ([Number of Lines] lines)
> Purpose: Check item by item during development to prevent function omissions
> Usage: Mark [x] for each implemented functional point, and verify no omissions at the end
---
## [Module Number] [Module Name]
### [Sub-module Number] [Sub-module Name]
**[UI Area Name]:**
- [ ] [Specific functional point description with implementation details]
- [ ] [Specific functional point description with implementation details]
**[Another UI Area]:**
- [ ] ...
---
## Statistics
|------|---------|
| [Module 1] | [Quantity] |
| [Module 2] | [Quantity] |
| **Total** | **[Total Number]** |
3. Ask User for Confirmation
After generating the Checklist, inform the user:
- Total number of functional points extracted
- Please ask the user to check against the original document for any omissions
- Only proceed to the implementation phase after user confirmation
Phase 2: Implement Module by Module
1. Implement in Module Order
- Only implement one module at a time (e.g., 3.1 School Data Cockpit)
- Before starting implementation, re-read the corresponding Checklist chapter for the module
- Also re-read the original text of the module in the original PRD document (Checklist is a summary, the original text has more context)
2. Check Off Items One by One
- Immediately change to in the Checklist file after implementing a functional point
- Do not wait until the entire module is written to check off in batches—check off while writing, so omissions can be detected in real time
3. Scan After Module Completion
After writing the code for a module:
- Re-read the Checklist for the module
- Check item by item to ensure all are checked off
- If there are unchecked items, supplement the implementation
- Only proceed to the next module after all items are checked off
Phase 3: Global Verification After Completion
After all modules are implemented:
- Read the complete Checklist file
- Search for all unchecked items
- If there are unchecked items, inform the user and ask if supplementary implementation is needed
- Output final statistics: Total functional points / Implemented count / Unimplemented count
Handling Special Cases
When the document contains non-frontend requirements (e.g., backend, operation and maintenance, security):
- Still extract them into the Checklist, but mark as
- Skip these items during implementation, but list them in the final report
When the document has "optional function" marks:
- Mark as in the Checklist
- Ask the user whether to implement them during implementation
When the user says "only implement a certain module first":
- Still generate a complete Checklist (because there may be dependencies between modules)
- But only implement the module specified by the user