系统开发中的需求分析与管理（a）

《系统开发中的需求分析与管理（a）》由会员分享，可在线阅读，更多相关《系统开发中的需求分析与管理（a）（58页珍藏版）》请在金锄头文库上搜索。

1、第九章 系统开发中的需求分析与管理,一、需求工程概述 二、需求开发 三、需求管理 四、需求工程方法与工具,一、需求工程概述,一、需求工程概述,1、什么是需求 基本概念：宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。 需求可能来自以下几个方面：用户（客户）、接口、环境（硬件、组织文化、政策等）。 需求的重要性: 开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。（Br

2、ooks：没有银弹）,案例凭空想象的需求一家大型电信设备企业有多个分支机构，A与B是研发机构，B是核心平台的研发机制，A做增值业务的研发，C是整个公司的项目管理机构，负责立项、结项与经费管理，D是销售机构。 B研制出一种数据接入服务器的原型，找到A，说该产品市场前景看好，请你们开发网管软件，一起做好产品。 D对A，B说“你们把软硬件都做好，我负责销售，挣到钱大家分”。于是A决定参与合作，向C提出立项，立项后，A把该项目外包给一家专业的网管软件开发公司E，预期半年完成。由于网管软件要运行于B的产品上，A与E派出开发人员到B处进行需求分析，而B的产品还是原型并不成熟，不断在变化，最终用了1年时间才

3、完成软件开发。 开发完成后，E将软件交付给A后，A付清开发费用，再把软件交付到D，D又卖给某电信局F，结果F对软件的功能不满意，要求按自己的要求修改后才能付钱。 D不得不要求A修改软件，而A已经将开发费用付给了E，只能自己吞苦果，结果是A想办法把软件转让给B，希望拿出成本并且以后再也不与B合作。 这在很多大企业中都是普遍发生的事实。产品是闭门造车出来的，根本没有弄清楚要开发的系统应该是什么样的。,一、需求工程概述,2、系统需求的来源 1) 客户：购买系统的人。 2）用户：实际使用系统进行日常业务活动的人。 3）技术人员：维护系统运行的人。 4）其他系统相关者。,一、需求工程概述,3、需求工程

4、1)基本概念：在软件开发的生命周期中，与需求直接相关的活动。主要包括：需求开发和需求管理两部分内容。,一、需求工程概述,3、需求工程,需求开发过程：通过调查与分析，获取用户需求并定义产品需求。 需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生用户需求说明书。 需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。 需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生产品需求规格说明书。系统设计人员将依据产品需求规格说明书开展系统设计工作。,一、需求工程概述,3、需求工程,需求管理过程：在

5、客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。 需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。 需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。 需求变更控制是指依据“变更申请审批更改重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。,一、需求工程概述,3、需求工程 2）需求工程的主要内容： 需求开发产生的主要文档为用户需求说明书与软件需求规格说明书。 需求管理产生的主要文档为需求评审报告、需求跟踪报

6、告和需求变更控制报告,一、需求工程概述,4、需求工程中的主要问题 知识技能问题 态度问题 合作关系 用户说不清楚需求 双方误解需求 开发人员写不好需求文档 用户经常变更需求,知识技能问题,应用域的知识是无边无际的，任何人都不可能是“万事通”。俗话说“隔行如隔山”，需求分析员可能是某一领域的专家，但当他接手陌生的业务时，他可能是个“无知”者。一个企业要谋求发展，不能总在做老的业务。人一生中会有许多充满挫折的“第一次”，不可以逃避。 当需求分析员缺乏应用域知识时，他该怎么办？ 首先要有勇气做事，否则连实践的机会都没有。 其次应当赶紧补习应用域知识，不论是通过自学还是培训的方式，否则他很难与用户交流

7、。如果可能的话，开发方最好请既懂软件又懂应用域知识的行家来帮忙。,态度问题,相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会发牢骚，找出一堆用户的毛病。很多开发人员错误地以为：需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发什么吗？如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，应当由他们自己负责。 用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不是绝症，是人们可以设法解决的。可悲的是开发人员把这些问题当成了借口，不愿主动攻克问题，导致需求问题扩散到整个软件开发过程，产生太多的后患。 软件企业的领导应当给具有错误观

8、念的开发人员们洗脑：需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。,合作关系,如果需求分析员不能与用户建立良好的合作关系，那么他们在需求开发过程中会很疲惫。 倘若用户不能很好地配合需求分析员，那并不表示他是个坏蛋。因为用户有他自己的想法：我回答了你们的问题，讲了该讲的。我们付钱给你们，难道还要我伺候你们不成？我还要干自己的事情，别打扰我了。你们自己想办法把活干好吧 。 对于一些竞标项目，在合同未签订之前的需求开发工作尤为困难。用户未必会买你的产品，他不会投入很多精力来协助你搞需求开发。 需求分析员不是销售人员，他们不可能象销售人员那样通过某些手段笼

9、络住用户就能成功。出色的需求分析员不仅要有过硬的专业知识，还要具备较强的交流、沟通能力。 开发方与用户的合作关系对需求开发而言是至关重要的。对于重大的、复杂的项目，我们不能完全期望双方能够自发地建立起良好地合作关系，这样风险太大。 开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中的权利与义务”，即以协议的方式确定合作关系。“好话”和“丑话”都说在前头，这样能减少今后的摩擦。如果条件允许的话，开发方最好为用户举办关于需求工程的培训,合作关系,用户在需求工程中的“权利” 1. 有权要求开发方派遣资质合格的需求分析员和相关人员。 2. 有权要求开发方采用用户熟悉的语言来描述需求，即

10、开发方必须提供用户看得懂得需求文档。 3. 有权审查需求文档，并对有争议的需求作出决策。如果认为需求文档不能准确地反映用户真实的意愿，可以拒绝在需求文档上签字。 4. 如果用户想要变更需求，有权要求开发方对该变更将产生的影响作出真实可信的评估，以便用户决定是否变更需求。 用户在需求工程中的“义务” 1. 以积极友善的态度与开发方人员交流、协作，尽可能地为开发方人员提供工作和生活上的便利。 2. 乐意接受需求分析员的采访，在不泄漏机密的前提下尽可能地回答需求分析员的问题。 3. 在不泄漏机密的前提下，尽可能地向需求分析员提供与需求相关的材料。 4. 与需求分析员共同评审需求文档，确保需求文档准确

11、地反映用户真实的意愿。,用户说不清楚需求,用户说不清楚需求是普遍现象，这是让开发人员头痛的大问题。有些用户真的不知道需求是什么，或者对需求只有朦胧的感觉，他当然说不清楚需求。有些用户虽然心里明白想要什么，但却说不清楚需求。 系统分析员绝不能以用户说不清楚需求为借口而草率地对待需求开发工作，否则会连累整个开发团队的。 无论是什么原因导致用户说不清楚需求，系统分析员必须设法搞清楚用户真正的需求，这是系统分析员的职责，也是职业的挑战。,双方误解需求,了解需求的过程中会发生“问非所求，答非所问”的事情。,开发人员写不好需求文档,需求调查工作不充分，获取的需求信息太少或者太乱，以至于写不成需求文档。 要

12、想写出好的需求文档，前提条件是把需求调查工作做好。 企业应当提供合适的文档模板以及比较好的示例文档，尽可能地降低写作难度。,用户经常变更需求,需求变更通常会对项目的进度、人力资源、经费产生很大的影响。如果在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，导致产品的部分内容需要重新开发。毫无疑问，这种需求变更将使项目付出额外的代价。 需求变更并不可怕，可怕的是需求变更失去控制，导致项目混乱。所以需求变更控制是需求工程的重要活动。,用户经常变更需求,需求变更通常会对项目的进度、人力资源、经费产生很大的影响。如果在项目开发的初始阶段，开发人员和用户没

13、有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，导致产品的部分内容需要重新开发。毫无疑问，这种需求变更将使项目付出额外的代价。 需求变更并不可怕，可怕的是需求变更失去控制，导致项目混乱。所以需求变更控制是需求工程的重要活动。,一、需求工程概述,5、需求工程的层次 开发者对待需求工程的态度可分“被动型”、“主动型”和“领先型”三种，只有后两种才有可能开发出成功的产品。 “被动型”是指开发者被动地对待需求工程中的各项活动，能少干则少干，能偷懒则偷懒。他们认为需求是用户的事情而不是自己的事情。开发过程中经常发生需求变更，导致产品迷失方向，不是半途而废就是陷入半死不活的状态。 “主动型”

14、是指开发者积极地开展需求工程中的各项活动。他们把获取准确的需求当作自己的职责，会想尽一切办法克服需求开发和需求管理过程中的困难，而不是找借口推卸责任。俗话说“良好的开端是成功的一半”，“主动型”需求工程是开发成功产品的必备条件。 “领先型”是需求工程的最高境界。开发者发掘了连用户自己都没有意识到的需求，导致用户跟着新产品跑而不是新产品围着用户转，这叫引导消费。需求工程做到这个份上，才能使产品立于不败之地，长盛不衰。,二、需求开发,1、需求的获取 一般地，分析员首先要通过与用户面谈、问卷调查等方式获取需求，通过对这些需求进行记录与定义并进行讨论与修正，将未解决的问题放在一个条目中，等下一次调查解

15、决。通过多次迭代最终得到完整的系统需求。 1)需求获取规程 现代软件系统分析与开发一般都遵循一定的范式和规程。在需求调查阶段，一般按以下规程进行：,二、需求开发,1、需求的获取 2)调查准备 (1)需求分析员应当起草需求调查问题表，将调查重点锁定在该问题表内，否则调查工作将变得漫无边际。 问题表可以有多份，随着调查的深入，问题表将不断地被细化。 根据经验，用户通常没有耐心回答复杂的论述题，所以问题表应当以“选择题”和“是非题”为主。 制定问题表最简便的方法就是从用户需求说明书的模板中提取需求问题。,二、需求开发,1、需求的获取 2)调查准备 (2)确定调查方式，调查的方法有： 问卷调查 复查现

16、有报表和业务过程的描述 与用户面谈与讨论 观察与记录业务过程 与同行或专家交谈，听取意见与建议 分析已经存在的软件系统，提取需求 从行业标准和规则中提取需求 到Internet上查找相关信息,二、需求开发,1、需求的获取 2)调查准备 (2)确定调查方式，辅助调查的方法有： 可通过原型的方法获取需求，这对于“说不出需求”的用户尤其适用。 JAD（联合应用开发会议）是加快调查的重要方法，即将相关人员全部召集在一起参加单一会议直接解决需求分析问题。,二、需求开发,1、需求的获取 2)调查准备 (3)需求分析员与被调查者建立联系，确定调查的时间、地点、人员等，撰写需求调查计划。要特别留意的是不要漏掉典型的用户。,二、需求开发,1、需求的获取 3)调查与记录 准备工作完毕后，需求分析员按照计划执行调查。在调查过程中随时记录（或存储）需求信息 。通过完成计划的调查任务，系统分析员获取用户需求并将其正确的记录。记录形式一般为表格,二、需求开发,