软件需求规约(1.0)
软件需求规范
软件需求规范软件需求规范是对软件实施的全过程进行描述和指导的一种综合文件，是软件开发的基础文档之一。
软件需求规范的主要目的是明确软件的功能、性能、界面、安全等方面的需求，为软件开发和测试提供依据。
软件需求规范一般包括以下内容：1. 介绍：对软件的背景、目的、范围、读者等进行介绍，为后续内容提供背景信息和上下文。
2. 功能需求：对软件的主要功能进行详细描述，包括输入、输出、处理逻辑等方面的需求。
可以采用用例图、用例描述等方式进行描述。
3. 非功能需求：对软件的性能、可靠性、安全性、可用性等方面的需求进行详细描述。
可以包括性能指标、数据安全性要求、用户友好性等方面的要求。
4. 界面需求：对软件的用户界面进行详细描述，包括界面布局、样式、交互逻辑等方面的要求。
可以采用界面原型、界面流程图等方式进行描述。
5. 数据需求：对软件的数据模型、数据流程、数据存储等方面的需求进行描述。
可以使用数据模型图、数据流程图等方式进行描述。
6. 约束和限制：对软件开发和实施过程中的约束和限制进行描述，包括时间、成本、技术平台、法律法规等方面的约束。
7. 接口需求：对软件与其他系统、硬件设备等的接口进行描述，包括数据格式、通信协议、接口功能等方面的要求。
8. 测试需求：对软件测试的需求进行描述，包括测试用例、测试环境、测试数据等方面的要求，为测试人员提供指导。
软件需求规范应具有以下特点：1. 明确性：需求规范中的要求应该具有明确性，能够让软件开发人员和测试人员一目了然，不产生二义性。
2. 完整性：需求规范应该尽可能地覆盖软件的各个方面，包括功能需求、非功能需求、界面需求等。
3. 一致性：需求规范中的各个部分应该是一致的，相互之间不产生矛盾。
4. 可追踪性：需求规范应该具有可追踪性，能够将需求与软件的设计、实现、测试等阶段进行关联。
5. 可验证性：需求规范中的要求应该是可验证的，能够通过测试或其他手段进行验证。
以上只是软件需求规范的一些基本要点，具体的需求规范内容和格式可以根据具体项目的情况进行调整。
软件工程需求分析文档(一)
软件工程需求分析文档（一）引言概述:本文档旨在对软件工程需求分析进行全面解析。
在软件开发过程中，需求分析是一个至关重要的阶段，其中包括了需求获取、需求分析、需求验证等多个环节。
通过本文档的详细阐述，读者将能够全面了解和掌握软件工程需求分析的相关内容，以便在实际项目中能够做到需求准确、明确，并且满足项目的目标和用户需求。
正文:I. 需求获取A. 用户需求的收集1. 与用户进行面对面的交流，获取用户的真实需求2. 收集用户的需求文档和经验总结3. 进行可行性分析，评估用户需求的可行性和优先级B. 系统需求的定义1. 根据用户需求，定义系统的功能和性能等需求2. 确定系统的输入输出流程3. 确定系统的非功能性需求，如安全性、可靠性等II. 需求分析A. 需求分解与分类1. 将系统的总体需求分解为较小的子需求2. 对子需求进行分类，如功能需求、性能需求、界面需求等B. 需求建模1. 使用统一建模语言(UML)等工具对需求进行建模2. 利用用例图、活动图、状态图等进行需求的形式化表示C. 需求规约1. 利用自然语言或规约语言对需求进行明确的描述2. 使用表格、图表等形式记录需求的详细信息III. 需求验证A. 需求审查1. 将需求文档交给相关人员进行审查2. 检查需求的正确性、合理性和可行性B. 需求验证测试1. 设计和执行测试用例，验证需求是否满足2. 检查系统的功能、性能和可靠性是否符合需求IV. 需求变更管理A. 需求变更的评估1. 对需求变更进行评估，包括影响范围和优先级等2. 利用变更控制工具进行需求变更的管理和跟踪B. 需求变更的实施1. 根据变更评估结果，对需求文档进行相应的修改2. 更新系统设计和测试计划等相关文档V. 需求跟踪与管理A. 需求跟踪1. 对需求文档中的每个需求进行编号和跟踪2. 记录需求的状态、变更历史等信息B. 需求管理工具的使用1. 使用需求管理工具对需求进行管理和跟踪2. 利用工具生成需求报告、状态报告等总结：通过本文档的阐述，我们详细介绍了软件工程需求分析的内容和过程。
软件工程自考题模拟8
软件工程自考题模拟8(总分：100.00，做题时间：90分钟)一、单项选择题(总题数：20，分数：40.00)1.下列关于需求规约的作用说法错误的是______（分数：2.00）A.需求规约是软件开发者和客户之间一份相关的技术合同书√B.对于项目的其余大多数工作，需求规约是一个管理控制点C.对于产品/系统的设计，需求规约是一个正式的，受控的起始点D.需求规约是创建产品验收测试计划和用户指南的基础解析：[考点] 本题主要考查的知识点为需求规约的作用。
需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现，并不是客户与开发者之间的相关技术合同。
2.下列描述中，不属于程序流程图优点的是______（分数：2.00）A.历史最悠久，使用最广泛B.容易表示数据结构√C.支持程序的三种基本控制结构D.直观清晰，易于使用解析：[考点] 本题主要考查的知识点为程序流程图。
程序流程图是一种历史最悠久，使用最广泛的设计工具，对控制流程的描绘直观，便于初学者掌握。
在程序流程图中，使用顺序、选择和循环三种基本控制结构。
但是它不是一种逐步求精的工具，也不易表示数据结构。
3.数据字典是软件需求分析阶段所采用的最重要工具之一，其最基本的功能是______（分数：2.00）A.数据定义√B.数据通讯C.数据库设计D.数据维护解析：4.以下说法错误的是______（分数：2.00）A.组合是聚合的一种特殊形式B.在一个组合中，一个链所连接的对象构成的任何元组，必须都属于同一个整体类的对象C.在一个组合中，组合末端的多重性可以超过1 √D.如果整体类的实例和部分类的实例具有相同的生命周期，那么这样的聚合称为组合解析：5.不属于在单元测试期间需要考虑的模块特征的是______（分数：2.00）A.模块接口B.局部数据结构C.重要的执行路径D.测试用例√解析：6.调试的目的是为了______（分数：2.00）A.证明软件符合设计要求√B.发现软件中的错误和缺陷C.改善软件的功能和性能D.发掘软件的潜在能力解析：[考点] 本题主要考查的知识点为调试。
软件需求规格说明书(原型法)
[项目名称]软件需求规格说明书（原型法）公司EPG版本历史目录1.引言 (1)1.1.目的 (1)1.2.适用范围 (1)1.3.参考资料 (1)1.4.术语和缩略语 (1)1.5.关联文档 (1)1.6.编写说明 (2)2.需求概述 (2)2.1.系统目标 (2)2.2.用户的特点 (2)2.3.关键点 (2)2.4.约束条件 (2)3.需求规格 (2)3.1.描述约定 (2)3.2.软件系统总体功能/对象结构 (3)3.3.软件子系统功能/对象结构 (3)4.详细功能需求（能力需求） (3)4.1.子系统A (3)4.1.1.具体功能A1 (3)4.2.子系统A (3)4.2.1.具体功能A1 (3)5.非功能需求 (3)5.1.适应性需求 (3)5.2.软件质量因素其他需求 (4)6.接口需求 (4)6.1.外部接口需求 (4)6.2.内部接口需求 (4)7.数据需求 (4)8.计算机资源需求 (4)8.1.计算机硬件需求 (4)8.2.计算机软件需求 (4)8.3.计算机通信需求 (5)9.尚未解决的问题 (5)附录A：需求确认 (1)1.引言1.1.目的说明编写这份软件需求规格说明书的目的，项目组成员和用户是文档的预期读者。
明确系统范围、系统与其他系统的接口问题、用户的各种功能、性能需求等。
1.2.适用范围说明1）本文档适用于采用原型法开发的软件项目；2）本文档的编写目的；3）本文档的预期读者。
1.3.参考资料[列出本文档引用的所有文档的标识、标题、修订版本和日期]1.4.术语和缩略语表1.术语说明1.5.关联文档表2.与软件需求规格说明书相关的文档1.6.编写说明1）第三章，对于项目合同额小于50万的项目，可以只画出功能结构图即可，流程图、对象图可省略；2）第四章应逐一描述每一个功能画面，不得遗漏；2.需求概述2.1.系统目标1）待开发的软件系统的名称；2）说明软件将干什么，如果需要的话，还要说明软件产品不干什么；3）说明软件与其他系统的接口，本系统要完成什么，不完成什么，要实现的系统功能，需要其他系统提供什么，本系统需要为其他系统提供什么。
后勤服务业务管理系统软件需求规约
SCYDHQFW后勤服务业务管理系统软件需求规约V1.0项目承担部门：撰写人（签名）：卓靖山完成日期：2014年12月07日本文档使用部门：■主管领导■项目组□客户（市场）□维护人员■用户评审负责人（签名）：评审日期：文档信息修订文档历史记录目录1. 简介 (4)1.1目的 (4)1.2范围 (4)1.3定义、首字母缩写词和缩略语 (4)1.4参考资料 (4)1.5概述 (4)2. 整体说明 (5)2.3产品总体效果 (5)2.4产品功能 (5)2.5用户特征 (8)3. 具体需求 (8)3.1功能模块 (8)3.1.1 系统设置模块 (8)3.1.2 信息管理模块 (16)3.1.3 业务处理模块 (35)3.2可用性 (75)3.3可靠性 (76)3.3.1 数据精确度 (76)3.3.2 平均故障时间 (76)3.3.3 其他可靠性需求 (76)3.4性能 (76)3.4.1 时间以及系统需求 (76)3.4.2 其他性能需求 (76)3.5可支持性 (76)3.5.1 维护需求 (76)3.5.2 系统构建需求 (76)3.6设计约束 (76)3.6.1 系统开发约束 (76)3.6.2 架构设计约束 (76)3.7联机用户文档和帮助系统需求 (76)3.8购买的构件 (77)3.9接口 (77)3.9.1 用户界面 (77)3.9.2 硬件接口 (77)3.9.3 软件接口 (77)3.9.4 通信接口 (77)3.10许可需求 (77)3.11法律、版权及其他声明 (77)3.12适用的标准 (77)4. 支持信息 (77)1.简介1.1目的1.定义系统总体要求，作为用户和软件开发人员之间相互了解的基础。
2.提供系统初步设计，让用户明确项目的需求范围，作为软件人员进行软件结构设计和编码的基础。
3.作为软件总体测试和项目验收的依据。
1.2范围本文档适用于“后勤服务业务管理系统”项目开发的整个生命周期，覆盖项目每一项工作任务，适用于参与本项目的所有成员以及相关组。
软件功能需求规范
软件功能需求规范一、引言随着信息技术的发展和应用的普及，各行各业对于软件的需求也日益增加。
为了确保软件开发能够准确满足用户的需求，我们制定了本软件功能需求规范，以明确软件的功能需求和规范。
二、背景在本节中，我们将介绍软件开发的背景和相关要求。
涉及到的背景信息包括：软件的使用范围、目标用户、硬件和软件环境、软件当前的问题和挑战等。
1. 软件的使用范围本软件针对的是XXXX行业，旨在解决XXXX问题。
在该行业中，XXX问题一直存在，并对企业的经营和服务带来了一定的困扰。
因此，我们开发了本软件，希望能够解决这一问题。
2. 目标用户本软件的目标用户为该行业的从业人员，包括管理人员、技术人员和普通员工等。
用户对软件的需求和使用习惯各不相同，因此我们需要在开发软件的过程中考虑到各种用户的需求。
3. 硬件和软件环境为了保证软件的正常运行，用户需要在其计算机上安装特定的硬件和软件环境。
具体的要求包括：操作系统的版本、处理器的类型和频率、内存大小、硬盘空间等。
确保用户的系统满足这些硬件和软件环境的要求非常重要。
4. 软件当前的问题和挑战在开发软件之前，我们需要了解现有软件的问题和挑战，以便我们可以针对性地解决这些问题。
其中涉及的问题和挑战包括：功能不完善、界面不友好、性能不稳定、安全性风险等。
在开发新的软件之前，我们需要确保新软件能够解决这些问题，并能够更好地满足用户的需求。
三、功能需求在本节中，我们将详细介绍软件的功能需求。
根据用户的需求和挑战，我们制定了以下功能需求。
1. 功能需求一（根据具体需求编写）2. 功能需求二（根据具体需求编写）3. 功能需求三（根据具体需求编写）四、性能需求除了功能需求外，我们还制定了一些性能需求，以确保软件的高效运行和稳定性。
1. 响应时间本软件对用户的操作要求在X毫秒内响应，尽量减少用户等待的时间。
在设计和开发软件的过程中，我们将采取一些优化措施来提高响应速度。
2. 并发处理能力为了支持大量用户同时使用软件的需求，我们需要确保软件拥有良好的并发处理能力。
软件工程(软件需求)习题与答案
1、与软件工程不同，（）是系统工程所追求的目标。
A.最优化B.系统化C.一体化D.情境化正确答案：A2、下面不属于需求的基本性质是（）A.必要性B.无歧义性C.可测性D.可扩展性正确答案：D3、下列需求属于性能需求的是（）A.并发访问数B.网络协议C.异常响应D.用户友好正确答案：A4、下列需求属于外部接口需求的是（）A.第三方插件B.安全隐私C.编程语言D.字体字号5、下列需求属于设计约束的是（）A.响应时间B.运行平台C.错误处理D.可维护正确答案：B6、当无法与用户进行直接交流时，可采用（）的需求发现方式。
A.自悟B.提炼C.小组会D.思考正确答案：A7、下述情况分别最适合采取哪种需求发现的方式（）①为解决生活中遇到的麻烦事而开发的软件②有较多繁琐环节的社区医保系统的开发③某小型团体组织开发其内部人员管理系统④某大型连锁集团开发集团人员管理系统⑤某专业化软件外包公司接手烂尾的软件开发项目A.①-自悟；②-观察；③-交流；④-小组会；⑤-提炼B.①-观察；②-自悟；③-小组会；④-交流；⑤-提炼C.①-自悟；②-交流；③-观察；④-提炼；⑤-小组会D.①-提炼；②-自悟；③-交流；④-观察；⑤-小组会正确答案：A8、需求规约是一个软件产品/系统的（）A.开发模型B.框架模型C.概念模型D.功能模型正确答案：C9、在需求分析阶段会形成（）的测试计划。
A.单元测试B.集成测试C.确认测试D.系统测试正确答案：C二、判断题1、相比硬件而言，软件更容易被修改，而且更容易被正确地进行修改。
(×)2、任何软件开发过程必须从软件需求入手。
(√)3、采用瀑布模型的开发过程是一种自顶向下的开发方法，而软件构件复用的开发过程是一种自底向上的开发方法。
(√)4、软件需求是待开发产品或系统的功能描述。
(×)5、非功能需求必须依附于功能需求而存在。
(√)6、质量属性必须要给出量化的测量指标。
(√)7、小组会和交流这两种需求发现方式的区别在于参加人员的多少。
软件需求规格说明（Word版）
软件需求规格说明（Word版）软件需求规格说明(SRS)1 范围1.1 标识本条应包含本文档适用的系统和软件的完整标识，（若适用）包括标识号、标题、缩略词语、版本号和发行号。
1.2系统概述本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出其他有关的文档。
1.3文档概述本条应概述本文挡的用途和内容，并描述与其使用有关的保密性或私密性要求。
1.4基线说明编写本系统设计说明书所依据的设计基线。
2 引用文件本章应列出本文档引用的所有文档的编号、标题、修订版本和发行日期，也应标识不能通过正常的供货渠道获得的所有文档的来源。
3 需求本章应分以下几条描述CSCI需求，也就是，构成CSCI验收条件的CSCI的特性。
CSCI需求是为了满足分配给该CSCI的系统需求所形成的软件需求。
给每个需求指定项目唯一标识符以支持测试和可追踪性。
并以一种可以定义客观测试的方式来陈述需求。
如果每个需求有关的合格性方法（见第4章）和对系统（若适用，子系统）需求的可追踪性（见5．a 条）在相应的章中没有提供，则在此进行注解。
描述的详细程度遵循以下规则：应包含构成CSCI 验收条件的那些CSCI特性，需方愿意推迟到设计时留给开发方说明的那些特性。
如果在给定条中没有需求的话，本条应如实陈述。
如果某个需求在多条中出现，可以只陈述一次而在其他条直接引用。
3.1 所需的状态和方式如果需要CSCI在多种状态和方式下运行，且不同状态和方式具有不同的需求的话，则要标识和定义每一状态和方式，状态和方式的例子包括：空闲、准备就绪、活动、事后分析、培训、降级、紧急情况和后备等。
状态和方式的区别是任意的，可以仅用状态描述CSCI，也可以仅用方式、方式中的状态、状态中的方式或其他有效方式描述。
如果不需要多个状态和方式，不需人为加以区分，应知实陈述；如果需要多个状态或方式，还应使本规格说明中的每个需求或每组需求与这些状态和方式相关联，关联可在本条或本条引用的附录中用表格或其他的方法表示，也可在需求出现的地方加以注解。
需求规约模板（SystemRequirementSpecification）
需求规约模板（SystemRequirementSpecification）Software RequirementsSpecificationforVersion 1.0 approvedPrepared byTable of ContentsTable of Contents (ii)Revision History (ii)1. Introduction (1)1.1 Purpose (1)1.2 Document Conventions (1)1.3 Intended Audience and Reading Suggestions (1) 1.4 Project Scope (1)1.5 References (1)2. Overall Description (2)2.1 Product Perspective (2)2.2 Product Features (2)2.3 User Classes and Characteristics (2)2.4 Operating Environment (2)2.5 Design and Implementation Constraints (2)2.6 User Documentation (2)2.7 Assumptions and Dependencies (3)3. System Features (3)3.1 System Feature 1 (3)3.2 System Feature 2 (and so on) (4)4. External Interface Requirements (4)4.1 User Interfaces (4)4.2 Hardware Interfaces (4)4.3 Software Interfaces (4)4.4 Communications Interfaces (4)5. Other Nonfunctional Requirements (5)5.1 Performance Requirements (5)5.2 Safety Requirements (5)5.3 Security Requirements (5)5.4 Software Quality Attributes (5)6. Other Requirements (5)Appendix A: Glossary (5)Appendix B: Analysis Models (6)Appendix C: Issues List (6)Revision History1.Introduction1.1Purpose1.2Document Conventions1.3Intended Audience and Reading Suggestions 1.4Project Scope1.5References2.Overall Description2.1Product Perspective2.2Product Features2.3User Classes and Characteristics2.4Operating Environment2.5Design and Implementation Constraints2.6User Documentation2.7Assumptions and Dependencies3.System Features3.1System Feature 13.1.1 Description and Priority<="" of="" p="" short="" the="" whether="">or Low priority. You could also include specific priority component ratings, such asbenefit, penalty, cost, and risk (each rated on a relative scale from a low of 1 to ahigh of 9).>3.1.2 Stimulus/Response Sequences<="" user="">behavior defined for this feature. These will correspond to the dialog elementsassociated with use cases.>3.1.3 Functional Requirements<="" associated="" bdsfid="172" detailed="" feature.="" functional="" p="" requirements="" the="" these="" this="" with="">the software capabilities that must be present in order for the user to carry out theservices provided by the feature, or to execute the use case. Include how theproduct should respond to anticipated error conditions or invalid inputs.Requirements should be concise, complete, unambiguous, verifiable, and necessary.Use “TBD” as a placeholder to indicate when necessaryinformation is not yetavailable.><="" bdsfid="180" be="" identified="" number="" or="" p="" requirement="" sequence="" should="" uniquely="" with="">meaningful tag of some kind.>REQ-1:REQ-2:3.2System Feature 2 (and so on)4.External Interface Requirements4.1User Interfaces4.2Hardware Interfaces4.3Software Interfaces4.4Communications Interfaces5.Other Nonfunctional Requirements5.1Performance Requirements5.2Safety Requirements5.3Security Requirements5.4Software Quality Attributes6.Other RequirementsAppendix A: GlossaryAppendix B: Analysis ModelsAppendix C: Issues List< This is a dynamic list of the open requirements issues that remain to be resolved, including TBDs, pending decisions, information that is needed, conflicts awaiting resolution, and the like.>。
软件产品需求规范详解
软件产品需求规范详解1. 引言软件产品需求规范是在软件开发过程中非常关键的一步。
通过明确规范软件产品需求，可以确保开发团队和客户在需求理解和预期功能方面达成一致，减少沟通误差，提高软件开发效率。
本文将详细介绍软件产品需求规范的要素和编写流程。
2. 需求规范概述2.1 需求定义在需求规范中，需要明确软件产品的功能需求、非功能需求和限制条件等信息。
其中，功能需求指产品应具备的各项功能，非功能需求则包括性能、可靠性、安全性等方面的要求。
限制条件则定义了开发过程中的限制因素，如预算、技术要求等。
2.2 需求编写原则在编写需求规范时，需遵循以下原则：- 明确性：需求应该清晰、具体、无歧义，并且能够被准确理解。
- 可衡量性：需求应该可以被测量和验证，以确保其实现的可行性。
- 可追踪性：需求应该能够与软件开发的其他阶段建立有效的关联，使得需求的演化和变更能够被追踪和管理。
- 可测试性：需求应该能够进行有效的测试，以验证系统是否满足需求。
3. 需求规范编写流程3.1 需求收集在需求收集阶段，需要与利益相关者进行深入沟通和交流，了解其需求、期望和约束条件。
这可以通过面对面的访谈、问卷调查等方式进行，以确保对需求的全面理解。
3.2 需求分析与整理在需求分析与整理阶段，需要对收集到的需求进行梳理和整理，识别其中的功能需求、非功能需求和限制条件，并进行分类和归纳。
3.3 需求规范编写在需求规范编写阶段，可以采用自由文本、表格、图表等形式来呈现需求规范。
需要明确规范的内容包括：- 产品概述：对软件产品的背景和目标进行描述。
- 功能需求：对软件产品应具备的各项功能进行详细描述。
- 非功能需求：对软件产品性能、可靠性、安全性等方面的要求进行描述。
- 使用案例：通过详细的使用案例来描述软件产品的交互过程。
- 界面设计：对软件产品的界面布局和交互设计进行描述。
- 限制条件：定义软件开发过程中的限制因素，如预算、技术要求等。
3.4 需求验证与确认在需求规范编写完成后，需要与客户进行沟通，以确保需求的准确性和可行性。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
基于网络的CAI教学系统
软件需求规约
版本 1.0
修订历史记录
目录
●简介
●目的
●范围
●定义、首字母缩写词和缩略语
●参考资料
●概述
●整体说明
●用例模型调查
●假设与依赖关系
●具体需求
●用例报告
●补充需求
●支持信息
目的
本文档将从构架方面对系统进行综合概述，其中会使用多种不同的构架视图来描述系统的各个方面。
它用于记录并表述已在构架方面对系统作出的重要决策。
范围
此软件构架文档适用于将由 Context Integration 开发的基于网络的CAI教学系统。
定义、首字母缩写词和缩略语
CAI—计算机辅助教育,计算机模拟输入
参考
1.《软件工程实践教程》（第2版），赵池龙等编，电子工业出版社
2.《软件工程实践教程》（第1版），谭庆平等编，高等教育出版社
3.《软件工程》（第1版），张海藩等编著，清华大学出版社
4.《软件工程导论》（第4版），张海藩等编著，清华大学出版社
概述
使用者透过TCP/IP 通讯协定的方式进入全球资讯网，以浏览网页的方式连结到电脑辅助教学系统，并且在进入系统前接受系统的安全认证，然后选择要参与学习的科目，再来藉由HTML、XML 或者ASP 的互动方式来呈现教学的内容，使用者可以切换教学网页来进行上课内容传授。
当教学辅助系统告一段落后，使用者不需更换介面环境，只需切换至另外一个网页，进入智慧型的适性测验系统，直接在线上接受测验，并且可以按每位学习者的学习效率和程度立即得到答案和课后评语，而后使用者也可以在线上(BBS)和一同上课的同学进行心得交换，不了解的地方也可以在线上或者使用电子邮件(Email)和老师讨论。
整体说明
用例模型调查
详见UML模型文件夹
假设与依赖关系
详见UML模型文件夹
用例报告
使用者透过TCP/IP 通讯协定的方式进入全球资讯网，以浏览网页的方式连结到电脑辅助教学系统，并且在进入系统前接受系统的安全认证，然后选择要参与学习的科目，再来藉由HTML、XML 或者ASP 的互动方式来呈现教学的内容，使用者可以切换教学网页来进行上课内容传授。
当教学辅助系统告一段落后，使用者不需更换介面环境，只需切换至另外一个网页，进入智慧型的适性测验系统，直接在线上接受测验，并且可以按每位学习者的学习效率和程度立即得到答案和课后评语，而后使用者也可以在线上(BBS)和一同上课的同学进行心得交换，不了解的地方也可以在线上或者使用电子邮件(Email)和老师讨论。
补充需求
无。