南京大学软件学院-2025Fall-软件需求工程（研究生）期末复习参考

发表于 2026/01/04

作者 Jiaqi Chen

28 分钟阅读

2025FALL真题回顾

需求类型：根据材料各写出一条业务需求、用户需求、约束；约束的三种来源
目标模型：根据材料画出目标模型
需求获取的三种方法：根据材料，从需求获取的三种方法的角度给建议
设计面谈问题：10-15个问题
PI/PA模型：画出模型并解释风险化解策略
领域模型（类图）：根据材料画出领域模型
状态图：根据材料画出状态图
需求验证6个方法与需求管理的3个活动，以及基于材料分析相关手段的应用

一、需求基本概念

考点：需求类型

1.什么是需求？

需求是用户对问题域当中的实体状态或事件的期望描述。

需求规格说明（requirement specification，RS）是解系统为满足用户需求而提供的解决方案，规定了解系统的行为特征。

2.问题域与解系统

问题域：问题产生时，需要改变现实世界中某些实体的状态，这些实体和状态构成了问题解决的基本范围，成为问题的问题域。

解系统：软件系统通过影响问题域，能够帮助人们解决问题，称为解系统。

考点一：需求类型**

考试形式：直接考概念；给定材料，写出各种需求类型实例；

3.需求的层次

3.1业务需求（Business Requirement，BR）

概念：系统建立的战略出发点，表现为高层次的目标，描述了组织为什么要开发系统。

怎么开发业务需求：为了满足用户的业务需求，需求工程师需要描述系统高层次的解决方案，定义系统应该具备的特性（System Feature，SF）

3.2用户需求（User Requirement，UR）

概念：执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么

表达方式： 用户可以使用系统完成XX任务

3.3系统级需求（System Requirement，SR）

概念：用户对系统行为的期望，一系列的系统行为联系在一起可以帮助用户完成任务，满足业务需求。

用处：系统需求可以直接映射为系统行为（对应需求规格说明），定义了系统中需要实现的功能，描述了开发人员需要实现什么

4.需求的常见类型

需求的分类

按性质分为：功能性需求和非功能性需求
按层次分为：业务需求、用户需求、系统级需求
更广泛的分类：项目需求、过程需求、系统需求（软件需求、硬件需求、其他需求）

功能需求：软件产生价值的基础，最需要按照BR、UR、SR三个层次进行开发
性能需求：响应速度、容量、吞吐量、负载、实时性
质量属性：
- 系统为了满足规定的及隐含的所有要求而需要具备的要素称为质量，质量属性是用来度量质量要素而选用的特征。
- 可靠性、可用性、安全性、可维护性、易用性
对外接口：用户界面、通信协议
约束：系统开发及运行环境、商业规则、法律法规
其他需求：安装需求、数据需求

二、需求获取

需求获取上半段：确定项目前景与范围-目标模型；涉众分析（涉众识别之ADM模型、涉众评估之Power-Interest、Power-Attitude模型、涉众共赢之Stakeholder-lssue模型）
需求获取下半段：面谈、原型、观察三大获取手段的联系与区别，面谈问题的设计

概念：需求获取是从人、资料或者环境当中获取需求的过程。

（一）确定项目前景与范围

1.为什么要确定项目前景和范围？

确定项目的前景与范围，就是确定项目的问题、目标、特性。软件项目往往是解决现实世界中的复杂问题，需要确定好哪些内容属于项目范围，以及项目要达到什么目标和特性，才能进项后续开发。

2.目标

目标的概念：目标是系统被开发的目的。

目标的类型：

软目标（云朵）：
硬目标（矩形）：具体的目标，可以利用技术手段确认是否满足

目标的层次：高层次目标（战略的、全局的、业务的）、低层次目标（技术的、局部的、产品的）

3.目标模型

目标的关系：精化关系（AND精化、OR精化）、阻碍关系、支持与冲突关系。

3.1精化关系

一个高层次目标G可以精化为低层次目标，精化结束的标志是子目标仅含单一事务：

AND精化（实心圆圈）：如果一系列子目标{G1,G2,…,Gn}的完成有助于目标G的完成，那么G与{G1,G2,…,Gn}之间就是AND 精化关系。此时任意两子目标Gi与Gj之间是互补的，他们作用的对象/场景是相同的。
OR精化（空心圆圈）如果任一子目标Gi都是G的替代方案，那么G与{G1,G2,…,Gn}之间就是OR 精化关系。此时，任意两子目标Gi与Gj之间是互相替代的。

3.2目标阻碍

如果子目标O的达成会使得高层目标G失败，那么O与G的关系就是阻碍关系。阻碍关系在箭头上画一道横线。

3.3目标支持与冲突

支持：Support，可以处理为OR精化

冲突：Conflict，在箭头上画×

（二）涉众分析

1.什么是涉众、涉众分析

涉众：影响软件系统的实现，或者会被实现后的软件系统所影响的，关键个人和团体。

涉众分析：涉众分析围绕一个组织的各个部门内的员工所负责的业务展开。

2.涉众分析过程

2.1涉众识别

简单方法：先膨胀后收缩，尽可能列出涉众后尝试合并，易用但可能有遗漏

经典方法：涉众网络

用容易发现的涉众（客户、管理者、投资人）出发
与初始涉众一起“膨胀 - 收缩” ，集体确定关键涉众列表，再请列表中的新代表加入讨论，直到列表稳定

经验方法：检查列表

2.1.1✨利用主体依赖模型ADM分析涉众互动，识别关键涉众类别

会议ADM示例分析：

A. 目标依赖 (Goal Dependency) —— 红色椭圆

会议日程安排： “会议发起者”依赖“时间安排者”完成日程安排。
特点： 发起者只关心“日程被安排好了”这个结果，至于具体怎么排、用什么工具，由时间安排者自主决定。

B. 软目标依赖 (Softgoal Dependency) —— 黄色云朵

这是模型中最具“社会性”的部分，涉及难以量化的质量需求：

对会议有贡献： “会议发起者”依赖“参与者”提供有价值的见解。
有用的会议： “参与者”反过来依赖“发起者”确保会议不是在浪费时间。
合适的时间： “参与者”依赖“时间安排者”找一个大家都能接受的时间点。

C. 任务依赖 (Task Dependency) —— 绿色六边形

参与会议： “时间安排者”依赖“参与者”准时出席。
特点： 这是一个具体的行为约束，参与者必须执行“出席”这个动作，任务才算完成。

D. 资源依赖 (Resource Dependency) —— 蓝色矩形

日程信息： “时间安排者”依赖“参与者”提供他们的空闲时间或日程数据。
特点： 这是一个物理或信息实体，没有这个资源，时间安排者的工作就无法开展。

2.2涉众评估

1.优先级评估

2.风险评估（Power-Interest、Power-Attitude模型）

2.3涉众共赢Stakeholder/Issue关系图

（三）需求获取的三种手段

1.面谈

最具丰富内容的交流方式

应用最广泛的需求获取方法

可以获得：事实和问题、观点、感受、目标

场景分析：有没有好好准备、主持、整理面谈？

1.1准备面谈

1.1.1如何准备？

阅读背景资料
确定面谈主题和目标
选择被会见者
通知被会见者（电话/邮件等正式途径）
确定问题和类型

1.1.2面谈准备的关键：问题类型

开放式问题

回答形式不受限制，可多可少、可主观可客观
适合希望得到丰富信息时采用
优点：广度+深度、回答者更自在、更主观、更感兴趣、更自发性
缺点：不相干信息、面谈失控、浪费时间、看上去你没有提前准备好

封闭式问题

答案有基本格式
优点：节省时间、切中要点、能更好控制面谈、得到更确切的数据
缺点：失去细节、对方感觉被控制不自在、氛围不融洽、丧失主观性

1.1.3面谈问题设计

前期：

1.目前业务主要碰到了哪些问题？

2.希望新系统能帮助达成哪些目标？

3.这项工作是怎样进行的？

4.哪些人会参与到这个过程中？

后期:

其他类型的问题：

1.2面谈的类型

1.3面谈的优缺点

优点：简单、经济成本低；能获得广泛的信息甚至意料之外的信息；通过面谈可以同涉众建立友好的关系；提高涉众的参与热情

缺点：时间成本高；地理分散时难以实现面谈（线上会议）；依赖需求工程师的交流能力和被访谈者的表达能力；不确定因素较多；

1.4面谈的方法

群体面谈

调查问卷

头脑风暴

2.原型

2.1什么是原型

原型是一个系统，它内化了一个更迟系统的本质特征。原型系统通常被构造为不完整的系统，以在将来进行改进、补充或者替代。

如果在最终的物件产生之前，一个中间物件被用来在一定广度和深度范围内表现这个最终物件，那么这个中间物件就被认为是最终物件在该广度和深度上的原型。

包括书面描绘、场景叙述、情节串联图板、幻灯演示、动画模拟、屏幕快照和程序代码等在内的各种被用来探索和论证软件系统功能的物件都是软件的原型。

2.2为什么要用原型？

不确定性：不知道要什么
不确定性广泛存在
软件工程中存在着大量的不确定性，原型、迭代和（方法）验证是人们解决不确定性的主要手段

2.3使用原型获取需求

2.4原型法的使用要点

2.4.1抛弃式原型和演化式原型

获取原型的方法：

因为基于不确定的需求基础，所以抛弃式原型难免反复修改，导致代码质量较低，应该坚决抛弃。

抛弃式原型的贡献不在于它的代码，而是它所包含的内容，它说明了正确的需求和正确的技术方案，如果认识不到这一点，他们就只能得到低质量的代码，而丢失真正宝贵的内容。

2.4.2控制原型成本

控制开发成本，用便宜的介质降低成本

（1）控制抛弃式原型的成本

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

（2）控制水平原型的开发成本

水平原型仅仅实现选定功能所有层次中的某些特定层次，要把注意力集中在概括性需求和工作流问题上。

（3）控制垂直原型的开发成本

垂直原型会触及到选定功能实现的所有层次，要保证真实实现它的各种功能。

2.4.3善用故事板原型

将原来分散的功能与步骤组织成故事，让普通人能够更好地体验与评估：为需要探索和澄清的用例/场景建立故事板原型，或者依据故事板原型的评估结果建立清晰、明确的用例/场景描述

2.4.4原型方法的风险

原型开发工作投入太多的工作，使得开发团队消耗了过多的时间和过大的成本
涉众看到了一个正在运行的原型，得出产品几乎已经完成的结论，从而提出快速交付产品的不当要求：不要将原型的功能开发的太好，以免用户提出“交付”的要求
用户可能会被原型所表现出来的非功能特性遮蔽了眼睛，从而忽略了他们更应该重视的功能特性
在澄清需求不确定性的同时也可能会掩盖一些用户的假设，这些假设将会无从发现

3.观察

3.1观察什么时候用？

应用于用户无法完成主动的信息告知的情况下：采样观察、民族志、话语分析、协议分析、任务分析
某些事件只有和它们发生时的具体环境联系起来，才能得到理解：突现、局部、暂时、涉身、开放、模糊

3.2采样观察和民族志

3.2.1采样观察

3.2.2民族志

对于一些复杂的协同工作而言，工作的协同安排具有社会性，有突现的情景性，民族志可以帮助开发者了解这些工作的社会性因素，解决突现的情景性因素。

优点：
- 能够得到信息的深度理解
- 能够让真实世界的社会性因素可见化
- 打破人们已有的一些错误假设和错误观念
缺点：
- 需要耗费很多的时间
- 调研结果很难传递到开发过程

4.面谈、原型和观察的区别与联系

维度	面谈	观察	原型
获取内容	利益相关者的主观诉求、愿景和目标。	用户的实际操作行为、真实工作流和环境约束。	对需求的具体实现方案的反馈和验证。
信息来源	“听”用户怎么说。	“看”用户怎么做。	“试”用户怎么用。
适用阶段	需求获取初期，用于建立大框架。	业务流程复杂或用户无法准确描述行为时。	需求模糊、UI/UX 要求高或逻辑复杂的阶段。
主要优点	直接、高效，能挖掘深层动机。	揭示“默会知识”（用户做了但没意识到的操作）。	减少歧义，通过直观交互快速达成共识。
主要局限	用户可能表达不清、遗忘或由于利益隐瞒信息。	耗时较长，且观察者的存在可能改变用户行为（霍桑效应）。	开发成本相对较高，可能导致用户关注细枝末节。

这三种手段并非孤立，而是一个互补的链条，共同构建完整的需求蓝图：

面谈与观察的互补： 面谈获取的是“应该是什么样的”（理想模型），而观察获取的是“现在是什么样的”（现实模型）。通过对比两者的差异，可以发现由于系统落后或流程不合理导致的潜在需求。
面谈为原型提供输入： 通过面谈获取初步目标后，需求人员将其转化为原型。如果没有面谈作为基础，盲目做出的原型往往偏离业务重心。
原型是面谈的“共同语言”： 当面谈进入细节探讨出现分歧时，原型可以作为实物参考，避免双方在“文字描述”上的理解偏差。
观察验证原型： 在原型迭代过程中，通过观察用户使用原型的过程（类似可用性测试），可以更真实地反馈系统是否符合用户习惯。