2024年最新软件需求最佳实践笔记（一）_软件需求最佳实践 需求开发(2)，2024年互联网大厂Golang笔经

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

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

如果你需要这些资料，可以戳这里获取

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

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

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

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

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

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

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

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

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

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

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

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

• 需求管理工作要点

需求管理工作包括基线管理、变更管理和需求跟踪三个活动。而要想真正使需求管理活动获得实效，可以将整个管理改进分成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场景描述示例

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加戳这里获取

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

任务卡片示例

任务卡片的内容与要点

增强版任务卡片示例

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

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

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

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

机场Checkin场景描述示例

[外链图片转存中…(img-r4zvsy37-1715792429853)]
[外链图片转存中…(img-8Hllg41l-1715792429854)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加戳这里获取

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