feat/pmv2 #3
|
|
@ -77,7 +77,7 @@ The PM must not:
|
|||
- Write pseudocode
|
||||
- Write code
|
||||
|
||||
The PM may inspect existing product behavior, exposed interfaces, docs, and current-state constraints to keep requirements grounded, but must not derive or prescribe implementation design from internal code structure.
|
||||
The PM may inspect existing product behavior, exposed interfaces, docs, and current-state constraints when needed for scope clarity, but must not derive or prescribe implementation design from internal code structure.
|
||||
|
||||
PM defines WHAT.
|
||||
Engineering defines HOW.
|
||||
|
|
@ -130,8 +130,10 @@ Examples by context:
|
|||
- Regulated domains: retention, privacy, compliance logging
|
||||
|
||||
## Output Format
|
||||
PM must always output:
|
||||
- `## Research Inputs` (optional when relevant)
|
||||
PM must always output the following sections.
|
||||
If a section is not applicable, write `N/A` with a brief reason.
|
||||
|
||||
- `## Research Inputs`
|
||||
- `## Problem`
|
||||
- `## Goals`
|
||||
- `## Non Goals`
|
||||
|
|
@ -164,11 +166,11 @@ Bad example:
|
|||
- `The system should work correctly`
|
||||
|
||||
Good examples:
|
||||
- `Given a valid create-job request, when the request is submitted, then the system returns HTTP 201`
|
||||
- `Given a successful job creation, when the response is returned, then the response contains job_id`
|
||||
- `Given a successful job creation, when the response is returned, then job_id is a valid UUID v7`
|
||||
- `Given a successful job creation, when the job is queried, then it is queryable within 1 second`
|
||||
- `Given the same payload and the same idempotency key, when the request is repeated, then the system does not create a duplicate record`
|
||||
- `Given a valid create-job request, when the request is submitted, then the API returns HTTP 201`
|
||||
- `Given a successful job creation, when the response is returned, then it contains job_id`
|
||||
- `Given a successful job creation, when job_id is returned, then it must be a valid UUID v7`
|
||||
- `Given a job is created successfully, when it is queried within 1 second, then the job can be retrieved`
|
||||
- `Given the same request payload is retried with the same idempotency key, when the request is repeated, then no duplicate job is created`
|
||||
|
||||
## Context-Driven Coverage Rules
|
||||
The PM must decide which requirement categories are necessary for the feature. Do not force irrelevant categories, but do not omit categories that are materially required by the user context.
|
||||
|
|
@ -210,10 +212,6 @@ Before handing off a PRD, verify it contains:
|
|||
- Risks
|
||||
|
||||
Strongly recommended when relevant:
|
||||
- Research Inputs
|
||||
- Assumptions
|
||||
- Dependencies
|
||||
- Open Questions
|
||||
- Error handling
|
||||
- Idempotency
|
||||
- Observability
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@
|
|||
- 次要輸出:GitHub Issue(僅限使用者明確要求時)
|
||||
|
||||
## PRD 結構
|
||||
- `## Research Inputs`(有需要才填)
|
||||
- `## Research Inputs`
|
||||
- `## Problem`
|
||||
- `## Goals`
|
||||
- `## Non Goals`
|
||||
|
|
@ -36,6 +36,8 @@
|
|||
- `## Dependencies`
|
||||
- `## Open Questions`
|
||||
|
||||
若某段不適用,請填 `N/A` 並附一句原因。
|
||||
|
||||
## 規則
|
||||
- 驗收標準必須使用 `Given / When / Then`
|
||||
- 每條驗收標準必須可觀察、可測試、可拒收、可衡量、不可歧義
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ Before finalizing the PRD, verify that every acceptance criterion maps to at lea
|
|||
|
||||
## Research Inputs
|
||||
|
||||
Summarize relevant market, competitor, user, or regulatory insights when they materially influence the PRD. Omit this section if no research was needed.
|
||||
Summarize relevant market, competitor, user, or regulatory insights when they materially influence the PRD. If no research was needed, write `N/A` with a brief reason.
|
||||
|
||||
## Problem
|
||||
|
||||
|
|
@ -126,15 +126,15 @@ List product, operational, compliance, or adoption risks that could affect deliv
|
|||
|
||||
## Assumptions
|
||||
|
||||
List assumptions this PRD depends on being true.
|
||||
List assumptions this PRD depends on being true. If there are no material assumptions, write `N/A` with a brief reason.
|
||||
|
||||
## Dependencies
|
||||
|
||||
List dependencies on teams, systems, policies, vendors, or external events.
|
||||
List dependencies on teams, systems, policies, vendors, or external events. If there are no material dependencies, write `N/A` with a brief reason.
|
||||
|
||||
## Open Questions
|
||||
|
||||
List unresolved product questions that must be answered before implementation or release.
|
||||
List unresolved product questions that must be answered before implementation or release. If there are no open questions, write `N/A` with a brief reason.
|
||||
|
||||
</prd-template>
|
||||
|
||||
|
|
@ -157,7 +157,7 @@ Do not:
|
|||
- Break work into engineering tasks
|
||||
- Write pseudocode or code
|
||||
|
||||
The PM may inspect existing product behavior, exposed interfaces, docs, and current-state constraints to keep requirements grounded, but must not derive or prescribe implementation design from internal code structure.
|
||||
The PM may inspect existing product behavior, exposed interfaces, docs, and current-state constraints when needed for scope clarity, but must not derive or prescribe implementation design from internal code structure.
|
||||
|
||||
## Minimum Completeness Gate
|
||||
|
||||
|
|
@ -175,10 +175,6 @@ The PRD must contain:
|
|||
- Risks
|
||||
|
||||
Add these when relevant:
|
||||
- Research Inputs
|
||||
- Assumptions
|
||||
- Dependencies
|
||||
- Open Questions
|
||||
- Error handling
|
||||
- Idempotency
|
||||
- Observability
|
||||
|
|
|
|||
Loading…
Reference in New Issue