This commit is contained in:
2026-03-22 22:40:25 +07:00
parent 56acb0d5ee
commit d5c27b4b88

View File

@@ -30,14 +30,16 @@ This document defines the documentation framework for a software project. It est
- Aligns engineering efforts with business goals - Aligns engineering efforts with business goals
- Provides a north star for feature development - Provides a north star for feature development
- Establishes acceptance criteria before implementation begins - Establishes acceptance criteria before implementation begins
- Creates a contract between product and engineering - Creates a contract between product, engineering, security, and operations.
**Content Guidelines**: **Content Guidelines**:
- User stories with clear acceptance criteria (As a X, I want Y so that Z) - User stories with clear acceptance criteria (As a X, I want Y so that Z)
- Product Requirements Documents (PRDs) with success metrics - Product Requirements Documents with clear success metrics and KPIs.
- Non-functional requirements (performance, security, scalability) - Nonfunctional requirements covering performance, scalability, availability, reliability, and privacy.
- Boundary definitions (what's in scope vs. out of scope) - Boundary definitions that state what is in scope and out of scope.
- Do not cite any other documents as requirements.md is the first document to be created in the ASG Framework - Security requirements including threat model outcomes, authentication and authorization expectations, data classification, encryption requirements, and compliance controls.
- Observability requirements specifying required telemetry, metrics, traces, logs, alerting thresholds, and retention policies.
- Traceability rule: do not cite other documents as the source of requirements. requirements.md is the canonical first document in the ASG Framework.
**Best Practices**: **Best Practices**:
- Link each requirement to a measurable KPI - Link each requirement to a measurable KPI
@@ -401,24 +403,39 @@ Each documentation artifact has associated KPIs. Track these to ensure quality:
```markdown ```markdown
# PRD: Feature Name # PRD: Feature Name
## Business Goal ## 1. Business Context & Success Metrics
[What problem are we solving?] - Business Goal
- User Stories (with acceptance criteria)
- KPIs & Targets (e.g., "99.95% availability", "<200ms p95 latency")
## Success Metrics ## 2. Technical Boundaries
- [Metric 1]: Target [value] - In Scope
- [Metric 2]: Target [value] - Out of Scope
- Dependencies (e.g., "Requires Stripe API v2023-08")
## User Stories ## 3. Non-Functional Requirements (NFRs)
- As a [role], I want [feature] so that [benefit] ### 3.1 Performance & Scalability
- Acceptance Criteria: [details] - [e.g., Support 10K TPS, scale horizontally to 100 nodes]
## Non-Functional Requirements ### 3.2 Availability & Reliability
- Performance: [details] - [e.g., SLO: 99.9% monthly uptime, MTTR < 10min]
- Security: [details]
- Scalability: [details]
## Out of Scope ### 3.3 Privacy & Security
- [What's explicitly excluded] - Data Classification: [e.g., PII, PHI]
- Threat Model Outcomes: [e.g., "Mitigates replay attacks via nonce + timestamp"]
- Auth/Z Expectations: [e.g., RBAC with 3 roles: viewer, editor, admin]
- Encryption: [e.g., TLS 1.3+, AES-256 at rest]
- Compliance: [e.g., GDPR Art. 32, SOC2 Type II]
### 3.4 Observability & Telemetry
- Required Logs: [e.g., `user_id`, `request_id`, `status`, `latency_ms`]
- Critical Metrics: [e.g., `auth_failures_total`, `api_latency_seconds{quantile=0.99}`]
- Tracing: [e.g., Zipkin/B3 propagation, 10% sampling]
- Alerting: [e.g., `auth_failure_rate > 5%/min` triggers PagerDuty]
- Retention: [e.g., Logs: 30 days, Metrics: 1 year]
## 4. Acceptance Conditions
- [List verifiable conditions for sign-off, including validation gates]
``` ```
### Specification Template ### Specification Template