产品需求规格说明书模版

产品需求规格说明书

副标题：

版本0.1

修订历史

目录

一、业务目标？业务背景？ (3)

二、术语表 (3)

三、业务流程图 (3)

四、系统用例模型 (5)

五、系统用例详细描述 (6)

1.用例1 (7)

2. (11)

一、业务目标？业务背景？

业务的价值是什么？

它的责任范围是什么？

哪些不属于它的责任范围？（可选）

二、术语表

所有本文中可能需要用到的业务术语，都需要在这里定义，以保证业务的相关人员对这些专

有名词的理解是一致的，并且，保证所有需要用到这些专有名词的地方，都统一地使用这些

专有名词

三、业务流程图

说明：业务流程图可以采用流程图的形式，也可以是序列图的形式，业务流程图需要先以组

织结构为单位建立组织结构之间的工作流程，再按照人力资源关系细化这些组织内部的工作

流程，组织结构本身又有层次之分。

例如，阿里巴巴集团和外部集团或者公司之间的协作关系，属于集团级别的流程图，阿里巴

巴内部各个公司之间的协作，属于公司级别的流程，支付宝公司内部部门之间的协作，属于

部门级别的协作，最后，才是人力资源之间的协作关系，到了人力资源层次，每个人的个人活动才可能需要一次上机操作（也可以不需要上机操作），当需要上机操作的时候，这个操作任务就被映射到一个系统用例。

因此，业务流程图建立的是各个活动之间的关系，而这些活动又按照粒度自上而下，逐步展开的方式进行描述，见范例：

四、系统用例模型

｛观察上面流程图中各个活动结点的粒度划分，这些粒度正好是每个角色的最原子的“业务

目标”——即，具有不可分割性，如果继续分割，活动就将成为一个一个操作，而操作本身

不具有完整的业务意义，因为系统用例必须按照“业务目标”进行组织，因此，按照“业务

目标”组织活动结点的好处是，每个活动如果需要上机操作，它实际上就可以被当作一个系

统用例，所以，流程图到系统用例的转化就具有了可追溯性，系统用例模型描述了系统参与

者和系统的职责边界，如下图范例所示

五、系统用例详细描述

对系统用例模型中的各个系统用例展开描述

思考思路如下所述：

1.用例1

<<层次>> <<名称>>

层次的概念：系统用例之间存在相互依赖关系，例如，我们需要先进入管理保单这个高层用

例，才可能进一步进入修改保单、统计结果等子用例，因此，管理保单就成为这些子用例的

高层用例，实际上是一个描写用例名称的规范。

版本号：

该UC的版本号

UC变更历史：

该UC历史上的变更情况

负责人：

该UC的负责人

摘要：

●用例描述：

简单描写该用户的业务目标

●权限项：

如果是支付宝后台的UC，需要在这里描述该UC所属的权限项（由业务部门确认），所属菜

单，以及角色分配情况，和角色分配的用户情况

用户界面设计：

●主要参与者及其目标：

{任务的执行者是谁？它做这件事情的目的是什么？这个角色可以是任何事物，可以是人、外部系统、定时器、温度感受器等等，主要参与者必须是和系统直接交互的人或事物}

●辅助参与者及其作用：

{任务执行过程中需要什么角色来辅助任务的完成？例如：银行职员的操作过程需要用户输入密码，才能进入下一步工作，辅助参与者必须是和系统直接交互的人或事物}

●涉众利益：（用例评审者，利益相关者）

｛除了直接交互的参与者，还有哪些角色会关心这个用例的执行过程和结果？它们关心的理由是什么？｝

●前置条件：

｛这个用例需要满足什么条件才能进行？这个条件必须是系统能够感知的，，否则，不能作为前置条件，只能写背景概述中，另外，要求这个条件必须是当前操作需要进行判断的，有的用例在当前并不判断如“用户是否登录”这样的状态，因为这些状态在进入这个用例之前的用例已经做了｝

●主流程：

｛如果一切顺利，通过那些交互过程来达成目标

几点约束：

采用：用户。。。。。。

系统。。。。。。

用户。。。。。。

系统。。。。。。

这样的格式进行描述，要求使用简明扼要的动宾结构，统一的格式便于阅读；

２、通过使用者视角，并采用业务语汇进行描述；

３、不包含交互的具体数据描述以及系统背后的操作；甚至不包含业务规则；此处仅仅关注的交互——即用户如何使用系统，其他的内容分离到相应的部分详细展开描述，此处可以说明“业务规则见规则２。。。。（后文业务规则中的规则编号）”

４、每个操作必须具有业务意义上的“意图”，例如：输入用户名、输入密码这两个操作背后的意图是“输入并提交用户验证信息”，因此，不能将这两个操作分别作为用例的步骤，只能写“用户输入并提交验证信息”，也就是说，每个用例步骤都根本地表达出一个完整的“意图”，并且有助于朝目标迈进一步。

５、如果一个步骤是一个需要展开描述的复杂交互，可以作为一个“功能级”用例分离到一个单独的用例中描述，此处的只要写这个用例的名称，并且带下划线，表示是一个需要展开子用例。因此，正常的用例很少超过９步，如果多于这个数字，需要警惕。

６、某些部分需要循环，直接在用例文本的重复步骤后面说明“重复步骤n到m直到。。。。

（推出条件）

后置条件：

｛如果目标达成了，系统和开始以前相比，发生了哪些变化？这种变化包括操作者可见和不可见两个部分，例如：银行柜员机除了告诉操作者其银行账户减少了多少金额，还同时在背后按照业务规则给另一个账户增加了等量的金额｝

●扩展流程：

｛主流程中各个步骤都可能出现的各种其他可能情况，这些扩展点的写法是：对于需要扩展

的步骤，使用这个步骤的编号加英文字母表示，英文a表示第一种可能的情况，b表示第二

种可能的情况，对于在任何步骤都可能出现的情况，标号使用“＊”号表示。｝

●输入项详列：

｛详细罗列可能的输入项，说明字段长度、必填还是选填等具体要求，对于可选项的可选范

围，在输入输出限制中描述｝

●输出项详列：

｛详细罗列可能的输出项｝

●输入输出限制：

｛例如：是使用刷卡器来读卡还是手工输入卡号？还有例如：某些输入项的可选范围限制是

什么，在对某个可选项进行选择以后，对其他输入项的可选范围产生什么影响？等等，避免

使用“下拉列表”、“选择框”之类关乎界面设计的表述，只能用“单选项”或者“复选项”

这种表达方式。｝

●领域的业务规则：

｛例如：法律的、政府的、行业的……｝

●用户操作流程：

用图形的模式展现用户流程，简单说就是流程图。

●未决的问题：

补充规约：

思考范围：

安全性要求：｛例如：加密算法、安全架构……. ｝

可用性要求：｛例如：新手无需帮助的情况下的平均上手时间……｝

可靠性要求:｛例如：平均故障率，故障的平均恢复时间……. ｝

性能要求：｛例如：在一定并发数下的响应时间……｝

可支持性要求：｛例如：支持新的接口扩展、支持国际化扩展……. ｝

软硬件环境约束：｛例如：操作系统、网络、设备…..的限制｝

必须符合的标准：｛例如：网络协议、行业标准………｝

对文档和帮助的要求：｛例如：需要什么形式的帮助文档？细化到什么程度？｝

日志要求：｛例如：日志的用途？所需要的信息……. ｝

开发的约束条件：｛例如：使用JAVA语言、测试驱动，过程迭代……｝

其它：

可能的变更：

遗留问题和可能的解决方案：

｛例如：系统最可能发生变化地方在哪里？面对这些风险，可能解决方案由哪些？｝2.……