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

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

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

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

• 划分主题域（子系统）

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

传统子系统划分示例

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

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

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

②为什么使用构件图

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

某连锁酒店构件图示例

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

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

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Go语言工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Go语言全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Golang知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Go）

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

关系。

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

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Go语言工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Go语言全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
[外链图片转存中…(img-yDkRW63M-1713084800729)]
[外链图片转存中…(img-fE5EGonU-1713084800730)]
[外链图片转存中…(img-Ai3CWy9U-1713084800730)]
[外链图片转存中…(img-jw1Kz3CI-1713084800731)]
[外链图片转存中…(img-qsvg0K5K-1713084800731)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Golang知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Go）
[外链图片转存中…(img-bLo9C8vo-1713084800732)]

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！