需求开发过程.docx
- 文档编号:28300095
- 上传时间:2023-07-10
- 格式:DOCX
- 页数:12
- 大小:111.03KB
需求开发过程.docx
《需求开发过程.docx》由会员分享,可在线阅读,更多相关《需求开发过程.docx(12页珍藏版)》请在冰豆网上搜索。
需求开发过程
需求开发过程
当前版本
1.0
密级
机密
文档编号
总页数
10
正文页数
附录页数
编制人
李晓杰
评审人
林柏
批准人
陈迪
编制日期
2013.10.23
评审日期
2014.01.10
批准日期
2014.01.14
四川启明星蜀达电气有限公司
修改履历
序号
状态
版本
修改内容
修改
位置
修改人
日期
评审人
日期
批准人
日期
1
C
1.0
创建文档
李晓杰
林柏
陈迪
2013.10.23
2014.01.10
2014.01.14
4
5
6
7
8
9
10
11
12
13
14
15
16
17
状态:
C—创建文档,A—增加内容,M—修改内容,D—删除内容
目录
1目的3
2范围3
3术语3
4参考资料3
5角色与职责3
6流程图5
7流程描述5
7.1需求开发准备5
7.2开发客户需求6
7.3开发产品需求7
8附录9
1目的
本文档描述需求开发过程,用以指导整个生命周期的需求开发活动。
2范围
本文档适用于项目整个生命周期与需求开发有关的活动。
3术语
术语
描述
操作概念(operationalconcept)
对每一个实体使用方法的全面描述。
场景(scenario)
用于描述行为、按特定顺序排列的动作序列。
可用来描述系统用户与系统之间的交互行为或执行行为,也可以理解为用例的实例。
4参考资料
NO
文档名称
1
《CMMI-DEVVersion1.2》
5角色与职责
角色
职责描述
高层经理
●评审、批准用户需求、产品需求、产品构件需求、接口、产品需求规格说明书等过程产品,并参与本过程域重要的活动
●解决在实施本过程域中所遇到的无法解决的问题
项目经理
(项目经理或者产品经理)
●为需求开发工作提供各种必要的环境和条件
●制订需求调研计划,并跟踪维护该计划
●负责联系用户和需求分析员进行需求开发的分析工作
●参与评审本过程域的工作产品
●完成或协助完成本过程域的工作产品
●向高层经理报告本过程域的实施情况
●跟踪需求开发工作完成情况
需求人员
●收集、分析、细化、导出和描述用户需要、期望、约束和接口,并把它们转换成用户需求
●按时完成项目经理指定的工作产品
●参与评审本过程域有关工作产品
●把用户需求转换为产品、产品构件和接口的需求
●对用户、产品、产品构件需求进行确认
开发人员
●和需求人员共同分配产品构件需求和产品构件接口需求
测试人员
●参与需求评审。
项目级配置管理员
●负责在本过程所涉及的配置管理工作
QA工程师
●审计本过程域的活动和工作产品,并确保不符合问题得到解决
度量分析工程师
●负责在本过程所涉及的度量工作
客户
●提供用户需求和确认用户的潜在需求
●如何需要参与用户需求说明书、产品需求规格说明书的评审
●提供操作概念和场景
6流程图
7流程描述
7.1需求开发准备
进入条件
1
已批准立项
2
需求变更通过审批
输入
1
立项材料
2
变更后的需求项
步骤
1
项目经理制定《需求调研计划》,确定需求调研的方式,时间,地点,参加人员等,并定义不同时期要提交的工作产品
2
需要时项目经理组织人员对参加需求调研的人员进行需求调研培训,确保参加需求调研的人员掌握项目需求调研的方法;
3
项目经理就《需求调研计划》内容与客户进行沟通并达成一致,并确定客户代表和客户方的需求负责人。
输出
1
需求调研计划
退出条件
1
需求调研计划得到客户认可,并与相关需求人员确认。
7.2开发用户需求
进入条件
1
已批准立项
2
需求变更通过审批
输入
1
立项材料
2
变更后的需求项
3
需求调研计划
步骤
1
项目经理按《需求调研计划》与客户或相关人员联系并确定进行需求获取的时间,地点及人员。
2
项目经理确定或任命具体的需求负责人,可以是自己或者需求人员。
3
抽取用户需求,在实施需求调研的过程中,按项目的行业、规模和属性不同,需求负责人可以采用不同的方法或综合使用多种方法、分多次进行来获取需求。
抽取用户需求的过程如下:
●进行抽取用户需求的前期准备工作。
包括准备调查问卷、准备访谈内容、对目前市场上的产品或竞争产品进行调研、对政府或行业法规进行研究等。
●访问客户以获得需求。
主要的活动包括:
与客户进行直接交流、让有关客户填写调查问卷、观察正在工作的用户等。
●如果客户当前已在使用一个类似的产品,则需要了解当前客户使用的情况,收集用户在使用过程中所遇到问题,以及用户关于产品改进的想法。
●如果已经开发了新产品的原型,或已有类似的产品,则通过向用户演示该系统,搜集用户的意见。
●将每次抽取得到的需求整理写入《需求调研记录》,并与客户及需求负责人进行书面的确认。
4
每次完成一次需求抽取,应与客户确认《需求调研记录》,没有问题后才开始下一次需求抽取;对于暂时无法确定的问题则标记为项目问题,在以后的过程中进行跟踪解决。
5
撰写《用户需求说明书》:
在所有需求获取过程结束后,整理所有确认后的需求内容,消除其中的矛盾之处,并对其中不一致的地方进行协调和平衡。
6
对《用户需求说明书》进行的确认。
项目经理安排客户代表或客户需求负责人及有关项目人员对《用户需求说明书》进行评审。
输出
1
用户需求说明书
退出条件
1
客户已签字确认用户需求说明书
7.3开发产品需求
进入条件
1
用户需求已经过用户确认
输入
1
用户需求说明书
步骤
1
细化并分析用户需求。
需求人员对《用户需求说明书》进行细化,以便产生详细的产品需求。
需求人员对比较复杂的用户需求进行建模分析,以帮助软件开发人员更好地理解需求。
可以采用的分析步骤有:
●建议使用RationalRose、BorlandTogether、MSVisio等建模工具进行需求的建模分析,通过分析系统的功能模型、结构模型和行为模型,进行系统建模。
建模的过程包括系统功能建模、系统数据建模和体系结构建模,在需求开发阶段应至少完成功能建模。
功能建模的方式包括静态建模和动态建模。
静态建模要求画出用例图、主要的类图和对象图,动态建模要求画出主要的状态图、时序图、协作图和活动图等。
另外在用例图中,需标明每个用例的业务描述、业务数据、业务流程、入口条件、输出结果、异常处理等要素。
●分析可行性:
在允许的时间、成本、性能要求下,分析每项需求实施的可行性,明确与每项需求实现相联系的风险,包括与其它需求的冲突,对外界因素的依赖和技术障碍。
●确定需求优先级:
确定使用实例、产品特性或单项需求实现的优先级别。
可根据该需求的价值、实现的费用和风险等方面综合评估,可以在这里给出一个优先级分类的参考,比如定义出3级,每级代表什么…。
以优先级为基础确定产品版本将包括哪些特性或哪类需求。
当允许需求变更时,在特定的版本中加入每一项变更,并在该版本计划中做出需要的变更。
将需求的优先级信息记录到项目需求文档中。
2
根据需要建立系统原型。
当开发人员或客户不能确定需求时,开发一个系统原型,这样使得许多概念和可能发生的事更为直观明了。
用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。
注意要找出需求文档与原型之间所有的冲突之处。
3
撰写《产品需求规格说明书》。
需求人员按照指定的文档模板撰写《产品需求规格说明书》。
4
评审产品需求规格说明书
输出
1
评审通过的产品需求规格说明书
2
评审记录
退出条件
1
产品需求规格说明书评审通过
1
8附录
无
9
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 需求 开发 过程