第2章 IT项目管理之需求管理

IT项目管理之需求为准,第二部分,需求工程,需求获取,需求分析,文档编写,需求状态,需求跟踪,版本控制,需求验证,需求变更,基础认知,需求相关概念剖析,需求的重要性,需求是业务的根源，需求工作的优劣对业务影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。,需求是缺陷主要来源,错误定位费用分析,错误引入阶段分析,JamesMartin：超过50%的缺陷由不完善的、不正确的、不准确的和/或不明确的需求所引起,JamesMartin：80%以上的用于定位业务错误的费用是基于业务系统需求定义的错误,一个小故事,如何练就需求分析的火眼金晴？,5W+1H+8C5W就是Who、When、Where、What、WhyWhy是关键1H就是How需求本身的流程8C指的是8个约束和限制，即8个Constraints：包括性能Performance、成本Cost、时间Time、可靠性Reliability、安全性Security、合规性Compliance、技术性Technology、兼容性Compatibility,如何建立组织级需求工程？,专业的角色做专业的事？,专业的人做专业的事？,需求工程贯穿开发全过程,需求存在什么问题,不是“大而全”，而是“准而精”；镀金.swf不是“热点组合”，而是“关键点组合”；不是“盲目跟风”，而是“为我所用”；不是“形成报告”，而是“达成共识”。CRUDLCreate-Read-Update-Delete-List,1.可行性研究项目的机会选择初步可行性研究详细可行性研究（1）可行性分析报告模版（2）金蝶公司可行性分析报告,2.项目立项立项管理过程建设方的立项管理承建方的立项管理（1）某大型集团IT项目实施管理方法（2）校务通模型,可研与立项,合同项目立项过程,1.甲方过程招标书定义、乙方选择、合同签署2.乙方过程项目分析、竞标、合同签署3.相关文档立项报告、可行性分析报告、标书,需求分析在工程中的位置,包括：需求确认、需求变更控制、需求跟踪1、需求确认需求确认是指开发方和用户共同对需求文档进行评审，双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果。,需求管理的最终作用,需求管理的目的是在用户与开发方之间建立对需求的共同理解，维护需求与工作成果的一致性，并控制需求的变更。,一、需求确认,项目开发面临的实际问题,项目开发面临的实际问题,项目开发面临的实际问题,需求验证的目的和任务,需求验证的目的就是要确保软件需求具有良好的特性（如完整性，正确性等）。需求验证包含的活动满足性（功能需求是否满足需要）满意性（非功能需求是否满意）明确及含蓄的需求(失败)、(成功)共识行（是否能共同理解）可行性（技术是否可行）明晰性（信息是否存在含混性）,1、为需求进行正式评审,正式的审查过程,需求评审做不好的后果：,需求变更需求不明确需求不可测需求不可实现导致后续工作难于开展或经常出现变更由于需求未能得到有效管理，在最终项目验收过程中出现了令人不愉快的情况，实际开发的软件没能完全反映用户的需求，导致用户不满意，项目延期。,如何进行需求评审,参与需求分析和评审的人员的管理软件需求文档的管理需求分析过程的管理需求变更的管理,需求规格评审实例,例1：“产品应在不少于每秒的正常周期内提供状态信息。”分析：这个需求是不完整的：状态信息是什么，如何显示给用户。这个需求有几处含糊。我们在谈论产品的哪部分？状态信息间隔真的假定为不少于秒？，甚者每10年显示一条新的状态信息也可以？也许它的意图是消息间隔不应超过秒，那么1毫秒是不是太短？“每”这个词导致了不确定性。问题的后果，就是需求的不可证实。,需求规格评审实例,例1需求：后台任务管理器因以误差上下不超过10秒的秒间隔，在用户界面的指定位置显示状态信息；如果后台进程处理正常，那么应该显示任务已完成的百分数/比；任务完成时，应显示相关的信息；后台任务出错应该显示错误信息；为了测试和追踪，将需求分解多个子需求。使在构造和测试时，被易于分别执行。,需求规格评审实例,例2：“产品应瞬间在文本中的显示和隐藏不可打印字符间切换”计算机在瞬间不能做任何事，所以这个需求不切实可行。它的不完整性表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己？或者用户为了模仿更改要做一些什么动作？而且，在文档中改变显示的范围是多大：选中的文本？整个的文档，或其他的？这也是个模模糊的问题。不可打印字符和隐藏字符一样吗？或者是一些属性标志或一些控制字符？问题的后果，就是需求的不可证实。,需求规格评审实例,例2需求：用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换。现在就很清楚，不可打印字符是HTML标记。由于没有定义触发条件，需求对设计没有约束力。只有设计人员选定了触发条件后，你才能编写测试验证触发的正确操作。,需求规格评审实例,例3：“HTML分析器可以产生HTML标记错误报告，帮助HTML入门者快速解决错误”。单词“快速”使其模糊，没有加进错误报告的定义也是不完整的。我不知道，你怎么验证这个需求。找一个自称为HTML的入门者，看看能不能根据错误报告快速解决错误？,需求规格评审实例,例3需求：“HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误，就不会产生错误报告”。现在我们知道了，什么会被加到出错报告中，但是出错报告是个什么样子，则留由设计人员决定。我们还指定了一个例外：如果没有发现错误，不产生错误报告。,需求规格评审实例,练习：以下描述哪些属于不精确的用户需求描述？如果不精确，应如何改正？1）系统应表现出良好的响应速度。不精确，应指出具体项目和响应时间。2）系统必须用菜单驱动。“必须”不精确，因系统还可以用其他方式驱动。3）在数据录入界面，应该有10个按钮。不精确，因过于细致，限制了设计的自由度。4）系统运行时占用的内存不得超过200M。仅是一个约束条件。5）电梯应平稳运行。不精确，应指出加速、减速、运行速度的大小。6）即使系统崩溃，也不能损坏用户数据。不精确，因这是一个难以保证的“用户需求”。,2、为需求写测试用例,目标是识别需求的含混性以需求为基础，并视其为黑盒子，然后编写测试用例。要覆盖需求常见的测试点入口条件出口条件主事件流可选事件流非功能需求,3、用检查单识别常见问题,4、为需求设定优先级,支持项目分期交付支持需求取舍之道支持需求的模式化,为什么要设定需求的优先级,软件开发受时间、成本、质量等多种资源的限制，同时软件开发的高不确定性，导致需求在项目结束时往往难以被全部实现。因此需要在需求开发阶段，对需求进行分解，设定优先级，先实现优先级别较高的需求，有助于维护项目收益和提高项目成功率。,基于价值、费用和风险的优先级设定,费用方法（Cost）：价值方法（Value）：风险方法（Risk）：,最小费用优先原则,最高价值优先原则,最低风险优先原则,它们本质上从单一视角探寻适用标准来评价每个需求，并且计算出一个分值用于编排需求的优先级。,如何设定需求的优先级,基于价值、费用和风险的优先级设定,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,相对权值,在一个平面中列出要设定优先级的所有需求、特性或使用实例；在这个例子中，我们将使用特性来设定优先级。所有项都必须在同一抽象级别上；不要把个人需求与产品特性混合在一起。如果某些特性有逻辑上的联系（例如，只有包括特性A的情况下才能实现特性B）那么在分析中只要列出驱动特性就可以了。这种模型在其有效范围内可以容纳几十种特性。如果你有更多的项，那么就把相关的特性归成一类，并建立一个可管理的初始化列表。如果你需要的话，可以在更详细的级别上进行第二轮分析。,估计每一个特性提供给客户或业务的相关利益，并用19划分等级，1代表可忽略的利益，9代表最大的价值。这些利益等级表明了与产品的业务需求的一致性。客户代表是判断这些利益的最佳人选。在缺省情况下，利润和损失的权值是相等的，作为一种精化，你可以更改这两个因素的相对权值。,估计出如果没有把应该实现的特性包括到产品中，将会给客户或业务上带来的损失。使用19划分等级，这里1代表基本无损失，9代表严重损失。,总价值相对利润相对损失,价值%=总价值/总计价值100,根据需求的复杂度，所需求的用户界面的实现情况、重用当前代码的潜在能力、所需要的测试量和文档等等，开发者可以估算出费用。估计实现每个特性的相对费用，使用1（低）9（高）划分等级。平面图将计算出由每一个特性所构成的总费用的百分比。,开发者应该要估计出与每个特性相关的技术或风险相对程度，并利用19划分等级。1级表示你可以轻而易举地实现编程，而9级表示需要极大地关注其可行性、缺乏具有专门知识的人员，或者使用不成熟或不熟悉的工具和技术。平面图将计算出每个特性所产生的风险百分比。在缺省情况下，利润损失，费用和风险的权值是相等的，但是你可以在平面图中调整其权值。如果你无需在模型中考虑风险，就把风险的权值设为0。,优先级设定演示,迭代1BaseLine=UC1-3,迭代2BaseLine=UC4-6,迭代3BaseLine=UC7-9,5、最后：形成总体共识,本需求文档建立在双方对需求的共同理解基础上，我同意后续的开发工作根据该需求文档开展。如果需求发生变化，我们将按照“需求变更控制规程”执行。我明白，需求的变更将导致双方重新协商成本、资源和进度等。甲方负责人签字乙方负责人签字,什么是需求变更？项目实现需求的程度(失败)、（成功）,时间,二、控制需求变更,受控的需求,受控的需求变更,由CCB委员会裁定,CCB的解释,CCB变更控制委员会(ChangeControlBoard)CCB是系统集成项目的所有者权益代表，负载裁定接受那些变更。CCB由项目所涉及的多方成员共同组成，通常包括用户和实施方的决策人员。CCB是决策机构，不是作业机构，通常CCB的工作是通过评审手段来决定项目是否能变更，不提出变更方案。,批准,提出变更请求,变更影响评估,评审评估报告,审批,用户认可,修订项目计划,实施变更,验证,变更结束,拒绝,修正,需求变更控制流程,需求变更申请单（我国）,变更管理五级成熟度模型,需求变更案例分析,面对客户的需求变更，接受还是拒绝？在某公司的项目管理课堂上，小李，小王、小林等人正在七嘴八舌地议论纷纷。原来，大家正在讨论公司最近遇到的两个颇为有趣的项目。,情况1：尽量满足用户需要,据小王介绍，这两个项目分别由两个项目经理来担任。其中，项目经理A属于“谦虚”型，对于客户提出的问题，无论大小都给与解决，客户对此非常满意，然而，项目进度却拖得比较长，而且，客户总想把所有的问题都改完再说，项目已经一再延期。,情况2：严格执行项目计划,相比之下，项目经理B显得稍有些“盛气凌人”，对于客户提出的问题，大多都不予理睬，客户对此不是很满意，不过，该项目的进度控制得比较好，基本能够按期完成项目。,分析1不太迁就用户,小王：“对项目经理来说，成本、质量和时间是最为重要的三要素。与客户的关系当然很重要，但也要全盘考虑项目的各要素。对于用户的要求，应该在有限的范围内给与解决，但不可以做出太大的牺牲。一味的迁就用户将会使整个项目失败。”,分析2坚持原则，适当调节用户关系,小林：“当前，国内的项目一般情况下是由销售处面签单，再由项目经理接手后续的工作，因此客户关系多在事前已经搞定。发生新的情况后，可以由公司的公关部出面与客户进行协调，项目经理可以在此过程中坚持一下原则，与公司的公关部一个红脸，一个白脸，唱出一出好戏。”,分析3用户就是上帝,小李：“不管怎样，客户才是第一位的。客户可以给你带来收入，也可以给你带来更多的客户和工作，有什么道理不多配合一下他们呢？说实话我对B的做法蛮欣赏的，可惜行不通。因为客户是上帝，如果照B的做法，后果会造成做一次项目丢掉一个客户，太不划算了。”,问题：1、如果你的项目遇到需求变更问题，你会采用哪种方式去应对？2、分析这两种应对需求变更方式的优缺点。,指导策略：合理控制,1、根据客户提出需求的实际情况而定对于客户的需求，如何是合理的，在自己的范围之内，是可以变更的，但是如果在对前面的主体框架是做以否定的话，那就断然拒绝！,指导策略：合理控制,2、把握好度项目的目的是在规定的时间内完成规定的内容。项目范围在项目启动阶段就已经确定下来了，绝对不能更改的。如果经常更改，项目经理需要分析一下原因。如果是客户原因需要更改，项目经理需要分析工作量，尽量少做改动，但是不能完全拒绝客户。如果全盘接受，客户会毫无顾及的更改；如果全然拒绝，就没做好沟通管理。,随着开发工作的进展需求将逐步扩展和演化各个开发阶段的工作业务之间存在的继承关系使每一项需求均能追溯到前后继承关系的脉络清晰可见,三、需求跟踪,开发阶段,需求状态,需求,建议,设计,编码,测试,获取,定义,承诺,设计,实现,完成,生存期各阶段需求状态的演变,需求的类型及其追踪性,解决方案领域,业务领域,业务需求,用户需求,软件需求,需求跟踪归纳如下：1、建立和维护需求跟踪矩阵正向跟踪逆向跟踪当需求文档或后续工作成果发生变更时，要及时更新需求跟踪矩阵2、查找不一致后续工作成果没有实现需求文档中的某些需求后续工作成果实现了需求文档中不存在的需求后续工作成果没有正确实现需求文档中的需求3、消除不一致将消除不一致记录到“需求跟踪报告”消除