5.5 KiB
5.5 KiB
ISO/IEC/IEEE 29148 需求规格模板
来源和定位
本模板用于 UniDesk project-management/ 下的 L0、L1、L2 需求规格文档。模板基线采用 ISO/IEC/IEEE 29148:2018 的需求工程分层思路,并结合 HWLAB 项目管理约束做轻量裁剪。
参考来源:
- ISO/IEC/IEEE 29148:2018:https://www.iso.org/standard/72089.html
- IEEE 830-1998 已被替代的官方说明:https://standards.ieee.org/ieee/830/1222/
- ReqView 对 29148 模板族的说明:https://www.reqview.com/doc/iso-iec-ieee-29148-templates/
- ReqView 的 29148 软件需求规格示例:https://www.reqview.com/doc/iso-iec-ieee-29148-srs-example/
使用原则:
- 业务需求规格用于使命和商业目标,利益相关方需求规格用于用户和运营方诉求,系统需求规格用于跨硬件、软件、人员和流程的系统级要求,软件需求规格用于软件能力要求。运行流程和一次性执行过程不进入 1-6 章需求正文;需要挂阶段 issue、内测、灰度或反馈分流时,放入第 7 章过程控制,稳定概念优先沉淀为术语表。
- HWLAB 的 L0、L1、L2 规格共用同一骨架,但粒度不同:L0 写使命、边界和全局需求;L1 写内部模块职责和验收边界;L2 写具体课题的交付物、阻塞项和验证计划。
- 规格正文的 1-6 章只写稳定需求、系统边界、外部输入输出和职责;内部治理、阶段报告、执行流水、长日志、拉取请求过程和一次性运行材料不进入需求章节。第 7 章过程控制只做阶段 issue、反馈分流和敏感信息边界的索引,不承载问卷正文、参与者资料、原始反馈或长证据。
- 每条原子需求使用独立小节。信息表使用横向表格且只放短元数据,推荐包含编号、短名、主责模块和关联模块;主责模块填写下一层主责单元,L0 写 L1,L1 写 L2,L2 写 L3,不重复当前规格本级;需求定义、职责划分、意图、范围和边界写在正文中,避免表格厚而正文薄。
- 不要为了凑全局需求条目自动添加证据收集、硬编码诊断、硬编码建议、任务状态收集、结果包或结果收集类次要需求;除非用户明确授意,这些内容不进入 OA 规格。
文档骨架
# <编号> <短名> 需求规格
## 修改历史
| 版本 | 对应提交标识 | 更新日期 | 变更说明 |
| --- | --- | --- | --- |
| v0.1 | 待提交 | <年-月-日> | 创建需求规格;如来自历史议题,只在这里写迁移来源 <组织>/<仓库>#<编号>。 |
未定稿前不新增版本号,不为单次编辑追加 `待提交` 版本;只有用户明确确认可以定稿时,才更新修改历史。
## 正文
## <编号> <短名> 需求规格
## 1. 文档控制
| 字段 | 内容 |
| --- | --- |
| 编号 | <项目编号> |
| 短名 | <短名> |
| 层级 | L0、L1 或 L2 |
| 状态 | 已生效、已废弃或未生效 |
| 需求规格模板 | [ISO/IEC/IEEE 29148 需求规格模板](<相对路径>) |
| 上级规格 | <相对路径链接;L0 可留空> |
| 规格治理索引 | <相对路径链接> |
本文采用 ISO/IEC/IEEE 29148 需求规格模板的项目裁剪版:正文只保留稳定使命、范围、术语、系统边界、内部模块或课题分工、原子需求和必要过程控制。编号、层级职责、回写、偏离判定和交叉引用治理由规格治理文档承载。
## 2. 目的和范围
### 2.1 目的
<用一段话说明该规格服务的项目目标、用户目标或系统目标。>
### 2.2 范围内
- <范围项>
### 2.3 范围外
- <非目标或转交范围>
## 3. 术语表
| 术语 | 定义 |
| --- | --- |
| <术语> | <稳定定义> |
## 4. 系统边界和接口
本规格把目标对象作为一个完整系统看待;本章只描述外部输入、外部输出和系统边界,不描述内部治理流程。
| 边界项 | 内容 |
| --- | --- |
| 外部使用者 | <用户、管理员或自动化任务> |
| 外部输入 | <用户请求、业务对象、资源约束、身份凭据、配置项或文件> |
| 受控资源 | <系统管理的资源、数据、运行环境或外部设备> |
| 外部输出 | <用户可获得的状态、结果、产物、通知、报告或记录> |
| 用户接口 | <网页端、命令行、应用接口、开发工具包等> |
| 系统边界 | <系统负责什么;明确不替代用户、管理员或运行环境负责什么> |
## 5. 内部分工与规格索引
| 编号 | 模块或课题 | 规格文档 | 主责边界 | 上游依赖 | 下游支撑 |
| --- | --- | --- | --- | --- | --- |
| <项目编号> | <短名> | [<规格名>](<相对路径>) | <主责> | <依赖> | <支撑对象> |
## 6. 原子需求
### 6.1 <需求编号> <需求短名>
| 编号 | 短名 | 主责模块 | 关联模块 |
| --- | --- | --- | --- |
| <需求编号> | <需求短名> | <下一层项目编号 短名,必要时使用相对路径链接> | <关联模块,使用相对路径链接> |
<正文第一段写完整需求定义。正文后续段落写主责职责、关联模块职责、意图、范围和边界。正文不放执行流水和长证据。>
## 7. 过程控制
本章只索引跨模块阶段验证、内测、灰度或用户反馈分流 issue;不新增 L1,不替代阶段计划,不把问卷、参与者资料、原始反馈、长证据或执行流水写入规格正文。
| 阶段 issue | 定位 | 关联模块 | 回写口径 |
| --- | --- | --- | --- |
| [#<编号>](https://github.com/<组织>/<仓库>/issues/<编号>) <短名> | <阶段验证或反馈分流定位> | <关联 L1/L2> | <脱敏、分流和回写规则> |