1、需求分析培训需求分析培训福建新大陆软件工程有限公司福建新大陆软件工程有限公司中国移动通信集团福建有限公司中国移动通信集团福建有限公司目录目录需求概述需求概述.需求开发活动需求开发活动3.业务功能需求模板业务功能需求模板3.需求概述需求概述需求问题的症状（需求问题的症状（1）症状：在软件项目中，变更频繁，而且集中出现在项目的中后阶段。分析要点：变更是对原需求的背离，还是补遗(需求不完整)?背离发生在什么方面(流程间/流程内/数据使用)？这些变更是需求阶段是否可能预见的?是否存在无效的变更响应(管理有问题)?改进方向：变更的可预测性需求阶段标识(需求捕获/分析)变更渠道单一化、统一化(需求管理)需
2、求问题的症状（需求问题的症状（2）症状：软件项目上线运行时遇到很多阻力。分析要点：是否为组织因素?阻力源于操作层还是管理层?改进方向：清晰的业务需求导向(需求定义)面向不同层面的需求分析 正确识别组织因素(需求捕获)需求问题的症状（需求问题的症状（3）症状：软件项目上线运行后效果很差。分析要点：为什么不使用(用户界面/功能/手工系统)?使用者的成本/效益分析?改进方向：抓准业务需求(需求定义)不同层面用户的分析(需求捕获/分析)需求问题的症状（需求问题的症状（4）症状：产品二次开发量大。分析要点：二次开发量最要集中于什么方面(业务规则/用户界面/流程顺序/流程细节/报表格式)?改进方向：工作流
3、模型顺序/细节 弹性设计业务规则/UI 报表格式理解数据模型需求问题的症状（需求问题的症状（5）症状：产品/项目完全不可用或崩溃。分析要点：忽略了哪方面非功能需求?改进方向：性能与能力 操作环境 可靠性 需求：导致项目失败的罪魁祸首需求：导致项目失败的罪魁祸首 根据Standish Group对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，只有约26%的项目获得成功。而在于这些高达74%的不成功项目中，有约60%的失败是源于需求问题。也就是说，有近45%的项目最终因为需求的问题最终导致失败。我们在哪里会摔跤我们在哪里会摔跤 在Standish
4、Group的报告中总结了导致项目失败的最重要的8大原因中，有5个与需求相关：不完整的需求(13.1%)；缺乏用户的介入(12.4%)；不实际的客户期望(9.9%)；需求和规范的变更(8.7%)；提供了不再需要的(7.5%)项目成功的因素项目成功的因素 用户的参与：用户的参与：15.9%管理层支持：13.9%清晰的需求描述清晰的需求描述(13.0%)；合适的规划(9.6%)；现实的客户期望现实的客户期望(8.2%)；较小的里程碑(7.7%)；有才能的员工(7.2%)软件需求曾经让我们如此狼狈软件需求曾经让我们如此狼狈-需求是什么？需求是什么？业务需求业务需求 业务需求是指反映组织机构或客户对系统
5、、产品高层次的目标要求，通常问题定义本身就是业务需求，业务需求就是系统目标。背景描述：XX公司希望充分利用日益完善的移动通信技术，在原有的办公系统的基础上进行扩展，使得在外的业务人员能够及时地获得客户、业务相关的动态信息，与此同时，实现企业内部的即时通信。业务需求/目标：通过该系统的实施，将人工办理业务、人工稽核两项业务效率提高10以上，使企业内部沟通效率大幅改善，以帮助企业运转效率得以提高。客户需求客户需求 用户需求是指描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。用户有不同类型：管理型、事务
6、型 信息系统、人 决策层、使用层 常用者、偶用者 组织方法：用例、用户故事、特性 例子：对快到期的客户，系统将通过短信将业务信息发给客户软件需求软件需求 从系统实现的角度描述的需求。开发人员（设计及分析人员）在业务需求、用户需求的基础上生成的。有时还需要考虑相关联的硬件、环境方面的需求功能需求功能需求 功能需求是需求的主体，是需求的本质 功能需求定义了：系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作 零散（需求项）整理（特性、用例）非功能性需求非功能性需求 可靠性：成熟性、容错性、易恢复性 易使用性：易理解性、易学习性、易操作性 效率：时间特性、资源特性 可维护性：易
7、分析性、易更改性、稳定性、易测试性 可移植性：适应性、易安装性、一致性、易替换性设计约束设计约束 也称为限制条件、补充规约，这通常是对解决方案的一些约束说明。例如：必须采用国有自主知识版权的数据库系统 再如：必须运行在UNIX操作系统之下 再如：用户将在户外完成作业优秀的需求优秀的需求 完整性：完整描述即将交付使用的功能 正确性：经过用户的审阅 无歧义：对所有读者只有一种一致的解释 必要性：每项需求记录的功能都应是用户真正需要的 有优先次序：提供了实现优先级 可行性：在已知能力和约束条件中实现 可验证性：可以设计测试方法来检查 需求开发活动需求开发活动需求开发活动需求开发活动需求获取的常用技术
8、需求获取的常用技术阅读背景资料阅读背景资料讨论分析讨论分析文档考古文档考古面谈（用户访谈）面谈（用户访谈）用户调查用户调查现场观摩现场观摩用户访谈用户访谈 用户访谈是最基本、最常见的技术 利：直接有效、形式灵活、交流深入，应该做为主要的需求捕获技术（宽带通信、固有灵活性、各类信息）弊：占用时间长占用时间长（特别当客户忙时更显示出其不足）、面窄而容易造成信息的片面性片面性。要点：首先要有准备准备：通常包括说明对流程的理解，并征得客户的意见；预先根据流程中的不明确点设计要询问的问题问题，并将客户的反馈记录下来；应留有一些即兴的空间，根据实际情况应变，以确保信息完善。第二是要有计划计划性：计划好时间
9、、计划好人员、计划好策略。用户访谈用户访谈 一般建议不超过1小时，否则应安排下一次面谈 时间安排：开场白：陈述理解 515 Min 预先计划问题：主体工作 2530 Min 即兴问题：展开性 2030 Min 总结：陈述理解 510 Min 地点选择：适当的不受干扰和避免打扰 记录：自己做笔记（分神）用户访谈：特点用户访谈：特点 最传统的方法，单独使用并不有效，通常别期望用户知道并能够说出他们的需求 应先草拟一份问卷，向要访谈的用户发出一份涉及访谈主题和时间安排的材料 在访谈的过程中，及时用草图绘制模型，从而得以及时反馈 应以业务事件为谈话的中心，问问问题，听听取回答，然后反馈反馈理解用户访谈
10、：操作方法用户访谈：操作方法 避免类似以下暗示：我的时间比你宝贵，我不知道我在做什么，你不知道你在讲什么 用简单的语言清楚地表达问题，采用对方的术语和行话 不要遗漏任何事情 不要搞错基本信息流要求的方向 有效结合开放性、半封闭性、封闭性问题用户调查用户调查 用户调查是面最广的技术 利：面广，能够获得更多的人的反馈。这点是对用户访谈技术不足之处的最好补充。弊：不够深入，容易形而上学。而这点是正是用户访谈技术所能够解决的。要点：结合用户访谈技术使用。先访谈，后调查用调查验证访谈结果 先调查，后访谈用调查理清方向用户调查用户调查:主要用途主要用途 搜索某项假设的统计依据搜索某项假设的统计依据：设计一
11、些封闭的问题，例如“从现有系统中取得客户统计资料的难易程度：非常困难、相当困难、容易、非常容易”搜索意见、建议搜索意见、建议：询问与用户访谈类似的开放性问题，例如“日常工作中的三个最大问题是什么？”，“你对能够更好地支持日常常工作的IT系统有什么建议”。-误解你的问题，你误解他的回答文档考古文档考古 文档考古是最贴近实现的技术 利：能详细、直观地对数据流细节进行了解与分析。弊：易陷入文山书海之中不可自拔，甚至常引起误导。要点：应该尽量让客户提供写有真实数据的文档。特点：从旧的工作材料中挖掘新的需求 检查收集的文档，从中找出名词，包括列标题、命名的表格区域 涉及内容：文档、打印输出、清单、手册、
12、屏幕等文档考古：优缺点文档考古：优缺点 优：获取信息相对比较直接，获得系统所有输入、输出及内部文档（但不应假定已获得全部描述）；有助于数据模型分析。缺：文档说明的系统与实际系统可能是不匹配的；文档考古的传统分析方式（如开发文档流图）可能导致产生现有系统的结构模型，从而带入新系统现场观摩现场观摩 现场观摩是最生动的技术 利：百闻不如一见，能够对需求与业务流程建立直观的认识。弊：消耗时间长，而且由于“被观摩”的微妙心理变化，会使得“观摩”失真。适用性：要对于复杂流程更加深入的理解时。要点：悄悄地进行，明确要强化理解的具体流程环节。现场观摩现场观摩 任务示范：任务示范：要求用户示范如何执行特定的任务
13、 利：可用于发现异常的、关键性的任务 弊：“示范”失真、耗时 做学徒：做学徒：和用户坐在一起，通过观察、问问题、并在用户指导下完成一些工作来学习 适用性：用户无法详细解释清楚他们在做什么时“人们正在做一件事时，最能解释他们在做什么，为什么要这么做”需求分析员可以通过学徒关系试验他的需求和设计思想需求分析需求分析 所谓分析是指通过对问题域的研究，获得对该领域特性及存在于其中（需要解决）的问题特性的透彻理解并用文档说明 分析方法：结构化分析法、面向对象分析法、面向问题域分析法 任何分析法，均需描述以下几个方面:问题域的结构 问题子域的固有属性及行为 问题域中的重要事件及现象 需求：应产生的效果需求
14、分析的方法需求分析的方法结构化结构化 vs.vs.面向对象面向对象 结构化分解 符合人的心智模型 适用于宏观层面 DFD、E/R、DD 面向对象 符合事物客观规律 适用于微观层面 UML(用例模型、类模型、活动图)需求分析何时进行需求分析何时进行 应该在“业务需求”充分理解，并且收集了最本质的“用户需求”之后就开始需求分析，但并不是等到需求捕获完全做完之后 交替进行，先把握用户需求主要部分，然后在分析的基础上引入系统级的需求（系统的设计与实现角度），并且分析模型，成为开发人员之间、开发人员与客户之间达成共识的一个平台 分析的基础上，就会发现更多的不明确项，更多待捕获的信息，这时就可以生成第二次
15、的需求调研的计划、问题、素材 需求分析何时结束需求分析何时结束 需求捕获、分析与建模、规格说明书的编写、需求的验证这个需求开发的循环，是在整个软件开发生命周期中存在的 每一次的循环，都将在需求开发的工作要点与份量上有所不同，它们应该遵循以下：从本质到边缘：本质、重要、次重要、一般、镶金 细化阶段是需求开发最密集的阶段 构建阶段需求开发逐渐减少编写规约编写规约 规格说明书是对需求分析结果的文档化过程 比较“正规”的开发组织都会重视这个活动，甚至可以说是“重视过度”，而且产生出来的文档经常是与实际的开发脱离，完成之后就束之高阁，再也不使用、不更新，这是一个需求崩溃的信号 规格说明书的格式与所采用的
16、开发过程、分析方法相关的，不同的方法格式不同 定义统一的格式是一个很重要的工作 规约内容的严谨、正确、无岐义是很重要的需求验证需求验证 这个工作大多数组织都不够重视，导致这个工作直到交付系统时才真正被履行，这也就是为什么客户拿到系统后才提出许多这样那样的需求变更，甚至认为整个系统都不是他所需要的 提高需求质量的重要手段：需求评审 需求确认 通过原型来验证需求案例案例 BOSS1.5资源管理资源管理需求调研初步沟通/问卷调查赴地市调研 文档编写编写并细化需求文档（编写中不断征求业务部门/地市的反馈意见）与业务部门反馈 汇报设计原则与模型介绍资源管理基本流程业务目标制定完整的可涵盖所有资源并与实际
17、操作流程相符的订单流程提供准确的实时库存信息，达到稽核、盘点的管理要求需求验证召集各地市业务人员开会评审资源管理业务功能、业务流程根据评审意见调整修改 业务功能需求模板业务功能需求模板模板内容模板内容1.业务描述2.业务原则 2.1适用范围 2.2前提条件 2.3 业务互斥 2.4开通限制功能 。3 业务管理 3.1业务流程 3.2业务受理 3.3 票据说明 3.4 相关业务 。模板内容模板内容4.计费处理5.帐务处理6.资费原则 6.1 营业资费 6.2 帐务资费 6.3 计费原则7.优惠说明 7.1 营业优惠 7.2 帐务优惠8.结算9.报表统计10.外系统接口 11.其它注意事项业务原则
18、注意事项业务原则 业务开放的地市、开放的用户类型、开放的品牌、产品 业务的前提条件 业务的依赖、互斥规定 开通、限制的功能注意事项业务管理注意事项业务管理 业务流程：涉及功能多，涉及的角色多，涉及的交互步骤多，画出流程图说明 业务受理：受理的步骤、界面要素、功能按钮、业务校验规则、短信的通知内容、菜单位置、开放角色权限、开放的受理渠道 票据说明：受理免填单、缴款收据、发票、对帐单的格式需明确、打印的内容需明确 相关业务：如过户、改号、销户、预销户、品牌转换时业务如何处理注意事项帐务、计费、注意事项帐务、计费、资费原则、优惠资费原则、优惠 帐务处理：汇总帐目项、综合帐目项、明细帐目项、发票和对帐单帐目项、报表体现 计费处理：话单格式 资费原则：受理费用、周期性费用、计费规则 优惠：优惠模板、优惠方案注意事项结算、报表注意事项结算、报表 结算：结算规则、结算报表格式 报表：报表格式、报表口径注意事项接口注意事项接口 接口功能 接口要素 接口文件格式 接口协议您有什么问题吗?讨论被忽略的问题其他期望和要求其它约束等
