1. 概述
需求在IEEE中的定义如下：
1）用户解决问题或达到目标所需的条件或能力。
2）系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力。
3）一种反映上述1）或2）所描述的条件或能力的文档。
开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。
本文主要内容就是我们如何正确地获取客户需求。但是需求本身是一个“商务问题”，本文是提供一个获取需求的方法，但是不可能消除需求的变化。要解决需求变化和需求管理的问题建议从商务层面上去解决。
在需求开发中我们一般会对需求进行分类，这些分类的目的就是让我们更深刻地理解和分析需求，下面使我们一般采用的需求分类方法，以及各分类的关系。
Ø 需求层次分类(需求的层析分类是需求调研的顺序，我们可以简单把需求的层次理解为需求的继承的关系)：
l 客户需求：一般是来自客户高层经理求，是客户对公司总体的业务规划。
l 业务需求：一般是来自客户中层经理，是客户对具体业务的业务流程。
l 用户需求：一般是来自最终用户，是客户员工的工作流程。
Ø 需求的类型分类：
l 功能需求
l 非功能需求
Ø 需求的必要性分类：
l 必须（必须满足、不能裁剪）
l 期望（可以进行适当裁剪）
Ø 需求的影响范围分类：
l 全局的
l 局部的
|
客户需求 |
|
业务需求 |
|
用户需求 |
|
功能需求 |
|
非功能需求 |
|
必须的 |
|
期望的 |
|
需求的分类及分类之间的关系 |
|
全局的 |
|
局部的 |
我们要是根据项目特征来确定的需求开发的步骤，然后为每个任务安排资源确定时间，并建立开展需求开发活动的各类管理计划。需求开发计划的主要目的是明确需求开发活动的时间计划，列出需求开发的任务、需要的资源，定义需求开发过程中各项活动的管理方式，识别需求开发活动的风险。
n 在项目开始时由于项目类型不一样，我们依据客户状况项目类型确定了项目的生命周期。一般采用的生命周期模型以“原型＋瀑布”和“迭代”为多。下面是依据项目特征选择生命周期模型的准则：
Ø 瀑布模型
l 适用于新的有较多用户的产品、平台/中间件开发项目，或者是用户对开发过程有严格要求的工程定制项目 。
l 充分理解用户需求,且需求是确定不变的。
l 用户有一定的能力，对需求的表述是确切的 。
l 所有过程工作产品的控制基线，需要有可见度和可靠性 。
Ø 原型＋瀑布模型
l 新领域的应用项目的开发：如企业应用系统开发项目等。
l 项目包含一种新技术，例：新硬件、新的系统架构等。
l 需求不很清楚。
l 存在关于性能、可靠性和可行性的主要的、未解决的问题。
l 用户界面对系统成功是很关键的，但不很清楚。
Ø 迭代模型
l 新领域、新技术的研发项目 。
l 规模较大的项目或产品 。
l 需求的清晰度低，且需要进一步的调查。
l 技术或体系结构方面的知识匮乏
n 依据需求的层次和已选择的需求开发过程制定需求的每个阶段或步骤的概要时间计划、资源、人员及职责，识别需求开发的风险。要点包括：
Ø 计划需求开发的时间
Ø 计划需求开发需要的资源
Ø 计划需求准备活动
Ø 计划需求调研活动
Ø 计划需求分析活动
Ø 计划需求开发需要的参与人员，并为他们分配任务和职责
Ø 计划需求评审和确认活动
Ø 计划需求开发干系人管理，并识别出需求开发活动的干系人
Ø 计划需求开发的内部、外部沟通方式
Ø 识别并分析需求开发的风险
n 需求开发计划的评审。
评审员一般有：客户、商务人员、同行专家、后续阶段的开发人员等。
n 收集客户资料，该活动的目的是为需求调研做准备。主要手段是从外围获取客户的信息，使需求开发人员了解客户行业特点。我们收集的资料一般有：
Ø 收集客户资料
Ø 客户的招标文件。
Ø 收集客户的产业结构、行业、地域分布、部门设置、员工规模、生产规模、经营规模等信息。
Ø 收集客户所在行业的行业标准，并从中提取需求。
Ø 收集客户所在行业的类似信息系统的状况，并从中提取需求。
Ø 通过其他途径了解客户行业的业务特点，如：行业的专家学者、互联网等。
n 需求调研人员的行业知识培训，使需求开发人员了解客户行业特点。
5. 获取调研
5.1. 需求调研的准则
获取需求是需求开发过程的主体活动，在实际工作中获取需求、分析需求、描述需求和需求的确认不是按顺序排列的活动，他们之间的关系应该是一个迭代的过程。在获取需求活动中我们应该遵循下列3个原则：
Ø 深入浅出
l 全面、深入的了解需求
l 简单、概括的抽象需求
Ø 站在用户的角度获取需求
l 业务是如何流转的？
l 是如何使用系统的？
Ø 以业务流程为主线,采用输入、处理、输出的思想获取需求
l 视同整个系统为一个盒子
l 视同整个业务为一个盒子
l 视同某个用户为一个盒子
|
输入什么 |
|
输出什么 |
|
系统、业务、用户。如何处理 |
|
谁输入 |
|
输出给谁 |
Ø 要从系统的全生命周期过程来考虑需求，下列是考虑的要素：
l 如何使用？
l 如何生产？
l 如何安装？
l 如何培训？
l 如何维护？
l 如何报废？
l 在每个生命周期的阶段涉及到的人、设备或系统？他们会有哪些需求？
项目的目的、目标和范围一般需要商务人员、项目经理去与客户高层确认。明确了项目的目的、目标和范围才能有效地控制预算、有利于需求调研的展开、能够对需求进行平衡和优先级的判断。我们一般用幻灯片的方式去与客户展现。
n 获取客户组织结构。通过与客户接触获取客户的组织结构。
|
董事长 |
|
总经理 |
|
副总经理 |
|
…… |
|
…… |
|
…… |
|
…… |
|
…… |
n 获取客户的业务规划。业务规划可能是客户整体的业务规划，我们需要找出我们项目要解决客户的哪些规划，这些规划是我们项目的出发点。
n 获取项目的目的。项目目的就是系统要解决的核心问题是什么，为解决该问题的约束是什么。项目的目的必须在需求调研前明确，这是进行需求调研的基础。
n 获取项目目标。项目目标需要是可度量的、可以达到的,项目的范围应能确保项目的目标可以达到。
n 获取项目范围。项目的范围一般从广度和深度来分析，广度就是系统覆盖的业务、部门、功能，深度就是我们做到什么程度。
n 与客户高层一起确认“项目目的目标和范围”。
n 对需求调研人员与客户参与需求访谈的人员进行“项目目的目标和范围”的宣灌。确认后的“项目目的目标和范围”需在客户方“项目启动会议”上进行宣贯，使所有项目干系人了解项目的目的和范围，这样才有利于需求调研的展开。
需求调研计划必须与用户一起制定，这样才能确保需求调研的工作顺利展开。虽然有调研计划，但是实际客户是否有时间参与访谈是不受控制的。我们制定计划时应该标识出任务的依赖关系，当计划发生变化后我们可以及时的调整计划。并且每个访谈任务最好能列出一些备选的用户代表。
n 依据组织结构，与各个部门来确定项目涉及的岗位，并对这些岗位职责进行描述。输出“岗位定义”。
n 识别所有可能的需求提供者。识别需求提供者的要点如下：
Ø 谁使用该系统?
Ø 谁维护该系统?
Ø 谁需要从系统中获取数据?
Ø 系统的运行会影响到谁?
Ø 谁来推广该系统?
Ø 谁测试该系统?
Ø 谁生产该系统?
Ø 谁购买该系统?
Ø 调研客户现有信息系统。
Ø 该项目的替代的系统
Ø 与该项目有数据接口、业务接口的系统
Ø 客户拥有的其他系统
n 制定需求访谈详细时间计划。计划要点如下：
Ø 计划需要客户参与制定
Ø 计划调研客户现有信息系统的使用状况
Ø 计划需求调研的问题的沟通及协调方法和流程
Ø 计划调研的方式、时间、地点、内容、需求分析员、用户代表及备选用户代表等
Ø 识别需求调研的关键路径
Ø 识别需求调研的风险
Ø 与客户确认需求调研计划。
Ø 需求调研准备
Ø 依据需求调研计划，为需求调研准备问题清单。
n 准备“需求调查表”，“需求调查表”一般包含下列内容：
Ø 现有系统是如何运作的？
Ø 现有系统存在什么问题？
Ø 希望新系统解决什么问题？
Ø 客户（用户）希望如何解决问题？
Ø 希望交付哪些工作产品？
Ø 最终用户的背景如何？
Ø 对系统的速度、可靠性、安全性、数据容量的要求？
Ø 系统的运行环境是什么？
Ø 最重要的3项需求是什么？
Ø 业务流程的启动条件、终止条件、正常事件流、异常事件流、输入数据、处理规则、输出数据。
Ø 数据的名称、来源、计算方法、类型、计量单位、精度、取值范围、去向、生成时间、产生的频度、高峰期的频度、存储方式、保密要求。
5.4. 需求访谈
一般获取需求是软件开发中最困难、最关键、最容易出错和最需要交流的方面。需求开发人员需要透过客户提出的表面需求理解他们的真正需求。我们一般通过访谈为主，辅以原型来获取客户需求。需求访谈的要点如下：
Ø 访谈前我们需要进行详细的准备，为每个不同的访谈准备好“需求调查表”。
Ø 需求分析员在调研前要了解用户的身份、背景。
Ø 限制面谈时间。
Ø 在调研前和用户讲清楚调研的意义、过程、以及需要注意的问题。
Ø 在调研时应该一个人发问，其他人记录。
Ø 需求调查应先了解宏观问题，再了解细节问题。
Ø 使用需求调查表进行调研，并做好详细记录。
Ø 调研时以业务流程作为总体的主线。
Ø 在用户讲解时,不要中断用户,使对方有充分的演说机会。
Ø 注意寻找异常和错误情况。
Ø 注意交谈的技巧，并尽可能多的记住用户的姓名、职务、爱好等。
Ø 详细记录访谈的时间、地点、被访谈的人员、角色、持续的时间、参与的人员、需求、为什么需要？
Ø 指出并记录用户没有未回答条目和待解决问题。
Ø 从不同的渠道进行需求的验证，如要验证已有的业务流程图，原有的部门或业务接口处理方式等。
Ø 当需求出现不一致时，由客户进行决策。
业务需求一般是与部门的主管进行获取，主要的目的获取出各个部门的业务接口以及部门内业务的操作流程。实际过程中很多客户并不能清晰地表达出他们的业务操作和业务接口，我们需要与各部门的业务操作者（用户）进行访谈，把获取到的需求进行分析和梳理，把各个部门内的业务操作拼接起来，才能获得一个完整的业务流程。所以业务需求获取的过程往往是与用户需求获取一起进行的。
n 通过访谈获取业务需求。在获取业务需求中我们应该是把部门作为一个盒子，获取这个部门如何与外部交互，在获取的过程中要明确每个操作涉及的角色。
n 整理业务流程图。将获取的业务需求描述为业务流程图（按角色和部门的泳道图），对关键业务处理要使用文字描述的方法进行补充说明。
n 获取客户对系统的非功能需求。非功能需求的数据一定要量化，不能使用好、快等形容词来描述性能需求，当客户不能提出非功能需求的时候，我们要从系统的基本特征提出非功能需求指标，并得到客户的确认。我们记住这个原则就是能量化则量化，不能量化那么我们就原形化。
n 将获取的功能需求和非功能需求整理到“需求一览表”中。
n 与客户部门主管及客户方各分管领导确认业务需求。
把具体业务操作者的工作方式工作内容我们称为功能需求，这些功能需求是业务流程每个步骤的细节描述，是系统构建的基石。我们在调研这类用户前应该做充分的准备，特别是“需求调查表”，并通过多种方法去验证这些功能需求的正确和合理性。同时在调研功能需求的时候我们也要对业务流程进行验证或获取。
n 在访谈中通过“需求调查表”获取每个操作的功能需求（包含非功能需求）。
n 整理获取的需求
n 复查调研记录的准确性、完整性和可理解性。
n 整理业务流程图，不仅要描述正常的业务流程，还要描述异常的业务操作的描述，业务流程的每个正常和异常的操作流程就是一个操作场景。
n 明确每个业务流程的前置条件、后置条件。
n 确定需要进一步调研的问题。
n 完善组织结构图与岗位定义文档。
n 将获取的功能需求和非功能需求整理到“需求一览表”中。
5.7. 通过原型来获取需求
我们在需求获取中往往会存在着理解不一致或表达不清晰的问题，为了解决这些问题我们可以通过原型来获取这些需求。一般通过界面原型来获取需求、通过设计原型来验证技术路线、通过功能原型来获取关键需求。通过原型展示消除需求分析员和用户对需求理解的不一致。使用原型的基本原则如下：
Ø 复杂业务流程的需求，尽量采用界面原型来抽取客户的需求。
Ø 当一些性能需求不能量化时可以使用设计原型进行验证和确认，以减少系统架构的风险。
Ø 复杂功能或特殊算法的需求，我们使用功能原型来抽取客户的需求，功能原型必须易于升级和维护。
分析需求的目的是消除原始需求中存在的冲突、重叠、遗漏、不一致、不切实际的问题。我们一般采用下列准则去分析需求：
Ø 正确性：所有需求必须是正确的、合理的、满足项目目标的要求。
Ø 必要性：所有需求必须是为完成指定任务所必需的。
Ø 可行性：在指定的环境和条件下，所有的需求必须是可行的。
Ø 完备性：为完成指定任务，这些需求是完备的、无遗漏的。
Ø 一致性：所有需求相互之间没有矛盾，是一致的。
Ø 非退化：任一需求的引入都不会导致软件性能的退化。
Ø 无歧义：任一需求的陈述都是确定的、不会导致多义性的。
Ø 可验证：任一需求都是可以测试、可以验证的。
通过列举需求，消除需求存在的问题，使得需求具备正确性、必要性、完备性、一致性等特征。
n 确定每条需求的来源和最终使用者，检查需求的正确性。
n 识别每条需求的最终确认者
n 消除用户需求中的矛盾和不一致
n 补充遗漏的用户需求
n 删除不必要的需求
n 定义非功能需求
n 定义外部接口需求
n 定义需求的其他约束
n 通过业务流程图、需求原型等方式细化需求
通过整理需求，我们对需求进行分析、识别出各逻辑或功能部分，根据相似性、偶合度及性能原则，将需求分类，推导并建立出产品组件，将需求分配到各产品组件上，同时，确定出与外部系统以及各组件之间的接口。
n 定义系统的非功能需求
n 定义系统设计的约束
n 定义功能需求
n 识别可复用的需求
n 对功能需求进行分类
n 建立产品组件（系统子系统或模块）
n 为产品组件分配需求
n 定义内部和外部接口需求
n 检查需求的可测试性
n 评价需求的可行性，必要与客户协商一些难以实现的需求，平衡需求以及质量、进度和成本。
n 划分需求的优先级
n 识别关键需求
n 标识出待确定的需求
n 识别需求的相关风险
n 编写“用户需求报告”，该步骤与步骤5.9一起进行。我们在进行需求开发时往往忽略了“用户需求报告”，但是这个报告是很重要的，是与客户确认需求和系统验收的主要依据。“用户需求报告”可以依据客户确认的要求进行裁剪，并采用不同的形式去展现，内容和建议展现方式如下：
| 内容 | 表现方式 | 工具 | 是否裁剪 |
| 客户基本信息 | 文字 | word | 不可裁剪 |
| 项目的目标和范围 | 幻灯片、文字 | PPT、word | 不可裁剪 |
| 组织结构图和岗位职责描述 | 图表 | Visio、excel、word | 不可裁剪 |
| 现有系统（或管理方法）及存在的问题 | 文字 | word |
|
| 业务流程图 | 图表 | Visio、excel、word | 不可裁剪 |
| 可能存在的变化 | 表格 | excel、word |
|
| 数据模型（单据、报表、台帐等） | 图表 | Visio、excel | 不可裁剪 |
| 功能需求（包含限制条件、处理规则、外部接口需求等） | 表格 | excel、word | 不可裁剪 |
| 非功能需求 | 表格 | excel、word | 不可裁剪 |
| 其他约束 | 图表、文字 | Visio、excel、word | 不可裁剪 |
| 待确定需求列表 | 表格 | excel、word | 不可裁剪 |
| 需求原型 | html |
|
|
“用户需求报告”是从用户的角度来描述需求，是直接阐述客户原始需求的文档。用户需求报告也可以根据客户要求合并到“需求规格说明书”，但是不可裁剪的内容必须在“需求规格说明书”中体现。
n 编写“需求规格说明书”，该步骤与步骤5.10一起进行。“需求规格说明书”是从开发的角度来描述需求，是一个基于系统设计方案（不是技术方案）的文档。
n 验证需求，一般我们从以下几个方面去验证需求“用户需求报告”、“需求规格说明书”：
Ø 组织和完整性
l 所有对其它需求的内部交叉引用是否正确？
l 所有需求的编写在细节上是否都一致或者合适？
l 需求是否能为设计提供足够的基础？
l 是否包括了每个需求的实现优先级？
l 是否识别了关键需求？
l 是否定义了所有外部接口？
l 是否定义了功能需求内在的算法？
l 是否在需求中遗漏了必要的信息？如果有的话，就把它们标记为待确定的问题？
l 是否记录了所有可能的错误条件所产生的系统行为？
Ø 正确性
l 是否有需求与其它需求相冲突或重复？
l 是否简明、简洁、无二义性地表达每个需求的？
l 是否每个需求都能通过测试、演示、审查得以验证或分析？
l 是否每个需求都在项目的范围内？
l 是否每个需求都没有内容上和语法上的错误？
l 在现有的资源限制内，是否能实现所有的需求？
l 是否任一个特定的错误信息都具有唯一性和明确的意义？
Ø 质量属性
l 是否合理地确定了性能目标？
l 是否合理地确定了安全与保密方面的考虑？
l 在确定了合理的折衷情况下，是否详实地记录了其它相关的质量属性？
l 可跟踪性
l 是否每个需求都具有唯一性并且可以正确地识别它？
Ø 特殊的问题
l 是否确定了对时间要求很高的功能并且定义了它们的时间标准？
l 是否对需求开发前和需求开发后进行的项目规模偏差的计算？
5.13. 确认需求
我们一般采用需求原型、“用户需求报告”、“需求规格说明书”与客户进行需求确认。在确认中我们最好能获取客户的书面确认。当需求确认后我们必须向客户明确需求变更流程和变更原则。
扫一扫
1073
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
