One-sentence requirement → Complete PRD: Through a structured SOP process, transform a vague product idea into a professional product requirements document containing user stories, a feature list, MoSCoW prioritization, and acceptance criteria.
Quick Start
The user only needs to provide a one-sentence description of the requirement, and the Agent automatically completes the PRD according to the following process:
用户：我想做一个团队内部的知识库系统
Agent：[按 SOP 流程输出完整 PRD]
SOP Process
Phase 1: Requirement Elicitation
Goal: Extract enough information from the user's one-sentence requirement to build the PRD.
Steps：
- Parse the original requirement: Identify the core verbs, target objects, and implicit constraints in the user's requirement
- Ask clarifying questions(up to 5 key questions):
- Who are the target users? (internal team / external customers / both)
- What is the core pain point to be solved? (How is it done now, and what is bad about it)
- Are there any reference products or competitors?
- Are there any hard constraints? (time, budget, tech stack, compliance requirements)
- What are the measures of success? (key metrics)
- If the user asks to skip clarification, then proceed based on reasonable assumptions and state them in the "Assumptions and Constraints" section of the PRD
Output: A requirements background summary (no more than 200 words)
Phase 2: User Personas & Stories
Goal: Identify all key roles and write user stories for each role.
Steps：
-
Identify user roles（Persona）：
-
List 2-5 core roles
-
Describe each role's identity, goals, and pain points in one sentence
-
Format:
**角色名称**：[一句话描述] - 身份：[职位/角色] - 核心目标：[想达成什么] - 主要痛点：[现在遇到什么问题]
-
-
Write user stories（User Stories）：
- At least 3 user stories per role
- Standard format:As a[role],I want[feature],so that[value/purpose]
- User stories must satisfy the INVEST principle:
- Independent: stories should have as few dependencies on each other as possible
- Negotiable: do not lock in the implementation approach
- Valuable: provides clear value to users
- Estimable: the team can estimate the effort
- Small: can be completed within one iteration
- Testable: has a clear verification method
-
Story map arrangement: Arrange stories according to the timeline of the user journey and identify the core path
Output: User role table + user story list
Phase 3: Feature Decomposition
Goal: Translate user stories into a concrete feature list, distinguishing functional and non-functional requirements.
Procedure：
-
Functional requirements（Functional Requirements）：
- Extract specific feature points from each user story
- Each feature point includes:
- Feature ID (F-001, F-002...)
- Feature name
- Parent user story ID
- Feature description (state in one sentence what it does)
- Input / output / interaction description
-
Non-functional requirements（Non-Functional Requirements）：
-
Check the following dimensions one by one and mark the applicable ones:
Dimension Check item Performance Response time, concurrency, throughput Security Authentication, authorization, data encryption, compliance Availability SLA, disaster recovery, backup and restore Scalability User growth, data growth, feature expansion Usability Learning cost, accessibility, multilingual support Compatibility Browsers, devices, operating systems, API versions
-
-
Feature dependencies: Draw the sequential dependencies between features (which features must be built first)
Output: Functional requirements table + non-functional requirements table + dependency description
Phase 4: MoSCoW prioritization
Objective: Classify all features by priority using the MoSCoW framework.
MoSCoW framework definition：
| Level | Meaning | Criteria | Suggested proportion |
|---|---|---|---|
| Must Have | Must have | Without it the product cannot launch and the user's core flow cannot be completed | About 60% |
| Should Have | Should have | Important but not critical; a workaround can be used in the short term | About 20% |
| Could Have | Could have | Nice to have; better with it, fine without it | About 15% |
| Won't Have (this time) | Won't have | Explicitly excluded to avoid scope creep; deferred to a later version | About 5% |
Procedure：
-
Evaluate each feature: Answer three questions for each feature:
- If this feature were missing, could the product still launch? (No → Must)
- If this feature were missing, would users be clearly dissatisfied? (Yes → Should)
- Does this feature have a clear alternative? (Yes → Could / Won't)
-
Priority check：
- Must Have should not exceed 60% of all features (exceeding this means the breakdown is not fine enough)
- Won't Have must include at least 1-2 items (showing that trade-offs were made, not that everything is included)
- Check whether the dependency chains among Must Have items are complete
-
Output the priority matrix table：
| 功能编号 | 功能名称 | 优先级 | 理由 | |----------|----------|--------|------| | F-001 | xxx | Must | xxx |
Output: MoSCoW priority matrix
Phase 5: Acceptance Criteria
Objective: Write testable acceptance criteria for each Must Have and Should Have feature.
Steps：
-
Use the Given-When-Then format：
功能：F-001 用户登录 AC-F001-01: 正常登录 Given 用户已注册且账号状态正常 When 用户输入正确的邮箱和密码并点击登录 Then 系统跳转到首页，显示用户昵称 AC-F001-02: 密码错误 Given 用户已注册 When 用户输入错误密码并点击登录 Then 系统显示"邮箱或密码错误"，不透露具体是哪个错 -
Acceptance criteria checklist(each AC must satisfy):
- Does it describe only behavior, without specifying the implementation?
- Can it be verified independently (without depending on other ACs)?
- Does it cover the normal path and at least one exception path?
- Are the boundary conditions explicit (numeric ranges, character lengths, null handling)?
- Is there a clear expected result (not a vague description like "works normally")?
-
Coverage requirements：
- Must Have features: at least 3 ACs each (normal + exception + boundary)
- Should Have features: at least 2 ACs each (normal + exception)
- Could Have features: at least 1 AC each (normal path)
Output: A list of acceptance criteria grouped by feature
Phase 6: Document assembly and output
Goal: Assemble the outputs of the first five phases into a complete PRD document.
PRD document template：
# [产品名称] - 产品需求文档（PRD）
> 版本：v1.0 | 作者：[填写] | 日期：[当前日期]
> 状态：草稿
## 1. 概述
### 1.1 背景与动机
[Phase 1 的需求背景摘要]
### 1.2 目标
- 业务目标：[要达成什么业务结果]
- 用户目标：[要解决用户什么问题]
- 成功指标：[KPI / 北极星指标]
### 1.3 范围
- 本期包含：[Must + Should 功能概述]
- 本期不包含：[Won't Have 列表及原因]
## 2. 用户画像
[Phase 2 的用户角色表]
## 3. 用户故事
[Phase 2 的用户故事列表，按角色分组]
## 4. 功能需求
### 4.1 功能清单
[Phase 3 的功能需求表]
### 4.2 非功能需求
[Phase 3 的非功能需求表]
### 4.3 功能依赖关系
[Phase 3 的依赖关系说明]
## 5. 优先级
### 5.1 MoSCoW 矩阵
[Phase 4 的优先级矩阵表]
### 5.2 版本规划建议
- MVP（v1.0）：所有 Must Have
- v1.1：所有 Should Have
- v2.0：评估 Could Have
## 6. 验收标准
[Phase 5 的验收标准列表，按功能分组]
## 7. 假设与约束
### 7.1 假设
- [列出所有假设，特别是 Phase 1 中因信息不足而做的假设]
### 7.2 约束
- 技术约束：[如有]
- 业务约束：[如有]
- 时间约束：[如有]
### 7.3 风险
| 风险 | 影响 | 概率 | 缓解措施 |
|------|------|------|----------|
| xxx | 高 | 中 | xxx |
## 8. 开放问题
- [ ] [待确认的问题 1]
- [ ] [待确认的问题 2]
## 附录
- 术语表（如有领域专业术语）
- 参考文档链接
Document output requirements：
- All tables use Markdown format
- Feature numbers are globally unique and consecutive
- There is a clear mapping relationship between user story numbers and feature numbers
- Acceptance criteria numbering format: AC-[feature number]-[sequence number] (e.g., AC-F001-01)
- Dates use the current actual date
Process control rules
Interaction mode selection
Select the mode based on the level of detail in the user input:
| User input | Mode | Behavior |
|---|---|---|
| Only one sentence (< 50 characters) | Guided mode | Execute Phase 1 questioning, and continue after the user answers |
| Some detail (50-200 characters) | Semi-automatic mode | Ask 2-3 key questions while starting Phase 2 |
| Detailed requirement description (> 200 characters) | Fully automatic mode | Start directly from Phase 2, skipping clarification |
| The user says "just write it / no need to ask" | Quick mode | Output the complete PRD directly based on reasonable assumptions |
Quality checklist
Before outputting the final PRD, check each item one by one:
- Each user role has at least 3 user stories
- Each user story maps to at least 1 feature
- Each feature has a MoSCoW priority
- Must Have accounts for no more than 60%
- Won't Have has at least 1 item
- All Must Have features have at least 3 acceptance criteria
- Acceptance criteria use the Given-When-Then format
- The assumptions and constraints section is non-empty
- The open questions section is non-empty (there are always unconfirmed items)
- All numbers are consecutive with no omissions
Iterative refinement
If the user gives feedback on the PRD:
- Locate the Phase involved in the feedback
- Re-execute from that Phase
- Cascade updates downward to all affected content
- Maintain numbering system consistency
Reference methodologies
This SOP integrates the following product management methodologies:
- User Story Mapping(Jeff Patton): User Story Mapping method
- MoSCoW Prioritization(DSDM / Agile): Requirements prioritization framework
- INVEST Principle: User story quality standards
- Behavior-Driven Development (BDD): Given-When-Then acceptance criteria format
- Kano Model(Reference): Requirements classification concept (Basic → Must, Expected → Should, Excitement → Could)