软件需求说明书模板-.pdf

《软件需求说明书模板-.pdf》由会员分享，可在线阅读，更多相关《软件需求说明书模板-.pdf（26页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、1.涉众分析涉众是与要建设的业务系统相关的一切人和事。可能包括：业主、业务提出者、业务管理者、业务执行者、第三方、承建方、相关的法律法规、用户。最终的系统使用者将从当中产生，但用户不等于涉众，仅是涉众的一部分。在此阶段应产生涉众分析报告。包括以下几部分：涉众概要、涉众简档、用户概要、用户简档、消费者统计、以及业务角色的组织结构图。表样如下：1.1.涉众分析表 1 涉众概要编号涉众名称涉众说明期望1.表 2 涉众简档涉众涉众代表特点职责1.成功标准1.参与可交付工件意见/问题1.2.用户分析表 3 用户概要编号用户名称用户概况和特点使用系统方式代表涉众1.表 4 用户简档用户用户代表说明特点职责

2、1.成功标准1.参与可交付工件意见/问题1.3.消费者统计表 5 消费者统计消费者名称消费者概况和特点应用环境使用频率特殊要求1.4.用户组织结构图给出系统主要用户的组织结构图，如存在多个用户组织，请分别给出。2.业务需求分析业务需求分析的目的是输出业务模型，业务模型是我们需求分析阶段最主要的工作成果，完整的业务模型包括以下内容：业务用例视图、业务用例场景、业务用例规约、业务对象模型和业务规则。要注意理解业务模型中各制品的意义及关系，业务用例视图是业务整体情况的完整展现，既要涵盖完全，又要以不同的视角对其进行展现，以保证项目需求单位与实施单位对现有业务能够具备统一的理解；业务用例场景是对业务用

3、例视图中每一个具体的用例执行情况的图形化描述，一般采用活动图（泳道）表示；业务用例规约是对业务用例的全面解释，既包含了业务用例的总体情况说明、执行者、执行过程（包括主流、分支和异常）、执行条件和约束，又包含了执行过程中涉及的业务对象；业务对象模型对业务用例中所涉及的业务实体之间的关系进行的描述；而业务规则是对业务过程中约束的描述。2.1.业务目标定义业务目标是对要建设系统的展望，业务系统的边界将基于业务目标来定义。在此阶段应提供明确的 系统目标。2.2.系统范围确定根据项目周期、成本、可行性分析等因素，衡量项目可以容纳的项目范围，调整已获得的业务目标和涉众期望，使后续的需求调研工作被局限在这些

4、范围内。但这个范围并不一定是系统的建设范围，如交费如果可作为一个涉众希望被规划在项目范围内，而不同的交费方式是否均在系统内实现才是真正的系统建设范围。该阶段应得到涉众的确认，明确范围后，应为每一个涉众及其期望定义优先级，并通过优先级矩阵确认实现涉众期望的顺序，这将是系统迭代的依据。该阶段应输出 全部涉众期望及其优先级 以及业务词汇表。优先级定义标准：涉众：最高3，业务核心人员，其工作构成最核心的业务流程，或核心业务的制定和监管者；普通2，主要业务的参与者，其工作是核心业务的重要辅助；最低1，边缘业务的参与者，其工作对核心业务流程不产生重要影响。期望：最高3，核心业务的组成部分，如缺少该期望，核

5、心业务流程不能运转；普通2，核心业务的重要辅助，如缺少该期望，核心业务流程将无法完成某些特定目标或无法顺畅运转；最低1，边缘业务，缺少该期望也不会影响核心业务流程的顺利运转。2.2.1.涉众期望整理表 6 涉众期望列表涉众编号涉众名称涉众优先级期望编号期望期望优先级2.2.2.期望优先级分析优先级分析可以使用优先级矩阵方法进行。优先级矩阵以涉众优先级作为横轴，期望优先级作为纵轴，单元格内的数值为涉众优先级与期望优先级的乘积。优先级矩阵可以给出两个结论：第一是确定期望的最终优先级，相乘结果大于等于6的为最高优先级，用红色表示；相乘结果大于等于4的为普通优先级，用黄色表示；剩余为最低优先级，用绿色

6、表示；对于多个涉众具有同一个期望的情况，该期望的优先级最终取值为最高优先级涉众的优先级因子与该期望的乘积。第二是明确下一步对某一期望的调研对象。表 7 优先级矩阵WR_SZ001（3）WR_SZ002（2）WR_SZ003（2）WR_SZ004（1）WR_EQS01（3）WR_EQS12（2）WR_EQS13（1）2.3.关键业务词汇说明该部分将需求分析过程中出现的重要词汇进行简要说明，有常用英文词汇的，填在备注栏内。表 8 业务词汇表序号业务词汇说明备注（常用英文名）2.4.业务边界及主角定义根据整理出的业务目标定义系统边界，在此过程中我们可以根据系统目标定义多个边界；对于每个定义出的边界，

7、我们只关注该业务目标所服务的涉众对于系统的期望，而忽略其他位于该边界范围内的各涉众的期望。只有直接与系统交互的涉众才被称为业务主角，我们应该按照所确定的业务边界从涉众概要中寻找站在边界外的涉众，并以主角的定义发现哪些涉众会成为业务主角。此过程应提供业务边界定义图 和边界内主角关系图，以明确定义的每个边界的服务对象，和边界范围内的涉众以及任务。2.5.边界 1 业务用例分析按照已定义的边界，根据业务主角所代表的涉众的针对该边界的期望或通过与客户访谈或其他沟通方式或缺业务用例，获取业务用例的过程中可以通过以下几个问题得到正确的用例：业务主角对系统的期望业务主角打算在这个系统里做些什么事情业务主角做

8、这件事情的目的是什么业务主角做完这件事希望有一个什么样的结果？涉众期望该过程结束后，应针对该业务边界范围内的业务主角与相关用例的业务用例视图、业务用例场景及业务用例规约。2.5.1.业务用例视图给出业务用例视图，简要说明业务用例视图中每个业务用例的含义。业务用例视图应完整，覆盖该边界内全部的业务主角和业务用例，在必要的情况下，还应以不同的视角展现业务用例。2.5.2.业务用例 1 2.5.2.1.业务用例场景用来描述业务用例在该业务的实际过程中是如何做的，是与用户就业务达成共识的重要制品。要求至少用活动图进行描述；如果该用例中主角间传递的信息很重要，要求同时用时序图表现该业务用例的执行过程。业

9、务用例场景图应以业务用例名命名。一个业务用例可能对应多个业务用例场景（正常执行、分支流程、异常流程等）。2.5.2.2.业务用例规约以文字的形式表述了业务用例的情况，包括用例名称、用例描述、执行者、前置条件、后置条件、主事件流描述、分支事件流描述、异常事件流描述、业务规则（交互规则）、涉及的业务实体等信息。业务用例规约一般以表格形式展现，要求每个用例必须提供业务用例规约。对于具有特别的非功能性需求的用例，应在业务用例规约表中添加一行说明非功能性需求；对于整个系统适用的非功能性需求应单独列出非功能性需求列表。表 9XX 业务用例规约业务用例名称用例描述执行者前置条件1.后置条件1.主过程描述1.

10、分支过程描述异常过程描述业务规则涉及的业务实体2.5.3.业务用例 2 2.5.3.1.业务用例场景用来描述业务用例在该业务的实际过程中是如何做的，是与用户就业务达成共识的重要制品。要求至少用活动图进行描述；如果该用例中主角间传递的信息很重要，要求同时用时序图表现该业务用例的执行过程。业务用例场景图应以业务用例名命名。一个业务用例可能对应多个业务用例场景（正常执行、分支流程、异常流程等）。2.5.3.2.业务用例规约以文字的形式表述了业务用例的情况，包括用例名称、用例描述、执行者、前置条件、后置条件、主事件流描述、分支事件流描述、异常事件流描述、业务规则（交互规则）、涉及的业务实体等信息。业务

11、用例规约一般以表格形式展现，要求每个用例必须提供业务用例规约。对于具有特别的非功能性需求的用例，应在业务用例规约表中添加一行说明非功能性需求；对于整个系统适用的非功能性需求应单独列出非功能性需求列表。表 10XX 业务用例规约业务用例名称用例描述执行者前置条件2.后置条件2.主过程描述2.分支过程描述异常过程描述业务规则涉及的业务实体2.6.边界 2 业务用例分析按照已定义的边界，根据业务主角所代表的涉众的针对该边界的期望或通过与客户访谈或其他沟通方式或缺业务用例，获取业务用例的过程中可以通过以下几个问题得到正确的用例：业务主角对系统的期望业务主角打算在这个系统里做些什么事情业务主角做这件事情

12、的目的是什么业务主角做完这件事希望有一个什么样的结果？该过程结束后，应针对该业务边界范围内的业务主角与相关用例的业务用例视图、业务用例场景及业务用例规约。2.6.1.业务用例视图给出业务用例视图，简要说明业务用例视图中每个业务用例的含义。业务用例视图应完整，覆盖该边界内全部的业务主角和业务用例，在必要的情况下，还应以不同的视角展现业务用例。2.6.2.业务用例 1 2.6.2.1.业务用例场景用来描述业务用例在该业务的实际过程中是如何做的，是与用户就业务达成共识的重要制品。要求至少用活动图进行描述；如果该用例中主角间传递的信息很重要，要求同时用时序图表现该业务用例的执行过程。业务用例场景图应以

13、业务用例名命名。一个业务用例可能对应多个业务用例场景（正常执行、分支流程、异常流程等）。2.6.2.2.业务用例规约以文字的形式表述了业务用例的情况，包括用例名称、用例描述、执行者、前置条件、后置条件、主事件流描述、分支事件流描述、异常事件流描述、业务规则（交互规则）、涉及的业务实体等信息。业务用例规约一般以表格形式展现，要求每个用例必须提供业务用例规约。对于具有特别的非功能性需求的用例，应在业务用例规约表中添加一行说明非功能性需求；对于整个系统适用的非功能性需求应单独列出非功能性需求列表。表 11XX 业务用例规约业务用例名称用例描述执行者前置条件3.后置条件3.主过程描述3.分支过程描述异

14、常过程描述业务规则涉及的业务实体2.6.3.业务用例 2 2.6.3.1.业务用例场景用来描述业务用例在该业务的实际过程中是如何做的，是与用户就业务达成共识的重要制品。要求至少用活动图进行描述；如果该用例中主角间传递的信息很重要，要求同时用时序图表现该业务用例的执行过程。业务用例场景图应以业务用例名命名。一个业务用例可能对应多个业务用例场景（正常执行、分支流程、异常流程等）。2.6.3.2.业务用例规约以文字的形式表述了业务用例的情况，包括用例名称、用例描述、执行者、前置条件、后置条件、主事件流描述、分支事件流描述、异常事件流描述、业务规则（交互规则）、涉及的业务实体等信息。业务用例规约一般以

15、表格形式展现，要求每个用例必须提供业务用例规约。对于具有特别的非功能性需求的用例，应在业务用例规约表中添加一行说明非功能性需求；对于整个系统适用的非功能性需求应单独列出非功能性需求列表。表 12XX 业务用例规约业务用例名称用例描述执行者前置条件4.后置条件4.主过程描述4.分支过程描述异常过程描述业务规则涉及的业务实体2.7.业务对象分析业务对象分析的目的是建立业务对象模型，业务对象模型用于描述业务用例中涉及业务实体的基本信息及相互之间的关系。建立业务对象模型是通过分析业务用例，找出其中涉及的业务实体，来确定业务用例中各业务实体间关系的过程。此过程结束后应提供 业务对象关系图及业务对象属性表

16、。2.7.1.业务对象关系图业务对象关系图一般按业务用例绘制，对于关键业务领域中跨多个用例的业务对象也应提供该业务领域内全局的业务对象关系图。2.7.2.对象属性表业务对象属性表中应体现业务对象属性及内禀规则表 13XX 对象属性表业务对象名称业务对象描述属性名称类型精度业务含义说明业务规则2.8.业务规则整理业务规则可以分为交互规则、内禀规则和全局规则。此过程结束后应提供全局规则列表，更新业务对象属性表中的业务规则栏，更新业务用例规约中前置条件、后置条件及业务规则栏。其中：全局规则是指那些对于系统大部分业务或系统设计都起约束作用的那些规则，一般是与所有用例都相关，是跨用例的规则。一般我们将全

17、局规则以表格形式单独编制，放入业务模型中，作为业务模型的一个组成部分。全局规则应统一编码，故如需求分析由多人合作进行，应现在各自文档中采用临时编码进行引用，汇总全局规则后统一为其编码，再更新需求文档。全局规则列表表样如下：交互规则一般产生于业务用例场景中，在业务用例场景中，活动的转移、状态的变迁或是业务实体的交互都可能有一些限制条件，这些限制条件就是交互规则。由于交互规则依赖于业务用例场景，所以一般我们将交互规则写到用例规约中（包括入口条件、出口条件及业务规则三部分），如该规约中的交互规则可作用于多个业务用例，建议定义为全局规则，为其统一编号后，在业务用例规约中直接引用该业务规则的编号。内禀规

18、则是指那些业务实体本身具备的，并且不因为外部的交互而变化的规则。一般我们将内禀规则写到业务对象属性表中，可以不为其编号。表 14 全局规则列表编号名称描述标志日期备注注：编号格式应按要求，编号.后的数字表示该规则的版本，每次变更+1，在需要引用全局规则的文档中，直接引用主编号即可，默认将最大版本号的规则视为当前规则；名称的定义应具备唯一性，并容易理解；备注用于记录该规则发生变更的原因。2.9.非功能性需求整理非功能性需求是系统在满足客户工作所需要的各种功能的基础上，必须达到的系统目标，获取非功能性需求时应完整记录客户需求，以及系统是否对其进行相应和具体的响应方式，以便后续工作中对其进行确认和跟

19、踪。此过程结束后得到更新的非功能性需求列表。非功能性需求一般包括以下4个主要方面：可靠性（安全性、事务性和稳定性）、可用性（界面、操作习惯、效率、容错、帮助）、有效性（性能、可伸缩性、可扩展性）、可移植性。非功能性的需求获取可对照非功能性需求调研表中的说明（大象P267-P269）进行逐一收集，表样如下：表 15 非功能性需求列表需求描述是否响应不响应原因响应方式可靠性安全性系统数据的敏感程度系统运行于何种环境客户组织中的信息保密制度使用人员情况事务性系统业务交叉程度数据精确度要求业务是否在线系统集成情况系统是分布式还是集中式稳定性系统的服务能力要求用户的操作频率业务的及时性要求数据的重要程度

20、可用性界面客户的行业性质客户的企业文化客户的业务复杂程度使用人员的情况操作习惯客户常用/喜 爱 的系统风格效率客户对系统反应时间的要求容错被打断的工作是否要被记忆故障出现后，系统能否恢复已完成的工作帮助客户需要操作向导吗客户需要联机文档吗客户需要在线帮助吗客户的计算机操作水平有效性性能系统的平均访问量系统的峰值访问量系统的数据流量系统的并发要求硬件环境可伸缩性客户业务预期的扩张速度客户数据量的扩张速度使用人数的扩张速度可扩展性系统规模会持续扩大吗客户是否有长期系统建设的计划客户是否有升级系统的长期计划可移植性硬件环境客户当前的硬件环境客户是否有长期的硬件厂商合作伙伴客户的业务是否在快速增长软件

21、环境系统运行环境客户是否有长期的软件提供商自己是否有长期明确的技术路线2.10.业务包定义此过程应按实际业务情况使用包图为业务用例分包，使整个业务模型完整清晰。其中的包图在建模过程中主要用于信息分类，一般可以按业务领域、业务部门等进行分类，我们建议采用按业务领域对业务进行分类。3.系统分析系统模型是我们系统分析阶段最主要的工作成果，完整的系统模型包括以下内容：用例视图、用例场景、用例规约、用例实现视图、用例实现场景、业务规则实现规划和非功能性需求列表。要注意理解该阶段各制品间的关系，以及用例和业务用例间的关系。用例一般由业务用例的单个活动抽象出来，表现一次完整的人机交互过程；用例场景和用例规约

22、分别以图形和文字的形式表现了该过程；对于具有不同实现方式的用例，我们应给出用例实现视图，以及解释该用例实现视图的用例场景；业务规则和非功能性需求则是在用例之外对系统需求描述的有效补充。3.1.边界 1 3.1.1.业务用例 1 系统分析对业务用例进行系统分析的目的是得到系统用例。系统用例就是我们常说的用例，以后均用用例简称系统用例。用例主要是通过映射、抽象、合并、拆分、演绎等方式从业务用例中细化而来的。业务用例确定了需求范围，也就是旧世界有哪些东西；而用例则确定了系统范围，也就是新世界有哪些东西；需求范围不等于系统范围，对于那些不适合在计算机系统里运行的任务，就不能定义在系统范围之内；系统范围

23、也不是全部都从需求范围中来，比如那些系统管理类的任务。我们要找到用例，一般要先分析业务用例场景，从中抽取出那些可以在计算机系统中实现的单元来，对于原来业务用例场景中的某某做什么，可能就是用例的来源。在此过程中我们应记录每一个活动单元推导成用例的主要过程（包括方法与思路），以便在将来能够更好的追溯系统用例所来源的业务用例，也就是真正的业务目的。我们应注意了解注意业务用例与用例在粒度上的区别，业务用例一般表现一个完整的业务目的，而用例一般表现一次完整的人机交互过程。该过程完成后，应提供用例视图、用例场景、用例规约，有必要的情况下提供 用例实现视图 和用例实现场景。3.1.1.1.演化过程3.1.1

24、.2.系统用例视图给出系统用例视图，简要说明系统用例视图中每个用例的含义。系统用例视图应完整，覆盖该边界内全部的主角和系统用例，在必要的情况下，还应以不同的视角展现系统用例。3.1.1.3.系统用例 1 如系统用例有不同实现，应以用例实现视图表达用例的一种或多种实现方式，如和某人沟通可以通过见面、电话等各种方式，故一个用例可能对应多个用例实现。用例实现视图对于整个项目过程中的需求追溯和系统实现对需求覆盖的完整性验证具有重要的作用具有重要的作用。得到用例实现试图后，按照系统实现需求，分别对每个待实现的用例实现以用例实现场景和用例实现规约全面说明该用例。用例实现场景用于说明该用例是如何通过人机交互

25、来完成的，是与用户就如何操作达成的共识，也是制作系统原型的依据。用例实现规约与用例规约相同。3.1.1.3.1.用例场景描述主角是如何操作计算机来完成用例的。是与用户就系统如何做达成共识的重要制品。要求至少用活动图进行描述；如果该用例中主角间传递的信息很重要，要求同时用时序图表现该用例的执行过程。用例场景图应以用例名命名。一个用例可能对应多个用例场景。3.1.1.3.2.用例规约用例规约以文字的形式表述了用例的情况包括用例名称、用例描述、执行者、前置条件、后置条件、主事件流描述、分支事件流描述、异常事件流描述、业务规则（交互规则）、涉及的实体。用例规约一般以表格形式展现，要求每个用例必须提供用

26、例规约。对于具有特别的非功能性需求的用例，应在用例规约表中添加一行说明非功能性需求；对于整个系统适用的非功能性需求应单独列出非功能性需求列表。3.1.1.4.系统用例 2 如系统用例有不同实现，应以用例实现视图表达用例的一种或多种实现方式，如和某人沟通可以通过见面、电话等各种方式，故一个用例可能对应多个用例实现。用例实现视图对于整个项目过程中的需求追溯和系统实现对需求覆盖的完整性验证具有重要的作用具有重要的作用。得到用例实现试图后，按照系统实现需求，分别对每个待实现的用例实现以用例实现场景和用例实现规约全面说明该用例。用例实现场景用于说明该用例是如何通过人机交互来完成的，是与用户就如何操作达成

27、的共识，也是制作系统原型的依据。用例实现规约与用例规约相同。3.1.1.4.1.用例实现视图3.1.1.4.2.用例实现 1 场景3.1.1.4.3.用例实现 1 规约3.1.1.4.4.用例实现 2 场景3.1.1.4.5.用例实现 2 规约3.1.2.业务用例 2 系统分析对业务用例进行系统分析的目的是得到系统用例。系统用例就是我们常说的用例，以后均用用例简称系统用例。用例主要是通过映射、抽象、合并、拆分、演绎等方式从业务用例中细化而来的。业务用例确定了需求范围，也就是旧世界有哪些东西；而用例则确定了系统范围，也就是新世界有哪些东西；需求范围不等于系统范围，对于那些不适合在计算机系统里运行

28、的任务，就不能定义在系统范围之内；系统范围也不是全部都从需求范围中来，比如那些系统管理类的任务。我们要找到用例，一般要先分析业务用例场景，从中抽取出那些可以在计算机系统中实现的单元来，对于原来业务用例场景中的某某做什么，可能就是用例的来源。在此过程中我们应记录每一个活动单元推导成用例的主要过程（包括方法与思路），以便在将来能够更好的追溯系统用例所来源的业务用例，也就是真正的业务目的。我们应注意了解注意业务用例与用例在粒度上的区别，业务用例一般表现一个完整的业务目的，而用例一般表现一次完整的人机交互过程。该过程完成后，应提供用例视图、用例场景、用例规约，有必要的情况下提供 用例实现视图 和用例实

29、现场景。3.1.2.1.演化过程3.1.2.2.系统用例视图给出系统用例视图，简要说明系统用例视图中每个用例的含义。系统用例视图应完整，覆盖该边界内全部的主角和系统用例，在必要的情况下，还应以不同的视角展现系统用例。3.1.2.3.系统用例 1 如系统用例有不同实现，应以用例实现视图表达用例的一种或多种实现方式，如和某人沟通可以通过见面、电话等各种方式，故一个用例可能对应多个用例实现。用例实现视图对于整个项目过程中的需求追溯和系统实现对需求覆盖的完整性验证具有重要的作用具有重要的作用。得到用例实现试图后，按照系统实现需求，分别对每个待实现的用例实现以用例实现场景和用例实现规约全面说明该用例。用

30、例实现场景用于说明该用例是如何通过人机交互来完成的，是与用户就如何操作达成的共识，也是制作系统原型的依据。用例实现规约与用例规约相同。3.1.2.3.1.用例场景描述主角是如何操作计算机来完成用例的。是与用户就系统如何做达成共识的重要制品。要求至少用活动图进行描述；如果该用例中主角间传递的信息很重要，要求同时用时序图表现该用例的执行过程。用例场景图应以用例名命名。一个用例可能对应多个用例场景。3.1.2.3.2.用例规约用例规约以文字的形式表述了用例的情况包括用例名称、用例描述、执行者、前置条件、后置条件、主事件流描述、分支事件流描述、异常事件流描述、业务规则（交互规则）、涉及的实体。用例规约

31、一般以表格形式展现，要求每个用例必须提供用例规约。对于具有特别的非功能性需求的用例，应在用例规约表中添加一行说明非功能性需求；对于整个系统适用的非功能性需求应单独列出非功能性需求列表。3.2.边界 2 3.2.1.业务用例 1 系统分析对业务用例进行系统分析的目的是得到系统用例。系统用例就是我们常说的用例，以后均用用例简称系统用例。用例主要是通过映射、抽象、合并、拆分、演绎等方式从业务用例中细化而来的。业务用例确定了需求范围，也就是旧世界有哪些东西；而用例则确定了系统范围，也就是新世界有哪些东西；需求范围不等于系统范围，对于那些不适合在计算机系统里运行的任务，就不能定义在系统范围之内；系统范围

32、也不是全部都从需求范围中来，比如那些系统管理类的任务。我们要找到用例，一般要先分析业务用例场景，从中抽取出那些可以在计算机系统中实现的单元来，对于原来业务用例场景中的某某做什么，可能就是用例的来源。在此过程中我们应记录每一个活动单元推导成用例的主要过程（包括方法与思路），以便在将来能够更好的追溯系统用例所来源的业务用例，也就是真正的业务目的。我们应注意了解注意业务用例与用例在粒度上的区别，业务用例一般表现一个完整的业务目的，而用例一般表现一次完整的人机交互过程。该过程完成后，应提供用例视图、用例场景、用例规约，有必要的情况下提供 用例实现视图 和用例实现场景。3.2.1.1.演化过程3.2.1

33、.2.系统用例视图给出系统用例视图，简要说明系统用例视图中每个用例的含义。系统用例视图应完整，覆盖该边界内全部的主角和系统用例，在必要的情况下，还应以不同的视角展现系统用例。3.2.1.3.系统用例 1 如系统用例有不同实现，应以用例实现视图表达用例的一种或多种实现方式，如和某人沟通可以通过见面、电话等各种方式，故一个用例可能对应多个用例实现。用例实现视图对于整个项目过程中的需求追溯和系统实现对需求覆盖的完整性验证具有重要的作用具有重要的作用。得到用例实现试图后，按照系统实现需求，分别对每个待实现的用例实现以用例实现场景和用例实现规约全面说明该用例。用例实现场景用于说明该用例是如何通过人机交互

34、来完成的，是与用户就如何操作达成的共识，也是制作系统原型的依据。用例实现规约与用例规约相同。3.2.1.3.1.用例场景描述主角是如何操作计算机来完成用例的。是与用户就系统如何做达成共识的重要制品。要求至少用活动图进行描述；如果该用例中主角间传递的信息很重要，要求同时用时序图表现该用例的执行过程。用例场景图应以用例名命名。一个用例可能对应多个用例场景。3.2.1.3.2.用例规约用例规约以文字的形式表述了用例的情况包括用例名称、用例描述、执行者、前置条件、后置条件、主事件流描述、分支事件流描述、异常事件流描述、业务规则（交互规则）、涉及的实体。用例规约一般以表格形式展现，要求每个用例必须提供用

35、例规约。对于具有特别的非功能性需求的用例，应在用例规约表中添加一行说明非功能性需求；对于整个系统适用的非功能性需求应单独列出非功能性需求列表。3.2.1.4.系统用例 2 如系统用例有不同实现，应以用例实现视图表达用例的一种或多种实现方式，如和某人沟通可以通过见面、电话等各种方式，故一个用例可能对应多个用例实现。用例实现视图对于整个项目过程中的需求追溯和系统实现对需求覆盖的完整性验证具有重要的作用具有重要的作用。得到用例实现试图后，按照系统实现需求，分别对每个待实现的用例实现以用例实现场景和用例实现规约全面说明该用例。用例实现场景用于说明该用例是如何通过人机交互来完成的，是与用户就如何操作达成

36、的共识，也是制作系统原型的依据。用例实现规约与用例规约相同。3.2.1.4.1.用例实现视图3.2.1.4.2.用例实现 1 场景3.2.1.4.3.用例实现 1 规约3.2.1.4.4.用例实现 2 场景3.2.1.4.5.用例实现 2 规约3.2.2.业务用例 2 系统分析对业务用例进行系统分析的目的是得到系统用例。系统用例就是我们常说的用例，以后均用用例简称系统用例。用例主要是通过映射、抽象、合并、拆分、演绎等方式从业务用例中细化而来的。业务用例确定了需求范围，也就是旧世界有哪些东西；而用例则确定了系统范围，也就是新世界有哪些东西；需求范围不等于系统范围，对于那些不适合在计算机系统里运行

37、的任务，就不能定义在系统范围之内；系统范围也不是全部都从需求范围中来，比如那些系统管理类的任务。我们要找到用例，一般要先分析业务用例场景，从中抽取出那些可以在计算机系统中实现的单元来，对于原来业务用例场景中的某某做什么，可能就是用例的来源。在此过程中我们应记录每一个活动单元推导成用例的主要过程（包括方法与思路），以便在将来能够更好的追溯系统用例所来源的业务用例，也就是真正的业务目的。我们应注意了解注意业务用例与用例在粒度上的区别，业务用例一般表现一个完整的业务目的，而用例一般表现一次完整的人机交互过程。该过程完成后，应提供用例视图、用例场景、用例规约，有必要的情况下提供 用例实现视图 和用例实

38、现场景。3.2.2.1.演化过程3.2.2.2.系统用例视图给出系统用例视图，简要说明系统用例视图中每个用例的含义。系统用例视图应完整，覆盖该边界内全部的主角和系统用例，在必要的情况下，还应以不同的视角展现系统用例。3.2.2.3.系统用例 1 如系统用例有不同实现，应以用例实现视图表达用例的一种或多种实现方式，如和某人沟通可以通过见面、电话等各种方式，故一个用例可能对应多个用例实现。用例实现视图对于整个项目过程中的需求追溯和系统实现对需求覆盖的完整性验证具有重要的作用具有重要的作用。得到用例实现试图后，按照系统实现需求，分别对每个待实现的用例实现以用例实现场景和用例实现规约全面说明该用例。用

39、例实现场景用于说明该用例是如何通过人机交互来完成的，是与用户就如何操作达成的共识，也是制作系统原型的依据。用例实现规约与用例规约相同。3.2.2.3.1.用例场景描述主角是如何操作计算机来完成用例的。是与用户就系统如何做达成共识的重要制品。要求至少用活动图进行描述；如果该用例中主角间传递的信息很重要，要求同时用时序图表现该用例的执行过程。用例场景图应以用例名命名。一个用例可能对应多个用例场景。3.2.2.3.2.用例规约用例规约以文字的形式表述了用例的情况包括用例名称、用例描述、执行者、前置条件、后置条件、主事件流描述、分支事件流描述、异常事件流描述、业务规则（交互规则）、涉及的实体。用例规约

40、一般以表格形式展现，要求每个用例必须提供用例规约。对于具有特别的非功能性需求的用例，应在用例规约表中添加一行说明非功能性需求；对于整个系统适用的非功能性需求应单独列出非功能性需求列表。3.3.确定业务规则该阶段的任务是确定哪些业务规则可以实现，并规划各类业务的实现方式，其中：对于全局规则一般根据规则要求从软件架构角度提出统一的规则解决方案，使需要遵循该规则的系统用例对于该规则的遵守可以通过继承某个超类、实现某些接口的方法或填写某些配置文件的这些统一的方式实现。所以这些业务规则可以不抽象为单独的系统用例，而使其混杂在具体业务当中；全局业务规则的实现方式应在系统分析阶段确立，比如通过架构实现或在业

41、务中直接实现，但具体的设计工作应在系统设计阶段通过对软件架构的设计或对业务逻辑的实现设计完成。对于交互规则一般牵涉到一个业务用例中的不同业务实体乃至多个业务用例间的相互调用，对于这种可能跨越用例、甚至跨越部门的交互规则，我们可以为之设计统一的规则管理库，使需要交互的不同业务实体间的交互，通过规则管理库中具体规则类进行处理，需要引用规则的用例只需传入规则ID，就可得到规则执行结果，这样就解耦了相对独立的业务实体或业务模块。规则的变化也只需更新规则管理库中的具体规则类，而不需变更具体的用例实现；交互规则的实现方式应在系统分析阶段确立，比如通过规则管理库实现或在业务中直接实现，但具体的设计工作应在系

42、统设计阶段通过对规则管理库的设计或对业务逻辑的实现设计完成。对于内禀规则一般只是业务实体自身的约束，我们可以在设计该业务对象实现方式的同时，以单独的类、接口或方法处理该业务对象的内禀规则。建议为业务对象设计统一的内禀原则处理接口，有内禀规则处理要求的对象实现该接口，具体的实现由程序员根据具体规则要求实现。内禀规则的实现方式以及具体设计应在系统设计阶段明确，具体实现则可在实现阶段完成。该阶段完成后，应输出 业务规则实现规划表，表样如下：表 16 业务规则实现规划表全局规则编号实现方式（架构、规则管理库、统一接口、业务逻辑）设计人版本号(.前的X指大版本号，在实现方式有变更时对其进行更新；.后的x

43、指小版本号，在实现方式没有变更，具体的实现上有变更时对其进行更新)3.4.确定非功能性需求对非功能性需求调查结果的描述应包含对该要求的描述以及客户实现该要求的方式，如必须靠硬件实现，还是必须靠软件实现，或是必须依赖硬、软件结合才能够实现。其中响应方式包括不支持、硬件架构支持、软件架构支持、特别处理等。表 17 非功能性需求列表需求描述是否响应不响应原因响应方式可靠性安全性系统数据的敏感程度系统运行于何种环境客户组织中的信息保密制度使用人员情况事务性系统业务交叉程度数据精确度要求业务是否在线系统集成情况系统是分布式还是集中式稳定性系统的服务能力要求用户的操作频率业务的及时性要求数据的重要程度界面

44、客户的行业性质客户的企业文化客户的业务复杂程度使用人员的情况操作习惯客户常用/喜 爱 的系统风格效率客户对系统反应时间的要求容错被打断的工作是否要被记忆故障出现后，系统能否恢复已完成的工作帮助客户需要操作向导吗客户需要联机文档吗客户需要在线帮助吗客户的计算机操作水平有效性有效性性能系统的平均访问量系统的峰值访问量系统的数据流量系统的兵法要求硬件环境可伸缩性客户业务预期的扩张速度客户数据量的扩张速度使用人数的扩张速度可扩展性系统规模会持续扩大吗客户是否有长期系统建设的计划客户是否有升级系统的长期计划可移植性硬件环境客户当前的硬件环境客户是否有长期的硬件厂商合作伙伴客户的业务是否在快速增长软件环境系统运行环境客户是否有长期的软件提供商自己是否有长期明确的技术路线附件请附需求说明所用到的相关原始材料