it项目管理之需求为准

《it项目管理之需求为准》由会员分享，可在线阅读，更多相关《it项目管理之需求为准（65页珍藏版）》请在金锄头文库上搜索。

1、IT项目管理之需求为准,第二部分,需求工程,需求获取,需求分析,文档编写,需求状态,需求跟踪,版本控制,需求验证,需求变更,基础认知,需求相关概念剖析,需求的重要性,需求是业务的根源，需求工作的优劣对业务影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。,需求是缺陷主要来源,错误定位费用分析,错误引入阶段分析,James Martin： 超过50%的缺陷由不完善的、不正确的、不准确的和/或不明确的需求所引起,James Martin： 80%以上的用于定位业务错误的费用是基于业务系统需求定义的错误,一个小故事,如何练就需求分析的火眼金晴？,5W + 1H + 8C 5W就是

2、Who、When、Where、What、Why Why是关键 1H就是 How 需求本身的流程 8C指的是8个约束和限制，即8个Constraints： 包括性能Performance、成本Cost、时间Time、可靠性Reliability、安全性Security、合规性Compliance、技术性Technology、兼容性Compatibility,如何建立组织级需求工程？,专业的角色做专业的事？,专业的人做专业的事？,需求工程贯穿开发全过程,需求存在什么问题,不是“大而全”，而是“准而精”；镀金.swf 不是“热点组合”，而是“关键点组合”； 不是“盲目跟风”，而是“为我所用”； 不是

3、“形成报告”，而是“达成共识”。 CRUDL Create-Read-Update-Delete-List,1.可行性研究 项目的机会选择 初步可行性研究 详细可行性研究 （1）可行性分析报告模版 （2）金蝶公司可行性分析报告,2.项目立项 立项管理过程 建设方的立项管理 承建方的立项管理 （1）某大型集团IT项目实施管理方法 （2）校务通模型,可研与立项,合同项目立项过程,1.甲方过程 招标书定义、乙方选择、合同签署 2.乙方过程 项目分析、竞标、合同签署 3.相关文档 立项报告、可行性分析报告、标书,需求分析在工程中的位置,包括：需求确认、需求变更控制、需求跟踪 1、需求确认 需求确认是指

4、开发方和用户共同对需求文档进行评审，双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果。,需求管理的最终作用,需求管理的目的是在用户与开发方之间建立对需求的共同理解，维护需求与工作成果的一致性，并控制需求的变更。,一、需求确认,项目开发面临的实际问题,项目开发面临的实际问题,项目开发面临的实际问题,需求验证的目的和任务,需求验证的目的就是要确保软件需求具有良好的特性（如完整性，正确性等）。 需求验证包含的活动 满足性（功能需求是否满足需要） 满意性（非功能需求是否满意） 明确及含蓄的需求(失败)、(成功) 共识行（是否能共同理解） 可行性（技术是否可行） 明晰性（信息是否存在含混性）

5、,1、为需求进行正式评审,正式的审查过程,需求评审做不好的后果：, 需求变更 需求不明确 需求不可测 需求不可实现 导致后续工作难于开展或经常出现变更 由于需求未能得到有效管理， 在最终项目验收过程中出现了令人不愉快的情况，实际开发的软件没能完全反映用户的需求，导致用户不满意，项目延期。,如何进行需求评审, 参与需求分析和评审的人员的管理 软件需求文档的管理 需求分析过程的管理 需求变更的管理,需求规格评审实例,例1：“产品应在不少于每秒的正常周期内提供状态信息。” 分析：这个需求是不完整的： 状态信息是什么，如何显示给用户。这个需求有几处含糊。我们在谈论产品的哪部分？状态信息间隔真的假定为不

6、少于秒？，甚者每10年显示一条新的状态信息也可以？也许它的意图是消息间隔不应超过秒，那么1毫秒是不是太短？“每”这个词导致了不确定性。问题的后果，就是需求的不可证实。,需求规格评审实例,例1需求： 后台任务管理器因以误差上下不超过10秒的秒间隔，在用户界面的指定位置显示状态信息； 如果后台进程处理正常，那么应该显示任务已完成的百分数/比； 任务完成时，应显示相关的信息； 后台任务出错应该显示错误信息； 为了测试和追踪，将需求分解多个子需求。使在构造和测试时，被易于分别执行。,需求规格评审实例,例2：“产品应瞬间在文本中的显示和隐藏不可打印字符间切换” 计算机在瞬间不能做任何事，所以这个需求不切

7、实可行。它的不完整性表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己？或者用户为了模仿更改要做一些什么动作？而且，在文档中改变显示的范围是多大：选中的文本？整个的文档，或其他的？这也是个模模糊的问题。不可打印字符和隐藏字符一样吗？或者是一些属性标志或一些控制字符？问题的后果，就是需求的不可证实。,需求规格评审实例,例2需求： 用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换。 现在就很清楚，不可打印字符是HTML标记。由于没有定义触发条件，需求对设计没有约束力。只有设计人员选定了触发条件后，你才能编写测试验证触发的正确操作。,需求规格评审实例,例3

8、：“HTML分析器可以产生HTML标记错误报告，帮助HTML入门者快速解决错误”。 单词“快速”使其模糊，没有加进错误报告的定义也是不完整的。我不知道，你怎么验证这个需求。找一个自称为HTML的入门者，看看能不能根据错误报告快速解决错误？,需求规格评审实例,例3需求： “HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误，就不会产生错误报告”。 现在我们知道了，什么会被加到出错报告中，但是出错报告是个什么样子，则留由设计人员决定。我们还指定了一个例外：如果没有发现错误，不产生错误报告。,需求规格评审实例,练习：以下描述哪些属于不

9、精确的用户需求描述？如果不精确，应如何改正？ 1）系统应表现出良好的响应速度。 不精确，应指出具体项目和响应时间。 2）系统必须用菜单驱动。 “必须”不精确，因系统还可以用其他方式驱动。 3）在数据录入界面，应该有10个按钮。 不精确，因过于细致，限制了设计的自由度。 4）系统运行时占用的内存不得超过200M。 仅是一个约束条件。 5）电梯应平稳运行。 不精确，应指出加速、减速、运行速度的大小。 6）即使系统崩溃，也不能损坏用户数据。 不精确，因这是一个难以保证的“用户需求”。,2、为需求写测试用例,目标是识别需求的含混性 以需求为基础，并视其为黑盒子，然后编写测试用例。 要覆盖需求常见的测试

10、点 入口条件 出口条件 主事件流 可选事件流 非功能需求,3、用检查单识别常见问题,4、为需求设定优先级,支持项目分期交付 支持需求取舍之道 支持需求的模式化,为什么要设定需求的优先级,软件开发受时间、成本、质量等多种资源的限制，同时软件开发的高不确定性，导致 需求在项目结束时往往难以被全部实现。 因此需要在需求开发阶段，对需求进行分解，设定优先级，先实现优先级别较高的需求，有助于维护项目收益和提高项目成功率。,基于价值、费用和风险的优先级设定,费用方法（Cost）： 价值方法（Value）： 风险方法（Risk）：,最小费用优先原则,最高价值优先原则,最低风险优先原则,它们本质上从单一视角探

11、寻适用标准来评价每个需求，并且计算出一个分值用于编排需求的优先级。,如何设定需求的优先级,基于价值、费用和风险的优先级设定,XXX,XX%,X,XX%,X,XX%,XX,X,X,n. XXXXX,优先级,风险%,相对风险,费用%,相对费用,价值%,总价值,相对损失,相对利润,需求/特性,XXX,XX%,X,XX%,X,XX%,XX,X,X,1. XXXXX,总计,X,X,X,X,相对权值,在一个平面中列出要设定优先级的所有需求、特性或使用实例；在这个例子中，我们将使用特性来设定优先级。 所有项都必须在同一抽象级别上；不要把个人需求与产品特性混合在一起。如果某些特性有逻辑上的联系（例如，只有包括

12、特性A的情况下才能实现特性B）那么在分析中只要列出驱动特性就可以了。 这种模型在其有效范围内可以容纳几十种特性。如果你有更多的项，那么就把相关的特性归成一类，并建立一个可管理的初始化列表。如果你需要的话，可以在更详细的级别上进行第二轮分析。,估计每一个特性提供给客户或业务的相关利益，并用1 9划分等级，1代表可忽略的利益，9代表最大的价值。 这些利益等级表明了与产品的业务需求的一致性。客户代表是判断这些利益的最佳人选。 在缺省情况下，利润和损失的权值是相等的，作为一种精化，你可以更改这两个因素的相对权值。,估计出如果没有把应该实现的特性包括到产品中，将会给客户或业务上带来的损失。 使用1 9划

13、分等级，这里1代表基本无损失， 9代表严重损失。,总价值相对利润相对损失,价值%=总价值/总计价值100,根据需求的复杂度，所需求的用户界面的实现情况、重用当前代码的潜在能力、所需要的测试量和文档等等，开发者可以估算出费用。 估计实现每个特性的相对费用，使用1（低） 9（高）划分等级。 平面图将计算出由每一个特性所构成的总费用的百分比。,开发者应该要估计出与每个特性相关的技术或风险相对程度，并利用1 9划分等级。 1级表示你可以轻而易举地实现编程，而9级表示需要极大地关注其可行性、缺乏具有专门知识的人员，或者使用不成熟或不熟悉的工具和技术。 平面图将计算出每个特性所产生的风险百分比。在缺省情况

14、下，利润损失，费用和风险的权值是相等的，但是你可以在平面图中调整其权值。 如果你无需在模型中考虑风险，就把风险的权值设为0。,优先级设定演示,迭代1 BaseLine=UC1-3,迭代2 BaseLine=UC4-6,迭代3 BaseLine=UC7-9,5、最后：形成总体共识,本需求文档建立在双方对需求的共同理解基础上，我同意后续的开发工作根据该需求文档开展。如果需求发生变化，我们将按照“需求变更控制规程”执行。我明白，需求的变更将导致双方重新协商成本、资源和进度等。 甲方负责人签字 乙方负责人签字,什么是需求变更？ 项目实现需求的程度(失败)、（成功）,时间,二、控制需求变更,受控的需求,

15、受控的需求变更,由CCB委员会裁定,CCB的解释,CCB 变更控制委员会(Change Control Board) CCB 是系统集成项目的所有者权益代表，负载裁定接受那些变更。CCB由项目所涉及的多方成员共同组成，通常包括用户和实施方的决策人员。CCB是决策机构，不是作业机构，通常CCB的工作是通过评审手段来决定项目是否能变更，不提出变更方案。,批准,提出变更请求,变更影响评估,评审评估报告,审批,用户认可,修订项目计划,实施变更,验证,变更结束,拒绝,修正,需求变更控制流程,需求变更申请单（我国）,变更管理五级成熟度模型,需求变更案例分析,面对客户的需求变更，接受还是拒绝？ 在某公司的项

16、目管理课堂上，小李，小王、小林等人正在七嘴八舌地议论纷纷。原来，大家正在讨论公司最近遇到的两个颇为有趣的项目。,情况1：尽量满足用户需要,据小王介绍，这两个项目分别由两个项目经理来担任。其中，项目经理A属于“谦虚”型，对于客户提出的问题，无论大小都给与解决，客户对此非常满意，然而，项目进度却拖得比较长，而且，客户总想把所有的问题都改完再说，项目已经一再延期。,情况2：严格执行项目计划,相比之下，项目经理B显得稍有些“盛气凌人”，对于客户提出的问题，大多都不予理睬，客户对此不是很满意，不过，该项目的进度控制得比较好，基本能够按期完成项目。,分析1 不太迁就用户,小王：“对项目经理来说，成本、质量和时间是最为重要的三要素。与客户的关系当然很重要，但也要全盘考虑项目的各要素。对于用户的要求，应该在有限的范围内给与解决，但不可以做出太大的牺牲。一味的迁就用户将会使整个项目失败。”,分析2