需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法。
需求可以定义为:系统必须符合的条件或具备的功能。
需求管理可以定义为:需求管理是一种系统化方法,可用于获取、组织和记录系统需求并使客户和项目团队在系统变更需求上达成并保持一致。
有效需求管理的关键在于维护需求的明确阐述、每种需求类型所适用的属性,以及与其他需求和其他项目工件之间的可追踪性。
需求一般可以分为对下几方面的需求:
No. |
需求种类 |
举例 |
1 |
对时间的需求 |
对项目进度、完成纳期的需求 |
2 |
对质量的需求 |
对缺陷率的需求。 |
3 |
对功能的需求 |
对产品功能的实现方面的需求 |
4 |
对性能的需求 |
对产品性能的要求,如运算速度。 |
5 |
对管理的需求 |
对生产过程的管理的要求,如对使用的流程的要求。 |
6 |
对其它方面的需求 |
略 |
初始需求: 包括客户提出的原始需求与根据客户原始需求开发出的需求,如式样书等。
需求变更: 需求的增加、改变、减少。
对于维护类项目(项目工作就是对应客户各种需求),则可以认为都是需求变更,没有初始需求。
SRS: Software Request Specification
产品式样书:具体的需求
Mail、电话、电视会议等其他方式提出的需求
需求管理的活动有制定需求管理计划、需求记录、需求分析、需求确认、需求承诺、需求实现、需求追溯、度量与分析。
在项目立项后制定项目计划时,制定项目的需求管理计划(包含在项目计划中),内容主要有:
1) 人员与职责
项目方对接受、记录、分析、确认、实现需求人员的规定。
可以不写具体的人名,明确对相关人员的规定即可。
2) 需求管理的方法与模板
需求追溯的方法:命名规则/开发手册
需求管理的方式:使用用什么模板/方法对需求进行管理
需求确认保留方式:如何保留确认记录。
3) 需求承诺的规则
项目可以定义需求承诺的规则来规定的组内如何进行承诺。
记录管理需求。将需求记录到需求管理模板中。
对需求进行分析,内容包括以下几个方面:
1) 技术影响度:该需求是否可以实现,实现后对其他需求有没有什么影响。
2) 工作量估计:实现该需求大约需要多少人时,资源是否足够,是否需要调整计划。
3) 对需求内容的理解、一致性:客户提出的需求内容是否完全可以理解?是否有不明确的地方需要与客户进行确认?
在接受需求时,可以从以下几点来验收需求是否可以被接受。
1) 需求的描述是否清晰,完整。
2) 需求之间是否是一致的,没有矛盾。
3) 需求是否是可以被验证(可测试)的。
4) 需求是否适当,能被完成。
5) 需求是否可实现(考虑技术、资源、时间、质量等因素)
一般来说某个具体需求有以下情况时要对其进行详细的分析。
1) 要采用没有接触过的新技术实现的需求
2) 需求变更范围大,牵涉到多个模块、不同功能的修改
3) 需求实现是对某个底层模块进行的变更。
4) 需求实现会使接口发生改变
5) 市场对应项目,如果是对某个共通功能的需求变更
分析的话可以从以下几个方面来进行:
1) 说明可能影响的功能、模块
2) 说明需求实现后可能产生的Side Effect
3) 说明对策,如需求实现后对某块功能重新进行测试等等
4) 市场对应项目,是否也需要在其他机种上水平展开
确认的主要步骤。
将需求分析结果提交项目负责人进行审核,审核不通过则再分析确认,或直接取消。
审核通过后与客户对分析结果进行确认,消除明显的错误和分歧。
保留确认记录与结果。
将需求确认结果提交项目负责人进行承认。
如需要,根据确认结果调整项目计划。
项目参与人员对需求的实现进行承诺。
需求实现是指根据导出并分析客户、产品或产品组件的需求。
需求追溯的目的。
1) 建立与维护产品从需求-设计-实现-测试式样之间的可追溯性,需求到计划的可追溯性,即纵向的可追溯性。
2) 建立与维护横向的可追溯性。如不同模块、功能、接口互相之间的关系、影响。
需求追溯性分类。
1)纵向可追溯性:
a. 定义<需求追溯文档>将项目中需求的追溯关系描述清楚,需求追溯必须要到功能点。
b. 需求与计划的追溯关系必须明确,即需求与计划中任务安排的相互之间的关系。
2)横向可追溯性:
如某两个模版互相之间的关系,在需求、设计文档中、代码中、测试式样中如何体现。
可以通过以下任何一种方式反应实现需求间的横向关系的追溯,也可以采用以下之外的方式,但必须可查找,有证据。
a. 通过设计式样书,可以以UML图的方式给出各个模块之间的关系
b. 在开发手册中说明
c. 通过命名规则来体现
需求追溯的方式。
1)需求追溯矩阵
利用表格的形式,将某个需求如何对应到相应的设计、代码、测试式样说明清楚。
2)命名规则
项目可以定义命名规则用于实现需求-设计-代码-测试式样的追溯。
3)开发手册
项目可以作成一份开发手册,描述在项目开发中,对每个需要改动的功能的实现应如何修改,有哪些设计,哪些测试用例。此种方法一般比较适合于一些长期的维护类项目。
在项目小结时需要统计如下的度量与分析数据:
需求变更总数:按类别统计:需求添加、需求改动、需求删除。
---------------------------------------------------------------------------
GL(arui319)
http://blog.csdn.net/arui319
《Android应用开发精解》已出版 欢迎购买阅读
本文可以转载,但是请保留以上作者信息。谢谢。
---------------------------------------------------------------------------