软件需求开发

《软件需求开发》由会员分享，可在线阅读，更多相关《软件需求开发（11页珍藏版）》请在金锄头文库上搜索。

1、软件需求开发1. 概述需求在IEEE中的定义如下：1）用户解决问题或达到目标所需的条件或能力。2）系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具 有的条件或能力。3）一种反映上述1）或2）所描述的条件或能力的文档。开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念 性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软 件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分， 并且以后再对它进行修改也极为困难。本文主要内容就是我们如何正确地获取客户需求。但是需求本身是一个“商务问题”，本文是提供一个获取需求的方法，但是不可能消除需求的变 化。要

2、解决需求变化和需求管理的问题建议从商务层面上去解决。2. 需求的分类在需求开发中我们一般会对需求进行分类，这些分类的目的就是让我们 更深刻地理解和分析需求，下面使我们一般采用的需求分类方法，以及各分 类的关系。 需求层次分类（需求的层析分类是需求调研的顺序，我们可以简单把 需求的层次理解为需求的继承的关系）: 客户需求：一般是来自客户高层经理求，是客户对公司总体的 业务规划。 业务需求：一般是来自客户中层经理，是客户对具体业务的业 务流程。 用户需求：一般是来自最终用户，是客户员工的工作流程。 需求的类型分类： 功能需求 非功能需求 需求的必要性分类： 必须（必须满足、不能裁剪） 期望（可以进

3、行适当裁剪） 需求的影响范围分类： 全局的 局部的客户需求业务需求用户需求功能需求非功能需求必须的期望的需求的分类及分类之间的关系全局的 局部的3. 需求开发计划我们要是根据项目特征来确定的需求开发的步骤，然后为每个任务安排 资源确定时间，并建立开展需求开发活动的各类管理计划。需求开发计划的 主要目的是明确需求开发活动的时间计划，列出需求开发的任务、需要的资 源，定义需求开发过程中各项活动的管理方式，识别需求开发活动的风险。 在项目开始时由于项目类型不一样，我们依据客户状况项目类型确定了项目的生命周期。一般采用的生命周期模型以“原型+瀑布”和“迭代”为多。下面是依据项目特征选择生命周期模型的准

4、则： 瀑布模型 适用于新的有较多用户的产品、平台/中间件开发项目，或者是 用户对开发过程有严格要求的工程定制项目。 充分理解用户需求，且需求是确定不变的。 用户有一定的能力，对需求的表述是确切的。 所有过程工作产品的控制基线，需要有可见度和可靠性。原型+瀑布模型 新领域的应用项目的开发：如企业应用系统开发项目等。 项目包含一种新技术，例：新硬件、新的系统架构等。 需求不很清楚。 存在关于性能、可靠性和可行性的主要的、未解决的问题。 用户界面对系统成功是很关键的，但不很清楚。 迭代模型 新领域、新技术的研发项目。 规模较大的项目或产品。 需求的清晰度低，且需要进一步的调查。 技术或体系结构方面的

5、知识匮乏 依据需求的层次和已选择的需求开发过程制定需求的每个阶段或步骤 的概要时间计划、资源、人员及职责，识别需求开发的风险。要点包括： 计划需求开发的时间 计划需求开发需要的资源 计划需求准备活动 计划需求调研活动 计划需求分析活动 计划需求开发需要的参与人员，并为他们分配任务和职责 计划需求评审和确认活动 计划需求开发干系人管理，并识别出需求开发活动的干系人 计划需求开发的内部、外部沟通方式 识别并分析需求开发的风险 需求开发计划的评审。评审员一般有：客户、商务人员、同行专家、后续阶段的开发人员等。4. 需求调研准备 收集客户资料，该活动的目的是为需求调研做准备。主要手段是从外围 获取客户

6、的信息，使需求开发人员了解客户行业特点。我们收集的资料 一般有： 收集客户资料 客户的招标文件。 收集客户的产业结构、行业、地域分布、部门设置、员工规模、生 产规模、经营规模等信息。 收集客户所在行业的行业标准，并从中提取需求。 收集客户所在行业的类似信息系统的状况，并从中提取需求。 通过其他途径了解客户行业的业务特点，如：行业的专家学者、互 联网等。 需求调研人员的行业知识培训，使需求开发人员了解客户行业特点。5. 获取调研5.1. 需求调研的准则获取需求是需求开发过程的主体活动，在实际工作中获取需求、分析需求、 描述需求和需求的确认不是按顺序排列的活动，他们之间的关系应该是一个迭代 的过程

7、。在获取需求活动中我们应该遵循下列3个原则： 深入浅出 全面、深入的了解需求 简单、概括的抽象需求 站在用户的角度获取需求 业务是如何流转的？ 是如何使用系统的？ 以业务流程为主线，采用输入、处理、输出的思想获取需求 视同整个系统为一个盒子 视同整个业务为一个盒子 视同某个用户为一个盒子输入什么输出什么系统、业务、用户。如何处理谁输入输出给谁 要从系统的全生命周期过程来考虑需求，下列是考虑的要素: 如何使用？ 如何生产？ 如何安装？ 如何培训？ 如何维护？ 如何报废？ 在每个生命周期的阶段涉及到的人、设备或系统？他们会有哪些需 求？5.2. 获取并确认项目的目的、目标和范围项目的目的、目标和范

8、围一般需要商务人员、项目经理去与客户高层确认。 明确了项目的目的、目标和范围才能有效地控制预算、有利于需求调研的展开、 能够对需求进行平衡和优先级的判断。我们一般用幻灯片的方式去与客户展现。 获取客户组织结构。通过与客户接触获取客户的组织结构。董事长总经理副总经理 获取客户的业务规划。业务规划可能是客户整体的业务规划，我们需要找出 我们项目要解决客户的哪些规划，这些规划是我们项目的出发点。 获取项目的目的。项目目的就是系统要解决的核心问题是什么，为解决该问 题的约束是什么。项目的目的必须在需求调研前明确，这是进行需求调研的 基础。 获取项目目标。项目目标需要是可度量的、可以达到的，项目的范围应

9、能确 保项目的目标可以达到。 获取项目范围。项目的范围一般从广度和深度来分析，广度就是系统覆盖的 业务、部门、功能，深度就是我们做到什么程度。 与客户高层一起确认“项目目的目标和范围”。 对需求调研人员与客户参与需求访谈的人员进行“项目目的目标和范围”的 宣灌。确认后的“项目目的目标和范围”需在客户方“项目启动会议”上进 行宣贯，使所有项目干系人了解项目的目的和范围，这样才有利于需求调研 的展开。5.3. 制定需求访谈详细时间计划需求调研计划必须与用户一起制定，这样才能确保需求调研的工作顺利展开。 虽然有调研计划，但是实际客户是否有时间参与访谈是不受控制的。我们制定计 划时应该标识出任务的依赖

10、关系，当计划发生变化后我们可以及时的调整计划。 并且每个访谈任务最好能列出一些备选的用户代表。 依据组织结构，与各个部门来确定项目涉及的岗位，并对这些岗位职责进行 描述。输出“岗位定义”。 识别所有可能的需求提供者。识别需求提供者的要点如下： 谁使用该系统？ 谁维护该系统？ 谁需要从系统中获取数据？ 系统的运行会影响到谁？ 谁来推广该系统？ 谁测试该系统？ 谁生产该系统？ 谁购买该系统？ 调研客户现有信息系统。 该项目的替代的系统 与该项目有数据接口、业务接口的系统 客户拥有的其他系统 制定需求访谈详细时间计划。计划要点如下： 计划需要客户参与制定 计划调研客户现有信息系统的使用状况 计划需求

11、调研的问题的沟通及协调方法和流程 计划调研的方式、时间、地点、内容、需求分析员、用户代表及备选用 户代表等 识别需求调研的关键路径 识别需求调研的风险 与客户确认需求调研计划。 需求调研准备 依据需求调研计划，为需求调研准备问题清单。 准备“需求调查表”，“需求调查表”一般包含下列内容： 现有系统是如何运作的？ 现有系统存在什么问题？ 希望新系统解决什么问题？ 客户（用户）希望如何解决问题？ 希望交付哪些工作产品？ 最终用户的背景如何？ 对系统的速度、可靠性、安全性、数据容量的要求？ 系统的运行环境是什么？ 最重要的3项需求是什么？ 业务流程的启动条件、终止条件、正常事件流、异常事件流、输入数

12、据、 处理规则、输出数据。 数据的名称、来源、计算方法、类型、计量单位、精度、取值范围、去 向、生成时间、产生的频度、高峰期的频度、存储方式、保密要求。5.4. 需求访谈一般获取需求是软件开发中最困难、最关键、最容易出错和最需要交流的方 面。需求开发人员需要透过客户提出的表面需求理解他们的真正需求。我们一般 通过访谈为主，辅以原型来获取客户需求。需求访谈的要点如下： 访谈前我们需要进行详细的准备，为每个不同的访谈准备好“需求调查 表”。 需求分析员在调研前要了解用户的身份、背景。 限制面谈时间。 在调研前和用户讲清楚调研的意义、过程、以及需要注意的问题。 在调研时应该一个人发问，其他人记录。

13、需求调查应先了解宏观问题，再了解细节问题。 使用需求调查表进行调研，并做好详细记录。 调研时以业务流程作为总体的主线。 在用户讲解时，不要中断用户，使对方有充分的演说机会。 注意寻找异常和错误情况。 注意交谈的技巧，并尽可能多的记住用户的姓名、职务、爱好等。 详细记录访谈的时间、地点、被访谈的人员、角色、持续的时间、参与 的人员、需求、为什么需要？ 指出并记录用户没有未回答条目和待解决问题。 从不同的渠道进行需求的验证，如要验证已有的业务流程图，原有的部 门或业务接口处理方式等。 当需求出现不一致时，由客户进行决策。5.5. 调研业务需求业务需求一般是与部门的主管进行获取，主要的目的获取出各个

14、部门的业务 接口以及部门内业务的操作流程。实际过程中很多客户并不能清晰地表达出他们 的业务操作和业务接口，我们需要与各部门的业务操作者（用户）进行访谈，把 获取到的需求进行分析和梳理，把各个部门内的业务操作拼接起来，才能获得一 个完整的业务流程。所以业务需求获取的过程往往是与用户需求获取一起进行的。 通过访谈获取业务需求。在获取业务需求中我们应该是把部门作为一个盒子，获取这个部门如何与外部交互，在获取的过程中要明确每个操作涉及的角色。 整理业务流程图。将获取的业务需求描述为业务流程图（按角色和部门的泳道图），对关键业务处理要使用文字描述的方法进行补充说明。 获取客户对系统的非功能需求。非功能需

15、求的数据一定要量化，不能使用好、 快等形容词来描述性能需求，当客户不能提出非功能需求的时候，我们要从 系统的基本特征提出非功能需求指标，并得到客户的确认。我们记住这个原 则就是能量化则量化，不能量化那么我们就原形化。 将获取的功能需求和非功能需求整理到“需求一览表”中。 与客户部门主管及客户方各分管领导确认业务需求。5.6. 调研用户需求把具体业务操作者的工作方式工作内容我们称为功能需求，这些功能需求是 业务流程每个步骤的细节描述，是系统构建的基石。我们在调研这类用户前应该 做充分的准备，特别是“需求调查表”，并通过多种方法去验证这些功能需求的 正确和合理性。同时在调研功能需求的时候我们也要对业务