Back to Details

problem-based-srs

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Problem-Based SRS

基于问题的SRS

Orchestrate requirements engineering using the Problem-Based SRS methodology (Gorski & Stadzisz). This skill coordinates a 5-step process that ensures every requirement traces back to a real business problem.
采用基于问题的SRS方法论（Gorski & Stadzisz）统筹需求工程。本方法包含5个步骤，确保每一项需求都能追溯到真实的业务问题。

Methodology Overview

方法论概述

Business Context
       ↓
┌──────────────────┐
│ Step 1: CP       │ → See references/step1-customer-problems.md
│ Customer Problems│
└────────┬─────────┘
         ↓
┌──────────────────┐
│ Step 2: SG       │ → See references/step2-software-glance.md
│ Software Glance  │
└────────┬─────────┘
         ↓
┌──────────────────┐
│ Step 3: CN       │ → See references/step3-customer-needs.md
│ Customer Needs   │
└────────┬─────────┘
         ↓
┌──────────────────┐
│ Step 4: SV       │ → See references/step4-software-vision.md
│ Software Vision  │
└────────┬─────────┘
         ↓
┌──────────────────┐
│ Step 5: FR/NFR   │ → See references/step5-functional-requirements.md
│ Requirements     │
└──────────────────┘
Traceability Chain: FR → CN → CP (every requirement traces back to a problem)
Domain Mapping (WHY → WHAT → HOW):
DomainArtifactQuestion Answered
WHYCustomer Problems (CP)Why is the solution needed? (Business justification)
WHATCustomer Needs (CN)What outcomes must the software provide?
HOWFunctional Requirements (FR)How will the system behave?
业务背景
       ↓
┌──────────────────┐
│ 步骤1: CP       │ → 参考references/step1-customer-problems.md
│ 客户问题（Customer Problems）│
└────────┬─────────┘
         ↓
┌──────────────────┐
│ 步骤2: SG       │ → 参考references/step2-software-glance.md
│ 软件概览（Software Glance）  │
└────────┬─────────┘
         ↓
┌──────────────────┐
│ 步骤3: CN       │ → 参考references/step3-customer-needs.md
│ 客户需求（Customer Needs）   │
└────────┬─────────┘
         ↓
┌──────────────────┐
│ 步骤4: SV       │ → 参考references/step4-software-vision.md
│ 软件愿景（Software Vision）  │
└────────┬─────────┘
         ↓
┌──────────────────┐
│ 步骤5: FR/NFR   │ → 参考references/step5-functional-requirements.md
│ 需求（Requirements）     │
└──────────────────┘
可追溯链： FR → CN → CP（每一项需求都可追溯到对应的问题）
领域映射（为什么→是什么→怎么做）：
领域产物解答的问题
为什么客户问题（CP）为什么需要这个解决方案？（业务合理性）
是什么客户需求（CN）软件必须实现哪些成果？
怎么做功能需求（FR）系统将如何表现？

📁 Saving Progress (CRITICAL)

📁 进度保存（至关重要）

IMPORTANT: At each step, you MUST save the produced artifacts to files. Progress is NOT automatically saved between sessions.
注意： 在每个步骤完成后，你必须将生成的产物保存到文件中。会话之间不会自动保存进度。

First Time Setup

首次设置

When starting a new project, ask the user:
Before we begin, where would you like to save your SRS artifacts?

Options:
1. `docs/srs/` (recommended - keeps SRS separate from code docs)
2. `requirements/` (alternative - at project root)
3. Custom path: [specify your preferred location]

All artifacts will be saved in this folder with consistent naming.
启动新项目时，询问用户：
开始之前，你希望将SRS产物保存到哪里？

选项：
1. `docs/srs/`（推荐 - 将SRS与代码文档分开存放）
2. `requirements/`（替代选项 - 项目根目录下）
3. 自定义路径：[指定你偏好的位置]

所有产物将以统一命名规则保存到该文件夹中。

Artifact File Structure

产物文件结构

Create the following folder structure as you progress through each step:
[chosen-folder]/                      # e.g., docs/srs/
├── 00-context.md                     # Business context and project overview
├── 01-customer-problems.md           # Step 1: CPs (WHY)
├── 02-software-glance.md             # Step 2: High-level solution view
├── 03-customer-needs.md              # Step 3: CNs (WHAT)
├── 04-software-vision.md             # Step 4: Architecture and scope
├── functional-requirements/          # Step 5: Individual FR files
│   ├── _index.md                     # FR summary and traceability matrix
│   ├── FR-001.md                     # Individual FR file
│   ├── FR-002.md                     # Individual FR file
│   └── ...                           # One file per FR
├── non-functional-requirements/      # NFR files (quality attributes)
│   ├── _index.md                     # NFR summary
│   ├── NFR-001.md                    # Individual NFR file
│   └── ...                           # One file per NFR
└── traceability-matrix.md            # CP → CN → FR complete mapping
在推进各步骤时，创建以下文件夹结构：
[选定文件夹]/                      # 例如：docs/srs/
├── 00-context.md                     # 业务背景和项目概述
├── 01-customer-problems.md           # 步骤1：CP（为什么）
├── 02-software-glance.md             # 步骤2：高层级解决方案视图
├── 03-customer-needs.md              # 步骤3：CN（是什么）
├── 04-software-vision.md             # 步骤4：架构与范围
├── functional-requirements/          # 步骤5：单独的FR文件
│   ├── _index.md                     # FR汇总及可追溯矩阵
│   ├── FR-001.md                     # 单个FR文件
│   ├── FR-002.md                     # 单个FR文件
│   └── ...                           # 每个FR对应一个文件
├── non-functional-requirements/      # NFR文件（质量属性）
│   ├── _index.md                     # NFR汇总
│   ├── NFR-001.md                    # 单个NFR文件
│   └── ...                           # 每个NFR对应一个文件
└── traceability-matrix.md            # CP → CN → FR完整映射表

Why Individual FR/NFR Files?

为什么要将FR/NFR保存为单独文件？

Each Functional Requirement and Non-Functional Requirement is saved as a separate file so that:
  1. Engineers can work independently on different requirements
  2. Version control tracks changes to individual requirements
  3. Code reviews can focus on specific requirements
  4. Traceability is maintained at the file level
  5. Status tracking is easier (draft, approved, implemented, tested)
每个功能需求和非功能需求都保存为独立文件，以便：
  1. 工程师可独立工作在不同需求上
  2. 版本控制可追踪单个需求的变更
  3. 代码评审可聚焦于特定需求
  4. 可追溯性在文件层面得以维护
  5. 状态追踪更便捷（草稿、评审中、已批准、已实现、已测试）

FR File Template (FR-XXX.md)

FR文件模板（FR-XXX.md）

Each FR file follows this template:
markdown
undefined
每个FR文件遵循以下模板：
markdown
undefined

FR-XXX: [Brief Title]

FR-XXX: [简短标题]

Requirement

需求

Statement: The [System] shall [verb] [object] [constraint] [condition].
Priority: [Must Have | Should Have | Could Have | Won't Have] Status: [Draft | Review | Approved | Implemented | Tested]
陈述： [系统]应[动词] [对象] [约束条件] [场景]。
优先级： [必须具备 | 应该具备 | 可以具备 | 暂不具备] 状态： [草稿 | 评审中 | 已批准 | 已实现 | 已测试]

Traceability

可追溯性

Traces ToIDDescription
Customer NeedCN-XXX[Brief CN description]
Customer ProblemCP-XXX[Brief CP description]
追溯至ID描述
客户需求CN-XXX[CN简要描述]
客户问题CP-XXX[CP简要描述]

Acceptance Criteria

验收标准

  • Criterion 1 (testable)
  • Criterion 2 (testable)
  • Criterion 3 (testable)
  • 标准1（可测试）
  • 标准2（可测试）
  • 标准3（可测试）

Notes

备注

[Any additional context, assumptions, or dependencies]
<!-- ⚠️ NO CODE SNIPPETS: Do not include code examples, SQL, or implementation details here. Construction details belong in design/ folder (see design/implementation-notes/) -->
Created: [Date] Last Updated: [Date] Author: [Name]
undefined
[任何额外背景、假设或依赖关系]
<!-- ⚠️ 请勿包含代码片段：此处不要添加代码示例、SQL或实现细节。 构建细节应放在design/文件夹中（参考design/implementation-notes/） -->
创建日期: [日期] 最后更新: [日期] 作者: [姓名]
undefined

NFR File Template (NFR-XXX.md)

NFR文件模板（NFR-XXX.md）

markdown
undefined
markdown
undefined

NFR-XXX: [Brief Title]

NFR-XXX: [简短标题]

Requirement

需求

Category: [Performance | Security | Usability | Reliability | Scalability | Maintainability] Statement: The [System] shall [quality attribute with measurable criteria].
Priority: [Must Have | Should Have | Could Have | Won't Have] Status: [Draft | Review | Approved | Implemented | Tested]
类别： [性能 | 安全性 | 易用性 | 可靠性 | 可扩展性 | 可维护性] 陈述： [系统]应[具备可衡量标准的质量属性]。
优先级： [必须具备 | 应该具备 | 可以具备 | 暂不具备] 状态： [草稿 | 评审中 | 已批准 | 已实现 | 已测试]

Traceability

可追溯性

Traces ToIDDescription
Customer NeedCN-XXX[Brief CN description]
Applies To FRsFR-XXX, FR-YYY[Related functional requirements]
追溯至ID描述
客户需求CN-XXX[CN简要描述]
关联FRFR-XXX, FR-YYY[相关功能需求]

Acceptance Criteria

验收标准

  • Criterion 1 (measurable)
  • Criterion 2 (measurable)
  • 标准1（可衡量）
  • 标准2（可衡量）

Measurement Method

验证方法

[How this NFR will be verified/tested]
<!-- ⚠️ NO CODE SNIPPETS: Do not include code examples or implementation details here. Technical specifications belong in design/ folder -->
Created: [Date] Last Updated: [Date]
undefined
[如何验证/测试该NFR]
<!-- ⚠️ 请勿包含代码片段：此处不要添加代码示例或实现细节。 技术规格应放在design/文件夹中 -->
创建日期: [日期] 最后更新: [日期]
undefined

Save After Each Step

每步完成后保存

After completing each step, ALWAYS:
  1. Create or update the corresponding file(s)
  2. Confirm with user that files were saved
  3. Show the file paths for reference
Example handoff for Step 5:
✅ Step 5 Complete: Functional Requirements Specified

📁 Saved to: docs/srs/functional-requirements/
   ├── _index.md (summary with 8 FRs)
   ├── FR-001.md → CN-001 (User Registration)
   ├── FR-002.md → CN-001 (User Authentication)
   ├── FR-003.md → CN-002 (Data Validation)
   ├── FR-004.md → CN-002 (Error Handling)
   ├── FR-005.md → CN-003 (Report Generation)
   ├── FR-006.md → CN-003 (Export Functionality)
   ├── FR-007.md → CN-004 (Search Capability)
   └── FR-008.md → CN-004 (Filter Options)

📁 Updated: docs/srs/traceability-matrix.md

Engineers can now work on individual requirements independently.
Each FR file contains full context and acceptance criteria.
完成每个步骤后，必须：
  1. 创建或更新对应的文件
  2. 与用户确认文件已保存
  3. 展示文件路径供参考
步骤5完成后的示例交付：
✅ 步骤5完成：功能需求已明确

📁 保存至：docs/srs/functional-requirements/
   ├── _index.md（包含8个FR的汇总）
   ├── FR-001.md → CN-001（用户注册）
   ├── FR-002.md → CN-001（用户认证）
   ├── FR-003.md → CN-002（数据验证）
   ├── FR-004.md → CN-002（错误处理）
   ├── FR-005.md → CN-003（报告生成）
   ├── FR-006.md → CN-003（导出功能）
   ├── FR-007.md → CN-004（搜索能力）
   └── FR-008.md → CN-004（筛选选项）

📁 更新文件：docs/srs/traceability-matrix.md

工程师现在可独立处理单个需求。每个FR文件包含完整上下文及验收标准。

Context File (00-context.md)

上下文文件（00-context.md）

Create this file at the start of every project:
markdown
undefined
每个项目启动时都要创建此文件：
markdown
undefined

Project Context: [Project Name]

项目上下文: [项目名称]

Business Domain

业务领域

[Description of the business area]
[业务领域描述]

Current Situation

当前现状

[Description of current state/problems]
[当前状态/问题描述]

Stakeholders

干系人

RoleName/GroupInterest
[Role][Who][What they care about]
角色姓名/群体关注点
[角色][相关人员][他们关心的内容]

Scope

范围

  • In Scope: [What's included]
  • Out of Scope: [What's excluded]
  • 包含范围： [包含的内容]
  • 排除范围： [排除的内容]

Constraints

约束条件

  • [Constraint 1]
  • [Constraint 2]
Created: [Date] Last Updated: [Date]
undefined
  • [约束条件1]
  • [约束条件2]
创建日期: [日期] 最后更新: [日期]
undefined

How to Use This Skill

如何使用本方法

Starting Fresh

全新启动

When user provides business context or problem description:
  1. Ask where to save artifacts (if not already specified)
  2. Create 00-context.md with the business context
  3. Detect current step (see Detection Heuristics below)
  4. Load the appropriate reference file
  5. Follow instructions from that reference
  6. Save output to the corresponding file(s)
  7. Guide user through the process
当用户提供业务背景或问题描述时：
  1. 询问产物保存位置（若未指定）
  2. 创建00-context.md文件，记录业务背景
  3. 检测当前步骤（参考下方检测规则）
  4. 加载对应的参考文件
  5. 遵循参考文件中的指引
  6. 将输出保存到对应文件
  7. 引导用户完成流程

Continuing Work

继续已有工作

If user has existing artifacts (CPs, CNs, etc.):
  1. Check for existing SRS folder (docs/srs/, requirements/, etc.)
  2. Read existing files to understand current state
  3. Identify what they have
  4. Jump to appropriate step
  5. Load that step's reference file
  6. Continue from there, updating files as needed
若用户已有产物（CP、CN等）：
  1. 检查是否存在SRS文件夹（docs/srs/、requirements/等）
  2. 读取现有文件以了解当前状态
  3. 识别已完成的内容
  4. 跳转到对应步骤
  5. 加载该步骤的参考文件
  6. 继续推进，按需更新文件

Validation

验证

At any point, use references/zigzag-validator.md to check consistency.
在任何阶段，可使用references/zigzag-validator.md检查一致性。

Detection Heuristics

检测规则

Determine current step by checking what artifacts exist:
If user has...Current StepLoad ReferenceSave To
Nothing / business idea only1step1-customer-problems.md01-customer-problems.md
Customer Problems (CPs)2step2-software-glance.md02-software-glance.md
CPs + Software Glance3step3-customer-needs.md03-customer-needs.md
CPs + CNs + Software Glance4step4-software-vision.md04-software-vision.md
CPs + CNs + Software Vision5step5-functional-requirements.mdfunctional-requirements/*.md
通过检查已存在的产物来确定当前步骤：
若用户已有...当前步骤加载参考文件保存至
无内容 / 仅业务想法1step1-customer-problems.md01-customer-problems.md
客户问题（CP）2step2-software-glance.md02-software-glance.md
CP + 软件概览3step3-customer-needs.md03-customer-needs.md
CP + CN + 软件概览4step4-software-vision.md04-software-vision.md
CP + CN + 软件愿景5step5-functional-requirements.mdfunctional-requirements/*.md

The 5 Steps (Quick Reference)

5个步骤（快速参考）

Step 1: Customer Problems (CP)

步骤1：客户问题（CP）

Purpose: Identify and document business problems
Input: Business context
Output: List of CPs classified as Obligation/Expectation/Hope
Syntax: 
[Subject] [must/expects/hopes] [Object] [Penalty]

Save to: 
01-customer-problems.md

Details: See step1-customer-problems.md
目标： 识别并记录业务问题
输入： 业务背景
输出： 分类为“义务/期望/希望”的CP列表
格式： [主体] [必须/期望/希望] [对象] [后果]
保存至： 
01-customer-problems.md

详情： 参考step1-customer-problems.md

Step 2: Software Glance (SG)

步骤2：软件概览（SG）

Purpose: Create initial abstract solution view
Input: Customer Problems
Output: High-level system description with boundaries and components
Save to: 
02-software-glance.md

Details: See step2-software-glance.md
目标： 创建初始抽象解决方案视图
输入： 客户问题
输出： 定义了边界和组件的高层级系统描述
保存至： 
02-software-glance.md

详情： 参考step2-software-glance.md

Step 3: Customer Needs (CN)

步骤3：客户需求（CN）

Purpose: Specify outcomes software must provide
Input: CPs + Software Glance
Output: CNs with outcome classes (Information/Control/Construction/Entertainment)
Syntax: 
[Subject] needs [system] to [Verb] [Object] [Condition]

Save to: 
03-customer-needs.md

Details: See step3-customer-needs.md
目标： 明确软件必须实现的成果
输入： CP + 软件概览
输出： 带有成果分类（信息/控制/构建/娱乐）的CN列表
格式： [主体]需要[系统]来[动词] [对象] [场景]
保存至： 
03-customer-needs.md

详情： 参考step3-customer-needs.md

Step 4: Software Vision (SV)

步骤4：软件愿景（SV）

Purpose: Define high-level scope and positioning
Input: CNs + Software Glance
Output: Vision document with stakeholders, features, architecture
Save to: 
04-software-vision.md

Details: See step4-software-vision.md
目标： 定义高层级范围和定位
输入： CN + 软件概览
输出： 包含干系人、功能、架构的愿景文档
保存至： 
04-software-vision.md

详情： 参考step4-software-vision.md

Step 5: Functional Requirements (FR) & Non-Functional Requirements (NFR)

步骤5：功能需求（FR）& 非功能需求（NFR）

Purpose: Generate detailed requirements
Input: CNs + Software Vision
Output: Individual FR and NFR files with traceability
Syntax FR: 
The [System] shall [Verb] [Object] [Constraint] [Condition]

Save to: 
functional-requirements/FR-XXX.md
and 
non-functional-requirements/NFR-XXX.md

Details: See step5-functional-requirements.md
目标： 生成详细需求
输入： CN + 软件愿景
输出： 带有可追溯性的单个FR和NFR文件
FR格式： [系统]应[动词] [对象] [约束条件] [场景]
保存至： 
functional-requirements/FR-XXX.md
和 
non-functional-requirements/NFR-XXX.md

详情： 参考step5-functional-requirements.md

Quality Gates

质量关卡

IMPORTANT: Zigzag validation using references/zigzag-validator.md is MANDATORY after Steps 3 and 5 to verify traceability and identify gaps.
注意： 在步骤3和步骤5完成后，必须使用references/zigzag-validator.md进行Z字形验证，以确认可追溯性并识别缺口。

After Step 1 (CPs)

步骤1完成后（CP）

  • All CPs use structured notation
  • Classifications assigned (Obligation/Expectation/Hope)
  • No solutions embedded in problem statements
  • File saved: 
    01-customer-problems.md
  • 所有CP使用结构化格式
  • 已分配分类（义务/期望/希望）
  • 问题陈述中未嵌入解决方案
  • 已保存文件： 
    01-customer-problems.md

After Step 2 (SG)

步骤2完成后（SG）

  • System boundaries defined
  • Main actors and interfaces identified
  • High-level components described
  • File saved: 
    02-software-glance.md
  • 已定义系统边界
  • 已识别主要参与者和接口
  • 已描述高层级组件
  • 已保存文件： 
    02-software-glance.md

After Step 3 (CNs)

步骤3完成后（CN）

  • Every CP has at least one CN
  • All CNs use structured notation
  • Outcome classes assigned
  • File saved: 
    03-customer-needs.md
  • MANDATORY: Run zigzag validation (CP → CN mapping)
  • 每个CP至少对应一个CN
  • 所有CN使用结构化格式
  • 已分配成果分类
  • 已保存文件： 
    03-customer-needs.md
  • 必须执行：运行Z字形验证（CP → CN映射）

After Step 4 (SV)

步骤4完成后（SV）

  • Positioning statement clear
  • All stakeholders identified
  • Major features listed
  • File saved: 
    04-software-vision.md
  • 定位陈述清晰
  • 已识别所有干系人
  • 已列出主要功能
  • 已保存文件： 
    04-software-vision.md

After Step 5 (FRs/NFRs)

步骤5完成后（FR/NFR）

  • Every CN has at least one FR
  • All FRs use "shall" or "should"
  • Each FR saved as individual file in 
    functional-requirements/
  • Each NFR saved as individual file in 
    non-functional-requirements/
  • Index files created (
    _index.md
    )
  • Traceability matrix complete (FR → CN → CP)
  • No code snippets or programming examples in FR/NFR files
  • Construction details in separate 
    design/
    folder (not in FR/NFR files)
  • File saved: 
    traceability-matrix.md
  • MANDATORY: Run zigzag validation (full chain verification)
  • 每个CN至少对应一个FR
  • 所有FR使用“应”或“应该”表述
  • 每个FR保存为
    functional-requirements/
    下的独立文件
  • 每个NFR保存为
    non-functional-requirements/
    下的独立文件
  • 已创建索引文件（
    _index.md
    ）
  • 可追溯矩阵已完成（FR → CN → CP）
  • FR/NFR文件中无代码片段或编程示例
  • 构建细节存放在单独的
    design/
    文件夹中（而非FR/NFR文件）
  • 已保存文件： 
    traceability-matrix.md
  • 必须执行：运行Z字形验证（完整链验证）

Problem-First Enforcement

问题优先原则

If user attempts to skip to solutions, redirect:
Detect: User mentions specific technology, feature, or implementation before CPs exist
Redirect:
I notice you're describing a solution. Let's first understand the problem.

Before we design [mentioned solution], help me understand:
1. What business obligation, expectation, or hope drives this need?
2. What negative consequences occur without this?
3. Who is impacted?

→ Loading: references/step1-customer-problems.md
若用户试图直接跳到解决方案，需引导回问题分析：
检测： 用户在CP尚未明确时提及特定技术、功能或实现方案
引导：
我注意到你正在描述解决方案。我们应先理解问题本身。

在设计[提及的解决方案]之前，请帮助我理解：
1. 是什么业务义务、期望或希望驱动了这个需求？
2. 如果没有这个解决方案，会产生什么负面影响？
3. 哪些人会受到影响？

→ 正在加载：references/step1-customer-problems.md

Quick Syntax Reference

快速格式参考

ArtifactSyntax Pattern
CP[Subject] [must/expects/hopes] [Object] [Penalty]
CN[Subject] needs [system] to [Verb] [Object] [Condition]
FRThe [System] shall [Verb] [Object] [Constraint] [Condition]
NFRThe [System] shall [quality attribute with measurable criteria]
产物格式模板
CP[主体] [必须/期望/希望] [对象] [后果]
CN[主体]需要[系统]来[动词] [对象] [场景]
FR[系统]应[动词] [对象] [约束条件] [场景]
NFR[系统]应[具备可衡量标准的质量属性]

Handoff Protocol

交付协议

When completing each step:
  1. Save outputs to the appropriate file(s)
  2. Summary of outputs produced
  3. Validation that gate criteria are met
  4. Next step recommendation
  5. Required inputs for next step
Example:
✅ Step 3 Complete: Customer Needs Specified

📁 Saved to: docs/srs/03-customer-needs.md

Outputs:
- CN-001: [Information] User needs system to display...
- CN-002: [Control] Admin needs system to manage...
- CN-003: [Information] Manager needs system to report...

Gate Check:
- [x] All CNs use structured notation
- [x] Outcome classes assigned
- [x] Every CP has at least one CN
- [x] File saved

→ Next: Step 4 - Software Vision
→ Loading: references/step4-software-vision.md
→ Will save to: docs/srs/04-software-vision.md
→ Input: The CNs documented above
完成每个步骤时：
  1. 保存输出到对应文件
  2. 汇总生成的输出内容
  3. 验证是否符合关卡标准
  4. 推荐下一步骤
  5. 说明下一步所需输入
示例：
✅ 步骤3完成：客户需求已明确

📁 保存至：docs/srs/03-customer-needs.md

输出内容：
- CN-001: [信息类] 用户需要系统显示...
- CN-002: [控制类] 管理员需要系统管理...
- CN-003: [信息类] 经理需要系统生成报告...

关卡检查：
- [x] 所有CN使用结构化格式
- [x] 已分配成果分类
- [x] 每个CP至少对应一个CN
- [x] 文件已保存

→ 下一步：步骤4 - 软件愿景
→ 正在加载：references/step4-software-vision.md
→ 将保存至：docs/srs/04-software-vision.md
→ 输入：上述已记录的CN

Usage Patterns

使用模式

Pattern 1: Full Process (New Project)

模式1：完整流程（新项目）

Start with Step 1 and progress through all 5 steps sequentially. Remember: Ask where to save files, create context file first.
从步骤1开始，依次完成所有5个步骤。 注意： 询问文件保存位置，先创建上下文文件。

Pattern 2: Jump In (Existing Artifacts)

模式2：中途接入（已有产物）

Detect what artifacts exist, skip completed steps, resume at current step. Remember: Check for existing SRS folder and read current files.
检测已存在的产物，跳过已完成步骤，从当前步骤继续。 注意： 检查是否存在SRS文件夹并读取现有文件。

Pattern 3: Iterative Refinement

模式3：迭代优化

Complete initial pass, then iterate on specific steps as understanding improves. Remember: Update existing files rather than creating new ones.
完成初始流程后，随着理解加深，迭代优化特定步骤。 注意： 更新现有文件而非创建新文件。

Pattern 4: Validation Only

模式4：仅验证

Use zigzag-validator.md to check existing artifacts without generating new ones.
使用zigzag-validator.md检查现有产物，不生成新内容。

Pattern 5: Independent Development

模式5：独立开发

After Step 5, engineers can pick up individual FR files and develop independently. Each FR file contains all context needed (traceability, acceptance criteria).
步骤5完成后，工程师可选取单个FR文件独立开发。每个FR文件包含所需的完整上下文（可追溯性、验收标准）。

When to Load Each Reference

何时加载各参考文件

  • Step 1 (CP): User has business context but no structured problems
  • Step 2 (SG): User has CPs and needs high-level solution view
  • Step 3 (CN): User has CPs + SG and needs to specify outcomes
  • Step 4 (SV): User has CNs and needs detailed vision document
  • Step 5 (FR/NFR): User has CNs + SV and needs functional requirements
  • Validation: User needs to check traceability or consistency
Always load only one reference at a time based on current step to minimize context usage.
  • 步骤1（CP）： 用户有业务背景但无结构化问题
  • 步骤2（SG）： 用户有CP且需要高层级解决方案视图
  • 步骤3（CN）： 用户有CP + SG且需要明确成果
  • 步骤4（SV）： 用户有CN且需要详细愿景文档
  • 步骤5（FR/NFR）： 用户有CN + SV且需要功能需求
  • 验证： 用户需要检查可追溯性或一致性
始终根据当前步骤仅加载一个参考文件，以最小化上下文占用。