场景/用例模型与需求获取

发表于 2025-12-25 Waline：阅读次数：本文字数： 5k 阅读时长 ≈ 18 分钟

用户需求获取分为两个阶段：前半段确定项目前景与范围，后半段以场景/用例模型为核心展开具体获取。三大要素贯穿始终：确定范围、模型与流程、获取方法。

获取活动的关键原则

保持项目范围是首要任务，需参照系统特性、围绕系统边界设计获取计划，避免需求遗漏。获取过程应采用多轮次策略，根据内容特点合理安排方法，并及时组织已获取需求以指导后续工作。

多轮次获取的典型节奏：

阶段	轮次	核心目标
前景与范围	准备	背景资料获取与分析
-	第一轮	问题分析（深入）
-	第二轮	高层解决方案制定（确认）
用户需求获取	准备	明确主题与内容，准备材料
-	第一轮	明确任务与主要问题（深入）
-	第二轮	明确任务细节，澄清困难内容
-	第三轮	明确解决方案（确认）

获取方法的选择

不同情境适用不同方法：

面谈：常规方法，与用户创造性交流，充分发掘潜在想法
集体面谈：快速方法，适合需要多方参与的场景
调查问卷：用户地理分散时的有效手段
头脑风暴：用于「发明」需求，激发创新
原型：消除用户或需求工程师想法中的不确定性
观察：需求工程师亲自体验，发掘情景性需求

场景与用例

场景描述人与外部世界随时间变化的交互与结果，具有重点描述真实世界的特征——利用情景、行为者交互、事件演化等方式叙述性地描述系统使用过程。

用例是相关场景集合的叙述性文本描述。UML 将其定义为「在系统与外部对象的交互中所执行的行为序列的描述，包括各种不同的序列和错误的序列，它们能够联合提供一种有价值的服务」。

以用例/场景为单位组织用户需求的优势在于：易于接受、易于使用，因此在实践中广受欢迎，形成了「用例驱动」的开发模式。

用例描述模板

要素	说明
ID	用例标识，通常采用 X.Y.Z 层次结构
名称	精确描述用例内容，体现所描述的任务，通常为「动词 + 名词」
参与者	主参与者、辅助参与者及各自目标
描述	简要说明用例产生原因、大概过程和输出结果
优先级	需求的优先级
触发条件	启动用例的事件（外部/内部/正常流程首步）
前置条件	用例正常启动和工作的系统状态条件
后置条件	用例执行完成后的系统状态条件
正常流程	常见和符合预期条件下的行为交互序列
分支流程	非常见的其他合理场景
异常流程	非预期错误条件下的响应交互序列
相关用例	存在关系的其他用例
业务规则	可能影响用例执行的业务规则
特殊需求	相关的其他需求，尤其是非功能性需求
假设	建立用例时所做的假设
待确定问题	当前描述尚未解决的问题

用例/场景模型的局限性

用例/场景模型存在两个固有局限：

只考虑其他内容与功能需求之间的联系，无法描述其他内容相互之间的联系（如质量需求的相互依赖、界面需求的跳转、对外接口需求与质量需求的联系）
只考虑了存在联系的事实，无法分析联系的合理性（如有无遗漏功能需求、数据需求及业务规则是否充分、质量需求是否可行）

因此，目标模型、面向对象分析模型或结构化模型等其他模型形式仍然是必要的补充。

面谈

面对面会见被认为是最具丰富内容的交流方法，是实践中应用最广泛的需求获取方法之一。

可获得的信息类型包括：事实和问题、被会见者的观点、被会见者的感受、组织和个人的目标。

面谈过程

flowchart LR
    subgraph 面谈过程
        direction LR
        A[准备面谈] --> B[主持面谈] --> C[整理面谈报告]
    end

    D[前景和范围<br>输入] --> A
    C --> E[指导面谈报告<br>输出]

    %% 样式定义
    classDef process fill:#e1f5fe,stroke:#01579b,stroke-width:2px,color:#01579b,font-weight:bold
    classDef input fill:#f3e5f5,stroke:#4a148c,stroke-width:2px,color:#4a148c
    classDef output fill:#e8f5e8,stroke:#1b5e20,stroke-width:2px,color:#1b5e20
    
    class A,B,C process
    class D input
    class E output
    
    %% 连接线样式
    linkStyle default stroke:#666,stroke-width:2px,fill:none

准备阶段：

阅读背景资料
- 注重权威性与第一手资料（图书馆、官网、上市报表）
- 同时展开收集与分析，多做分类、坐标、时间趋势
- 通过互联网获取任意领域的业务流程、相关专家、知识获取途径
确定面谈主题和目标
选择被会见者
通知被会见者：通过电话或邮件等正式途径
确定问题和类型

问题类型

问题类型的选择是面谈准备的关键：

开放式问题（Open-Ended）：被会见者的答复不受限制，可能是两个词，也可能是两段话。适合希望得到丰富信息时使用。

例：「你觉得把所有的经理都置于一个内联网内怎么样？」
例：「请解释你是如何做进度决策的？」

优点	缺点
让被会见者感到自在	可能产生太多不相干细节
收集被会见者使用的词汇，反映其价值标准和态度	面谈可能失控
提供丰富的细节	花费大量时间才能获得有用信息
对后续提问有启迪作用	可能使会见者看上去没有准备
让被会见者更感兴趣	-
容许更多自发性	-

封闭式问题（Closed）：答案有基本形式，被会见者的回答受到限制。

例：「项目存储库每个星期更新多少次？」
例：「下列信息中哪个对你最有用：（1）填好的客户投诉单；（2）访问 web 站点的客户的电子邮件投诉；（3）与客户面对面的交流；（4）退回的货物。」

优点	缺点
节省时间	使被会见者厌烦
切中要点	得不到丰富细节
保持对面谈的控制	可能失去主要思想
快速探讨大范围问题	不能建立友好关系
得到贴切的数据	-

其他重要问题类型：

探究式问题：「为什么？」「你能举个例子吗？」「你能详细描述一下吗？」
诱导性问题：「你和其他经理一样，都同意把财产管理计算机化，是吗？」（应避免）
双筒问题：「每天你通常会做什么决策，你是怎样做的？」（应避免，一次问两个问题）
元问题：「我的问题看起来相关吗？」「你是回答这些问题的最佳人选吗？」「我还应该见什么人？」

程序性提示：

类型	示例
总结和反馈	你能不能总结一下系统的功能？
重复和改述	能不能再说一次系统的哪些特征是重要的？
建立场景和细节描述	有什么是你现在能做，却在新系统中不能做的？
抗辩	你能不能想出什么不使用系统的理由？

问题准备的阶段性策略

前期：

开放式问题为主
决策层与专家为主
遵循「问题 → 目标 → 解决方案」路线
分析基本的涉众特点（角色、任务、个人目标、频率、优先级）

后期：

封闭式问题为主
抓住主题与线索（任务分解、流程图、界面示意）
问题针对性强（任务分解关系、流程正确性与异常、界面中的行为与数据项）
事先准备面谈记录材料

面谈问题准备示例

面谈对象：投资人、管理者

目前的业务主要碰到了哪些问题？
希望新系统能够帮助达成哪些目标？
销售工作是怎样进行的？
哪些人会参与销售过程？
哪些人的哪些工作是最为瓶颈的？

面谈对象：销售人员

销售人员的主要工作是什么？
销售处理的主要过程是怎样的？
销售处理工作目前的困难有哪些？
销售处理的频率怎么样？
平均多长时间完成一次销售处理？

主持阶段

开始：

开场仪式（握手）
简要重申面谈目标
准备好记录设备
用轻松的开放式问题作为开始

主体：

保持有礼貌的倾听，遵循交流模式
控制面谈过程，必要时主动打破交流模式
保持面谈主题，以面谈问题为主线索
使用探究式问题深入挖掘
观察被会见者（全部感觉中 7% 通过语言交流，38% 通过语调，55% 通过面部表情和肢体语言）
使用道具支持

结束：

面谈应在 45 分钟到 1 小时内结束
总结谈话要点，请被会见者快速检查记录
感谢被会见者，给时间让他们询问关心的问题
握手话别

处理面谈结果

复查面谈记录：整理出内容要点，进行分类
总结面谈信息：评估面谈中所得到的信息
完成面谈报告：应尽快完成

面谈的核心平衡

面谈需要在「共情」与「目标」之间取得平衡：

- **共情**：取得信任、激发主动性、获得更全面的问题域背景和业务意向
- **目标**：充分正确地获取用户需求，在项目前景和范围指导下充分获取用户需求与问题域知识

面谈的类型

类型	特点
结构化面谈	严格按照事先的问题和结构控制面谈
半结构化面谈	事先准备问题和结构，但过程中可灵活调整
非结构化面谈	没有事先预定的议程安排，考验领域理解和面谈技巧

面谈的优缺点

优点：

开展条件简单，经济成本较低
能获得广泛内容（事实、问题、观点、态度、信仰）
可与涉众建立友好关系
提高涉众的项目参与热情

缺点：

比较耗时，时间成本较高
被会见者地理分散时难以实现
参与者的记忆和交流能力对结果影响较大
概念结构不同、模糊化表述、默认知识、潜在知识和态度偏见等问题不可避免
会见者不了解被会见者认知结构时效果不佳

调查问卷

调查问卷以文档为主要交流媒介，适用于以下情况：

系统涉众在地理上是分布的
涉众数量众多，需要了解所有涉众的统计倾向
需要进行探索性研究，希望在确定具体方向之前了解总体状况
为后续面谈标识问题和主题，建立工作基础框架

调查问卷设计要点

问题导向性：「是否赞同或反对」→「是否支持或了解」
答案导向性：「非常反对/反对/中立/同意/非常同意」→「非常同意/同意/部分同意/不太确定/不了解」
从个人相关的「开放选择」到业务相关的「封闭问题」
考虑引入「防呆型」问题，对表格进行过滤

原型

原型是一个系统，它内化了一个更迟系统的本质特征。如果在最终物件产生之前，一个中间物件被用来在一定广度和深度范围内表现这个最终物件，那么这个中间物件就是最终物件在该广度和深度上的原型。

原型使产品足够真实，让涉众能够提出可能被遗漏的需求。

为什么使用原型

原型的核心价值在于解决不确定性。软件工程中存在大量不确定性，原型、迭代和方法验证是主要解决手段。

需求工程中的不确定性场景：

产品用户对相关类别产品没有经验，细节需求存在不确定性
用户在完成工作方式上存在障碍，整体方案可行性存在不确定性
用户在清晰说明需求方面存在困难
需求工程师在理解用户需求上存在困难
需求的可行性值得怀疑
创新性产品，基本需求是潜在的

原型的类型

按开发方式分类：

类型	特点	产物
探索式（exploratory）	以缺陷需求开始，不断调整和修正需求，尽可能调整各种设计选项	演示原型、严格意义的原型
实验式（experimental）	以清晰的用户需求和模糊的实现方法开始，明确需求可行性和技术实现方案	试验原型
演化式（evolutionary）	以清晰的原型化需求和项目积累的原型资产为开始	引示系统原型

抛弃式原型 vs 演化式原型：

抛弃式原型	演化式原型
花费最小代价，争取最快速度	质量从一开始就要达到最终系统要求
可能使用简易开发工具和不成熟构造技术	要易于扩展和频繁改进
可能忽略或简化与原型目的不相关的功能特征	仅应用于处理清晰的需求、规格说明和技术方案
要坚决抛弃	持续演进

按覆盖范围分类：

水平原型（horizontal prototype）：仅实现选定功能所有层次中的某些特定层次，注意力集中在概括性需求和工作流问题上
垂直原型（vertical prototype）：触及选定功能实现的所有层次，保证真实实现各种功能

按保真度分类：

flowchart LR
    direction LR

    subgraph 低保真原型
        direction LR
        A[纸面草图]
        B[幻灯/动画]
    end

    subgraph 高保真原型
        direction LR
        C[快速语言与工具]
        D[程序语言实现]
    end

    A -- 真实感与成本递增 --> B --> C --> D

    style A fill:#e1f5fe,stroke:#01579b,stroke-width:2px,color:#01579b
    style B fill:#e1f5fe,stroke:#01579b,stroke-width:2px,color:#01579b
    style C fill:#f3e5f5,stroke:#4a148c,stroke-width:2px,color:#4a148c
    style D fill:#f3e5f5,stroke:#4a148c,stroke-width:2px,color:#4a148c
    style 低保真原型 fill:#f0f9ff,stroke:#81d4fa,stroke-dasharray:5 5
    style 高保真原型 fill:#faf4ff,stroke:#ce93d8,stroke-dasharray:5 5

真实感和成本从左到右递增。

原型方法过程

flowchart LR
    direction LR

    A[“确定原型需求”]
    B[“原型开发”]
    C[“原型评估”]
    D{“达到目的？”}
    E[“原型修正”]
    F[“原型结束”]

    A --> B --> C --> D
    D -- 否 --> E --> B
    D -- 是 --> F

    style A fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px,color:#1b5e20
    style B fill:#bbdefb,stroke:#1565c0,stroke-width:2px,color:#0d47a1
    style C fill:#fff9c4,stroke:#f9a825,stroke-width:2px,color:#5d4037
    style D fill:#ffccbc,stroke:#bf360c,stroke-width:2px,color:#bf360c
    style E fill:#f8bbd9,stroke:#880e4f,stroke-width:2px,color:#880e4f
    style F fill:#d1c4e9,stroke:#4527a0,stroke-width:2px,color:#311b92

确定原型需求

界定不确定性：

可能发生的需求变更
存在冲突的地方
信息不充分的地方

明确不确定的维度：

维度	含义
外观（Look and Feel）	用户对原型物件的具体感觉体验——看到什么、听到什么、感觉到什么
角色（Role）	原型物件在用户工作中的价值——能帮助用户完成什么工作
实现（Implementation）	原型物件完成功能的细节技术和方法

原型开发

将探索不确定功能需求的原型构建得易于修改
让探索可行性的原型收集充分的数据
控制开发成本

原型评估

需要获取的评估者反馈：

评估者反应
评估者建议
创新思想

评估要点：

可以创建脚本来指导评估者的体验活动
务必让合适的人从恰当的角度来评估原型
观察评估人员使用原型的过程，让评估人员畅所欲言（无偏见）

故事板原型

故事板最早是好莱坞在设计电影场景和卡通故事时使用的，通过勾画一系列相连的图片来展示故事，具有更直观、可视化的故事叙述能力。

故事板原型要素：

角色（Who）
内容（What）
方法（How）

故事板原型类型：

类型	特点	类比
被动（Passive）	静态展示	连环画
主动（Active）	动态展示	漫画
交互（Interactive）	可交互	网页

原型方法的风险

原型开发投入太多工作，消耗过多时间和成本
涉众看到运行的原型后，得出产品几乎完成的结论，提出快速交付的不当要求
用户可能被原型表现的非功能特性遮蔽眼睛，忽略更应重视的功能特性
在澄清需求不确定性的同时可能掩盖一些用户的假设

控制原型成本

不要过于详细地构建抛弃式原型，只要它能够满足原型制作的目标就足够了。要抵制住诱惑，也要顶住用户的压力，不要向抛弃式原型添加更多的功能。

观察

观察方法应用于用户无法完成主动信息告知的情况，主要方法包括：采样观察、民族志、话语分析、协议分析、任务分析。

事件的情景性

某些事件只有和它们发生时的具体环境联系起来，才能得到理解：

特性	含义
突现（Emergent）	集体促成，互动中突现
局部（Local）	特定的上下文环境
暂时（Contingent）	演进过程中的一刻
涉身（Embodied）	参与者的认知和能力受限
开放（Open）	业务不确定并开放，以后完善
模糊（Vague）	基于潜在知识，尚未明确表达

观察方法解决的问题

问题类型	情景性特性	适用方法
理解复杂的协同事件	突现	民族志
获取工作中的异常处理	局部	采样观察、民族志
获取与用户认知不一致的实际知识	暂时	采样观察、民族志
了解用户的认知	涉身	民族志、话语分析
获取默认（tacit）知识	模糊	采样观察、民族志、协议分析

采样观察

类型	时间采样	事件采样
优点	通过随机观察减少偏差；对频繁发生事件取代表性事件观察	允许在行为展开过程中观察；允许对指定重要事件观察
缺点	分段收集数据不能提供全面信息；漏掉不经常发生却很重要的事件	消耗大量时间；漏掉频繁发生事件的代表性样本
适用情景	发现异常流程；验证用户知识和实际工作的一致性；获取默认知识	验证用户知识和实际工作的一致性

民族志

民族志的典型应用是复杂的协同问题。

优点：

能够得到信息的深度理解
能够让真实世界的社会性因素可见化
打破人们已有的一些错误假设和错误观念

缺点：

需要耗费很多时间
调研结果很难传递到开发过程

针对复杂协同问题的民族志关注三个方面：

工作的分布式协同（Distributed Coordination）：特别注意利用物件实现的协同和创建这些物件的文书工作
工作的计划和程序（Plans and Procedures）：关注它们在组织活动中的应用方式，发现实际工作和文档化程序之间的偏离
工作的意识（Awareness of Work）：活动是如何对协同中的其他人可见或可理解的

民族志应用规则：

应该定期记录发现
尽快记录可能在观察过程中发生的面谈
定期复查和更新自己的想法
确定管理海量数据的应对策略

三种获取方法的比较

方法	核心优势	主要局限	适用场景
面谈	信息丰富、建立关系、激发参与	耗时、依赖交流能力、地理限制	常规需求获取、深入理解用户想法
原型	消除不确定性、使需求具象化	成本控制、可能误导用户期望	需求不明确、创新性产品、可行性验证
观察	发现情景性需求、获取默认知识	耗时耗力、结果难以传递	复杂协同、异常处理、用户认知与实际不一致