本文将与《UML系统分析与设计02－用例图和活动图（上）》、《UML系统分析与设计02－用例图和活动图（下）》共同组成简单的基于UML技术的软件需求分析说明并对其分析结果进行输出，后续将继续对基于UML技术的软件设计进行总结，以抛砖引玉。
《软件需求分析说明书》虽然不是UML体系的内容，但作为使用UML进行系统分析与设计的一项重要输出，我想也很有必要进行简单的说明。由于我所在的公司本文档标记为“保密”，也就无法在此共享出来给大家做个参考。
但话又说回来，我所在的公司以前也是没有这个文档的，至少在我入职时是没有的，后来应该是参考了别的人模板，结合自身的特点作了一定的更改，与网上公开的模板也是大同小异。有兴趣的可以参考一下百度文库中的“系统需求分析说明书实例模板”。（我并没有认真分析其内容，只是简易的看了下格式）
[注：如果下载不了的，可以通过工具“iDocDown”来下载百度文库中的文档。当然，对下载“系统需求分析说明书实例模板”文档带的任何责任，本人概不负责。]
本着学习与交流的目的我把我所了解的文档目录共享给大家，目录大体分分三部分：
1）：前面部分
前部分的内容大多可以从产品的《可行性分析报告》和《产品需求规格说明书》中获得，不做详述。
2）：中间部分
中间部分是本说明书的重点，主要是对业务/需求进行分析后的文档输出，是本文的重点。
3）：后面部分
最后部分主要是从总体上的要求，比如：与外部系统的集成与合作，对产品的后继开发升级、扩展等进行了一些规划。
4）：特别说明
在本文档中，有很多类似“约束”、“限制”、“环境”等字眼，后继一般会以“非功能性需求”来进行验证，很多时候销售为了签单往往在前期什么都答应，不以为然。比如响应时间、并发数据、数据量等，但对开发来说却不可大意，我曾经就在并发数上吃过亏。
[注意：可性行分析和产品规格说明书，都是基于产品的。而系统需求分析说明书是基于当前项目的，产品需求可能会分成若干个项目，分批次分阶段来进行（我们有时会忽悠用户说：在第二期为您提供。其实有钱才有第二期，没钱就是遥遥无期）。严格来说两个文档的目标，用户等可能不完全一致，可以简单的认为项目的需求小于等于产品需求]
从目录中我们会发现：其实前部分和后部分在以往的文档中都基本上已经提及，所以直接拷贝过来整理一下即可，也不是重点。中间部分的“用例描述”就成了我们的本次说明的重点，主要用于对功能性需求进行描述。也就是我们前几篇文章中所讲的需求分析所生成结果的文档输出、即《软件需求分析说明书》。
《软件需求分析说明书》的格式，以Word格式为例常见的有两种。经我在网上查找，基本上类似如下下：
1）： 表格方式
|
用例1 |
用例名称 |
||
|
描述 |
该用例的详细解释 |
||
|
前提 |
要使该用例能够工作，系统需要处于什么样条件下，如商店要卖东西必须先开张 |
||
|
触发条件 |
是什么导致这个用例开始工作？如顾客需要商品，并进入商店。 |
||
|
成功 |
用例完成后系统处于什么状态？如顾客拥有了所需产品并感到愉快，货币保存在出纳机中，等待下一位顾客。 |
||
|
中止 |
如果用例被放弃了，会发生哪些情况？如，如果顾客放下购物篮没有买任何东西离开，需要有人看到这些并把货物放回原处。 |
||
|
参与者 |
主要的 |
谁起主导作用？如顾客和收款员？ |
|
|
从属的 |
谁起次要作用？如店员？ |
||
|
过程 |
步骤 |
活动名 |
描述 |
|
|
1 |
|
|
|
|
2 |
|
|
|
|
3 |
|
|
|
|
|
||
|
|
|
||
|
变更 |
步骤 |
活动名 |
描述 |
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
异常 |
步骤 |
活动名 |
描述 |
|
|
|
||
|
|
|
||
|
|
|
||
2）： 编号方式
- 用例名
1.1 前置条件
1.2 后置条件
1.3 扩充点
1.4 事件流
1.4.1 基流
1.4.2 分支流
S-1:
S-2:
S-n:
1.4.3 替代流
E-1:
E-2:
E-n:
2．用例名2（略）
我比较喜欢第二种缩进方式，因为活动图的步骤是不定的，我不喜欢总去添加和删除网格，麻烦。当然网格看起来比较一目了然。废话说了一堆，直接来个例子以作参考吧 (*^_^*)
－－－－－－－－－－－－－－－－－－－－－－－－－示例－－－－－－－－－－－－－－－－－－－－－－－－－
1. 唱片资料管理
1、 用例图
2、 用例描述：
管理唱片资料用例，主要用于管理员对唱片资料信息进行“新增”、“修改”和“删除”操作，方便管理员对唱片资料进行及时创建和更新。（此处可以更详细一些）。
管理员在“基础数据管理”的“唱片资料管理”模块来实施本用例。主要用于维护唱片资料的基础信息、库存信息等。
该用例包括三个具体的用例：
创建唱片资料：管理员输入唱片的基础信息、库存信息，并创建数据信息。
修改唱片资料：管理员修改唱片的基础信息、库存信息。随后进行保存或取消恢复操作。
删除唱片资料：管理员对所选的唱片资料信息进行删除。
3、前置条件：
只有具有管理员身份的用户才具有此功能的操作权限。
4、后置条件：
如用例成功，则用例对应的唱片信息及关联信息将会被新增到系统中、或被修改更新、或被删除；如不成功，则系统状态不变化。
5、参与者：
管理员
6、基本事件流：
当管理员需要新增、修改、删除唱片资料信息时，用例启动。
系统呈现管理员可以执行的活动（新增唱片资料、修改唱片资料、删除唱片资料）供选择。
如果所选活动是“新增唱片资料”，则执行分支流S-1：新增唱片资料。
如果所选活动是“修改唱片资料”，则执行分支流S-2：修改唱片资料。
如果所选活动是“删除唱片资料”，则执行分支流S-4：删除唱片资料。
7、分支流：
S-1：新增唱片资料
(1) 用户选择新增操作
(2) 系统提供新增唱片资料的信息编辑界面，要求用户指定唱片名称、出版社、出版时间、现有库存进行录入。
[注：这些信息只为代表，并不一定适应现实]
(3) 用户录入完唱片资料信息后提交
(4) 系统校验用户提交的信息（E-1）
(5) 系统保存新唱片资料信息内容
S-2：修改唱片资料
(1) 用户选择修改操作
(2) 系统显示唱片资料列表并要求用户选择要修改的唱片资料
(3) 用户选择一个要修改的唱片资料
(4) 系统提供选中唱片资料的信息编辑界面
(5) 用户编辑唱片资料基本信息后提交
(6) 系统校验用户提交的信息（E-2）
(7) 系统保存修改后的唱片资料信息内容
S-3：删除唱片资料
(1) 用户选择删除操作
(2) 系统显示晶片资料列表并要求用户选择将要被删除的唱片资料项
(3) 用户选择唱片资料并确认删除唱片资料
(4) 系统校验用户提交的信息（E-3）
(5) 系统删除唱片资料的信息
8、替代流：
E-1:用户提交的唱片资料信息与系统中的数据有冲突，系统显示失败的信息，用户可以重新输入或终止用例。
E-2:用户提交编辑后的唱片资料信息与系统中的数据有冲突，系统显示修改失败的信息，用户可以刷新唱片资料列表显示重新开始修改或终止用例。
E-3:用户选择的删除操作不可行，系统显示失败信息，返回并刷新唱片资料列表。或提示警告信息，用户可以确认或取消。
9、扩充点
无；
[注：此处用于描述“extend”的用例说明]
10、活动图：
[注意：好的用例分解，其优点不仅体现在技术方面，对项目管理也是很有帮助的。特别是在进行任务WBS分解及任务计划制定时，会表现的一目了然。]
－－－－－－－－－－－－－－－－－－－－－－－－－示例完－－－－－－－－－－－－－－－－－－－－－－－－－
到目前为此大部分基于UML的工作是对需求进行分析，从而进行一定的筛选和归纳，主要面对的对象是用户、产品经理等。在整个过程中技术人员可能更多作用的是明确用例的可行性，并协助完成对产品需求到系统需求的转换（比如“店长可以删除唱片资料，而店员不可以”进行分析后转化成“基于角色的权限管理”）从而形成这个《软件需求分析说明书》。
《软件需求分析说明书》的一个重要作用是把产品需求或用户需求转变成了系统需求，成为后继项目开发的一个基线。按“项目管理”的说法是明确了本项目的“项目范围”。
当然，在很多的项目中也会把“系统的典型UI风格”、“操作文档”、甚至“简单的Demo模型”等作为附件与本说明书一起提供，为相关的“评审”提供更直观的表述，为后继开发提供更准确的指导。
[补充：软件需求分析说明书有时也称作：系统需求分析说明书或系统软件需求分析说明书]