前   言

软件需求确认书主要描述、界定软件的范围，同时给出软件必须解决的问题的详细描述。每个问题可以认为是软件产品的一个“功能”，需要对每个功能提供一个处理叙述、设计约束、性能特征以及与其他元素间的相互影响的说明。

软件需求确认书另外一个重要的作用是提供一个软件产品的确认验收标准，进行功能实现的识别和性能、约束的条件等的设定。

文档修订记录

* 变化状态：C--创建；A--增加；M--修改；D--删除

1.  概述

1.1  目的

编写本文档的目的是明确用户需求，在最终用户和开发者之间达成对软件产品要求的共用理解，作为项目开发的目标，为软件概要设计提供指导，并作为软件测试的依据。

本文档的读者是最终用户代表、高级项目经理、项目经理、项目组成员、测试组成员、质量保证组成员。

1.2  范围

本文档是项目的软件需求规格说明书，是技术文档。

本文档使用对象为：

l  项目需求人员

l  项目经理

l  软件工程组

l  用户

l  ……

未经项目经理书面许可，该文档不得提供给上述规定对象以外的人员阅读或使用。

1.3  定义、首字母缩写词和缩略语

1.4  参考资料

1． 姚尚郎 ,Android开发入门与实践 ,人民邮电出版社,2009.7

1. 杨丰盛, Android应用开发揭秘, 机械工业出版社,2010.1
2. 余志龙 ,Google Android SDK开发范例大全(第2版), 人民邮电出版社,2010.6
3. 郭宏志 ,Android应用开发详解, 电子工业出版社,2010.6
4. 张利国，代闻，龚海平,Android移动开发案例详解, 人民邮电出版社 ,2010.2

6.  系统说明

6.1  产品的背景

大学实行的是走班的上课制度，这样就会造成有些教室空着而有些学生不能及时找到可以利用的自习教室。为了提高自习教室的利用率，减少去学生找自习教室所花费的时间，我们开发这款找自习教室app，方便学生的学习。

6.2  产品的功能

1． 用户可以自行上传空自习教室数据；

2． App自动定位距离用户最近的教学楼；

3． 错误数据补救措施；

4． 推送服务。

6.3  用户类和特征

比较喜爱读书、自习的大学生

6.4  运行环境

1. 服务器端：Linux
2. 客户端：Android4.0 及以上
3. 开发语言： java
4. 数据库选择: MySQL

6.5  设 计 和 实 现 上 的 限 制

6.6  假设和依赖

[列举出在对软件需求确认书中影响需求陈述的假设因素（与已知因素相对立），可能包括打算 使用的商业组件或有关开发或运行环境的问题。你可能认为产品将符合一个特殊的用户界面设计约定， 但是另一个读者却可能不这样认为。如果这些假设不正确、不一致或被更改，就会使项目受到影响。

确定项目对外部因素存在的依赖。例如，如果你打算把其它项目开发的组件集成到系统中，那么你 就要依赖哪个项目按时提供正确的操作组件， 如果这些依赖已经记录到其它文档 （例如项目计划） 中了， 那么在此就可以参考其它文档。]

6.7  其他条件与限制

[尽量列出开展本项目的假定和约束，例如：经费限制，开发期限，设备条件，用户现场环境准备、 安全保密等]

7.  业务流程

8.  功能描述

1. 用户可以自行上传空自习教室数据；
2. App自动定位距离用户最近的教学楼
3. 错误数据补救措施
4. 推送服务

5.  数据描述

5.1  数据来源和数据流图

5.1.1  输入数据

登陆名和密码

用户基本信息

新添加空自习教室

修正自习教室

5.1.2  输出数据

自习教室信息

5.1.3  数据流程图

5.2  数据库描述

5.2.1  教室表

5.2.2  用户表

5.2.3  课程表

5.2.4  录入表

6.  数据描述

6.1  数据精确度

[数据内部显示精度，外部显示精度]

6.2  时间特性

[系统响应时间、界面更新处理时间、数据转换与传输时间等]

6.3  适应性

[在操作方式、运行环境、与其他软件的接口以及开发计划等发生变化时，应具有的适应能力]

7.  安全性

7.1  安全设施需求

[详尽陈述与产品使用过程中可能发生的损失、破坏或危害相关的需求。定义必须采取的安全保护或动作，还有那些预防的潜在的危险动作。明确产品必须遵从的安全标准、策略或规则。一个安全设施需求的范例如下：“如果油箱的压力超过了规定的最大压力的 95％，那么必须在 1 秒种内终止操作”。] 

7.2  安全性需求

[详尽陈述与系统安全性、完整性或与私人问题相关的需求，这些问题将会影响到产品的使用和产品所创建或使用的数据的保护。 定义用户身份确认或授权需求。 明确产品必须满足的安全性或保密性策 略。一个软件系统的安全需求的范例如下：“每个用户在第一次登录后，必须更改最初登录密码。最初的登录密码不能重用。”]

8.  运行接口需求

8.1  用户界面

[陈述所需要的用户界面的软件组件。描述每个用户界面的逻辑特征。以下是可能要包括的一些特 征：

l  将要采用的图形用户界面（GUI）标准或产品系列的风格。

l  屏幕布局或解决方案的限制。

l  将出现在每个屏幕的标准按钮、功能或导航链接（例如一个帮助按钮）。

l  快捷键。

l  报表输出定义。

l  错误信息显示标准。

对于用户界面的细节，例如特定对话的布局，应该写入一个独立的用户界面规格说明中，而不能

写入软件需求规格说明中。]

8.2  硬件接口

[描述系统中软件和硬件每一接口的特征，这种描述可能包括支持的硬件类型、软硬之间交流的数据和控制信息的性质以及所使用的通信协议]

例如网络图等

8.3  软件接口

[包括数据库、操作系统、工具、库和集成的商业组件，明确并描述在软件组件之间交换数据或消息的目的]

8.4  通信接口

[描述与产品所使用的通信功能相关的，包括电子、Web 浏览器、网络通信标准或协议及电子表格等。定义了相关的消息格式。规定通信安全或加密问题、数据传输速率和同步通信机制。]

9.  其他需求

[定义在软件需求规格说明的其它部分未出现的需求，例如国际化需求或法律上的需求。还可以增加有关操作、管理和维护部分来完善产品安装、配置、启动和关闭、修复和容错，以及登录和监控操作等方面的需求。如果不需要增加其它需求，可省略这一部分。]

10.  验收标准

[明确规定产品验收依据的各种标准或条件的具体内容]

10.1  软件质量

[详尽陈述与客户或开发人员至关重要的产品质量特性。这些特性必须是确定的、定量的并在可能时是可验证的。]

10.2  用户文档

[列举出将与软件一同发行的用户文档部分，例如，操作手册、安装手册、维护手册、在线帮助和教程。明确所有已知的用户文档的交付格式和标准。]

注： 文档中[ ]里面的内容是对相应部分的说明，在写具体项目的需求说明书时，应去掉或更改为适当的内容。