第一讲需求分析与管理.pptVIP

第一讲需求分析与管理 一切软件成功的基石 目录 1.需求分析的基本概念 2.需求工程 3.需求分析的主要困难和对策 4.需求变更与管理 5.需求分析所用到的工具 1.需求分析的基本概念 1.1定义 需求分析指的是在建立一个新的或改变一个现存的系统时描写新系统的目的、范围和定义时所要做的所有的工作。需求分析是软件工程中的一个关键过程。 需求分析就是准确的获取客户的“需要”，规范客户的“欲望”； 1.2需求分析的重要性 Frederick Brooks在他1986 《没有银弹》的论文中阐述了需求的重要性：开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。 IBM/360 1.需求分析的基本概念 1.3 需求分析的参与人员 一般的项目中需求分析阶段可能存在以下的参与角色，不同的角色以不同的立场会对需求分析产生不同的影响。 客户 项目经理（需求方，开发方） 最终用户 系统分析员 系统构架师 1.需求分析的基本概念 1.3 需求分析的参与人员 客户：负责掏钱的人，扮演着上帝的角色 项目经理（需求方）：上帝的代理人 项目经理（开发方）：保证项目能够顺利完成的看护人 最终用户：最终使用用户的人 系统分析员：需求分析的导演 系统构架师：导演的技术顾问 2.需求工程 2.1需求分析的工程化划分 2.需求工程 2.2需求开发 需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。 需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》。 需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。 需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。 2.需求工程 2.3需求管理 需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。 需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。 需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。 需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。 2.需求工程 2.4需求分析的工程化方法 需求分析不是艺术创作，需要有规范的基本方法，沟通技巧可以因人而异，需求分析的过程和基本目标是严肃而细致的。 需求的管理，变更和追踪是细致的工作，不能因为需求项目的细小而放弃管理，放弃管理最终会使项目在大量的细节中失败。记忆是不可靠的，没有详尽的记录和确认只会使项目陷入争论和互相埋怨。 需求的工程化方法的目标是保证需求清晰，可控 3.需求分析的主要困难和对策 3.1 知识技能问题 应用域的知识是无边无际的，任何人都不可能是“万事通”。需求分析员可能是某一领域的专家，但当他接手陌生的业务时，他可能是个“无知”者。人一生中会有许多充满挫折的“第一次”，不可以逃避。 当需求分析员缺乏应用域知识时，他该怎么办？ 首先他要有勇气做事，否则连实践的机会都没有。 其次他应当赶紧补习应用域知识，不论是通过自学还是培训的方式，否则他很难与用户交流。如果可能的话，开发方最好请既懂软件又懂应用域知识的行家来帮忙。 3.需求分析的主要困难和对策 3.2态度问题 相当多的开发人员习惯于被动地对待需求开发。很多开发人员错误地以为： 需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发什么吗？如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，应当由他们自己负责。 用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不是绝症，是人们可以设法解决的。可悲的是开发人员把这些问题当成了借口，不愿主动攻克问题，导致需求问题扩散到整个软件开发过程，产生太多的后患。 软件企业的领导应当给具有错误观念的开发人员们洗脑：需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。 3.需求分析的主要困难和对策 3.3合作关系 如果需求分析员不能与用户建立良好的合作关系，那么他们在需求开发过程中会很疲惫。 倘若用户不能很好地配合需求分析员，那并不表示他是个坏蛋。因为用户有他自己的想法： 我回答了你们的问题，讲了该讲的。我们付钱给你们，难道还要我伺候你们不成？我还要干