1 引言

1.1 目的

本文档是进一步分析用户需求的结果，详尽说明了这一软件的需求和规格，这些规格说明时进行系统设计的基础，也是编写测试用例和进行系统测试的主要依据。同时，该文档也是用户确定软件功能需求的主要依据。

本文档撰写的目的是明确软件需求、安排项目计划、推广软件设计和组织软件开发和测试。本文档主题内容为项目的需求汇总分类以及以此为基础而建立的需求模型。

本说明书的预期读者是软件概要设计人员和详细设计人员，是软件设计的基础。

1.2 背景

背景：是指衬托其他事物的要素或背后力量。

阐述项目或特定需求产生的背景，便于各方的干系人了解事情的背景。

1.3 定义

项目的名称与标识

1.4 参考资料

其他参考资料

2 需求概述

2.1 总体目标

阐述需要解决客户哪方面的问题或痛点？阐述客户的期望和目标。

2.2 运行环境

软件系统的运行环境（操作系统、计算机硬件等）

2.3 约束条件（CONSTRAINTS）与假定条件（ASSUMPATION）

约束：不是具体的动作或行为，而是对项目或设计的行为动作或行为进行限制。通常通过"约束”强调其限制性。

（1）业务环境约束（来自客户或出资方的约束条件）

预算的约束
上线时间的约束
业务领域的约束
业务规则的约束
业务限制的约束
法律或专利的约束

（2）用户使用环境的约束（使用者）

使用群体的约束
用户年龄的约束
用户喜好的约束
使用期间的环境：如移动性、车载等
运行平台的约束，如只能运行在Linux环境中
数据库的约束

（3）构建环境的约束（来自开发团队的实际情况的约束）

开发团队的开发环境
开发团队的技术水平
开发团队的成员工作地点的分布
开发项目管理的约束
是否需要开放源代码的约束

（4）技术环境的约束

业内的技术水平的约束

（5）技术要求的约束

性能指标的约束
功能的约束
体积、总量、功耗

找出、发现这些隐性的约束是一件非常重要的任务，如果无视一些约束，有可能会成为项目或需求无法实现的一颗炸药或一个大坑。

3. 数据描述

3.1 静态数据

静态数据是指在运行过程中主要作为控制或参考用的数据,它们在很长的一段时间内不会变化，一般不随运行而变。

3.2 动态数据

动态数据包括所有在运行中发生变化的数据以及在运行中需要输入、输出的数据及在连机操作中要改变的数据。

3.3 数据库介绍

数据库是“按照数据结构来组织、存储和管理数据的仓库”。是一个长期存储在计算机内的、有组织的、可共享的、统一管理的大量数据的集合。

3.4 数据词典

IBM计算词典中定义的数据字典或元数据存储库是“有关数据的信息的集中存储库，例如含义、与其他数据的关系、来源、用法和格式”。Oracle将其定义为具有元数据的表的集合。

3.5 数据采集

数据采集(DAQ)，是指从传感器和其它待测设备等模拟和数字被测单元中自动采集非电量或者电量信号,送到上位机中进行分析，处理。数据采集系统是结合基于计算机或者其他专用测试平台的测量软硬件产品来实现灵活的、用户自定义的测量系统。

4. 功能需求概述

功能需求规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求功能需求有时也被称作行为需求。

功能需求，描述是开发人员需要实现什么。

产品特性，是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标得以满足对商业软件而言。特性则是一组能被客户识别，并帮助他决定是否购买的需求。

4.1 功能划分

对大的功能需要进行分解，分解成一个个相对独立的功能。功能性需要取决于客户对系统的操作性需要。

4.2 功能概述

（1）用用户故事描述

（2）用户场景进行描述

（3）用用户用例进行描述

（4）用时序图进行描述

（5）用独立文本进行描述

5. 非功能性需求概述

非功能性需求，是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性，包括安全性、可靠性、互操作性、健壮性等。

非功能性需求是随着软件系统的规模成长和复杂性增加这两个因素才逐渐成为软件工程师们的新着眼点和关注点的，早期的时候，甲方处于自身对软件技术的了解和自身对系统文件维护的方便性考虑等，对系统有了诸如：开发平台、技术流派、关键实现等等方面的要求，这被称之为“设计约束”。从甲乙双方合同的角度，设计约束也是一种需求——一种“非功能”性的需求，后来，软件的质量问题越来越突出，描述软件质量目标的要求也成为非功能性需求的一部分。于是，目前业界关于软件的非功能需求，一般就包括：质量属性要求和约束性要求。

场景的性能指标有：

（1）容量：最大用户数

（2）并发量：同时并发运行的进程数、用户数

（3）响应时间

（4）利用率：CPU、内存、网络、硬盘

（5）高可用性：高负载多长时间，系统能够持续提供服务。