高级需求分析.ppt

课程总结 需求分析过程需要有工程化的过程，重在执行 一抓、二定、三分析 四测、五控、六跟踪 END 高级需求分析概述 项目案例 案例角色和人物 小王：软件项目负责人 老王：公司技术老总 开发小组：小李，老赵，小田，小谢 要对软件需求进行管理(1/2) 按照初步的项目计划，老赵带领项目组的部分成员(需求分析小组)开始进驻用户场地，开展需求调查工作，但在需求分析和后续开发过程中陆续出现了许多与用户需求有关的一系列问题，影响软件项目的实施 整个项目规模比较庞大，需求分析小组不知如何开展工作？从何处下手？对需求分析的复杂性和难度估计不足。 需求分析小组不能有效工作：不知哪些属于用户需求，哪些不是？不知怎样才能获取用户需求？如何把它分析清楚？ 不知应该按照怎样的规范书写软件需求规格说明书? 得到的软件需求质量不高：说不清，遗漏，矛盾，罗嗦…. 案例提示我们 需求分析是极为重要的 需求分析是困难和复杂的 为了保证软件需求的质量，必须从需求分析过程角度进行改进与保证 需求分析过程质量低下将会导致严重后果 需求开发的主要困难与对策 1 知识技能问题 应用域的知识是无边无际的，任何人都不可能是“万事通”。俗话说“隔行如隔山”，需求分析员可能是某一领域的专家，但当他接手陌生的业务时，他可能是个“无知”者。一个企业要谋求发展，不能总在做老的业务。人一生中会有许多充满挫折的“第一次”，不可以逃避。 当需求分析员缺乏应用域知识时，他该怎么办？ 首先他要有勇气做事，否则连实践的机会都没有。 其次他应当赶紧补习应用域知识，不论是通过自学还是培训的方式，否则他很难与用户交流。如果可能的话，开发方最好请既懂软件又懂应用域知识的行家来帮忙。 2 态度问题 相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会发牢骚，找出一堆用户的毛病。很多开发人员错误地以为： 需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发什么吗？如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，应当由他们自己负责。 需求开发的主要困难与对策 用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不是绝症，是人们可以设法解决的。可悲的是开发人员把这些问题当成了借口，不愿主动攻克问题，导致需求问题扩散到整个软件开发过程，产生太多的后患。 软件企业的领导应当给具有错误观念的开发人员们洗脑：需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。 需求开发的主要困难与对策 3 合作关系 如果需求分析员不能与用户建立良好的合作关系，那么他们在需求开发过程中会很疲惫。 倘若用户不能很好地配合需求分析员，那并不表示他是个坏蛋。因为用户有他自己的想法： 我回答了你们的问题，讲了该讲的。我们付钱给你们，难道还要我伺候你们不成？我还要干自己的事情，别打扰我了。你们自己想办法把活干好吧?……。 对于一些竞标项目，在合同未签订之前的需求开发工作尤为困难。用户未必会买你的产品，他不会投入很多精力来协助你搞需求开发。 需求分析员不是销售人员，他们不可能象销售人员那样通过某些手段笼络住用户就能成功。出色的需求分析员不仅要有过硬的专业知识，还要具备较强的交流、沟通能力。 开发方与用户的合作关系对需求开发而言是至关重要的。对于重大的、复杂的项目，我们不能完全期望双方能够自发地建立起良好地合作关系，这样风险太大。 开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中的权利与义务”，即以协议的方式确定合作关系。 “好话”和“丑话”都说在前头，这样能减少今后的摩擦。 如果条件允许的话，开发方最好为用户举办关于需求工程的培训，这样的培训将使用户明白需求的重要性以及忽视需求的危害性，从而促使他们积极友善地参加需求工程中的各项活动。 需求开发的主要困难与对策 用户在需求工程中的“权利” 1. 有权要求开发方派遣资质合格的需求分析员和相关人员。 2. 有权要求开发方采用用户熟悉的语言来描述需求，即开发方必须提供用户看得懂得需求文档。 3. 有权审查需求文档，并对有争议的需求作出决策。如果认为需求文档不能准确地反映用户真实的意愿，可以拒绝在需求文档上签字。 如果用户想要变更需求，有权要求开发方对该变更将产生的影响作出真实可信的评估，以便用户决定是否变更需求。 用户在需求工程中的“义务” 1. 以积极友善的态度与开发方人员交流、协作，尽可能地为开发方人员提供工作和生活上的便利。 2. 乐意接受需求分析员的采访，在不泄漏机密的前提下尽可能地回答需求分析员的问题。 3. 在不泄漏机密的前提下，尽可能地向需求分析员提供与需求相关的材料。 与需求分析员共同评审需求文档，确保需求文档