画图理解软件工程-进行详细的需求分析（二）
首先,我们看下从用户那里获取到整理成SRS文档的过程 
我们怎么从用户那里获取详细需求呢
可以从下面这一些列的问号入手
- 系统将要做什么？
- 系统什么时候做？
- 有多种操作模式吗？
- 必须执行什么种类的计算和数据转换？
- 对可能刺激合适的反应是什么？
- 输入、输出系统的格式是什么？
- 在任何时间都必须保留任何数据吗？
- 设备安放在哪？
- 在一个地还是多个地方？
- 是否有任何环境限制？
- 是否对系统的设计规模有限制？
- 是否因为现有的软件构建对程序设计的语言有所限制？
- 输入是来自一个还是多个其他系统？
- 输出是否传送到一个或多个其他系统？
- 输入输出的数据格式是否时预先规定？
- 谁会使用系统？
- 将会有几种类型的用户？
- 每类用户的技术水平？
- 构建系统需要哪些材料、人员或其他资源？
- 开发人员需要具备什么样的技能？
- 需要多少种文档?
- 文档是联机的，还是印刷，还是两种都要?
- 每种文档的读者?
- 有没有执行速度、响应时间，吞吐量的约束?
- 使用什么方法测试响应时间?
- 多少数据流经系统?
- 数据发送接收的时间间隔?
- 每类用户需要的培训?
- 就一个系统而言，如何防止用户误用系统?
- 必须控制对系统或者信息的访问吗?
- 应该将每个用户的数据和其他用户的数据隔开吗?
- 应该将用户的程序和其他程序以及操作系统隔开吗?
- 要采取什么措施防止蓄意破坏?
- 系统崩溃后重新启动的时间间隔?
- 系统数据多久备份一次?
- 备份的副本存放在不同的地方吗?
- 维护仅仅时修改系统，或者是改进系统?
- 从一个平台向另一个系统一直容易吗?
- 数据计算的精确度有多高?
- 计算精确到什么程度?
- 开发时间表?
- 资金限制?
然后再来看看规范的SRS文档格式
XX 软件需求规格说明书
修订记录
日期 修订
版本 CR号 修改
章节 修改描述 作者
2001-06-08 1.00 初稿完成
作者名
yyyy-mm-dd 1.01 xxx x.x.x; y.y.y I. 修改XXX
1. Xxx
2. Xxx
3. ... 作者名
xxx x.x.x; y.y.y I. 修改XXX
1. Xxx
2. Xxx
3. ... 作者名
关键词：能够体现文档描述内容主要方面的词汇。
摘 要：
缩略语清单：对本文所用缩略语进行说明，要求提供每个缩略语的英文全名和中
文解释。
缩略语 英文全名 中文解释
目 录
1 简介 3
1.1 目的 3
1.2 范围 3
2 总体概述 3
2.1 软件概述 3
2.1.1 项目介绍 3
2.1.2 产品环境介绍 3
2.2 软件功能 4
2.3 用户特征 4
2.4 假设和依赖关系 4
3 具体需求 4
3.1 功能需求 4
3.1.1 功能需求1 5
3.2 性能需求 6
3.2.1 性能需求1 6
3.3 外部接口需求 7
3.3.1 用户接口 7
3.3.2 软件接口 7
3.3.3 硬件接口 8
3.3.4 通讯接口 8
4 总体设计约束 8
4.1 标准符合性 8
4.2 硬件约束 8
4.3 技术限制 9
5 软件质量特性 9
6 依赖关系 9
7 其他需求 9
7.1 数据库 9
7.2 操作 9
7.3 本地化 9
8 附录 9
8.1 附录A 需求建模 9
8.1.1 数据流图 10
8.1.2 数据字典 10
8.2 附录B 参考资料清单： 10
8.2 附录B 10
1 简介
1.1 目的
这部分要描述文档的目的。应该指明读者。说明本需求文档描述了哪个产品的软件需求。
1.2 范围
本节应描述文档所包括和不包括的内容。
2 总体概述
本节描述影响产品和产品需求的一般因素。由以下4个部分构成。 有一点需说明的是本节不描述具体的需求，只是使那些将要描述的具体需求更易于理解。
2.1 软件概述
2.1.1 项目介绍
描述本软件需求所描述的项目的背景。例如：本项目是一系列版本中的一个，或者是替代某个已经存在的系统，还是一个新的独立的项目。
2.1.2 产品环境介绍
描述的是本产品与其它产品或项目所组成的整体环境。
1.如果本产品是独立的并完全自我包含，在此说明这一点。
2.如果SRS定义的产品是更大的系统或项目的组件（此种情形经常发生），那么应：
A. 描述此大系统或项目每个组件的功能，并且标识接口。
B. 确定本软件产品主要外部接口。（ 注意：在此部分并不进行这些接口的详细描述；对这些接口的详细描述在SRS的其它 部分提供。）
C. 描述相关产品硬件和所使用的外部设备。（ 注意： 这只是概述性描述。）
通过方块图来描述大系统或项目的主要组件，互连性以及外部接口将是非常有帮助的。本部分不应提出一个具体的设计解决方案或对解决方案的具体设计约束（具体设计约束将在具体需求章节中描述）。本部分内容是产生设计约束的基础。
2.2 软件功能
概述软件的必须实现的和通过用户操作实现的主要功能。这里只需要进行简要描述（例如目录列表），详细描述在详细需求部分描述。对需求功能进行组织，以便于读者理解，并能指导后续的设计和测试。可以用图表来表示主要需求群组之间的关系，例如：高层的数据流图，面向对象的分析等。
有时此部分所要求的功能概述可以从分配具体功能给此软件产品的更高层规格（如果存在的话）直接引用。
本节不应描述具体需求。但本节内容是具体需求章节的基础。
2.3 用户特征
列出对用户或系统操作者的要求，如：经验，能力，角色等。
本节不应描述具体需求。但本节内容是具体需求章节的基础。
2.4 假设和依赖关系
列出可能影响SRS中需求的所有的假设因素（与已知事实相对而言），包括准备使用的第三方或商业组件，操作和开发环境的问题约束等。如果上述假设不正确、没有被告知或者改变了都将对项目产生影响。列出项目对外部条件的依赖，例如重用其他项目的模块等。如果在其他文档（例如项目计划或范围文档等）里已经描述了，在这里可以不用描述。
3 具体需求
在每一条需求描述中重复下列部分
3.1 功能需求
本子章节应描述软件产品的输入怎样被转换成输出。它描述了软件必须执行的基本动作。
对每一类功能或有时对每一个单独的功能，必须描述输入、处理、输出方面的需求。这些通常以下面四个子段落来组织：
3.1.1 功能需求1
用需求编号加上简短词汇做为功能需求名，不要用“功能需求（1）”作为功能名，例如：R.INTF.CALC.001 计算表达式
R.INTF.CALC.002 打印
需求编号规则按照软件需求管理规程(REP01)进行
1. 介绍
逐条列出与本特性相关的功能需求。包括项目如何响应预期的错误输入，非法条件和无效输入。需求应该简明，完整，不含糊，可验证，必要的。 当需要的信息不确定的时候使用“待定”。
2. 输入
本子段落应包含下列内容：
A. 对该功能所有输入数据的详细描述，包括：
输入来源
数量
度量单位
时间要求
包含精度和容忍度的有效输入范围
B. 在适当的地方提供的对接口规格或接口控制文档的参考。
3. 处理
本子段落应描述对输入数据所执行的所有操作和如何获得输出的过程。这包括下列规格：
A. 输入数据的有效性检测。
B. 操作的确切次序，包括各事件的时序。
C. 对异常情况的回应，例如：
溢出
通信失败
错误处理
D. 用于把系统输入转换到相应输出的任何方法（诸如方程式，数学算法，逻辑操作）。例如，这可能描述下列方面：
对工资单里代扣所得税的计算公式。
用于气象预报的气象模型。
E. 对输出数据的有效性检测。
4. 输出
本子段落应包含：
A. 对该功能所有输出数据的详细描述，这个描述包括：
输出的到何处（如打印机，文件）
数量
度量单位
时序
包含精确度和容忍度的有效输出范围
对非法值的处理
错误消息
B. 在适当的地方提供对接口规格或接口控制文档的参考。
此外，对那些需求集中在输入/输出行为的系统，SRS应描述所有重要的输入/输出行为及输入输出对的次序。对一个需要记忆其行为以根据输入和过去的行为进行反应的系统，输入输出对的次序是要求的；这种功能行为就类似于有限状态机。
3.2 性能需求
如果有性能方面的需求，在这里列出并解释他们的原理。以帮助开发者理解意图以做出正确的设计选择。在实时系统中的时序关系。保证需求尽可能的详细而精确。
3.2.1 性能需求1
本子章节应从整体上描述静态和动态的量化的对软件（或人与软件交互）的需求。
静态的量化需求可能包括：
A. 支持的终端数目。
B. 支持的同时使用的用户数目。
C.处理的文件和记录的数目。
D.表和文件的大小。
动态的量化需求可能包括:
A. 在正常和峰值工作量条件下特定时间段（如一小时）
B. 处理的事务和任务的数目以及数据量。
所有的这些需求应以可测量的术语进行描述，例如所有的操作应在1秒内被处理完成，而不是描述成操作员不必等待操作的完成。
注意： 用于一个具体功能的量化限制通常在该功能的处理子章节中描述。
3.3 外部接口需求
3.3.1 用户接口
详细描述系统与用户之间的接口
这应描述下述内容：
A. 对每种人机界面，软件所必须支持的特性。例如，如果系统用户通过一个显示终端进行操作，那么应包含下述内容：
要求的屏幕格式
页面规划及报告或菜单的内容
输入和输出的相关时序
一些组合功能键的用法
B. 与系统用户接口使用相关的所有方面。这可能只是一个简单的关于系统怎样展示给用户而该做什么和不该做什么的列表。例如提供关于长或短错误消息选项。和所有其它需求一样，这些需求也应能被检验，例如，四级打字员经一小时的培训后能在Z分钟内完成功能X，而不是一个打字员能完成功能X。
3.3.2 软件接口
详细描述与其他系统 /模块 /项目之间的接口
在此应描述如何使用其它（必需的）软件产品（例如，数据管理系统，操作系统，或算法工具包），以及与其它应用系统的接口（例如，协议处理系统和数据库管理系统之间的接口）。
对每个必需的软件产品，应提供下列信息：
A. 名字
B. 助记符
C. 版本号
D. 来源
对每个接口，本部分应：
A . 讨论与本软件产品相关的接口软件的目的。
B. 按消息/函数内容和格式定义接口。如果接口已在其它文档中很清楚地描述，就没有必要在这儿进行详细描述，但需说明应参考的文档。
3.3.3 硬件接口
详细描述与硬件的接口
在此描述软件产品和系统硬件组件之间接口的逻辑特征，也包括支持哪些设备、怎样支持这些设备和协议等。
按软/硬件协议内容和格式定义接口。如果接口已在其它文档中很清楚地描述，就没有必要在这儿进行详细描述，但需说明应参考的文档。
3.3.4 通讯接口
详细描述通讯接口，如本地网络协议等。
按消息/函数内容和格式定义接口。如果接口已在其它文档中很清楚地描述，就没有必要在这儿进行详细描述，但需说明应参考的文档。
4 总体设计约束
描述可能限制开发人员选择的事项。
4.1 标准符合性
本节详细说明需求所采用的标准或规范的来源。如果项目采用了国际标准，应该说明国际标准及项目与标准的偏离情况。
4.2 硬件约束
本节包括软件在不同的硬件平台运行的需求，如时间相关的约束，内存方面的约束等。
4.3 技术限制
本节包括对使用特定技术的限制，包括接口，数据库，并行操作，通讯协议，设计约定，编程规范等。
5 软件质量特性
详细说明项目任何其他的质量特性。该特性对客户和开发者都非常重要。考虑的方面包括：适应性，可用性，正确性，灵活性，交互工作能力，可维护性，可移植性，可靠性，可重用性，鲁棒性，可测试性和可用性等。定量的详细描述这些特性，尽可能的可验证。对不同属性之间的重要性加以阐述，如：易用性比易学性更重要。
每一个属性单独使用一个小节描述，可根据需要进行增减，如增加可维护性小节等。
6 依赖关系
解释每一条需求的内部和外部依赖关系。
7 其他需求
使用适当的章节，详细说明任何其他客户需求，包括数据库，编码需求，错误处理，测试需求等。下面仅列出了少量样例，你可以删除和增加项目。
7.1 数据库
详细说明项目相关的数据库方面的需求。
7.2 操作
详细说明用户通常的和特殊的操作需求。
7.3 本地化
描述支持多语种的需求。
8 附录
8.1 附录A 需求建模
8.1.1 数据流图
1. 顶层数据流图
在这里画出顶层数据流图
2. 0层数据流图
在这里画出0层数据流图
3. 1层数据流图
在这里画出1层数据流图
8.1.2 数据字典
1. 数据流说明
1） 数据流1名称
与数据流图中的名称一致，采用数据描述符号说明数据流的内容
2） 数据流2名称
与数据流图中的名称一致，采用数据描述符号说明数据流的内容
2. 数据存储说明
1） 数据存储1名称
与数据流图中的名称一致，采用数据描述符号说明数据流的内容，另外还需描述数据排列方式
2） 数据存储2名称
与数据流图中的名称一致，采用数据描述符号说明数据流的内容，另外还需描述数据排列方式
3. 加工说明
1） 加工1名称
采用自然语言，判断表/判断树，伪码的形式描述对数据流进行处理的过程
2） 加工2名称
采用自然语言，判断表/判断树，伪码的形式描述对数据流进行处理的过程
8.2 附录B 参考资料清单：
Please list referred literature and related documents, format:
请罗列本文档所参考的有关参考文献和相关文档，格式如下：
Author + book name (or magazine, literature, document) + publishing company (or issue No., volume No., internal documentation ID) + publishing date + start and end page number,
作者＋书名（或杂志、文献、文档）＋出版社（或期号、卷号、公司文档编号）＋出版日期+起止页码
examples:
例如：
[1] D. B. Leeson, “A Simple Model of Feedback Oscillator Noise Spectrum,” Proc. IEEE, pp329-330, February 1966 （英文文章格式）
[2] D. Wolaver, Phase-Locked Loop Circuit Design, Prentice Hall, New Jersey,1991 （英文书籍格式）
[3] XXX，SDXXX用户手册 V1.1，基础部文档室，2001/4/26