系统开发软件中的需求分析.pptx

第九章 系统开发中的需求分析与管理 一、需求工程概述 二、需求开发三、需求管理 四、需求工程方法与工具用户需求验收测试产品需求系统测试系统设计集成测试系统实现单元测试一、需求工程概述一、需求工程概述1、什么是需求基本概念：宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。需求可能来自以下几个方面：用户（客户）、接口、环境（硬件、组织文化、政策等）。需求的重要性: 开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。（Brooks：《没有银弹》） 案例——凭空想象的需求????一家大型电信设备企业有多个分支机构，A与B是研发机构，B是核心平台的研发机制，A做增值业务的研发，C是整个公司的项目管理机构，负责立项、结项与经费管理，D是销售机构。B研制出一种数据接入服务器的原型，找到A，说该产品市场前景看好，请你们开发网管软件，一起做好产品。D对A，B说“你们把软硬件都做好，我负责销售，挣到钱大家分”。于是A决定参与合作，向C提出立项，立项后，A把该项目外包给一家专业的网管软件开发公司E，预期半年完成。由于网管软件要运行于B的产品上，A与E派出开发人员到B处进行需求分析，而B的产品还是原型并不成熟，不断在变化，最终用了1年时间才完成软件开发。开发完成后，E将软件交付给A后，A付清开发费用，再把软件交付到D，D又卖给某电信局F，结果F对软件的功能不满意，要求按自己的要求修改后才能付钱。D不得不要求A修改软件，而A已经将开发费用付给了E，只能自己吞苦果，结果是A想办法把软件转让给B，希望拿出成本并且以后再也不与B合作。——这在很多大企业中都是普遍发生的事实。产品是闭门造车出来的，根本没有弄清楚要开发的系统应该是什么样的。 ?一、需求工程概述2、系统需求的来源 1) 客户：购买系统的人。2）用户：实际使用系统进行日常业务活动的人。3）技术人员：维护系统运行的人。4）其他系统相关者。一、需求工程概述3、需求工程1)基本概念：在软件开发的生命周期中，与需求直接相关的活动。主要包括：需求开发和需求管理两部分内容。一、需求工程概述3、需求工程需求开发过程：通过调查与分析，获取用户需求并定义产品需求。 需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》。 需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。 需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。 一、需求工程概述3、需求工程需求管理过程：在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。 需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。 需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。 需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。 一、需求工程概述3、需求工程2）需求工程的主要内容： 需求开发产生的主要文档为《用户需求说明书》与《软件需求规格说明书》。需求管理产生的主要文档为《需求评审报告》、《需求跟踪报告》和《需求变更控制报告》一、需求工程概述4、需求工程中的主要问题知识技能问题 态度问题 合作关系 用户说不清楚需求 双方误解需求 开发人员写不好需求文档 用户经常变更需求 知识技能问题应用域的知识是无边无际的，任何人都不可能是“万事通”。俗话说“隔行如隔山”，需求分析员可能是某一领域的专家，但当他接手陌生的业务时，他可能是个“无知”者。一个企业要谋求发展，不能总在做老的业务。人一生中会有许多充满挫折的“第一次”，不可以逃避。当需求分析员缺乏应用域知识时，他该怎么办？–首先要有勇气做事，否则连实践的机会都没有。–其次应当赶紧补习应用域知识，不论是通过自学还是培训的方式，否则他很难与用户交流。如果可能的话，开发方最好请既懂软件又懂应用域知识的行家来帮忙。 态度问题 相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会发牢骚，找出一堆用户的毛病。很多开发人员错误地以为：需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发什么吗？如果用户说不清楚需求，或者经常变更需求，这类问题是用