信息系统项目管理师考试辅导教程第3版第27章需求管理资料.docx
- 文档编号:26994937
- 上传时间:2023-06-24
- 格式:DOCX
- 页数:18
- 大小:24.78KB
信息系统项目管理师考试辅导教程第3版第27章需求管理资料.docx
《信息系统项目管理师考试辅导教程第3版第27章需求管理资料.docx》由会员分享,可在线阅读,更多相关《信息系统项目管理师考试辅导教程第3版第27章需求管理资料.docx(18页珍藏版)》请在冰豆网上搜索。
信息系统项目管理师考试辅导教程第3版第27章需求管理资料
基线(Baseline)有时也称为基准,分别有需求基线(信息系统需完成哪些开发内
容)、进度基线(完成各项任务活动的具体时间计划)、成本基线(完成各项任务活动的
具体费用预算)等。
有了基线,才有了控制的基础,才能在其上做好变更控制,否则变
更控制无从谈起。
按照PMI(国际项目管理协会)的理论,项目整体计划是项目总的基
线,WBS(工作分解结构)是范围的基线(也就是需求的基线)、项目进度是时间的基
线、成本计划是成本的基线。
变更控制要保证这些基准的健全性。
下面以一个软件开发
项目的需求基线为例,阐述一下基线的应用和重要性。
开发一个销售订单管理的软件系统项目时,经过调研、细化、评审后的功能和范围
说明书经过各方(包括甲乙方)签字后生效,注意此时的需求说明书就是需求基线,有
关需求后续的控制和管理都在此基础上进行。
如在项目实施过程中,甲方用户需要增加
在原来的功能和范围说明书中没有的财务管理模块,此时就涉及变更控制,如果变更后
的需求与基线的偏差不大,可不另收费及项目进度不会拖延;如偏差太大,就会另收费
用或再开一个新项目或项目进度延迟。
由此可见,在项目开始时就应指定严格的变更控
制办法,规定变更如何评估、如何审批、如何收费等,否则项目范围越做越大、时间越
拖越长、费用越来越多,不能保证成本、进度和质量得到有效控制,给项目的成功带来
许多风险。
如果经过变更与最初的基线有了很大偏差,就需要增加费用或另开一个新项
目。
在事先与客户约定一个变更需求的收费标准,可避免项目的成本风险。
通过上面例子描述,信息系统的某一正式版本的、经过项目各方签字确认的、用来
作为项目各计划制订基础依据的需求说明书就是项目的需求基线。
下节将重点阐述需求
说明书如何编写及格式规范。
27.1需求获取活动的组织
需求说明书的基线交付,是整个信息系统(特别是软件开发项目)建设中多个重要
里程碑中的第一个,因为这是后续进度计划、人力资源计划、成本计划等的基础依据。
但这里需要强调的是,在需求管理中,我们强调的是需求获取的过程,需求说明书非常
重要,但由于只是需求获取这一重要活动的输出成果和交付物,所以下面重点围绕如何
组织需求获取活动来获得有效、正确的需求进行阐述。
1.成立需求分析小组
首先成立需求分析小组,提供办公设备,明确责任,启动任务,该小组的成员主要
由业务专家和部分技术专家组成,包括客户和项目承建商两方面的人员,一控制在
10人以内,主要由客户方人员组成。
此小组的任务是全面调查、分析、引导、挖掘客
户对项目实现功能的需求,并进行沟通、协调、妥协和平衡,最终得到各方签字认可的
需求说明书,用于进行项目的后续开发建设。
这里需要强调的是,需求分析小组一定要
由客户方的业务人员参与,而且其对系统具体功能有一定的决策权。
2.做好准备工作,包括准备相应文档和帮助客户了解相关技术和项目管理知识
需求分析小组的需求分析人员同用户的需求提供人员正式接触前,应制订完成一个
访谈人员计划列表和针对不同类别人员的问询表。
通常问询表包含以下内容:
用户为明
确需求已经完成的文档情况,业务的目的,当前的目标,长远的目标,当前准备情况,
完成的业务功能列表,将来系统操作人员的业务及电脑技术了解情况,最终操作用户,
当前及将来的硬件、软件及网络环境等整体问题,当然针对不同人员侧重点不一样,需
要做相应的增加和删除修改。
很多时候,客户并不明白,或不能一次性地描述清楚他们确实需要什么,需求分析
人员的主要作用是同客户紧密合作并帮助他们找出其需求的明确要求,这可通过培训客
户来改善,即让客户对所涉及的技术问题有所理解,包括项目中的技术问题是什么,可
交互何种产品来体现这些技术,交互产品的功能如何,有何局限性等。
另外,对客户进
行项目管理基础教育也大有益处,以便他们可以更好地理解来如何说明需求,并要使客
户认识到其需求变化是很自然的,这些变化会增加项目正常管理的成本。
这样,通过进
一步了解项目中产生的问题,客户会明白自己在定义需求时的责任是什么,从而更好地
配合需求分析人员的工作。
3.访谈用户获取问题
(1)了解和划分客户方的所有用户类型,以及潜在的类型。
然后,根据他们的要
求来确定系统的整体目标和系统的工作范围。
为避免出现疏忽某一用户群需求的情况,
需要将可能使用产品的客户分成不同组别,他们可能在使用频率、使用特性、优先等级
或熟练程度等方面都有所差异,详细描述出他们的个性特点及任务情况,将有助于产品
设计。
(2)选择每类用户的代表,对其进行访谈和调研。
为每类用户至少选择一位能真
正代表他们需求的人作为那一类用户的代表并做出决策。
交流的方式可以是会议、电话、
电子邮件、小组讨论、模拟演示等不同形式。
需要注意的是,每一次交流一定要有记录,
对于交流的结果还可以进行分类,便于后续的分析活动。
例如,可以将需求细分为功能
需求、非功能需求(如响应时间、平均无故障工作时间、自动恢复时间等)、环境限制、
设计约束等类型:
(3)需求分析人员对收集到的用户需求做进一步的分析和整理。
对用户提出的每
个需求都要知道“为什么”,并判断用户提出的需求是否有充足的理由;将那种以“如
何实现”的表述方式转换为“实现什么”的方式,因为需求分析阶段关注的目标是“做
什么”,而不是“怎么做”;分析由用户需求衍生出的隐含需求,并识别用户没有明确提
出来的隐含需求,这一点往往容易忽略掉,经常因为对隐含需求考虑得不够充分而引起
需求变更。
(4)需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关
人员。
大家共同确认需求分析人员所提交的结果是否真实地反映了用户的意图。
需求分
析人员在这个任务中需要执行下述活动:
•明确标识出那些未确定的需求项(在需求分析初期往往有很多这样的待定项);
•使需求符合系统的整体目标;
•保证需求项之间的一致性,解决需求项之间可能存在的冲突。
4.需求分析
在很多情形下,分析用户需求是与获取用户需求并行的,主要通过建立模型的方式
来描述用户的需求,为客户、用户、开发方等不同参与方提供一个交流的渠道^这些模
型是对需求的抽象,以可视化的方式提供一个易于沟通的桥梁。
用户需求的分析与获取
用户需求有着相似的步骤,区别在于分析用户需求时使用模型来描述,以获取用户更明
确的需求。
分析用户需求需要执行下列活动:
(1)以图形表示的方式描述系统的整体结构,包括系统的边界与接口;
(2)通过原型、页面流或其他方式向用户提供可视化的界面,用户可以对需求做出
自己的评价;
(3)系统可行性分析,需求实现的技术可行性、环境分析、费用分析、时间分析等;
(4)以模型描述系统的功能项、数据实体、外部实体、实体之间的关系、实体之间
的状态转换等方面的内容。
5.需求说明书编写
此项工作是根据系统目标和访谈结果编写内容明确的、结果可验证的、相互一致的
需求说明书。
这里需要强调的是,需求说明书的编制是一个渐进明细的过程。
第15.2
节《需求说明书编制》更加详细地描述本点内容。
6.需求验证和评审
需求验证是为了确保需求说明书准确、完整地表达必要的质量特点。
这里需要强调
的是在需求验证过程和评审过程中,客户的参与是非常重要的。
对需求文档进行正式审
查是保证软件质量的有效方法,组织一个由分析人员、客户、设计人员、测试人员等组
成的小组,对其进行仔细的检查和评审。
如果有必要的话,还可以组织公司外的、行业
内的专家评审。
一的评审分为用户评审和同行评审两类。
用户和开发方对于软件项目内容的描
述,是以需求规格说明书作为基础的;用户验收的标准则是依据需求规格说明书中的
容来制订,可见,评审需求文档时用户的意见是第一位的。
而同行评审的目的,是在软
件项目初期发现那些潜在的缺陷或错误,避免这些错误和缺陷遗漏到项目的后续阶段。
7.需求定稿建立基线
经过多次评审后的需求说明书,在某一版本上定稿,作为需求管理的基线,今后的
变更和修改在此基础上按照变更控制流程进行。
本步工作做得较少,但很重要,因为其
确定了基线。
8.管理和控制需求变更
当完成需求说明书后,需求的变更是不可避免的,如何以可控的方式管理软件的需
求,对项目的顺利进行有着重要的意义。
对于需求变更的管理,则主要使用需求变更流
程和变更控制委员会两个手段来实现。
需要对每项变更带来的潜在影响及可能的成本费
用、进度质量进行评估,变更控制委员会应与项目风险承担者进行协商,以确定哪些需
求可以变更。
同时无论在开发阶段还是测试阶段,每项变更和需求都是可跟踪的。
27.2需求说明书的编制
需求规格说明书也称为功能规格说明、需求协议或系统规格说明,它精确地阐述了
一个软件系统必须提供的功能和性能,以及它所要考虑的限制条件。
需求规格说明书不
仅是开发设计的依据,而且是系统测试和用户文档的依据,也是所有子项目规划、设计
与编码的基础。
它应该完整地描述系统预期的外部行为和用户可视化行为。
高质量的需
求说明书应该具有完整性、一致性、可修改性、可跟踪性4个特点:
(1)完整性。
不能遗漏任何必要的需求信息。
遗漏需求将很难查出。
注重用户的任
务而不是系统的功能将有助于避免不完整性。
如果知道缺少某项信息,用TBD(待确定)
作为标准标识来标明这项缺漏。
在开始开发之前,必须解决需求中所有的TBD项。
(2)—致性。
一致性是指与其他软件需求或高层(系统、业务)需求不相矛盾。
在开发前必须解决所有需求间的不一致部分。
只有进行一番调查研究,才能知道某一项
需求是否确实正确。
(3)可修改性。
在必要时或为维护每一需求变更历史记录时,应该修订SRS。
这
就要求每项需求独立标出,并与别的需求区别开来,从而无二义性。
每项需求只应在
SRS中出现一次,这样更改时易于保持一致性。
另外,使用目录表、索引和相互参照
列表方法将使软件需求规格说明更容易修改。
(4)可跟踪性。
应能在每项软件需求与它的根源和设计元素、源代码、测试用例
之间建立起链接链,这种可跟踪性要求每项需求以一种结构化的,粒度好(Fine-Grained)
的方式编写并独立标明,而不是大段大段地叙述。
需求说明书的编写应该遵循以下几个原则:
(1)采用SRS模板。
在需求说明书的组织中要为编写软件需求文档定义一种标准
模板。
该模板为记录功能需求和各种其他需求相关的重要信息提供了统一的结构。
注意,
其目的并非是创建一种全新的模板,而是采用一种已有的且可满足项目需求并适合项目
特点的模板。
许多组织一开始都采用ffiEE标准830-1998(IEEE1998)描述的SRS模
板。
要相信模板是很有用的,但有时要根据项目特点进行适当改动。
(2)指明需求的来源。
为了让所有项目风险承担者明白SRS中为何提供这些功能
需求,要都能追源每项需求的来源,这可能是一种使用实例或其他客户需求,也可能是
某项更高层系统需求、业务规范、政府法规、标准或别的外部来源。
(3)为每项需求注上标号。
制订一种惯例来为SRS中的每项需求提供一个独立的
可标识的标号或记号。
这种惯例应当很健全,允许增加、删除和修改。
做了标号的需求
使得需求能被跟踪,记录需求变更并为需求状态和变更活动建立度量。
(4)记录业务规范。
业务规范是指关于产品的操作原则,比如,谁能在什么情况
下采取什么动作。
将这些编写成SRS中的一个独立部分,或一个独立的业务规范文档。
某些业务规范将引出相应的功能需求;当然这些需求也应能追溯相应业务规范。
(5)创建需求跟踪能力矩阵。
建立一个矩阵把每项需求与实现、测试它的设计和
代码部分联系起来。
这样的需求跟踪能力矩阵同时也把功能需求和高层的需求及其他相
关需求联系起来了。
在开发过程中建立这个矩阵,而不要等到最后才去补建。
下面是一个常见的需求说明书模板,供读者参考:
1.前言
1.1目的
1.2范围
1.3定义、缩写词、略语
1.4参考资料
2.项目概述
2.1产品描述
2.2产品功能
2.3用户特点
2.4一约束
3.5假设和依据
4.功能需求
4.1功能需求1
4.1.1引言
4.1.2输入
4.1.3加工
4.1.4输出
4.1.5外部接口
4.1.5.1用户接口
4.1.5.1硬件接口
4.1.5.1软件接口
4.1.5.1通信接□
4.1.6性能需求
4.2功能需求2
A.n功能需求n
5.非功能需求
5.1性能需求
5.2安全性需求
5.3维护性需求
5.4软件质量属性
5.5其他需求
附录
索引
27.3需求变更控制
27.3.1需求变更控制的基本原则'
由于需求变化是不可避免的,会对项目产生影响,所以变更控制也是不可避免的,
是需要而且也必须进行的。
需求变更控制的基本原则归纳总结如下。
(1)谨慎对待变更请求,尽量控制变更。
由于项目管理的一个重要原则“做且只
做规定的事”,所以应谨慎对待变更请求,尽量控制变更,对任何一方提出的变更请求,
其他各方都应谨慎对待。
例如,承约方对客户提出的变更,在未对这种变更可能会对项
目的工期、费用产生何种影响做出判断前,就不能随便同意变更。
而应估计变更对项目
进度和费用及质量产生的影响。
(2)髙度重视需求变更。
在工程变更中一般存在着需求变更、进度变更、成本变
更3种主要变更,但其中最需要重视和谨慎对待的是需求变更,因为需求是龙头,一旦
需求发生变化,就会直接导致后面的进度、费用,以及质量三要素发生变化,所以任何
时候对需求变更都要高度重视和谨慎,充分论证和评估。
(3)签署变更控制的协议。
在项目计划期间,项目承担人和客户之间、项目经理
和团队之间就应该就变更原则、变更方式、变更过程、相应的成本进度质量如何变化等
问题进行协商,达成一致共识,并形成文件协议,以规范和指导今后工程实施过程中的
变更。
(4)在基线的基础上,做好变更实施。
有了基线和标准,才能做好控制,否则无
从谈起。
在工程的计划阶段,必须充分做好需求基线、成本基线、进度基线、质量标准,
并经过批准。
为了充分理解,这里可将基线简单理解为标准的计划,换句话说就是要做
好一个标准的各方认可的并正式签署的项目需求范围、进度计划、成本计划和质量标准,
以此来控制项目。
如因各方原因,需变化标准的计划,就应该走变更控制流程,而不是
无序的随意的变化。
(5)需有好的变更控制工具的支持。
为了提高效率,在工程建设管理中,都要求
有一套计算机化的变更控制系统来支持变更控制管理,特别是在规模较大的信息系统建
设中,尤其重要。
根据实际情况和项目规模大小,可以外购现成的变更控制工具或开发
一个小的变更控制软件来使用,这里强调的是,如果是一个复杂的大型项目,变更控制
的信息系统是必须的且是整个项目的项目信息管理系统的一部分。
(6)把项目变化融入项目计划。
把项目变化融入项目计划中,这是一个新的项目
规划过程,只不过这一规划过程是以原来的项目计划为框架,在考察项目变化的基础上
完成的。
通过新旧计划的对比,项目管理者可以清楚地看到项目变化对项目预算进度,
以及资源配置的影响和冲击。
(7)及时发布变更信息。
在项目发生变更时,只有项目管理团队和部分项目关键
人员才清楚和控制这一变化过程的始终,而其他众多的团队队员并未获得项目变更
的完全信息。
因此,当项目管理团队做出变更决策时,应及时将变更信息和方案公
布于众。
27.3.2需求变更的管理控制程序
需求变更应以其可行性为基础,对其有效控制非常重要,否则将会导致工期、成本、
质量不断扩大,对工程的成功影响较大。
作为监理师要充分认识到这一点,而且要将其
重要性不断灌输给工程的客户、各施工方等所有干系人,特别是让客户认识到,有时控
制需求变更不是拒绝用户,而是为了保证工程实现核心目标,达到预期的成功目标,当
然控制需求变更也不是一味拒绝用户提出的需求。
需求变更的管理控制程序一如下:
(1)建立需求基线、变更控制策略和变更控制系统。
如前面章节所述,只有建立
了基线才能很好地实施变更,否则无法控制,没有参照标准,也就没有控制而言;变更控
制策略和变更控制系统同样重要,是变更的控制标准和手段,有良好可行的变更控制系统,
可以达到事半功倍的效果。
这里需要特别强调的是,变更控制系统并非都要用计算机信息
系统来实现,格式化的表格、流程图和制度组合起来也是一套很好的变更控制系统。
(2)需求变更以规定格式提出。
需求变更应以规定格式提出,并统一提交到变更
控制委员会。
这里需要强调的是,需求变更一定要变更控制委员会统一管理,不能出现
多头管理。
以规定格式提出需求变更,是为了保证需求的明确性、可实现性和无二义性。
(3)变更控制委员会对需求进行评估论证。
变更控制委员会接收到需求变更申请
后,应评估变更的技术可行性、代价、业务需求和资源限制,决定是采纳还是拒绝。
(4)需求变更以书面方式获得批准并修改进度成本等项目计划。
变更控制委员会
应给每一个采纳的变更需求设定一个优先级或变更实现的日期,项目管理团队对人员、
进度计划、成本计划进行变更,并通知到相关干系人。
(5)定期评估需求变更对项目绩效的影响。
应定期评估需求变更对项目进度、成
本、质量等绩效的影响,以便及时对偏差进行调整,并为后续的需求变更不断积累数据
和经验。
以上第1项工作是工程项目准备阶段就应该做的整体准备工作,后面的第2到第5
的4项工作针对每个需求变更都是要顺序执行的。
27.4需求版本控制
为了控制指定给软件的系统需求,为软件工程和管理应用建立基线,必须控制需求
基线的变动,实施需求变更控制和版本控制。
首先建立需求说明书的基准版本,这是一
致性需求在特定时刻的快照。
之后的需求变更就遵循变更控制过程即可。
每个版本的需
求规格说明都必须是独立说明,以避免将底稿和基准或新旧版本相混淆。
最好的办法是
使用合适的配置管理工具在版本控制下为需求文档定位。
维护需求变更的历史记录、记录变更需求文档版本的日期,以及所做的变更、原因,
还包括由谁负责更新和更新的新版本号等。
版本控制工具能自动_成这些任务。
版本控
制是管理需求的一个必要方面。
需求文档的每一个版本必须被统一确定。
组每个成员
必须能够得到需求的当前版本,必须清楚地将变更写成文档,并及时通知到项目开发所
涉及的人员。
为了尽量减少困惑、冲突、误传,应仅允许指定的人来更新需求。
这些策
略适用于所有关键项目文档。
需求版本混乱造成的灾害主要体现在资源的浪费上,很多软件团体中经常发生开发
组花费时日改进了一项功能,同时却发现整项功能已经取消,发生错误原因是因为开发
部门没有拿到最新的需求。
版本控制包括两个方面:
保证人人得到的是最新的版本,记录需求的历史版本。
如
果有专门的需求管理商业工具可以助您一臂之力,如瑞理公司的RequisitePro,需求和
瑞理的其他工具如Rose、TeamTest等联系起来,从而实现需求链。
能够借助工具将需
求自动化固然很好,不过,工具使用不当也不会提高生产效率。
需求管理的工具其实用
简单的Office和任一个关系型数据库就可以解决,而且根据企业自身的特点,可以摸
索出最适合企业用的工具。
版本控制的最简单方法是在每一个公布的需求文档的版本应该包括一个修正版本
的历史情况,即已做变更的内容、变更日期、变更人的姓名,以及变更的原因,并根据
标准约定手工标记软件需求规格说明的每一次修改。
27.5需求跟踪
需求跟踪包括编制每个需求同系统元素之间的联系文档,这些元素包括别的需求、
体系结构、其他设计部件、源代码模块、测试、帮助文档等。
需求跟踪信息使变更影响
分析十分便利,有利于确认和评估某个建议的需求变更所必须做的工作。
如图27-2所示说明了4类需求跟踪能力链,客户需求可以向前追溯到需求,这样就能
区分出开发过程中或开发结束后由于需求变更受到影响的需求。
这也确保了需求说明包括
所有客户需求,同样,可以从需求回溯到相应的客户需求,确认每个软件需求的源头。
表示需求和别的系统元素之间的联系链的最普遍的方式是使用需求跟踪能力矩阵,
需求跟踪提供了一个表明与合同或说明一致的方法。
更进一步,需求跟踪可以改善
产品质量,降低维护成本,而且很容易实现重用(Ramesh1998)。
实际上,创建需求跟
踪能力是困难的,尤其是在短期之内会造成开发成本的上升,虽然从长远来看可以减少
软件生存期的费用,软件团体在实施这项能力的时候应循序渐进,逐步实施需求跟踪矩
阵并没有规定的实现办法,每个团体注重的方面不同,所创建的需求跟踪矩阵也不同,
只要能够保证需求链的一致性和状态的跟踪就达到目的了。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 信息系统 项目 管理 考试 辅导 教程 27 需求 资料