软件需求最佳实践笔记（一）

1.软件需求最佳实践笔记 | 需求框架

前言：SERU是一套系统全面的需求方法论，可指导我们日常的软件需求工作。曾参加过徐峰老师软件需求最佳实践课程的培训，收益颇多，现通过笔记形式整理出来，以期与具有同样需求的读者共同学习进步。

S: Subject Area的首字母，可以理解为子系统，表示子问题域，核心的思想就是根据业务区划来分解系统，使系统的各个部分在业务上保持相对独立，降低耦合性。更强调业务分析，非功能分解；

E: Event的首字母，表示业务事件，它是流程的起点。通过业务事件的标识，就能够找到流程，通过流程就可以有效地将不同的场景串接在一起，承上启下。

R: Report 的首字母，表示查询、分析、统计，通过寻找管控点（从意图出发），以确定报表类型，再细化到具体报表项。

U: Use Case的首字母，即用例，一种需求技术（迄今为止应用最广泛的技术之一），是封装需求的最好手段，可以作为需求组织的最小单位。也可以理解为功能模块，只不过它更强调用户视角，而非功能分解。

需求过程包括四个阶段和20+3个工作任务集。

第一阶段是“需求定义”阶段，主要定义目标和范围。定义目标的工作任务包括项目背景分析、目标/愿景分析、干系人识别、干系人分析以及项目约束分析。定义范围的工作任务为业务子系统划分、业务流程识别、管控点识别。

第二阶段是“梳理脉络”阶段，工作任务包括业务流程分析、流程内功能标识、子系统用例模型整理、流程内数据关系分析、子系统领域模型整理、管控点分析、质量需求全局分析。

第三阶段是“填充需求细节”阶段，工作任务包括业务功能分析 、业务数据分析、业务报表分析、业务接口分析、质量场景分析、设计约束分析。

第四阶段为附加阶段，工作任务为预期读者分析、术语/缩写词说明、参考文献整理等。

软件需求最佳实践SERU包括四大部分内容：

1、原理、模型和误区

• 需求实践现状分析
• 不同软件项目的需求视图
• 软件需求与需求工程

2、需求开发

• 需求定义最佳实践
• 需求捕获最佳实践
• 需求分析与建模最佳实践
• 需求描述最佳实践
• 需求验证最佳实践

3、需求管理

• 需求基线操作实务
• 变更管理操作实务
• 需求跟踪操作实务

4、总结

• SERU过程框架总结

2.软件需求最佳实践笔记 | 需求实践现状

一、软件项目失败的根源

在信息化高速发展的今天，构建与时倶进的信息化系统已成为所有政府、企事业单位的重点课题之一。然而在软件项目实施过程中，进度超期、经费超预算、变更频繁的现象层出不穷，甚至有许多项目根本无法达到预期的目标，更谈不上为业主创造真正的效益。归根结底，软件需求实践这一共同的软肋是问题的根源。

十大成功保证中有三个是直接与需求相关的（下图高亮显示），累计权重达到37.1%；而十大败因中与需求直接相关的更是高达五个，累计权重高达 51.6%，可见需求问题对项目影响程度之高。

Standish Group 总结的软件项目十大成功保证和十大败因

五个需求相关败因简要分析：

1、未从用户的业务视角去写用户需求说明书：需求规格说明书用户看不懂，充斥着数据字典、字典管理、报表子系统之类的以技术动词唱主角的字眼。如果你看到这样两份《家装方案设计书》：第一份的目录中是诸如“客厅”、 “厨房”、“卫生间”、“卧室”、“书房”……另一份的目录中是诸如“水路”、“电路”、“家具”……你喜欢哪份？需求规格说明书应该采用业务导向的树型层次结构来组织。

2、**缺乏用户参与：**在很多的软件项目中，用户都不能有效地参与到项目中来，也许诸如“你们先做， 做出来我们试试后再改”之类的话。主要是客户代表没有积极性，不知道通过新系统能获得什么好处。需要基于业务利益（解决问题、创造机会、提高管控力等）进行沟通。

3、**提供了用户不再需要的：**产品经理、开发人员想当然的认为是卖点，是亮点，其实用户压根用不到。

**4、不切实际的用户期望：**用户往往异想天开，去提一些现阶段无法满足的需求。

**5、需求变更频繁：**频繁的需求变更不仅增加了项目成本，还增加了项目失败的风险。

软件需求的迷思

• 沟通失真

根据相关的研究，在信息的传递过程中，如果没有采取任何措施，那么在沟通过程中信息衰减可能的最大值高达60%。而在软件开发过程中，需求信息通常要经历用户代表、需求人员、设计人员再到开发人员，因此最坏的情况下，开发人员获得的信息仅是原来的8.4% ，这是一个十分可怕的结果。

两个手段可避免沟通失真：一是有效地利用文档，将达成共识的信息文档化；二是Review，通过再次的审读，尽早地暴露出错误，用户代表阐述了需求之后，需求分析员用自己的语言再复述一遍。

• 客户需求的放大

比较第1幅和第10幅图，会发现用户在描述自己的需求时做了许多“添砖加瓦”的事，担心自己“亏损”。这种思维对于任何一个客户、任何一个人而言都是本能反应。

在进行需求捕获活动时，客户代表一般会给出自己认为“好”的解决方案，除了掌握要做什么（What)外，更要多问“为什么”，了解用户提出需求的真正动机（Why)。

• 项目经理的需求控制

比较图第1幅和第2幅图，会发现项目经理在沟通的过程中会导致需求产生偏差。项目经理们通常身兼多职，项目管理、需求分析、架构设计一肩挑，在需求捕获的过程中，总会“及时”地在脑海里勾勒出技术框架和路线，尽可能地控制需求的范围。但实际上，有些需求“表面上”是控制下去了，但却在后面以“需求变更”的形式全回来了。

好的做法是以业务为线索来组织需求，基于“Why”的层面对需求建立高层次的认识。

• 分析人员的技术加工

第3幅图，现在许多名称中包含“需求分析”、“系统分析”之类的职位，大多是由技术骨干担任的，因此在工作中很少从业务角度进行分析，更多还是追求技术框架、新技术。“技术能力”对他们的未来发展更为重要。

所以项目要配备专业的需求分析师，需求分析的本质在于业务分析，而非技术分析。

二、 透过现象，分析本质

有一种观点是“软件项目失败的关键在于项目管理技能不足”。虽然提高项目管理能力很重要，但它不是万能的；现在许多软件项目遇到的问题，从表面上看是项目管理的问题，而其根源实际上是需求问题。

• 需求变更频繁

如果遇到频繁的需求变更，则可从下图的几个方面进行原因分析。

**①背离原有需求：**说明需求描述与沟通有问题，导致需求在交流过程中失真；因此应该加强需求过程的管理，加强沟通手段的管理。

**②需求变更集中在流程间：**说明需要采用工作流引擎。

**③补充原有需求：**说明需求捕获有问题，需求不完整；应该加强需求捕获方法的组合应用，加强对业务模型的梳理。

④还可能涉及数据字段的变更，业务规则的变更，以上只是提供一个解决思路，需要具体问题具体分析。

• 上线阻力大

许多软件项目在上线时会遇到阻力，有的来自于操作层、有的来自于管理层。究其原因，通常是软件项目遭遇了行政因素。

一种是利益冲突，信息系统会对业务流程产生影响，会提高业务数据的管控力，因此经常会伤害到某些部门的既得利益，有时会导致新的利益冲突。

另一种是工作量增大，对于基层（也就是操作层）而言，新系统通常会增加他们的工作量。

解决思路可从下面几个方面考虑：

①提高易用性：诸如“业务申请受理”之类的场景，其具有重复性、规模大的特点；在需求阶段应标识出此类功能，在设计时充分基于业务实际场景来提高易用性，否则可能会使其成为日常工作的瓶颈。

②工作量价值化：基层人员很多时候无法理解新增工作量的意义，加大了其抵触情绪；在需求阶段应尽可能地标识出这些工作量对于实际业务、管理工作等方面带来了什么样的好处，以提高基层人员的积极性。

③将数据迁移、准备工作独立出来：很多系统在刚上线时需要对历史数据进行处理，或者是录入大量的基础数据，在需求阶段应该标识出这些工作，将其独立出来，不使其成为基层人员的负担。

• 运行效果差

近几年，信息化项目逐渐开始从“装门面”向“业务价值提升”转变，但有不少软件系统在上线之后运行效果差，未取得预期效果，并没有真正用起来，无法验收。从根上说就是软件项目在开发的过程中缺乏有效的目标作为指引，与实际的业务过程存在脱节现象。

解决思路是从问题或机会入手、从障碍和困难出发。

①从问题或机会入手：提高管理人员的推动力，将系统的实施与管理人员的利益连接起来，否则不可能获得这些管理人员的真正支持。而针对不同管理人员的内动力分析，就是需求阶段一个很重要的工作。

②从障碍和困难出发：有了管理人员的推动，可以从制度上、过程规范上要求操作人员应用系统；但要使他们有积极性还需要为他们扫清使用障碍（也就是根据场景来设计更易用的系统)，解决一些困难（也就是在原系统或手工操作过程中难以克服或需花费大量时间的问题）。

• 完全崩溃

最终的软件系统完全不可用，或者称之为崩溃了！这种情况大多是因为忽略了某方面的非功能需求，例如系统容量不足以支撑业务需求，系统没有足够的可靠性而经常死机等。

所以，软件的非功能性需求不可忽略，采用“定量”的方法来描述非功能需求。

---

3.软件需求最佳实践笔记 | 需求视图

随着信息化应用的逐渐深入，软件项目在企业、政府等各类组织中所担负的角色也越来越多，应用也在逐渐深入，而不同的软件项目有不同特点，对需求工作产生了诸多影响。

下面将从信息系统、嵌入式系统、软件产品三个不同角度来说明如何进行相应的需求工作。

一、信息系统的需求视图

• 信息系统的本质

信息系统是人、数据、过程和接口的组合，它们之间相互作用，支持并改进企业和政府的日常运作，并支持管理人员和用户解决问题和做出决策。

• 信息系统的类别

在信息工程理论框架中，信息系统分为联机事务处理系统（OLTP)、管理信息系统（MIS)、主管信息系统（EIS)、决策支持系统（DSS)、专家系统、办公自动化系统（0A)等。现在的系统都是复合型的，很难简单、纯粹地归属于哪个类别中。但仔细研究它们之间的关系，会发现它们对需求工作有着很好的指导意义。

•联机事务处理系统是数据的生产者：对流程进行电子化，在这个过程中，将通过用户输入、系统采集等方式积累出大量数据。

•管理信息系统是数据的消费者：为中层管理人员（事务型管理人员）提供服务，主要是通过查询、分析、统计的手段来完成监督、控制等活动，其核心载体是报表。

•主管信息系统、决策支持系统是数据的高级消费者：为高层管理人员（决策型管理人员）提供服务，与管理信息系统类似，但会对数据做更深层次的挖掘。

•专家系统是一种模拟人类专家解决领域问题的计算机程序，是对个人知识的沉淀，同时也是数据的消费者。

•办公自动化系统是对沟通与协作的直接支持。

此外还有IoT系统等，也是数据的生产者。

• 联机事物处理系统——流程电子化

OLTP系统的核心是实现流程的电子化，构成系统的三元素是人、过程（也就是工作流程）和工具。工作流程是一个企业或组织的主线索，因为归根结底企业或组织存在的价值就在于对外部客户请求的响应，在为外部客户创造价值的同时为自己带来相应的利益。

流程分析（业务事件）是OLTP系统的关键线索和主要视图。

• 管理信息系统——数据信息化

管理信息系统主要针对的用户群体是企业/组织中的中层管理人员。管理活动的本质就是计划、控制、组织、协调，而这些工作体现到信息系统中就是一系列查询、统计操作（以下称为报表），即将企业/组织的日常运作中产生的大量数据转化为信息，为其提供管理活动所需的支持。

报表体现了管理人员在日常管理中对业务事件执行情况以及业务实体的内容及关系的了解。可分为事务管理类报表和管理决策类报表：

事务管理类报表实际上是体现了中层管理人员在日常管理活动中对业务事件执行情况以及业务实体的内容及关系的了解。

•**进度报表：**呈现业务事件的进度信息，是对业务进程进行管控的有效手段。它通常按周期生成或日程生成；关键指标报表也是一种特殊的进度报表，它是对前一周期关键活动的汇总。

**•异常报表：**业务事件中发生的异常通常是中层管理人员很关注的视角，例如预算超支的项目列表。

**•常规报表：**就某一情况为管理者提供详细的数据，通常提供的是针对一个业务实体的信息。

**•需求报表：**按中层管理人员的要求提供相应信息，通常涉及多个业务实体之间的信息，如产品销售形势表。

决策管理类报表则会在一个事实（可能是业务实体也可能是业务事件）的基础上，结合其关心的几个不同维度来建模。

决策层管理人员可对销售数据按时间（销售周期、特定的时间段等）、客户（某个客户、某类客户等)、产品维（某个产品、某类产品等)、销售人员维（某个销售人员、某个销售小组等）进行分析，甚至可能对多个维度进行综合分析。

这种情况下，不是基本的数据库操作所能够很好地满足了，因此经常需要对历史数据进行抽取、加工、转换，这时也就会产生对数据仓库、数据集市的需求。

在报表分析时，可从Why(目的是什么）、What(怎样获得）、How(如何展现）三个层次着手。

• 决策支持系统（DSS）——决策信息化

决策场景是DSS系统的关键线索和主要视图。

非结构化问题也不是一成不变的，通过人类的不断研究，如AI技术的应用，也可能最终会转换成结构化问题。

• 专家系统——个人知识转换为企业/组织知识

专家系统对于企业/组织而言，最为关键的价值在于实现个人知识到企业/组织知识的转换。不仅仅有相应的数据视图，更重要的是有相应的经验模型、判断模型等。

*工作场景是专家系统的关键线索和主要视图。*

• 办公自动化——协同信息化

OA中有一个很重要的功能，那就是对协同的支持。近几年来，企业/组织开始关注流程的效率。将串行的流程转变成并行的流程就是一种很重要的策略，但并行执行的流程就涉及并行部门、岗位之间的沟通和协作问题，*这些协作场景就是此类系统的需求线索*。

例如，可能会需要文件交换、信息共享等，先将这些场景归纳出来，再针对每个场景细化其中的行为需求，就能很好地完成此类系统的需求收集与整理工作。

注：此0A(办公自动化系统）非大家日常谈到的OA，它只是其中一个子集。平常开发的OA系统会涉及联机事务处理系统、管理信息系统的范畴。

前面，针对不同的信息系统分析了具体的需求线索，但这些都是主线索。在信息系统的需求工作中，还需要注意其他的一些线索，它们概括**为人、事（过程)、物（数据)、接口。**其中事、物是主线索，人和接口是辅助线索。在联机事务处理和办公自动化系统中，事是主线索，而管理信息系统、决策支持系统中物是主线索，在专家系统中也更偏重于物的线索。

二、嵌入式系统的需求视图

嵌入式系统可分为面向直接用户、面向特定设备和面向综合应用的三类系统。

• 面向直接用户的嵌入式系统

在梳理需求的时候应该采用层次结构来梳理。此类系统的需求主线索是具体的使用场景，而为了更好地保持其完整性，建议根据其逻辑性归纳成不同的功能域、功能子域。

手机系统分析示例

手机接打电话行为分析：

**行为一：**用户在接打电话的时候，经常会遇到需要记录一些电话号码、地址之类信息的情况，相信对于“你等一下，我找下纸和笔”之类的回答并不陌生，但这里就蕴藏着潜在的功能点。细致的需求人员就会设计这样一个功能，当接听电话时能够调出“便笺”，同时打开免提，这样用户就无须找纸和笔了。

**行为二：**用户在接到询问某人电话号码的电话时，用户可能就需要能够在通话状态中调出“通讯录”的功能。

*对于面向用户的嵌入式系统，行为分析是要点。*

• 面向特定设备的嵌入式系统

需求主要包括对外接口和内部功能两部分。

**对外接口：**首先找到相关联的外部系统，然后明确外部系统与其的功能交互点。因此在需求描述时可以采用上下文关系图确定其与外部系统的协作。在标识了这些接口之后，接着在需求的后续阶段逐步分析、捕获这些接口的使用时机、功能要求和内容等。

**内部功能：**可以采用事件作为线索。事件分为外部事件（通常是外部接口触发的）、状态事件、时间事件和内部事件（内部设备触发的）。识别事件最基本的方法是寻找触发点。如果内部功能比较复杂，就需要对这些事件进行归类，归纳成不同的功能域、功能子域。

*面向特定设备的嵌入式系统，外部接口和事件分析是要点。*

三、软件产品的需求视图

与软件产品相对应的是软件项目，项目通常是针对一个企业/组织的，软件产品则是为多个企业/组织设计的，生命周期会更长。

从需求的角度，根据与问题域的相关度将软件产品划分成3类。而其中游戏类软件通常是不需要需求分析人员的，需要的是策划、编剧。

• 信息系统类软件产品

诸如进销存、ERP、OA、财务电算化等软件产品都属于此类产品，是与现实问题域息息相关的，成败关键在于对问题的理解。与信息系统项目在需求梳理时采用的方法是类似，也有自身固有的特点。一般需要做目标市场分析和商业模式分析等。

目标市场分析

商业模式分析

商业模式举例

产品体系设计

产品体系设计与需求工作有直接相关的核心要点是根据不同的商业模式来封装变化点。将不同商业模式之间的共同点做一些抽象，然后将不同点封装到可插接的模块中。

①共同点抽象

例如对于上面提到的直销模式，不管是电话销售还是邮件销售，它们的共同点就在于销售漏斗（潜在客户+跟踪客户+意向客户+签约客户），不同点在于具体的跟踪手段。

②先找出通用性，再通过插接解决扩展性

假设在开发一个人力资源管理软件时，发现不同企业对请假的审批流程是不同的，那么该如何处理呢？通过分析发现，整个请假过程可以分解成如下图几个步骤。

填写请假条和记录请假两个阶段是通用的，而请假审批则是复杂的，那么就可以将其抽取出来封装在独立的模块中，并预留插接点（接口）。填写请假条模块提供输出请假条的接口，记录请假提供用来接收请假审批结果的接口，请假审批使用这两个接口。

• 工具软件类软件产品

工具软件通常利用电脑为人们解决日常工作、生活中可能遇到的问题。其灵感通常来自于两个方面：对现实世界中某种工具的仿真，例如计算器、便笺等；利用电脑的优势创造新的体验，例如QQ、电子词典、AutoCAD等。

***基于使用场景的困难点分析是工具软件的需求要点。***对于工具软件而言，人机交互部分是十分重要的，可以在需求描述时采用用户界面原型驱动的形式。

---

4.软件需求最佳实践笔记 | 软件需求与需求工程

一、什么是软件需求

可从三方面对软件需求进行定义：

业务知识：包括业务事件、业务实体和业务规则。

问题列表：用户在工作中遇到的困难与障碍，这也是软件开发时需要解决的问题。

其他因素：包括了一些设计约束和非功能方面需求。

• 需求的三个层次

包括业务需求、用户需求和功能需求。

反映到需求文档中，可用下图表示：业务需求一般在项目视图/范围文档中体现，用户需求通过用例文档以用户的视角呈现，软件需求需要写到软件需求规格说明书（SRS）中。

• 需求的三种类型

需求按类型划分可分为功能需求、非功能需求以及设计约束。

• 优秀需求的标准

优秀的需求要符合以下几个标准：

**①完整性：**验证需求规格说明书中罗列的主题域、业务事件、业务活动、业务步骤等是否完整；同时，需求是有层次的，高层管理人员、中层管理人员、操作人员，在验证需求完整性时需要采用分层评审。

**②不失真：**求在信息传递的过程中不失真，即正确和无歧义。

③有优先级：“事有轻重缓急”，想要更好地对项目进行管理，就需要有效地区分出优先级。

④**有技术早期介入：**解决方案既要具备可行性，又要具备可验证性。

而一旦需求不完整、失真，会使软件项目付出很大的成本代价，甚至失败风险。

上张图是说，如果在需求阶段只需花费1个单位时间就能改正的错误，拖到设计阶段来改正就需要5倍的时间，到了编码阶段将是10倍，测试阶段可能达到20~50倍，而到了运行与维护阶段或许会达到200倍之多。足见需求分析人员对一个软件项目的重要性。

二、软件需求工程

• 需求工程的范畴

软件需求工程包括需求开发和需求管理两个过程域。需求开发是收集、分析、整理、编写、验证需求的全过程，重点在于开发出高质量的需求规格说明。需求管理是对需求的实现、变化进行追踪的全过程，重点在于确保开发的软件满足这些需求。

• 需求开发工作要点

通过需求获取、需求分析、编写规约和需求验证4个具体活动多次循环的形式进行需求开发。

需求开发工作示意图

一般经过三次循环，可形成一份合格的需求产物。

需求开发的三次循环

需求获取也称为需求捕获，它们都是主动动词。而现实的需求实践中最大的问题恰好是比较被动的。存在捕获范围不足、缺乏计划性、缺乏科学性、捕获对象不明确、捕获手段不足等问题。

软件需求捕获中的常见问题

需求分析是需求开发中的核心任务，但在实践中却经常被“忽略”，也就是直接将需求捕获得到的信息整理到需求规格说明书中。

①需求分析首先是业务分析，是对问题域进行研究，要从从业务线索入手，而非系统结构。

②需求分析是一种分解活动，将待开发的系统按职责划分成不同的主题域(可以将其理解成子系统，在划分时是按业务视角进行），然后分解成组成该主题域的所有业务流程，再分解到业务活动（用例）、业务步骤。

③需求分析是一种提炼与整合活动：将用户的原始需求合并到业务活动中去，将各个业务流程合并成全局业务流程图，将每个业务事件相关的领域类图片段合并成全局领域类图，将各个业务事件的用例图片断合并成全局的用例模型等。

④需求分析是一种规格化活动：要找到冲突、矛盾，并且通过访谈等手段解决这个问题。

注意区分内容与形式，需求分析是任务，建模是手段。建模的过程就是分析的过程，核心思想是用“图形”代替“文本”，以更加可视化的方法表述信息。建模产生的结果并不一定非得是规范性很高的模型，重在分析、交流，重在解决问题。

需求分析和需求捕获交替进行，获取了部分信息之后，就可以对其进行分析，并将分析的结果填写到已经规划好章节的需求规格说明书中。通过分析会发现更多的不明确项，更多待捕获的信息，这时就可以生成第二次需求调研的计划、问题、素材。

注：按照现代软件工程思想，通常会采用迭代、增量的开发过程，需求分析工作贯穿整个软件生命周期。

编写规约是将需求分析结果文档化的过程。软件需求规格说明书总结了四字要诀：共享、更新，而每个要诀都包括两层含义。

**需求验证，**对于需求验证工作，大多数组织都不够重视，有时只是找一个客户代表签字确认，甚至直到交付系统时通过测试系统来验证。这样当系统交付时，可能会出现大量需求变更。

需求验证的关键手段是评审，且要分层次、分内容进行验证，以期在早期阶段尽可能多地暴露出问题。

• 需求管理工作要点

需求管理工作包括基线管理、变更管理和需求跟踪三个活动。而要想真正使需求管理活动获得实效，可以将整个管理改进分成4步：

①统一明确的需求项划分标准；

②引入基线管理；

③引入变更管理；

④引入需求跟踪。

• 需求分析人员的技能组成

需求分析人员是需求收集、分析、记录和验证等职责的主要承担者，是用户群体与软件开发团队间进行需求沟通的主要渠道。他们需要完成的活动包括：定义业务需求、确定项目涉众和用户类别、获取需求、分析需求、为需求建模、编写需求规格说明、主持对需求的验证、引导对需求的优先级划分、管理需求等。

因此必须掌握的技能包括倾听、交谈和提问的技巧，分析、协调、观察、写作、组织、建模、人际交往和创造能力。而这些能力可以概括为业务知识、技术知识和沟通能力三个方面。

• SERU软件需求过程框架全景图

对于遗留系统项目，SERU模型也适用。在S层，考虑项目是一个新主题域，还是对某些主题域产生影响；在E层，考虑项目新添或修改了哪些业务事件。

5.软件需求最佳实践笔记 | 需求定义

一、需求定义的任务

需求定义，就是确定项目的宏观需求。也就是定义项目的业务需求，明确项目的目标和范围。

• 需求定义在项目立项时完成

清晰的项目目标和范围定义，能够引导需求工作顺利进行。

而事实往往是有不少项目在立项时并没有很好地完成需求定义工作。造成这一现象的主要的原因是：在项目立项阶段开发团队（包括需求分析人员）还没有开始工作，可能招标还没有完成，项目团队还没有成立。不管怎样，需求分析员应认真审视需求定义阶段的产物，如果没有达到要求必须做一些“补课”工作。

• 需求定义的理念与策略

在现实工作中，似乎每个项目都经历了立项环节，也会产生一个定义项目目标和范围的文档。但经常比较空洞。诸如“全面提高企业的信息化应用水平”、“打造一流的信息化管理平台”等难以落实的虚目标。

要对混沌不清的项目目标进行破解，通常有两种方法。

①内部寻根

尝试在提出项目的企业/组织内部寻找真正的项目发起人，和这些项目发起人的深入沟通。

②外部溯源

外部因素所激发的项目，需求定义时要找到目标参照物，通过对目标参照物的分析与了解，就能够很好地做好需求定义工作。有可能领导在外面考察，他山之石给他留下了较好印象，即受到了外部刺激。

**需求定义工作的着手点可概括问题与机会。**因为对于信息系统而言，要么是解决问题的，要么是创造机会的（例如，互联网发展催生了网上银行、外卖、打车等新的商业模式）。

基于以上分析，需求定义的策略可总结为四步：

**目标：**通过内部寻根或外部溯源的方法，先将项目要解决的问题或机会罗列出来，如“废品率太高”。

**问题：**对目标层面的问题进行分析，找到导致该问题产生的根源问题，然后将其全部列出来，例如“订单不准确”、“运输损耗”等。

**可选方案：**针对每个问题罗列出可能解决的方案，如针对“订单不准确”问题，可选方案包括“用户直接通过电子化手段下订单”、“对订单内容进行电子化校核”等。

**建议方案：**最后从各种可选的方案中挑出认为比较合理，对解决问题贡献度更高的方案。

二、问题分析的五步法

RUP给出的问题分析5步法，为需求分析人员提供一个很好的理论指导框架。

• 在问题定义上达成共识

问题分析就是理解真实世界中的问题和用户需求，并提出解决方案的过程。第一步是把问题拿出来，得到所有人的共识。虽然名为问题定义，实际上也可以定义为机会点。

下面是一个描述机会点的例子：

对问题进行了正确的定义，意味着成功解决了一半。而在问题定义时应该善于使用转换和本源两个技巧。

本源—发现问题的真正所在，建议读一下《你的灯亮着吗？》这本书。

• 分析问题背后的问题

通常使用鱼骨图分析来找到原因，然后再通过收集相应的统计数据，再以直方图表示出来，并对其进行相关的分析。

鱼骨图示例

帕累托图示例

• 确定相关人员和用户

一般按Stakeholder和用户两类角色进行分析。

• 定义解决方案的界限

首先需要确定范围和边界，范围是指系统涉及哪些内容（事、物），而边界则是系统与人的职责边界。

产品销售公司的销售过程示意图

先看1号边界，如果系统只实现“记录订单”的功能，意味着用户必须手动完成接订单和信用核查工作，系统只起到了一个电子化功能。这显然不是投入20万~30万的系统所应该采用的边界。

接着看2号边界，不仅实现了记录订单功能，还可根据该顾客的历史交易记录、提供的信用卡进行信用检查，这里实现的功能显然是与用户的投入相匹配的。

再看3号边界，也就是实现订单接收的自动化，可能的方法有呼叫中心、Web网站等。这些功能虽然很合理，但它是超出系统预算的，不应该将其纳入系统边界内。

综上分析，2号边界是一个很不错的选择。超出预算的边界，要进行边界谈判。当然也有创新边界，对于上例而言，通过考虑计算顾客对各种商品的消耗速度，直接在客户缺货前主动营销。

• 确定加在解决方案上的约束

可从技术开发和项目实施两个方面去考虑：

三、需求定义的产物和要素

• 需求定义的产物

一般包括项目综述（POS）和愿景（Vision）。

POS的主要内容：

Vision的主要内容：

• 需求定义的要素

**①目标：**写作过程中，应该注意从目标、业务优势、度量指标、合理性、可行性和可达成性方面进行编写。

一个好的目标描述应该满足SMART原则。具体（Specific)的，能够指导具体的工作，可度量（Measurable)的，能进行成本/效益分析，可达（Attainable)的，否则是没有意义的目标，和其他目标具有相性关（Relevant)，有明确的截止期限（Time-based)。

项目目标编写示例

**②范围：**项目的范围对于需求分析人员的意义是相当重要的，可以说需求分析人员在进行需求定义工作时，核心的工作就是确定范围。

很多书籍推荐通过上下文关系图描述范围，但在实际的应用过程中仍然存在很多疑问与误区。SERU推荐的方法是“两图一纲”。

③相关人员和用户：在进行需求定义时，需要对和软件项目相关的人员进行研究。系统的使用者（用户）也是相关人员的一种，不过在整理这些信息时，思考的角度是不同的。

对于用户而言，需要收集和分析的信息包括：与主题相关的经验、技术上的经验、智力能力、对工作的态度、对技术的态度、受教育程度、语言技能、年龄、性别等信息。换句话说，是对其能力进行建模。

项目相关人员分析示例

四、需求定义范围

定义需求范围通常会用一段话，或者一个程序分解结构（系统+子系统+模块+子模块）来表示。自顶向下的程序分解结构使用户无法介入到需求范围的评价中，导致需求范围执行时存在困难。

SERU建议采用业务导向的层次结构来，通过三个相互独立的步骤逐渐演化出需求的范围定义，采用两图一纲（构件图、上下文关系图和需求大纲)来描述，为软件需求规格说明书提供最初的目录结构。

以“体检医院管理系统”为例进行分析说明。

体检医院管理系统背景资料

• 划分主题域（子系统）

①按照业务的职责区块来划分的子系统称为主题域

传统子系统划分示例

这种划分在进行需求捕获和分析时会发现各个子系统和模块与客户部门是交错在一起的，每个模块都需要对不同的部门进行调研。并没有很好地把业务结构体现出来。

原因在于传统的划分方法经常采用“业务名词+管理”的形式命名，其中业务名词实际上是业务实体，也就是“物”的线索；对于大多数业务系统而言都不是最佳的分解方式，因为这些业务实体会牵涉到大量的业务流程。

更合适的分解方式是根据业务流程来分解，也就是以“事”为线索。

②为什么使用构件图

每个系统/主题域都不是孤立存在的，它们之间总是会有这样那样的协作，需要提前将这些协作标识出来，这就是主题域之间的服务接口。各个主题域之间的服务接口是需求变更的防火墙。

某连锁酒店构件图示例

在构件图中，只有两种元素，即构件、接口，构件对接口而言有两种关系，一种是实现关系（表示这个接口是某个构件提供的），另一种是使用关系。

在考虑和标识服务接口时，最有参考价值的思想是“职责驱动设计”，通过一个实际的例子来阐释。

所谓的职责驱动设计，简单地说就是职责必须匹配。什么是职责呢？一个类或构件的职责包括两个方面：一个是知道的事，对于一个类来说就是它的属性；一个是能做的事，对于一个类来说就是它的方法。

**解决的方法之一是将行为接口改变成数据接口。**抽象出一个“逻辑资源池”的概念，从而避免营账系统直接预留物理资源，而只是预留逻辑资源，让资源管理系统来完成物理资源与逻辑资源的对应关系。于营账系统而言，并不需要知道每个物理的资源情况，只要知道某个片区是否有足够的资源数即可。

③体检医院管理信息系统案例分析

下面是主题域划分的思考过程：

**销售区块：**主要完成对客户的销售、服务跟踪，再考虑到其部门的命名，把针对这个职责区块的主题域称为“客服管理子系统”。

**生产区块：**负责向体检者提供全程的体检业务。因此这个职责区块的主题域称为“体检业务管理子系统”。

**后勤区块：**为企业提供支撑的，它涉及了两个相对独立的部分：一个是财务，另一个是物资。考虑到它们之间的独立性，通常在划分主题域时会建议将其分成两个，即“财务管理子系统”和“物资管理子系统”。

目标决定范围。在最终确定主题域之前，还需要结合目标来考虑这些主题域。财务管理子系统对系统既定目标没有直接贡献，根据目标决定范围的原则，就应该将它移出。

主题域划分完毕后，开始绘制构件图。

绘制完成的构件图示例

• 确定主题域范围

以“体检业务子系统”为例来说明上下文关系图的绘制方法。

首先将体检业务子系统当作一个黑盒子，用一个矩形表示；接着思考该主题域有哪些外部的Customer，很显然最重要的是体检者。所以先分析他会发起对系统有影响的什么行为（事件）。显然，申请体检就是最重要的一个，然后考虑为了处理体检者的申请，主题域的内部Worker要做些什么，这个思考过程将得到如下图所示的片断。

体检者除了申请体检之外，还有什么独立的行为呢？体检者可能会因为有事而中途修改体检项。这是一个独立的、不是必然发生的事情。首先应该由体检者提出申请，然后由收费人员做相应的处理即可，因此将这两个信息添加到上下文关系图上，这时就会得到如下图所示的结果。

接下来再看看是否还有其他Customer。可以从构件图中获得线索，发现客服管理子系统会需要查询团队体检的进程，财务部门会输入团队缴费信息。将其添加进来，就可以得到如图所示的结果。

外部的Customer都分析完之后，上下文关系图的主体也就完成了。接下来再思考内部的Worker是否有主动的行为。例如：维护人员要管理体检项（包括名称、费用等）信息、系统通知体检者取报告。将这些内容添加到图中，将得到了一个完整的上下文关系图，如下图所示。

• 标识业务事件与报表

上下文关系图绘制出来之后，整个主题域的范围也就框定出来了，但还不足以为后续的需求捕获、分析与建模活动提供良好的基础。还需要做进一步的工作，将主题域的内容以业务事件列表和报表列表表示出来。

注：对于联机事务处理系统而言，业务事件（流程）是核心线索，对于管理信息系统而言*，*Report(包括各种查询、分析、统计）是核心线索。而通常的业务系统都包含了这两种成分，因此应该在需求定义阶段将这两个线索明确地标识出来。

业务事件是梳理业务系统需求的一个很重要的线索，因为一个企业或组织存在的核心价值在于接受外部用户的请求，通过响应请求让用户满意的同时也创造了相应的价值。

业务事件是业务流程的触发点，标识出业务事件能够帮助我们识别出业务流程；

业务流程是为了响应业务事件而触发的一系列业务活动，它通常是由不同部门、不同岗位协作完成的。

业务活动则从属于一个特定的业务流程，它是一个人的活动，一个业务流程应该是由一个或多个业务活动组成；

业务步骤是完成某个业务活动所需要的具体步骤。

业务事件可分为外部事件（来自系统外部的事件，也就是系统参与者发起的）和内部事件（也就是系统内部触发的）两类，而每种类型的业务事件又可以分成两种。

**Customer发起：**由主题域外的客户发起的，在绘制上下文关系图时建议的主线索，如体检者申请体检。

**Worker发起：**由主题域内的客户发起的，在绘制上下文关系图时也涉及了这种事件，例如维护人员管理体检项。

**时间事件：**由于到达某一时刻所发生的事件，如到信用卡结算日时向客户发送账单，是一种时间事件。

**状态事件：**由于到达某一状态时所发生的事件，如当体检结果出来并出具报告之后，通知体检者领取报告。

上一小节，绘制出了针对体检业务子系统的上下文关系图，在绘制的过程中，寻找的就是业务事件，可以得出该主题域所涉及的业务事件：

①体检者申请体检

②体检者中途改单

③财务部门体检团队缴费情况

④客服中心查询体检情况

⑤维护人员管理体检项

⑥系统通知体检者取报告

业务事件标识出来之后，可在此基础上分析潜在的报表类型。在需求定义阶段主要是标识出报表的类型，说明为什么要这些报表，它们的使用场景是什么样的。根据前面的分类，可以大致分析出一些潜在的报表类型。

• 生成需求大纲

通过这三步把需求的范围界定之后，就可以把它填到POS或Vision文档中的“项目范围”小节中，先从主题域划分，然后每个主题域一个小节，分别阐述业务事件和列表需求。

也可以利用这些范围信息把软件需求规格说明书（SRS)的框架搭建出来，以便在后续的环节中不断演化、填充。

需求定义阶段的产物：

链接：https://pan.baidu.com/s/1iSCj7dje10DBQTaPuNvpHw

提取码：tavx

6.软件需求最佳实践笔记 | 需求捕获

一、需求捕获的策略

• 需求捕获应该是主动的

需求捕获或称为需求获取都是主动动词，强调需求分析人员在整个过程中应充分发挥主动性。

两种需求捕获模式的对比

• 需求捕获应该是聚焦的

需求捕获案例

这个案例中，小张提问的方法就将导致整个捕获过程是发散的，而老李的问题就能够使整个问题很聚焦，这样产生镀金需求、非重要需求的可能性就会大大下降。

• 破解需求的冰山模型

用户的需求是一个冰山，有很大一部分信息是埋藏在海平面之下的，这就会对需求捕获工作带来很大的困扰。这个冰山可以分为三层。

解需求的冰山模型

**意识到的需求：**通常是一些困扰用户的问题、用户自己能够设想得到的功能。如果只知道捕获这一层信息，就不算是合格的需求分析人员，因为这将导致大量的需求将以变更的形式出现。

**无意识的需求：**它是用户的实际工作场景，如果能够对这些场景做到“感同身受”的话，可以大大减少变更的数量，而且能够开发出更加合理的解决方案，具体的方法就是加强对业务知识的捕获。这是每一个合格的需求分析人员都应该做到的。

**未梦想的需求：**用户对技术解决方案不是最擅长的，因此他们无法构想出对其工作产生革新性变化的解决方案。这就需要通过需求分析人员在对问题域充分理解的基础上，选择合适的技术方案，才可能创造出用户未梦想到的功能。能够做到这一点就可称为优秀的需求分析人员。

这就是意识到的需求，用户能够清晰地表示出来。但小宁却没有进一步分析。

这是无意识需求搞的鬼！房产经纪人提出这个需求的原因是客户对房源的需求是多样化的，他可能需要某路段的两房或另一路段的三房，无法用一组查询条件将它们总结在一起。以前在本子上查找时，人的脑子是可以记录多组条件的。

去理解业务场景是合格需求分析人员的良好习惯。

这就是一个未梦想的需求，用户代表是不可能想到这样的解决方案的。只有理解了用户的实际场景，并有其他领域的经验、熟悉技术能力时，才会想到这些更优化的解决方案。

善于利用技术为用户创造全新体验是优秀需求人员的特质。

• 破解阻碍需求捕获的心理现象

需求捕获过程是与人打交道的过程，因此遇到一些阻碍需求捕获活动的心理现象在所难免。如果需求分析人员能够多思考这些心理现象后面的心理动机，就一定能够找到有效的手段来缓解它们所带来的影响。

阻碍需求捕获的五种常见心理现象

**言过其实心理：**通过比较用户代表的表述来识别言过其实，利用差异展现、瓶颈分析法来缓解影响。

**越俎代庖心理：**针对越俎代庖心理现象最有效的方法是识别正确的被访谈者。

**非正事心理：**离开办公室、对访谈进行计划是避免非正事现象的主要手段。

**抗拒心理：**化敌为友是缓解抗拒心态的主要方向，倾听对方抱怨是化敌为友的有效手段之一。

**推卸责任心理：**让被访谈者介绍工作场景，存在什么样的障碍，有什么困难等。

• 不要忽视对变更可能的捕获

需求变更一般发生在下面三个方面：

注：弹性的架构并不意味着修改是无须成本的。把影响架构设计的变更因素写在软件需求规格说明书中，才能够帮助架构师正确地做出决定。

• 需求协商

在需求捕获的过程中经常会遇到需要协商的地方，能否灵活应对这些场景，取决于需求捕获人员的沟通技能。下面从三个方面介绍需求协商的策略。

①揭开解决方案后面的问题

随着人们学识、经历的不断增长，其讲话时就会更偏向于说解决方案，而不会直接说问题。这种心态对于需求捕获会造成障碍。同样是口渴了，我们来看看不同人是怎么说的。

3岁小孩的生活经验、学识都相对比较少，所以经常会直接反映问题；而一位成人则经常会给出一个解决方案，可能会需要多次交流才可能解决问题；而许多领导则经常会给出更加迂回的解决方案，如果听者不是很有经验，或许根本无法满足他。

在需求捕获过程中，“不直接说问题，而是说解决方案”的现象并不少见，那么面对这样的问题,我们应该如何解决呢？其实方法很简单，就是多问为什么。

②共赢性谈判

需求协商也是一种谈判，显然不是你死我活的谈判，而是一种共赢性谈判。而共赢性谈判的技巧在于抛开立场，追求满足大家的利益诉求。而要完成这样的转变，在谈判过程中的核心技巧就在于问出对方的立场。

共赢性谈判的技巧在于抛开立场，追求满足大家的利益诉求。而要完成这样的转变，在谈判过程中的核心技巧就在于问出对方的立场。

• 转换技巧

在需求捕获阶段，特别是基于自有产品作定制开发的团队，应该尽可能将用户的需求转换成已实现的产品解决方案。但除了将未知问题转换成已知解问题之外，转换还有一些其他应用思路。

①相对重要到相对次要

在这个案例中，自动生成实时值班日志功能相对于小李而言是重要的，但相对于告警短信自动发送功能则是次要的。通过这样的转换，成功地判断了需求的优先级。

②关注点转换

事物都具有多面性，都各有优劣；而关注点转换的核心思想就是利用其多面性，引导对方向有利于自己的关注点进行思考，从而为自己赢得机会。

在这个案例中，用户最初的关注点在于速度、性能；而这位客服人员将用户的注意力带到–个更重要的角度，那就是安全性。通过这种关注点的转换，有效地赢得了改进的时间。

③隐喻

隐喻就是打比方，是用对方熟悉领域的事物来解释深奥问题的手段，它也是转换技巧中最精彩的一个。需求捕获人员通常是介于问题域和解决方案域之间，在与人沟通时，隐喻能够起到很好的润滑作用。

二、需求捕获的主要方法

可灵活采用以下六种方法的一种或多种。

• 用户访谈

①优缺点与使用时机

用户访谈的优点是直接有效、形式灵活、交流深入的宽带通信形式（有文字、有声音、有图像）。但它也有一些很明显的缺点：如占用时间长、信息存在片面性等。用户访谈是需求捕获过程中的主体技术，因此只要有可能，就应该尽可能多地进行用户访谈。

②用户访谈的类型

在需求捕获阶段最常见的被访谈者包括高层管理人员、中层管理人员、操作层、技术团队4类 。通常对高层管理人员的访谈结果是访谈中层管理人员时的指导，同样对中层管理人员的访谈结果是访谈操作层时的指导；而对技术团队的访谈则是突发的，是需求捕获人员无法确定技术是否能够实现、实现成本是否过高时进行的。

③用户访谈的时间安排

一般来说，一次用户访谈的时间应该控制在1小时以内，如果时间不够用可以考虑中场休息或者安排下一次访谈。

④用户访谈的记录工作

用户访谈的过程中会产生大量的信息，免不了记录的工作，但这个工作看似简单其实经常会困扰需求捕获人员，因为每种方法都有各自的长处，但也有自己的短处，如下表。建议采用“自己做笔记+录音”的组合方式。

⑤用户访谈中的沟通技巧：

技巧一：制作访谈问卷并事先发给被访谈者

尽量将访谈问题事先发给被访谈者，让他打一场有准备之战。在向被访谈者发送访谈计划时，应该记住这样一个时间原则：2天前、1周内。

技巧二：把握语言节奏

首先在整个需求访谈过程中，访谈者要注意谈话中心是“业务”，而非“技术”！而且要明白自己是一位倾听者，交流的模式是“问问题，听取回答，然后反馈理解”。

在访谈的过程中，应该尽量使用简单的语言清楚地表达问题。具体来说，就是要注意以下两个方面问题：沟通时应该尽可能使用短句，以“主谓宾”结构的句式为主，要点在于简明地讲清问题。**不要问过长的问题，**需求访谈应该采用的模式可以比作“短兵相接”，也就是很少有长问题，要把长问题拆分成多个递进性的子问题；更应该避免将多个问题一次性提出。

技巧三：有效结合不同的问题类型

在访谈的过程中，可以使用的问题类型有3种：封闭式问题（判断题）、半封闭式问题（选择题）和开放式问题（简答题）。作为需求捕获人员应该熟知各种问题的特点，以便做出适当的选择。

技巧四：善于安排问题顺序

在访谈时，各个问题的顺序应该根据业务逻辑组织。而对于每一组问题而言，还应该注意借鉴归纳和演绎方式。具体来说，可以使用金字塔结构、漏斗结构和菱形结构来组织问题。

技巧五：注意沟通的细节

技巧六：善于观察异常现象

⑥用户访谈计划

计划时间、人员

用户访谈安排计划示例模板

计划内容

• 用户调查

用户调查技术实际上是和用户访谈相关的一组技术，它们在市场调查领域有着广泛的应用。优点是调查面比较广，能够获得更多人的反馈，能够克服用户访谈的片面性。

可以采用两种不同的组合方式：

**先调查，后访谈：**也就是先设计一个通用的问卷，从问卷的结果中梳理出一些关键点，然后选取一些用户代表，进行更有针对性的访谈。对于市场调查比较合适，由于很难深入接触到潜在的用户代表。

**先访谈，后调查：**也就是先筛选出一些典型的用户代表，然后对访谈的结果进行整理，在这些结果的基础上设计相关的调查问卷，通过调查来验证用户访谈的结果是否具有普遍性。

• 文档考古

文档考古也称为文档研究，文档考古填补了用户访谈、用户调查技术在数据需求上的不足，它就是研究、分析、细化数据需求的主要手段。因为数据需求通常比较琐碎、趋于细节信息，因此不要期望用户能够将其记在脑子里，这些信息往往寄生于各种类型的文档中。

主要要点：

**•注意文档的历史性：**收集文档时，应该尽可能让用户提供带有真实数据的样本；分析文档资料时应该思考新流程对其的影响。

**•化被动收集为主动索取：**根据流程分析的结果（各个业务活动所要处理、传递的表单，产生和加工的数据）主动收集相关文档。

• 情节板串联

经常被称为原型法。不过原型法是一个完整的开发方法论，而情节串联板则更强调的是借助原型来加速需求捕获过程，是一种对生动直观的需求捕获技术。

优缺点与使用时机：

**优缺点：**优点就是用户友好和交互性，对用户界面提供了早期评审；缺点是花费的时间很多，需求捕获的速度大大降低。

**使用时机：**许多用户对信息系统是没有直观认识的，很容易产生盲区，需求捕获人员通过情节串联板技术来帮助用户消除盲区，达成共识；需求捕获虽然很大的一部分精力在于理解业务、分析业务、了解潜在问题，但不可避免地涉及一些解决方案的探讨，只有让用户了解将如何解决时才会更容易达成共识。

情节板串联示意图

情节串联板的使用要点：确保以业务场景作为展示的主线索。

合理的做法是是以业务工作场景作为线索，也就是“情节”。说明用户下订单时怎么做、用户改订单时怎么做、用户要查询订单执行情况时怎么做？先把这些工作的业务步骤列出来，作为整个情节串联板的情节，然后让用户带着这样的线索来审视系统的操作过程，看看是否合理、是否满足需求。

注：人往往看不到自己的错误，指责别人却很厉害，可这样的错误我们也一直在犯。想想你写的用户手册，不也是这样的吗？截一张图，圈住填写客户名的文本框，说这里填用户名，圈住填写订单信息的文本框，说这里填订单信息，然后再圈住“提交”按钮，说接着点击它！这种“看图说话”式的用户手册有什么用呢？看了不会做还是不会做呀，关键是在实际的工作中要怎么做。

**情节串联板的使用要点：理解“串联”的本质：**串联体现了原型的动态性、交互性，用户不仅仅关心用户界面的样子，更关心用户界面的流转过程、交互过程。因为交互过程是对工作任务的最好回答。很多需求捕获人员在使用这项技术时，却把目光只放在单个页面的内容、格式上，而忽略了交互的本质。

• 现场观摩

现场观摩是另外一种很生动的需求捕获的技术，通俗说，就是到现场去看一看，以便对业务场景建立更加感性的认识。

优缺点与使用时机：

**优缺点：**百闻不如一见，能够对需求与业务流程建立直观的认识;而缺点则是消耗时间长，而且由于“被观摩”的微妙心理变化，会使得“观摩”失真。

**使用时机：**在需要对复杂流程建立更深入的了解时、在对关键任务理解不清晰时、在很多东西用文字表述不清时，都是使用现场观摩技术的最佳时机。

• 联合开发

用户代表、需求分析人员、开发人员代表齐聚一堂，以头脑风暴的形式进行需求探讨，它是最理想的需求捕获方式。

优缺点与使用时机：

**优缺点：**需求过程是完成用户需要到解决方案的转换过程，各方代表一起探讨是很有效的方式。优点在于客户、开发人员直接的头脑风暴，是击破需求盲点的关键手段；缺点是成本高，如果缺乏控制会变成一次闲扯大会。

**使用时机：**双方对需求都还有盲区的时候是使用该技术的最佳时机。

项目启动初期：大家对系统的目标和范围可能比较模糊，因此需要大家一起来讨论，使目标和范围更加明确，为需求工作、开发工作指出方向。

关键主题域、功能块的专项探讨：系统中一些很关键的部分，它是整个系统的价值核心，这时组织此类的活动也可以有效地提高需求的质量。

三、需求捕获的记录工具

• 工具的选择与定义

**①任务卡片。**十分适合对业务活动级的信息收集与整理。

任务卡片示例

任务卡片的内容与要点

增强版任务卡片示例

这个版本和前面一个相比，增加了两类对于系统开发而言很重要的信息，它们分别是：

**•问题点：**也就是在子任务和任务变体栏中，增加了一些问题点描述，这通常是引出解决方案的要点。

**•方案示例：**也就是针对这些问题点，系统需要实现什么样的功能，以便验证这些解决方案是否能够解决用户提出的问题点。

有时候很难总结出子任务、任务变体，那么就可以整理为如下所示的场景描述。

机场Checkin场景描述示例

需求分析人员可以根据这些信息来进行抽象（其中加粗的字就是主要的线索）整理出子任务。这种场景描述可以在编写测试用例、用户培训材料时再次用到。

• 其他工具

用户故事、Volere白卡也是常见的需求记录工具。