需求分析与规范上课件

单击此处编辑母版标题样式,*,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,第一部分,1.需求分析的基本概念,2.需求分析的主要困难,3.需求工程,1.需求分析的基本概念,1.1定义,需求：系统为解决问题或完成目标所必须满足的条件或能力。,需求分析指的是在建立一个新的或改变一个现存的系统时描写新系统的目的、范围和定义时所要做的所有的工作。需求分析是软件工程中的一个,关键过程,。,需求分析就是准确的获取客户的“需要”，规范客户的“欲望”；,1.需求分析的基本概念,1.2需求分析的重要性,Frederick Brooks在他1986 没有银弹的论文中阐述了需求的重要性：开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。,1.需求分析的基本概念,1.2需求分析的重要性,几个失败案例：,1）演出权益协议的PROMS项目，在花费了1100万英镑后1992年放弃，失败的主要因素是“他们未能以常人能够理解和检查的形式表述软件需求，软件规格说明也考虑不周”,2)Swanick空中交通控制系统，计划在1998年完成，直到2001年尚未完工（额外开支1.8亿英镑），主要因素为”缺乏健壮的需求规格说明而继续进行系统实现）,1.需求分析的基本概念,1.3需求的种类,功能需求：比如在新建一个新学生记录时系统能够自动参数一个学生序号；,性能需求：比如系统支持存放10万条学生记录；,思考,：,如何定义和描述“可靠性”“可用性”这样的一般性性能需求？结合战略举措案例分析“可靠性”“可用性”,设计约束：比如使用的开发平台,商业约束：比如费用，时间，人力资源,1.需求分析的基本概念,1.3,需求分析的参与人员,一般的项目中需求分析阶段可能存在以下的参与角色，不同的角色以不同的立场会对需求分析产生不同的影响。,客户,项目经理（需求方，开发方）,最终用户,系统分析员,系统构架师,1.需求分析的基本概念,1.3,需求分析的参与人员,客户：负责掏钱的人，扮演着上帝的角色,项目经理（需求方）：上帝的代理人,项目经理（开发方）：保证项目能够顺利完成的看护人,最终用户：最终使用的人,系统分析员：需求分析的导演,系统构架师：导演的技术顾问,2.需求分析的主要困难,请看下图,2.需求分析的主要困难,我们再来看一个故事：,一部This is spinal tap的电影中有这样的情节,一个重金属乐队想在一场演唱会中使用一个史前的建筑作为舞台的支撑物，于是乐队经理在餐馆约见了一位雕刻家，他在餐巾纸上画下了他想要的东西，一段时间后他拿到了他要的东西，雕刻得非常的美，但是乐队经理确勃然大怒，应为他得到的东西和他画在餐巾纸上的一样大，而不是他想象的那样有5米高。,2.需求分析的主要困难,2.1,知识技能问题,应用域的知识是无边无际的，任何人都不可能是“万事通”。需求分析员可能是某一领域的专家，但当他接手陌生的业务时，他可能是个“无知”者。人一生中会有许多充满挫折的“第一次”，不可以逃避。,当需求分析员缺乏应用域知识时，他该怎么办？,首先他要有勇气做事，否则连实践的机会都没有。,其次他应当赶紧补习应用域知识，不论是通过自学还是培训的方式，否则他很难与用户交流。如果可能的话，开发方最好请既懂软件又懂应用域知识的行家来帮忙。,2.需求分析的主要困难,2.2态度问题,相当多的开发人员习惯于被动地对待需求开发。很多开发人员错误地以为：,需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发什么吗？如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，应当由他们自己负责。,用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不是绝症，是人们可以设法解决的。可悲的是开发人员把这些问题当成了借口，不愿主动攻克问题，导致需求问题扩散到整个软件开发过程，产生太多的后患。,软件企业的领导应当给具有错误观念的开发人员们洗脑：需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。,2.需求分析的主要困难,2.3,合作关系,如果需求分析员不能与用户建立良好的合作关系，那么他们在需求开发过程中会很疲惫。,倘若用户不能很好地配合需求分析员，那并不表示他是个坏蛋。因为用户有他自己的想法：,我回答了你们的问题，讲了该讲的。我们付钱给你们，难道还要我伺候你们不成？我还要干自己的事情，别打扰我了。你们自己想办法把活干好吧。,需求分析员不是销售人员，他们不可能象销售人员那样通过某些手段笼络住用户就能成功。出色的需求分析员不仅要有过硬的专业知识，还要具备较强的交流、沟通能力。,开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中的权利与义务”，即以协议的方式确定合作关系。“好话”和“丑话”都说在前头，这样能减少今后的摩擦。如果条件允许的话，开发方最好为用户举办关于需求工程的培训，这样的培训将使用户明白需求的重要性以及忽视需求的危害性，从而促使他们积极友善地参加需求工程中的各项活动。,2.需求分析的主要困难,2.4,用户说不清楚需求,讨论-评审-修改-确认-讨论-评审-修改.,通过讨论出真知的方式，激发和挖掘出需求，不断的使需求清晰起来。,沟通技巧（助产术,建议法）,和客户的沟通技巧在需求分析时占据着很重要的位置。,需求理解与需求挖掘,可以广泛的借鉴其他系统的应用经验服务于当前项目,眼见为实：原型系统,由于各种原因，客户缺乏成功构建系统的动力或者主动性：根据客观条件改善沟通关系,2.需求分析的主要困难,2.5,双方误解需求,沟通行为本身就存在歧义,使用客户容易理解的语言和表达方式，一些负责的问题采用图表，动画和原型系统等直观的方式进行讨论,沟通术语不统一,加强学习和培训,角度不同，理解不同,知识面不对称,解决沟通误解的主要技术手段除了加强沟通外，就是需要确保需求的确认工作。,2.需求分析的主要困难,2.6,开发人员写不好需求文档,开发人员在调查过程中已经获得了不少需求信息，却写不出好的需求文档来。,理工科学生普遍存在写作能力不强的问题。,提高开发人员写作能力的根本办法就是让他们多练习写文档，熟能生巧。,另外，企业应当提供合适的文档模板以及比较好的示例文档，尽可能地降低写作难度。,分析,从上面的需求分析困难我们可以看出，这些困难基本上都是可以导致项目失败的一些重要根源，从规避风险的角度出发，请设计一份需求规范。,3.需求工程,3.1,需求分析的工程化划分,需求工程就是需求分析的工程化实施方法；,3.需求工程,3.2,需求开发,需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。,需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生用户需求说明书。,需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。,需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生产品需求规格说明书。系统设计人员将依据产品需求规格说明书开展系统设计工作。,3.需求工程,3.3,需求管理,需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。,需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。,需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。,需求变更控制是指依据“变更申请审批更改重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。,3.需求工程,3.4,需求分析的工程化方法,需求分析不是艺术创作，需要有规范的基本方法，沟通技巧可以因人而异，需求分析的过程和基本目标是严肃而细致的。,需求的管理，变更和追踪是细致的工作，不能因为需求项目的细小而放弃管理，放弃管理最终会使项目在大量的细节中失败。记忆是不可靠的，没有详尽的记录和确认只会使项目陷入争论和互相埋怨。,需求的工程化方法的目标是保证需求清晰，可控,4.需求变更与管理,4.1常见的困境,客户的一个电话，就推翻了之前你与客户、与你自己的开发团队，经过再三讨论而确认定下来的需求。之后你就重新开始了和客户、和你的开发团队进入新一轮的需求谈论中，甚至是无休止的谈论。,“我们无法拒绝客户,但也无法立即满足他的新需求,所以只好是推到以后再进行完善。”,而因为需求变更的原因，致使项目多次的延期后，客户仍然说这不是他们想要的。,4.需求变更与管理,4.2,需求变更的主要原因,范围没有圈定就开始细化,项目功能的添加和改善,没有指定需求的基线,需求的基线是指是否容许需求变更的分界线。随着项目的进展，基线将越定越高,没有良好的软件结构适应变化,4.需求变更与管理,4.3对策,加强前期工作：客户不断提出需求变更，那就有一个问题，客户为什么要不断提出变更？可见客户自己对项目并不是很理解，在项目的进行中有了想法，就要求项目团队加进去，所以，问题的本原在于，从一开始就要了解客户的需要是什么？他们会有那些潜在的需要？,需求确认是指开发方和客户方共同对产品需求规格说明书进行评审，双方对需求达成共识后作出承诺。需求确认包含两个重要工作：“需求评审”和“需求承诺”。,4.需求变更与管理,4.3对策,实行分级管理，以达到对需求变更的控制和管理,一级需求（或变更）是关键性的需求，这种需求如果不满足，意味着整个项目不能正常交付使用，前期工作也会被全部否定。,二级需求（或变更）是后续关键性需求，它不影响前面工作内容的交付，但不加以满足，新的项目内容无法提交或继续,三级需求是后续重要的需求，如果不被满足会令整体项目工作的价值下降，为了体现项目价值，也是开发人员自已的技术价值的证明,四级需求是改良性需求，没有满足这类需求并不影响已有功能的使用，但如果实现了则会更好,五级需求是可选性需求，更多的是偶是一种设想，以及一种可能，通常只是客户的的一种个人喜好而已,4.需求变更与管理,4.4,需求评审面临的困难,需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚开始评审时，大家都比较认真，越到后头越马虎。,需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起花费比较长的时间开会并不容易（例如有些人可能出差在外，有些人可能事务缠身）。没有必要把所有事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进行。这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。,开评审会议时经常会“跑题”，导致评审效率很低。有时话匣子一打开后关不上，大家越扯越远，结果评审会议变成了聊天会议。主持人应当控制话题，避免大家讨论与主题无关的东西。,4.需求变更与管理,4.4,需求评审面临的困难,开评审会议时经常会发生争议。适当的争议有利于澄清问题，比什么东西都一致赞成要好。然而当争议变为争吵时就坏事了，争吵不仅对评审工作没有好处，而且会无意中伤害同事们的感情。,人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。毫不妥协或者轻易妥协都不是好办法。我们应当养成良好的习惯：不要一棍子打死异己的观点，尝试着让自己站在他人的立场思考问题，这样你会找到比较满意的答案。,4.需求变更与管理,4.5,需求跟踪,需求跟踪的目的是建立与维护“需求设计编程测试”之间的一致性，确保所有的工作成果符合用户需求。,需求跟踪有两种方式：,正向跟踪。检查产品需求规格说明书中的每个需求是否都能在后继工作成果中找到对应点。,逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在产品需求规格说明书中找到出处。,正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后继工作成果的对应关系。,4.需求变更与管理,核心：,变更可控,需求变更管理