信息系统项目管理师考试辅导第14章

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

第14章需求管理14.1大纲要求

本章对应《信息系统项目管理师教程》第17章内容。

考试大纲中对本章的要求有:

•需求基线

•需求变更控制

•需求版本控制

•需求跟踪

根据考试大纲及历年考试情况分析,本章重点知识包括:•需求工程包括需求开发和需求管理

•需求开发的4个阶段

•需求管理的三个目的

•需求规格的版本控制

•需求变更控制委员会的人员组成

•需求跟踪

•需求双向跟踪矩阵

14.2知识结构图

第14章需求管理229 14.3要点详解

14.3.1需求管理概述

需求和需求管理

需求是指由项目接受的或项目产生的产品和产品构件需求,包括由组织征集的对项 目的需求。有技术性的,也有非技术性的。

需求管理的目的是确保各方对需求的一致理解;管理和控制需求的变更;从需求到 最终产品的双向跟踪。

需求工程

需求工程是所有与需求直接相关的活动的通称,它的活动可分为两大类:需求开发 和需求管理。

需求开发的目的是通过调查和分析获取用户需求并定义产品需求。

需求基线:软件项目需求开发的结果应该有项目视图和范围文档、用例文档、软件 需求规格说明及相关分析模型,经评审批准,这些文档就定义了开发工作的需求基线。

需求开发的主要活动:

•需求获取。与用户进行交流,捕捉、分析用户对目标系统的需求,提炼出符合解 决问题的用户需求,产生《用户需求说明书》。

•需求分析。对各种需求信息进行分析并抽象描述,为目标系统建立一个概念模型。

•需求定义。根据需求调查和需求分析的结果,进一步定义准确无误的产品需求,产生《需求规格说明书》。

.需求验证。指开发方和用户共同对需求文档评审,经双方对需求达成共识后作出 书面承诺,使需求文档具有商业合同效果。

需求管理和需求开发密切合作,需求开发涉及把项目关系人的需要转换成产品需求 和决定如何在各个产品构件之间安排或分配需求;需求管理要收集需求的变更和变更的 理由,并且维持对原#需求和所有产品及产品构件需求的双向跟踪。

CMMI中的需求管理流程

CM M I中的需求管理流程如下:

(1)制订需求管理计划。

(2)求得对需求的理解。

(3)求得对需求的承诺。

(4)管理需求变更。

(5)维护对需求的双向跟踪性。

(6)识别项目工作与需求的不一致。

230信息系统项目管理师考试辅导(针对上午考试)

需求属性

除了文本,每个功能需求应该有一些相关的信息或属性与之相联系。这些属性在它 的预期功能性之外为每个需求建立了一个上下文和背景资料。

需求文档中需要考虑的属性包括:

•创建需求的时间。

•需求的版本号。

•创建需求的作者。

•负责认可该需求的人员。

•需求状态。

•需求的原因或根据。

•需求涉及的子系统。

•需求涉及的产品版本号。

•使用的验证方法或接受的测试标准。

•产品的优先级或重要程度。

•需求的稳定性。

14.3.2制订需求管理计划

制订需求管理计划的主要步骤如下:

(1)建立并维护需求管理的组织方针。

(2)确定需求管理需使用的资源。

(3)分配责任。

(4)培训计划。

(5)确定需求管理的项目干系人,并确定介入时机。

(6)制订判断项目工作与需求不一致的准则和纠正规程。

(7)制订需求跟踪性矩阵。

(8)制订需求变更审批流程。

(9)制订审批规程。

14.3.3需求规格的版本控制

需求文档的每个版本必须被统一确定。组织内每个成员必须能够得到需求的当前 版本。

每个公布的需求文档的版本应包括一个修正版本的历史情况,即已做变更的内容、变更日期、变更人的姓名以及变更的原因。

版本控制的最简单方法是根据标准约定手工标记软件需求规格说明的每一次修改。

更高级别的版本控制是使用版本控制工具来存储需求文档。

2

第14章需求管理113 14.3.4需求变更管理

控制项目范围扩展

扩展需求是指在软件需求基线已经确定后又要增添新的功能或进行较大改动。

控制范围扩展的技术:

•把新系统的视图、范围、限制文档化并作为业务需求的一部分,将每一项建议的需求与项目的视图和范围相比较决定是否应该采纳。

•原型法:能够给用户提供预览所有可能的实现,以帮助用户与开发方沟通从而准确把握用户的真实需求。

控制范围扩展的方法是要敢于说“不”。

变更控制过程

变更控制策略有:

•所有需求变更必须遵循的过程,按照此过程,如果一个变更需求未被采纳,则其 后过程不再予以考虑。

•对于未获批准的变更,除可行性论证之外,不应再做其他设计和实现工作。

•简单请求一个变更不能保证能实现变更,要由项目变更控制委员会决定实现哪些变更。

•项目风险承担者应该了解变更数据库的内容。

•决不能从数据库中删除或修改变更请求的原始文档。

•每一个集成的需求变更必须能跟踪到一个经核准的变更请求。

变更控制状态报告是用报告、图表来总结变更控制数据库的内容和按状态分类的变更请求数量。项目管理人员通常使用这些报告来跟踪项目状态。

变更控制过程可以通过自动工具来执行,挑选工具时应该注意以下几个方面:

•可以定义变更请求的数据项。

•可以定义变更请求生存期的状态转换图。

•可以加强状态转换图,使经授权的用户仅能作出所允许的状态变更。

•记录每一种状态变更的数据,确认作出变更的人员。

•可以定义在提交新请求或请求状态被更新后应该自动通知的设计人员。

•可以根据需要生成标准的或定制的报告和图表。

变更控制委员会

变更控制委员会可以由一个小组担任,也可由多个不同的组担任,负责做出决定究 竟将哪一些已建议需求变更或新产品特性付诸应用,其人员可以包括:•产品或计划管理部门

•项目管理部门

•开发部门

相关文档
最新文档