v6ole
168 lines
19 KiB
Markdown
168 lines
19 KiB
Markdown
# 中国电信软件研发规范需求管理分册（修订版）
|
|
|
|
> 脱敏整理版：已移除编制人员、联系人和联系方式，并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。
|
|
|
|
中国电信软件研发规范需求管理分册 （修订版）
|
|
|
|
中国电信集团有限公司
|
|
|
|
## 2023 年 12 月
|
|
|
|
i
|
|
|
|
> 编制人员信息已移除。
|
|
|
|
版本变更历史
|
|
|
|
iii
|
|
|
|
## 1 文档说明
|
|
|
|
### 1.1 编制说明
|
|
|
|
本规范制定中国电信软件研发项目的需求管理要求，包括需求的收集、分析、编写、评审、变更、验收等，用以指导和要求项目团队的需求开发活动，实现对需求的闭环管理和全程跟踪。保证客户和软件开发小组对产品业务的理解达成一致意见，包括系统需求和软件运行性能需求的共识，确保交付物符合约定的功能和质量要求。根据规范要求项目团队应编制清楚、完整、一致、可测试的《软件需求规格说明书》、《单个模块需求文档》、《需求追踪表》等，确保需求管理的规范性和可回溯性。
|
|
|
|
### 1.2 文档结构
|
|
|
|
本规范由文档说明、需求管理过程、需求管理、需求变更、需求跟踪和附件构成， 各章节的主要内容如下：第 1 章节文档说明，对规范的编制、文档结构、适用范围、起草单位、解释权 、版权和本规范用到的术语进行说明。第 2 章需求管理过程， 对需求开发过程及涉及的角色与职责进行说明。第 3 章需求管理，对需求调研、需求分析、需求评审和需求验收各个阶段进行描述。第 4 章需求变更，对需求变更的申请、评估、审批、制定计划并执行、验证进行说明。第 5 章需求跟踪， 规范需求跟踪的流程和要求。第 6 章为相关附件。
|
|
|
|
### 1.3 适用范围
|
|
|
|
1
|
|
|
|
本规范适用于中国电信的软件研发项目在项目生命周期中的设计、实现、测试以及产品发布的需求跟踪活动 。重点有以下几方面：（1） 本规范适用于传统 、敏捷 、预研 、小微等生命周期模型。（2） 本规范适用于项目启动初期， 对整个项目所有需求的开发过程， 同时也适用于在项目进行过程中， 用户临时新增需求的开发过程。（3） 需求管理是一个循环往复的过程，在日常项目中需求多是迭代获取的，随着项目的进展，需求逐步增加、逐步细化，在项目开发阶段，对既有需求的补充， 如需求开发 、需求变更， 都作为新需求处理， 同样适用本规范。（4） 本规范适用于中国电信C1 能力级别项目， 即适用于所有项目。
|
|
|
|
### 1.4 起草单位
|
|
|
|
本规范的起草单位是中国电信集团公司。
|
|
|
|
### 1.5 解释权
|
|
|
|
本规范解释权属于中国电信集团公司。
|
|
|
|
### 1.6 版权
|
|
|
|
本规范的版权属于中国电信集团公司。
|
|
|
|
### 1.7 名词解释
|
|
|
|
2
|
|
|
|
3
|
|
|
|
## 2 需求管理过程
|
|
|
|
### 2.1 需求开发过程
|
|
|
|
（1） 制定需求开发计划需求工程师依据需求范围，配合项目经理制定需求开发计划，明确需求总体交付时间 、需求调研范围 、干系人清单。（2） 需求调研需求调研是需求收集的一种，调研后生成《需求调研记录》或《客户访谈记录》。（3） 需求分析需求工程师从整体进行分析，阐述项目背景与目标，理解客户要解决什么问题，有怎样的期望， 由用户需求转化为软件需求，软件设计师可依据软件需求进行设计、编码等工作。根据各层次需求，需求工程师依据实际业务制作原型。此阶段的需求成果物主要为《软件需求规格说明书》和原型。（4） 需求评审需求工程师提交《需求跟踪表》 、《软件需求规范说明书》给项目经理， 由项目经理组织需求评审，评审后输出《评审记录表》（无固定格式，项目方可根据实际情况自行拟定）、评审后修订的《需求跟踪表》、评审后修订的《软件需求规格说明书》。（5） 用户确认需求将整理好的业务需求、软件需求、原型图与客户进行确认，形成用户确认单 、用户签字的需求文档或用户回复的确认邮件、或其他可作为确认凭证的留档文件，做到需求收集过程留痕即可。（6） 需求变更当形成基线后，仍有可能出现较多的需求变更，需对变更的需求进行有效管理。项目经理提交变更申请，经 CCB 评审同意后，需求工程师输出修改后的《软件需求规格说明书》。（7） 需求跟踪4
|
|
|
|
需求追踪在于保证干系人、项目组始终就项目需求达成统一一致的视图。需求工程师在所有需求管理阶段， 结合各阶段主要交付物， 更新《需求跟踪表》，将需求 、关联文档和发布版本进行关联。（8） 需求验收需求验收即检验产品相关需求是否符合用户方要求，是否符合发布条件。需求工程师对版本实现的功能逐一检查， 以避免开发出来的内容与定义存在偏差。
|
|
|
|
### 2.2 过程流程图
|
|
|
|
1. 需求开发过程流程图
|
|
|
|
5
|
|
|
|
2. 需求变更过程流程图
|
|
|
|
6
|
|
|
|
### 2.3 角色与职责
|
|
|
|
7
|
|
|
|
8
|
|
|
|
9
|
|
|
|
## 3 需求管理
|
|
|
|
需求管理包括需求调研 、需求编写 、需求评审和验收各个阶段的管理。
|
|
|
|
### 3.1 需求调研
|
|
|
|
需求调研是为实现项目目标而定义并记录干系人的过程 。需求是指发起人、客户和其他干系人的已量化且记录下来的需要与期望。项目一旦开始，就应该足够详细地探明、分析和记录这些需求， 以便日后进行测量。收集需求旨在定义和管理客户期望。成本、进度和质量规划都要在需求基础上进行，需求是工作分解结构的基础。
|
|
|
|
#### 3.1.1 收集需求
|
|
|
|
收集需求的工具与技术有：用户访谈 、问卷调查、竞品分析、现场观摩、原型法 、联合开发和头脑风暴等 。常用的如下：（1） 竞品分析需求工程师收集市场上同类产品的相关资料，采取迭代的方式获取系统需求。（2） 与干系人沟通用户访谈的一种，由需求工程师直接到用户的工作场所邀请用户及相关人员召开产品需求调研会议， 也可通过线上或线下直接交流系统需求。
|
|
|
|
#### 3.1.2 记录需求
|
|
|
|
需求工程师根据客户处直接获得需求与收集的相关资料，完成《客户访谈记录》并要求客户确认， 确认信息留档备查。
|
|
|
|
### 3.2 需求分析及编写规范
|
|
|
|
10
|
|
|
|
对已完成的《客户访谈记录》应进行汇总分析、划定优先级及每项范围，形成初步的《需求跟踪表》， 以便后续进行需求状态跟踪。对汇总的需求应进行评审分析， 形成《软件需求规格说明书》。
|
|
|
|
#### 3.2.1 需求分析准则
|
|
|
|
需求问题识别是从系统角度理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件及需求应达到的标准 。需求包括： 功能需求(做什么) 、性能需求(要达到什么指标) 、环境需求(如机型,操作系统等) 、可靠性需求(不发生故障的概率） 、接口需求 、安全保密需求 、用户界面需求 、资源使用需求(软件运行是所需的内存， CPU 等) 、开发进度需求 、预先估计以后系统可能达到的目标等。需求分析人员应负责对收集和归纳的需求进行进一步的分析， 主要包括：（1） 分析需求细化合理性： 确定需求是否细化到合理程度， 可作为设计人员进行设计实现的有效依据， 若需要细化， 则进一步调研和归纳。（2） 分析需求可行性：综合成本、性能等因素，分析每项需求实施的可行性，剔除掉不可行的需求；需求实现有风险的，通过风险管理过程进行风险识别和控制。（3） 分析需求优先级： 对需求按高 、 中 、低的优先级进行分类， 优先级是对需求进行裁减或开发工作安排的重要依据。高： 关键的功能特性，不实现意味着无法满足客户的需求。必须在本次项目开发中实现。中： 重要的功能特性， 不实现可能会影响产品的销售和客户满意度 。在时间、资源的压力下， 可以考虑在产品的下一个版本中实现。低： 有用的功能或性能的提高， 不实现不会对产品产生实质性影响， 在时间、资源允许的情况下， 可以考虑在产品的某一版本中实现。（4） 分析需求与产品线关系： 如果项目属于某个产品线， 要求分析并标识功能需求与产品线功能之间的关系， 是新增的 、待优化的 。产品经理/项目经理应分析、评估此需求属于特例，还是共性问题，并根据分析结果，决定作为特定项目需求， 还是整个产品需求来进行管理。11
|
|
|
|
（5） 分析确认各需求描述是否清晰明确、完整、相互一致、可验证、可跟踪。且根据开发和测试过程中提出的需求缺陷进行进一步判断。（6） 分析所归纳的需求是否与合同/立项任务书及附件相一致，若不一致，要提请项目经理注意和处理。上述分析将作为编制或修订《软件需求规格说明书》或《单个模块需求文档》及相关文件的依据。
|
|
|
|
#### 3.2.2 编写需求文档
|
|
|
|
在新项目启动初期，针对整个项目的整体需求，要求需求分析人员按照模板要求编写《软件需求规格说明书》（根据需求，在需求调研和需求归纳时形成文稿并循环修订） ，包括： 整体描述、功能需求 、非功能需求、接口需求等。为便于审核，如果模版中某一特定部分不适用，在原处保留标题，并注明该项不适用。在项目执行过程中，针对用户临时提出的，或部分新增的模块需求，要求需求分析人员按照模板要求编写单个模块需求文档，主要包括：需求背景描述、用户业务功能需求 、非功能需求 、接口需求等。《软件需求规格说明书》中每个需求都要唯一编号，编号参考需求编号规则。需求分析的其它成果，包括需求的优先级、与产品线功能的关系、需求功能点细化结果等， 要求体现在需求书中 。“优先级 ”属性可应用在一个需求点上，也可以应用在一个完整的功能模块上。对于不同类型的需求， 需求细化的程度也不相同。查询统计类需求：须明确查询条件、查询结果以及详细的统计口径。统计口径需要描述到用户或者测试 、实施人员可以验证查询结果是否正确；涉及性能的需求：应该明确性能指标要求，如响应时间、系统用户数、在线用户数 、并发用户数 、吞吐量 、资源利用率等。对于涉及多个岗位流程操作的需求：需要通过流程图来直观展现，至少包括流程图和关键环节说明。外部接口类需求，必须有明确的接口规范，至少包含接口协议字段名称、备选值 、约束条件 、接口性能指标。业务数据类需求， 必须明确输入条件 、计算逻辑和输出结果。12
|
|
|
|
需求小组在对整份需求书的完整性、一致性进行分析的基础上修订《软件需求规格说明书》。
|
|
|
|
### 3.3 需求评审
|
|
|
|
内部评审： 由项目经理负责组织，安排需求工程师、开发工程师、测试工程师 、QA 工程师 、配置工程师等相关干系人， 对《软件需求规格说明书》描述的需求功能的正确性、完整性、清晰性等内容达成一致意见，并更新《需求跟踪表》中需求状态跟踪内容。在内部评审过程中，需求跟踪内容是内部评审的完整性检查点之一。《软件需求规格说明书》编写完毕之后，必须通知用户，发起外部评审，进行需求确认 。如有修改意见， 需求分析人员根据意见对《软件需求规格说明书》或《单个模块需求文档》及其附件进行修改，重新提交用户确认。需求确认可保证需求相关文档的质量， 确保与用户 、产品负责人之间能达成一致理解。需求人员完成需求用户确认后，将《软件需求规格说明书》或《单个模块需求文档》，上传至配置库，并邮件通知相关人员。项目经理组织需求人员给项目组的开发 、测试和实施人员进行讲解 、澄清最终需求。
|
|
|
|
### 3.4 需求验收
|
|
|
|
项目经理组织开发、测试人员对澄清后的《软件需求规格说明书》展开开发、测试任务，该过程要求从需求完整性、需求合规性、需求对既有系统的影响等多个方面，验证需求文档描述是否准确，如果发现需求不完整或存在错误，可提交需求缺陷， 需求分析人员修改完善该需求。需求分析人员收到缺陷后，可以重新针对某条需求进行需求调研、需求分析，修改需求文档后重新请用户确认， 将需求缺陷反馈给提出人员进行验证。需求通过测试后， 项目经理组织需求工程师 、QA 工程师 、配置工程师等内部需求干系人，基于《软件需求规格说明书》描述内容进行功能性验证，若符合说明书描述内容， 则内部验收通过； 反之需提交开发 、测试人员进行需求修复。内部验收通过后，项目经理组织开发、配置人员进行上线发布；根据前期与用户约定的里程碑验收周期和验收版本，项目经理确定是否邀请用户参与上线验13
|
|
|
|
收。用户参照评审通过的《软件需求规格说明书》，依次验证系统功能的完整性和可用性，并反馈验收确认单（项目用户可根据项目实际情况拟定确认单格式）。
|
|
|
|
14
|
|
|
|
## 4 需求变更
|
|
|
|
需求变更控制在《软件需求规格说明书》评审通过后，管理和控制已评审通过需求项的变更， 使需求项在变更情况下是受控的 、可追溯的。从可行性、方便性、可维护性的角度考虑，如果变更在项目可控范围内，则将该变更作为新需求进行处理； 如果变更影响较大， 则提请 CCB 审核， 如果审核通过，则作为新需求进行处理。变更不可避免， 因而必须强制实施某种形式的变更控制。
|
|
|
|
### 4.1 变更申请
|
|
|
|
有需求变更时，变更提出者应向项目经理提出变更申请，项目经理评估变更影响范围，对项目进度、成本的影响。若变更需求是客户提出的，则客户侧的联系人需将变更内容书面给项目经理，客户要有单位盖章或领导签字，无论变更处理结果如何，项目经理须在一周内把变更申请结果答复给变更发起方，对于电子版的变更申请，需存放在配置库的指定路径下，对于纸质的变更申请，必须按照规定的存放办法存放。
|
|
|
|
### 4.2 需求评估 、 审批
|
|
|
|
需求变更应由CCB 负责评估 、上级主管进行审批， 变更结果通知客户和相关干系人。变更评估内容可从涉及变更的配置项、估计工时、成本、可能的风险以及影响范围等角度考虑， 评估 、审批结果应记录到《需求跟踪表（变更） 》。
|
|
|
|
### 4.3 制定计划并执行
|
|
|
|
对于审批同意的需求变更，应将该变更视为一个新需求。需求人员按照本规范要求， 编写《软件需求规格说明书》或《单个模块需求文档》并与用户确认。15
|
|
|
|
项目经理制应定变更工作计划（变更配置项名称及版本、变更进度安排、变更实施人 、变更验证方式）， 项目组依据计划实施变更。
|
|
|
|
### 4.4 验证发布变更
|
|
|
|
需求人员应输出更新后的《软件需求规格说明书》或《单个模块需求文档》变更请求审批表。对于需求配置项，配置工程师应更新《软件需求规格说明书》，并将变更控制表纳入配置库，通知相关受影响人员（包括客户），对于变更范围内的相关修订记录必须记录在配置项变更控制表中直至问题全部关闭。
|
|
|
|
16
|
|
|
|
## 5 需求跟踪
|
|
|
|
需求追踪的目的，在于保证干系人、项目组始终就项目需求达成统一一致的视图；需求追踪的原则，是要保证需求全覆盖，且计划可控。项目组通过维护需求追踪列表来标识需求状态转换，有利于项目整体管控，便于随时掌握项目整体进展。
|
|
|
|
## 1 、需求编号遵循规则如下： [系统标识]_（模块标识）_[编号](_二级编号)
|
|
|
|
（1） []中的内容表示必选， ()中的内容表示可选。（2） 系统标识和模块标识应采用英文缩写或拼音缩写。（3）每个项目可以根据项目的实际情况确定需求编号规则 。需求编号规则要方便于追踪到需求。（4）对于未能确定的需求，可以考虑在编号前加上“TBD_ ”，表示待确定。
|
|
|
|
## 2 、需求应包含以下流程状态：
|
|
|
|
（1） 新需求： 用户提出需求申请。（2） 需求已确认： 该需求已被分析， 用户已经确认该需求。（3） 已开发： 开发组完成系统功能开发， 提交测试。（4） 已测试： 测试组完成系统功能测试 、 回归测试， 达到发布现场条件。（5） 已上线： 系统功能已经发布上线， 用户已经认可该功能 。该需求现在被认为完成。（6） 已验收： 该需求用户侧已验收通过， 可作为需求关闭的标识。
|
|
|
|
## 3 、需求追踪列表填写规范
|
|
|
|
（1） 需求阶段列表的填写需求分析人员负责接收用户或产品线的业务需求申请，并记录到《需求追踪表》中，填写需求名称、用户期望上线时间等内容，需求状态标记为“新需求 ”；需求分析人员完成需求分析，并提请用户确认需求后，将该需求状态更新为“需求已确认 ”， 并填写功能需求编号 、功能需求内容描述等内容。（2） 软件开发 、测试阶段列表的填写开发人员应根据《软件需求规格说明书》， 编制详细设计文档， 开发完成并提交测试后， 将程序文件名记录到需求追踪表， 需求状态更新为“ 已开发 ”。17
|
|
|
|
测试人员应根据需求编写软件测试用例，并将测试用例编号记录到需求追踪列表中。测试人员进行功能测试和回归测试，所有已发现问题均已验证通过，确保没有功能需求被疏漏，确保非功能需求符合要求，更新需求追踪列表中状态为“ 已测试 ”。（3） 版本发布阶段列表的填写需求测试通过后， 实施人员应向用户申请现场发布， 发布成功后， 更新《需求追踪表》， 记录实际上线时间 、上线版本号。版本发布上线后， 需求人员 、实施人员应与用户联系，通知用户进行功能确认 。用户认可该功能后， 填写需求状态项为“ 已上线 ”， 该需求追踪过程结束。（4） 用户验收阶段列表的填写上线后， 应通知用户在生产环境进行测试验收，若验收通过， 则需求分析人员在需求追踪表中更新需求状态为“ 已验收 ”。
|
|
|
|
18
|