This commit is contained in:
2026-05-22 07:41:26 +07:00
parent 6e321dedcd
commit c325520128

View File

@@ -50,11 +50,6 @@ This document defines the documentation framework for a software project. It est
- Maintain backward compatibility with existing requirements
- Review and update requirements as business context changes
**Requirement vs KPI Clarification**:
- **FR and NFR** is a *requirement* — it defines what quality or constraint the system must have (e.g., "System shall support 10K TPS", "99.9% monthly uptime", "TLS 1.3+ encryption")
- **KPI** is a *measurement* — it's the actual data collected to verify if the requirement was met (e.g., "Peak traffic was 8.5K TPS", "MTTR was 8 minutes", "100% of connections use TLS 1.3")
- Requirements tell you **what to build**; KPIs tell you **how well you built it**
---
### 2. Solution Design
@@ -442,6 +437,23 @@ Each documentation artifact has associated KPIs. Track these to ensure quality:
---
## Deployment Decision Rules
These rules define the critical gates that must be passed before and after deployment:
- **Acceptance Condition NOT met → Don't deploy** (buggy/broken)
- **KPI NOT met after deployment → Deployed feature is failing business goals (need fix/optimization)**
**Acceptance Conditions** are verified *before deployment* through testing and validation. They determine whether the implementation matches the specification and is ready for production.
**KPIs** are measured *after deployment* to validate whether the feature is achieving its business goals. If KPIs are not met, the feature may be deployed but is failing its intended purpose and requires immediate attention (fixes or optimization).
These rules serve as a binary decision framework:
- Acceptance Conditions = **Quality Gate** (deploy or block)
- KPIs = **Business Health Monitor** (deploy but fix if failing)
---
## Template Examples
### Requirements Template