a有关质量分数的计算.docVIP

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