搜索
IT项目管理之需求为准第二部分需求工程需求获取需求分析文档编写需求状态需求跟踪版本控制需求开发需求管理需求验证需求变更基础认知需求相关概念剖析需求的重要性需求是业务的根源，需求工作的优劣对业务影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。需求是缺陷主要来源Requirements56%Design27%Other10%Code7%错误定位费用分析Requirements82%Design13%Other4%Code1%错误引入阶段分析JamesMartin：超过50%的缺陷由不完善的、不正确的、不准确的和/或不明确的需求所引起JamesMartin：80%以上的用于定位业务错误的费用是基于业务系统需求定义的错误一个小故事如何练就需求分析的火眼金晴？•5W+1H+8C•5W就是Who、When、Where、What、Why•Why是关键•1H就是How–需求本身的流程•8C指的是8个约束和限制，即8个Constraints：•包括性能Performance、成本Cost、时间Time、可靠性Reliability、安全性Security、合规性Compliance、技术性Technology、兼容性Compatibility如何建立组织级需求工程？专业的角色做专业的事？专业的人做专业的事？需求工程贯穿开发全过程设计需求架构设计系统规格软件需求硬件需求•质量属性•DFX业务需求用户需求内部需求客户要求•功能需求•非功能需求标准约束•书面标准•事实标准需求存在什么问题•不是“大而全”，而是“准而精”；镀金.swf•不是“热点组合”，而是“关键点组合”；•不是“盲目跟风”，而是“为我所用”；•不是“形成报告”，而是“达成共识”。•CRUDLCreate-Read-Update-Delete-List1.可行性研究项目的机会选择初步可行性研究详细可行性研究（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、为需求写测试用例•目标是识别需求的含混性1.以需求为基础，并视其为黑盒子，然后编写测试用例。2.要覆盖需求常见的测试点•入口条件•出口条件•主事件流•可选事件流•非功能需求3、用检查单识别常见问题需求特性检查内容所有定义、实现方法是否清楚地表达了用户的原要求在功能实现过程、方法和技术要求的描述上，是否背离了功能的实际要求是否有不能理解或造成误解的描述是否有一个内容表格，该表格包含了所有需求描述是否所有的图形、表格都进行了标号是否所有的需求项都进行了标号，并提供了索引是否所有需求可以被定义的更细致，或简单对于不清晰的信息是否进行了指出是否存在有需求让你不舒服是否所有与需求相关的设计约束都包含了是否所有与需求相关的性能都包含了是否所有与需求相关的属性都包含了是否所有与需求相关的外部接口都包含了是否所有与需求相关的通信都被包含了是否所有与需求相关的硬件都被包含了是否所有与需求相关的数据库都被包含了是否所有与需求相关的软件都被包含了是否所有与需求相关的输入和输出都被包含了是否所有与需求相关的安装特性都被包含了是否所有与需求相关的维护特性都被包含了是否所有与需求相关的安全特性都被包含了所有对其他需求的内部交叉引用是否正确所有需求的编写在细节上是否都一致或者合适需求是否能为设计提供足够的基础是否包括了每个需求的实现优先级需求定义是否包含了有关文件(指质量手册、质量计划以及其他有关文件)中所规定的需求定义所应该包含的所有内容需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有需求功能需求是否覆盖了所有非正式情况的处理是否对各种操作模式(如正常、非正常、有干扰等)下的环境条件都作了规定是否对所有功能与时间因素有关的方面都作了考虑是否标识出了所有与时间因素有关的功能？它们的时间准则是否都说明了？时间准则的最大、最小执行时间是否都定义了是否标识并定义了在将来可能会变化的需求是否定义了系统所有的输入是否标识清楚了系统输入的来源是否标识出了系统的输出是否说明了系统输入、输出的值域、单位、格式等是否说明了如何进行系统输入的合法性检查是否定义了系统输入、输出的精度是否定义了系统性能的各个方面在不同负载情况下，是否规定了系统的生产率在不同情况下，是否规定了系统的响应时间是否充分定义了有关人机界面的需求是否对需求定义进行了可行性分析和相关文件(资料)是否已归档是否对影响需求实现的因素进行了调查、调查结果是否已归档需求评审检查表清晰性/无二义性完整性4、为需求设定优先级•支持项目分期交付•支持需求取舍之道•支持需求的模式化为什么要设定需求的优先级软件开发受时间、成本、质量等多种资源的限制，同时软件开发的高不确定性，导致需求在项目结束时往往难以被全部实现。因此需要在需求开发阶段，对需求进行分解，设定优先级，先实现优先级别较高的需求，有助于维护项目收益和提高项目成功率。•基于价值、费用和风险的优先级设定1)费用方法（Cost）：2)价值方法（Value）：3)风险方法（Risk）：最小费用优先原则最高价值优先原则最低风险优先原则它们本质上从单一视角探寻适用标准来评价每个需求，并且计算出一个分值用于编排需求的优先级。如何设定需求的优先级基于价值、费用和风险的优先级设定XXXXX%XXX%XXX%XXXXn.XXXXX优先级风险%相对风险费用%相对费用价值%总价值相对损失相对利润需求/特性XXXXX%XXX%XXX%XXXX1.XXXXX总计XXXX相对权值在一个平面中列出要设定优先级的所有需求、特性或使用实例；在这个例子中，我们将使用特性来设定优先级。所有项都必须在同一抽象级别上；不要把个人需求与产品特性混合在一起。如果某些特性有逻辑上的联系（例如，只有包括特性A的情况下才能实现特性B）那么在分析中只要列出驱动特性就可以了。这种模型在其有效范围内可以容纳几十种特性。如果你有更多的项，那么就把相关的特性归成一类，并建立一个可管理的初始化列表。如果你需要的话，可以在更详细的级别上进行第二轮分析。估计每一个特性提供给客户或业务的相关利益，并用1~9划分等级，1代表可忽略的利益，9代表最大的价值。这些利益等级表明了与产品的业务需求的一致性。客户代表是判断这些利益的最佳人选。在缺省情况下，利润和损失的权值是相等的，作为一种精化，你可以更改这两个因素的相对权值。估计出如果没有把应该实现的特性包括到产品中，将会给客户或业务上带来的损失。使用1~9划分等级，这里1代表基本无损失，9代表严重损失。总价值＝相对利润＋相对损失价值%=总价值/总计价值×100根据需求的复杂度，所需求的用户界面的实现情况、重用当前代码的潜在能力、所需要的测试量和文档等等，开发者可以估算出费用。估计实现每个特性的相对费用，使用1（低）~9（高）划分等级。平面图将计算出由每一个特性所构成的总费用的百分比。开发者应该要估计出与每个特性相关的技术或风险相对程度，并利用1~9划分等级。1级表示你可以轻而易举地实现编程，而9级表示需要极大地关注其可行性、缺乏具有专门知识的人员，或者使用不成熟或不熟悉的工具和技术。平面图将计算出每个特性所产生的风险百分比。在缺省情况下，利润损失，费用和风险的权值是相等的，但是你可以在平面图中调整其权值。如果你无需在模型中考虑风险，就把风险的权值设