软件需求程序.docx

软件需求程序.docx

《软件需求程序.docx》由会员分享，可在线阅读，更多相关《软件需求程序.docx（11页珍藏版）》请在冰豆网上搜索。

软件需求程序

软件需求程序

1.概述

1.1.目的

本程序文件的目的是进行软件的需求开发和需求管理。

需求开发的目的是通过调查与分析，获取用户需求并定义软件需求。

需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。

1.2.方针

（1）软件需求必须包括用户需求、技术需求及相关的法律、法规需求

（2）项目经理和客户方负责人应进行需求管理知识的培训。

（3）对于自主研发的产品项目，有关客户的活动可以裁减或由实施人员代替

（4）开发、测试、实施等同行专家和用户（包括客户和最终用户，自主研发产品可以使实施经理）应对需求进行评审。

（5）所有被批准的需求必须纳入软件配置管理，当需要变更时，履行需求变更手续。

（6）通过需求管理确保需求得到追踪，保证开发的软件与需求的一致性。

1.3.适用范围

本文件主要适用于本公司所有的软件开发项目。

1.4.角色职责

1.4.1.项目经理

（1）负责组织系统分析师调查、分析用户的需求、定义软件需求

（2）组织对需求的评审

（3）负责控制需求变更

（4）负责跟踪需求

1.4.2.系统分析师

（1）负责调查、分析用户的需求、定义软件需求

（2）参加项目经理组织的需求评审

1.4.3.研发中心经理

（1）负责批准软件需求。

1.5.术语与缩略语

（1）需求文档：

包括“业务需求说明书”、“前景”、“用例规约”、“词汇表”。

（2）设计文档：

包括“软件构架文档”、“数据库设计说明书”、“软件实现规约”及软件界面原型

2.工作程序

2.1.工作流程图

产品需求定义

需求

变更

控制

需求跟踪

需求确认

需求

管理

过程域

输出

输出

用户需求调查

需求

开发

过程域

图1-1需求开发与需求管理流程图

2.2.SR-P-100用户需求调研

责任角色

系统分析师

相关角色

项目经理

过程接口

进入条件

（或过程启动的事件）

“项目任务书”已经下达，并已成立项目组

过程的输入

“项目任务书”

任何与用户需求相关的材料

过程的输出

“业务需求说明书”

退出条件

（或触发其它过程的件）

完成“业务需求说明书”文档，并做了内部审查

2.2.1.SR-A-110调研准备

系统分析师确定需求调查的方式，例如：

（1）与用户交谈，向用户提问题。

（2）参观用户的工作流程，观察用户的操作。

（3）向用户群体发调查问卷。

（4）与同行、专家交谈，听取他们的意见。

（5）分析已经存在的同类软件产品，提取需求。

（6）从行业标准、规则中提取需求。

（7）从Internet上搜查相关资料。

系统分析师与被调查者建立联系，确定调查的时间、地点、人员等。

2.2.2.SR-A-120调查与记录

系统分析师调查用户需求，随时记录调查过程中所获取的需求信息。

2.2.3.SR-A-130分析需求信息

系统分析师分析已经获取的需求信息，消除错误，归纳与总结共性的用户需求。

2.2.4.SR-A-140撰写“业务需求说明书”

系统分析师按照指定的文档模板撰写“业务需求说明书”文档，主要内容包括：

（1）产品介绍；

（2）描述用户群体的特征；

（3）产品应当遵循的标准或规范；

（4）描述产品的功能性需求；

（5）描述产品的非功能性需求，如用户界面、软硬件环境、质量等需求。

补充说明：

调查过程中获取的需求信息可以作为“业务需求说明书”的附件。

2.3.SR-P-200产品需求定义

责任角色

系统分析师

过程接口

进入条件

（或过程启动的事件）

完成“业务需求说明书”文档

过程的输入

“业务需求说明书”

过程的输出

“前景”、“用例模型”、“用例规约”、“词汇表”

退出条件

（或触发其它过程的件）

完成“前景”、“用例模型”、“用例规约”、“词汇表”

2.3.1.SR-A-210确定产品需求

系统分析师对“业务需求说明书”进行分析，确定产品的功能需求及其它需求。

系统分析师根据产品需求编制“前景”文档。

前景的主要内容包括：

（1）软件介绍；

（2）描述用户群体的特征；

（3）定义软件的范围；

（4）阐述软件应当遵循的标准或规范；

（5）定义软件中的角色；

（6）定义软件的功能性需求；

（7）定义软件的非功能性需求，如用户界面、软硬件环境、质量等需求。

2.3.2.SR-A-220建模分析

为帮助软件开发人员更好地理解需求，系统分析师对产品需求进一步细化的建模分析，建立“用例模型”。

建议采用Rational的Rose工具进行需求的建模分析。

2.3.3.SR-A-230细化产品需求

系统分析师根据“业务需求说明书”、“前景”、“用例模型”及其它相关资料对每一个用例编制详细的“用例规约”。

2.4.SR-P-300需求确认

责任角色

系统分析师

相关角色

项目经理

研发中心经理

构架设计师

项目测试主管

测试工程师

项目实施经理

实施工程师

过程接口

进入条件

（或过程启动的事件）

需求文档已经完成

过程的输入

需求文档

过程的输出

“评审记录表”

退出条件

（或触发其它过程的件）

“前景”通过了正式评审并且得到批准，其它需求文档经过了确认。

2.4.1.SR-A-310需求评审

项目经理邀请开发、测试、实施等相关人员（必要时可以邀请同行专家和客户）按《评审程序》的有关要求评审“前景”文档，尽最大努力使需求文档能够正确无误地反映用户的真实意愿。

其它需求文档需要经过项目组的内部确认，必要时也可以进行评审。

2.4.2.SR-A-320获取需求批准

当“前景”文档通过正式的评审之后，研发中心经理对需求文档进行批准。

2.5.SR-P-400需求跟踪

角色

项目经理

过程接口

进入条件

（或过程启动的事件）

需求文档通过了评审，并且获得了批准

设计文档、源代码、“软件测试用例”这些后续工作成果已经部分产生或者全部产生

过程的输入

需求文档、设计文档、源代码、“软件测试用例”

过程的输出

修改后的需求文档和相关后续工作成果

退出条件

（或触发其它过程的件）

已经消除了需求文档与后续工作成果之间的不一致性。

项目经理在开发的后续过程中跟踪需求与设计、开发、测试的双向一致性。

双向跟踪指：

正向跟踪：

检查需求文档中的每个需求是否都能在后续工作成果中找到对应点。

逆向跟踪：

检查设计文档、代码、测试用例等工作成果是否都能在需求文档中找到出处。

当需求文档或后续工作成果发生变更时，项目经理要及时更新需求。

项目经理及时将需求跟踪过程中存在的问题填写在“需求问题处理跟踪表”上并跟踪至关闭。

2.6.SR-P-500需求变更控制

责任角色

系统分析师

相关角色

项目经理

研发中心经理

系统分析师

过程接口

进入条件

（或过程启动的事件）

开发方或客户方提出变更请求时

过程的输入

原需求文档

过程的输出

新需求文档

“需求变更控制报告”

退出条件

（或触发其它过程的件）

新的需求文档已经被确认

2.6.1.SR-A-510需求变更申请

系统分析师撰写“需求变更控制报告”，递交给项目经理或客户方负责人。

“需求变更控制报告”必须阐述：

（1）变更原因；

（2）变更的内容；（3）此变更对项目造成的影响。

2.6.2.SR-A-520审批需求变更申请

项目经理审批“需求变更控制报告”。

如果变更未经批准，则退回变更请求，项目按照原需求文档执行。

如果变更得到批准，则执行SR-A-530。

需求变更申请得到批准后，系统分析师将“需求变更控制报告”交至配置管理员，执行配置管理相应的变更控制流程，具体参见《配置管理程序》。

2.6.3.SR-A-530更改需求文档

系统分析师根据SR-A-510和SR-A-520的要求更改原需求文档，产生新的需求文档。

2.6.4.SR-A-540重新进行需求确认

需求变更后需要项目经理确认，必要时可以重新进行需求评审和批准，参见SR-P-300。

2.6.5.SR-A-640进行关联变更

需要变更完成后，项目经理应及时通知受影响的项目成员，并重新安排受影响的其它关联变更。

3.相关文件

（1）《评审程序》

（2）《配置管理程序》

4.相关记录

（1）“项目任务书”

（2）“业务需求说明书”

（3）“前景”

（4）“用例模型”（UML图）

（5）“用例规约”

（6）“词汇表”

（7）“评审记录表”

（8）“需求问题处理跟踪表”

（9）“需求变更控制报告”

（3）“软件构架文档”

（4）“数据库设计说明书”

（5）“软件实现规约”

（10）软件界面原型（一般为HTML文件）

（11）“软件测试用例”