@ngocsangairvds/vsaf 4.1.25 → 4.1.26
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/skills/sdlc/ba-validate-srs/SKILL.md +8 -0
- package/skills/sdlc/ba-validate-srs/data/domain-checklists/insurance.yaml +110 -0
- package/skills/sdlc/ba-validate-srs/data/grep-patterns-srs.yaml +158 -0
- package/skills/sdlc/ba-validate-srs/data/srs-review-glossary.md +237 -0
- package/skills/sdlc/ba-validate-srs/steps-v/step-v-01-discovery.md +280 -0
- package/skills/sdlc/ba-validate-srs/steps-v/step-v-02-business-alignment.md +351 -0
- package/skills/sdlc/ba-validate-srs/steps-v/step-v-03-completeness.md +353 -0
- package/skills/sdlc/ba-validate-srs/steps-v/step-v-04-consistency.md +352 -0
- package/skills/sdlc/ba-validate-srs/steps-v/step-v-05-quality.md +347 -0
- package/skills/sdlc/ba-validate-srs/steps-v/step-v-06-system-nfr.md +217 -0
- package/skills/sdlc/ba-validate-srs/steps-v/step-v-07-delivery-readiness.md +288 -0
- package/skills/sdlc/ba-validate-srs/steps-v/step-v-08-risk-analysis.md +283 -0
- package/skills/sdlc/ba-validate-srs/steps-v/step-v-09-user-impact.md +262 -0
- package/skills/sdlc/ba-validate-srs/steps-v/step-v-10-report.md +308 -0
- package/skills/sdlc/ba-validate-srs/workflow.md +269 -0
- package/skills/sdlc/ba-write-srs/SKILL.md +8 -0
- package/skills/sdlc/ba-write-srs/srs-feature-template.md +669 -0
- package/skills/sdlc/ba-write-srs/srs-system-template.md +430 -0
- package/skills/sdlc/ba-write-srs/workflow.md +139 -0
- package/skills/sdlc/pack.yaml +4 -0
- package/skills/sdlc/srs/SKILL.md +44 -55
|
@@ -0,0 +1,280 @@
|
|
|
1
|
+
---
|
|
2
|
+
# model: haiku
|
|
3
|
+
# contextOutput: '{output_folder}/_validation_temp/context.yaml'
|
|
4
|
+
# grepPatterns: '../data/grep-patterns-srs.yaml'
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Step V-01: Discovery — Xác định scope và tạo report skeleton
|
|
8
|
+
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
## 1. Xác định SRS files cần validate
|
|
12
|
+
|
|
13
|
+
Hỏi user:
|
|
14
|
+
|
|
15
|
+
```
|
|
16
|
+
Bạn muốn validate SRS nào?
|
|
17
|
+
|
|
18
|
+
1. **Single file** — Validate 1 file SRS cụ thể
|
|
19
|
+
2. **Batch** — Validate nhiều files SRS (chọn danh sách)
|
|
20
|
+
3. **Full** — Validate toàn bộ SRS trong folder output
|
|
21
|
+
|
|
22
|
+
Chọn (1/2/3):
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
Chờ user chọn.
|
|
26
|
+
|
|
27
|
+
---
|
|
28
|
+
|
|
29
|
+
## 2. Scan files
|
|
30
|
+
|
|
31
|
+
Dựa vào lựa chọn:
|
|
32
|
+
|
|
33
|
+
### Option 1 — Single file
|
|
34
|
+
- User cung cấp file path hoặc FR number
|
|
35
|
+
- Đọc file, xác nhận file tồn tại và có nội dung
|
|
36
|
+
|
|
37
|
+
### Option 2 — Batch
|
|
38
|
+
- Liệt kê tất cả SRS files trong `{output_folder}/`
|
|
39
|
+
- User chọn files cần validate
|
|
40
|
+
- Đọc danh sách files đã chọn
|
|
41
|
+
|
|
42
|
+
### Option 3 — Full
|
|
43
|
+
- Scan toàn bộ `{output_folder}/05-srs*.md`
|
|
44
|
+
- Liệt kê cho user confirm
|
|
45
|
+
|
|
46
|
+
---
|
|
47
|
+
|
|
48
|
+
## 3. Load Project Context (auto — không cần user input)
|
|
49
|
+
|
|
50
|
+
Tự động load project context từ VSAF artifacts:
|
|
51
|
+
|
|
52
|
+
1. Read `graphify-out/graph.json` (nếu tồn tại) → extract document nodes, feature nodes, service nodes
|
|
53
|
+
2. For each SRS file in scope:
|
|
54
|
+
- Determine feature name from file path
|
|
55
|
+
- Locate upstream docs trong `.vsaf/docs/features/{feature-name}/`
|
|
56
|
+
3. Cross-validation sources (auto-load):
|
|
57
|
+
- PRD: `.vsaf/docs/features/{feature-name}/02-prd.md`
|
|
58
|
+
- Architecture: `.vsaf/docs/features/{feature-name}/03-adr.md`
|
|
59
|
+
- Epics: `.vsaf/docs/features/{feature-name}/04-epics.md` (nếu tồn tại)
|
|
60
|
+
- BRD: tìm trong `.vsaf/docs/` (optional — chỉ khi project có BRD)
|
|
61
|
+
- System SRS: tìm trong `.vsaf/docs/` (optional)
|
|
62
|
+
|
|
63
|
+
**Token efficiency rule:** PRD và ADR trong VSAF thường nhỏ (<500 lines). Đọc toàn bộ file thay vì dùng line-range optimization.
|
|
64
|
+
|
|
65
|
+
---
|
|
66
|
+
|
|
67
|
+
## 3b. Build SRS Section Index and UC Cache
|
|
68
|
+
|
|
69
|
+
After loading KG context, build two caches to eliminate redundant reads in parallel validation steps.
|
|
70
|
+
|
|
71
|
+
### 3b-1. SRS Section Index
|
|
72
|
+
|
|
73
|
+
Load `../data/grep-patterns-srs.yaml` → get `srs_structure` patterns.
|
|
74
|
+
|
|
75
|
+
For each SRS file in scope:
|
|
76
|
+
- Run Grep `^## ` on SRS file, output_mode="content", -n=true → extract all Level-2 section headers with line numbers
|
|
77
|
+
- Build `section_index`: list of `{heading, start_line, end_line}` for each `##` header
|
|
78
|
+
- Compute `end_line` for each heading = next heading's `start_line - 1` (or file total lines for last section)
|
|
79
|
+
|
|
80
|
+
### 3b-2. UC Cache
|
|
81
|
+
|
|
82
|
+
For each SRS file:
|
|
83
|
+
- Run Grep `^### .*UC-` with -n=true → extract all UC headers and line numbers
|
|
84
|
+
- For each UC found, record:
|
|
85
|
+
- `id`: UC identifier (e.g., UC-CA-01)
|
|
86
|
+
- `title`: UC title text
|
|
87
|
+
- `start_line`: line of UC header
|
|
88
|
+
- `end_line`: start_line of next UC (or +80 as estimate)
|
|
89
|
+
- `has_gherkin`: run Grep `Given.*When.*Then` within UC line range → true/false
|
|
90
|
+
- Build `uc_cache`: list of all UCs across all SRS files in scope
|
|
91
|
+
|
|
92
|
+
### 3b-3. Extract Glossary Dimension Items
|
|
93
|
+
|
|
94
|
+
To avoid each parallel agent loading the full glossary:
|
|
95
|
+
- From the glossary already loaded in workflow initialization, extract item IDs per dimension:
|
|
96
|
+
- completeness_items: [has_overview, has_use_case_summary, has_glossary, ...]
|
|
97
|
+
- consistency_items: [uc_id_pattern, screen_id_pattern, ...]
|
|
98
|
+
- quality_items: [no_ambiguous_language, acceptance_criteria_format, ...]
|
|
99
|
+
- (etc. for each dimension)
|
|
100
|
+
|
|
101
|
+
### 3b-4. Write context.yaml
|
|
102
|
+
|
|
103
|
+
Create directory `{output_folder}/_validation_temp/` if it does not exist.
|
|
104
|
+
|
|
105
|
+
Write `{output_folder}/_validation_temp/context.yaml`:
|
|
106
|
+
|
|
107
|
+
```yaml
|
|
108
|
+
# SRS Validation session context — auto-generated by step-v-01
|
|
109
|
+
# DO NOT EDIT manually
|
|
110
|
+
validation_date: "{date}"
|
|
111
|
+
scope: "{single|batch|full}"
|
|
112
|
+
report_path: "{report_output_path}"
|
|
113
|
+
silent_mode: {false} # set true if --silent invocation arg
|
|
114
|
+
|
|
115
|
+
# SRS files in scope
|
|
116
|
+
srs_files:
|
|
117
|
+
- path: "{srs_file_path}"
|
|
118
|
+
fr_id: "{FR_ID}"
|
|
119
|
+
section_index: # from Grep ^## with computed end_line
|
|
120
|
+
- heading: "1. Mô tả chung"
|
|
121
|
+
start_line: 39
|
|
122
|
+
end_line: 134 # next heading start_line - 1
|
|
123
|
+
- heading: "2. Đặc tả Use Cases"
|
|
124
|
+
start_line: 135
|
|
125
|
+
end_line: 1318
|
|
126
|
+
# ... all ## headings with computed end_line (last section end_line = total file lines)
|
|
127
|
+
uc_cache: # from Grep ^### UC-
|
|
128
|
+
- id: "UC-CA-01"
|
|
129
|
+
title: "Đăng ký tài khoản chủ động"
|
|
130
|
+
start_line: 120
|
|
131
|
+
end_line: 200
|
|
132
|
+
has_gherkin: true
|
|
133
|
+
# ... etc
|
|
134
|
+
|
|
135
|
+
# Project context (VSAF convention)
|
|
136
|
+
upstream:
|
|
137
|
+
prd_path: ".vsaf/docs/features/{feature-name}/02-prd.md"
|
|
138
|
+
adr_path: ".vsaf/docs/features/{feature-name}/03-adr.md"
|
|
139
|
+
epics_path: ".vsaf/docs/features/{feature-name}/04-epics.md"
|
|
140
|
+
brd_path: null # set if project has BRD
|
|
141
|
+
graph_json: "graphify-out/graph.json" # set if graphify index exists
|
|
142
|
+
|
|
143
|
+
# Glossary item IDs per dimension (pre-extracted for agent efficiency)
|
|
144
|
+
dimension_items:
|
|
145
|
+
business_alignment: []
|
|
146
|
+
completeness: [has_overview, has_use_case_summary, has_glossary, has_references, has_uc_screens, has_uc_sequence, has_uc_flow_table, has_erd, has_error_codes, has_impact, has_business_rules, has_nfrs, has_dependencies, has_state_diagrams, has_traceability, has_edge_cases, has_acceptance_criteria]
|
|
147
|
+
consistency: []
|
|
148
|
+
quality: [no_ambiguous_language, acceptance_criteria_format, no_duplicate_requirements, clear_scope, flow_step_numbering, diagram_syntax_valid]
|
|
149
|
+
system_nfr: []
|
|
150
|
+
delivery_readiness: []
|
|
151
|
+
risk_analysis: []
|
|
152
|
+
user_impact: []
|
|
153
|
+
```
|
|
154
|
+
|
|
155
|
+
**Token efficiency note:** context.yaml (~100-150 lines) replaces 8+ separate KG file reads across parallel agents. Each agent reads context.yaml once instead of re-loading project artifacts independently.
|
|
156
|
+
|
|
157
|
+
**Derived-from traceability rule (CRITICAL):**
|
|
158
|
+
SRS is a **derived document** — every requirement MUST trace back to PRD, BRD, or Architecture. If SRS contains requirements not in any upstream source, flag as:
|
|
159
|
+
- **CRITICAL** if SRS invents new functional requirements not in PRD/BRD
|
|
160
|
+
- **HIGH** if SRS adds business rules not traceable to BRD
|
|
161
|
+
- **MEDIUM** if SRS adds NFRs/constraints beyond Architecture specs
|
|
162
|
+
|
|
163
|
+
Upstream chain: `BRD → PRD → SRS`, `Architecture → SRS`
|
|
164
|
+
|
|
165
|
+
---
|
|
166
|
+
|
|
167
|
+
## 3c. Regression Check — Load Previous Reports
|
|
168
|
+
|
|
169
|
+
Scan `.vsaf/docs/features/{feature-name}/05-srs-validation-report*.md` for existing reports.
|
|
170
|
+
|
|
171
|
+
If previous reports exist:
|
|
172
|
+
1. Find the most recent report (by date in filename, excluding the report being created now)
|
|
173
|
+
2. Read its frontmatter to get `overall_score`, `overall_status`, `files_reviewed`
|
|
174
|
+
3. Read its "Critical & High Findings" section (section 4) — extract finding IDs
|
|
175
|
+
4. Write to context.yaml:
|
|
176
|
+
|
|
177
|
+
```yaml
|
|
178
|
+
regression:
|
|
179
|
+
previous_report: "05-srs-validation-report-2026-04-06.md"
|
|
180
|
+
previous_score: 72.3
|
|
181
|
+
previous_status: WARN
|
|
182
|
+
previous_critical_high_ids:
|
|
183
|
+
- {id: C-001, dimension: consistency, summary: "service boundary violation"}
|
|
184
|
+
- {id: DR-002, dimension: delivery, summary: "API specs missing"}
|
|
185
|
+
```
|
|
186
|
+
|
|
187
|
+
If no previous reports exist:
|
|
188
|
+
```yaml
|
|
189
|
+
regression:
|
|
190
|
+
previous_report: null
|
|
191
|
+
note: "First validation run — no regression baseline"
|
|
192
|
+
```
|
|
193
|
+
|
|
194
|
+
---
|
|
195
|
+
|
|
196
|
+
## 4. Tạo report skeleton
|
|
197
|
+
|
|
198
|
+
Tạo file output: `.vsaf/docs/features/{feature-name}/05-srs-validation-report.md`
|
|
199
|
+
|
|
200
|
+
Viết frontmatter:
|
|
201
|
+
|
|
202
|
+
```yaml
|
|
203
|
+
---
|
|
204
|
+
type: srs-validation-report
|
|
205
|
+
date: {date}
|
|
206
|
+
validator: BA Validate SRS Skill
|
|
207
|
+
scope: {scope}
|
|
208
|
+
files_reviewed:
|
|
209
|
+
- {list of files}
|
|
210
|
+
overall_score: TBD
|
|
211
|
+
overall_status: TBD
|
|
212
|
+
stepsCompleted:
|
|
213
|
+
- step-v-01-discovery
|
|
214
|
+
---
|
|
215
|
+
```
|
|
216
|
+
|
|
217
|
+
Viết section headers (chưa có nội dung):
|
|
218
|
+
|
|
219
|
+
```markdown
|
|
220
|
+
## 1. Executive Summary
|
|
221
|
+
|
|
222
|
+
_(Sẽ được điền ở Step V-10)_
|
|
223
|
+
|
|
224
|
+
## 2. Overall Score & Confidence
|
|
225
|
+
|
|
226
|
+
_(Sẽ được điền ở Step V-10)_
|
|
227
|
+
|
|
228
|
+
## 3. Heatmap — Score by Dimension
|
|
229
|
+
|
|
230
|
+
_(Sẽ được điền ở Step V-10)_
|
|
231
|
+
|
|
232
|
+
## 4. Critical & High Findings
|
|
233
|
+
|
|
234
|
+
_(Sẽ được điền ở Steps V-02 → V-09)_
|
|
235
|
+
|
|
236
|
+
## 5. Medium & Low Findings
|
|
237
|
+
|
|
238
|
+
_(Sẽ được điền ở Steps V-02 → V-09)_
|
|
239
|
+
|
|
240
|
+
## 6. Top Missing Areas
|
|
241
|
+
|
|
242
|
+
_(Sẽ được điền ở Step V-10)_
|
|
243
|
+
|
|
244
|
+
## 7. Unresolved Questions
|
|
245
|
+
|
|
246
|
+
_(Sẽ được điền ở Steps V-02 → V-09)_
|
|
247
|
+
|
|
248
|
+
## 8. Action Plan
|
|
249
|
+
|
|
250
|
+
_(Sẽ được điền ở Step V-10)_
|
|
251
|
+
|
|
252
|
+
## 9. Appendix: Full Scoring Matrix
|
|
253
|
+
|
|
254
|
+
_(Sẽ được điền ở Step V-10)_
|
|
255
|
+
```
|
|
256
|
+
|
|
257
|
+
---
|
|
258
|
+
|
|
259
|
+
## 5. Confirm & Route
|
|
260
|
+
|
|
261
|
+
Xuất cho user:
|
|
262
|
+
|
|
263
|
+
```
|
|
264
|
+
Scope: {scope}
|
|
265
|
+
Files: {count} file(s)
|
|
266
|
+
- {file list}
|
|
267
|
+
Cross-validate: PRD=auto, ADR=auto, Epics=auto (if exists), BRD=auto (if exists)
|
|
268
|
+
Report: .vsaf/docs/features/{feature-name}/05-srs-validation-report.md
|
|
269
|
+
Context: {output_folder}/_validation_temp/context.yaml ✓
|
|
270
|
+
UC Cache: {uc_count} UCs indexed ✓
|
|
271
|
+
Graph: {graph_json status}
|
|
272
|
+
|
|
273
|
+
[C] Continue — Bắt đầu validate Business Alignment (Step V-02)
|
|
274
|
+
[X] Cancel — Dừng lại
|
|
275
|
+
```
|
|
276
|
+
|
|
277
|
+
**Chờ user chọn.**
|
|
278
|
+
|
|
279
|
+
Khi user chọn **C** và `{parallel_mode}` là `true`: Hiển thị "Parallel validation mode: launching Round 1..." rồi follow **PARALLEL EXECUTION ROUNDS → Round 1** trong workflow.md
|
|
280
|
+
Khi user chọn **C** và `{parallel_mode}` là `false`: đọc fully và follow `./step-v-02-business-alignment.md` (sequential fallback)
|
|
@@ -0,0 +1,351 @@
|
|
|
1
|
+
---
|
|
2
|
+
# model: sonnet
|
|
3
|
+
# findingsOutput: '{output_folder}/_validation_temp/findings-business-alignment.yaml'
|
|
4
|
+
# contextFile: '{output_folder}/_validation_temp/context.yaml'
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Step V-02: Business Alignment — Validate mục tiêu kinh doanh
|
|
8
|
+
|
|
9
|
+
Weight: **1.2** (highest — foundation of the entire SRS)
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## 0. Load Context
|
|
14
|
+
Read `{contextFile}` → get `srs_path`, `kg.prd_key_sections`, `kg.brd_key_sections`. Use KG line ranges for all upstream document reads — do NOT read full PRD/BRD.
|
|
15
|
+
|
|
16
|
+
## 1. Problem Statement check
|
|
17
|
+
|
|
18
|
+
Kiểm tra mỗi SRS file:
|
|
19
|
+
|
|
20
|
+
- Có section mô tả **vấn đề cần giải quyết** (problem statement)?
|
|
21
|
+
- Problem statement rõ ràng: ai bị ảnh hưởng, ảnh hưởng như thế nào, tại sao cần giải quyết?
|
|
22
|
+
- Phân biệt được problem vs solution?
|
|
23
|
+
|
|
24
|
+
**Scoring:**
|
|
25
|
+
- Có rõ ràng, cụ thể → 1.0
|
|
26
|
+
- Có nhưng chung chung / generic → 0.5
|
|
27
|
+
- Chỉ có solution description, không có problem → 0.25
|
|
28
|
+
- Không có → 0.0
|
|
29
|
+
|
|
30
|
+
Item ID: `problem_statement_clear`
|
|
31
|
+
|
|
32
|
+
---
|
|
33
|
+
|
|
34
|
+
## 2. Business Goal & KPI check
|
|
35
|
+
|
|
36
|
+
Kiểm tra:
|
|
37
|
+
|
|
38
|
+
- Có **business goal** / mục tiêu kinh doanh cụ thể?
|
|
39
|
+
- Có **KPI hoặc success metrics** đo lường được?
|
|
40
|
+
- Ví dụ: conversion rate, revenue target, NPS, error reduction %, SLA
|
|
41
|
+
- Metrics có SMART (Specific, Measurable, Achievable, Relevant, Time-bound)?
|
|
42
|
+
|
|
43
|
+
**Scoring:**
|
|
44
|
+
- Goal + KPI + SMART → 1.0
|
|
45
|
+
- Goal + KPI nhưng không SMART → 0.75
|
|
46
|
+
- Có goal nhưng không KPI → 0.5
|
|
47
|
+
- Chỉ mention feature, không có goal/KPI → 0.25
|
|
48
|
+
- Không có → 0.0
|
|
49
|
+
|
|
50
|
+
Item ID: `business_goal_kpi_defined`
|
|
51
|
+
|
|
52
|
+
---
|
|
53
|
+
|
|
54
|
+
## 3. Scope Alignment check
|
|
55
|
+
|
|
56
|
+
Kiểm tra SRS scope có aligned với business goal:
|
|
57
|
+
|
|
58
|
+
- Features trong SRS có trực tiếp address business goal không?
|
|
59
|
+
- Có features nào vượt quá / không liên quan business goal? → scope creep risk
|
|
60
|
+
- Có features nào cần thiết nhưng bị thiếu để đạt goal?
|
|
61
|
+
|
|
62
|
+
**Scoring:**
|
|
63
|
+
- Fully aligned, không gap, không excess → 1.0
|
|
64
|
+
- Mostly aligned, minor mismatch → 0.75
|
|
65
|
+
- Partial alignment, some gaps hoặc excess → 0.5
|
|
66
|
+
- Misaligned — features không rõ liên quan đến goal → 0.25
|
|
67
|
+
- Không thể đánh giá vì không có goal → 0.0
|
|
68
|
+
|
|
69
|
+
Item ID: `scope_aligned_with_goal`
|
|
70
|
+
|
|
71
|
+
---
|
|
72
|
+
|
|
73
|
+
## 4. Out-of-Scope Clarity check
|
|
74
|
+
|
|
75
|
+
Kiểm tra:
|
|
76
|
+
|
|
77
|
+
- Có section **ngoài phạm vi** (out-of-scope) rõ ràng?
|
|
78
|
+
- Out-of-scope có liệt kê các items explicitly?
|
|
79
|
+
- Có ranh giới rõ với các FRs liên quan (để tránh assumption)?
|
|
80
|
+
|
|
81
|
+
**Scoring:**
|
|
82
|
+
- Có explicit out-of-scope list + boundary rõ → 1.0
|
|
83
|
+
- Có out-of-scope nhưng generic → 0.75
|
|
84
|
+
- Implied nhưng không explicit → 0.5
|
|
85
|
+
- Không có → 0.0
|
|
86
|
+
|
|
87
|
+
Item ID: `out_of_scope_defined`
|
|
88
|
+
|
|
89
|
+
---
|
|
90
|
+
|
|
91
|
+
## 5. Stakeholder & Context check
|
|
92
|
+
|
|
93
|
+
Kiểm tra:
|
|
94
|
+
|
|
95
|
+
- Ai là stakeholders chính? (PO, Business, Dev, Legal, Partner)
|
|
96
|
+
- Context về regulatory / compliance requirements liên quan?
|
|
97
|
+
- Dependencies với business processes khác?
|
|
98
|
+
|
|
99
|
+
**Scoring:**
|
|
100
|
+
- Đầy đủ stakeholders + context → 1.0
|
|
101
|
+
- Có stakeholders nhưng thiếu context → 0.75
|
|
102
|
+
- Chỉ có actors technical, thiếu business stakeholders → 0.5
|
|
103
|
+
- Không có → 0.0
|
|
104
|
+
|
|
105
|
+
Item ID: `stakeholder_context_defined`
|
|
106
|
+
|
|
107
|
+
---
|
|
108
|
+
|
|
109
|
+
## 6. Business Rule assumptions check
|
|
110
|
+
|
|
111
|
+
Kiểm tra mỗi Business Rule (BR) trong SRS:
|
|
112
|
+
|
|
113
|
+
- BR có ghi nguồn xác nhận rõ ràng: PRD AC, BRD, nghị định, hoặc PO sign-off?
|
|
114
|
+
- **Không chấp nhận**: BR được viết sẵn trong luồng nhưng file ghi "câu hỏi cần confirm", "cần PO xác nhận", "giả định tạm", hoặc tương đương — đây là CONTRADICTION: luồng đã cứng hoá một quyết định chưa được chốt.
|
|
115
|
+
- BR có assumption ngầm (implicit business decision) mà không được ghi nhận?
|
|
116
|
+
- VD: auto-cancel ngay sau grace period (không có final notice) — quyết định này từ đâu?
|
|
117
|
+
- VD: không cho gia hạn khi có claim đang mở — quyết định này ai confirm?
|
|
118
|
+
|
|
119
|
+
**Scoring:**
|
|
120
|
+
- Tất cả BR có nguồn xác nhận rõ ràng → 1.0
|
|
121
|
+
- Phần lớn có nguồn, 1-2 BR implicit nhưng low-risk → 0.75
|
|
122
|
+
- Nhiều BR implicit, hoặc 1+ BR contradicts stated open question → 0.25
|
|
123
|
+
- Luồng đã cứng hoá quyết định chưa được business confirm → 0.0 (CRITICAL)
|
|
124
|
+
|
|
125
|
+
Item ID: `br_assumptions_confirmed`
|
|
126
|
+
|
|
127
|
+
---
|
|
128
|
+
|
|
129
|
+
## 6b. PRD Business Goal Alignment (cross-validation via KG)
|
|
130
|
+
|
|
131
|
+
**Token-efficient:** Read PRD entity → find FR section line range → targeted read.
|
|
132
|
+
|
|
133
|
+
1. From KG: read PRD entity `key_sections` to find the FR section matching this SRS's FR ID
|
|
134
|
+
2. Targeted read: `Read(prd_path, offset=section_start, limit=section_end-section_start)`
|
|
135
|
+
3. Compare:
|
|
136
|
+
- SRS problem statement aligns with PRD FR description?
|
|
137
|
+
- SRS business goals/KPIs match PRD acceptance criteria for this FR?
|
|
138
|
+
- SRS scope matches PRD FR scope?
|
|
139
|
+
|
|
140
|
+
**Scoring:**
|
|
141
|
+
- Fully aligned with PRD → 1.0
|
|
142
|
+
- Minor misalignment → 0.75
|
|
143
|
+
- Significant gaps between SRS and PRD → 0.5
|
|
144
|
+
- Contradicts PRD → 0.25
|
|
145
|
+
- PRD has no matching FR → 0.0
|
|
146
|
+
|
|
147
|
+
Item ID: `prd_business_alignment`
|
|
148
|
+
|
|
149
|
+
## 6c. BRD Business Rule Coverage (cross-validation via KG)
|
|
150
|
+
|
|
151
|
+
**Token-efficient:** Read BRD entity → find FR section line range → targeted read.
|
|
152
|
+
|
|
153
|
+
1. From KG: read BRD entity `key_sections` to find the FR group matching this SRS's FR ID
|
|
154
|
+
2. Targeted read of BRD FR section
|
|
155
|
+
3. Compare:
|
|
156
|
+
- BRD business rules for this FR are reflected in SRS Business Rules section?
|
|
157
|
+
- BRD use case descriptions covered by SRS UCs?
|
|
158
|
+
- Any BRD requirement silently dropped in SRS?
|
|
159
|
+
|
|
160
|
+
**Scoring:**
|
|
161
|
+
- All BRD requirements covered → 1.0
|
|
162
|
+
- Most covered, minor gaps → 0.75
|
|
163
|
+
- Significant BRD requirements missing from SRS → 0.5
|
|
164
|
+
- Major BRD requirements not addressed → 0.25
|
|
165
|
+
- Cannot assess (BRD has no matching section) → 0.0
|
|
166
|
+
|
|
167
|
+
Item ID: `brd_business_rule_coverage`
|
|
168
|
+
|
|
169
|
+
## 6d. Scope Invention Check (derived-from rule)
|
|
170
|
+
|
|
171
|
+
Check if SRS scope EXCEEDS what PRD/BRD authorize:
|
|
172
|
+
|
|
173
|
+
1. List all SRS use cases and features
|
|
174
|
+
2. For each: can it be derived from PRD FR scope + BRD business requirements?
|
|
175
|
+
3. Flag any SRS content that appears to be invented (not in upstream sources):
|
|
176
|
+
- New actors not in PRD/BRD → CRITICAL
|
|
177
|
+
- New business flows not in PRD user journeys → CRITICAL
|
|
178
|
+
- Expanded scope beyond PRD FR boundaries → HIGH
|
|
179
|
+
|
|
180
|
+
Item ID: `scope_invention_check`
|
|
181
|
+
|
|
182
|
+
---
|
|
183
|
+
|
|
184
|
+
## 6f. Process Alignment — Current vs Future Process
|
|
185
|
+
|
|
186
|
+
Kiểm tra SRS có mô tả rõ sự chuyển đổi quy trình từ hiện tại sang tương lai:
|
|
187
|
+
|
|
188
|
+
- **AS-IS process**: SRS hoặc section phụ trợ có ghi nhận quy trình hiện tại (thủ công, tool cũ, pain point) không?
|
|
189
|
+
- **TO-BE process**: Flow mới trong SRS có giải quyết đúng pain point của AS-IS không?
|
|
190
|
+
- **Gap rõ ràng**: Sự khác biệt giữa AS-IS và TO-BE được phản ánh rõ trong scope + business rule không?
|
|
191
|
+
- **Stakeholder impact**: Người dùng hiện tại (ví dụ: nhân viên nghiệp vụ, agent) có quy trình thay đổi lớn nhưng SRS không mô tả transition plan / change impact?
|
|
192
|
+
|
|
193
|
+
**Không yêu cầu SRS phải có section riêng AS-IS/TO-BE.** Chỉ cần đảm bảo TO-BE flows phản ánh đúng bài toán thực tế, không viết trên giả định sai về trạng thái hiện tại.
|
|
194
|
+
|
|
195
|
+
**Dấu hiệu SAI:**
|
|
196
|
+
- SRS giả định flow đã hoàn toàn digital nhưng BRD ghi vẫn còn bước manual offline
|
|
197
|
+
- SRS bỏ qua bước hiện tại đang làm thủ công mà không nêu lý do
|
|
198
|
+
- TO-BE flow không address pain point nào được nêu trong BRD problem statement
|
|
199
|
+
|
|
200
|
+
**Scoring:**
|
|
201
|
+
- SRS phản ánh đúng TO-BE, có trace đến AS-IS pain points → 1.0
|
|
202
|
+
- TO-BE đúng nhưng không ghi rõ gap / change impact với AS-IS → 0.75
|
|
203
|
+
- TO-BE có chỗ giả định sai về quy trình hiện tại (minor) → 0.5
|
|
204
|
+
- TO-BE mâu thuẫn với AS-IS thực tế mô tả trong BRD → 0.25
|
|
205
|
+
- Không thể đánh giá (BRD không có mô tả quy trình hiện tại) → skip
|
|
206
|
+
|
|
207
|
+
Item ID: `process_alignment_current_future`
|
|
208
|
+
|
|
209
|
+
---
|
|
210
|
+
|
|
211
|
+
## 6e. Upstream Artifact Alignment (BRD/PRD vs SRS — general diff)
|
|
212
|
+
|
|
213
|
+
**Zero extra reads:** Reuses the BRD and PRD sections already loaded by 6b and 6c.
|
|
214
|
+
|
|
215
|
+
This check catches ANY structured artifact mismatch between upstream docs and SRS — not limited to state machines. It extracts all structured artifacts from both sides and runs a general diff.
|
|
216
|
+
|
|
217
|
+
#### Artifact Extraction Checklist
|
|
218
|
+
|
|
219
|
+
From the BRD and PRD sections already in context (loaded by 6b/6c), extract:
|
|
220
|
+
|
|
221
|
+
| # | Artifact Type | Extraction Method | SRS Counterpart |
|
|
222
|
+
|---|--------------|-------------------|-----------------|
|
|
223
|
+
| A1 | Entity status/lifecycle enum values | `entity_enum_values` pattern on BRD entity table | SRS Section 8 state diagram + entity tables |
|
|
224
|
+
| A2 | Entity field names (if in BRD/PRD only) | `entity_field_row` pattern on BRD entity table | SRS flow table "Bảng/Thực thể" column (no ERD in SRS) |
|
|
225
|
+
| A3 | State transitions + ordering | `plantuml_state` + `state_transition` patterns on BRD state diagram | SRS Section 8 PlantUML |
|
|
226
|
+
| A4 | Actor/role names | `actor_name_in_table` pattern on BRD requirement tables | SRS UC actor columns |
|
|
227
|
+
| A5 | Phase assignments (MVP/1.5/2) | `phase_assignment` pattern on BRD/PRD FR table | SRS scope section |
|
|
228
|
+
| A6 | Status names embedded in PRD ACs | `state_chain` pattern on PRD AC section | SRS canonical state names |
|
|
229
|
+
| A7 | Business rule references | BR-xxx pattern on BRD requirements | SRS Section 5 BR table |
|
|
230
|
+
| A8 | Vietnamese state flow text | `state_flow_text` pattern on BRD business reqs | SRS state diagram (translated) |
|
|
231
|
+
|
|
232
|
+
**Not all artifact types will be present for every FR.** Extract what's available; skip what's not.
|
|
233
|
+
|
|
234
|
+
#### Diff Algorithm
|
|
235
|
+
|
|
236
|
+
For each artifact type found in BOTH upstream and SRS:
|
|
237
|
+
|
|
238
|
+
1. **Build two lists:** `upstream_values` and `srs_values`
|
|
239
|
+
2. **Compute diff:**
|
|
240
|
+
- **Additions** (in SRS but not upstream): may be legitimate decomposition or invention
|
|
241
|
+
- **Removals** (in upstream but not SRS): may be a silent drop or intentional scope reduction
|
|
242
|
+
- **Renames** (same position/semantics, different name): naming inconsistency
|
|
243
|
+
- **Reorderings** (same items, different sequence): transition order conflict
|
|
244
|
+
- **Type mismatches** (same field name, different data type): technical inconsistency
|
|
245
|
+
|
|
246
|
+
3. **Severity assignment** (LLM judgment per diff item):
|
|
247
|
+
- Removal of upstream-defined item with no SRS note → **CRITICAL** (silent drop)
|
|
248
|
+
- Addition in SRS with no upstream source → **HIGH** (invention — cross-ref with 6d)
|
|
249
|
+
- Name mismatch for same concept → **HIGH** (causes Dev/QA confusion)
|
|
250
|
+
- Transition order reversal → **HIGH** (changes business logic)
|
|
251
|
+
- Data type mismatch → **HIGH** (runtime bugs)
|
|
252
|
+
- Legitimate decomposition (1 upstream → N SRS) documented in SRS → **LOW**
|
|
253
|
+
- Phase assignment difference → **MEDIUM** (planning confusion)
|
|
254
|
+
- Actor name variant for same role → **MEDIUM**
|
|
255
|
+
|
|
256
|
+
#### What NOT to flag
|
|
257
|
+
|
|
258
|
+
- SRS naturally has more detail than BRD/PRD — more fields, more states, more transitions is expected
|
|
259
|
+
- Only flag when SRS CONTRADICTS, DROPS, or RENAMES without documentation
|
|
260
|
+
- PRD is user-facing; SRS has internal states — SRS having states not in PRD is normal
|
|
261
|
+
|
|
262
|
+
**Scoring:**
|
|
263
|
+
- All upstream artifacts traceable in SRS, no contradictions → 1.0
|
|
264
|
+
- Minor: 1-2 naming variants, documented decompositions → 0.75
|
|
265
|
+
- Significant: undocumented additions/renames, or type mismatches → 0.5
|
|
266
|
+
- Major: silently dropped upstream items or transition order conflicts → 0.25
|
|
267
|
+
- Fundamental contradictions (SRS says X, BRD says not-X) → 0.0
|
|
268
|
+
|
|
269
|
+
Item ID: `upstream_artifact_alignment`
|
|
270
|
+
|
|
271
|
+
---
|
|
272
|
+
|
|
273
|
+
## 7. Ghi findings
|
|
274
|
+
|
|
275
|
+
```markdown
|
|
276
|
+
| # | Severity | Dimension | File | Item ID | Score | Evidence | Suggestion | Business Impact | Source |
|
|
277
|
+
```
|
|
278
|
+
|
|
279
|
+
Each finding MUST include `business_impact` with three sub-fields:
|
|
280
|
+
- **WHO**: Primary stakeholder affected (Dev, QA, PO, Ops, Customer)
|
|
281
|
+
- **WHAT**: Impact type (Blocked, Rework risk, UX degradation, Compliance risk)
|
|
282
|
+
- **WHEN**: When impact materializes (Before Sprint, During Sprint, After Release)
|
|
283
|
+
|
|
284
|
+
Scoring scale: 1.0 / 0.75 / 0.5 / 0.25 / 0.0
|
|
285
|
+
|
|
286
|
+
---
|
|
287
|
+
|
|
288
|
+
## 8. Tính Business Alignment dimension score
|
|
289
|
+
|
|
290
|
+
```
|
|
291
|
+
business_alignment_score = round(sum(item_scores.values()) / 11 × 100, 1)
|
|
292
|
+
```
|
|
293
|
+
|
|
294
|
+
Canonical item IDs (N = 11, fixed):
|
|
295
|
+
`problem_statement_clear`, `business_goal_kpi_defined`, `scope_aligned_with_goal`, `out_of_scope_defined`, `stakeholder_context_defined`, `br_assumptions_confirmed`, `prd_business_alignment`, `brd_business_rule_coverage`, `scope_invention_check`, `process_alignment_current_future`, `upstream_artifact_alignment`
|
|
296
|
+
|
|
297
|
+
⚠️ MANDATORY: N = 11 (fixed). N/A items → score = 1.0 (do not skip from denominator). No post-hoc calibration. dimension_score in YAML = formula result only.
|
|
298
|
+
|
|
299
|
+
Weight: **1.2**
|
|
300
|
+
|
|
301
|
+
---
|
|
302
|
+
|
|
303
|
+
## 9. Append findings vào report
|
|
304
|
+
|
|
305
|
+
Append CRITICAL/HIGH → section "4. Critical & High Findings".
|
|
306
|
+
Append MEDIUM/LOW → section "5. Medium & Low Findings".
|
|
307
|
+
|
|
308
|
+
Update frontmatter: thêm `step-v-02-business-alignment` vào `stepsCompleted`.
|
|
309
|
+
|
|
310
|
+
---
|
|
311
|
+
|
|
312
|
+
## [NEW] Write Structured Findings
|
|
313
|
+
Write `{findingsOutput}`:
|
|
314
|
+
```yaml
|
|
315
|
+
dimension: business_alignment
|
|
316
|
+
weight: 1.2
|
|
317
|
+
dimension_score: 0 # = round(sum(item_scores.values()) / 11 × 100, 1)
|
|
318
|
+
status: OK
|
|
319
|
+
findings: []
|
|
320
|
+
summary: {total: 0, critical: 0, high: 0, medium: 0, low: 0}
|
|
321
|
+
item_scores:
|
|
322
|
+
problem_statement_clear: 0.0
|
|
323
|
+
business_goal_kpi_defined: 0.0
|
|
324
|
+
scope_aligned_with_goal: 0.0
|
|
325
|
+
out_of_scope_defined: 0.0
|
|
326
|
+
stakeholder_context_defined: 0.0
|
|
327
|
+
br_assumptions_confirmed: 0.0
|
|
328
|
+
prd_business_alignment: 0.0
|
|
329
|
+
brd_business_rule_coverage: 0.0
|
|
330
|
+
scope_invention_check: 0.0
|
|
331
|
+
process_alignment_current_future: 0.0
|
|
332
|
+
upstream_artifact_alignment: 0.0
|
|
333
|
+
```
|
|
334
|
+
|
|
335
|
+
## 10. Menu
|
|
336
|
+
|
|
337
|
+
```
|
|
338
|
+
Business Alignment Score: {X}% ({status}) [weight 1.2]
|
|
339
|
+
- CRITICAL: {count}
|
|
340
|
+
- HIGH: {count}
|
|
341
|
+
- MEDIUM: {count}
|
|
342
|
+
- LOW: {count}
|
|
343
|
+
|
|
344
|
+
[C] Continue — Sang Completeness (Step V-03)
|
|
345
|
+
[D] Detail — Xem chi tiết findings
|
|
346
|
+
[X] Cancel
|
|
347
|
+
```
|
|
348
|
+
|
|
349
|
+
**Chờ user chọn.**
|
|
350
|
+
|
|
351
|
+
Khi user chọn **C**: đọc fully và follow `./step-v-03-completeness.md`
|