(CEN)第六章需求规格说明.ppt

1、第六章 需求规格说明(SRS),需求开发的最终成果是，在客户和开发人员对所要开发的产品达成共识后，所编写的具体的文档。 我们可以采用以下几种方式来表示软件需求： (1)文档 用结构合理的自然语言来精心编写需求文档。 (2)图形化模型 这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或者对象类及其关系。 (3)形式化规格说明 使用数学上精确的形式逻辑语言来定义需求。,6.1 需求规格说明(Software Requirement Specification)的定义 定义:软件需求规格说明，有时也称为功能规格说明(function specification)、产品规格说明(p

2、roduct specification)、需求文档(requirements document)或系统规格说明(system specification)，但各组织并不以相同的方式使用这些术语。 它精确的阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件。,6.2 需求规格说明的作用: (1)客户、市场部和销售人员需要从中了解他们期望得到什么样的产品。 (2)项目经理根据产品描述来估计项目的进度、工作量和所需资源。 (3)开发团队根据软件需求规格说明了解需要开发什么样的产品。 (4)测试小组使用软件需求规格说明来开发测试计划、测试用例和测试过程。 (5)软件维护和支持人员根据软件需

3、求规格说明了解产品的每一部分的功能是什么。,(6)文档编写人员根据软件需求规格说明和用户界面设计来编写用户手册和帮助屏幕。 (7)培训人员根据软件需求规格说明和用户文档来编写培训材料。 (8)公司律师要确保该需求遵守相应的法律法规。 (9)分包商根据软件需求规格说明来进行工作，当然这要在合法的基础上。,6.3 软件需求规格说明的模板和内容,每个软件开发组织都应该在它们的项目中采用一种或多种标准的软件需求规格说明模板。 软件需求规格说明模板改写自IEEE 830标准，该标准还包含了许多附加的特定需求的范例:,1. 引言 (1)目标 (2)文档约定 (3)读者对象和阅读建议 (4)项目范围 (5)

4、参考资料,2. 总体描述 (1)产品前景 (2)产品特性 (3)用户类及其特征 (4)运行环境 (5)设计和实现上的约束 (6)用户文档 (7)假设和依赖,3. 系统特性 系统特性X 3.x.1 描述和优先级 3.x.2 激励/响应序列 3.x.3 功能性需求,4. 外部接口需求 (1)用户界面 (2)硬件接口 (3)软件接口 (4)通信接口 5. 其他非功能性需求 (1)性能需求 (2)防护性需求 (3)安全性需求 (4)软件质量属性,6. 其他需求 7. 附录A：术语表 8. 附录B：分析模型 9. 附录C：待确定问题的清单,详细说明如下: 1 引言 引言提出了对软件需求规格说明的纵览，这

5、有助于读者理解文档如何编写并且如何阅读和解释。 1.1 编写的目标 说明编写这份需求说明书的目的，指出预期的读者。对产品进行定义，在该文档中详尽说明了这个产品的软件需求，包括修正或发行版本号。如果这个软件需求规格说明只与整个系统的一部分有关系，那么就只定义文档中说明的部分或子系统。,1.2 文档约定 描述编写文档时所采用的标准或排版约定，包括正文风格、提示区或重要符号。 1.3 预期的读者和阅读建议 列举了软件需求规格说明所针对的不同读者，例如开发人员、项目经理、营销人员、用户、测试人员或文档的编写人员。描述了文档中剩余部分的内容及其组织结构。提出了最适合于每一类型读者阅读文档的建议。,1.4

6、 产品的范围 提供了对指定的软件及其目的的简短描述，包括利益和目标。把软件与企业目标或业务策略相联系。可以参考项目视图和范围文档而不是将其内容复制到这里。 1.5 参考资料 列举了编写软件需求规格说明时所参考的资料或其它资源。这可能包括用户界面风格指导、合同、标准、系统需求规格说明、使用实例文档，或相关产品的软件需求规格说明。,2 总体描述 这一部分概述了正在定义的产品以及它所运行的环境、使用产品的用户和已知的限制、假设和依赖。 2.1 产品的前景 描述了软件需求规格说明中所定义的产品的背景和起源。说明了该产品是否是产品系列中的下一成员，是否是成熟产品所改进的下一代产品、是否是现有应用程序的替

7、代品，或者是否是一个新型的、自含型产品。,2.2 产品的功能 概述了产品所具有的主要功能。其详细内容将在d 中描述，所以在此只需要概略地总结。很好地组织产品的功能，使每个读者都易于理解。 2.3 用户类和特征 确定你觉得可能使用该产品的不同用户类并描述它们相关的特征。有一些需求可能只与特定的用户类相关。,2.4 运行环境 描述了软件的运行环境，包括硬件平台、操作系统和版本，还有其它的软件组件或与其共存的应用程序。 2.5 设计和实现上的限制 确定影响开发人员自由选择的问题，并说明这些问题为什么成为一种限制。 2.6 假设和依赖,列举出在对软件需求规格说明中影响需求陈述的假设因素(与已知因素相对

8、立)。这可能包括你打算要用的商业组件或有关开发或运行环境的问题。你可能认为产品将符合一个特殊的用户界面设计约定，但是另一个S R S 读者却可能不这样认为。如果这些假设不正确、不一致或被更改，就会使项目受到影响。 此外，确定项目对外部因素存在的依赖。例如，如果你打算把其它项目开发的组件集成到系统中，那么你就要依赖那个项目按时提供正确的操作组件。如果这些依赖已经记录到其它文档(例如项目计划)中了，那么在此就可以参考其它文档 。,3. 系统特性 3.1 描述和优先级 提出了对该系统特性的简短说明并指出该特性的优先级是高、中，还是低。或者你还可以包括对特定优先级部分的评价，例如利益、损失、费用和风险

9、，其相对优先等级可以从1(低)到9 (高)。,3.2 激励/响应序列 列出输入激励(用户动作、来自外部设备的信号或其它触发器)和定义这一特性行为的系统响应序列。这些序列将与使用实例相关的对话元素相对应。 3.3 功能性需求 详列出与该特性相关的详细功能需求。这些是必须提交给用户的软件功能，使用户可以使用所提供的特性执行服务或者使用所指定的使用实例执行任务。描述产品如何响应可预知的出错条件或者非法输入或动作，你必须唯一地标识每个需求。,4 外部接口需求 利用本节来确定可以保证新产品与外部组件正确连接的需求。关联图表示了高层抽象的外部接。需要把对接口数据和控制组件的详细描述写入数据字典中。如果产品

10、的不同部分有不同的外部接口，那么应把这些外部接口的详细需求并入到这一部分的实例中。 4.1 用户界面 陈述所需要的用户界面的软件组件。描述每个用户界面的逻辑特征。而对于用户界面的细节，例如特定对话框的布局，应该写入一个独立的用户界面规格说明中，而不能写入软件需求规格说明中。,4.2 硬件接口 描述系统中软件和硬件每一接口的特征。这种描述可能包括支持的硬件类型、软硬件之间交流的数据和控制信息的性质以及所使用的通信协议。 4.3 软件接口 描述该产品与其它外部组件(由名字和版本识别)的连接，包括数据库、操作系统、工具、库和集成的商业组件。明确并描述在软件组件之间交换数据或消息的目的。描述所需要的服

11、务以及内部组件通信的性质。确定将在组件之间共享的数据,4.4 通信接口 描述与产品所使用的通信功能相关的需求，包括电子邮件、We b 浏览器、网络通信标准或协议及电子表格等等。定义了相关的消息格式。规定通信安全或加密问题、数据传输速率和同步通信机制。,5 其它非功能需求 这部分列举出了所有非功能需求，如产品的易用程度如何，执行速度如何，可靠性如何，当发生异常情况时，系统如何处理，而不是外部接口需求和限制。 5.1 性能需求 阐述了不同的应用领域对产品性能的需求，并解释它们的原理以帮助开发人员作出合理的设计选择。确定相互合作的用户数或者所支持的操作、响应时间以及与实时系统的时间关系。 还可以在这

12、里定义容量需求，例如存储器和磁盘空间的需求或者存储在数据库中表的最大行数。尽可能详细地确定性能需求。可能需要针对每个功能需求或特性分别陈述其性能需求，而不是把它们都集中在一起陈述。,5.2 安全设施需求 详尽陈述与产品使用过程中可能发生的损失、破坏或危害相关的需求。定义必须采取的安全保护或动作，还有那些预防的潜在的危险动作。明确产品必须遵从的安全标准、策略或规则。 5.3 安全性需求 详尽陈述与系统安全性、完整性或与私人问题相关的需求，这些问题将会影响到产品的使用和产品所创建或使用的数据的保护。定义用户身份确认或授权需求。明确产品必须满足的安全性或保密性策略。,5.4 软件质量属性 详尽陈述与

13、客户或开发人员至关重要的其它产品质量特性。这些特性必须是确定、定量的并在可能时是可验证的。至少应指明不同属性的相对侧重点，例如易用程度优于易学程度，或者可移植性优于有效性。 5.5 业务规则 列举出有关产品的所有操作规则，例如什么人在特定环境下可以进行何种操作。这些本身不是功能需求，但它们可以暗示某些功能需求执行这些规则。 5.6 用户文档 列举出将与软件一同发行的用户文档部分，例如，用户手册、在线帮助和教程。明确所有已知的用户文档的交付格式或标准。,6 其它需求 定义在软件需求规格说明的其它部分未出现的需求，例如国际化需求或法律上的需求。你还可以增加有关操作、管理和维护部分来完善产品安装、配

14、置、启动和关闭、修复和容错，以及登录和监控操作等方面的需求。 附录A ：词汇表 定义所有必要的术语，以便读者可以正确地解释软件需求规格说明，包括词头和缩写。你可能希望为整个公司创建一张跨越多项项目的词汇表，并且只包括特定于单一项目的软件需求规格说明中的术语。,附录B ：分析模型 这个可选部分包括或涉及到相关的分析模型的位置，例如数据流程图、类图、状态转换图或实体-关系图。 附录C ：待确定问题的列表 编辑一张在软件需求规格说明中待确定问题的列表，其中每一表项都是编上号的，以便于跟踪调查。,6.4 软件需求文档的编制要求 (1) SRS应由开发者和用户双方联合起草 SRS是开发者和用户共同确认系

15、统做什么的基础。 (2)指明需求来源： 指明需求的来源为了让所有项目风险承担者明白需求规格说明书中为何提供这些功能需求，要都能追溯每项需求的来源，这可能是一种使用实例或其它客户要求，也可能是某项更高层系统需求、业务规范、政府法规、标准或别的外部来源。,(3)为每项需求注上标号： 为了满足软件需求规格说明的可跟踪性和可修改性的质量标准，必须唯一确定每个软件需求。 为每项需求注上标号制定一种惯例来为需求规格说明书中的每项需求提供一个独立的可识别的标号或记号。这种惯例应当很健全，允许增加、删除和修改。 作了标号的需求使得需求能被跟踪，记录需求变更并为需求状态和变更活动建立度量。需求标识方法有序列号;

16、层次化编码;使用待确定(to be determined, TBD )符号等。,(4)记录业务规范： 是指关于产品的操作原则，比如谁能在什么情况下采取什么动作。 将这些编写成需求规格说明书中的一个独立部分，或一独立的业务规范文档。某些业务规范将引出相应的功能需求;当然这些需求也应能追溯相应业务规范。 (5)创建需求跟踪能力矩阵： 建立一个矩阵把每项需求与实现、测试它的设计和代码部分联系起来。这样的需求跟踪能力矩阵同时也把功能需求和高层的需求及其它相关需求联系起来了。在开发过程中建立这个矩阵，而不要等到最后才去补建。,(6)SRS的编制工具 SRS的编制一般多采用自然语言，但自然语言不易精确。例

17、如，同一词汇经由文档的多个编制者在多处出现，而这一词汇又涉及系统的实体和许多活动，因此，就有必要对此加以验证，这就需要使用适当的工具。 另外，需求文档的形式化表达、制图、制表等，也都需要适当的工具来辅助完成。 例如:用到的图形模型-数据字典、数据流图、数据流图、状态转换图、对话图和类图。,6.5 需求规格说明实例,6.5.1 基本格式示例 软件需求规格说明书版本： 文档编号： *密 级：秘密 编 写：*编写日期：* 审 核：*审核日期:* 批 准：*批准日期： 年 月 日,修订记录,目 录 1引言 1.1编写目的 1.2范围 1.3定义 1.4参考资料 2项目概述 2.1产品描述 2.2产品功

18、能 2.3用户特点 2.4一般约束 2.5假设和依据 3具体需求 3.1功能需求 3.1.1功能需求1 3.1.2功能需求2 3.1.3功能需求3,3.2外部接口需求 3.2.1用户接口 3.2.2硬件接口 3.2.3软件接口 3.2.4通信接口 3.3性能需求 3.4设计约束 3.4.1其他标准的约束 3.4.2硬件的限制 3.5属性 3.5.1可用性 3.5.2安全性 3.5.3可维护性 3.5.4可转移 转换性 3.5.5警告 3.6其他需求 3.6.1数据库 3.6.2操作 3.6.3场合适应性需求 4附录,1 引言 1.1 编写目的 说明编写这份软件需求说明书的目的，指出预期的读者范

19、围。 1.2 范围 说明： a待开发的软件系统的名称； b说明软件将干什么，如果需要的话，还要说明软件产品不干什么； c描述所说明的软件的应用。应当： (1)尽可能精确地描述所有相关的利益、目的、以及最终目标。 (2)如果有一个较高层次的说明存在，则应该使其和高层次说明中的类似的陈述相一致（例如，系统的需求规格说明）。,1.3 定义 列出本文件中用到的专门术语的定义和缩写词的原词组。 1.4 参考资料 列出要用到的参考资料，如： a本项目的经核准的计划任务书或合同、上级机关的批文； b属于本项目的其他已发表的文件； c本文件中各处引用的文件、资料，包括所要用到的软件开发标准。 列出这些文件的标

20、题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。,2 项目概述 2.1 产品描述 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。 解释被开发软件与其他有关软件之间的关系。 如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。 如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。,2.2 产品功能 本条是为将要完成的软件功能提供一个摘要。例如，对于一个记帐程序来说，需求说明可以用这部分来描述：客房帐目维护、

21、客房财务报表和发票制作，而不必把功能所要求的大量的细节描写出来。 有时，如果存在较高层次的规格说明时，则功能摘要可从中取得，这个较高层次的规格说明为软件产品分配了特殊的功能，为了清晰起见，请注意： a.编制功能的一种方法是制作功能表，以便客房或者第一次读这个文件的人都可以理解； b.用方框图来表达不同的功能和它们的关系也是有帮助的。但应牢记，这样的图不是产品设计时所需求的，而只是一种有效的解释性的工具,2.3 用户特点 列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使用频度。这些是软件设计工作的重要约束。,2.4 一般约束 本条对设计系统时限制开发

22、者选择的其他一些项作一般性描述。而这些项将限定开发者在设计系统时的任选项。这些包括： a管理方针； b硬件的限制； c与其他应用间的接口； d并行操作； e审查功能； f控制功能； g所需的高级语言； h通信协议； i应用的临界点； j安全和保密方面的考虑。,2.5 假设和依据 本条列出影响需求说明中陈述的需求的每一个因素。这些因此不是软件的设计约束，但是它们的改变可能影响到需求说明中的需求。例如：假定一个特定的操作系统是在被软件产品指定的硬件上使用的，然而，事实上这个操作系统是不可能使用的，于是，需求说明就要进行相应的改变。 3 具体需求 3.1 功能需求 3.1.1 功能需求1 对于每一类

23、功能或者有时对于每一个功能，需要具体描述其输入、加工和输出的需求。由四个部分组成：,a 引言 描述的是功能要达到的目标、所彩的方法和技术，还应清楚说明功能意图的由来和背景。 b 输入 (1)详细描述该功能的所有输入数据，如：输入源、数量、度量单位、时间设定、有效输入范围（包括精度和公差）； (2)操作员控制细节的需求。其中有名字、操作员活动的描述、控制台或操作员的位置。例如：当打印检查时，要求操作员进行格式调整； (3)指明引用接口说明或接口控制文件的参考资料。,c 加工 定义输入数据、中间参数，以获得预期输出结果的全部操作。它包括如下的说明： (1)输入数据的有效性检查； (2)操作的顺序，

24、包括事件的时间设定； (3)响应，例如，溢出、通信故障、错误处理等； (4)受操作影响的参数； (5)降级运行的要求； (6)用于把系统输入变换成相应输出的任何方法（方程式、数学算法、逻辑操作等）； (7)输出数据的有效性检查。,d 输出 (1)详细描述该功能所有输出数据，例如：输出目的地、数量、度量单位、时间关系、有效输出的范围（包括精度和公差）、非法值的处理、出错信息； (2)有关接口说明或接口控制文件的参考资料。 此外，对着重于输入输出行为的系统来说，需求说明应指定所有有意义的输入、输出对及其序列。当一个系统要求记忆它的状态时，需要这个序列，使得它可以根据本次输入和以前的状态作出响应。也

25、就是说，这种情况犹如有限状态机。 3.1.2 功能需求2 3.1.3 功能需求3,3.2 外部接口需求 3.2.1 用户接口 提供用户使用软件产品时的接口需求。例如，如果系统的用户通过显示终端进行操作，就必须指定如下要求： a对屏幕格式的要求； b报表或菜单的页面打印格式和内容； c输入输出的相对时间； d程序功能键的可用性。,3.2.2 硬件接口 要指出软件产品和系统硬部件之间每一个接口的逻辑特点。还可能包括如下事宜：支撑什么样的设备，如何支撑这些设备，有何约定。 3.2.3 软件接口 在此要指定需使用的其他软件产品（例如，数据管理系统、操作系统或数学软件包），以及同其他应用系统之间的接口。

26、对每一个所需的软件产品，要提供如下内容：,a名字； b助记符； c规格说明号； d版本号； e来源。 对于每一个接口，这部分应说明与软件产品相关的接口软件的目的，并根据信息的内容和格式定义接口，但不必详细描述任何已有完整文件的接口，只要引用定义该接口的文件即可。,3.2.4 通信接口 指定各种通信接口。例如，局部网络的协议等等。 3.3 性能需求 从整体来说，本条应具体说明软件、或人与软件交互的静态或动态数值需求。 A 静态数值需求可能包括： (1)支持的终端数； (2)支持并行操作的用户数； (3)处理的文卷和记录数； (4)表和文卷的大小。,B 动态数值需求可能包括：欲处理的事务和任务的数

27、量，以及在正常情况下和峰值工作条件下一定时间周期中处理的数据总量。 所有这些需求都必须用可以度量的术语来叙述。例如，95的事务必须在小于1s时间内处理完，不然，操作员将不等待处理的完成。 3.4 设计约束 设计约束受其他标准、硬件限制等方面的影响。,3.4.1 其他标准的约束 本项将指定由现有的标准或规则派生的要求。例如： a报表格式； b数据命名； c财务处理； d审计追踪，等等。 3.4.2 硬件的限制 本项包括在各种硬件约束下运行的软件要求，例如，应该包括： 硬件配置的特点（接口数，指令系统等）； 内存储器和辅助存储器的容量,3.5 属性 在软件的需求之中有若干个属性，以下指出其中的几个

28、（注意：对这些决不应理解为是一个完整的清单）。 3.5.1 可用性 可以指定一些因素，如检查点、恢复和再启动等，以保证整个系统有一个确定的可用性级别。,3.5.2 安全性 指的是保护软件的要素，以防止各种非法的访问、使用、修改、破坏或者泄密。这个领域的具体需求必须包括： a利用可靠的密码技术； b掌握特定的记录或历史数据集； c给不同的模块分配不同的功能 ; d限定一个程序中某些区域的通信; e计算临界值的检查和。,3.5.3 可维护性 规定若干需求以确保软件是可维护的。例如： 软件模块所需要的特殊的耦合矩阵； 为微型装置指定特殊的数据程序分割要求。 3.5.4 可转移 转换性 规定把软件从一

29、种环境移植到另一种环境所要求的用户程序，用户接口兼容方面的约束等等。 3.5.5 警告 指定所需属性十分重要，它使得人们能用规定的方法去进行客观的验证。 3.6 其他需求 根据软件和用户组织的特性等，某些需求放在下面各项中描述。,3.6.1 数据库 本项对作为产品的一部分进行开发的数据库规定一些需求，它们可能包括： a在功能需求中标识的信息类别； b使用的频率； c存取能力； d数据元素和文卷描述符； e数据元素、记录和文卷的关系； f静态和动态的组织； g数据保存要求。 注：如果使用一个现有的数据库包，这个包应在“软件接口”中命名，并在那里详细说明其用法。,3.6.2 操作 这里说明用户要求

30、的常规的和特殊的操作。 a在用户组织之中各种方式的操作。例如，用户初始化操作； b交互作用操作的周期和无人操作的周期； c数据处理运行功能； d后援和恢复操作。 注：这里的内容有时是用户接口的一部分。 3.6.3 场合适应性需求 这里包括： a对给定场合或相关任务或操作方式的任何数据或初始化顺序的需 求进行定义。例如，栅值，安全界限等等。 b指出场合或相关任务为特点，这里可以被修改以使软件适合特殊配制的要求。,4 附录 对一个实际的需求规格说明来说，若有必要应该编写附录。附录中可能包括： a输入输出格式样本，成本分析研究的描述或用户调查结果； b有助于理解需求说明的背景信息； c软件所解决问题

31、的描述； d用户历史、背景、经历和操作特点； e交叉访问表。按先后次序进行编排，使一些不完全的软件需求得以完善； f特殊的装配指令用于编码和媒体，以满足安全、输出、初始装入或其他要求。 注：当包括附录时，需求说明必须明确地说明附录是不是需求要考虑的部分。,6.5.2 实际系统示例,会议信息管理系统 软件需求规格说明书版本： 文档编号： 001 密 级：秘密 编 写：许明强 编写日期：2011/10/1 审 核：刘映师 审核日期: 2011/10/7 批 准：缪少豪 批准日期：2011/10/12,1 引言 1.1 编写目的 本需求规格文档的目的是说明会议管理系统最终需要满足的条件和限制，为进一

32、步设计和实现提供依据。本文档将用户的需求用文字的形式固定下来，是与用户沟通的成果。也是用户验收项目时的参考。 本文档将供本系统全体软件开发组团队成员查阅和使用，其中包括系统设计人员、编程人员、测试人员。,1.2 项目背景 1.2.1 系统名称：会议信息管理系统 1.2.2 需求背景：随着我国经济的发展，学术会议、产业会议等越来越多，会议规模、会议流程也越来越复杂。所以，对实现会议的电子化管理有着迫切的需求。 1.2.3 系统用途：本系统利用网络平台，搭建通用的会议管理模板工具，帮助会议主办方更加电子化、智能化地管理各项会议工作，从而大大减少人工的参与。 1.2.4 系统使用范围：本系统主要面向

33、参会人数在1000人以内的会议。 1.2.5 系统开发人员：本系统由软件开发组团队完成的需求分析、设计到编码、测试、发布的全部过程中的所有相关人员。,1.3 相关文件 a会议管理系统设计说明书 b会议管理测试系统报告 c会议管理系统用户手册 2 任务总体描述 2.1 目标 由于多数会议管理在流程上的相似性，本系统旨在减少其中的重复工作，提高管理工作的正确性和效率。系统的目标是将人工参与的工作量减少50%，效率提高30%，同时使会议管理工作规范化、程序化。,2.2 系统使用用户 本系统的最终可能用户是党政/行政机关中会议的主办方、组织方、经常举办、承办会议的各种社会组织，中、小型企业等。操作人与

34、必须熟悉计算机的基本操作，维护人员的教育水平普遍应在本科学历以上在电脑方面有所专长。如果本系统开发成功。可用性极强。 2.3 系统使用前景 基于中国目前会议数量和规模的递增趋势，在一般的企事业单位中，本系统的预期使用频度应在15天，即平均每隔15天就会用使用该系统的需求产生。,2.4 非技术要求 本系统的开发周期为一个月左右。开发流程为：需求分析设计编码实现单元测试集成和系统测试交付，其中需求分析的更新贯穿于整个开发过程。 要交付的工作产品有：需求规格说明书、设计说明书、测试报告、用户手册、源代码、可执行程序。 本软件系统开发过程中的主要阶段:2011-10-24日验收需求分析结果，2011-

35、10-28日验收设计结果，2011-11-9日验收编码结果，2011-11-16日验收集成和系统测试结果。,2.5 系统运行环境,2.5.1 硬件运行环境 服务器 处理器型号：AMD/Intel 2.8GHZ及以上 内存容量：1GB及以上 外存剩余空间；100M网卡 签到客户机 处理器型号；AMD/Intel 1.6MHZ及以上 内存容量：512MB及以上 外存剩余空间：1GB及以上 网络配置：100M网卡、RS232串口、PS2接口 如果电脑无RS232串口、PS2接口，需购买USB to RS232、USB to PS转换线。 Web浏览PC机 处理器型号：AMD/Intel 1.6GMZ

36、及以上 内存容量：256MB及以上 外存剩余空间：200M及以上 网络配置：100M网卡,读卡器: 读卡器是非接触式的IC卡读卡器，可以读取RF（镭射）类型的非接触式IC卡。所采用的读卡器具有PS2接口（用手供电）、RS232串口（用于传输数据）。本系统采用的读卡器是北京航空航天大学校园一卡通所用的读卡器，校方可以为开发团队提供该读卡器。 2.5.2 软件运行环境 服务器 操作系统：windows XP Web服务器：TOMCAT7.0 数据库：MYSQL,3 外部接口需求,3.1 系统构架 本系统的网络拓补图如下图所示。,3.2 系统流程图,本系统采用C/S结构,由桌面程序构成。桌面程序为会

37、议组织人员提供登陆会议系统并且对会议的全程管控、的签到、查看参会情况、以及记录反馈统计结果等功能。另外参会者可以通过此系统登陆并查看会议的基本信息。,4 性能需求,4.1 正确性需求 系统正确性需求主要包括如下三项： a系统应能够把会议组织人员所创建的会议的相关信息以及参会人员信息准确地导入数据库中。 b与会者签到时，系统应能正确地读取相关信息并对到会情况进行统计。 c系统要能够正确地将会议通知、反馈表填写通知等信息发送到参会人员邮箱。 4.2 安全性需求 系统用于存储会议、参会人员等信息的数据库应具有很高的安全性，会议组织人员登录数据应加密后再通过网络传输。,4.3 界面需求 系统对界面的需求分为两部分：网站和客户端。这两部分有不同的界面需求： 客户端部分：组织者登陆窗口和进入管理端的窗口必须简洁清晰，参会人员签到时看到的窗口应很清晰，且比较美观，其他窗口布局较合