adspecs 0.1.34 → 0.1.36
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/.adspecs/templates/02-/344/272/247/345/223/201/351/234/200/346/261/202/350/257/264/346/230/216/344/271/246/346/250/241/346/235/277.md +784 -626
- package/.claude-plugin/marketplace.json +1 -1
- package/.claude-plugin/plugin.json +1 -1
- package/.codebuddy-plugin/plugin.json +1 -1
- package/.qoder-plugin/plugin.json +1 -1
- package/.workbuddy-plugin/plugin.json +1 -1
- package/package.json +1 -1
- package/skills/adspecs-adversarial-review/SKILL.md +1 -1
- package/skills/adspecs-analyze/SKILL.md +564 -574
- package/skills/adspecs-prd/SKILL.md +98 -19
|
@@ -1,627 +1,785 @@
|
|
|
1
|
-
# 产品需求说明书模板
|
|
2
|
-
|
|
3
|
-
> **版本**: v2.3
|
|
4
|
-
> **创建日期**: 2026-03-16
|
|
5
|
-
> **修订日期**: 2026-07-14（根据 P05-01 原辅材料仓库 PRD 落地实践对齐修正：新增 PRD 文档头格式、BR 编号改为写在规则标题后括号内、功能编号改用模块编号体系 P{模块}-{子模块}-{序号}、验收场景改为单行 Given-When-Then 格式、状态机补充状态说明表与单据状态图、§4.1 表头精简、数据权限补充数据隔离维度、修复架构文档引用路径）; 2026-07-07（新增 §10 风险与待确认问题章节，原 §10 变更记录顺延为 §11）; 2026-07-03（结构优化：§4 编号扁平化、§3.4 改用 Mermaid 状态图、扩充非功能需求 §6.2、新增 §8-§10 术语表/假设与约束/变更记录、增强 §7.3
|
|
6
|
-
> **适用人员**: 产品经理、需求分析师、业务方
|
|
7
|
-
> **目的**: 清晰、准确地表达用户需求，便于AI进行后续的需求分析、设计、编码、测试工作。本模板的结构设计支撑全链路需求追溯体系。
|
|
8
|
-
|
|
9
|
-
---
|
|
10
|
-
|
|
11
|
-
## 全链路ID体系约定
|
|
12
|
-
|
|
13
|
-
本模板的各章节与全链路需求 ID 体系的映射关系如下：
|
|
14
|
-
|
|
15
|
-
| 模板章节
|
|
16
|
-
|
|
|
17
|
-
| §2.1 用户故事
|
|
18
|
-
| §2.1 验收场景
|
|
19
|
-
| §3.
|
|
20
|
-
| §
|
|
21
|
-
| §
|
|
22
|
-
| §
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
##
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
[
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
[
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
-
|
|
118
|
-
|
|
119
|
-
|
|
120
|
-
|
|
121
|
-
|
|
122
|
-
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
1. `US-01
|
|
126
|
-
|
|
127
|
-
|
|
128
|
-
|
|
129
|
-
|
|
130
|
-
|
|
131
|
-
|
|
132
|
-
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
-
|
|
136
|
-
|
|
137
|
-
-
|
|
138
|
-
|
|
139
|
-
-
|
|
140
|
-
|
|
141
|
-
|
|
142
|
-
|
|
143
|
-
1. `US-02
|
|
144
|
-
|
|
145
|
-
|
|
146
|
-
|
|
147
|
-
|
|
148
|
-
|
|
149
|
-
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
-
|
|
154
|
-
|
|
155
|
-
-
|
|
156
|
-
|
|
157
|
-
|
|
158
|
-
|
|
159
|
-
1. `US-03
|
|
160
|
-
|
|
161
|
-
|
|
162
|
-
|
|
163
|
-
|
|
164
|
-
|
|
165
|
-
[
|
|
166
|
-
|
|
167
|
-
|
|
168
|
-
|
|
169
|
-
|
|
170
|
-
|
|
171
|
-
|
|
172
|
-
|
|
173
|
-
|
|
174
|
-
|
|
175
|
-
|
|
176
|
-
|
|
177
|
-
|
|
178
|
-
|
|
179
|
-
|
|
180
|
-
|
|
181
|
-
|
|
182
|
-
|
|
183
|
-
|
|
184
|
-
|
|
185
|
-
|
|
186
|
-
|
|
187
|
-
|
|
188
|
-
|
|
189
|
-
|
|
190
|
-
|
|
191
|
-
|
|
192
|
-
|
|
193
|
-
|
|
194
|
-
|
|
195
|
-
|
|
196
|
-
|
|
197
|
-
|
|
198
|
-
|
|
199
|
-
|
|
200
|
-
|
|
201
|
-
|
|
202
|
-
|
|
203
|
-
|
|
204
|
-
|
|
205
|
-
-
|
|
206
|
-
-
|
|
207
|
-
-
|
|
208
|
-
-
|
|
209
|
-
|
|
210
|
-
|
|
211
|
-
|
|
212
|
-
|
|
213
|
-
|
|
214
|
-
|
|
215
|
-
|
|
216
|
-
|
|
217
|
-
|
|
218
|
-
|
|
219
|
-
|
|
220
|
-
|
|
221
|
-
|
|
222
|
-
|
|
223
|
-
|
|
224
|
-
|
|
225
|
-
|
|
226
|
-
-
|
|
227
|
-
-
|
|
228
|
-
|
|
229
|
-
|
|
230
|
-
|
|
231
|
-
|
|
232
|
-
|
|
233
|
-
|
|
234
|
-
|
|
235
|
-
|
|
236
|
-
|
|
237
|
-
|
|
238
|
-
|
|
239
|
-
|
|
240
|
-
|
|
241
|
-
|
|
242
|
-
|
|
243
|
-
|
|
244
|
-
|
|
245
|
-
|
|
246
|
-
|
|
247
|
-
|
|
248
|
-
|
|
249
|
-
|
|
250
|
-
|
|
251
|
-
|
|
252
|
-
|
|
253
|
-
|
|
254
|
-
|
|
255
|
-
|
|
256
|
-
|
|
257
|
-
|
|
258
|
-
|
|
259
|
-
|
|
260
|
-
|
|
261
|
-
|
|
262
|
-
|
|
263
|
-
|
|
264
|
-
|
|
265
|
-
|
|
266
|
-
|
|
267
|
-
|
|
268
|
-
|
|
269
|
-
|
|
270
|
-
|
|
271
|
-
|
|
272
|
-
|
|
273
|
-
|
|
274
|
-
|
|
275
|
-
|
|
276
|
-
|
|
277
|
-
|
|
278
|
-
|
|
279
|
-
|
|
280
|
-
|
|
281
|
-
|
|
282
|
-
|
|
283
|
-
|
|
284
|
-
|
|
285
|
-
|
|
286
|
-
|
|
287
|
-
|
|
288
|
-
|
|
289
|
-
|
|
290
|
-
|
|
291
|
-
|
|
292
|
-
|
|
293
|
-
|
|
294
|
-
|
|
295
|
-
|
|
296
|
-
|
|
297
|
-
|
|
298
|
-
|
|
299
|
-
|
|
300
|
-
|
|
301
|
-
|
|
302
|
-
|
|
303
|
-
|
|
304
|
-
|
|
305
|
-
|
|
306
|
-
|
|
307
|
-
|
|
308
|
-
|
|
309
|
-
|
|
310
|
-
|
|
311
|
-
|
|
312
|
-
|
|
313
|
-
|
|
314
|
-
|
|
315
|
-
|
|
316
|
-
|
|
317
|
-
|
|
318
|
-
|
|
319
|
-
|
|
320
|
-
|
|
321
|
-
|
|
322
|
-
|
|
323
|
-
|
|
324
|
-
|
|
325
|
-
|
|
326
|
-
|
|
327
|
-
|
|
328
|
-
|
|
329
|
-
|
|
330
|
-
|
|
331
|
-
|
|
332
|
-
|
|
333
|
-
|
|
334
|
-
|
|
335
|
-
|
|
336
|
-
|
|
337
|
-
|
|
338
|
-
|
|
339
|
-
|
|
340
|
-
|
|
341
|
-
|
|
342
|
-
|
|
343
|
-
|
|
344
|
-
|
|
345
|
-
|
|
346
|
-
|
|
347
|
-
|
|
348
|
-
|
|
349
|
-
|
|
350
|
-
|
|
351
|
-
|
|
352
|
-
|
|
353
|
-
|
|
354
|
-
|
|
355
|
-
|
|
356
|
-
|
|
357
|
-
|
|
358
|
-
|
|
359
|
-
|
|
360
|
-
|
|
361
|
-
|
|
362
|
-
|
|
363
|
-
|
|
364
|
-
|
|
365
|
-
|
|
366
|
-
|
|
367
|
-
|
|
368
|
-
|
|
369
|
-
|
|
370
|
-
|
|
371
|
-
-
|
|
372
|
-
|
|
373
|
-
|
|
374
|
-
|
|
375
|
-
|
|
376
|
-
|
|
377
|
-
|
|
378
|
-
|
|
379
|
-
|
|
380
|
-
|
|
381
|
-
|
|
382
|
-
|
|
383
|
-
|
|
384
|
-
|
|
385
|
-
|
|
386
|
-
|
|
387
|
-
|
|
388
|
-
|
|
389
|
-
|
|
390
|
-
|
|
391
|
-
|
|
392
|
-
|
|
393
|
-
|
|
394
|
-
|
|
395
|
-
|
|
396
|
-
|
|
397
|
-
|
|
398
|
-
|
|
399
|
-
|
|
400
|
-
|
|
401
|
-
|
|
402
|
-
|
|
403
|
-
|
|
404
|
-
|
|
405
|
-
|
|
406
|
-
|
|
407
|
-
|
|
408
|
-
|
|
409
|
-
|
|
410
|
-
|
|
411
|
-
|
|
412
|
-
|
|
413
|
-
|
|
414
|
-
|
|
415
|
-
|
|
416
|
-
|
|
417
|
-
|
|
418
|
-
|
|
419
|
-
|
|
420
|
-
|
|
421
|
-
|
|
422
|
-
|
|
423
|
-
|
|
424
|
-
|
|
425
|
-
|
|
426
|
-
|
|
427
|
-
|
|
428
|
-
|
|
429
|
-
|
|
430
|
-
-
|
|
431
|
-
-
|
|
432
|
-
|
|
433
|
-
|
|
434
|
-
|
|
435
|
-
|
|
436
|
-
|
|
437
|
-
|
|
438
|
-
|
|
439
|
-
|
|
440
|
-
|
|
441
|
-
|
|
442
|
-
|
|
443
|
-
|
|
444
|
-
|
|
445
|
-
|
|
446
|
-
|
|
447
|
-
|
|
448
|
-
|
|
449
|
-
|
|
450
|
-
|
|
451
|
-
|
|
452
|
-
|
|
453
|
-
|
|
454
|
-
|
|
455
|
-
|
|
456
|
-
|
|
457
|
-
-
|
|
458
|
-
|
|
459
|
-
|
|
460
|
-
-
|
|
461
|
-
|
|
462
|
-
|
|
463
|
-
-
|
|
464
|
-
-
|
|
465
|
-
|
|
466
|
-
|
|
467
|
-
-
|
|
468
|
-
|
|
469
|
-
|
|
470
|
-
|
|
471
|
-
|
|
472
|
-
|
|
473
|
-
|
|
474
|
-
|
|
475
|
-
|
|
476
|
-
|
|
477
|
-
|
|
478
|
-
|
|
479
|
-
|
|
480
|
-
|
|
481
|
-
|
|
482
|
-
|
|
483
|
-
|
|
484
|
-
|
|
485
|
-
|
|
486
|
-
|
|
487
|
-
|
|
488
|
-
|
|
489
|
-
|
|
490
|
-
|
|
491
|
-
|
|
492
|
-
|
|
493
|
-
|
|
494
|
-
|
|
495
|
-
|
|
496
|
-
|
|
497
|
-
|
|
498
|
-
|
|
499
|
-
|
|
500
|
-
|
|
501
|
-
|
|
502
|
-
|
|
503
|
-
|
|
504
|
-
|
|
505
|
-
|
|
506
|
-
|
|
507
|
-
|
|
508
|
-
|
|
509
|
-
|
|
510
|
-
|
|
511
|
-
|
|
512
|
-
|
|
513
|
-
|
|
514
|
-
|
|
515
|
-
|
|
516
|
-
|
|
517
|
-
|
|
518
|
-
|
|
519
|
-
|
|
520
|
-
|
|
|
521
|
-
|
|
522
|
-
|
|
523
|
-
|
|
524
|
-
|
|
525
|
-
|
|
526
|
-
-
|
|
527
|
-
|
|
528
|
-
|
|
529
|
-
|
|
530
|
-
|
|
531
|
-
|
|
532
|
-
|
|
533
|
-
|
|
534
|
-
|
|
535
|
-
|
|
536
|
-
|
|
537
|
-
|
|
538
|
-
|
|
539
|
-
|
|
540
|
-
|
|
541
|
-
|
|
542
|
-
|
|
543
|
-
|
|
544
|
-
|
|
545
|
-
|
|
546
|
-
|
|
547
|
-
|
|
548
|
-
```
|
|
549
|
-
|
|
550
|
-
|
|
551
|
-
|
|
552
|
-
|
|
553
|
-
|
|
554
|
-
|
|
555
|
-
|
|
556
|
-
|
|
557
|
-
|
|
558
|
-
|
|
559
|
-
|
|
560
|
-
|
|
561
|
-
|
|
562
|
-
|
|
563
|
-
|
|
564
|
-
|
|
565
|
-
|
|
566
|
-
|
|
567
|
-
|
|
568
|
-
|
|
569
|
-
|
|
570
|
-
|
|
571
|
-
###
|
|
572
|
-
|
|
573
|
-
|
|
574
|
-
|
|
575
|
-
|
|
576
|
-
|
|
577
|
-
|
|
578
|
-
|
|
579
|
-
|
|
580
|
-
|
|
581
|
-
|
|
582
|
-
|
|
583
|
-
|
|
584
|
-
|
|
585
|
-
|
|
586
|
-
|
|
587
|
-
|
|
588
|
-
|
|
589
|
-
|
|
590
|
-
|
|
591
|
-
|
|
592
|
-
|
|
593
|
-
|
|
594
|
-
|
|
595
|
-
|
|
596
|
-
|
|
597
|
-
|
|
598
|
-
|
|
599
|
-
|
|
600
|
-
|
|
601
|
-
|
|
602
|
-
|
|
603
|
-
|
|
604
|
-
|
|
605
|
-
|
|
606
|
-
|
|
607
|
-
```
|
|
608
|
-
|
|
609
|
-
|
|
610
|
-
|
|
611
|
-
|
|
612
|
-
|
|
613
|
-
|
|
614
|
-
|
|
615
|
-
|
|
616
|
-
|
|
617
|
-
|
|
618
|
-
|
|
619
|
-
|
|
620
|
-
|
|
621
|
-
|
|
622
|
-
|
|
623
|
-
|
|
624
|
-
|
|
625
|
-
|
|
626
|
-
|
|
1
|
+
# 产品需求说明书模板
|
|
2
|
+
|
|
3
|
+
> **版本**: v2.3
|
|
4
|
+
> **创建日期**: 2026-03-16
|
|
5
|
+
> **修订日期**: 2026-07-14（根据 P05-01 原辅材料仓库 PRD 落地实践对齐修正：新增 PRD 文档头格式、BR 编号改为写在规则标题后括号内、功能编号改用模块编号体系 P{模块}-{子模块}-{序号}、验收场景改为单行 Given-When-Then 格式、状态机补充状态说明表与单据状态图、§4.1 表头精简、数据权限补充数据隔离维度、修复架构文档引用路径）; 2026-07-07（新增 §10 风险与待确认问题章节，原 §10 变更记录顺延为 §11）; 2026-07-03（结构优化：§4 编号扁平化、§3.4 改用 Mermaid 状态图、扩充非功能需求 §6.2、新增 §8-§10 术语表/假设与约束/变更记录、增强 §7.3 接口细节、修复文字错误）; 2026-09-01（第5部分业务对象说明章节融合《02-软件需求文档标准规范》第三部分业务对象说明；全链路ID体系表新增 OBJ 编号并规整对齐；修正章节编号：参考资料内部小节 7.x→8.x，术语表/假设与约束/风险与待确认问题/变更记录顺延为第9~12部分）
|
|
6
|
+
> **适用人员**: 产品经理、需求分析师、业务方
|
|
7
|
+
> **目的**: 清晰、准确地表达用户需求，便于AI进行后续的需求分析、设计、编码、测试工作。本模板的结构设计支撑全链路需求追溯体系。
|
|
8
|
+
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
## 全链路ID体系约定
|
|
12
|
+
|
|
13
|
+
本模板的各章节与全链路需求 ID 体系的映射关系如下：
|
|
14
|
+
|
|
15
|
+
| 模板章节 | 章节编号 | 对应需求 ID 前缀 | ID 示例 | 赋予阶段 |
|
|
16
|
+
| ------------------- | ------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | -------------------------------- | ----------------------------- |
|
|
17
|
+
| §2.1 用户故事 | 2.1.x | `US-{n}`（写在PRD章节号后） | `US-01` | PRD 编写阶段由AI自动赋予 |
|
|
18
|
+
| §2.1 验收场景 | 每个故事下编号条目 `US-{n}-AC{n}` | `US-{n}-AC{n}` | `US-01-AC1` | PRD 编写阶段由AI自动赋予 |
|
|
19
|
+
| §3.1 业务场景和流程 | 3.1.x 每个流程编号 | PROC-{业务域缩写}-{三位序号} | PROC-CON-001（合同履约回款流程） | PRD 编写阶段由AI自动赋予 |
|
|
20
|
+
| §3.2 业务规则 | 3.2.x | `BR-{n}`（写在规则标题后括号内，如 `规则1: 到货必检制度 (BR-01)`；引用全局业务规则库时编号可不连续） | `BR-01` | PRD 编写阶段由AI自动赋予 |
|
|
21
|
+
| §4.1 功能清单 | P{模块}-{子模块}-{序号}（三级编号深度优先递增，如 P05-01-01） | `FUNC-{n}` | `FUNC-01` | 需求分析阶段 AI 自动映射 |
|
|
22
|
+
| §5.1 业务对象 | 5.1.x | `OBJ-{业务域缩写}-{三位序号}` | `OBJ-CON-001（合同）` | PRD 编写阶段由AI自动赋予 |
|
|
23
|
+
| §6.1 权限矩阵 | 每行一个权限项 | `PERM-{n}` | `PERM-01` | 需求分析阶段 AI 自动赋予 |
|
|
24
|
+
| §7.1 验收标准 | 7.1.x（归约到 US/BR，不设独立 ID） | — | — | 验收标准中填写关联的 US/BR ID |
|
|
25
|
+
|
|
26
|
+
> **重要**：`US-{n}` 、 `BR-{n}` 、`PROC-{业务域缩写}-{三位序号}` 、`FUNC-{n}` 、 `OBJ-{业务域缩写}-{三位序号}` 和 `PERM-{n}` 由 AI 在需求分析阶段自动赋予。
|
|
27
|
+
|
|
28
|
+
---
|
|
29
|
+
|
|
30
|
+
## 📝 使用说明
|
|
31
|
+
|
|
32
|
+
本模板旨在帮助需求分析师或产品经理**快速、准确地表达用户需求**。填写本模板后，AI将自动完成以下工作：
|
|
33
|
+
|
|
34
|
+
1. **需求分析** - 提取业务实体、实体关系、核心业务规则（OOA），根据已有的 US/BR 编号记录 ID 映射表
|
|
35
|
+
2. **系统设计** - 设计类结构、数据模型、接口设计（OOD）
|
|
36
|
+
3. **编码实现** - 生成符合规范的代码（OOP）
|
|
37
|
+
4. **测试设计** - 设计测试用例和测试场景
|
|
38
|
+
|
|
39
|
+
## 流程图输出要求
|
|
40
|
+
|
|
41
|
+
本规范中所有流程图，无论是端到端流程、审批流，还是后续业务功能中的分支逻辑示意，**一律使用 Mermaid 源代码格式输出**，不使用图片、不使用其他绘图工具的专有格式。常用图表类型：
|
|
42
|
+
|
|
43
|
+
- 顺序流程、分支判断：`flowchart TD`
|
|
44
|
+
- 审批流转：`flowchart TD` 配合菱形判断节点
|
|
45
|
+
- 跨角色协作时序：`sequenceDiagram`（可选，用于强调角色间交互顺序时使用）
|
|
46
|
+
|
|
47
|
+
---
|
|
48
|
+
|
|
49
|
+
## 🎯 模板结构
|
|
50
|
+
|
|
51
|
+
### 第1部分：需求概览
|
|
52
|
+
|
|
53
|
+
```markdown
|
|
54
|
+
# 产品需求说明书 — [模块编号] [模块名称]
|
|
55
|
+
|
|
56
|
+
> **版本**: v1.0
|
|
57
|
+
> **创建日期**: [DATE]
|
|
58
|
+
> **修订日期**: [DATE]（[修订说明]）
|
|
59
|
+
> **所属模块**: [如：P05 仓储物流管理 → P05-01 原辅材料仓库管理]
|
|
60
|
+
> **数据标准**: [如：ISA-95]（如适用）
|
|
61
|
+
|
|
62
|
+
---
|
|
63
|
+
|
|
64
|
+
## 1. 需求概览
|
|
65
|
+
|
|
66
|
+
### 1.1 基本信息
|
|
67
|
+
- **需求名称**: [简短描述需求的名称]
|
|
68
|
+
- **需求编号**: [如：REQ-P05-01-001]
|
|
69
|
+
- **所属模块**: [如：仓储物流管理 — 原辅材料仓库]
|
|
70
|
+
- **需求来源**: [产品经理/业务方/客户]
|
|
71
|
+
- **创建日期**: [DATE]
|
|
72
|
+
- **优先级**: [P0/P1/P2/P3]
|
|
73
|
+
|
|
74
|
+
### 1.2 需求背景
|
|
75
|
+
#### 1.2.1 为什么需要这个需求？
|
|
76
|
+
|
|
77
|
+
[用1-3句话描述当前的业务痛点或问题]
|
|
78
|
+
|
|
79
|
+
#### 1.2.2 期望达到什么目标？
|
|
80
|
+
|
|
81
|
+
[用1-2句话描述期望达成的业务目标]
|
|
82
|
+
|
|
83
|
+
### 1.3 需求范围
|
|
84
|
+
#### 1.3.1 包含哪些功能？
|
|
85
|
+
|
|
86
|
+
[列出该需求包含的主要功能点，用逗号分隔]
|
|
87
|
+
|
|
88
|
+
#### 1.3.2 不包含哪些功能？
|
|
89
|
+
|
|
90
|
+
[明确说明该需求不包含的内容，建议逐条列出并标注归属模块，如：库位盘点执行（P05-05，本模块仅触发盘点需求）]
|
|
91
|
+
|
|
92
|
+
### 1.4 涉及角色
|
|
93
|
+
**谁会使用这个功能？**
|
|
94
|
+
|
|
95
|
+
- [角色1]: [描述该角色]
|
|
96
|
+
- [角色2]: [描述该角色]
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
---
|
|
100
|
+
|
|
101
|
+
### 第2部分：用户故事
|
|
102
|
+
|
|
103
|
+
<!--
|
|
104
|
+
重要提示：用户故事应按照用户旅程的重要性进行优先排序。
|
|
105
|
+
每个用户故事/旅程都必须是可独立测试的——这意味着如果你只实现其中一个，
|
|
106
|
+
你仍然应该有一个可行的最小可行产品（MVP），它能提供价值。
|
|
107
|
+
为每个故事分配优先级（P1、P2、P3等），其中P1为最高优先级。
|
|
108
|
+
将每个故事视为一个独立的功能模块，它们可以是：
|
|
109
|
+
- 独立开发
|
|
110
|
+
- 独立测试
|
|
111
|
+
- 独立部署
|
|
112
|
+
- 独立向用户演示
|
|
113
|
+
|
|
114
|
+
ID 体系说明：每个用户故事标题含唯一 ID（如 `US-01`），
|
|
115
|
+
故事下的每个验收场景条目包含唯一 ID（如 `US-01-AC1`）。
|
|
116
|
+
验收场景必须拆分为独立的 Given-When-Then 编号条目，采用单行格式：
|
|
117
|
+
`US-{n}-AC{n}` **[场景标题]**: **Given** [初始状态]，**When** [操作]，**Then** [预期结果]
|
|
118
|
+
-->
|
|
119
|
+
|
|
120
|
+
```markdown
|
|
121
|
+
## 2. 用户故事
|
|
122
|
+
|
|
123
|
+
### 2.1 核心用户故事
|
|
124
|
+
|
|
125
|
+
#### 2.1.1 `US-01` 用户故事 — [简短标题]（优先级：P1）
|
|
126
|
+
|
|
127
|
+
- **故事描述**: 作为[角色]，我想要[功能]，以便于[价值]
|
|
128
|
+
- **为何赋予此优先级**：[阐述其价值及为何赋予此优先级]
|
|
129
|
+
- **独立测试**：[描述如何独立进行测试 - 例如，”可以通过[具体操作]进行全面测试，并实现[具体价值]”]
|
|
130
|
+
- **前置条件**: [使用这个功能前需要满足的条件]
|
|
131
|
+
- **后置条件**: [使用这个功能后应该达到的状态]
|
|
132
|
+
|
|
133
|
+
**验收场景**：
|
|
134
|
+
|
|
135
|
+
1. `US-01-AC1` **[场景标题（如"正常到货登记"）]**: **Given** [初始状态]，**When** [操作]，**Then** [预期结果]
|
|
136
|
+
|
|
137
|
+
2. `US-01-AC2` **[场景标题（如"参数偏差告警"）]**: **Given** [初始状态]，**When** [操作]，**Then** [预期结果]
|
|
138
|
+
|
|
139
|
+
3. `US-01-AC3` **[场景标题]**（可选，按需增加）: **Given** [初始状态]，**When** [操作]，**Then** [预期结果]
|
|
140
|
+
|
|
141
|
+
---
|
|
142
|
+
|
|
143
|
+
#### 2.1.2 `US-02` 用户故事 — [简短标题]（优先级：P1）
|
|
144
|
+
|
|
145
|
+
- **故事描述**: 作为[角色]，我想要[功能]，以便于[价值]
|
|
146
|
+
- **为何赋予此优先级**：[阐述]
|
|
147
|
+
- **独立测试**：[描述]
|
|
148
|
+
- **前置条件**: [条件]
|
|
149
|
+
- **后置条件**: [状态]
|
|
150
|
+
|
|
151
|
+
**验收场景**：
|
|
152
|
+
|
|
153
|
+
1. `US-02-AC1` **[场景标题]**: **Given** [初始状态]，**When** [操作]，**Then** [预期结果]
|
|
154
|
+
|
|
155
|
+
2. `US-02-AC2` **[场景标题]**: **Given** [初始状态]，**When** [操作]，**Then** [预期结果]
|
|
156
|
+
|
|
157
|
+
---
|
|
158
|
+
|
|
159
|
+
#### 2.1.3 `US-03` 用户故事 — [简短标题]（优先级：P2）
|
|
160
|
+
|
|
161
|
+
- **故事描述**: 作为[角色]，我想要[功能]，以便于[价值]
|
|
162
|
+
- **为何赋予此优先级**：[阐述]
|
|
163
|
+
- **独立测试**：[描述]
|
|
164
|
+
- **前置条件**: [条件]
|
|
165
|
+
- **后置条件**: [状态]
|
|
166
|
+
|
|
167
|
+
**验收场景**：
|
|
168
|
+
|
|
169
|
+
1. `US-03-AC1` **[场景标题]**: **Given** [初始状态]，**When** [操作]，**Then** [预期结果]
|
|
170
|
+
|
|
171
|
+
---
|
|
172
|
+
|
|
173
|
+
#### 2.1.N `US-{n}` 用户故事 — [简短标题]（优先级：Px）
|
|
174
|
+
|
|
175
|
+
[按需继续添加，编号依次递增]
|
|
176
|
+
```
|
|
177
|
+
|
|
178
|
+
---
|
|
179
|
+
|
|
180
|
+
### 第3部分：业务场景
|
|
181
|
+
<!-- 重要提示：业务场景按照业务流程进行优先排序。必须包含异常场景-->
|
|
182
|
+
|
|
183
|
+
[
|
|
184
|
+
本部分要回答的核心问题:
|
|
185
|
+
这个业务领域端到端的完整流程是什么样的？
|
|
186
|
+
流程中哪些单据需要人工审批？审批流是怎样的？
|
|
187
|
+
流程步骤之间，哪些是"做完立刻继续下一步"，哪些是"做完之后允许稍后处理、不阻塞主流程"？
|
|
188
|
+
]
|
|
189
|
+
|
|
190
|
+
```markdown
|
|
191
|
+
## 3. 业务场景及流程
|
|
192
|
+
|
|
193
|
+
### 3.1 业务流程描述
|
|
194
|
+
描述用户使用这个功能的完整流程：
|
|
195
|
+
[每个端到端业务流程必须包含以下字段：]
|
|
196
|
+
|
|
197
|
+
#### 3.1.1 场景1: [流程编号+场景名称，如：PROC-P05-01-001 采购到货入库全流程]（可标注对应架构端到端场景编号，如 PROC-P05-01-001）
|
|
198
|
+
|
|
199
|
+
**流程目标**：描述这个流程整体要达成的业务结果（一句话）
|
|
200
|
+
**流程参与角色**：列出流程中涉及的所有岗位角色（引用 ROLE 编号）
|
|
201
|
+
**流程步骤**（按顺序列出，每一步标注步骤类型）：
|
|
202
|
+
| 步骤 | 步骤描述 | 引用的业务功能 | 衔接类型 | 分支条件 |
|
|
203
|
+
| ---- | -------------------------- | -------------- | -------- | ---------------------- |
|
|
204
|
+
| 1 | 录入合同 | FUNC-CON-001 | 同步等待 | - |
|
|
205
|
+
| 2 | 系统自动生成付款条款 | FUNC-PMT-001 | 异步触发 | - |
|
|
206
|
+
| 3 | 录入开票信息（可重复执行） | FUNC-INV-001 | 同步等待 | - |
|
|
207
|
+
| 4 | 录入收款信息 | FUNC-INV-002 | 同步等待 | - |
|
|
208
|
+
| 5 | 判断是否全款回收 | - | 条件分支 | 是→步骤6；否→返回步骤3 |
|
|
209
|
+
| 6 | 关闭合同 | FUNC-CON-002 | 同步等待 | - |
|
|
210
|
+
|
|
211
|
+
|
|
212
|
+
**Mermaid 流程图**：[这是标题不能删除]
|
|
213
|
+
|
|
214
|
+
```mermaid
|
|
215
|
+
flowchart TD
|
|
216
|
+
A[录入合同] -->|异步触发| B[系统自动生成付款条款]
|
|
217
|
+
A --> C[录入开票信息]
|
|
218
|
+
C --> D[录入收款信息]
|
|
219
|
+
D --> E{是否全款回收}
|
|
220
|
+
E -->|否| C
|
|
221
|
+
E -->|是| F[关闭合同]
|
|
222
|
+
```
|
|
223
|
+
|
|
224
|
+
**"衔接类型"字段是强制必填项**，每一个步骤到下一步骤的衔接，必须从以下两个值中明确选择一个：
|
|
225
|
+
|
|
226
|
+
- **同步等待**：当前步骤的执行结果是下一步骤的直接输入，下一步骤必须等待当前步骤完成才能开始，当前步骤失败则整个流程在此中断
|
|
227
|
+
- **异步触发**：当前步骤完成后产生一个业务事件，下一步骤是对该事件的响应，允许延迟执行，下一步骤的失败原则上不影响当前步骤已经达成的结果
|
|
228
|
+
[这个字段直接决定后续 ME 事件模型是否需要为该衔接点建立独立的事件定义，是流程描述中信息密度最高、也最容易被自然语言描述模糊掉的字段，撰写和评审时必须重点检查。]
|
|
229
|
+
|
|
230
|
+
[按需继续添加场景，编号依次递增]
|
|
231
|
+
|
|
232
|
+
```
|
|
233
|
+
|
|
234
|
+
[审批流说明]
|
|
235
|
+
**关键确认要求**：对于流程中涉及的每一个核心业务单据（如合同、开票单、付款申请），必须明确回答"这个单据是否需要人工审批"，不允许默认假设有或没有。如果存在审批流，按以下结构说明：
|
|
236
|
+
如果该单据明确不需要审批，仍需在文档中显式记录"OBJ-CON-001 合同：无需审批，录入后直接生效"，不允许留空——留空会被视为信息缺失而非"无审批"的确认结果。
|
|
237
|
+
```markdown
|
|
238
|
+
#### 3.1.n 审批流说明（每个 APPR 一份，如适用）
|
|
239
|
+
### APPR-CON-001 合同审批流
|
|
240
|
+
|
|
241
|
+
**适用单据**：OBJ-CON-001 合同
|
|
242
|
+
**触发条件**：什么情况下需要走审批（如：合同金额超过 X 万元）
|
|
243
|
+
**审批节点**：
|
|
244
|
+
|
|
245
|
+
| 节点序号 | 审批角色 | 审批动作 | 通过后状态 | 驳回后状态 |
|
|
246
|
+
| -------- | -------- | -------- | ------------ | -------------- |
|
|
247
|
+
| 1 | 部门经理 | 一级审批 | 进入二级审批 | 退回起草人修改 |
|
|
248
|
+
| 2 | 财务总监 | 二级审批 | 合同生效 | 退回起草人修改 |
|
|
249
|
+
|
|
250
|
+
**Mermaid 流程图**：
|
|
251
|
+
|
|
252
|
+
```mermaid
|
|
253
|
+
flowchart TD
|
|
254
|
+
A[起草合同] --> B{金额是否超限}
|
|
255
|
+
B -->|否| F[合同生效]
|
|
256
|
+
B -->|是| C[部门经理审批]
|
|
257
|
+
C -->|通过| D[财务总监审批]
|
|
258
|
+
C -->|驳回| A
|
|
259
|
+
D -->|通过| F
|
|
260
|
+
D -->|驳回| A
|
|
261
|
+
```
|
|
262
|
+
```
|
|
263
|
+
|
|
264
|
+
```markdown
|
|
265
|
+
### 3.2 业务规则
|
|
266
|
+
列出该需求涉及的所有业务规则：
|
|
267
|
+
|
|
268
|
+
规则类型按以下四类划分，撰写时需明确归属，便于后续与 M3 规则模型的五种类型对齐：
|
|
269
|
+
- **校验类**：判断单次输入是否合法（如金额必须大于0）
|
|
270
|
+
- **计算类**：根据输入计算出某个结果值（如运费计算）
|
|
271
|
+
- **推导类**：基于已知信息推导出新的属性或结论（如根据角色推导数据可见范围）
|
|
272
|
+
- **转换类**：将一种数据格式转换为另一种（通常出现在外部系统对接场景，本期较少涉及）
|
|
273
|
+
- **规则复用强制检查**：如果同一条业务规则在两个或以上业务功能中都被提及（即使描述文字略有差异），必须识别为同一条规则、合并为一个 RULE 编号，在"被哪些业务功能引用"字段中列出全部引用方，不允许同一逻辑重复定义为多条规则。
|
|
274
|
+
|
|
275
|
+
#### 3.2.1 规则1: [规则名称] (BR-01)
|
|
276
|
+
|
|
277
|
+
- **规则类型**：[校验类（输入数据是否合法）]
|
|
278
|
+
- **规则描述**: [详细描述规则内容]
|
|
279
|
+
- **校验失败提示**：[描述校验失败的提示内容]
|
|
280
|
+
- **适用场景**: [这个规则在什么情况下生效]
|
|
281
|
+
- **计算方式**: [如果有计算逻辑，用文字或公式描述]（可选）
|
|
282
|
+
- **示例**: [给出具体示例，让AI更容易理解]
|
|
283
|
+
|
|
284
|
+
#### 3.2.2 规则2: [规则名称] (BR-02)
|
|
285
|
+
|
|
286
|
+
- **规则类型**：[校验类（输入数据是否合法）]
|
|
287
|
+
- **规则描述**: [详细描述规则内容]
|
|
288
|
+
- **校验失败提示**：[描述校验失败的提示内容]
|
|
289
|
+
- **适用场景**: [这个规则在什么情况下生效]
|
|
290
|
+
- **计算方式**: [如果有计算逻辑，用文字或公式描述]（可选）
|
|
291
|
+
- **示例**: [给出具体示例，让AI更容易理解]
|
|
292
|
+
|
|
293
|
+
### 3.3 业务数据
|
|
294
|
+
列出该需求涉及的核心业务数据：
|
|
295
|
+
|
|
296
|
+
#### 3.3.1 数据1: [数据名称]（[实体英文名，如 MaterialLot]）
|
|
297
|
+
- **数据描述**: [这个数据是什么，用来做什么；若为聚合根/核心实体请说明其职责]
|
|
298
|
+
- **数据类型**: [如：金额、数量、日期、文本、复合数据对象、单据（主表+行项，1:N）、事务记录（只增不改不可删）等]
|
|
299
|
+
- **数据来源**: [这个数据从哪里来]
|
|
300
|
+
- **示例值**: [给出示例值]
|
|
301
|
+
|
|
302
|
+
#### 3.3.2 数据2: [数据名称]（[实体英文名]）
|
|
303
|
+
- **数据描述**: [这个数据是什么，用来做什么]
|
|
304
|
+
- **数据类型**: [如：金额、数量、日期、文本等]
|
|
305
|
+
- **数据来源**: [这个数据从哪里来]
|
|
306
|
+
- **示例值**: [给出示例值]
|
|
307
|
+
|
|
308
|
+
### 3.4 状态机(可选项)
|
|
309
|
+
|
|
310
|
+
存在状态流转时必须画出状态图、状态转换规则矩阵和状态说明表。建议使用 Mermaid `stateDiagram-v2` 绘制。每个存在状态流转的聚合根/单据（如物料批次、入库单、出库单）应分别绘制状态图。
|
|
311
|
+
|
|
312
|
+
**示例1：MaterialLot 批次状态流转：**
|
|
313
|
+
|
|
314
|
+
```mermaid
|
|
315
|
+
stateDiagram-v2
|
|
316
|
+
[*] --> QA_HOLD: 到货登记（必检物料）
|
|
317
|
+
[*] --> UNRESTRICTED: 到货登记（免检物料）
|
|
318
|
+
|
|
319
|
+
QA_HOLD --> UNRESTRICTED: 检验合格 / 让步接收（⚡QMS P08 返回结果）
|
|
320
|
+
QA_HOLD --> BLOCKED: 检验不合格（⚡QMS P08 返回 UNQUALIFIED）
|
|
321
|
+
|
|
322
|
+
UNRESTRICTED --> RESERVED: 工单预留（⚡production.work-order.released）
|
|
323
|
+
UNRESTRICTED --> IN_TRANSIT: 调拨发货
|
|
324
|
+
UNRESTRICTED --> CONSUMED: 生产出库（扫码投料确认）
|
|
325
|
+
|
|
326
|
+
RESERVED --> CONSUMED: 生产出库（按预留批次，LotReservation 释放）
|
|
327
|
+
RESERVED --> UNRESTRICTED: 释放预留（工单取消/订单取消）
|
|
328
|
+
|
|
329
|
+
IN_TRANSIT --> UNRESTRICTED: 调拨收货确认（目标基地 ReceivingOrder 上架）
|
|
330
|
+
|
|
331
|
+
BLOCKED --> SCRAPPED: 报废审批通过
|
|
332
|
+
BLOCKED --> UNRESTRICTED: 采购退货（退货出库）
|
|
333
|
+
|
|
334
|
+
CONSUMED --> QA_HOLD: 生产退料确认（ReturnOrder，需重新检验）
|
|
335
|
+
```
|
|
336
|
+
|
|
337
|
+
|
|
338
|
+
**状态转换规则矩阵：**
|
|
339
|
+
|
|
340
|
+
| 当前状态 | 目标状态 | 触发动作 | 前置条件 |
|
|
341
|
+
| ------------ | ------------ | ---------- | -------------------------------------------------------------- |
|
|
342
|
+
| (新建) | QA_HOLD | 到货登记 | 来料检验必检物料（inspection_required=true） |
|
|
343
|
+
| (新建) | UNRESTRICTED | 到货登记 | 免检物料（inspection_required=false） |
|
|
344
|
+
| QA_HOLD | UNRESTRICTED | 检验合格 | ⚡QMS(P08) 返回检验结果 result=QUALIFIED |
|
|
345
|
+
| QA_HOLD | UNRESTRICTED | 让步接收 | ⚡QMS(P08) 返回 result=CONDITIONAL_ACCEPT 且双重审批通过 |
|
|
346
|
+
| QA_HOLD | BLOCKED | 检验不合格 | ⚡QMS(P08) 返回 result=UNQUALIFIED |
|
|
347
|
+
| UNRESTRICTED | RESERVED | 工单预留 | 收到 ⚡production.work-order.released 事件，生成 LotReservation |
|
|
348
|
+
| UNRESTRICTED | IN_TRANSIT | 调拨发货 | TransferOrder 审批通过并发货确认 |
|
|
349
|
+
| UNRESTRICTED | CONSUMED | 生产出库 | 扫码投料确认，IssueOrder 行项完成 |
|
|
350
|
+
| RESERVED | CONSUMED | 生产出库 | 按预留批次出库，LotReservation 释放 |
|
|
351
|
+
| RESERVED | UNRESTRICTED | 释放预留 | 工单取消/订单取消 |
|
|
352
|
+
| IN_TRANSIT | UNRESTRICTED | 调拨收货 | 目标基地 ReceivingOrder 确认收货并上架 |
|
|
353
|
+
| BLOCKED | SCRAPPED | 报废处理 | 报废审批通过（Flowable 工作流） |
|
|
354
|
+
| BLOCKED | UNRESTRICTED | 采购退货 | ReturnOrder 审批通过（退货出库，非状态回退） |
|
|
355
|
+
| CONSUMED | QA_HOLD | 生产退料 | ReturnOrder 确认，退料需重新检验（IQC） |
|
|
356
|
+
|
|
357
|
+
> **说明**: 状态图与矩阵必须一致；对有质量管控要求的回退路径（如退料后需重新检验），应显式建模为进入待检状态而非直接可用。
|
|
358
|
+
|
|
359
|
+
**状态说明表：**
|
|
360
|
+
|
|
361
|
+
| 状态 | 中文 | 英文枚举 | 含义 |
|
|
362
|
+
| ------------ | ---- | ----------- | ----------------------------------- |
|
|
363
|
+
| QA_HOLD | 待检 | `QA_HOLD` | 到货已登记，等待品管检验结果 |
|
|
364
|
+
| UNRESTRICTED | 可用 | `AVAILABLE` | 检验合格/免检，可正常出库/调拨/预留 |
|
|
365
|
+
| BLOCKED | 冻结 | `BLOCKED` | 检验不合格/过期/人工冻结，禁止出库 |
|
|
366
|
+
| ... | ... | ... | [按需列出全部状态] |
|
|
367
|
+
|
|
368
|
+
**示例2：单据状态流转（每个存在状态流转的单据聚合根单独绘制）：**
|
|
369
|
+
|
|
370
|
+
```mermaid
|
|
371
|
+
stateDiagram-v2
|
|
372
|
+
[*] --> DRAFT: 创建单据
|
|
373
|
+
DRAFT --> APPROVED: 审批通过
|
|
374
|
+
APPROVED --> PICKING: 开始拣货
|
|
375
|
+
PICKING --> COMPLETED: 全部出库确认
|
|
376
|
+
DRAFT --> CANCELLED: 取消
|
|
377
|
+
APPROVED --> CANCELLED: 取消
|
|
378
|
+
```
|
|
379
|
+
```
|
|
380
|
+
|
|
381
|
+
---
|
|
382
|
+
|
|
383
|
+
### 第4部分：功能描述
|
|
384
|
+
|
|
385
|
+
<!--
|
|
386
|
+
ID 体系说明：PRD 中的功能编号 P{模块}-{子模块}-{序号}（如 P05-01-01）在需求分析阶段
|
|
387
|
+
按三级编号深度优先顺序映射为 FUNC-{n}（如 P05-01-01 → FUNC-01，P05-01-02 → FUNC-02...），
|
|
388
|
+
映射关系在需求分析文档的"需求 ID 映射表"中明确记录。
|
|
389
|
+
一级模块和二级模块需要作为前端菜单级规划，建议和菜单保持一致，如果是事务后端功能可以没有二级模块。三级功能是具体的功能如xx列表页/详情页/表单页/审批流/报表/定时任务/接口/其他]
|
|
390
|
+
|
|
391
|
+
一级模块和二级模块的名称与编号需要严格与 docs/10-architecture/01-smom-wms_business_architecture.md 中 §2.1 模块清单、§2.2 子模块清单 保持一致（如 P05 仓储物流管理 / P05-01 原辅材料仓库）。
|
|
392
|
+
-->
|
|
393
|
+
|
|
394
|
+
```markdown
|
|
395
|
+
## 4. 功能描述
|
|
396
|
+
|
|
397
|
+
### 4.1 功能清单
|
|
398
|
+
列出该需求包含的所有功能（功能类型可组合，如"列表页+表单页"）：
|
|
399
|
+
| 一级模块 | 编号 | 二级模块 | 编号 | 三级功能 | 编号 | 功能类型 | 优先级 | 简述 |
|
|
400
|
+
| -------------- | -------- | -------------- | ----------- | -------------- | -------------- | ------------------------------------------------------- | ---------- | ------------------------------------------------------ |
|
|
401
|
+
| [一级模块名称] | [如 P05] | [二级模块名称] | [如 P05-01] | [三级功能名称] | [如 P05-01-01] | [列表页/详情页/表单页/审批流/报表页/定时任务/接口/其他] | [P0/P1/P2] | [用1-2句话描述功能作用，标注关键实体和跨模块依赖] |
|
|
402
|
+
| 仓储物流管理 | P05 | 原辅材料仓库 | P05-01 | 入库单管理 | P05-01-01 | 列表页+表单页 | P0 | 入库单（ReceivingOrder）创建/列表/详情/导入SAP采购订单 |
|
|
403
|
+
|
|
404
|
+
|
|
405
|
+
|
|
406
|
+
### 4.2 功能模块结构图
|
|
407
|
+
采用 ASCII 树状图（代码块）表示，按业务分组组织，列出功能编号、功能名称（功能类型，优先级），可标注关键实体/依赖：
|
|
408
|
+
|
|
409
|
+
```
|
|
410
|
+
[一级模块名称]([编号])
|
|
411
|
+
└── [二级模块名称]([编号])
|
|
412
|
+
├── [业务分组1]
|
|
413
|
+
│ ├── [三级功能编号] [功能名称]（[功能类型]，[优先级]）— [关键实体/依赖标注]
|
|
414
|
+
│ └── [三级功能编号] [功能名称]（[功能类型]，[优先级]）
|
|
415
|
+
└── [业务分组2]
|
|
416
|
+
└── [三级功能编号] [功能名称]（[功能类型]，[优先级]）
|
|
417
|
+
```
|
|
418
|
+
|
|
419
|
+
|
|
420
|
+
### 4.3 功能详细说明（重点）
|
|
421
|
+
|
|
422
|
+
对每个功能进行详细说明：
|
|
423
|
+
|
|
424
|
+
#### 4.3.1 功能1: [功能编号] [功能名称]（如：P05-01-01 入库单管理）
|
|
425
|
+
|
|
426
|
+
**操作角色**：ROLE-SALES 销售人员、ROLE-CON-ADMIN 合同管理员
|
|
427
|
+
**主操作对象**：OBJ-CON-001 合同
|
|
428
|
+
**引用的关联对象**：OBJ-PRD-001 产品、OBJ-CUS-001 客户、OBJ-DEPT-001 部门
|
|
429
|
+
**前置条件**：
|
|
430
|
+
- 合同编号在系统中不存在（唯一性）
|
|
431
|
+
- 引用的产品、客户、部门均处于有效状态
|
|
432
|
+
- 当前用户具备合同录入权限
|
|
433
|
+
|
|
434
|
+
**功能描述**:
|
|
435
|
+
[详细描述这个功能的作用、目的和业务价值；涉及聚合根实体的请标注英文实体名]
|
|
436
|
+
|
|
437
|
+
**用户操作流程**:
|
|
438
|
+
1. [用户操作1]: [描述用户做什么]
|
|
439
|
+
2. [系统响应1]: [描述系统如何响应]
|
|
440
|
+
3. [用户操作2]: [描述用户做什么]
|
|
441
|
+
4. [系统响应2]: [描述系统如何响应]
|
|
442
|
+
|
|
443
|
+
**输入数据**:
|
|
444
|
+
- [数据1]: [数据名称] - [数据描述] - [示例值]
|
|
445
|
+
- [数据2]: [数据名称] - [数据描述] - [示例值]
|
|
446
|
+
|
|
447
|
+
**输出数据**:
|
|
448
|
+
- [数据1]: [数据名称] - [数据描述] - [示例值]
|
|
449
|
+
- [数据2]: [数据名称] - [数据描述] - [示例值]
|
|
450
|
+
|
|
451
|
+
**涉及的业务规则**：
|
|
452
|
+
- RULE-CON-001 合同金额合规校验
|
|
453
|
+
- RULE-CON-002 税率合规校验
|
|
454
|
+
- RULE-PMT-001 付款比例总和校验
|
|
455
|
+
|
|
456
|
+
**后置状态变更**：
|
|
457
|
+
- 合同状态变更为"生效"
|
|
458
|
+
|
|
459
|
+
**下游触发**：
|
|
460
|
+
- 自动触发 FUNC-PMT-001（批量创建付款条款），衔接类型：异步触发（见 PROC-CON-001 步骤2）
|
|
461
|
+
|
|
462
|
+
**特殊处理**:
|
|
463
|
+
- [如果有特殊的业务逻辑，描述清楚]
|
|
464
|
+
- [如：需要调用第三方接口、需要特殊计算、需要特殊权限等]
|
|
465
|
+
|
|
466
|
+
**异常处理**:
|
|
467
|
+
- [详细描述异常场景业务逻辑，重点包括权限异常、数据为空、接口失败、重复提交、状态冲突、网络异常、历史数据兼容、用户中途退出]
|
|
468
|
+
|
|
469
|
+
#### 4.3.2 功能2: [功能编号] [功能名称]
|
|
470
|
+
|
|
471
|
+
[按照上述格式继续描述。报表类功能可用"页面布局"小节替代操作流程；扫码/移动端功能可用"功能入口"小节列出各操作场景]
|
|
472
|
+
```
|
|
473
|
+
|
|
474
|
+
---
|
|
475
|
+
|
|
476
|
+
### 第5部分：业务对象说明
|
|
477
|
+
|
|
478
|
+
本部分要回答的核心问题:
|
|
479
|
+
业务需求中涉及哪些业务对象？哪些是单据类对象，哪些是主数据对象，哪些是枚举类对象？
|
|
480
|
+
每个对象有哪些业务属性？属性的类型、长度、约束是什么？
|
|
481
|
+
对象之间存在什么样的引用关系？这种引用是强依赖还是弱关联？
|
|
482
|
+
一个对象被删除或作废时，与它关联的其他对象应该如何处理？
|
|
483
|
+
|
|
484
|
+
撰写前需先对涉及的全部业务对象做分类标注：
|
|
485
|
+
|
|
486
|
+
| 分类 | 说明 | 示例 |
|
|
487
|
+
| ---------- | -------------------------------------------- | ------------------------------ |
|
|
488
|
+
| 单据类对象 | 有完整生命周期状态流转的业务单据 | 合同、开票单、付款申请 |
|
|
489
|
+
| 聚合子对象 | 依附于某个单据类对象、不能独立存在的明细信息 | 合同付款条款、订单明细 |
|
|
490
|
+
| 主数据对象 | 相对稳定、被多个单据引用的基础数据 | 客户、产品、供应商、部门、人员 |
|
|
491
|
+
| 枚举类对象 | 取值范围固定的分类标识 | 订单类型、合同状态 |
|
|
492
|
+
|
|
493
|
+
```markdown
|
|
494
|
+
## 5. 业务对象说明
|
|
495
|
+
|
|
496
|
+
### 5.1 业务对象说明结构（每个 OBJ 一份）
|
|
497
|
+
|
|
498
|
+
业务对象编号遵循 `OBJ-{业务域缩写}-{三位序号}`（如 OBJ-CON-001 合同），业务域缩写与 §3.1 流程编号保持一致。
|
|
499
|
+
|
|
500
|
+
### 5.1.1 OBJ-CON-001 合同
|
|
501
|
+
|
|
502
|
+
**对象分类**：单据类对象
|
|
503
|
+
|
|
504
|
+
**对象说明**：企业与客户签订的销售合同，是合同管理的核心单据
|
|
505
|
+
|
|
506
|
+
**生命周期状态**：草稿 → 生效 → 已关闭
|
|
507
|
+
|
|
508
|
+
**业务属性**：
|
|
509
|
+
|
|
510
|
+
| 属性名 | 中文名 | 类型 | 长度/精度 | 是否必填 | 是否唯一 | 引用对象 |
|
|
511
|
+
| --------------------- | ---------- | ------ | --------- | -------- | -------- | ------------------- |
|
|
512
|
+
| contractId | 合同编号 | 字符串 | 50 | 是 | 是 | - |
|
|
513
|
+
| contractName | 合同名称 | 字符串 | 200 | 是 | 否 | - |
|
|
514
|
+
| productId | 所属产品 | 字符串 | 50 | 是 | 否 | OBJ-PRD-001 |
|
|
515
|
+
| customerId | 所属客户 | 字符串 | 50 | 是 | 否 | OBJ-CUS-001 |
|
|
516
|
+
| departmentId | 所属部门 | 字符串 | 50 | 是 | 否 | OBJ-DEPT-001 |
|
|
517
|
+
| responsibleEmployeeId | 责任人 | 字符串 | 50 | 是 | 否 | OBJ-EMP-001 |
|
|
518
|
+
| totalAmount | 合同总金额 | 数值 | (18,2) | 是 | 否 | - |
|
|
519
|
+
| taxRate | 税率 | 数值 | (5,4) | 是 | 否 | - |
|
|
520
|
+
| status | 合同状态 | 枚举 | - | 是 | 否 | OBJ-ENUM-CON-STATUS |
|
|
521
|
+
|
|
522
|
+
**关联的聚合子对象**：
|
|
523
|
+
|
|
524
|
+
| 子对象 | 关联说明 | 父对象作废/删除时子对象如何处理 |
|
|
525
|
+
| -------------------- | ------------------------ | -------------------------------------- |
|
|
526
|
+
| OBJ-PMT-001 付款条款 | 一份合同包含多条付款条款 | 合同删除则付款条款级联删除（组合关系） |
|
|
527
|
+
|
|
528
|
+
**关联的其他业务对象**：
|
|
529
|
+
|
|
530
|
+
| 关联对象 | 关联关系说明 | 父对象作废/删除时如何处理 |
|
|
531
|
+
| -------------------- | -------------------- | -------------------------------------------------------------- |
|
|
532
|
+
| OBJ-INV-001 开票明细 | 一份合同对应多张开票 | 合同删除后开票记录作为财务凭证独立保留（聚合关系，不级联删除） |
|
|
533
|
+
|
|
534
|
+
**参照完整性约束**：
|
|
535
|
+
- 合同总金额必须大于 0
|
|
536
|
+
- 税率必须在 0 到 1 之间
|
|
537
|
+
|
|
538
|
+
[按需继续添加业务对象，编号依次递增]
|
|
539
|
+
```
|
|
540
|
+
|
|
541
|
+
**关联关系强制确认要求**（本部分撰写中最容易遗漏、也是后续影响最大的一项）：对于任何一对存在父子或引用关系的业务对象，必须明确回答"父对象删除或作废时，子对象/关联对象应该如何处理"，且答案只能是以下两种之一：
|
|
542
|
+
|
|
543
|
+
- **级联处理（对应组合关系）**：父对象删除时，子对象一并删除，子对象不能脱离父对象独立存在
|
|
544
|
+
- **独立保留（对应聚合关系）**：父对象删除或作废时，已存在的关联对象不受影响，继续独立存在
|
|
545
|
+
|
|
546
|
+
这个问题不能依赖 AI 从业务对象的名称或描述里自行推断，必须由业务专家明确确认并记录在文档中，因为同样名称的对象在不同企业的业务场景下答案可能完全相反（例如"开票记录是否随合同删除而删除"，不同企业的财务合规要求不同）。
|
|
547
|
+
|
|
548
|
+
```markdown
|
|
549
|
+
### 5.2 枚举类对象说明结构
|
|
550
|
+
|
|
551
|
+
### OBJ-ENUM-CON-STATUS 合同状态枚举
|
|
552
|
+
|
|
553
|
+
**对象说明**：合同的生命周期状态取值集合
|
|
554
|
+
|
|
555
|
+
**取值列表**：
|
|
556
|
+
|
|
557
|
+
| 取值 | 中文名 | 说明 |
|
|
558
|
+
| ------ | ------ | -------------- |
|
|
559
|
+
| DRAFT | 草稿 | 已创建但未生效 |
|
|
560
|
+
| ACTIVE | 生效 | 正常履约中 |
|
|
561
|
+
| CLOSED | 已关闭 | 履约完成或终止 |
|
|
562
|
+
```
|
|
563
|
+
|
|
564
|
+
---
|
|
565
|
+
|
|
566
|
+
### 第6部分：权限要求
|
|
567
|
+
|
|
568
|
+
```markdown
|
|
569
|
+
## 6. 权限要求
|
|
570
|
+
|
|
571
|
+
### 6.1 功能权限
|
|
572
|
+
描述不同角色对不同功能的访问权限。
|
|
573
|
+
每行对应需求分析阶段的一个权限 ID `PERM-{n}`。
|
|
574
|
+
|
|
575
|
+
| 功能名称 | 权限标识 | 角色1 | 角色2 | 角色3 |
|
|
576
|
+
| -------- | ----------------------------- | -------- | ------ | -------- |
|
|
577
|
+
| [功能1] | `{module}:{resource}:create` | 可访问 | 可访问 | 不可访问 |
|
|
578
|
+
| [功能2] | `{module}:{resource}:read` | 可访问 | 可访问 | 可访问 |
|
|
579
|
+
| [功能3] | `{module}:{resource}:approve` | 不可访问 | 可访问 | 不可访问 |
|
|
580
|
+
|
|
581
|
+
> 权限标识遵循项目约定：`{module}:{resource}:{action}`，如 `warehouse:receiving:create`、`warehouse:issue:approve`、`warehouse:lot:export`。
|
|
582
|
+
> 每行（每个权限标识 → 角色组合）对应一个 PERM-{n} ID。
|
|
583
|
+
|
|
584
|
+
### 6.2 数据权限
|
|
585
|
+
描述数据隔离维度和不同角色可以访问的数据范围：
|
|
586
|
+
|
|
587
|
+
#### 6.2.1 数据隔离维度（如适用）
|
|
588
|
+
- [隔离维度1]: [如：所有查询和操作自动按用户所属基地（site_code）过滤，上海基地用户不可查看/操作重庆基地的数据]
|
|
589
|
+
- [隔离维度2]: [如：跨基地业务场景中，发货操作由源基地用户执行，收货操作由目标基地用户执行]
|
|
590
|
+
|
|
591
|
+
#### 6.2.2 角色数据范围
|
|
592
|
+
- **[角色1]**: [如：仅可查看/操作自己所属基地的业务数据]
|
|
593
|
+
- **[角色2]**: [如：可查看/操作所属基地的全部业务数据，含审批权限]
|
|
594
|
+
- **[角色3]**: [如：可查看所有基地的报表和导出数据（只读）]
|
|
595
|
+
```
|
|
596
|
+
|
|
597
|
+
---
|
|
598
|
+
|
|
599
|
+
### 第7部分：验收标准
|
|
600
|
+
|
|
601
|
+
<!--
|
|
602
|
+
ID 体系说明：验收标准不设立独立 ID 前缀。每条验收标准通过"关联用户故事"和
|
|
603
|
+
"关联业务规则"字段归约到已有的 US-{n} 和 BR-{n} ID。
|
|
604
|
+
需求分析阶段 AI 会将这些标准合并到对应的 US-{n}-AC{n} 验收场景中。
|
|
605
|
+
-->
|
|
606
|
+
|
|
607
|
+
```markdown
|
|
608
|
+
## 7. 验收标准
|
|
609
|
+
|
|
610
|
+
描述如何判断这个需求已经完成：
|
|
611
|
+
|
|
612
|
+
### 7.1 功能验收标准
|
|
613
|
+
#### 7.1.1 标准1: [验收标准描述]
|
|
614
|
+
- **关联用户故事**: [引用用户故事编号，如 US-01]（必填，可多个）
|
|
615
|
+
- **关联业务规则**: [引用业务规则编号，如 BR-01, BR-03]（选填，可多个）
|
|
616
|
+
- **验证方式**: [如何验证]
|
|
617
|
+
- **测试数据**: [使用什么数据进行测试]
|
|
618
|
+
- **预期结果**: [预期看到什么结果]
|
|
619
|
+
|
|
620
|
+
#### 7.1.2 标准2: [验收标准描述]
|
|
621
|
+
- **关联用户故事**: [US-02]
|
|
622
|
+
- **关联业务规则**: [BR-02]
|
|
623
|
+
- **验证方式**: [如何验证]
|
|
624
|
+
- **测试数据**: [测试数据]
|
|
625
|
+
- **预期结果**: [预期结果]
|
|
626
|
+
|
|
627
|
+
### 7.2 非功能验收标准
|
|
628
|
+
|
|
629
|
+
#### 7.2.1 性能要求
|
|
630
|
+
- **页面加载时间**: [如：列表页 < 3秒，详情页 < 2秒]
|
|
631
|
+
- **接口响应时间**: [如：核心查询接口 P95 < 500ms，P99 < 1s]
|
|
632
|
+
- **并发能力**: [如：支持 100 用户同时操作]
|
|
633
|
+
- **数据量级**: [如：单表数据量预估 10万条，日增量 500条]
|
|
634
|
+
|
|
635
|
+
#### 7.2.2 安全性要求
|
|
636
|
+
- **访问控制**: [如：不同角色只能访问授权的功能和数据]
|
|
637
|
+
- **数据加密**: [如：敏感数据（金额、个人信息）需加密存储]
|
|
638
|
+
- **操作审计**: [如：关键操作（审批、删除）需记录操作日志]
|
|
639
|
+
- **防篡改**: [如：结算金额等关键字段不可前端篡改]
|
|
640
|
+
|
|
641
|
+
#### 7.2.3 兼容性要求
|
|
642
|
+
- **浏览器支持**: [如：Chrome 90+、Edge 90+]
|
|
643
|
+
- **分辨率适配**: [如：最低支持 1366×768]
|
|
644
|
+
- **移动端**: [如：是否需要支持移动端访问]
|
|
645
|
+
|
|
646
|
+
#### 7.2.4 可用性要求
|
|
647
|
+
- **操作便捷性**: [如：核心流程不超过 5 步完成]
|
|
648
|
+
- **错误处理**: [如：所有异常操作需给出明确的错误提示]
|
|
649
|
+
- **数据备份**: [如：每日全量备份，保留 30 天]
|
|
650
|
+
- **归档策略**: [如：已结算数据超过 3 年自动归档]
|
|
651
|
+
|
|
652
|
+
### 7.3 已知问题或限制
|
|
653
|
+
列出已知的问题或需要后续处理的内容：
|
|
654
|
+
- [限制1]: [描述]
|
|
655
|
+
- [限制2]: [描述]
|
|
656
|
+
```
|
|
657
|
+
|
|
658
|
+
---
|
|
659
|
+
|
|
660
|
+
### 第8部分：参考资料
|
|
661
|
+
|
|
662
|
+
```markdown
|
|
663
|
+
## 8. 参考资料
|
|
664
|
+
|
|
665
|
+
### 8.1 相关文档
|
|
666
|
+
列出相关的文档链接：
|
|
667
|
+
- [文档1]: [文档名称] - [链接]
|
|
668
|
+
- [文档2]: [文档名称] - [链接]
|
|
669
|
+
|
|
670
|
+
### 8.2 相关功能
|
|
671
|
+
列出与本需求相关的其他功能：
|
|
672
|
+
- [功能1]: [功能名称] - [功能描述]
|
|
673
|
+
- [功能2]: [功能名称] - [功能描述]
|
|
674
|
+
|
|
675
|
+
### 8.3 外部依赖
|
|
676
|
+
列出本需求依赖的外部系统或服务：
|
|
677
|
+
|
|
678
|
+
| 依赖系统 | 集成方式 | 数据方向 | 频率 | 异常策略 | 备注 |
|
|
679
|
+
| ---------- | ------------------------------------------ | -------------------- | ------------------------------- | ----------------------------------------- | ------ |
|
|
680
|
+
| [系统名称] | [HTTP API / 内部RPC / 事件驱动 / 文件同步] | [读取 / 写入 / 双向] | [实时 / 定时 / 事件触发 / 按需] | [失败重试 / 降级 / 告警 / Outbox模式重发] | [说明] |
|
|
681
|
+
|
|
682
|
+
简要说明：
|
|
683
|
+
- [依赖1]: [系统名称] - [依赖描述]
|
|
684
|
+
- [依赖2]: [服务名称] - [依赖描述]
|
|
685
|
+
|
|
686
|
+
### 8.4 备注
|
|
687
|
+
其他需要说明的内容：
|
|
688
|
+
- [备注1]: [描述]
|
|
689
|
+
- [备注2]: [描述]
|
|
690
|
+
```
|
|
691
|
+
|
|
692
|
+
---
|
|
693
|
+
|
|
694
|
+
### 第9部分：术语表
|
|
695
|
+
|
|
696
|
+
```markdown
|
|
697
|
+
## 9. 术语表
|
|
698
|
+
|
|
699
|
+
统一说明本需求中涉及的核心业务术语，降低理解偏差。
|
|
700
|
+
|
|
701
|
+
| 术语 | 英文 | 定义 | 备注 |
|
|
702
|
+
| ----------- | --------- | -------------------------------- | ---------- |
|
|
703
|
+
| [术语名称1] | [English] | [该术语在本需求语境下的精确定义] | [补充说明] |
|
|
704
|
+
| [术语名称2] | [English] | [该术语在本需求语境下的精确定义] | [补充说明] |
|
|
705
|
+
| [术语名称3] | [English] | [该术语在本需求语境下的精确定义] | [补充说明] |
|
|
706
|
+
```
|
|
707
|
+
|
|
708
|
+
---
|
|
709
|
+
|
|
710
|
+
### 第10部分：假设与约束
|
|
711
|
+
|
|
712
|
+
```markdown
|
|
713
|
+
## 10. 假设与约束
|
|
714
|
+
|
|
715
|
+
### 10.1 需求假设
|
|
716
|
+
编写本需求时所做的隐含假设，若假设不成立则需求可能发生变化：
|
|
717
|
+
|
|
718
|
+
- [假设1]: [如：审批流引擎已部署并可用]
|
|
719
|
+
- [假设2]: [如：案件数据已录入系统且数据完整]
|
|
720
|
+
- [假设3]: [如：用户已完成登录认证的基础流程]
|
|
721
|
+
|
|
722
|
+
### 10.2 业务约束
|
|
723
|
+
来自业务方或外部环境的硬性限制：
|
|
724
|
+
|
|
725
|
+
- [约束1]: [如：必须在 Q3 结束前上线]
|
|
726
|
+
- [约束2]: [如：不修改现有数据库表结构]
|
|
727
|
+
- [约束3]: [如：需符合银保监会数据报送规范]
|
|
728
|
+
|
|
729
|
+
### 10.3 技术约束
|
|
730
|
+
来自技术栈或架构层面的限制：
|
|
731
|
+
|
|
732
|
+
- [约束1]: [如：后端采用 Spring Boot + MyBatis-Plus 技术栈]
|
|
733
|
+
- [约束2]: [如：前端需兼容 IE11（如有明确要求）]
|
|
734
|
+
```
|
|
735
|
+
|
|
736
|
+
---
|
|
737
|
+
|
|
738
|
+
### 第11部分：风险与待确认问题
|
|
739
|
+
|
|
740
|
+
```markdown
|
|
741
|
+
## 11. 风险与待确认问题
|
|
742
|
+
|
|
743
|
+
列出需求编写阶段识别的风险项和待业务方/技术方确认的问题，推动遗留事项闭环。
|
|
744
|
+
|
|
745
|
+
### 11.1 风险清单
|
|
746
|
+
|
|
747
|
+
| 风险编号 | 风险描述 | 影响范围 | 发生概率 | 影响程度 | 应对措施 | 责任人 | 状态 |
|
|
748
|
+
| -------- | ------------------------------------ | ------------------ | ---------- | ---------- | ---------------- | -------- | ------------- |
|
|
749
|
+
| R-01 | [风险描述，如：外部接口文档尚未提供] | [影响的功能或模块] | [高/中/低] | [高/中/低] | [缓解或规避措施] | [负责人] | [开放/已关闭] |
|
|
750
|
+
| R-02 | [风险描述] | [影响范围] | [高/中/低] | [高/中/低] | [应对措施] | [负责人] | [开放/已关闭] |
|
|
751
|
+
| R-03 | [风险描述] | [影响范围] | [高/中/低] | [高/中/低] | [应对措施] | [负责人] | [开放/已关闭] |
|
|
752
|
+
|
|
753
|
+
### 11.2 待确认问题清单
|
|
754
|
+
|
|
755
|
+
| 问题编号 | 问题描述 | 关联章节 | 提出日期 | 期望确认日期 | 确认方 | 当前状态 | 确认结论 |
|
|
756
|
+
| -------- | ---------------------------------------------- | ---------------- | ---------- | ------------ | -------------------- | --------------- | ---------- |
|
|
757
|
+
| Q-01 | [待确认问题，如：审批流是否需要支持多级会签？] | [如：§3.1、§4.3] | [提出日期] | [期望日期] | [业务方/技术方/产品] | [待确认/已确认] | [确认结论] |
|
|
758
|
+
| Q-02 | [待确认问题] | [关联章节] | [提出日期] | [期望日期] | [确认方] | [待确认/已确认] | [确认结论] |
|
|
759
|
+
| Q-03 | [待确认问题] | [关联章节] | [提出日期] | [期望日期] | [确认方] | [待确认/已确认] | [确认结论] |
|
|
760
|
+
|
|
761
|
+
> **使用说明**：
|
|
762
|
+
> - 风险编号 `R-{n}` 和问题编号 `Q-{n}` 在本章节内递增，不与其他章节 ID 冲突。
|
|
763
|
+
> - "关联章节"填写本模板中受影响的章节编号（如 §3.1、§4.3），便于追溯。
|
|
764
|
+
> - 状态流转：开放 → 已缓解/已确认 → 已关闭。每次评审时更新状态。
|
|
765
|
+
```
|
|
766
|
+
|
|
767
|
+
---
|
|
768
|
+
|
|
769
|
+
### 第12部分：变更记录
|
|
770
|
+
|
|
771
|
+
```markdown
|
|
772
|
+
## 12. 变更记录
|
|
773
|
+
|
|
774
|
+
| 版本 | 日期 | 变更人 | 变更内容 |
|
|
775
|
+
| ---- | ---------- | ------ | ---------------------------------------- |
|
|
776
|
+
| v1.0 | 2026-03-10 | [姓名] | 初始版本，创建需求 |
|
|
777
|
+
| v1.1 | 2026-03-15 | [姓名] | 补充 §3.2 业务规则，新增结算审批规则 |
|
|
778
|
+
| v2.0 | 2026-04-01 | [姓名] | 评审后修订：调整功能优先级，补充权限矩阵 |
|
|
779
|
+
```
|
|
780
|
+
|
|
781
|
+
---
|
|
782
|
+
|
|
783
|
+
**文档结束**
|
|
784
|
+
|
|
627
785
|
*本模板作为产品需求说明书的标准参考。*
|