说明：笔记整理于京东韩杜忠的PPT（需求分析师培训）

---

1 软件需求是什么？

软件需求就是要解决一个工程是要“做什么”的问题。

2 需求问题的现状

现状1：前期模糊，中后期变更频繁。

---

分析要点：

1.变更是对原有需求的背离，还是补充原有不完整的需求？

2.背离发生在什么方面（流程间/流程内/数据使用）？

3.这些变更在需求阶段是否可能预见？

4.是否存在无效的变更响应（管理问题）？

改进方向：

1.变更的可预测性 --> 需求阶段标识（需求捕获 / 分析）。

2.变更渠道单一化、统一化（需求管理）。

现状2：软件项目上线运行时遇到很多阻力

---

分析要点：

1.是否为组织因素？

2.阻力源于操作层（技术）还是管理层（组织）？

改进方向：

1.清晰的业务需求导向（需求定义）。

2.面向不同层面的需求分析。

3.正确识别组织因素（需求捕获）。

现状3：软件项目上线运行后效果很差

---

分析要点：

1.为什么不能使用（用户界面/功能/手工系统）？

2.使用者的成本/效益分析？

改进方向：

1.抓准业务需求（需求定义）。

2.不同层面用户的分析（需求捕获/分析）。

现状4：产品二次开发量大

---

分析要点：

1.二次开发量最要集中于什么方面（业务规则/用户界面/流程顺序/流程细节/报表格式）？

改进方向：

1.工作流模型->顺序/细节

2.弹性设计->业务规则/UI

3.报表格式->理解数据模型

现状5：产品/项目完全不可用或崩溃

---

分析要点：

1.忽略了那方面非功能性需求？

改进方向：

1.性能

2.操作环境

3.可靠性

。。。。

3 导致项目失败的罪魁祸首

3.1 失败、成功项目统计

>>  根据Standish Group对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，只有约26%的项目获得成功。

>>  而在于这些高达74%的不成功项目中，有约60%的失败是源于需求问题。

>> 也就是说，有近45%的项目最终因为需求的问题最终导致失败。

>> 再次提醒：需求分析解决的就是“做什么”的问题。

>> 对不知道航行目的地的人来说，没有顺风！

3.2 项目失败原因（我们在哪里重重摔了一跤）

在Standish Group的报告中总结了导致项目失败的最重要的8大原因中，有5个与需求相关：

1. 不完整的需求(13.1%)；

2. 缺乏用户的介入(12.4%)；

3.不实际的客户期望(9.9%)；

4. 需求和规范的变更(8.7%)；

5. 提供了不再需要的(7.5%)

其余三个因素：

6. 缺乏资源(10.6%)

7. 没有执行层支持(9.3%)

8. 缺少规划(8.1%)

3.3 项目成功的因素

1. 用户的参与：15.9%

2. 管理层支持：13.9%

3. 清晰的需求描述(13.0%)

4. 合适的规划(9.6%)

5. 现实的客户期望(8.2%)

6. 较小的里程碑(7.7%)

7. 有才能的员工(7.2%)

3.4 软件需求曾经让我们如此狼狈

4 需求是什么？

4.1 业务需求

>> 业务需求是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求 。

>> 背景描述：XX保险公司希望充分利用日益完善的移动通信技术，在原有的办公系统的基础上进行扩展，使得在外的业务人员能够及时地获得客户、业务相关的动态信息，与此同时，实现企业内部的即时通信。

>> 业务需求/目标 ：通过该系统的实施，将人�工保费续缴、投保手续办理两项业务运转�周期缩短10％以上，使企业内部沟通效率�大幅改善，以帮助企业运转效率得以提高。

业务需求就是系统目标

>> 现状：功能分解盛行的今天，常常会犯“盲人摸象”的错误，这使得需求太过脆弱，难以经受考验。

>> 目标！目标！还是目标！--系统开发应目标驱动！目标是团队唯一的行动纲领。

>> 目标的定义不能够流于形式，应该具有以下特征：业务导向、可度量、合理、可行。要�注意目标太夸大会浪费资源，目标�太缩小会影响士气。

>> 目标通常就是业务需求！

4.2 用户需求

>> 用户需求是指描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。

>> 用户有不同类型：

        �> 管理型、事务型              > 信息系统、人

        �> 决策层、使用层              > 常用者、偶用者

>> 组织方法：用例、用户故事、特性

>> 例子：对快到期的客户，系统将通过短信�将续保信息发给该客户的代理人

4.3 软件需求

>> 从系统实现的角度描述的需求。

>> 开发人员（设计及分析人员）在业务需求、用户需求的基础上生成的。

>> 有时还需要考虑相关联的硬件、环境方面的需求.

4.4 功能需求

>> 功能需求是需求的主体，是需求的本质

>> 功能需求定义了：系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作

>> 零散（需求项）整理（特性、用例）

>> 敏捷方法：用户故事

4.5 质量属性

>> 产品必须具备的属性或品质

>> 可靠性：成熟性、容错性、易恢复性

>> 易使用性：易理解性、易学习性、易操作性

>> 效率：时间特性、资源特性

>> 可维护性：易分析性、易更改性、稳定性、易测试性

>> 可移植性：适应性、易安装性、一致性、易替换性

>> McCall体系：运行(正确性、可靠性、效率、�完整性、使用性)、修正(维护性、测试性、�灵活性)、转移(移植性、复用性、共运行性)

4.6 设计约束

>> 也称为限制条件、补充规约，这通常是对解决方案的一些约束说明。

>> 例如：必须采用国有自主知识版权的数据库系统…

>> 再如：必须运行在UNIX操作系统之下

>> 三如：用户将在户外完成作业

5 优秀需求的要点与实现

5.1优秀的需求

>> 完整性：完整描述即将交付使用的功能，发现缺少某项信息，可以采用TBD来标注。

>> 正确性：经过用户或用户信任的代理人审阅。

>> 无歧义：对所有读者只有一种一致的解释。

>> 必要性：每项需求记录的功能都应是用户真正需要的

>> 有优先次序：提供了实现优先级

>> 可行性：在已知能力和约束条件中实现

>> 可验证性：可以设计测试方法来检查

5.2 需求错误的代价

5.3 需求开发与管理

5.4 需求开发活动

5.5 需求获取

应收集什么信息：

�>>  问题域的描述--业务模型

>�> 要求解决的问题列表（需求）。

�>> 用户对解系统的行为或结构施加的任何约束。

信息来源：

>> 客户（实际的和潜在的）。

�>> 任何原有解系统（已有系统）及其文档。

�>> 原有系统用户 / 新系统的潜在用户。

>> 应用（问题）领域专家。

�>> 定义了任何接口系统的特片和行为的文档�。

>> 相关的技术标准和法规。

5.6 需求获取技术

1.阅读背景资料

2.头脑风暴

3.讨论分析

4.文档考古

5.面谈（用户访谈）

6.联合应用设计

7.用户调查

8.需求剥离

9.现场观摩

10.任务观察

11.用例和场景

5.7 需求获取的误区

>> 缺乏计划性：随意、走过场，预先没计划

>>缺乏科学性：未从本质入手

>> 捕获对象不明确，甚至造成岐义

>> 过于迷信现有文档

>> 过于迷信“听”到的东西

5.8 需求分析

所谓分析是指通过对问题域的研究，获得对该领域特性及存在于其中（需要解决）的问题特性的透彻理解并用文档说明。

分析方法：结构化分析法、面向对象分析法、面向问题域分析法

任何分析法，均需描述以下几个方面:

�>> 问题域的结构

�>> 问题子域的固有属性及行为

�>> 问题域中的重要事件及现象

�>> 需求：应产生的效果

5.8.1 需求分析方法--结构化分析

>> 从基于文本分析和规格文档  ->  图形建模表示法。

>> 结构化分析初期的模型：数据流图+E-R图。

数据流图：体现了流程，但是以数据为中心的流程

E-R图：体现了要存储的信息。

数据字典：对数据、数据流的描述。

>> 对问题域的研究力度不够大、 分析和设计之间缺乏清晰的界限，将�会导致不成熟的内部设计。

5.8.2 需求分析--何时进行

>> 应该在“业务需求”充分理解，并且收集了最本质的“用户需求”之后就开始需求分析，但并不是等到需求捕获完全做完之后

>> 交替进行，先把握用户需求主要部分，然后在分析的基础上引入系统级的需求（系统的设计与实现角度），并且分析模型，成为开发人员之间、开发人员与客户之间达成共识的一个平台

>> 分析的基础上，就会发现更多的不明确�项，更多待捕获的信息，这时就可以生�成第二次的需求调研的计划、问题、素材

5.8.3 需求分析--何时结束

>> 需求捕获、分析与建模、规格说明书的编写、需求的验证这个需求开发的循环，是在整个软件开发生命周期中存在的

>> 每一次的循环，都将在需求开发的工作要点与份量上有所不同，它们应该遵循以下：

    �> 从本质到边缘：本质、重要、次重要、一般、镶金

    > 细化阶段是需求开发最密集的阶段

    > 构建阶段需求开发逐渐减少

5.8.4 内容与形式

>> 需求分析与建模不应该是孤立的行为 ，产生的结果也不一定非得是规范度很高的标准文档，而应该重在分析、重在方法、重在交流、重在解决问题。

>> 团队聚在一起，利用白板甚至是纸张，在充分的合作下进行分析与初步建模是成本最低、效率最高、实用性最强的方法。

>> 对于这些活动所产生的结果，可以利用数码相机、扫描仪进行文档化 ，“直到你一定要用时，再写文档”。

对于比较重要、核心的内容，再采用Rose、Together这样的工具进行文档化。

5.8.5 编写规约

>> 规格说明书是对需求分析结果的文档化过程。

>> 比较“正规”的开发组织都会重视这个活动，甚至可以说是“重视过度”，而且产生出来的文档经常是与实际的开发脱离，完成之后就束之高阁，再也不使用、不更新。这是一个需求崩溃的信号。

>> 规格说明书的格式与所采用的开发过程、分析方法相关的，不同的方法格式不同。

>> 定义统一的格式是一个很重要的工作。

>> 规约内容的严谨、正确、无岐义是很�重要的。

5.8.6 需求验证

>> 这个工作大多数组织都不够重视，导致这个工作直到交付系统时才真正被履行，这也就是为什么客户拿到系统后才提出许多这样那样的需求变更，甚至认为整个系统都不是他所需要的。

>> 提高需求质量的重要手段：

    �> 需求评审

    �> 需求确认

    > 通过原型来验证需求。

6 需求开发与需求管理的分界

6.1 需求基线管理

6.1.1 为何需要

频繁的需求变更会破坏开发的节奏，使整个项目开发的进度陷入混乱和失控的状态，而且会变成一个“救火队”式的工作，整天都在处理突发事件。

6.1.2 主要思想

将所有现在的、将来的需求进行优先级评估，然后分解成为不同的组，每次迭代都选择其中优先级最高的部分进行开发，然后在迭�代完成之前，开发工作不响应变更，�这些划入的需求项就是需求基线的组�成部分。

6.1.3 操作思路

>> 我们应该在分析的基础上，将需求整合成为用例或功能项，然后对其优先级、依赖性进行综合性评估。

>> 优先级判断：业务人员确定业务决定，技术人员确定技术决策；“满意度/不满意度”模型。

>> 依赖性是指对于某些功能，在实现上有必须的依赖关系，即当某些功能没有实现时，另�外的功能无法开始，这就需要对其�进行调整。

7 需求变更管理

>> 需求变更是一定存在的，而需求变更管理并不是指逃避它，更不是说要避免它，它实际上是希望控制变更在基线内的需求不响应变更，为开发人员提供一个安静的工作时间状态

>> 专门的需求变更管理来对所有的需求变更进行响应，了解需求变更的关键意图、新产生的工作量，从而良好地进行重新计划，以便能够有效地解决其对整个开发带来的麻烦

8 需求跟踪

>> 需求的跟踪是指对需求的完成情况、变更影响进行系统化的跟踪与处理

>> “需求是不是已经被实现？”、“需求的变化将需要修改哪些设计元素？会影响谁的工作？对已经完成的部分是否有影响？”

9 需求管理的参与者

10 需求分析师

>> 需求分析员是对项目涉众的需求进行收集、分析、记录和验证等职责的主要承担者，是用户群体与软件开发团队间进行需求沟通的主要渠道。

典型活动：

定义业务需求、确定项目涉众和用户类别、获取需求、分析需求、为需求建模、编写需求规格说明、主持对需求的验证、引导对需求的优先级划分、管理需求。

必备技能：

倾听、交谈和提问的技巧，�分析、协调、观察、写作、组织、建�模、人际交往和创造能力。

必备知识：

现代需求管理技术、各种软件开发生命周期、领域知识。

需求分析员的来源：

用户转为分析员（软件工程知识欠缺）、开发人员转为分析员（领域知识、沟通能力）、主题专家（易按自己的偏好来构建系统）。

11 需求过程

12 需求大纲

1.Subject：

主题域，将一个复杂的大系统分解成由确定接口相互连接的多个子系统—构件图 /System（上下文关系图、事件列表、Report列表）/Subject

2.Event：

业务事件，信息系统行为主线条—（业务流程图、领域类图[E/R图]、用例图[opt]）/Event

3.Report：

查询、分析、统计等管理动作—（目的、数据、虚拟屏幕） /Report

4.Use case：

需求管理的分子！