系统开发的需求与管理报告(58页)讲解.ppt

第九章 系统开发中的需求分析与管理 一、需求工程概述 一、需求工程概述 1、什么是需求 基本概念：宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。 需求可能来自以下几个方面：用户（客户）、接口、环境（硬件、组织文化、政策等）。 需求的重要性: 开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。（Brooks：《没有银弹》） 一、需求工程概述 2、系统需求的来源 1) 客户：购买系统的人。 2）用户：实际使用系统进行日常业务活动的人。 3）技术人员：维护系统运行的人。 4）其他系统相关者。 一、需求工程概述 3、需求工程 1)基本概念：在软件开发的生命周期中，与需求直接相关的活动。主要包括：需求开发和需求管理两部分内容。 一、需求工程概述 3、需求工程 一、需求工程概述 3、需求工程 一、需求工程概述 3、需求工程 2）需求工程的主要内容： 需求开发产生的主要文档为《用户需求说明书》与《软件需求规格说明书》。 需求管理产生的主要文档为《需求评审报告》、《需求跟踪报告》和《需求变更控制报告》 一、需求工程概述 4、需求工程中的主要问题 知识技能问题 态度问题 合作关系 用户说不清楚需求 双方误解需求 开发人员写不好需求文档 用户经常变更需求 知识技能问题 应用域的知识是无边无际的，任何人都不可能是“万事通”。俗话说“隔行如隔山”，需求分析员可能是某一领域的专家，但当他接手陌生的业务时，他可能是个“无知”者。一个企业要谋求发展，不能总在做老的业务。人一生中会有许多充满挫折的“第一次”，不可以逃避。 当需求分析员缺乏应用域知识时，他该怎么办？ –首先要有勇气做事，否则连实践的机会都没有。 –其次应当赶紧补习应用域知识，不论是通过自学还是培训的方式，否则他很难与用户交流。如果可能的话，开发方最好请既懂软件又懂应用域知识的行家来帮忙。 态度问题 相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会发牢骚，找出一堆用户的毛病。很多开发人员错误地以为：需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发什么吗？如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，应当由他们自己负责。 用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不是绝症，是人们可以设法解决的。可悲的是开发人员把这些问题当成了借口，不愿主动攻克问题，导致需求问题扩散到整个软件开发过程，产生太多的后患。 软件企业的领导应当给具有错误观念的开发人员们洗脑：需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。 合作关系 如果需求分析员不能与用户建立良好的合作关系，那么他们在需求开发过程中会很疲惫。 倘若用户不能很好地配合需求分析员，那并不表示他是个坏蛋。因为用户有他自己的想法：我回答了你们的问题，讲了该讲的。我们付钱给你们，难道还要我伺候你们不成？我还要干自己的事情，别打扰我了。你们自己想办法把活干好吧?……。 对于一些竞标项目，在合同未签订之前的需求开发工作尤为困难。用户未必会买你的产品，他不会投入很多精力来协助你搞需求开发。 需求分析员不是销售人员，他们不可能象销售人员那样通过某些手段笼络住用户就能成功。出色的需求分析员不仅要有过硬的专业知识，还要具备较强的交流、沟通能力。 开发方与用户的合作关系对需求开发而言是至关重要的。对于重大的、复杂的项目，我们不能完全期望双方能够自发地建立起良好地合作关系，这样风险太大。 开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中的权利与义务”，即以协议的方式确定合作关系。“好话”和“丑话”都说在前头，这样能减少今后的摩擦。如果条件允许的话，开发方最好为用户举办关于需求工程的培训 合作关系 用户在需求工程中的“权利” –1. 有权要求开发方派遣资质合格的需求分析员和相关人员。 –2. 有权要求开发方采用用户熟悉的语言来描述需求，即开发方必须提供用户看得懂得需求文档。 –3. 有权审查需求文档，并对有争议的需求作出决策。如果认为需求文档不能准确地反映用户真实的意愿，可以拒绝在需求文档上签字。 –4. 如果用户想要变更需求，有权要求开发方对该变更将产生的影响作出真实可信的评估，以便用户决定是否变更需求。 用户在需求工程中的“义务” –1. 以积极友善的态度与开发方人员交流、协作，尽可能地为开发方人员提供工作和生活上的便利。 –2. 乐意接受需求分析员