产品需求规格说明书模版题材.doc

共 NUMPAGES 11页 第  PAGE \* ArabicDash  页 产品需求规格说明书 副标题： 版本 0.1 修订历史 版本号作者内容提要发布日期  目录  TOC \o 1-3 \h \z \u  HYPERLINK \l _Toc144279103 一、 业务目标？业务背景？  PAGEREF _Toc144279103 \h 3  HYPERLINK \l _Toc144279104 二、 术语表  PAGEREF _Toc144279104 \h 3  HYPERLINK \l _Toc144279105 三、 业务流程图  PAGEREF _Toc144279105 \h 3  HYPERLINK \l _Toc144279106 四、 系统用例模型  PAGEREF _Toc144279106 \h 5  HYPERLINK \l _Toc144279107 五、 系统用例详细描述  PAGEREF _Toc144279107 \h 6  HYPERLINK \l _Toc144279108 1. 用例1  PAGEREF _Toc144279108 \h 7  HYPERLINK \l _Toc144279109 2. ……  PAGEREF _Toc144279109 \h 11   业务目标？业务背景？ 业务的价值是什么？ 它的责任范围是什么？ 哪些不属于它的责任范围？（可选） 术语表 所有本文中可能需要用到的业务术语，都需要在这里定义，以保证业务的相关人员对这些专有名词的理解是一致的，并且，保证所有需要用到这些专有名词的地方，都统一地使用这些专有名词 业务流程图 说明：业务流程图可以采用流程图的形式，也可以是序列图的形式，业务流程图需要先以组织结构为单位建立组织结构之间的工作流程，再按照人力资源关系细化这些组织内部的工作流程，组织结构本身又有层次之分。 例如，阿里巴巴集团和外部集团或者公司之间的协作关系，属于集团级别的流程图，阿里巴巴内部各个公司之间的协作，属于公司级别的流程，支付宝公司内部部门之间的协作，属于部门级别的协作，最后，才是人力资源之间的协作关系，到了人力资源层次，每个人的个人活动才可能需要一次上机操作（也可以不需要上机操作），当需要上机操作的时候，这个操作任务就被映射到一个系统用例。 因此， 业务流程图建立的是各个活动之间的关系，而这些活动又按照粒度自上而下，逐步展开的方式进行描述，见范例： 系统用例模型 ｛观察上面流程图中各个活动结点的粒度划分，这些粒度正好是每个角色的最原子的“业务目标”——即，具有不可分割性，如果继续分割，活动就将成为一个一个操作，而操作本身不具有完整的业务意义，因为系统用例必须按照“业务目标”进行组织，因此，按照“业务目标”组织活动结点的好处是，每个活动如果需要上机操作，它实际上就可以被当作一个系统用例，所以，流程图到系统用例的转化就具有了可追溯性，系统用例模型描述了系统参与者和系统的职责边界，如下图范例所示 系统用例详细描述 对系统用例模型中的各个系统用例展开描述 思考思路如下所述： 用例1 层次 名称 层次的概念：系统用例之间存在相互依赖关系，例如，我们需要先进入管理保单这个高层用例，才可能进一步进入修改保单、统计结果等子用例，因此，管理保单就成为这些子用例的高层用例，实际上是一个描写用例名称的规范。 版本号： 该UC的版本号 UC变更历史： 该UC历史上的变更情况 负责人： 该UC的负责人 摘要： 用例描述： 简单描写该用户的业务目标 权限项： 如果是支付宝后台的UC，需要在这里描述该UC所属的权限项（由业务部门确认），所属菜单，以及角色分配情况，和角色分配的用户情况 用户界面设计： 页面白板Demo 用例场景： 主要参与者及其目标： {任务的执行者是谁？它做这件事情的目的是什么？这个角色可以是任何事物，可以是人、外部系统、定时器、温度感受器等等，主要参与者必须是和系统直接交互的人或事物} 辅助参与者及其作用： {任务执行过程中需要什么角色来辅助任务的完成？例如：银行职员的操作过程需要用户输入密码，才能进入下一步工作，辅助参与者必须是和系统直接交互的人或事物} 涉众利益：（用例评审者，利益相关者） ｛除了直接交互的参与者，还有哪些角色会关心这个用例的执行过程和结果？它们关心的理由是什么？｝ 前置条件： ｛这个用例需要满足什么条件才能进行？这个条件必须是系统能够感知的，，否则，不能作为前置条件，只能写背景概述中，另外，要求这个条件必须是当前操作需要进行判断的，有的用例在当