1概述
需求开发是产生和分析顾客需求、产品需求和产品组件需求。
需求管理的目的是维护需求并且确保能把对需求的更改反映到项目计划、活动和工作产品中。
本过程文件适用于全校项目的需求开发和管理活动。
2引用文件
3术语
本标准采用GJB 5000A-2008《军用软件能力成熟度模型》附录A 术语。
3.1正向跟踪
检查需求文档中的每个技术性需求是否都能在后续工作成果中找到对应点。
3.2逆向跟踪
检查设计文档、代码、测试用例等工作成果是否都能在需求文档中找到出处。
4角色与职责
本过程的人员角色与职责如表1所示。
表1 需求开发与管理过程角色与职责
角色 | 职责 |
客户方和用户方代表 | ●获得所在单位授权提供需求 ●协助需求开发人员进行需求开发活动 ●确认客户需求 ●提出客户需求变更 |
项目负责人 | ●提交客户需求变更申请 ●组织实施需求变更 ●负责需求在开发过程中的跟踪及控制 ●计划与监督软件需求开发活动 ●组织需求评审和需求确认 |
需求开发组 | ●负责客户需求开发与分析,编制《客户需求规格说明书》 ●负责软件需求开发与分析,编制《软件需求规格说明书》 ●参与需求在开发过程中的跟踪及控制 |
项目研发组 | ●协助需求开发人员进行需求开发 ●参与需求评审 |
项目测试组 | ●参与需求评审,编制确认测试方案初稿 |
项目CM | ●建立和发布需求基线 |
CCB | ●项目CCB批准软件需求及其变更 ●校CCB批准客户需求及其变更 |
5入口准则
1)项目任务已经下达;
2)已接收到客户提出的需求;
3)项目组成员等受到了需求开发与管理过程所需的培训。
6输入
1)立项申请的相关文档
2)《科研项目任务书》
7过程活动实施
需求开发与管理流程如图1所示。
图1 需求开发与管理过程流程图
7.1开发客户需求
开发客户需求是指产出并分析客户需求。开发客户需求说明如表2所示。
表2 开发客户需求活动说明
入口准则 | 《科研项目任务书》已经下达。 | |
过程活动 | A01 确定项目范围 | 需求开发人员对项目的业务流程进行分析,明确项目需要涉及的业务流程和职能部门。 |
A02 确定用户类别 及其代表 | 需求开发人员根据用户使用产品的频度、所属的应用领域、实施的业务过程、所属的职能部门及访问权限对用户进行分类,并选择每类用户的代表,明确用户需求决策者。 | |
A03 制定需求调研计划 | 需求开发人员根据客户的要求和用户的分类,按照《需求开发指南》确定调研方式,制定需求调研计划,并与相关的客户和用户进行沟通确认。 | |
A04 执行需求调研计划 | 需求开发人员按照需求调研计划对相关的客户和用户进行调研,将客户原始需求记录在《客户需求调查单》中。 | |
A05 整理分析客户需求 | 需求开发人员依据《客户需求调查单》,对原始需求进行整理分析,并向客户方逐一讲解对需求的理解,跟客户达成一致,形成《客户需求调研记录》。 | |
A06 定义客户需求 | 需求开发人员按照模板要求编制《客户需求规格说明书》。 | |
A07 评审客户需求 | 项目负责人依据《同行评审规程》组织评审《客户需求规格说明书》,客户代表和用户代表、需求开发组、项目研发组、项目测试组的相关人员参加,从而确保相关人员对客户需求的理解,达成对需求的共识,获得客户对需求的承诺。 | |
A08 确认客户需求 | 如果客户代表和用户代表没有参加对《客户需求规格说明书》的评审,项目负责人需要组织人员提交相关客需文档给客户签字确认,以取得客户对需求的承诺。 | |
A09 创建与维护 需求跟踪 | 客需文档经过确认后,项目负责人或需求开发人员按照模板要求创建《需求跟踪矩阵》和《需求状态跟踪表》。 当各阶段产品完成时,项目负责人或需求开发人员根据《需求跟踪矩阵》选择跟踪方法(正向跟踪、逆向跟踪)进行需求跟踪。每次跟踪活动结束后,项目负责人或需求开发人员需要更新《需求跟踪状态表》。 项目负责人或需求开发人员对《需求跟踪矩阵》和《需求状态跟踪表》定期(建议每周)进行审查。 | |
A10 建立、审批和发布客需基线 | 客需文档经过确认后,项目CM按照《配置管理过程》申请建立客户需求基线,提交给项目CCB上报校CCB审批,审批通过后,项目CM发布客需基线。 | |
出口准则 | 1)《客户需求规格说明书》已经确认; 2)《需求跟踪矩阵》和《需求状态跟踪表》已经创建; 3)客户需求基线已经建立和发布。 | |
裁剪指南 | 1)若上级单位或客户通过项目合同或技术规格说明书等文件直接标明客户需求时,可以裁剪A01-A06活动和工作产品。 2)总体单位或使用单位提出文档模板要求,按其文档模板要求实施。 3)根据项目选择的生命周期模型,来确定需求跟踪关系,根据项目已定义过程来对A8活动的工作产品内容进行裁剪。 |
7.2开发软件需求
开发软件需求是指产出并分析软件需求,开发软件需求说明如表3所示。
表3 开发软件需求活动说明
入口准则 | 1)《科研项目任务书》获批发布; 2)《客户需求规格说明书》已经确认。 | |
过程活动 | B01 选择需求分析的方法和工具 | 项目负责人依据《需求开发指南》组织需求开发人员选择需求分析的方法和工具,建议使用的需求分析方法包括:结构化分析法、面向对象分析法和快速原型法等。 |
B02 确定产品功能结构 | 需求开发人员依据《客户需求规格说明书》确定产品功能及其相互关系,建立产品功能结构。 | |
B03 定义功能需求 | 需求开发人员详细描述产品的每个功能需求,包括功能名称、目标、作用,功能的输入、处理、输出等内容。 | |
B04 建立操作概念 和场景 | 需求开发人员通过绘制用例图、时序图、数据流图等方法来建立软件的操作场景和概念,用以细化功能需求。 | |
B05 定义接口需求 | 需求开发人员定义功能需求(子系统与子系统、模块与模块)之间的行为联系,以及本软件与硬件或支持软件之间的接口关系要求,即定义内外部接口需求。 | |
B06 定义非功能需求 | 需求开发人员定义非功能需求,包括性能需求、环境需求、可靠性需求、安全性要求、界面友好性需求等内容。 | |
B07 确定需求优先级 | 需求开发人员根据客户要求和项目的实际情况对产品的需求进行优先级排序。 | |
B08 创建软件需求规格说明书 | 需求开发人员按照模板要求编制《软件需求规格说明书》。 | |
B09 评审软件需求 | 项目负责人依据《同行评审规程》组织评审《软件需求规格说明书》,需求开发组、项目研发组、项目测试组的相关人员参加,必要时客户代表和用户代表参加评审。从而确保相关人员对软件需求的理解,达成对需求的共识。 | |
B10 更新和维护需求跟踪,标识并解决不一致性问题 | 《软件需求规格说明书》评审通过后,项目负责人或需求开发人员更新和维护《需求跟踪矩阵》和《需求状态跟踪表》。 后续阶段工作产品评审时,项目负责人组织人员标识并解决项目计划、软件设计、源代码、测试用例等与需求之间的不一致性。 | |
B11 建立、审批和发布软需基线 | 《软件需求规格说明书》评审通过后,项目CM按照《配置管理过程》申请建立软件需求基线,提交项目CCB审批,审批通过后,项目CM发布软需基线。 | |
B12 编制确认测试方案初稿 | 项目测试组依据评审后的《软件需求规格说明书》,编制确认测试计划和确认测试说明初稿。 | |
出口准则 | 1)《软件需求规格说明书》已经通过评审; 2)《需求跟踪矩阵》和《需求状态跟踪表》已经更新,并消除了不一致性; 3)软件需求基线已经建立和发布。 | |
裁剪指南 | 活动不可裁剪。 |
7.3需求变更
需求变更管理是在项目的开发过程中,完成客需的确认后,当需求发生更改时,对需求变更进行控制和管理的活动。需求变更应进行相应级别的审批、并得到变更申请人的确认。需求变更活动说明如表4所示。
表4 需求变更活动说明
入口准则 | 需求发生变更。 | |
过程活动 | C01 申请提交需求变更 | 当需求变更时,变更申请人与项目负责人进行沟通后提交变更申请,提交给项目项目CCB。 |
C02 审批变更请求 | 项目CCB接收到变更申请后,组织进行变更影响分析,批准变更或提交校CCB进行审批。(软需变更需要项目CCB审批、客需变更需要校CCB审批)。 | |
C03 实施并确认 需求变更 | 项目CM从受控库检出配置项后交给项目负责人指定的变更实施人实施变更,变更完成后,项目负责人组织相关人员对变更后的需求进行评审,维护需求跟踪矩阵和需求状态,同时标识由于需求变更导致计划和工作产品所需的更改。必要时(客需变更)客户方代表和用户方代表参加对需求变更的确认。 | |
出口准则 | 需求变更已经确认。 | |
裁剪指南 | 无 |
8出口准则
1)客户需求和软件需求已通过评审,并纳入配置管理;
2)《需求跟踪矩阵》和《需求状态跟踪表》已经建立并得到了跟踪;
3)已经消除了后续工作产品、计划与需求间的不一致性。
9输出
1)《客户需求调查单》
2)《客户需求调研记录》
3)《客户需求规格说明书》
4)《软件需求规格说明书》
5)《需求跟踪矩阵》
6)《需求状态跟踪表》
7)《需求规格说明检查单》
8)《专家预审表》
9)《同行评审报告》
10)《基线建立及审批表》
11)《基线发布报告》
12)《确认测试计划》
13)《确认测试说明》
14)《变更申请及确认表》
15)《问题跟踪表》
16)《配置项状态记录》
附录 A 体系文件与GJB5000A标准映射表
体系文件与GJB5000A标准的映射关系如表A1所示。
表A1 体系文件与GJB5000A标准的映射表
序号 | GJB5000A标准简要描述 | 体系文件过程描述 | 对应规程及模板 | ||||
RD 专用实践 | |||||||
1 | SP 1.1 引出需要 | 7.1开发客户需求 | 《需求调研计划》 《客户需求调查单》 《客户需求调研记录》 | ||||
2 | SP 1.2 开发顾客需求 | 7.1开发客户需求 | 《客户需求规格说明书》 | ||||
3 | SP 2.1 确定产品需求和产品部件需求 | 7.2开发软件需求 | 《软件需求规格说明书》 | ||||
4 | SP 2.2 分配产品部件需求 | 7.2开发软件需求 | 《软件需求规格说明书》 | ||||
5 | SP 2.3标识接口需求 | 7.2开发软件需求 | 《软件需求规格说明书》 | ||||
6 | SP 3.1 制定运行方案和场景 | 7.2开发软件需求 | 《软件需求规格说明书》 | ||||
7 | SP 3.2 建立必需功能性的定义 | 7.2开发软件需求 | 《软件需求规格说明书》 | ||||
8 | SP 3.3 分析需求 | 7.2开发软件需求 | 《软件需求规格说明书》 | ||||
9 | SP 3.4 分析需求以达到平衡 | 7.2开发软件需求 | 《软件需求规格说明书》 | ||||
10 | SP 3.5 确认需求 | 7.1开发客户需求 7.2开发软件需求 | 《客户需求规格说明书》 《软件需求规格说明书》 | ||||
ReqM 专用实践 | |||||||
1 | SP 1.1 获得对需求的理解 | 7.1开发客户需求 7.2开发软件需求 | 《需求规格说明检查单》 《专家预审表》 《同行评审报告》 | ||||
2 | SP 1.2 获得对需求的承诺 | 7.1开发客户需求 7.2开发软件需求 | 《需求规格说明检查单》 《专家预审表》 《同行评审报告》 | ||||
3 | SP 1.3 管理需求更改 | 7.3需求变更 | 《变更申请及确认表》 《配置项状态记录》 | ||||
4 | SP 1.4 维护需求的双向可追溯性 | 7.1开发客户需求 7.2开发软件需求 7.3需求变更 | 《需求跟踪矩阵》 《需求状态跟踪表》 | ||||
5 | SP 1.5 标识项目工作与需求间的不一致 | 7.2开发软件需求 7.3需求变更 | 《问题跟踪表》 | ||||
RD ReqM 共用实践 | |||||||
1 | GP2.1制定组织方针 | 总则与方针 | |||||
2 | GP2.2策划此过程 | 项目策划 | 《软件开发计划》 | ||||
3 | GP2.3提供资源 | 项目策划 | 《软件开发计划》 | ||||
4 | GP2.4指派职责 | 项目策划 | 《软件开发计划》 | ||||
5 | GP2.5培训人员 | 组织培训过程 | |||||
6 | GP2.6管理配置 | 配置管理过程 | 《配置管理计划》 《配置项管理记录》 | ||||
7 | GP2.7标识并吸纳利益相关方 | 项目策划过程 | 《软件开发计划》 | ||||
8 | GP2.8监督并控制此过程 | 项目监控过程 | 《项目周报》 | ||||
9 | GP2.9客观评价遵循性 | 过程与产品质量保证过程 | 《QA审查报告》 | ||||
10 | GP2.10与更高层管理者一起评审状态 | 中高层验证规程 | 《会议纪要》 | ||||
11 | GP3.1建立已定义过程 | 项目策划 | 《项目定义过程》 | ||||
12 | GP3.2采集改进信息 | 软件过程改进与管理过程 | 《大学改进建议及反馈表》 《大学过程改进建议汇总表》 | ||||
联系我们
Contact us