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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 沟通失真

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

一、信息系统的需求视图

• 信息系统的本质

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

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

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

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

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

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

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

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

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

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

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

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

手机系统分析示例

手机接打电话行为分析：

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

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

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

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

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

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

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

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

三、软件产品的需求视图

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

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

商业模式分析

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

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

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

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

• 优秀需求的标准

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

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

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

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

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

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

• 需求开发工作要点

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

需求开发的三次循环

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

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

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

• 需求管理工作要点

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

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

②引入基线管理；

③引入变更管理；

④引入需求跟踪。

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

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

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

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

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

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

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

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

二、问题分析的五步法

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

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

• 分析问题背后的问题

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

鱼骨图示例

• 定义解决方案的界限

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

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

• 需求定义的产物

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

Vision的主要内容：

项目目标编写示例

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

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

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

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

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

• 划分主题域（子系统）

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

某连锁酒店构件图示例

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 生成需求大纲

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

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

需求定义阶段的产物：

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

提取码：tavx

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

一、需求捕获的策略

• 需求捕获应该是主动的

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

需求捕获案例

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

• 破解需求的冰山模型

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

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

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

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

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

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