亿阳信通
文档编号：BSS-项目标识_P_SRS_版本号
文档状态：正式版V1.0
版权属于亿阳信通所有，无亿阳信通的书面同意，任何个人或组织无权拷贝。
需求分析说明书审批表
项目: 亿阳信通****项目
文档版本:正式版V1.0
程序对之进行控制，得到CCB（管理控制委员会）确认的最终形式就是在本签批页上作出书面的签字认可。只有经过了这种正式的批准，才能启动软件设计等一系列工作。 //CCB的成员通常包括以上角色，此处应当依据项目的实际执行情况对之进行裁剪。
文档修改记录
容差异，使读者能够快速、便捷地查看本版本的焦点内容。
目 录
需求分析说明书审批表 ................................................................................................................... 1 文档修改记录................................................................................................................................... 2 1
引言....................................................................................................................................... 1-1 1.1 1.2 1.3 1.4 1.5 2
目的 ............................................................................................................................... 1-1 文档约定 ....................................................................................................................... 1-1 预期读者和阅读建议 ................................................................................................... 1-2 产品范围 ....................................................................................................................... 1-2 参考文献 ....................................................................................................................... 1-2
系统概述 ............................................................................................................................... 2-4 2.1 2.2 2.3 2.4
任务背景 ....................................................................................................................... 2-4 产品功能 ....................................................................................................................... 2-4 用户特点 ....................................................................................................................... 2-5 运行环境 ....................................................................................................................... 2-5
2.4.1 2.4.2 2.4.3 2.5 2.6 3
硬件平台 ............................................................................................................... 2-5 支持软件 ............................................................................................................... 2-5 通信环境 ............................................................................................................... 2-6
设计和执行约束 ........................................................................................................... 2-6 假设和依赖 ................................................................................................................... 2-6
外部接口需求 ....................................................................................................................... 3-7 3.1 3.2 3.3 3.4
用户界面 ....................................................................................................................... 3-7 硬件接口 ....................................................................................................................... 3-7 软件接口 ....................................................................................................................... 3-7 通信接口 ....................................................................................................................... 3-8
4 内部接口需求 ....................................................................................................................... 4-9 4.1 4.2
模块间的接口 ............................................................................................................... 4-9 功能间的接口 ............................................................................................................... 4-9
5 功能需求 ..............................................................................................................................5-10 5.1
需求类1名称 优先级别 ............................................................................................5-10
5.1.1 5.1.2 6
业务流程 ..............................................................................................................5-10 功能需求 ..............................................................................................................5-10
非功能需求 .......................................................................................................................... 6-11 6.1 6.2 6.3 6.4 6.5 6.6
性能需求 ...................................................................................................................... 6-11 安全设施要求 .............................................................................................................. 6-11 安全和保密要求 .......................................................................................................... 6-11 质量要求 ......................................................................................................................6-12 业务规则（选） ..........................................................................................................6-12 其它需求 ......................................................................................................................6-12
附录1：待确定问题清单 ...........................................................................................................6-12
1 引言
//引言，作为文档的第一部分，对整个软件需求说明书文档进行概要性的说明，帮助读者快速了解文档目的、编写约定、阅读方式以及软件产品。
1.1 目的
说明文档编写目的，即软件需求说明书的作用以及主要内容。其中要明确说明待修订的软件版本号，以及即将发行的软件版本号。
//这段文字的描述，目的就是对产品的软件需求进行定义，但是说明和定义的范围应当限于我们要做的软件系统或软件子系统。（相关的总体系统和其它系统的需求说明，应当在“参考文献”中指出。） 范例：
本文档是在对XX系统进行总体分析后，得出的对XX软件系统的需求说明。
XXX版本XX软件是对XX版本XX软件进行的修订，本文将对XX软件的软件需求进行详细的定义，并以需求基线的形式确定下来，对之进行严格的控制，目的是准确和正确地满足XX系统的要求，减少返工。
本文档将作为对XXX版本XX软件进行设计开发和验收活动的依据。
1.2 文档约定
描述编写文档时采用的标准或对排版风格的约定，如：不同样式的字体代表哪类内容、不同标题引导哪个层次的内容、特殊符号的含义等等。
//约定的目的是让读者与作者在同一语境中理解文章的含义，方便阅读、有效消除误解。 范例：
文档在编制时，遵守IEEE发布的对软件需求说明书的文档约定 / 或 采用公司发布的软件需求说明书模板，严格遵守其约定。
本文的特殊约定：高层需求的实现优先级可以被其细化的低层需求所继承，低层需求的实现
优先级如果高于其高层需求，必须单独补充说明。
1.3 预期读者和阅读建议
列出软件需求说明书所针对的不同读者，如项目经理、开发人员、销售、用户、测试人员或文档的编写人员；描述本文剩余内容及行文构架；每类读者最适合的阅读方式建议。 //不同读者，对需求的理解能力、关注的侧重点各不相同，需求分析人员应当给出方便他们阅读的合理化建议，有助于检查需求的质量。 范例：
本文可能的读者分为以下几类：
项目经理——仔细阅读文档的所有细节，同时阅读参考文献涉及的《系统分析说明书》和《用户需求说明书》；
开发人员和测试人员——仔细阅读每个需求功能说明和性能要求，同时关注“2.5设计和实现约束”；
用户和销售——注意业务流程的描述、假定和依赖、运行环境。
1.4 产品范围
首先，对所开发软件做一个概念性的描述。然后，说明软件成功开发后，开发商、客户和最终用户预期得到的利益，以及借此能够达到的（业务或/和市场）目标。 范例：
XX软件是商业通讯事业部受北京市政府委托，为其开发的一套办公自动化软件。 北京市政府使用这套软件后，可以使日常事务处理流程更趋于合理化，从而使办事效率得到极大改善，同时也节省了物力、人力资源。这也是中国政府加入WTO后的必然发展趋势。 亿阳集团作为本软件的开发商，不仅可以取得经济上的直接利益，同时也极大促进了今后占领本领域的市场份额，树立自己的品牌形象。
1.5 参考文献
列出编写本文所参考的各种资料和引用相关文档，并注明这些参考文献的详细信息，包括文
档编号（如果有）、文档名称、作者、版本、发布日期、出版单位或来源。 参考文献通常有：
1. 本项目经核准的方案建议书、可行性分析报告、立项申请表、项目任务书、合同、上级
机关批文、系统需求规格说明书、用户需求说明书、相关产品的软件需求说明书； 2. 遵守的行业规范、技术标准、软件需求说明书的书写规范； 3. 其它。
//本节的目的，是方便读者查阅相关文献，理解设计需求的依据和来源。
2 系统概述
//本章对待开发的软件系统做出概要性阐述，说明开发背景、作用范围、运行环境和已知的约束条件。
2.1 任务背景
描述开发本软件系统的背景和起源。
说明待开发软件是否是某产品系列中的下一成员，是否是成熟产品所改进的下一代产品，是否是现有软件系统的替代品，或者是否是一个新型的产品。
如果待开发软件属于某个大系统的组成部分，则需说明该软件在系统中的位置，它是怎样与整个系统相关联的，并定义出与系统其它部分之间的接口。（通常，使用系统结构图说明这一点） 范例：
XX单位的办公自动化软件是1990年根据当时的需要开发的，随着工作流程的细化、业务的增多，现行系统已经远远不能满足当前需要，因此XX单位提出根据目前的业务需求，开发一套新的办公处理软件来替代当前运行软件。
//描述现行旧系统的运行情况，以及不同状态和运行方式下（如正常、维护、降级、应急处理等状态）运行系统产生的差异，说明现行旧系统面临的问题和局限性，指出用户要求的改进方向，即新任务目标。
2.2 产品功能
简要列出软件产品具有的主要功能，粗框型的功能需求分组及各组功能之间的关系，可以用HIPO图或类图来表示。
//不需详细说明产品功能，只需概要性的总结，使读者清楚看到产品的功能是如何组织的，便于理解和阅读。
范例：（学生档案管理系统）
对学生的档案进行管理和维护。包括：录入学生信息；修改学生信息；组合条件查询学生信息；打印统计报表等。
2.3 用户特点
划分最终使用该软件系统的用户类别，描述不同用户类的特征（相关业务范围、技能水平、对系统的使用频率），注明哪些是重要用户。 说明不同用户类对系统的哪些功能更加关注。
//面对软件的众多用户（还可能是使用软件的不同角色），当他们的需求发生冲突时，首先考虑的应当是服从重要客户的需求，其余的需求可以考虑在下一版本实现。 范例：
班长坐席可能更关注统计等高级功能，这些功能通常只需要一天使用一次，因此对快速响应的性能要求不高，但对数据的准确性有要求。
2.4 运行环境
//描述待开发软件运行时对硬件、操作系统和其它软件的要求，或者是一种限制条件。
2.4.1 硬件平台
说明硬件需求，包括每种设备的类型、数量、主要特性。（处理器型号及容量、设备型号）
2.4.2 支持软件
指明必需使用或组合的计算机软件，包括操作系统、数据库管理系统、编程工具和其它支撑软件（通讯/网络软件、测试软件）。
2.4.3 通信环境
说明计算机通讯要求，包括连接的地理位置、配置和网络拓扑、传输技术、数据传输速率、网管、系统响应时间、传输/接收数据类型和数据量、传输/接收/响应时间界限、数据尖峰和数字特性。
2.5 设计和执行约束
说明约束软件实现的限制条件，如：
必须使用或避免的特定技术、工具、编程语言和数据库； 所要求的开发规范或标准（如约定的设计符号和编码标准）； 必须遵循的企业策略、政府法规或行业标准； 特定资源限制（已有的软件组件、硬件设备）； 数据转换格式标准。
//通常，出于系统优化、实现方便、容易维护等因素考虑，必须对以上做出必要的约束，设计和开发人员尤其要关注这些约束条件。约束有时是必需的，比如软件最终将由客户维护，或是必须与整个系统的风格相一致。
2.6 假设和依赖
说明在陈述以下的软件需求时，应用到的假设因素（与已知因素相对），比如打算要用的商业组件、有关开发或运行环境的问题。
确定软件开发活动对外部因素的依赖，例如，如果你打算把其他项目开发的组件集成到系统中，那么就要依赖那个项目组按时提供正确的组件组合进所开发的软件。
//如果这些假设因素不正确、不同读者理解不一致或被随意修改，项目的成功就会受到影响；同样，依赖因素也影响着项目，如果比较严重，应当作为一种风险对之随时监控。 //如果这些依赖已经记录到其它文档中，如项目计划，那么在此处就可以参考其它文档。
3 外部接口需求
//接口的正确识别和描述，有助于系统整体正确、高效运作。
根据节2.1所示的系统总体结构图，唯一标识与系统其它部分的外部接口，描述经过每个接口的接口数据和相关控制组件。
3.1 用户界面
陈述所需要的用户界面的软件组件。描述每个用户界面的逻辑特征。以下是可能要包括的一 些特征：
1. 将要采用的图形用户界面标准或产品系列的风格； 2. 屏幕布局或解决方案的限制；
3. 将出现在每个屏幕的标准按钮功能或导航链接，例如一个帮助按钮； 4. 快捷键；
5. 错误信息显示标准。
3.2 硬件接口
对本软件与系统硬件的每个接口进行描述，包括支持的硬件类型、软硬件之间交流的数据和控制信息、软硬件之间采用的通信协议。
3.3 软件接口
对本软件与其它系统软件的每个接口进行描述，包括软件之间的交换数据或信息及其作用（注意说明哪些是共享数据）、需要的服务、内部通信性质，。
//其它系统软件举例：数据库、操作系统、工具软件、集成的商业软件。
//如果必须用一种特殊的方法来实现数据共享机制，就必须把它定义为一种实现上的限制，放入相应的章节。
3.4 通信接口
//描述与本软件所使用的通信功能相关的需求。
电子邮件、Web 浏览器、网络通信标准或协议及电子表格等等。
包括对消息格式、通信安全或加密问题、数据传输速率和同步通信机制等要求。
4 内部接口需求
4.1 模块间的接口
根据系统高层次的结构模型，参考《需求分配单》定义出附带的子系统、模块、子模块间的接口；
给出每个内部接口的名称和唯一标识号，并说明在该接口上传递的信息提要、接口要求。
4.2 功能间的接口
参考《需求项之间的关系》列表，说明本软件系统的各项功能之间的接口需求； 给出每个内部接口的名称和唯一标识号，并说明在该接口上传递的信息提要、接口要求。
5 功能需求
//本章将分节描述软件系统必须实现的业务流程（使用实例），以及根据每个业务流程分解出来的详细的功能需求。
5.1 需求类1名称 优先级别
//对该需求特性做出简短的说明；并说明在资源限制下，实现的优先程度等级，必要时，对实现等级做出评价。
//举例：4.1新员工登记管理 高优先级
5.1.1 业务流程
使用一种或几种最恰当的方式，如流程图、表或者UML语言等，来表述系统执行该需求任务的输入/输出响应。
5.1.2 功能需求
//列出与该需求特性相关的详细功能需求。为了跟踪的需要，每个功能需求都要唯一标识。 //如果某项功能需求与其它需求类所定义的功能需求相同，在此处引用说明即可，不能重复。
5.1.2.1 功能需求1名称 唯一标识
描述系统要实现的详细功能。功能陈述中应当包含为满足规定的性能要求而必须设立的功能要求。
//性能需求包括：响应时间、更新处理时间、数据转换和传输时间、吞吐量、排序、精度、优先级、持续操作要求，还包括意外或边界条件下出错处理和应急操作要求等。
6 非功能需求
6.1 性能需求
软件性能需求通常包括以下方面：
1. 同时支持的最大用户数、同时支持操作的个数、某时刻能承受的最大数据量、数据最大
存储量、对系统运行时允许占用的系统资源要求；
2. 系统持续运行时间、响应时间、数据更新处理时间、数据间的转换和传输时间、界面刷
新处理时间的要求；
3. 在不同安装/运行环境、不同操作方式下，或者与其它子系统接口发生改变时，某些数据
和参数可以允许的变化范围。
//软件应用的领域不同，对其性能的要求可能也不尽相同。即使是为客户量身定做的专用软件，客户对某些性能的要求或许比某个功能更加重要和严格。因此应当解释这种要求，以便做出合理的设计和优化的算法。
//当这些性能要求已经分散到各项功能需求当中，这里的叙述就是不必要的。
范例：
当有30个以上的用户同时对系统执行查询操作时，系统的相应时间应当不多于2秒，页面刷新频率应当在0.2次/秒~0.3次/秒。
6.2 安全设施要求
//阐述的是与使用软件过程中可能发生的损失、破坏或危害相关的需求，满足安全设计要求。 说明为避免或减轻对相关人员、财产和物理环境产生危害，而必须采取的措施，以及为预防的潜在的危险动作而必须遵从的安全标准、策略或规则。
范例：
如果软件系统探知配电室的最高温度超过了35度，软件必须立刻同时启动三台冷风空调。
6.3 安全和保密要求
说明与系统安全性、完整性和保密性相关的需求，明确产品必须满足的安全保密策略。
//例如：防止非法访问系统功能及数据丢失而要求用户身份确认，防止病毒入侵和黑客进攻而增加的警告拦截等功能。
6.4 质量要求
说明其它的软件质量属性要求（可能从合同中或系统需求中导出，对用户来说至关重要）。这些特性应当是确定的、定量的、并在必要时可验证。如果这些属性之间发生了冲突，指明相对的侧重点是什么。 质量属性通常如下：
可靠性（软件能够无故障的运行一段时间的概率）、可维护性（对软件进行修改的难易程度——修改所用时间、修复的比率）、有效性（软件正常运行时间/总时间）、可用性（掌握软件操作的难易程度）、重用性、可测试性（查找缺陷的难易程度）、可移植性等。 //如，可靠性优于可维护性。
6.5 业务规则（选）
//对软件本身的操作规则，通常可以在某些功能需求中体现。
6.6 其它需求
//定义在软件需求说明书中其它部分未出现的需求，例如国际化需求或法律上的需求。还可以增加有关操作、管理和维护部分来完善产品安装、配置、启动和关闭、修复和容错，以及登录和监控操作等方面的需求。还可包括对于交付的产品文档的要求、培训要求、开发进度要求等等。//
如果不需要增加其它需求，可以省略这一部分。
附录1：待确定问题清单
将文档中待确定的问题（TBD）列出，便于今后的跟踪确认。
亿阳信通
文档编号：BSS-项目标识_P_SRS_版本号
文档状态：正式版V1.0
版权属于亿阳信通所有，无亿阳信通的书面同意，任何个人或组织无权拷贝。
需求分析说明书审批表
项目: 亿阳信通****项目
文档版本:正式版V1.0
程序对之进行控制，得到CCB（管理控制委员会）确认的最终形式就是在本签批页上作出书面的签字认可。只有经过了这种正式的批准，才能启动软件设计等一系列工作。 //CCB的成员通常包括以上角色，此处应当依据项目的实际执行情况对之进行裁剪。
文档修改记录
容差异，使读者能够快速、便捷地查看本版本的焦点内容。
目 录
需求分析说明书审批表 ................................................................................................................... 1 文档修改记录................................................................................................................................... 2 1
引言....................................................................................................................................... 1-1 1.1 1.2 1.3 1.4 1.5 2
目的 ............................................................................................................................... 1-1 文档约定 ....................................................................................................................... 1-1 预期读者和阅读建议 ................................................................................................... 1-2 产品范围 ....................................................................................................................... 1-2 参考文献 ....................................................................................................................... 1-2
系统概述 ............................................................................................................................... 2-4 2.1 2.2 2.3 2.4
任务背景 ....................................................................................................................... 2-4 产品功能 ....................................................................................................................... 2-4 用户特点 ....................................................................................................................... 2-5 运行环境 ....................................................................................................................... 2-5
2.4.1 2.4.2 2.4.3 2.5 2.6 3
硬件平台 ............................................................................................................... 2-5 支持软件 ............................................................................................................... 2-5 通信环境 ............................................................................................................... 2-6
设计和执行约束 ........................................................................................................... 2-6 假设和依赖 ................................................................................................................... 2-6
外部接口需求 ....................................................................................................................... 3-7 3.1 3.2 3.3 3.4
用户界面 ....................................................................................................................... 3-7 硬件接口 ....................................................................................................................... 3-7 软件接口 ....................................................................................................................... 3-7 通信接口 ....................................................................................................................... 3-8
4 内部接口需求 ....................................................................................................................... 4-9 4.1 4.2
模块间的接口 ............................................................................................................... 4-9 功能间的接口 ............................................................................................................... 4-9
5 功能需求 ..............................................................................................................................5-10 5.1
需求类1名称 优先级别 ............................................................................................5-10
5.1.1 5.1.2 6
业务流程 ..............................................................................................................5-10 功能需求 ..............................................................................................................5-10
非功能需求 .......................................................................................................................... 6-11 6.1 6.2 6.3 6.4 6.5 6.6
性能需求 ...................................................................................................................... 6-11 安全设施要求 .............................................................................................................. 6-11 安全和保密要求 .......................................................................................................... 6-11 质量要求 ......................................................................................................................6-12 业务规则（选） ..........................................................................................................6-12 其它需求 ......................................................................................................................6-12
附录1：待确定问题清单 ...........................................................................................................6-12
1 引言
//引言，作为文档的第一部分，对整个软件需求说明书文档进行概要性的说明，帮助读者快速了解文档目的、编写约定、阅读方式以及软件产品。
1.1 目的
说明文档编写目的，即软件需求说明书的作用以及主要内容。其中要明确说明待修订的软件版本号，以及即将发行的软件版本号。
//这段文字的描述，目的就是对产品的软件需求进行定义，但是说明和定义的范围应当限于我们要做的软件系统或软件子系统。（相关的总体系统和其它系统的需求说明，应当在“参考文献”中指出。） 范例：
本文档是在对XX系统进行总体分析后，得出的对XX软件系统的需求说明。
XXX版本XX软件是对XX版本XX软件进行的修订，本文将对XX软件的软件需求进行详细的定义，并以需求基线的形式确定下来，对之进行严格的控制，目的是准确和正确地满足XX系统的要求，减少返工。
本文档将作为对XXX版本XX软件进行设计开发和验收活动的依据。
1.2 文档约定
描述编写文档时采用的标准或对排版风格的约定，如：不同样式的字体代表哪类内容、不同标题引导哪个层次的内容、特殊符号的含义等等。
//约定的目的是让读者与作者在同一语境中理解文章的含义，方便阅读、有效消除误解。 范例：
文档在编制时，遵守IEEE发布的对软件需求说明书的文档约定 / 或 采用公司发布的软件需求说明书模板，严格遵守其约定。
本文的特殊约定：高层需求的实现优先级可以被其细化的低层需求所继承，低层需求的实现
优先级如果高于其高层需求，必须单独补充说明。
1.3 预期读者和阅读建议
列出软件需求说明书所针对的不同读者，如项目经理、开发人员、销售、用户、测试人员或文档的编写人员；描述本文剩余内容及行文构架；每类读者最适合的阅读方式建议。 //不同读者，对需求的理解能力、关注的侧重点各不相同，需求分析人员应当给出方便他们阅读的合理化建议，有助于检查需求的质量。 范例：
本文可能的读者分为以下几类：
项目经理——仔细阅读文档的所有细节，同时阅读参考文献涉及的《系统分析说明书》和《用户需求说明书》；
开发人员和测试人员——仔细阅读每个需求功能说明和性能要求，同时关注“2.5设计和实现约束”；
用户和销售——注意业务流程的描述、假定和依赖、运行环境。
1.4 产品范围
首先，对所开发软件做一个概念性的描述。然后，说明软件成功开发后，开发商、客户和最终用户预期得到的利益，以及借此能够达到的（业务或/和市场）目标。 范例：
XX软件是商业通讯事业部受北京市政府委托，为其开发的一套办公自动化软件。 北京市政府使用这套软件后，可以使日常事务处理流程更趋于合理化，从而使办事效率得到极大改善，同时也节省了物力、人力资源。这也是中国政府加入WTO后的必然发展趋势。 亿阳集团作为本软件的开发商，不仅可以取得经济上的直接利益，同时也极大促进了今后占领本领域的市场份额，树立自己的品牌形象。
1.5 参考文献
列出编写本文所参考的各种资料和引用相关文档，并注明这些参考文献的详细信息，包括文
档编号（如果有）、文档名称、作者、版本、发布日期、出版单位或来源。 参考文献通常有：
1. 本项目经核准的方案建议书、可行性分析报告、立项申请表、项目任务书、合同、上级
机关批文、系统需求规格说明书、用户需求说明书、相关产品的软件需求说明书； 2. 遵守的行业规范、技术标准、软件需求说明书的书写规范； 3. 其它。
//本节的目的，是方便读者查阅相关文献，理解设计需求的依据和来源。
2 系统概述
//本章对待开发的软件系统做出概要性阐述，说明开发背景、作用范围、运行环境和已知的约束条件。
2.1 任务背景
描述开发本软件系统的背景和起源。
说明待开发软件是否是某产品系列中的下一成员，是否是成熟产品所改进的下一代产品，是否是现有软件系统的替代品，或者是否是一个新型的产品。
如果待开发软件属于某个大系统的组成部分，则需说明该软件在系统中的位置，它是怎样与整个系统相关联的，并定义出与系统其它部分之间的接口。（通常，使用系统结构图说明这一点） 范例：
XX单位的办公自动化软件是1990年根据当时的需要开发的，随着工作流程的细化、业务的增多，现行系统已经远远不能满足当前需要，因此XX单位提出根据目前的业务需求，开发一套新的办公处理软件来替代当前运行软件。
//描述现行旧系统的运行情况，以及不同状态和运行方式下（如正常、维护、降级、应急处理等状态）运行系统产生的差异，说明现行旧系统面临的问题和局限性，指出用户要求的改进方向，即新任务目标。
2.2 产品功能
简要列出软件产品具有的主要功能，粗框型的功能需求分组及各组功能之间的关系，可以用HIPO图或类图来表示。
//不需详细说明产品功能，只需概要性的总结，使读者清楚看到产品的功能是如何组织的，便于理解和阅读。
范例：（学生档案管理系统）
对学生的档案进行管理和维护。包括：录入学生信息；修改学生信息；组合条件查询学生信息；打印统计报表等。
2.3 用户特点
划分最终使用该软件系统的用户类别，描述不同用户类的特征（相关业务范围、技能水平、对系统的使用频率），注明哪些是重要用户。 说明不同用户类对系统的哪些功能更加关注。
//面对软件的众多用户（还可能是使用软件的不同角色），当他们的需求发生冲突时，首先考虑的应当是服从重要客户的需求，其余的需求可以考虑在下一版本实现。 范例：
班长坐席可能更关注统计等高级功能，这些功能通常只需要一天使用一次，因此对快速响应的性能要求不高，但对数据的准确性有要求。
2.4 运行环境
//描述待开发软件运行时对硬件、操作系统和其它软件的要求，或者是一种限制条件。
2.4.1 硬件平台
说明硬件需求，包括每种设备的类型、数量、主要特性。（处理器型号及容量、设备型号）
2.4.2 支持软件
指明必需使用或组合的计算机软件，包括操作系统、数据库管理系统、编程工具和其它支撑软件（通讯/网络软件、测试软件）。
2.4.3 通信环境
说明计算机通讯要求，包括连接的地理位置、配置和网络拓扑、传输技术、数据传输速率、网管、系统响应时间、传输/接收数据类型和数据量、传输/接收/响应时间界限、数据尖峰和数字特性。
2.5 设计和执行约束
说明约束软件实现的限制条件，如：
必须使用或避免的特定技术、工具、编程语言和数据库； 所要求的开发规范或标准（如约定的设计符号和编码标准）； 必须遵循的企业策略、政府法规或行业标准； 特定资源限制（已有的软件组件、硬件设备）； 数据转换格式标准。
//通常，出于系统优化、实现方便、容易维护等因素考虑，必须对以上做出必要的约束，设计和开发人员尤其要关注这些约束条件。约束有时是必需的，比如软件最终将由客户维护，或是必须与整个系统的风格相一致。
2.6 假设和依赖
说明在陈述以下的软件需求时，应用到的假设因素（与已知因素相对），比如打算要用的商业组件、有关开发或运行环境的问题。
确定软件开发活动对外部因素的依赖，例如，如果你打算把其他项目开发的组件集成到系统中，那么就要依赖那个项目组按时提供正确的组件组合进所开发的软件。
//如果这些假设因素不正确、不同读者理解不一致或被随意修改，项目的成功就会受到影响；同样，依赖因素也影响着项目，如果比较严重，应当作为一种风险对之随时监控。 //如果这些依赖已经记录到其它文档中，如项目计划，那么在此处就可以参考其它文档。
3 外部接口需求
//接口的正确识别和描述，有助于系统整体正确、高效运作。
根据节2.1所示的系统总体结构图，唯一标识与系统其它部分的外部接口，描述经过每个接口的接口数据和相关控制组件。
3.1 用户界面
陈述所需要的用户界面的软件组件。描述每个用户界面的逻辑特征。以下是可能要包括的一 些特征：
1. 将要采用的图形用户界面标准或产品系列的风格； 2. 屏幕布局或解决方案的限制；
3. 将出现在每个屏幕的标准按钮功能或导航链接，例如一个帮助按钮； 4. 快捷键；
5. 错误信息显示标准。
3.2 硬件接口
对本软件与系统硬件的每个接口进行描述，包括支持的硬件类型、软硬件之间交流的数据和控制信息、软硬件之间采用的通信协议。
3.3 软件接口
对本软件与其它系统软件的每个接口进行描述，包括软件之间的交换数据或信息及其作用（注意说明哪些是共享数据）、需要的服务、内部通信性质，。
//其它系统软件举例：数据库、操作系统、工具软件、集成的商业软件。
//如果必须用一种特殊的方法来实现数据共享机制，就必须把它定义为一种实现上的限制，放入相应的章节。
3.4 通信接口
//描述与本软件所使用的通信功能相关的需求。
电子邮件、Web 浏览器、网络通信标准或协议及电子表格等等。
包括对消息格式、通信安全或加密问题、数据传输速率和同步通信机制等要求。
4 内部接口需求
4.1 模块间的接口
根据系统高层次的结构模型，参考《需求分配单》定义出附带的子系统、模块、子模块间的接口；
给出每个内部接口的名称和唯一标识号，并说明在该接口上传递的信息提要、接口要求。
4.2 功能间的接口
参考《需求项之间的关系》列表，说明本软件系统的各项功能之间的接口需求； 给出每个内部接口的名称和唯一标识号，并说明在该接口上传递的信息提要、接口要求。
5 功能需求
//本章将分节描述软件系统必须实现的业务流程（使用实例），以及根据每个业务流程分解出来的详细的功能需求。
5.1 需求类1名称 优先级别
//对该需求特性做出简短的说明；并说明在资源限制下，实现的优先程度等级，必要时，对实现等级做出评价。
//举例：4.1新员工登记管理 高优先级
5.1.1 业务流程
使用一种或几种最恰当的方式，如流程图、表或者UML语言等，来表述系统执行该需求任务的输入/输出响应。
5.1.2 功能需求
//列出与该需求特性相关的详细功能需求。为了跟踪的需要，每个功能需求都要唯一标识。 //如果某项功能需求与其它需求类所定义的功能需求相同，在此处引用说明即可，不能重复。
5.1.2.1 功能需求1名称 唯一标识
描述系统要实现的详细功能。功能陈述中应当包含为满足规定的性能要求而必须设立的功能要求。
//性能需求包括：响应时间、更新处理时间、数据转换和传输时间、吞吐量、排序、精度、优先级、持续操作要求，还包括意外或边界条件下出错处理和应急操作要求等。
6 非功能需求
6.1 性能需求
软件性能需求通常包括以下方面：
1. 同时支持的最大用户数、同时支持操作的个数、某时刻能承受的最大数据量、数据最大
存储量、对系统运行时允许占用的系统资源要求；
2. 系统持续运行时间、响应时间、数据更新处理时间、数据间的转换和传输时间、界面刷
新处理时间的要求；
3. 在不同安装/运行环境、不同操作方式下，或者与其它子系统接口发生改变时，某些数据
和参数可以允许的变化范围。
//软件应用的领域不同，对其性能的要求可能也不尽相同。即使是为客户量身定做的专用软件，客户对某些性能的要求或许比某个功能更加重要和严格。因此应当解释这种要求，以便做出合理的设计和优化的算法。
//当这些性能要求已经分散到各项功能需求当中，这里的叙述就是不必要的。
范例：
当有30个以上的用户同时对系统执行查询操作时，系统的相应时间应当不多于2秒，页面刷新频率应当在0.2次/秒~0.3次/秒。
6.2 安全设施要求
//阐述的是与使用软件过程中可能发生的损失、破坏或危害相关的需求，满足安全设计要求。 说明为避免或减轻对相关人员、财产和物理环境产生危害，而必须采取的措施，以及为预防的潜在的危险动作而必须遵从的安全标准、策略或规则。
范例：
如果软件系统探知配电室的最高温度超过了35度，软件必须立刻同时启动三台冷风空调。
6.3 安全和保密要求
说明与系统安全性、完整性和保密性相关的需求，明确产品必须满足的安全保密策略。
//例如：防止非法访问系统功能及数据丢失而要求用户身份确认，防止病毒入侵和黑客进攻而增加的警告拦截等功能。
6.4 质量要求
说明其它的软件质量属性要求（可能从合同中或系统需求中导出，对用户来说至关重要）。这些特性应当是确定的、定量的、并在必要时可验证。如果这些属性之间发生了冲突，指明相对的侧重点是什么。 质量属性通常如下：
可靠性（软件能够无故障的运行一段时间的概率）、可维护性（对软件进行修改的难易程度——修改所用时间、修复的比率）、有效性（软件正常运行时间/总时间）、可用性（掌握软件操作的难易程度）、重用性、可测试性（查找缺陷的难易程度）、可移植性等。 //如，可靠性优于可维护性。
6.5 业务规则（选）
//对软件本身的操作规则，通常可以在某些功能需求中体现。
6.6 其它需求
//定义在软件需求说明书中其它部分未出现的需求，例如国际化需求或法律上的需求。还可以增加有关操作、管理和维护部分来完善产品安装、配置、启动和关闭、修复和容错，以及登录和监控操作等方面的需求。还可包括对于交付的产品文档的要求、培训要求、开发进度要求等等。//
如果不需要增加其它需求，可以省略这一部分。
附录1：待确定问题清单
将文档中待确定的问题（TBD）列出，便于今后的跟踪确认。