第二章需求分析与规范(上).pptVIP

第二章 需求分析与规范上 第一部分 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合作关系 如果需求分析员不能与用户建立良好的合作关系，那么他们在需求开发过程中会很疲惫。 倘若用户不能很好地配合需求分析员，那并不表示他是个坏蛋。因为用户有他自己的想法： 我回答了你们的问题，讲了该讲的。我们付钱给你们，难道还要我伺候你们不成？我还要干自己的事情，别打扰我了。你们自己想办法把活干好吧?……。 需求分析员不是销售人员，他们不可能象销售人员那样通过某些手段笼络住用户就能成功。出色的需求分析员不仅要有过硬的专业知识，还要具备较强的交流、沟通能力。 开发方和用户方在开展需求开发