案例一 实验教学管理系统分析
【任务描述】
信息工程学院的实验教学管理文档一直采用纸质文件，每个学期都要产生大量纸质文档，这些文档保存不便、填写麻烦、数据统计分析困难，难以管理。采用结构化方法开发实验教学管理系统，需要确定系统是否值得开发、调查用户的需求，主要包括如下内容：
● 系统可行性分析
● 选择软件过程模型
● 分析系统需求
【任务分析】
结构化分析一般包括可行性分析、选择模型、需求分析。可行性分析通过对系统进行问题定义及经济可行性、技术可行性、法律可行性、用户使用可行性等方法的分析，确定系统是否值得开发。在需求分析阶段需要同用户进行深入沟通，准确把握用户需求，可以通过Visio工具建立功能模型、数据模型和行为模型。
【实施方案】
任务1 实验教学管理系统可行性分析
1.1 调研软件开发背景
（1）调研用户工作现状，分析软件开发背景。说明项目在什么条件下提出，提出者的要求、目标、实现环境和限制条件。
信息工程学院实验教学管理一直采用人工管理方式，实验过程中产生的大量数据都采用纸质文档记录，包括实验报告、实验室使用记录、实验仪器使用记录、实验室课表等。随着学生人数增多和办学历史延伸采用纸质文档的弊端越来越明显，学校需要印制、保存大量纸质文档，学生填写麻烦、容易出错，数据统计困难、不准确等，不利于管理和决策。我们需要一个管理信息系统使纸质文档电子化、帮助管理实验过程中的数据，实现管理规范化。
（2）确定供需双方。
软件用户方：信息工程学院。
软件开发方：软件孵化中心。
1.2 问题定义
调研软件细节，明确问题定义。在初步调研的基础上，逐步确定将要研发软件的具体问题。开发人员对用户提出的开发问题还需要从专业技术方面进行更深层次的细致调研、分析和定义，主要包括：软件名称、软件提出的背景、软件目标、软件类型、软件服务范围、基本需求、软件环境、主要技术、基本条件等。
（1）软件名称：实验教学管理系统。
（2）软件背景：每个学期都会产生大量实验教学文档，纸质文档保存不便、统计分析困难、浪费资源，迫切需要对这些纸质文档电子化，实现管理规范、节约资源。
（3）软件目标：能够实现实验报告、实验室使用记录、实验仪器使用记录等文档电子化，能够统计人时数、实验开出率、各类实验的比率、一学期的实验总数等数据进行统计分析。
（4）软件类型：专用软件。
（5）软件服务范围：软件先在信息工程学院实验教学中使用，随后可以扩展到其他院系。
（6）基本需求：能够对学期、教师、学生、实验室、实验课表、实验报告、实验室和仪器使用记录等进行管理，对实验室使用、实验开出率、实验报告成绩、实验人时数等数据进行统计分析。能够适合多数人同时使用，反应速度快，界面简洁，易于操作，每天能够持续工作24小时。
（7）软件环境：软件服务器端可以在Windows、Linux、UNIX等平台下运行，Web服务器Tomcat 6.0，数据库：MySQL，客户端采用Chrome或360浏览器。
（8）主要技术：软件开发采用结构化方法。具体为：可以采取访谈和实地调研获得分析，建模采用Visio工具辅助建立功能模型、数据模型和动态模型；设计采用成熟的B/S体系结构和SSH框架；编程阶段采用SVN进行统一管理，测试采用WinRunner和LoadRunner进行功能和性能测试。
（9）基础条件：软件由信息工程学院软件孵化中心开发，开发人员经验丰富；用户方是计算机教师和学生，熟悉软件开发流程方便沟通。
1.3 经济可行性分析
从投资和预期经济效益上进行分析经济上是否可行。包括基本建设投资（如开发环境、设备、软件和资料等），其他一次性和非一次性投资（如技术管理费、培训费、管理费、人员工资、奖金和差旅费等）。
（1）软件孵化中心成立3年，主要人员是软件工程专业的老师和学生，拥有专业实验室，配备专门服务器和计算机，软硬件资源齐全。实验教学管理系统的开发得到全院师生的支持，调研方便，实验教学资料齐全。开发经费全部由学院支付，软件开发人员也是软件用户的一部分，可以节省培训费、差旅费等。
（2）软件投入使用后每年节约纸张费用3万元、节约管理费用3万元，此外还能节约师生填写时间和管理者统计分析数据时间，提高管理效率。
（3）实验教学在很多学校都是管理上的难题，如果该系统投入使用效果好，可以推广到全校、甚至其他院校使用，将获得更大收益，节约更多资源。
（4）软件市场前景好，预期收益大，在经济上可行。
1.4 技术可行性分析
分析现有资源能否满足软件开发。现有资源（如人员、环境、设备和技术条件等）能否满足此工程和项目实施要求，若不满足，应考虑补救措施（如需要分承包方参与、增加人员、投资和设备等），最后确定此工程和项目是否具备技术可行性。
（1）信息工程学院软件孵化中心现有人员15名，其中教师6名，学生9名。中心成立3年来完成各类项目5项，教师经验较丰富，学生学习能力强，有时间和精力完成项目。
（2）软件将采用MyEclipse、Tomcat、MySQL等软件进行开发，这些软件稳定，应用范围广。主要应用JSP、HTML、JavaScript、JavaBean、Servlet、SSH等技术，这些技术已经成熟，很好地适应了交互站点设计和基于Web的数据库访问的要求，也能够实现功能扩充。
（3）软件开发需要的硬件环境已经具备，软件环境已经搭建，网络环境已经配置。
（4）现有资源可以满足软件实施要求，具备技术可行性。
1.5 法律可行性分析
分析软件开发是否违反法律。
政府，无论是中央政府还是地方政府，一般都用法律规定组织可以做什么，不可以做什么。例如：《合同法》《消费者权益保护法》《专利法》《反不正当竞争法》等对所有企业的行为都做了限制。法规的影响不仅仅限于时间和金钱，它还缩小了管理者可斟酌决定的范围，限制了可行方案的选择。根据《中华人民共和国计算机软件保护条例》（1991年6月4日中华人民共和国国务院令第84号发布）可知实验教学管理系统的开发不存在侵权、违法和责任，在法律上可行。
1.6 用户使用可行性分析
用户单位的行政管理和工作制度；使用人员的素质和培训要求。
从实验教学管理系统的使用人员来看，可大致分为四类：
（1）学生：信息工程学院的所有学生和全校其他院系的大一学生；
（2）教职工：信息工程学院的有实验教学任务的老师；
（3）实验管理人员：实验室的管理人员和实验室主任；
（4）院系领导：信息工程学院的领导和其他部分分管实验教学的领导。
用户的素质较高，大部分受过或正在接受本科教育，可以在软件使用前进行培训。软件系统友好的界面及简便的操作方法，能满足用户使用该系统的要求。
1.7 结论
鉴于以上分析，实验教学管理系统投资少，具有较高的经济效益和社会效益。该项目在经济、技术、法律和用户使用上都是可行的，可以立即立项开发。
1.8 可行性分析报告模板
1 引言
本章分为以下几条。
1.1 标识
本条应包含本文档适用的系统和软件的完整标识，（若适用）包括标识号、标题、缩略词语、版本号和发行号。
1.2 背景
说明项目在什么条件下提出，提出者的要求、目标、实现环境和限制条件。
1.3 项目概述
本条应简述本文档适用的项目和软件的用途，它应描述项目和软件的一般特性；概述项目开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出其他有关的文档。
1.4 文档概述
本条应概述本文档的用途和内容，并描述与其使用有关的保密性和私密性的要求。
2 引用文件
本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。本章也应标识不能通过正常的供货渠道获得的所有文档的来源。
3 可行性分析的前提
3.1 项目的要求
3.2 项目的目标
3.3 项目的环境、条件、假定和限制
3.4 进行可行性分析的方法
4 可选的方案
4.1 原有方案的优缺点、局限性及存在的问题
4.2 可重用的系统，与要求之间的差距
4.3 可选择的系统方案1
4.4 可选择的系统方案2
4.5 选择最终方案的准则
5 所建议的系统
5.1 对所建议的系统的说明
5.2 数据流程和处理流程
5.3 与原系统的比较（若有原系统）
5.4 影响（或要求）
5.4.1 设备
5.4.2 软件
5.4.3 运行
5.4.4 开发
5.4.5 环境
5.4.6 经费
5.5 局限性
6 经济可行性（成本—效益分析）
6.1 投资
包括基本建设投资（如开发环境、设备、软件和资料等），其他一次性和非一次性投资（如技术管理费、培训费、管理费、人员工资、奖金和差旅费等）。
6.2 预期的经济效益
6.2.1 一次性收益
6.2.2 非一次性收益
6.2.3 不可定量的收益
6.2.4 收益/投资比
6.2.5 投资回收周期
6.3 市场预测
7 技术可行性（技术风险评价）
本公司现有资源（如人员、环境、设备和技术条件等）能否满足此工程和项目实施要求，若不满足，应考虑补救措施（如需要分承包方参与、增加人员、投资和设备等），涉及经济问题应进行投资、成本和效益可行性分析，最后确定此工程和项目是否具备技术可行性。
8 法律可行性
系统开发可能导致的侵权、违法和责任。
9 用户使用可行性
用户单位的行政管理和工作制度；使用人员的素质和培训要求。
10 其他与项目有关的问题
未来可能的变化。
11 注解
本章应包含有助于理解本文档的一般信息（例如原理）。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。
附录
附录可用来提供那些为便于文档维护而单独出版的信息（例如图表、分类数据）。为便于处理附录可单独装订成册。附录应按字母顺序（A, B等）编排。
任务2 选择软件过程模型
实验教学管理系统由信息工程学院提出，经过分析符合立项开发的条件，需要根据项目的性质选择软件开发模型。软件开发模型是软件开发全部过程、活动和任务的结构框架，能清晰、直观地表达软件开发全过程，明确规定完成的主要活动和任务，是软件项目工作的基础。
实验教学管理系统主要管理基础数据、实验报告、实验项目、实验室使用记录、实验仪器使用记录等，需求明确、规模不大、且不复杂，可以采用瀑布模型。瀑布模型各阶段过程如下：经过可行性分析，若结论可行则进行需求分析；评审合格输出需求分析文档，进入软件设计，在设计中遇到不合适的地方，回溯到需求分析；软件设计完成输出软件设计文档，进入软件实现阶段，若实现中出问题可以回溯到软件设计和软件需求阶段；软件实现完成后输出源文件，进入软件测试；软件测试完成后输出源程序、各阶段文档，进入软件维护阶段，维护阶段可能回溯到其他任何阶段，模型如图2-1所示。
图2-1 瀑布模型
采取瀑布模型后可以管理软件开发进度、消除软件开发风险、保证软件质量。采用瀑布模型必须完成以下工作：
（1）每一阶段都要完成规定的文档。没有完成文档，就认为没有完成该阶段的任务。
（2）每一阶段都要对完成的文档进行复审，以便尽早发现问题，消除隐患。
任务3 实验教学管理系统需求分析
3.1 需求获取
3.1.1 获取业务需求
信息工程学院的实验数据如实验报告、实验室使用记录、实验仪器使用记录等都采用纸质记录，造成保存不便，统计检索速度慢、不准确，管理繁琐，数据不完整等。实验教学管理系统能够实现实验数据电子化，方便对实验教学过程中产生的数据进行管理，节约教师学生实验时间、节约人力物力资源，方便教学管理人员对数据进行统计分析，提高实验教学管理效率，促进管理规范化、信息化、正规化。
3.1.2 获取用户需求
系统主要角色分三类：学生、教师、管理员。
管理员所需主要功能包括：学生管理、教师管理、机构管理、课程管理、课表管理、仪器使用记录管理、实验室管理、统计管理、课表管理、管理员管理、注销等功能。
教师所需主要功能包括：个人信息管理、实验室使用记录管理、师生交流、批改报告、实验报告成绩管理、实验项目管理、注销等功能。
学生所需主要功能包括：个人信息管理、仪器使用记录管理、师生交流、实验报告管理、查看实验报告成绩、注销等功能。
3.1.3 确定功能需求
（1）学生管理：管理员输入学生信息保存到学生表，也可以批量导入学生信息；按院系、专业、班级查询全部的学生，并对选定的学生可以进行查看详情、更新、删除等操作；学生可以查看个人信息详情（包括登录账号和密码）；教师可以查询所教班级的学生。
（2）教师管理：管理员输入教师信息保存到教师表，也可以批量导入教师信息；查询所有教师，对选定的教师可以进行查看详情、更新、删除等操作；教师可以查看个人信息详情（包括登录账号和密码）。
（3）机构管理：管理员输入院系、专业、班级信息保存到院系表、专业表、班级表。院系中有专业、专业中有班级、班级中有学生。管理员可以按照级别查询全部的院系、专业和班级，可以查看院系、专业、班级详情。当管理员进入不同级别的机构时，就可以在对应级别的机构创建、修改相应的机构。管理员只能删除再无子机构的机构，然后才能删除父机构，也可以打印当前的数据页面。
（4）课程管理：管理员输入课程信息保存到课程表，可以查询全部的课程，并对选定的课程可以查看详情，进行更新、删除等操作，也可以打印当前的数据页面。
（5）学期管理：管理员添加学期信息保存到学期表，默认新添加的学期为当前学期，也可以查询学期信息列表、对选定的学期信息进行修改。
（6）课表管理：管理员输入上课信息（包括上课时间、地点、课程、教师等）保存到课表，也可以批量导入。还可以按实验室查询上课时间，修改和删除上课信息，也可打印课表。
（7）实验室管理：管理员录入实验室信息保存到实验室表，可以查询实验室使用状态和详细信息，并可进行修改、删除等操作。
（8）仪器使用记录管理：学生在实验时填写仪器使用记录并保存到仪器使用记录表，教师和学生都可以查看详情，对于写错的记录，学生可以删除。教师在上课时间可以查询班级全部记录，还可以导出excel表以便于统计。管理员可以按学期和实验室查询某个实验室的学生仪器使用记录。
（9）实验室使用记录管理：教师在实验时填写实验室使用记录，并可以修改和删除当前实验室使用记录。教师可以查询本人以往实验室使用记录，并可以查看详情。管理员可以按学期和实验室查询教师使用记录，并可以查看详情，还可以导出成excel表。
（10）实验项目管理：教师添加实验项目信息保存到实验项目表，也可以修改、删除实验项目、查看详情。管理员按学期、院系、专业、课程、类型查询实验项目，可以查看详情，也可以打印。
（11）统计管理：管理员可以按院系、专业统计实验项目数、实验类型统计、实验人时数统计、实验室的使用率、实验开出率等信息。
（12）实验报告管理：学生填写实验报告并保存到实验报告表，在教师批改之前可以查看详情、修改、删除实验报告。教师可以查询自己课程下提交的所有实验报告、查看实验报告详情，可以导出所有实验报告、批改实验报告，查看实验报告成绩、统计学生成绩。学生可以查看教师对本人此次实验的评语和分数。
（13）密码修改：学生和教师可以修改自己的密码并保存到学生表和教师表中。
（14）师生交流：学生可以选择教师进行交流，保存到留言表；教师可以看到学生的留言，回复学生留言。
（15）注销：学生、教师、管理员登录系统后可以进行注销。
3.1.4 分析性能需求
正确性需求：系统能够将添加的部门、学生、教师、实验报告、实验项目等基本信息准确地保存到数据库中。实验相关数据能够正确读取，统计信息要准确。
安全性需求：实验数据应具有高安全性，需要所有用户登录后才能访问数据。用户10分钟内不进行任何操作，账号自动退出系统。
并发能力：系统最少用户数量20000人，最大业务并发用户数不低于1000人，系统数据库应能同时对一定数量（200人）数据信息进行存储。
处理时间：系统部署后，在硬件条件和支持软件条件没有发生变化的情况下，能够一直保持运行状态，直到系统被升级或替代。
响应速度：学生、教师和管理员能在0.2秒内登录系统，并正确进入到用户界面，所有人员在查询、修改、添加、删除信息时能够在0.5秒内返回执行结果。
数据恢复：系统出现故障时能恢复到最近的正确状态。
3.1.5 分析其他需求
开放性：具有良好的可扩充性和可移植性。系统遵循主流的标准和协议，提供与学校现正在使用平台统一的接口。
界面友好：要求操作界面美观大方，布局合理，色彩搭配和谐。系统针对不同角色的用户可提供不同的界面内容和界面形式。
一致性要求：软件系统应该符合主流软件的标准，快捷键、语言、基本操作流程、交互等设置符合主流软件。
3.2 分析建模
3.2.1 建立功能模型
（1）绘制顶层数据流图
根据功能描述，找出外部实体，把整个系统看成一个加工，找出每个实体与系统之间的输入、输出信息。
实验教学管理系统中的实体有3个，分别是教师、学生和管理员。教师与系统的交互主要是实验项目、留言查看与回复、实验室使用记录、实验报告查看与批改、仪器使用记录查看；学生与系统的交互主要是实验报告提交及批改查看、留言及查看回复、仪器使用记录提交与查看；管理员与系统的交互主要是基础数据的录入与管理、统计信息、查询信息等。顶层数据流图如图2-2所示。
图2-2 顶层数据流图
顶层图中数据流说明如下。
统计信息：对实验项目类型及其比率、实验开出率、实验室使用情况、实验人时数、学期实验数等数据的统计分析，来自系统，流向管理员。
基础数据信息：包括学期、院系、专业、班级、实验室、课程、学生、教师、管理员等基本信息，来自系统，流向管理员。
查询信息请求：查询学期、院系、专业、班级、实验室、课程、学生、教师、管理员、仪器使用记录、实验室使用记录、实验报告、实验项目等信息，来自系统，流向管理员。
使用记录：获得实验室使用记录和仪器使用记录，来自系统，流向管理员。
添加请求：请求添加仪器使用记录、留言和实验报告，来自学生，流向系统。
学生查看请求：学生可以请求查看的内容包括仪器使用记录、留言、实验报告、实验报告成绩、个人信息等，来自系统，流向学生。
查看结果：系统显示学生请求查看的信息。
拒绝的请求：不允许学生进行的操作系统给出的拒绝信息。
新增请求：增加实验室实验记录、实验项目、回复留言的请求，来自教师，流向系统。
教师查询请求：查询学生、实验室记录、仪器使用记录、个人信息等信息的请求，来自教师，流向系统。
查询结果：教师查询的学生仪器使用记录、实验项目、实验报告、实验室使用记录等信息的显示。来自系统，流向教师。
拒绝的请求：非上课时间查询学生仪器使用记录被拒绝，来自系统，流向教师。
（2）绘制0层数据流图
0层数据流图是细化了的顶层数据流图。根据实验教学管理系统功能，细化顶层加工绘制0层数据流图。实验教学管理系统可以细化为6个子加工：基础数据管理（包括学期、院系、专业、班级、实验室、学生、教师、课程等）、实验室记录管理、实验项目管理、实验报告管理、仪器使用记录管理、留言管理，如图2-3所示。
图2-3 0层数据流图
0层图的加工和数据流说明如下。
1）加工说明
基础数据管理：管理员对学期、院系、专业、班级、实验室、课程、上课安排、学生、教师、管理员等信息进行管理，可以进行新增、修改、查询、删除等操作。
实验室记录管理：教师添加实验室使用记录，可以对其进行修改、查询、删除操作。管理员可以查询、统计。
实验项目管理：教师添加实验项目，可以对其进行修改、查询、删除操作。管理员可以查询、统计。
实验报告管理：学生添加实验报告并可以查看，在教师批改之前可进行修改、删除。教师可以查看、批改、导出实验报告，管理员也可以查看。
仪器使用记录管理：学生添加仪器使用记录，可以删除、查询。教师和管理员可以查询、导出。
留言管理：学生可以对指定教师留言，并查看留言和教师的回复。教师可以查看学生给自己的留言并回复。
2）数据流说明
基础数据信息：基础数据包括学期、院系、专业、班级、实验室、课程、上课安排、学生、教师、管理员等信息，来自管理员，流向系统。
统计项目请求：统计实验项目的请求，来自管理员，流向系统。
项目统计信息：根据实验类型、课程、学期等条件进行实验项目统计的信息，来自系统，流向管理员。
统计请求：统计实验室使用记录的请求，来自管理员，流向系统。
实验室记录：根据管理员的统计条件返回统计信息，来自系统，流向管理员。
统计记录请求：请求统计实验仪器使用记录，来自管理员，流向系统。
仪器记录统计信息：根据管理员的统计条件，返回统计结果，来自系统，流向管理员。
添加请求：学生添加实验报告的请求，来自学生，流向系统。
查看请求：学生查看本人的实验报告和实验报告成绩的请求，来自学生、流向系统。
实验报告成绩：学生本人的实验报告成绩，来自系统，流向学生。
留言请求：学生留言的请求，来自学生，流向系统。
教师的回复：教师对留言的回复信息，来自系统，流向学生。
添加记录请求：学生添加仪器使用记录的请求，来自学生，流向系统。
仪器使用记录：学生查询本人的仪器使用记录信息，来自系统，流向学生。
添加项目请求：教师添加实验项目的请求，来自教师，流向系统。
查询项目请求：教师查询实验项目的请求，来自教师，流向系统。
报告列表：根据教师的查询条件，返回学生的实验报告列表信息，来自系统，流向教师。
查询报告请求：教师请求查看所教课程的实验报告，来自教师，流向系统。
回复的留言：教师回复学生留言信息，来自教师，流向系统。
查询记录请求：教师请求查询当前上课班级的实验仪器使用记录，来自教师，流向系统。
记录列表：根据教师的查询条件，返回当前上课班级的学生仪器使用记录，来自系统，流向教师。
新增实验室记录请求：教师新增实验室仪器使用记录，来自教师，流向系统。
项目信息：实验项目的名称、类型、学时、实验要求等信息，来自实验项目管理，流向实验报告管理。
课程信息：实验课程的名称、上课教师等信息，来自基础数据管理，流向实验报告管理。
（3）绘制1层数据流图
对每一个加工继续细化。如果加工内还有数据流，可将该加工再细分成几个子加工，并在各子加工之间画出数据流，形成第1层数据流图。本书以实验项目管理、实验报告管理和实验仪器使用记录管理为例。
1）实验项目管理加工可以细化为添加、删除、查询、修改、统计5个子加工，每个子加工都需要与数据存储实验项目表进行交互，数据流图如图2-4所示。
图2-4 1层数据流图——实验项目管理
① 加工说明
添加：教师填写实验项目名称、类型、学时、目标、内容等信息，验证合格后保存到实验项目表中。
查询：教师可以查看自己课程的实验项目，选择一个可以查询项目详细信息。
修改：教师查看项目列表，选择需要修改的项目，读取原来的内容，进行修改，验证合格后将项目保存到实验项目表中。
删除：教师可以删除一个或多个项目。
统计：管理员可以统计一门课程的项目数，可按学期、专业统计实验类型、实验数量、类型比率等统计。
② 数据流说明
添加项目请求：教师添加实验项目的请求。
查询请求：教师查询本人添加的实验项目请求。
删除请求：教师请求删除选定的实验项目请求。
修改请求：教师请求修改选定的实验项目的请求。
添加的项目：教师新增的实验项目。
删除的项目：选定的需要删除的实验项目。
修改的信息：教师修改后的实验项目。
统计请求：管理员统计实验项目的请求，包括根据学期、课程、实验类型等条件的请求。
项目统计信息：根据管理员输入的条件，返回统计信息。
项目信息：实验项目的信息，包括项目名称、性质、学时、项目要求等。
③ 数据存储及数据项说明
实验项目表=项目ID+项目名称+项目类型+项目目的+项目环境+项目状态+开课课程+教师ID+开设学期。
项目ID：整型，长度11，不允许为空。
项目名称：字符类型，长度20，不允许为空。
项目类型：字符类型，长度20，不允许为空。
项目目的：字符类型，长度255，不允许为空。
项目环境：字符类型，长度255，不允许为空。
项目状态：字符类型，长度11，不允许为空。
开课课程：字符类型，长度11，不允许为空。
教师ID：整型，允许空。
开设学期：字符类型，长度11，不允许为空。
2）实验报告管理可以细化为批改、导出、成绩统计、查看、修改、添加、查看成绩7个子加工，每个加工都要同实验报告表进行交互，为了避免数据流交叉，将实验报告表出现2次（如果需要也可以出现多次）。与数据存储相连的数据流可以没有名称，其他数据流必须有名称，如图2-5所示。
图2-5 1层数据流图——实验报告管理
① 加工说明
添加：学生请求添加实验报告，按照实验学期、项目、姓名、班级、实验室，填写实验目的、内容、结论等信息，验证合格后保存到实验报告表中。只有已提交的实验报告，教师才能看到。
查看：学生可以查看所有实验报告（提交的和未提交的）、教师能查看所有提交的实验报告。
修改：学生可以查看自己所有的实验报告，选择一个查看详情并请求修改，将修改信息填写完成后，验证合格保存到实验报告表中。
批改：教师能够查看自己课程的所有学生提交的实验报告，选择一个查看详情进行批改，批改要写评语和给出实验成绩。
导出：教师可以按实验项目导出所有学生提交的实验报告。
成绩统计：教师批改完成后可以查看所有学生的成绩，统计出及格、不及格、优秀学生人数。
查看成绩：教师批改后，学生在实验报告列表中可以看到实验成绩，通过详情可以看到教师的评语和成绩。
② 数据流说明
批改请求：教师请求批改选择的实验报告。
成绩：教师录入的实验报告成绩。
查询请求：教师查询实验报告的请求，请求的条件可根据实验项目和实验班级来查询。学生的查询请求依据学生本人信息和课程来查询。
导出请求：教师请求导出一个班的某个实验项目的所有实验报告请求。
添加报告请求：学生请求添加实验报告。
实验报告：包含课程信息、实验项目、实验室、教师、学期、实验目的、实验要求、实验内容、实验结果等信息的实验报告。
拒绝信息：教师批改实验报告后，学生提出请求修改实验报告被拒绝的信息。
③ 数据存储及数据项说明
A．实验报告表=实验报告ID+学期+课程+实验项目ID+班级+学生+实验室+填写时间+内容+结果+评语+成绩+教师ID+批阅时间+实验报告状态。
实验报告ID：整型，长度11，不允许为空。
学期：字符类型，长度11，不允许为空。
课程：字符类型，长度11，不允许为空。
实验项目ID：整型，长度11，不允许为空。
班级：字符类型，长度11，不允许为空。
学生：字符类型，长度11，不允许为空。
实验室：字符类型，长度11，不允许为空。
填写时间：字符类型，长度30，不允许为空。
内容：文本类型，允许空。
结果：文本类型，允许空。
评语：文本类型，允许空。
成绩：浮点类型，不允许为空。
教师ID：整型，可以为空。
批阅时间：字符类型，长度20，允许空。
实验报告状态：整型，长度11，不允许为空，取值0、1、2。
B．学期表=学期ID+学期名称+学期状态
学期ID：整型，长度11，不允许为空，主键。
学期名称：字符类型，长度50，不允许为空。
学期状态：字符类型，长度11，不允许为空。
C．实验室表=实验室ID+实验室编号+实验室名称+实验室位置+实验室机器数量+实验室联系方式+实验室状态
实验室ID：整型，长度11，不允许为空。
实验室编号：字符型10，不允许为空，且不允许重复。
实验室位置：字符型20，允许空。
实验室机器数量：整型，11位，允许空。
实验室联系方式：字符型，20位，允许空。
实验室状态：整型，11位，允许空。
D．课程表=课程ID+课程编号+课程名称+课程类型+课程学分+开设专业+开设学期
课程ID：整型11位，不允许空。
课程编号：字符型，20位，不允许空，唯一。
课程名称：字符型，20位，允许空。
课程类型：字符型，20位，允许空。
课程学分：浮点型，允许空。
开设专业：整型11位，与专业表关联。
开设学期：整型11位，与学期表关联。
E．教师表=教师ID+教师工号+教师姓名+教师职称+教师密码+教师性别+教师电话+教师院系
教师ID：整型，11位，不允许空。
教师工号：字符型，15位，不允许空，唯一。
教师姓名：字符型，20位，不允许空。
教师职称：字符型，20位，不允许空。
教师密码：字符型，50位，不允许空。
教师性别：字符型，4位，允许空。
教师电话：字符型20位，允许空。
教师院系：整型11位，不允许空，与院系表关联。
3）仪器使用记录管理
仪器使用记录管理可以细化为添加仪器使用记录、删除仪器使用记录、查询仪器使用记录、导出仪器使用记录、统计仪器使用记录5个子加工，每个子加工都需要与数据存储实验仪器使用记录表进行交互，其数据流图如图2-6所示。
图2-6 仪器使用记录管理数据流图
数据存储及数据项说明如下：
A．班级表=班级ID+班级编号+班级名称+学生人数+所属专业
班级ID：整型11位，不允许为空。
班级编号：字符型8位，不允许空。
班级名称：字符型20位，允许空。
学生人数：整型11位，允许空。
所属专业：整型11位，与专业表关联。
B．课表=课ID+周几+上课时间+单双周+学期ID+班级ID+实验室ID+课程ID+教师ID
课ID：整型11位，不允许空。
周几：字符型15位，允许空。
上课时间：字符型15位，允许空。
单双周：字符型15位，允许空。
学期ID：整型11位，与学期表关联。
班级ID：整型11位，与班级表关联。
实验室ID：整型11位，与实验室表关联。
课程ID：整型11位，与课程表关联。
教师ID：整型11位，与教师表关联。
C．仪器使用记录表=仪器使用记录ID+仪器使用记录日期+运行启动时间+运行终止时间+实际使用时数+仪器使用附件+设备编号+机器IP+项目ID+学生ID+教师ID+班级ID+实验室ID+学期ID
仪器使用记录ID：整型11位，不允许空。
仪器使用记录日期：字符型20位，允许空。
运行启动时间：字符型15位，允许空。
运行终止时间：字符型15位，允许空。
实际使用时数：浮点型，允许空。
仪器使用附件：字符型20位，允许空。
设备编号：字符型10位，允许空。
机器IP：字符型20位，允许空。
项目ID：整型11位，与项目表关联。
学生ID：整型11位，与学生表关联。
教师ID：整型11位，与教师表关联。
班级ID：整型11位，与班级表关联。
实验室ID：整型11位，与实验室表关联。
学期ID：整型11位，与学期表关联。
4）根据自顶向下，逐层分解的原则，对1层图中全部或部分加工环节进行分解。以修改实验报告为例。得到修改实验报告请求后，首先要检查实验报告的状态，如果教师已经批改过，则不允许修改；若没有批改，则可以修改。修改后的信息要进行检查，如果有必填项是空白，则不允许提交；信息合格，则保存到实验报告表中。其数据流图如图2-7所示。
图2-7 修改实验报告数据流图
数据加工说明如下。
检查状态：系统接收到学生修改请求后，首先检查实验报告状态，若状态为已经批改，则拒绝修改请求；若未批改，则允许修改。
读取内容：从数据库中读取原来的实验内容。
检查：修改的信息是否符合数据要求，不符合则返回不合格的信息，合格进行提交。
提交：将修改后的信息提交到数据库，保存到实验报告表。
5）对图进行检查和合理布局，主要检查分解是否恰当、彻底，DFD中各层是否有遗漏、重复、冲突之处，各层DFD及同层DFD之间关系是否正确及命名、编号是否确切、合理等，对错误及不当之处进行修改。
修改后和用户进行交流，在用户完全理解数据图的内容的基础上征求用户的意见。
3.2.2 建立数据模型
（1）找出所有实体，确定实体属性。
实验教学管理系统的主要实体及其属性如下。
管理员：管理员账号、管理员密码、管理员名字、管理员联系电话。
院系：院系编号、院系名称、院系联系电话、院系地址。
专业：专业编号、专业名称、所属院系。
班级：班级编号、班级名称、班级人数、所属专业。
学生：学生学号、学生姓名、学生性别、学生密码、所属班级。
教师：教师工号、教师姓名、教师性别、教师密码、教师职称、教师电话、所属院系。
实验室：实验室编号、实验室名称、实验室位置、实验室机器数量、实验室联系方式、开放状态。
课程：课程编号、课程名称、课程类型、课程学分、开设专业、开设学期。
实验项目：项目名称、项目类型、项目目的、项目环境、项目状态、开设课程、教师ID、开设学期。
学期：学期名称。
实验仪器使用记录：仪器使用记录日期、工作内容、运行启动时间、运行终止时间、使用附件、设备编号、机器IP、实际使用时数、使用人、教师签名、备注、实验室、学期。
实验室使用记录：实验室使用记录日期、工作内容、实验时间、实验人数、仪器使用情况、设备编号、机器IP、教师签名、实验班级、实验室、学期。
实验报告：学期、课程、项目、班级、学生、实验室、填写实验报告时间、实验内容、实验结果、教师评论、实验报告成绩、教师ID。
课表：学期、班级、实验室、课程、教师、周、上课时间、单双周制。
留言：交流标题、交流内容、交流状态、教师回复、学生、教师。
（2）确定实体间的联系，画出实体联系图（E-R图）。
一个院系可以拥有多个专业，一个专业属于一个院系，关系是一对多。
一个专业可以拥有多个班级，一个班级属于一个专业，关系是一对多。
一个班级可以拥有多个学生，一个学生属于一个班级，关系是一对多。
一个院系可以拥有多个教师，一个教师属于一个院系，关系是一对多。
一个教师可以教授多门课程，一门课程可以被一个或多个教师所教授，授课与教师的关系是多对一，且授课与课程的关系也是多对一，以授课表为连接，实现教师与课程的关系是多对多。
一个课程可以有多个实验项目，一个实验项目属于一个课程，关系是一对多。
一个实验项目可以有多个实验报告，一个实验报告属于一个实验项目，关系是一对多。
一个院系可以有多个实验室，一个实验室属于一个院系，关系是一对多。
一个实验室可以有多个仪器使用记录，一个仪器使用记录属于一个实验室，关系是一对多。
一个实验室可以有多个实验室使用记录，一个实验室使用记录属于一个实验室，关系是一对多。
一个学生可以写多个留言，一个留言属于一个学生，关系是一对多。
一个教师可以写多个留言，一个留言属于一个教师，关系是一对多。
实体及其联系如图2-8所示。
图2-8 E-R图
3.2.3 建立行为模型
（1）确定状态图的主体，可以是一个系统，也可以是一个对象，本书以实验报告和实验项目为例。
（2）确定主题的生存期的各种稳定状态及顺序。
实验报告的状态是：创建、保存、完成、查看、批改、导出、删除。
实验项目的状态是：创建、完成、查看、修改、删除。
（3）确定状态迁移的事件。
● 实验报告状态迁移的事件如下：
创建到保存的事件：暂存。
保存到删除的事件：选择删除。
创建到完成的事件：提交。
保存到完成的事件：提交。
完成到导出的事件：选择导出。
完成到查看的事件：选择查看。
查看到批改的事件：进行批改。
批改到完成的事件：继续批改。
● 实验项目状态迁移的事件如下：
创建到完成的事件：提交。
完成到查看的事件：选择查看。
查看到修改的事件：选择修改。
修改到完成的事件：确定修改。
完成到删除的事件：选择删除。
（4）绘制状态图
实验报告状态图如图2-9所示。
图2-9 实验报告状态图
实验项目状态图如图2-10所示。
图2-10 实验项目状态图
（5）审核状态图，确定每个状态都可以结束。
3.3 软件需求规格说明书模板
1 范围
本章应分为以下几条。
1.1 标识
本条应包含本文档适用的系统和软件的完整标识，也可以包括标识号、标题、缩略词语、版本号和发行号。
1.2 系统概述
本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出其他有关的文档。
1.3 文档概述
本条应概述本文档的用途和内容，并描述与其使用有关的保密性或私密性要求。
1.4 基线
说明编写本系统设计说明书所依据的设计基线。
2 引用文件
本章应列出本文档引用的所有文档的编号、标题、修订版本和发行日期，也应标识不能通过正常的供货渠道获得的所有文档的来源。
3 需求
本章应分以下几条描述CSCI需求，也就是，构成CSCI验收条件的CSCI的特性。CSCI需求是为了满足分配给该CSCI的系统需求所形成的软件需求。给每个需求指定项目唯一标识符，以支持测试和可追踪性。并以一种可以定义客观测试的方式来陈述需求。如果每个需求有关的合格性方法和对系统需求的可追踪性。在相应的章中没有提供，则在此进行注解。描述的详细程度遵循以下规则：应包含构成CSCI验收条件的那些CSCI特性，需方愿意推迟到设计时留给开发方说明的那些特性。如果在给定条中没有需求的话，本条应如实陈述。如果某个需求在多条中出现，可以只陈述一次而在其他条直接引用。
3.1 所需的状态和方式
如果需要CSCI在多种状态和方式下运行，且不同状态和方式具有不同的需求的话，则要标识和定义每一状态和方式，状态和方式的例子包括：空闲、准备就绪、活动、事后分析、培训、降级、紧急情况和后备等。状态和方式的区别是任意的，可以仅用状态描述CSCI，也可以仅用方式、方式中的状态、状态中的方式或其他有效方式描述。如果不需要多个状态和方式，不需人为加以区分，应如实陈述；如果需要多个状态或方式，还应使本规格说明中的每个需求或每组需求与这些状态和方式相关联，关联可在本条或本条引用的附录中用表格或其他的方法表示，也可在需求出现的地方加以注解。
3.2 需求概述
3.2.1 目标
a．本系统的开发意图、应用目标及作用范围（现有产品存在的问题和建议产品所要解决的问题）。
b．本系统的主要功能、处理流程、数据流程及简要说明。
c．表示外部接口和数据流的系统高层次图。说明本系统与其他相关产品的关系，是独立产品还是一个较大产品的组成部分（可用方框图说明）。
3.2.2 运行环境
简要说明本系统的运行环境（包括硬件环境和支持环境）的规定。
3.2.3 用户的特点
说明是哪一种类型的用户，从使用系统来说，有些什么特点。
3.2.4 关键点
说明本软件需求规格说明书中的关键点（例如：关键功能、关键算法和所涉及的关键技术等）。
3.2.5 约束条件
列出进行本系统开发工作的约束条件（例如：经费限制、开发期限和所采用的方法与技术，以及政治、社会、文化、法律等）。
3.3 需求规格
3.3.1 软件系统总体功能/对象结构
对软件系统总体功能/对象结构进行描述，包括结构图、流程图或对象图。
3.3.2 软件子系统功能/对象结构
对每个主要子系统中的基本功能模块/对象进行描述，包括结构图、流程图或对象图。
3.3.3 描述约定
通常使用的约定描述（数学符号、度量单位等）。
3.4 CSCI能力需求
本条应分条详细描述与CSCI每一能力相关联的需求。“能力”被定义为一组相关的需求。可以用“功能”“性能”“主题”“目标”或其他适合用来表示需求的词来替代“能力”。
3.4.1 （CSCI能力）
本条应标识必需的每一个CSCI能力，并详细说明与该能力有关的需求。如果该能力可以更清晰地分解成若干子能力，则应分条对子能力进行说明。该需求应指出所需的CSCI行为，包括适用的参数，如响应时间、吞吐时间、其他时限约束、序列、精度、容量（大小/多少）、优先级别、连续运行需求、和基于运行条件的允许偏差。部分软件需求还应包括在异常条件、非许可条件或越界条件下所需的行为，错误处理需求和任何为保证在紧急时刻运行的连续性而引人到CSCI中的规定。在确定与CSCI所接收的输入和CSCI所产生的输出有关的需求时，应考虑在本文3.5.x给出要考虑的主题列表。
对于每一类功能或者对于每一个功能，需要具体描写其输入、处理和输出的需求。
a．说明
描述此功能要达到的目标、所采用的方法和技术，还应清楚说明功能意图的由来和背景。
b．输入
包括：
1）详细描述该功能的所有输入数据，如：输入源、数量、度量单位、时间设定和有效输入范围等。
2）指明引用的接口说明或接口控制文件的参考资料。
c．处理
定义对输入数据、中间参数进行处理以获得预期输出结果的全部操作。包括：
1）输入数据的有效性检查。
2）操作的顺序，包括事件的时间设定。
3）异常情况的响应，例如，溢出、通信故障、错误处理等。
4）受操作影响的参数。
5）用于把输入转换成相应输出的方法。
6）输出数据的有效性检查。
d．输出
1）详细说明该功能的所有输出数据，例如，输出目的地、数量、度量单位、时间关系、有效输出范围、非法值的处理、出错信息等。
2）有关接口说明或接口控制文件的参考资料。
3.5 CSCI外部接口需求
本条应分条描述CSCI外部接口的需求。外部接口需求，应分别说明：
a．用户接口；
b．硬件接口；
c．软件接口；
d．通信接口的需求。
3.5.1 接口标识和接口图
本条应标识所需的CSCI外部接口，也就是CSCI和与它共享数据、向它提供数据或与它交换数据的实体的关系。每个接口标识应包括项目唯一标识符，并应用名称、序号、版本和引用文件指明接口的实体（系统、配置项、用户等）。该标识应说明哪些实体具有固定的接口特性（因而要对这些接口实体强加接口需求），哪些实体正被开发或修改（从而接口需求已施加给它们）。可用一个或多个接口图来描述这些接口。
3.5.2 （接口的项目唯一标识符）
本条（从3.5.2开始）应通过项目唯一标识符标识CSCI的外部接口，简单地标识接口实体，根据需要可分条描述为实现该接口而强加于CSCI的需求。该接口所涉及的其他实体的接口特性应以假设或“当[未提到实体]这样做时，CSCI将……”的形式描述，而不描述为其他实体的需求。本条可引用其他文档（如：数据字典、通信协议标准、用户接口标准）代替在此所描述的信息。需求也可以包括下列内容：
a．CSCI必须分配给接口的优先级别；
b．要实现的接口的类型的需求（如：实时数据传送、数据的存储和检索等）；
c．CSCI必须提供、存储、发送、访间、接收的单个数据元素的特性，如：
1）名称/标识符；
a）项目唯一标识符；
b）非技术（自然语言）名称；
c）标准数据元素名称；
d）技术名称（如代码或数据库中的变量或字段名称）；
e）缩写名或同义名；
2）数据类型（字母数字、整数等）；
3）大小和格式（如：字符串的长度和标点符号）；
4）计量单位（如：米、元、纳秒）；
5）范围或可能值的枚举（如：0～99）；
6）准确度（正确程度）和精度（有效数字位数）；
7）优先级别、时序、频率、容量、序列和其他的约束条件，如：数据元素是否可被更新和业务规则是否适用；
8）保密性和私密性的约束；
9）来源（设置/发送实体）和接收者（使用/接收实体）；
d．CSCI必须提供、存储、发送、访问、接收的数据元素集合体（记录、消息、文件、显示和报表等）的特性，如：
1）名称/标识符；
a）项目唯一标识符；
b）非技术（自然语言）名称；
c）技术名称（如代码或数据库的记录或数据结构）；
d）缩写名或同义名；
2）数据元素集合体中的数据元素及其结构（编号、次序、分组）；
3）媒体（如盘）和媒体中数据元素/数据元素集合体的结构；
4）显示和其他输出的视听特性（如：颜色、布局、字体、图标和其他显示元素、蜂鸣器以及亮度等）；
5）数据元素集合体之间的关系。如排序/访问特性；
6）优先级别、时序、频率、容量、序列和其他的约束条件，如：数据元素集合体是否可被修改和业务规则是否适用；
7）保密性和私密性约束；
8）来源（设置/发送实体）和接收者（使用/接收实体）；
e. CSCI必须为接口使用通信方法的特性。如：
1）项目唯一标识符；
2）通信链接/带宽/频率/媒体及其特性；
3）消息格式化；
4）流控制（如：序列编号和缓冲区分配）；
5）数据传送速率，周期性/非周期性，传输间隔；
6）路由、寻址、命名约定；
7）传输服务，包括优先级别和等级；
8）安全性/保密性/私密性方面的考虑，如：加密、用户鉴别、隔离和审核等；
f. CSCI必须为接口使用协议的特性，如：
1）项目唯一标识符；
2）协议的优先级别/层次；
3）分组，包括分段和重组、路由和寻址；
4）合法性检查、错误控制和恢复过程；
5）同步，包括连接的建立、维护和终止；
6）状态、标识、任何其他的报告特征；
g．其他所需的特性，如：接口实体的物理兼容性（尺寸、容限、负荷、电压和接插件兼容性等）。
3.6 CSCI内部接口需求
本条应指明CSCI内部接口的需求（如有的话）。如果所有内部接口都留待设计时决定，则需在此说明这一事实。如果要强加这种需求，则可考虑本文档的3.5给出的一个主题列表。
3.7 CSCI内部数据需求
本条应指明对CSCI内部数据的需求，（若有）包括对CSCI中数据库和数据文件的需求。如果所有有关内部数据的决策都留待设计时决定，则需在此说明这一事实。如果要强加这种需求，则可考虑在本文档的3.5.x.c和3.5.x.d给出的一个主题列表。
3.8 适应性需求
本条应指明要求CSCI提供的、依赖于安装的数据有关的需求（如：依赖现场的经纬度）和要求CSCI使用的、根据运行需要进行变化的运行参数（如：表示与运行有关的目标常量或数据记录的参数）。
3.9 保密性需求
本条应描述有关防止对人员、财产、环境产生潜在的危险或把此类危险减少到最低的CSCI需求，包括：为防止意外动作和无效动作必须提供的安全措施。
3.10 保密性和私密性需求
本条应指明保密性和私密性的CSCI需求，包括：CSCI运行的保密性/私密性环境、提供的保密性或私密性的类型和程度。CSCI必须经受的保密性/私密性的风险、减少此类危险所需的安全措施、CSCI必须遵循的保密性/私密性政策、CSCI必须提供的保密性/私密性审核、保密性/私密性必须遵循的确证/认可准则。
3.11 CSCI环境需求
本条应指明有关CSCI必须运行的环境的需求。例如，包括用于CSCI运行的计算机硬件和操作系统。
3.12 计算机资源需求
本条应分以下各条进行描述。
3.12.1 计算机硬件需求
本条应描述cSc1使用的计算机硬件需求，（若适用）包括：各类设备的数量、处理器、存储器、输入/输出设备、辅助存储器、通信/网络设备和其他所需的设备的类型、大小、容量及其他所要求的特征。
3.12.2 计算机硬件资源利用需求
本条应描述CSCI计算机硬件资源利用方面的需求，如：最大许可使用的处理器能力、存储器容量、输入/输出设备能力、辅助存储器容量、通信/网络设备能力。描述（如每个计算机硬件资源能力的百分比）还包括测量资源利用的条件。
3.12.3 计算机软件需求
本条应描述CSCI必须使用或引人CSCI的计算机软件的需求，例如包括：操作系统、数据库管理系统、通信/网络软件、实用软件、输入和设备模拟器、测试软件、生产用软件。必须提供每个软件项的正确名称、版本、文档引用。
3.12.4 计算机通信需求
本条应描述CSCI必须使用的计算机通信方面的需求，例如包括：连接的地理位置、配置和网络拓扑结构、传输技术、数据传输速率、网关、要求的系统使用时间、传送/接收数据的类型和容量、传送/接收/响应的时间限制、数据的峰值、诊断功能。
3.13 软件质量因素
本条应描述合同中标识的或从更高层次规格说明派生出来的对CSCI的软件质量方面的需求，例如包括有关CSCI的功能性（实现全部所需功能的能力）、可靠性（产生正确、一致结果的能力）、可维护性（易于更正的能力）、可用性（需要时进行访间和操作的能力）、灵活性（易于适应需求变化的能力）、可移植性（易于修改以适应新环境的能力）、可重用性（可被多个应用使用的能力）、可测试性（易于充分测试的能力）、易用性（易于学习和使用的能力）以及其他属性的定量需求。
3.14 设计和实现的约束
本条应描述约束CSCI设计和实现的那些需求。这些需求可引用适当的标准和规范。
例如需求包括：
a．特殊CSCI体系结构的使用或体系结构方面的需求，例如：需要的数据库和其他软件配置项；标准部件、现有的部件的使用；需方提供的资源（设备、信息、软件）的使用；
b．特殊设计或实现标准的使用；特殊数据标准的使用；特殊编程语言的使用；
c．为支持在技术、风险或任务等方面预期的增长和变更区域，必须提供的灵活性和可扩展性．
3.15 数据
说明本系统的输入、输出数据及数据管理能力方面的要求（处理量、数据量）。
3.16 操作
说明本系统在常规操作、特殊操作以及初始化操作、恢复操作等方面的要求。
3.17 故障处理
说明本系统在发生可能的软硬件故障时，对故障处理的要求。包括：
a．说明属于软件系统的问题；
b．给出发生错误时的错误信息；
c．说明发生错误时可能采取的补救措施。
3.18 算法说明
用于实施系统计算功能的公式和算法的描述。包括：
a．每个主要算法的概况；
b．用于每个主要算法的详细公式。
3.19 有关人员需求
本条应描述与使用或支持CSCI的人员有关的需求，包括人员数量、技能等级、责任期、培训需求、其他的信息。如：同时存在的用户数量的需求，内在帮助和培训能力的需求，还应包括强加于CSCI的人力行为工程需求，这些需求包括对人员在能力与局限性方面的考虑：在正常和极端条件下可预测的人为错误，人为错误造成严重影响的特定区域，例如包括错误消息的颜色和持续时间、关键指示器或关键的物理位置以及听觉信号的使用的需求。
3.20 有关培训需求
本条应描述有关培训方面的CSCI需求。包括：在CSCI中包含的培训软件。
3.21 有关后勤需求
本条应描述有关后勤方面的CSCI需求，包括：系统维护、软件支持、系统运输方式、供应系统的需求、对现有设施的影响、对现有设备的影响。
3.22 其他需求
本条应描述在以上各条中没有涉及到的其他CSCI需求。
3.23 包装需求
本条应描述需交付的CSCI在包装、加标签和处理方面的需求。
3.24 需求的优先次序和关键程度
本条应给出本规格说明中需求的、表明其相对重要程度的优先顺序、关键程度或赋予的权值，如：标识出那些认为对安全性、保密性或私密性起关键作用的需求，以便进行特殊的处理。如果所有需求具有相同的权值，本条应如实陈述。
4 合格性规定
本章定义一组合格性方法，对于第3章中每个需求，指定所使用的方法，以确保需求得到满足。可以用表格形式表示该信息，也可以在第3章的每个需求中注明要使用的方法。合格性方法包括：
a．演示：运行依赖于可见的功能操作的CSCI或部分CSCI，不需要使用仪器、专用测试设备或进行事后分析；
b．测试：使用仪器或其他专用测试设备运行CSCI或部分CSCI，以便采集数据供事后分析使用；
c．分析：对从其他合格性方法中获得的积累数据进行处理，例如测试结果的归约、解释或推断；
d．审查：对CSCI代码、文档等进行可视化检查；
e．特殊的合格性方法。任何应用到CSCI的特殊合格性方法，如：专用工具、技术、过程、设施、验收限制。
5 需求可追踪性
本章应包括：
a．从本规格说明中每个CSCI的需求到其所涉及的系统（或子系统）需求的可追踪性。（该可追踪性也可以通过对第3章中的每个需求进行注释的方法加以描述）。
注：每一层次的系统细化可能导致对更高层次的需求不能直接进行追踪。例如：建立多个CSCI的系统体系结构设计可能会产生有关CSCI之间接口的需求，而这些接口需求在系统需求中并没有被覆盖，这样的需求可以被追踪到诸如“系统实现”这样的一般需求，或被追踪到导致它们产生的系统设计决策上。
b．从分配到被本规格说明中的CSCI的每个系统（或子系统）需求到涉及它的CSCI需求的可追踪性。分配到CSCI的所有系统（或子系统）需求应加以说明。追踪到IRS中所包含的CSCI需求可引用IRS.
6 尚未解决的问题
如需要，可说明软件需求中的尚未解决的遗留问题。
7 注解
本章应包含有助于理解本文档的一般信息（例如背景信息、词汇表、原理）。本章应包含为理解本文档需要的术语和定义，所有缩略语和它们在文档中的含义的字母序列表。
附录
附录可用来提供那些为便于文档维护而单独出版的信息（例如图表、分类数据）。为便于处理，附录可单独装订成册。附录应按字母顺序（A, B等）编排。
备注：以上描述，可根据软件项目实际情况进行删减。