常见电商术语
PV： Page view，即网站被浏览的总次数
UV： Unique Vister 的缩写，独立访客（Redis的hyperloglog统计）
CR： ConversionRate 的缩写，是指访问某一网站访客中，转化的访客占全
访客的比例（订单转化率=有效订单数/访客数）
SPU： Standard Product Unit （标准化产品单元），SPU 是商品信息聚合的
最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述了一个产品
的特性。
SKU： Stock keeping unit(库存量单位) SKU 即库存进出计量的单位（买家购
买、商家进货、供应商备货、工厂生产都是依据 SKU 进行的），在服装、鞋类
商品中使用最多最普遍。
例如纺织品中一个 SKU 通常表示：规格、颜色、款式。SKU 是物理上不可分
割的最小存货单元。
设计系统的核心流程
遵照软件工程的一般规律,我们先从需求阶段开始。那么，需求分析应该如
何做呢?理想情况下,系统分析师或产品经理应该负责完成需求分析的任务。但是,
现实中绝大多数情况下,你得到的所谓的“需求”,很有可能就是一两句话。需求
分析的工作最终往往是由开发者完成的。
很多项目交付以后,仍需要不断地进行修改和变更,用户不满意,开发者也很
痛苦,造成这个问题的根本原因其实就是缺失了需求分析的步骤。所以,为了后续
工作能够顺利开展,每位开发者都应该掌握一些用于需求分析的方法。那么,开发
者进行需求分析时应该做些什么呢？我们本次课不介绍那些做需求分析的方法
和理论，更多有关需求分析的知识请参考附录《需求分析指引》。
其实任何产品都是给人用的，所以需求分析最重要、最关键的一个点：不要
一上来就设计功能,而是先明确下面这两个问题的答案。
1）这个系统(或者功能)是给哪些人用的?
2）这些人使用这个系统是为了解决什么问题?
这两个问题的答案，我们称之为业务需求。那么，对于我们将要设计的电商
系统，其业务需求又是什么呢?如果大家平时用过电商，熟悉电商的业务,那么回
答这两个问题应该很容易。
第一个问题,电商系统是给哪些人用的?首先是买东西的人，即“用户”;其次
是卖东西的人，即“运营”；还有一个非常重要的角色就是出钱的人，即“管理
者”(请记住，在设计任何一个系统的时候，出钱的人的意见都是重要的，甚至
可以说是最重要的)。综上所述,电商系统是面向用户、运营和管理者开发的。
第二个问题,用户、运营和管理者使用电商系统分别想要解决什么问题?这个
也很容易回答，用户为了买东西，运营为了卖东西,管理者需要通过系统了解自
己所得的收益。
这两个问题的答案,或者说业务需求可以用下图表述。
上面的图被称为用例图(Use Case)，是我们进行需求分析的时候所要画的第
一张图。用例图可用于回答业务需求中的两个关键问题,即这个系统给谁用?他们
用这个系统是为了解决什么问题?
但是实际来说业务需求与我们要设计的系统关系不大。为什么这么说呢?因
为我们将上的用例，放在传统的商业企业(比如,一个小杂货铺、一个线下实体商
场或商店,或者一个做电视购物的公司)中也是适用的,所以,做业务需求的主要目
的是理清楚业务场景是怎样的。
下面就来分析电商系统的业务流程。很显然,电商系统最主要的业务流程,一
定是购物流程。购物流程很简单，所有电商的购物流程几乎都是如此，具体流程
如下图所示。
下面就来分析一下这个流程。流程从用户选购商品开始,用户首先在 App 中
浏览商品,找到心仪的商品之后,把商品添加到购物车,选完商品之后,打开购物车,
提交订单。
下单结算之后,用户就可以支付了。支付成功后,运营人员会为已经支付的订
单发货,为用户邮寄相应的商品。最后,用户收到商品并确认收货。至此,一个完整
的购物流程就结束了。
根据流程来划分模块
进一步细化电商购物的业务流程,看一下电商系统是如何实现
该流程的。下图所示的是细化之后的电商系统购物流程时序图
1）用户浏览商品,这个步骤需要通过一个商品模块来展示商品详情页,用户可
以从中获取所浏览商品的详细介绍和价格等信息。
2）然后,用户把选好的商品加入购物车,这个步骤需要使用一个购物车模块来
维护用户购物车中的商品。
3）接下来是用户下单，这个步骤需要基于一个订单模块来创建新订单。订
单创建好了之后,系统需要把订单中的商品从购物车中删减掉。
4）订单创建完成后,系统需要引导用户付款,即发起支付流程,可通过一个支
付模块来实现支付功能,用户成功完成支付之后,系统需要把订单的状态变更为
“已支付”。
5）成功支付之后,运营人员就可以发货了,发货之后,系统需要扣减对应商品
的库存数量,这个步骤需要基于一个库存模块来实现库存数量的变更,同时系统还
需要把订单状态变更为“已发货”。
6）最后,用户收到商品,在系统中确认收货,系统需要把订单状态变更为“已
收货”,流程结束。
这个流程涉及 5 大功能模块,即商品、购物车、订单、支付和库存。这 5 大
模块就是一个电商系统中的核心功能模块。
当然,仅有这 5 个模块是不够的,因为我们只分析了“购物”这个最主要的流
程，并没有完全涵盖业务需求中的全部用例,比如,运营人员进货、管理者查看报
表等还没有覆盖到。相比购物流程,剩下的几个用例和流程都相对简单一些,大家
可以采用同样的方法来分析其他的功能模块
整个系统按照功能,可以划分为 10 个模块,除了购物流程中涉及的商品、订单、
购物车、支付和库存这 5 个模块之外,还有了促销、用户、账户、搜索推荐和报
表这 5 个模块，这些都是构建一个可实际运营电商系统必不可少的功能模块。每
个模块需要实现的功能说明如下。
➢ 商品:维护和展示商品的相关信息。
➢ 订单:维护订单信息和订单状态,计算订单金额。
➢ 购物车:维护用户购物车中商品的信息。
➢ 支付:负责与系统内外部的支付渠道对接,实现支付功能。
➢ 库存:维护商品的库存信息。
➢ 促销:制定促销规则,计算促销优惠信息。
➢ 用户:维护系统的用户信息,注意,用户模块是一个业务模块,一般不负责
用户的登录和认证,这是两个完全不同的功能。
➢ 账户:账户模块负责维护用户的账户信息，例如用户的积分、等级、余额。
➢ 搜索推荐:提供商品搜索功能,并负责各种商品列表页和促销页的组织和
展示,简单地说就是，搜索推荐决定用户优先看到哪些商品。
➢ 报表:实现数据统计和分析功能，生成报表,为管理者进行经营分析和决
策提供数据信息。
总结电商系统设计核心要点
首先,电商系统面向的角色是:用户、运营人员和管理者。这三个角色对电商
系统的需求是:用户通过系统来购物,运营人员负责商品的销售,管理者关注系统
中的经营数据。电商系统最核心的流程是用户购物的流程,购物流程从用户浏览
选购商品开始,加购、下单、支付、运营人员发货、用户确认收货,至此电商系统
的购物流程结束。
细化这个流程之后,我们可以分析出支撑这个流程的核心功能模块:商品、订
单、购物车、支付和库存。除此之外,一个完整的电商系统还包括促销、用户、
账户、搜索推荐和报表这些必备的功能模块。
需求分析定义
软件需求
分析也称为系统需求分析或需求分析工程等，是开发人员经过深入
细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将
用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。
软件开发一般包括：可行性分析、需求分析、软件设计、软件开发、软件测
试、软件实施、软件服务等步骤，需求分析是软件开发的第一步骤。
用户需求分析是指在系统设计之前和设计、开发过程中对用户需求所作的调
查与分析，是系统设计、系统完善和系统维护的依据。
需求是需要与欲求的意思，需求是机体的一种客观需要，而欲求则是一种主
观需要，包括人在胜利、环境、社会等方面的需要。
需求是一款产品的市场基础，成功的产品不但能满足用户的物质需求，也要
满足用户的精神和心理需求。
软件需求分析目标
需求分析是软件计划阶段的重要活动，也是软件生存周期中的第一步，该阶
段是分析系统在功能上需要“实现什么”，而不是考虑如何去“实现”。
对客户的信息化需求进行分析，将客户不规范的、随意的需求，转换成规范
的、严谨的、结构化的需求，将客户不正确的需求转换成正确的需求、将客户不切实际的需求转换成可以实现的需求，将客户不必要的需求砍掉，将客户漏掉的
需求补上。
此外，软件的一些非功能性需求(如软件性能、可靠性、响应时间、可扩展
性等)，软件设计的约束条件，运行时与其他软件的关系等也是软件需求分析的
目标
软件需求分析原则
需求分析通常来讲它们应符合以下一般原则：
- 能够表达和理解问题的信息域
信息域反映的是用户业务系统中数据的流向和对数据进行加工的处理过程，
根据信息域描述的信息流、信息内容和信息结构，可以较全面地（完整地）了解
系统的功能。 - 建立描述系统信息、功能和行为的模型
建立模型的过程是“由粗到精”的综合分析的过程。通过对模型的不断深化
认识，来达到对实际问题的深刻认识。 - 能够对所建模型按一定形式进行分解
分解是为了降低问题的复杂性，增加问题的可解性和可描述性。分解可以在
同一个层次上进行（横向分解），也可以在多层次上进行（纵向分解）。 - 分清系统的逻辑视图和物理视图
软件需求的逻辑视图描述的是系统要达到的功能和要处理的信息之间的关
系，这与实现细节无关，而物理视图描述的是处理功能和信息结构的实际表现形
式，这与实现细节是有关的。
需求分析只研究软件系统“做什么？”，而不考虑“怎样做？”。
软件需求分析内容
需求分析的内容是针对待开发软件提供完整、清晰、具体的要求，确定软件
必须实现哪些任务。
具体分为功能性需求、非功能性需求与设计约束三个方面：
- 功能性需求
功能性需求即软件必须完成哪些事，必须实现哪些功能，以及为了向其用户
提供有用的功能所需执行的动作。
功能性需求是软件需求的主体，开发人员需要亲自与用户进行交流，核实用
户需求，从软件帮助用户完成事务的角度上充分描述外部行为，形成软件需求规
格说明书。 - 非功能性需求
作为对功能性需求的补充，软件需求分析的内容中还应该包括一些非功能需
求。
主要包括软件使用时对性能方面的要求、运行环境要求，软件设计必须遵循
的相关标准、规范、用户界面设计的具体细节、未来可能的扩充方案等。 - 设计约束
一般也称做设计限制条件，通常是对一些设计或实现方案的约束说明。
例如：要求待开发软件必须使用 Oracle 数据库系统完成数据管理功能，运
行时必须基于 Linux 环境等。
软件需求分析过程
需求分析阶段的工作,可以分为四个方面：问题识别、分析与综合、制订规
格说明、评审。
- 问题识别
就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需
求的实现条件，以及需求应该达到的标准。
这些需求包括：功能需求（做什么）、性能需求（要达到什么指标）、环境
需求（如机型、操作系统等）、可靠性需求（不发生故障的概率）、安全保密需
求、用户界面需求、资源使用需求（软件运行是所需的内存、CPU 等）、软件成
本消耗与开发进度需求、预先估计以后系统可能达到的目标。 - 分析与综合
逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的
限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。
最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型（做什么的
模型）。 - 制订规格说明书
即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析
阶段的成果是需求规格说明书，向下一阶段提交。 - 评审
对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可
进行下一阶段的工作，否则重新进行需求分析。
软件需求评估方法
需求评估分析方法通常有：模糊聚类分析、质量功能展开、KANO 模型分析、
A/B 测试。其中以卡诺（KANO）模型最常用。
- 模糊聚类分析法
是通过分析客观事物之间的不同特征和亲疏程度，建立模糊相似关系，从而
对齐进行分类的方法。
在用户需求分析的运用中，判断用户需求之间的相似程度（亲疏关系），然
后统计并建立相似性矩阵，继而寻找需求组合之间的相似程度，由此逐渐将用户
需求逐一归类。
最终得到一个关系图谱，以更直观和自然的方式展示用户需求各个特性之间
的差异性和相似性，模糊聚类分析法一般要求对需求进行数学建模分析。 - 质量功能展开
是指把用户对产品的需求进行多层次的演绎分析，转化为产品的设计需求、
工程部件特征、工艺要求、生产要求，用来指导产品设计并保证产品的质量，是
一种以用户为导向的质量管理工具。
由于该方法所使用的主要图形就像房屋，所以它也被称为“质量屋”。
3.卡诺 KANO 模型
是 Noriaki Kano 博士提出的与产品性能有关的用户满意度模型，该模型能
对用户需求进行很好的识别和分类，是对用户需求分类和优先排序的有用工具，
以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非
线性关系。
Noriaki Kano 将影响满意度的因素划分为五个类型，包括：必备需求、期望
需求、魅力需求、无差异需求、反向需求。
兴奋（魅力）需求：用户意想不到的，如果不提供次需求，用户满意度不会
降低，但是提供次需求，用户满意度会有很大的提升；
期望（意愿）需求：当提供此需求，用户满意度会提升，当不提供此需求，
用户满意度会降低；
基本（必备）需求：当优化此需求，用户满意度不会提升，当不提供此需求，
用户满意度会大幅下降；
无差异需求：无论提供或者不提供此需求，用户满意度都不会有变化，而且
根本不会在意；
反向（逆向）需求：用户根本没有这个需求，提供之后用户满意度反而会下
降。
利用 KANO 模型进行需求评估主要集中于对用户需求类型的分类讨论。为了
便于分析可以设计相应的调研问卷。
问卷中需要对产品的某项功能分别设置正向和负向两个问题：“如果产品有
这个功能，您觉得如何？” 、“如果产品的这个功能不存在，您觉得如何？”
每个问题采用态度量表的形式设计选项，即“我喜欢这样”、“我期望这样”、
“我没有意见”、“我可以忍受”、“我讨厌这样”，具体形式如下表：
经过访谈调研后，根据归类矩阵，将调研问题进行归类来确定需求的类型，
KANO 模型需求归类矩形如下表：
就能够比较明确地看到，哪些用户需求是必须有的，哪些是用户期望的，哪
些是可有可无的，哪些需求又是用户自己不确定的。
将用户需求进行分类，在产品开发时，功能优先级的排序一般是：基本属性>
期望属性>兴奋属性>无差异属性，去掉可疑结果的需求和相反的需求。 - A/B 测试
是为 Web 或 App 界面或流程制作两个或多个版本，分别让组成成分相同（相
似）的访客群组（目标人群）随机的访问这些版本，收集各群组的用户体验数据
和业务数据，最后分析、评估出最好版本并且实现的综合成本低，正式采用。
比较常见的案例是对网站注册页进行 A/B 测试，确定哪一个方案的注册率高，
更加满足用户的需求，实现的商业利益最大化。
需要注意在进行 A/B 测试时，每次必须只测量一个变量，多个变量测试，则
无法判断是哪个变量导致的结果；测试的环境应当一直，例如测量时间应一致。
因为在不同的时间段，用户的访问量会有变动；测量的样本量要具有统计学
意义，样本流量太小时，无法体现在线用户的真实行为。
需求分析优先级的方法
需求优先级的分析方法大致可以分成两大类：定性分析方法、定量分析方法；
一类是根据分析人员的经验主观地对需求进行优先级分类，称之为定性的分
析方法，比如：四象限分析法、波士顿矩阵分析法；另一类是根据调查数据，对
调查数据进行分析，得出需求的优先级分类，称之为定量的分析方法，比如：KANO
模型。
- 四象限分析法
根据需求对于业务的影响，以及需求实现的紧迫程度，我们可以按照如下方
式将需求归为 4 个象限，这也是需求归类的经典 4 分法。四象限分析法是很常见
的一种定性分析需求优先级的方法，如下：
重要且紧急的事，影响业务正常进行，需要尽快处理；
不重要但紧急的事，虽然对业务影响不大，但是需要尽快处理；
重要且不紧急的事，对业务影响大，但不需要短期内就完成；
不紧急且不重要的，对业务影响不大，也不需要短期内完成。 - 波士顿矩阵
波斯顿矩阵是由波士顿咨询公司发明的一种方法，最早用于分析市场增长率
和市场份额，现在也被经常用于对需求的分析之中，波士顿矩阵由用户价值维度
和公司价值两个维度将需求分成了四个象限：
明星需求：对用户体验有价值，对公司战略也有价值的需求。明星需求是双
赢的需求，需要优先得到满足，如一些促进用户活跃、转化的需求，具体的有，
活跃度排名、优惠提醒等功能；
问题需求：对用户体验有价值，但对公司战略和目标没价值的需求。此类需
求虽然看似对公司没直接价值，但是提升用户体验有助于提升用户的忠诚度，如
一些提升用户体验的需求。具体的有，提供多种快捷登陆方式、提供辅助输入功
能等；
金牛需求：对用户体验没价值甚至会对用户造成困扰，但是对公司战略有价
值的需求。公司价值的体现，此类需求应该尽量考虑避免对用户造成影响。如一
些运营需求等。具体的有，收集用户信息等；
瘦狗需求：对用户体验无价值，对公司战略也无价值的需求。此类需求应该
过滤掉，例如一些伪需求。
3. 卡诺 KANO 模型法
Noriaki Kano 将影响满意度的因素划分为五个类型，包括：必备需求、期望
需求、魅力需求、无差异需求、反向需求（详情见上文）。
需求文档，需求说明书
常用的软件需求说明书模板
软件需求说明书，又称软件需求规格说明书，英文名为 Software
Requirements Specification（SRS），是需求人员在需求分析阶段需要完成的产物。
它的作用是作为用户和软件开发者达成的技术协议书，作为设计工作的基础和依
据，作为测试和验收的依据。
软件需求说明书应该完整、一致、精确、无二义性，同时又要简明、易懂、
易修改。在一个团队中，须用统一格式的文档进行描述，为了使需求分析描述具
有统一的风格，可以采用已有的且能满足项目需要的模板，也可以根据项目特点
和开发团队的特点对标准模板进行适当的改动，形成自己的模板。
下面介绍几种常用的软件需求说明书模板：
RUP 版本
Volere 版本
国标 ISO 版本
SERU 版本
RUP 版本
RUP（Rational Unified Process），统一软件开发过程，是一个面向对象且基
于网络的程序开发方法论。RUP 是由 Rational 软件公司（Rational 公司被 IBM 并
购）创造的软件工程方法。RUP 描述了如何有效地利用商业的可靠的方法开发和
部署软件，是一种重量级过程，适用于大型软件团队开发大型项目。
以下是一个标准的 RUP 文档模板：
1.文档概述
这个部分是欧美标准文档通用的格式：首先指出文档的目的、目标读者及各
类读者的要点（目的小节)；然后说明项目的背景信息（背景小节)；接着是文档
中出现的术语和缩略语（定义、首字母缩写词和缩略语小节)；再接着则是该文
档所引用的参考资料（参考资料小节)；最后则是概要地表达本文档的内容（概
述小节)。
1.1 目的
1.2 背景
1.3 定义、首字母缩写词和缩略语
1.4 参考资料
1.5 概述
2.整体说明
[让读者对整个软件系统的需求有一个框架性的认识。主要包括产品总体效
果、产品功能、用户特征、约束、假设与依赖关系、需求子集等方面的内容。]
2.1 用例模型
2.2 假设与依赖关系
这个部分的内容是用来使读者建立一个框架性认识的。在写作指南中指出，
应该写明产品的总体效果、产品功能、用户特征（也就是国标版本中的用户特点）、
假设与依赖关系（专门开辟了一个小节)、需求子集（当系统需要多层分解时将
使用它）。在 RUP 的相关示例中，还在本部分中使用了上下文关系图。
另外，这个部分显然最重要的是系统的用例模型！因为在 RUP 中，用例是
需求组织的核心元素。在此应该给出系统的总体用例图以及用例的简述。
3.具体需求
3.1 用例描述
3.2 补充需求
[易用性、可靠性、性能、其他]
显然这个部分的主要内容就是对用例模型中列出的每个用例进行详细描述。
除此之外，还应该说明外部接口、质量属性、设计约束等补充需求。
4.支持信息
根据该文档的写作指南中的信息，这个部分主要是用来提供目录、索引、附
录、用户界面原型等信息的，以便令“软件需求规约”更易于使用。
模板说明:
在 RUP 中指出“用例视图是由活动图、用例图、类图组成的”。但上面的
文档模板缺失活动图和类图。换句话说，这份需求模板最主要缺少的内容就是串
起用例之间的行为逻辑的“流程”信息（用活动图表示），以及描述领域数据之
间的关系、它们构成的信息（用类图表示）。
建议要么在这个需求规约的基础上补充这两类信息，要么就用一个 UML 模
型来补充它（可以使用 Rose、Together 之类的建模工具）。
实际的应用中该模板中的信息不够完整，因为在 RUP 中所采用的需求描述
策略是“模型为主、文档为辅”，也就是说，“需求模型”推荐使用 Rose 创建
“用例规约”才是完整的。
Volere 版本
Atlantic System Guild 公司所提供的 Volere 需求过程与软件需求规格说明书
模板则充分利用了现代软件工程思想与技术，是一个十分实用、完善的模板。
Part Ⅰ：项目驱动
1.项目的目标
1.1 该项目工作的用户业务或背景
1.2 项目的目标
2. 客户、顾客和其他风险承担者
2.1 客户
2.2 顾客
2.3 其他风险承担者
3. 产品的用户
3.1 产品的直接操作用户
3.2 对用户设定的优先级
3.3 用户参与程度
3.4 维护用户和服务技术人员
PartII:产品限制条件
4. 强制的限制条件
4.1 解决方案的限制条件
4.2 当前系统的实现环境
4.3 伙伴应用或协作应用
4.4 立即可用的软件
4.5 预期的工作地点环境
4.6 进度计划限制条件
4.7 该产品的财务预算
5. 命名惯例和定义
5.1 定义在项目中使用的所有术语，包括同义词
5.2 所有包含模型的数据字典
6. 相关事实和假定
6.1 事实
6.2 假定
PartIII:功能性需求
7. 工作的范围
7.1 当前的状态
7.2 工作的上下文范围
7.3 工作切分
8. 产品的范围
8.1 产品边界
8.2 产品用例清单
8.3 单个产品用例
9. 功能性需求与数据需求
9.1 功能性需求
9.2 数据需求
PartIV:非功能需求
10. 观感需求
10.1 外观需求
10.2 风格需求
11. 易用性和人性化需求
11.1 易于使用的需求
11.2 个性化和国际化需求
11.3 学习的容易程度
11.4 可理解性和礼貌需求
11.5 可用性需求
12 执行需求
12.1 速度和延迟需求
12.2 安全性至关重要的需求
12.3 精度需求
12.4 可靠性和可访问性需求
12.5 健壮性或容错需求
12.6 容量需求
12.7 可伸缩性和可扩展需求
12.8 寿命需求
12. 操作需求
13.1 预期的物理环境
13.2 与相邻系统接口的需求
13.3 产品化需求
13.4 发布需求
13. 可维护性和支持需求
14.1 可维护性需求
14.2 支持需求
14.3 适应能力需求
14. 安全需求
15.1 访问控制需求
15.2 完整性需求
15.3 稳私需求
15.4 审计需求
15.5 免疫力需求
15. 文化和政策需求
16.1 文化需求
16.2 政策需求
16. 法律需求
17.1 合法需求
17.2 标准需求
PartV:项目问题
17. 开放式问题
18. 立即可用的解决方案
19.1 已经做好的产品
19.2 可复用的组件
19.3 可以复制的产品
19. 新问题
20.1 对当前环境的影响
20.2 对已实施系统的影响
20.3 潜在的用户问题
20.4 预期的实现环境会存在什么限制新产品的因素
20.5 后续问题
20. 任务
21.1 项目计划
21.2 开发阶段计划
21. 迁移到新产品
22.1 迁移到新产品的需求
22.2 为了新系统，哪些数据必须修改或转换
22. 风险
23. 费用
24. 用户文档和培训
25.1 用户文档需求
25.2 培训需求
25. 后续版本需求
26. 关于解决方案的设想
国标 ISO 版本（1998）
- 引言
1.1 编写的目的
我经常会在一些需求规格说明书中看到类似于“为了更好地完成本次软件的
开发，经过详细的用户调查……”之类的描述。每当看到的时候，我就会问作者：
“这段话有什么用呢？”作者通常会回答“那应该写什么呢？”
其实如果你认真地阅读过相应的指南，就会发现本小节的本意应该是：指出
本文档所针对的读者对象，以及每类读者对象应该重点阅读的部分。那么软件需
求规格说明书有哪些不同的读者对象呢？它们的阅读重点又应该有什么不同
呢？
第一个方面的区别显然是读者背景，很多软件需求规格说明书对业务背景的
读者照顾不足，这样会导致用户评审变得困难。因此如果在此能够说明不同背景
的读者应该重点阅读哪些内容是不错的办法。
第二个方面的区别是用户的层次：高层用户关心业务需求（目标与范围），
也就是偏重于阅读任务概述、目标这些小节；中层用户关心业务事件、Stakeholder
关注点,也就是偏重于阅读每个子系统中的分解、流程图以及一些利益点分析；
操作层用户关心业务活动，也就是偏重于阅读用例的描述。
第三个方面的区别是用户所属的业务区域，如果需求规格说明书中的内容能
够体现这种区域划分，就能够使读者更好地评审。
1.2 背景
1.3 定义
[本文件中用到的专门术语的定义和外文首字母组词的原词组。]
1.4 参考资料
[列出用得着的参考资料。] - 任务概述
2.1 目标
[叙述该系统开发的意图、应用目标、作用范围以及其他应向读者说明的有
关该系统开发的背景材料。解释被开发系统与其他有关系统之间的关系。]
2.2 用户的特点
[列出本系统的最终用户的特点，充分说明操作人员、维护人员的教育水平
和技术专长，以及本系统的预期使用频度。]
2.3 假定和约束
[列出进行本系统开发工作的假定和约束。] - 需求规定
3.1 对功能的规定
[用列表的方式，逐项定量和定性地叙述对系统所提出的功能要求，说明输
入什么量、经怎么样的处理、得到什么输出，说明系统的容量，包括系统应支持
的终端数和应支持的并行操作的用户数等指标。]
这个部分是最为核心的内容，通常会占整份文档的 60%〜70%的篇幅；可是
模板中只是定义了该小节，里面该如何组织并没有明确地定义出来，那么如何保
证每个人写出来的东西具有相近的风格呢？
这实际上就是通用型模板和企业模板的区别，作为通用型模板是无法定义到
更细的程度的，因为不同的软件项目、不同的团队、不同的开发方法必然会采用
不同的组织方法。因此我们在使用之前，必须对这个部分做进一步的细化。
另外，在该标准中建议直接用“条目”来定义需求，而这种方法最大的问题
是数量大、粒度不统一，因此现代软件需求理论实际上更建议使用用例、用户故
事、特性之类的组织单元来代替这种风格的表述。
3.2 对性能的规定
这个部分经常被理解成非功能需求的全部，同时导致了一种误解：所有非功
能需求都应该单独地罗列出来，这样都经常出现“全局性”非功能需求，但实际
上有很多是“局部性”的，我们应该让它和相应的功能需求同时出现。
其实，如果我们认真阅读指南就会发现，在针对“对功能的规定”小节的指
南中，有一句“说明系统的容量，包括系统应支持的终端数和应支持的并行操作
的用户数等指标”，这显然是非功能需求。
3.2.1 精度
3.2.2 时间特性要求
3.2.3 灵活性
3.3 输入/输出要求
这个部分具有很强的历史性，在当时输入、输出设备并不是只有键盘、鼠标、
打印机，还有列表机、纸带机等形式多样、功能不同的其他设备。因此在软件开
发之前,是有必要做相应描述的。
而在今天的很多软件中，这个部分是比较单一的，因此可以考虑将这个部分
内容从模板中去除。
3.4 数据管理能力要求（针对软件系统）
在该标准制定时，数据库并不是最流行的或唯一的数据管理机制，开发人员
可能会需要直接使用外部文件等方法。而今天的情况完全不同，数据管理基本上
是交由数据库管理系统实现的，因此通常也不会需要本小节。
不过也有一些软件系统有例外的情况，例如地理信息系统、实验数据管理平
台都可能涉及这一部分。对于地理信息系统而言，有许多数据不是直接存储到数
据库中的，它涉及各种图层信息应该以什么格式保存、如何保存、如何组织等；
对于实验数据管理平台也是这样，数据量极大，数据库无法解决，需要开发人员
另想办法，这也就涉及到了数据管理能力方面的信息。
3.5 故障处理要求
这个部分在很多信息系统中是相对较弱的，因此可以将其合并到“其他专门
要求”中，或者归类为“补充规约”也是不错的做法。
3.6 其他专门要求 - 运行环境规定
这个部分的信息，现在的绝大多数软件也都会遇到；在 UML 中建议用部署
图对其进行建模，并纳入“补充规约”中。在这份模板中定义了以下几个方面内
容：
•设备：用到的硬件资源；
•软件：预期的操作系统、中间件、数据库、第三方软件等软件环境资源；
•接口：所需的外部系统接口；
•控制：这个部分有些过时，在诸如 CIMS(计算机集成制造系统）之类的软
件中就经常会涉及控制信号方面的规定。
4.1 设备
[列出运行该软件所需要的硬设备。说明新型设备及其专门功能。]
4.2 支持软件
[列出支持软件，包括要用到的操作系统、编译程序、测试支持软件等。]
4.3 接口
[说明该系统同其他系统之间的接口、数据通信协议等。]
4.4 控制
[说明控制该系统的运行方法和控制信号，并说明这些控制信号的来源。]
国标 ISO 版本（2006）
新模板的第 1 和第 2 小节实际上起到的作用还是“引言”的作用，不过在具
体的内容上还是做出了不小的调整。
首先是做了一些扩展，包括将“编写目的”扩充为“文档概述”，将“背景”
扩展为“系统概述”，同时也更明确地指出了它应该包含的内容。
然后是做了一些剪裁和调整，包括将“定义”小节去掉了（放在最后的“注
释”部分中），这和我们前面的分析比较类似，该信息更适合单独来管理；另外
还将“参考资料”更精确地定义为“引用文件”，并将其作为单独的章节。
另外还做了一些补充，增加了“标识”和“基线”，它们是近代软件工程理
论的产物，用来实现需求的跟踪和需求基线管理。
- 范围
1.1 标识
[本文档适用的系统和软件的完整标识]
1.2 系统概述
[适用的系统和软件的用途；开发、运行、维护历史]
1.3 文档概述
[文档的用途和内容]
1.4 基线 - 引用文件
- 需求
3.1 所需的状态和方式
[软件项是否在多种状态和方式下运行]
3.2 需求概述
3.2.1 目标
[表述系统的目标和范围]
3.2.2 运行环境
3.2.3 用户特点
3.2.4 关键点
[关键功能、关键算法、关键技术]
3.2.5 约束条件
3.3 需求规格
3.3.1 软件系统总体功能/对象结构
[对软件系统总体功能/对象结构进行描述，包括结构图、流程图或对象图]
3.3.2 软件子系统功能/对象结构
[对每个主要子系统中的基本功能模块/对象结构进行描述，包括结构图、流
程图或对象图]
3.3.3 描述约定
3.4 软件配置项能力要求
[可用功能、性能、目标或类似词代替“能力”]
3.4. X
[包括能力的说明、输入、处理、输出]
3.5 外部接口需求
3.5.1 接口标识和接口图
3.5. X 具体接口
[说明接口优先级、接口类型、数据元素特性、数据元素集合、接口通信方
法、必须使用的接口协议等]
3.6 内部接口需求
3.7 内部数据需求
3.8 适应性需求
[提供的依赖于安装的数据有关的需求]
3.9 保密性需求
[诸如防止意外动作和无效动作所必须提供的安全措施]
3.10 保密性和私密性需求
3.11 环境需求
3.12 计算机资源需求
3.12.1 计算机硬件需求
3.12.2 计算机硬件资源利用需求
3.12.3 计算机软件需求
3.12.4 计算机通信需求
3.13 软件质量因素
3.14 设计和实现的约束
3.15 数据
3.16 操作
3.17 故障处理
3.18 算法说明
3.19 有关人员需求
3.20 有关培训需求
3.21 有关后勤需求
3.22 其他需求
3.23 包装需求
3.24 需求的优先次序和关键程度 - 合格性规定
[可以独立，也可以直接在前面注明方法，包括演示、测试、分析、审查、
其他特殊方法] - 需求可追踪性
- 尚未解决问题
- 注释
新版本相对老版本做了以下两点的更新：
①对“需求规定”进行了详细的分拆。
新模板一改上一版本中简单的风格，对“需求规定”小节提供了更加完整、
全面的分解，并且将原先的“运行环境规定”部分也整合进来了。但是从最终的
效果上来看，通用性被强化了，适用性被减弱了，因此在实际应用中应根据需要
对其进行必要的剪裁。
另外，为了帮助大家能够更好地理解新模板中对“需求规定”小节所分出的
24 个子部分，我们再对其做一些简要的说明，如下表所示：
②增加了一些提升文档功能性的内容
新模板的第 4〜7 小节实际上是为了提高整个软件需求规格说明书的功能性；
合格性规定是针对测试团队、验收团队的信息；需求可追踪性是针对项目管理人
员的信息；尚未解决问题、注释则是为了帮助读者更好地理解、使用文档。
SERU 版本
SERU 是一套系统全面的需求方法论，适合中国国情，尤其对 ToB 类软件的
需求文档编写有较好的指导作用。
1.文档概述
在本小节中将说明整个文档所针对的不同读者群（编写目的）、整个项目的
背景和概况信息（背景)、文档中常用的技术缩略语及相关词条（定义)，以及文
档编写时所需引用、参考的资料（参考资料）。
1.1 编写的目的
1.2 背景
1.3 定义
1.4 参考资料
在老版本的国标模板、RUP 提供的模板中都有相似小节，这个部分是规范的
文档所应该具有的信息。
2. 任务概述
2.1 业务需求
2.2 Stakeholder 利益分析
2.3 用户特点分析
2.4 相关事实与假定
也就是项目目标、Stakeholder 关注点、用户特点、相关事实与假定之类的
概述性信息，这部分信息通常是需求定义（项目立项）阶段就需要确定的，属于
业务需求的范畴，是中高层用户代表所关心的内容。这部分内容单独地放在一个
小节中。当然，这个阶段还将产生一个十分重要的内容，也就是项目范围，但为
了便于阅读，将其作为第 3 部分（需求概述）的纲要出现。
3. 需求概述
3.1 系统概述
[主题域划分，用构件图表述]
3.2 主题域 1
3.2.1 概述
[用上下文关系图表示该主题域的范围]
3.2.2 业务事件
3.2.2.1 业务事件 1
[包括流程分析、领域类分析、用例分析]
3.2.2.n 业务事件 N
3.2.3 报表
3.2.3.1 Report1
[用领域类图片段表示涉及数据，用用例标识具体的报表项]
3.2.3.N Reportn
3.3 主题域 n
以上部分和第 4 部分（具体需求部分)，实际上是对老版本的国标模板中“3.1
对功能的规定”小节的分解，以便让软件需求规格说明书的作者更加有的放矢地
组织所需的信息。
需求概述部分的主要内容是针对中层用户代表的，其核心内容在于对业务知
识的梳理，目标在于导出系统的用例模型和领域模型，是需求分析第一阶段（理
清框架和脉络）的工作任务。简单地说，就是：
•首先将系统按业务的特点分成不同的子问题域（主题域)，并且通过构件图
整理出它们之间的接口。
•对每个子问题域（主题域）进行分解，标识出与系统相关的业务流程（业
务事件是流程的起点）、报表类型。
•然后绘制每个业务流程的流程图，将流程中涉及的业务实体之间的关系、
结构规则用领域类图片段表示出来，并根据“是否在系统边界之内”的原则从流
程图中派生出用例图。
•同时对于每类报表而言，用领域类图片段表示出其涉及的业务实体，用用
例图表示具体的报表项。
因此这个部分实际上就是采用一个业务驱动的树型结构（主题域、业务流程、
报表类型）贯穿的业务知识，它框出了系统所需完成的行为需求，以及它涉及的
结构需求。
这部分内容在老版本的国标模板中并没有涉及，但在新版本的国标模板中就
增加了这方面的信息，即“3.3 需求规格”小节，但具体的组织方法未定义。而
在 RUP 版本的模板中也没有明确地指出，但这部分信息实际上是从属于需求模
型的。
4. 具体需求
4.1 主题域 1
4.1.1 用例模型
4.1.1.1UC_B_xx(B 类)
(1) 概述[编号、名称、概述、相关 Stakeholder]
(2) 事件流描述[前、后置条件，基本、扩展、子事件流]
(3) 相关需求与功能点
(4) 界面原型[交互过程与界面详解]
(5) 规约与约束
4.1.1.2UC_R_xx(R 类)
(1) 概述
[名称、用户部门与职位、业务意图、相关场景]
(2) 报表内容[领域类图、数据项]
(3) 输入/输出格式
(4) 其他
4.1.1.3UC_I_xx(I 类)
(1)使用者[名称、业务目的、时机、频率]
(2)内容与格式[交互过程、数据包说明]
(3)设计与实现约束[诸如协议格式要求、性能要求等]
4.1.2 领域模型
4.1.2.1xx 领域类
(1)概述
[类名称、别名]
(2)数据窗口分析
[涉及主题域、业务事件，各域数据]
(3)数据组成与格式
(4)其他
4.N 主题域 n
以上部分是针对具体的开发人员和操作层的用户代表的，它将描述最为细节
的需求信息；由于该模板是针对“用例分析技术”的，因此选择“用例”作为行
为需求的最小单元，“领域类”作为结构需求的最小单元；换句话说，就是填充
用例和领域类的细节。
在这个部分中，参考了 RUP 版本的模板，并对用例模板进行了适当的扩展，
将每个具体的报表项定义为一个报表类（R)用例，每个具体的接口定义为一个接
口类（I)用例，同时为它们分别定义了不同的格式模板。另外，也对领域类应该
填充什么方面的内容进行了约定。
而在国标版本（包括老版本和新版本）、Volere 版本的模板中，由于它们并
不限定某种需求分析技术，因此采用了更通用的表示方法；因此在使用之前，建
议还是应该对其做进一步的定义与约定。
5. 补充规约
5.1 设计约束
5.1.1 技术选择的限制条件
5.1_2 运行环境
[建议使用部署图表示]
5.1.3 预期的使用环境
5.2 质量属性
[本部分建议直接分解成需要开发的技术功能点]
5.2.1 安全性要求
5.2.1.1 访问安全性要求
5.2.1.2 数据安全性要求
5.2.1.3 通信安全性要求
5.2.1.4 其他安全性要求
5.2.2 可靠性要求
5.2.2.1 容错性要求
5.2.2.2 可恢复性要求
5.2.2.3 其他可靠性要求
5.2.3 易用性要求
5.2.3.1 界面友好性要求
5.2.3.2 易操作性要求
5.2.3.3 其他易用性要求
5.2.4 性能要求
5.2.4.1 数据访问性能要求
5.2.4.2 数据传输性能要求
5.2.4.3 其他性能要求
5.2.5 可维护性要求
5.2.5.1 公共数据要求
5.2.5.2 公共框架开发要求
5.2.5.3 公共程序库开发要求
5.2.5.4 其他可维护性要求
5.2.6 可移植性要求
5.2.6.1 适应性要求
5.2.6.2 易安装性要求
5.2.6.3 其他可移植性要求
5.2.7 其他质量属性要求
5.3 其他需求
5.3.1 培训需求
5.3.2 后勤需求
5.3.3 包装需求
除了结构需求、行为需求之外的其他需求都应放在“补充规约”这一部分中，
在 RUP 版本的模板中采用了相同的组织方法；而在国标模板（包括新、老版本）、
Volere 模板中则是将它们打开，每个部分一个小节，区别仅在于展开的程度各有
不同。
我们根据在业务系统中经常涉及的内容对补充规约分成了三类：一是设计约
束；二是质量属性；三是其他内容。
对于设计约束而言应该包括技术选择的限制条件（也就是非技术因素决定的
技术选型）、运行环境（也就是预期的软、硬件环境，通常可以使用部署图表示）
以及预期的使用环境。这些内容在新版本的国标模板中也有详细的划分。
而对于质量属性而言，建议直接分解到要开发什么功能上，并根据对开发的
影响提供了一个树形结构。
此外还可以涉及培训、后勤、包装、升级等其他方面的需求，这在新国标版
本的模板、Volere 模板中都归纳了一些