西
西北浪人
Unregistered / Unconfirmed
GUEST, unregistred user!
wind28,我要实例 ，能发给我一份嘛，谢谢，lujiqing@21cn.com
您正在使用一款已经过时的浏览器！部分功能不能正常使用。
请尝试升级或使用 其他浏览器。
请尝试升级或使用 其他浏览器。
L
lwd_2002
Unregistered / Unconfirmed
GUEST, unregistred user!
也给我义愤啊！
D
demodh16
Unregistered / Unconfirmed
GUEST, unregistred user!
我也要啊， demodh16@sina.com
D
dedema
Unregistered / Unconfirmed
GUEST, unregistred user!
关注中..........................................................................
C
Cloutar
Unregistered / Unconfirmed
GUEST, unregistred user!
也给我一份吧
急需
ziying661@sina.com
急需
ziying661@sina.com
A
ayi_fan
Unregistered / Unconfirmed
GUEST, unregistred user!
需求分析的写法看设计阶段的不同，详细的写得和帮助文件差不多。
欢迎就具体问题交流。我曾经是专职的需求人员。
欢迎就具体问题交流。我曾经是专职的需求人员。
Y
yejsj
Unregistered / Unconfirmed
GUEST, unregistred user!
我只是要一份作一个模板，我现在要写，可是根本就不会写，
要是按照书上的，根本不可能 ，
那么多，有一本那么厚的书啊，要是我写得那样，
我干脆就去出书得了，
要是有哪位兄弟有，就给我 一份吧。
在这谢过了。
要是按照书上的，根本不可能 ，
那么多，有一本那么厚的书啊，要是我写得那样，
我干脆就去出书得了，
要是有哪位兄弟有，就给我 一份吧。
在这谢过了。
L
langzizheng
Unregistered / Unconfirmed
GUEST, unregistred user!
给我发一份吧，qianming1978@vip.sina.com
次
次时代
Unregistered / Unconfirmed
GUEST, unregistred user!
最好发到网上去。
DZ.JC@163.COM
DZ.JC@163.COM
F
fodou0608
Unregistered / Unconfirmed
GUEST, unregistred user!
我也想要一份
zjc0907@163.com
zjc0907@163.com
J
jslyglwd
Unregistered / Unconfirmed
GUEST, unregistred user!
me too!
lwd_0@mail.china.com
lwd_0@mail.china.com
T
tuti
Unregistered / Unconfirmed
GUEST, unregistred user!
《编写有效用例》
K
Kevinjoan
Unregistered / Unconfirmed
GUEST, unregistred user!
课程注册系统
需求属性指南
版本 1.0
修订历史记录
日期
版本
说明
作者
08/Jan/1999 1.0 初始发布版 Simon Jones
目录
目标
范围
参考
需求属性
产品需求属性
状态
利益
工作量
风险
目标发布版
职责分配
用例需求属性
状态
优先级
工作量估计
技术风险
目标开发迭代
职责分配
Rose 模型
测试用例属性
测试状态
工作版本号
测试者
测试日期
测试说明
可追踪性标准
产品需求标准
用例需求标准
测试需求标准
需求属性指南
目标
需求属性指南确定并说明将用于管理课程注册系统需求的属性。此外，本文档还概述了项目在开发过程中将要维护的需求可追踪性。
分配给每个需求的属性将用于管理软件开发和确定每一个发布版的特性的优先级。
保持需求可追踪性的目的是为了减少在开发周期后期发现缺陷的数量。确保所有产品需求记录在软件需求、设计和测试用例中，这样会提高产品的质量。
范围
本文档中的属性和可追踪性指南适用于课程注册系统的产品需求、软件需求和测试需求。
参考
适用的参考资料包括：
课程注册系统前景文档，WyIT387，1.0 版，1998，Wylie College IT。
课程注册系统补充规约，WyIT400，草案，1998，Wylie College IT。
用例规约 - 结束注册，WyIT403，草案，1998，Wylie College IT。
用例规约 - 登录，WyIT401，草案，1998，Wylie College IT。
用例规约 - 维护教授信息，WyIT407，草案，1998，Wylie College IT。
用例规约 - 课程注册，WyIT402，草案，1998，Wylie College IT。
用例规约 - 选择要讲授的课程，WyIT405，草案，1998，Wylie College IT。
用例规约 - 维护学生信息，WyIT408，草案，1998，Wylie College IT。
用例规约 - 提交成绩，WyIT409，草案，1998，Wylie College IT。
用例规约 - 查看成绩报告单，WyIT410，草案，1998，Wylie College IT。
课程注册系统测试计划，WyIT<TBD>，Wylie College IT。
需求属性
本节确定将要管理的需求的类型，以及确定用于各个需求类型的属性。课程注册系统将确定并管理以下需求类型：
产品需求，
用例需求，和
测试用例。
本项目正计划使用 RequisitePro 来这些管理需求。本节所描述的属性将在 RequisitePro 中定义。RequisitePro 能够按照属性对在 Word 文档中标记的每个需求进行说明。RequisitePro 也可用来追踪需求（如本文档第 5 节所述）。
产品需求属性
通过本节定义的属性来管理产品需求（在前景文档 [1] 中定义）。这些属性有助于管理开发工作和确定针对不同发布版的特性的优先级。
状态
在前景文档中定义了产品需求后进行设置。用于在确立项目基线的过程中对进度进行跟踪。
已提出 用于说明正在进行讨论但尚未经过复审和批准的特性。
已批准 性能被认为是有用可行的，并且已批准进行实施。
已并入 在特定时间点并入产品基线中的特性。
利益
由市场经理、产品经理或业务分析员设置。并非所有需求都同等重要。通过按照各项需求对最终用户的相对利益来划分其等级，可以促使客户、分析员和开发团队成员相互交换意见。用于管理规模和确定开发优先级。
产品经理将利用关键、重要、可用三个层次来具体说明每个已提议特性的优点。
关键 必不可少的特性。不实现这些规约就无法使系统满足客户的需要。所有关键特性都必须在发布时实施，否则将错过预定的发布时间。
重要 对于系统在大多数应用中的有效性及效率都较为重要的特性。很难通过其他方式来实现这方面的功能。如果遗漏了某项重要特性，就可能会影响客户或用户满意度，甚至会影响收入，但发布并不会因为缺少任意一项重要特性而延期。
有用 有些特性在不太典型的应用中比较有用，或者可以合理而有效地实现其替代特性，这些特性的使用次数将会相对较少。即使发布版中没有包括某一项这样的特性，也不会对收入或客户满意度造成严重的影响。
工作量
由开发团队设置。由于有些特性所需的时间和资源多于其他特性，所以在评测复杂程度并预计在给定时间范围内能否完成哪些工作时，最佳的方式就是估计团队工作周数或个人工作周数、所需的代码行数或功能点数（举例来说）。用于管理规模和确定开发优先级。
在课程注册系统中，工作量用人员天数来确定。
风险
由开发团队根据项目遭遇意外事件的可能性来设置，这些事件包括超支、工期延误，甚至是项目取消。虽然可以对风险级别进行细分，但大多数项目经理都发现把风险归类为高、中、低就足够了。通过评测项目团队进度估计的不确定性（范围），一般都可以间接地对风险进行评估。
在课程注册项目中，项目经理把风险定义为高、中、低三个级别。
高 风险的影响严重，并且风险发生的概率也很高。
中 风险的影响不太严重，并且风险发生的概率也不太高。
低 风险的影响最小，并且风险发生的概率也很低。
目标发布版
记录将首次包括指定特性的产品版本。该字段可用于将前景文档中的特性分配给特定的基线发布版。如果将其与状态字段结合，项目团队就可以提出、记录和讨论发布版的各种特性，而不对其进行开发。只有状态被设置为“已并入”且目标发布版已确定的特性才将被实施。当进行规模管理时，可以增加目标发布版号，这样该项特性虽然仍保留在前景文档中，但将安排在以后发布。
在课程注册系统中，这些特性将计划包含在前 3 个发布版中。
R 1.0 计划课程注册发布版 1.0 的发布日程（1999 年 10 月）
R 2.0 计划课程注册发布版 2.0 的发布日程（2000 年 10 月）
R 3.0 计划课程注册发布版 3.0 的发布日程（2001 年 10 月）
其他 计划未来发布版 TBD 的日程
职责分配
在许多项目中，特性将被分配给“特性团队”，这些团队负责进一步获取需求，并编写软件需求和实施方案。这一简单的下拉列表将帮助项目团队中的每位成员更好地理解他们的职责。
用例需求属性
用例需求（在课程注册用例规约 [3 - 10] 和补充规约 [2] 中定义）将利用本节定义的属性来进行管理。这些属性有助于管理开发工作，决定迭代内容，以及将用例和它们特定的 Rose 模型相关联。
状态
在分析人员起草用例后设置。从用例的最初起草直到最后确认的整个过程中追踪用例的编制进度。
已提出 用例已经确定但尚未通过复审和批准。
已批准 用例已被批准进行进一步的设计和实施。
已确认 用例已在系统测试中得到确认。
优先级
由项目经理来设置。根据给用例分配开发资源和监测用例编制进度的重要性来确定用例的优先级。优先级一般根据用户考虑的利益、计划的发布和迭代、用例的复杂性（风险）、以及实施用例的工作量来确定的。
高 相对于确保密切监控用例实施并给任务适当地分配资源而言，用例具有较高的优先级。
中 相对于其他用例而言，用例具有中等优先级。
低 用例具有较低优先级。此用例的实施不太关键，而且可以在以后的迭代和发布中继续进行或重新安排。
工作量估计
由开发团队设置。由于有些特性所需的时间和资源多于其他特性，所以在评测复杂程度并预计在给定时间范围内能否完成哪些工作时，最佳的方式就是估计团队工作周数或个人工作周数、所需的代码行数或功能点数（举例来说）。用于管理规模和确定开发的优先级。项目经理利用这些工作量估计的结果来确定项目进度并有效地根据任务计划资源分配。
课程注册项目用人员天数来估计工作量（假定一个工作日有 7.5 个小时）。
技术风险
由开发团队根据用例遭遇意外事件的概率来设置，这些事件包括工作量超限、设计有瑕疵、存在大量缺陷、质量和性能低下等。诸如此类的意外事件通常是由没有很好地理解或定义需求、知识不足、缺乏资源、技术复杂以及新技术、新工具、新设备等引起的。
课程注册项目将每个用例的技术风险分成高、中、低三类。
高 风险的影响严重，并且风险发生的概率也很高。
中 风险的影响不太严重，并且风险发生的概率也不太高。
低 风险的影响最小，并且风险发生的概率也很低。
目标开发迭代
记录将实施用例的开发迭代。计划每个发布版的开发在项目构建阶段中将执行若干次开发迭代。
项目经理利用分配给每个用例的迭代数目来计划项目团队的活动。
当前的计划是课程注册项目在构建阶段要经历 3-4 次迭代。在每次迭代中，所选的用例集将要进行编码和测试。
迭代 E-1 为精化阶段安排的一次迭代，即迭代 1
迭代 C-1 为构建阶段安排的第一次迭代，即迭代 1
迭代 C-2 为构建阶段安排的第二次迭代，即迭代 2
迭代 C-3 为构建阶段安排的第三次迭代，即迭代 3
职责分配
用例被分配给个人或开发团队作进一步的分析、设计和实施。一个简单的下拉列表将帮助项目团队中的每位成员更好地理解他们的职责。
Rose 模型
确定和用例需求相关联的 Rose 用例模型。
测试用例属性
利用本节定义的属性来计划并追踪测试用例（在课程注册系统测试计划 [11] 中定义）。
测试状态
由测试负责人设置。追踪每个测试用例的状态。
未测试
尚未执行测试用例。
失败
测试已经执行，但失败了。
有条件的通过
测试已经完成，但还存在问题。测试之所以通过是因为完成了某些操作。
通过
测试成功地完成。
工作版本号
记录将要核实特定测试用例的系统工作版本。
课程注册系统将在构建阶段的几次迭代中进行实施。一次迭代通常需要 1-3 个工作版本。
工作版本 A 为系统工作版本 A 准备的测试用例
工作版本 B 为系统工作版本 B 准备的测试用例
工作版本 C 为系统工作版本 C 准备的测试用例
工作版本 D 为系统工作版本 D 准备的测试用例
工作版本 E 为系统工作版本 E 准备的测试用例
工作版本 F 为系统工作版本 F 准备的测试用例
工作版本 G 为系统工作版本 G 准备的测试用例
工作版本 H 为系统工作版本 H 准备的测试用例
工作版本 I 为系统工作版本 I 准备的测试用例
工作版本 J 为系统工作版本 J 准备的测试用例
工作版本 K 为系统工作版本 K 准备的测试用例
工作版本 L 为系统工作版本 L 准备的测试用例
测试者
被指派来执行并核实测试用例的个人。这一简单的下拉列表将帮助项目团队中的每位成员更好地理解他们的职责。
测试日期
计划的测试日期或实际的测试日期。
测试说明
所有与计划和执行测试相关的说明。
可追踪性标准
产品需求标准
在前景文档 [1] 中定义的产品需求将追踪到在用例规约 [3]、[4]、[5]、[6]、[7]、[8]、[9]、[10] 和补充规约 [2] 中相应的用例或补充需求。
每个产品需求追踪到一个或多个用例需求和补充需求。
用例需求标准
在用例规约 [3]、[4]、[5]、[6]、[7]、[8]、[9]、[10] 和补充规约 [2] 中定义的用例需求将追踪到在测试计划 [11] 中指定的相应测试用例。
每个用例需求追踪到一个或多个系统测试用例。
测试需求标准
在测试计划 [11] 中说明的测试用例被追踪回到通过特定测试用例进行核实的产品需求 [1] 和用例需求 [2]、[3]、[4]、[5]、[6]、[7]、[8]、[9]、[10]。
一个测试用例可以追踪回到一个或多个产品和用例需求。在测试用例正在核实一个派生需求或设计的情况下，该测试用例可能不具有追溯到原来产品需求或用例需求的可追踪性。
&copy;
1987 - 2001 Rational Software Corporation。版权所有。
Rational Unified Process
课程注册系统
前景文档
版本 1.0
修订历史记录
日期
版本
说明
作者
1/Dec/98 草案 初始草案 Sue Gamble
13/Dec/98 1.0 平级复审后的局部修订。
添加了性能需求。
Sue Gamble
目录
目标
范围
参考
定位
商机
问题说明
产品定位说明
用户描述
用户/消费者统计数据
用户简档
用户环境
关键用户需要
备选方案和竞争
产品概述
产品总体效果
功能摘要
假设与依赖关系
成本与定价
许可与安装
功能属性
产品特性
登录
课程注册
课程取消
学生收费
输入、更新和查看教授信息
查看学生成绩
选择要讲授的课程
输入、更新和查看学生信息
记录学生成绩
查看课程目录信息
查看课程表
监控课程是否满员
约束
质量范围
优先级
其他产品需求
适用的标准
系统需求
性能需求
环境需求
文档需求
用户手册
联机帮助
安装向导、配置和自述文件
标签与包装
前景
目标
本文档的目的是根据最终用户的需要来定义 Wylie 课程注册 (C-Registration) 系统的高级需求。
范围
本前景文档适用于将由 Wylie College 信息系统 (IT) 部门开发的 Wylie 课程注册系统。IT 部门将开发这套客户机服务器系统，以便同现有的课程目录数据库结合起来使用。
课程注册系统将为学生提供在线课程注册的服务。课程注册系统可以让教授选择其要讲授的课程并保存学生的成绩。
参考
适用的参考资料包括：
课程注册系统的系统商业理由，WyIT388，草案，1998，Wylie College IT。
课程收费接口规约，WC93332，1985，Wylie College Press。
课程目录数据库规约，WC93422，1985，Wylie College Press。
课程注册系统涉众请求文档，WyIT389，1.0 版，1998，Wylie College IT。
课程注册系统词汇表，WyIT406，1.0 版，1998，Wylie College IT。
课程注册系统需求属性指南，WyIT404，1.0 版，1998，Wylie College IT。
定位
商机
本项目将用一个最新的在线系统来代替现有课程注册系统的整个前端处理机，从而让学生和教授可以通过 PC 客户机来访问系统。
现有的注册系统从 1985 年投入使用，到目前处理 2000 年计划的学生和课程数据负载的能力已经捉襟见肘。另外，现有系统使用的是过时的大型机技术，该技术只支持通过注册办公室的职员来访问系统。而新系统将提供两种方式让所有的教授和学生访问系统：将个人计算机连接到 Wylie College 计算机网络以及连接到 Internet。
新系统将使 Wylie College 步入课程注册系统的领先行列，从而改善学校的形象，吸引更多的学生以及提高管理工作的效率。
问题说明
问题是 Wylie College 过时的、很大部分依靠手工进行的学生注册流程。
影响 学生、教授和大学管理部门。
其后果是 流程缓慢且费用高昂，学生和教授皆不满意。
成功的解决办法是 改善大学的形象，吸引更多的学生和提高注册管理部门的工作效率。
产品定位说明
针对于 Wylie College 的学生、教授和课程注册员。
谁 参加、讲授或管理大学课程。
课程注册系统 是一个工具。
因为 实现在线课程注册和访问课程及成绩信息。
不同于 已有过时的大型机注册系统。
我们的产品 任何一台 PC 只要通过 College LAN 或 Internet 连接，就能够向所有用户提供有关所有课程、注册、教师和成绩的最新信息。
用户描述
本节描述 Wylie 课程注册系统的用户。课程注册系统有 3 种类型的用户：课程注册员、学生和教授。
用户/消费者统计数据
大学用户群是一个庞大复杂的群体，他们要求在线课程注册系统能够提供巨大的灵活性和快速的响应时间。
这些用户受过教育，具有计算机知识，而且在大多数情况下，家里都拥有个人计算机。通过个人计算机在线注册课程和复查成绩，这种能力将大大提高课程注册的效率。
课程注册系统的初始发布版将仅限于 Wylie College。Wylie IT 部门正在考虑把以后的发布版销售给其他学校、学院和综合性大学。因此，课程注册系统将具有可扩展性，并且所有用户群体的数据（例如大学名称）都表驱动方式，在系统安装时很容易对数据进行修改。
用户简档
注册员：
注册员负责管理每个学期的课程注册。注册员通常是受过大学教育、具有丰富计算机技能的专业技术人员。目前的注册员已经接受老式的面向批的注册系统使用培训。
教授：
使用课程注册系统的教授受过良好教育，具有计算机知识而且熟悉 Wylie 注册流程。可以假设不是所有的教授家里都有个人计算机，而且不是所有的教授都能够访问 Internet。
学生：
每个学期有多达 2000 名学生将使用课程注册系统来注册课程和查看他们最终的成绩。学生们一般都受过教育，有计算机知识，而且能够访问 Internet。预计每个学期有 10% 的学生第一次在 Wylie 注册，因而对课程注册的流程不熟悉。
用户环境
用户群体位于 Wylie College 校园中。课程注册系统安装在学院管理总部大楼之外，连接校园的局域网。学生和教授可以通过学院图书馆和学生宿舍内的个人计算机自由地访问该局域网。
关键用户需要
通过对学生、教授以及课程注册员进行有代表性的抽样用户调查，确定现有课程注册系统存在的问题并征求用户的改进意见。全部的调查结果记录在涉众请求文档 [4] 中。调查结果的摘要按照相对重要性从高到低的顺序列出：
学生课程注册系统运行缓慢，效率低下。通常，学生需要填好课程注册单并交给注册员。注册员要花费多达 2 周的时间来处理这些表单，然后再花费 1 周的时间把确认信息反馈给学生。由此，如果课程满员或学生兴趣偏好转变引起课程表变更，那么都需要注册员花费三周的时间来重复整个处理工作。这使得给学生选择课程表的余地就非常有限。学生们希望通过在线访问，迅速确定选择哪些开设的课程以及任课教授。
建议能够尽快查看到学生成绩。期末考试成绩报告单通常在考期开始 8 周后邮寄给学生。在此期间内，学生们会不断地打电话给他们的教授，希望早点知道他们的分数。完成抽样调查的绝大多数学生都建议能够在线访问查看个人的课程成绩。
办工时间长，费用高。每个学期注册员和 2-3 个临时雇请的办事人员要花费 400 — 500 个小时来处理课程注册的文书工作。很大一部分时间是用来往课程注册主数据库中录入信息，以及为解决课程表冲突和课程开设问题将一部分学生重新登记到其他课程中。如果学生能够访问课程注册系统，则将有效地完全减少这项工作。
备选方案和竞争
用户群体对可行的备选方案或市售的解决方案一无所知。用户群体支持由学院内部进行系统开发的方案，以便降低费用，确保功能合适并保障对系统进行连续支持和维护。
产品概述
本节对课程注册系统的功能、外部收费系统和课程目录数据库系统的接口以及系统配置进行高度概括说明。
产品总体效果
课程注册系统将代替 Wylie College 现有的大型机课程注册系统。如下面环境图所示，新系统将和现有的收费系统和课程目录数据库系统交互（请参见图 6.1.1）。
如图 6.1.2 所示，课程注册系统由客户机构件和服务器构件组成。服务器构件位于 Wylie College UNIX 服务器中。服务器构件必须和位于 College DEC VAX 大型机上的收费和课程目录数据库系统交互。现有的 Open SQL Interface 支持该接口。
客户机构件在个人计算机上。学院的 PC 机将配置安装客户机构件。不属于学院的 PC 机必须通过 Internet 从 UNIX 服务器上下载客户机软件。只要 PC 机上安装了客户构件，那么用户就可以通过 College LAN 或 Internet 从 PC 机访问课程注册系统。必须输入有效的 ID 号和口令，才能访问系统。
图 6.1.1 课程注册系统环境图
图 6.1.2 课程注册系统概述
功能摘要
在本节的表中根据产生的利益和有关特性确定课程注册系统的主要功能。这些特性将在本文档的第 7 节作进一步的说明。有关术语的说明，请参考词汇表 [5]。
客户利益
支持功能
最新的课程信息 系统访问课程目录数据库以获得有关 Wylie College 开设的所有课程的最新信息。
对每门课程，学生和教授可以查看课程说明、先决条件、任课教师、上课地点和课程时间。
最新的注册信息 所有的课程注册被立即记录到注册数据库中，以提供最新的有关课程满员或课程取消的信息。
方便而且及时访问查看课程成绩 学生只要提供他们的用户 ID 和口令就可以查看到他们所有课程的成绩。
学生们可以通过 Internet 从任何一台学院 PC 或他们家里的 PC 访问课程注册系统。
教授们通过他们的 PC 机直接把所有学生的成绩输入到注册数据库中。
从任何一台学院 PC 机访问 学生们可以通过 Internet 从任何一台学院 PC 机或他们家里的 PC 机访问课程注册系统。
通过 Internet 在 PC 机上安装课程注册系统客户机构件是一个很方便执行的过程。
从家中的 PC 机进行访问非常容易方便 学生们可以通过 Internet 从任何一台学院 PC 或他们家里的 PC 访问课程注册系统。
安全和保密 需要提供有效的用户 ID 和口令才能访问课程注册系统。
学生成绩报告单信息受保护，未经许可不能访问。
即时反馈课程满员或课程取消的信息 所有的课程注册被立即记录到注册数据库中，以提供最新的有关课程满员或课程取消的信息。
假设与依赖关系
下列假设和依赖关系涉及到前景文档中所概述的课程注册系统的功能。
驻留在 College DEC VAX 大型机中现有的收费和课程目录数据库系统至少到 2005 年前将继续获得支持。
收费和课程目录数据库系统的外部接口按 [2] 和 [3] 进行定义，并且将不被修改。
假定学院将继续运行并支持现有的 UNIX 服务器和 DEC VAX 大型机至少到 2005 年。
假定到 2005 年之前将获得额外的资金来更换遗留的收费和课程目录数据库系统。
新注册系统在 2000 年一月份学期开始时是否能及时投入使用取决于投资在 1999 年 3 月 1 日以前是否获得批准。
成本与定价
由于投资资金有限，开发系统的费用不能超过 $1,200,000。
预计学院现有的计算机将用作目标计算机，因此就需要硬件预算。
许可与安装
系统使用的 1.0 版本没有许可要求，因为该版本仅用于 Wylie College。
客户机构件的安装必须过软盘、CD或从 Internet 上下载来进行。
服务器构件的安装必须提供两个选项，即保留现有注册数据库（不丢失任何数据）或者生成一个新的数据库。
功能属性
课程注册系统中已定义的功能指定了属性，这些属性可以用来对提议进行实施的产品进行评估、追踪、确定优先级和管理。在需求属性指南 [6] 中定义了适用于此开发的功能属性。
产品特性
本节定义并说明课程注册系统的功能。功能特性是给用户带来利益所必需的高级系统性能。
登录
学生、教授和课程注册员都必须提供有效的 ID 和口令才能进入课程注册系统。当用户申请进入学院时，他们将得到 ID 和临时口令。系统应允许用户修改他们的临时口令。
课程注册
系统根据学生的请求向学生显示可选的课程。学生应可以根据课程名称、课程代码和所在系来对课程进行查询。系统将接受学生的课程注册，并根据课程的开设情况、课程表冲突和完成必修课程等情况来进行核实。如果课程注册没有成功，那么系统应立即通知学生。
在注册期结束以前，系统应允许学生更改课程选择。
课程取消
系统应允许注册员取消课程。通常，注册员在注册期结束前检查所有的课程，并取消那些没有任课教师或者选课人数少于 3 人的课程。课程注册员通过电话或邮件通知选择了被取消课程的学生。
学生收费
在注册期结束后，系统将给收费系统发出通知。这些通知应包括学生姓名、地址、所选课程和收费金额。
输入、更新和查看教授信息
系统应接受和更新教授信息，包括姓名、地址、电话、传真和电子邮件地址。教授信息应能够让教授和课程注册员查看。
查看学生成绩
系统应允许学生查看某门课程的成绩或全部的成绩报告单。同时，系统应保护学生的成绩信息，除了学生本人和教授以外的其他用户不能访问这些信息。
选择要讲授的课程
系统应使教授能够在注册期结束前登记要讲授的课程。
输入、更新和查看学生信息
系统应接受和更新学生信息，包括学生的 ID、姓名、地址、电话、和电子邮件地址。学生信息应能够让教授和课程注册员查看。系统应确保学生只能访问他（她）本人的信息。注册员维护学生信息。
记录学生成绩
系统应接受、确认和保留教授输入的学生成绩。
查看课程目录信息
保存在课程目录数据库中的课程目录信息应根据用户的请求显示给用户。用户可以根据课程名称、课程代码、教授姓名和所在系来查询课程信息。
查看课程表
系统应根据学生的请求显示该学生全部课程的时间安排。
监控课程是否满员
系统应确保没有一门课程选修的学生人数超过 10 名。
约束
除了第 6 节中列出的假设和依赖关系以外，下列约束也适用于课程注册系统。
系统不需开发或购置任何硬件。
可用的课程信息限于为现有课程目录数据库所支持的数据类型。
质量范围
本节定义课程注册系统的质量范围，包括性能、强壮性、容错性、可用性以及类似特征。
可用性：系统在每周七天，每天二十四小时内都应可以使用。
易用性：系统应易于使用，并适合由具有计算机知识的学生和教授构成的目标市场的需要。
易用性：系统应包括提供给用户的联机帮助。学生和教授不需要借助书面的用户手册来使用系统。
可维护性：系统设计应以易于维护的目标。学院特有的所有数据应采用表驱动方式，不需要重新编译系统就可以进行修改。
优先级
本节提供有关建议使用的系统功能的相对重要性的指导说明。本前景文档中定义的功能应包括在系统最早的 2 个发布版中。第一个发布版本计划包括所有与学生注册有关的关键功能。
随着系统开发的进行，功能属性（参考本文档第 7 节）将用来权衡功能的相对重要性并计划发布版本的内容。利益、工作量和风险等属性被用于确定功能的优先级和目标发布版。
预计课程注册系统将通过发布 2-4 个发布版本来实现在 Wylie College 的全面使用。
发布版 1 必须至少包含如下所列的基本功能：
登录
课程注册
课程目录数据库的接口
维护学生信息
维护教授信息
发布版 2 应该包括：
提交学生成绩
查看成绩
选择要讲授的课程
发布版 3 的功能还没有确定。预计这个发布版将增强现有的功能。
在 2005 年发布的版本 4 的目标是替换遗留的收费系统和课程数据库系统。
其他产品需求
适用的标准
桌面用户界面应与 Windows 95/98 兼容。
系统需求
系统应与现有的课程目录数据库系统交互。课程注册系统应支持在 [3] 中所定义的数据格式。
系统应与现有的收费系统交互，并支持在 [2] 中定义的接口。
系统的服务器构件应在学院校园网服务器上运行，并运行在 UNIX 操作系统下。
系统的客户机构件应运行在配置 486 微处理器或更高配置的个人计算机上。
系统的客户构件最多要求 32 MB 内存和 20 MB 磁盘空间。
系统的客户机构件应在 Windows 95、Windows 98 和 Microsoft Windows NT 环境中运行。
性能需求
在任意既定时刻，系统最多可支持 2000 名用户同时使用中央数据库，并在任意时刻最多可支持 500 名用户同时使用本地服务器。
系统将能在十秒钟内提供对遗留课程目录数据库的访问。
系统应在 2 分钟内完成全部处理事务的 80%。
环境需求
无。
文档需求
本节说明课程注册系统的文档需求。
用户手册
用户手册应从学生、教授和注册员的角度说明系统的使用方法。用户手册应包括：
最低系统需求
PC 客户机的安装
登录
注销
所有的系统功能部件
客户支持信息
用户手册应采用 Wylie College 用户手册模板所定义的格式。
用户手册的内容量应在 50 — 100 页之间。用户手册的页面尺寸为 7×9 英寸。用户手册应提供硬拷贝，也可以通过联机帮助获得。
联机帮助
用户可以获得每项系统功能的联机帮助。用户手册中所涉及的每个主题也应可以通过联机帮助获得。
安装向导、配置和自述文件
服务器部分的安装向导应包括：
最低系统需求
安装指导
配置学院特有的参数
如何初始化课程注册数据库
如何保留现有的课程注册数据库
客户支持信息
如何定制升级
自述文件应在安装后可以显示。自述文件还应保留在磁盘上，用户在任何时候都可以查看它。自述文件应包括：
新发布版的特性
已知错误和解决方法
标签与包装
Wylie College 徽标在用户文档和显示屏幕中十分引人注目。
因为初始发布版只针对 Wylie College 而不是面向一般市场，所以没有编写产品的市场营销资料和宣传材料，也没有对产品进行包装。
&copy;
1987 - 2001 Rational Software Corporation。版权所有。
Rational Unified Process
需求属性指南
版本 1.0
修订历史记录
日期
版本
说明
作者
08/Jan/1999 1.0 初始发布版 Simon Jones
目录
目标
范围
参考
需求属性
产品需求属性
状态
利益
工作量
风险
目标发布版
职责分配
用例需求属性
状态
优先级
工作量估计
技术风险
目标开发迭代
职责分配
Rose 模型
测试用例属性
测试状态
工作版本号
测试者
测试日期
测试说明
可追踪性标准
产品需求标准
用例需求标准
测试需求标准
需求属性指南
目标
需求属性指南确定并说明将用于管理课程注册系统需求的属性。此外，本文档还概述了项目在开发过程中将要维护的需求可追踪性。
分配给每个需求的属性将用于管理软件开发和确定每一个发布版的特性的优先级。
保持需求可追踪性的目的是为了减少在开发周期后期发现缺陷的数量。确保所有产品需求记录在软件需求、设计和测试用例中，这样会提高产品的质量。
范围
本文档中的属性和可追踪性指南适用于课程注册系统的产品需求、软件需求和测试需求。
参考
适用的参考资料包括：
课程注册系统前景文档，WyIT387，1.0 版，1998，Wylie College IT。
课程注册系统补充规约，WyIT400，草案，1998，Wylie College IT。
用例规约 - 结束注册，WyIT403，草案，1998，Wylie College IT。
用例规约 - 登录，WyIT401，草案，1998，Wylie College IT。
用例规约 - 维护教授信息，WyIT407，草案，1998，Wylie College IT。
用例规约 - 课程注册，WyIT402，草案，1998，Wylie College IT。
用例规约 - 选择要讲授的课程，WyIT405，草案，1998，Wylie College IT。
用例规约 - 维护学生信息，WyIT408，草案，1998，Wylie College IT。
用例规约 - 提交成绩，WyIT409，草案，1998，Wylie College IT。
用例规约 - 查看成绩报告单，WyIT410，草案，1998，Wylie College IT。
课程注册系统测试计划，WyIT<TBD>，Wylie College IT。
需求属性
本节确定将要管理的需求的类型，以及确定用于各个需求类型的属性。课程注册系统将确定并管理以下需求类型：
产品需求，
用例需求，和
测试用例。
本项目正计划使用 RequisitePro 来这些管理需求。本节所描述的属性将在 RequisitePro 中定义。RequisitePro 能够按照属性对在 Word 文档中标记的每个需求进行说明。RequisitePro 也可用来追踪需求（如本文档第 5 节所述）。
产品需求属性
通过本节定义的属性来管理产品需求（在前景文档 [1] 中定义）。这些属性有助于管理开发工作和确定针对不同发布版的特性的优先级。
状态
在前景文档中定义了产品需求后进行设置。用于在确立项目基线的过程中对进度进行跟踪。
已提出 用于说明正在进行讨论但尚未经过复审和批准的特性。
已批准 性能被认为是有用可行的，并且已批准进行实施。
已并入 在特定时间点并入产品基线中的特性。
利益
由市场经理、产品经理或业务分析员设置。并非所有需求都同等重要。通过按照各项需求对最终用户的相对利益来划分其等级，可以促使客户、分析员和开发团队成员相互交换意见。用于管理规模和确定开发优先级。
产品经理将利用关键、重要、可用三个层次来具体说明每个已提议特性的优点。
关键 必不可少的特性。不实现这些规约就无法使系统满足客户的需要。所有关键特性都必须在发布时实施，否则将错过预定的发布时间。
重要 对于系统在大多数应用中的有效性及效率都较为重要的特性。很难通过其他方式来实现这方面的功能。如果遗漏了某项重要特性，就可能会影响客户或用户满意度，甚至会影响收入，但发布并不会因为缺少任意一项重要特性而延期。
有用 有些特性在不太典型的应用中比较有用，或者可以合理而有效地实现其替代特性，这些特性的使用次数将会相对较少。即使发布版中没有包括某一项这样的特性，也不会对收入或客户满意度造成严重的影响。
工作量
由开发团队设置。由于有些特性所需的时间和资源多于其他特性，所以在评测复杂程度并预计在给定时间范围内能否完成哪些工作时，最佳的方式就是估计团队工作周数或个人工作周数、所需的代码行数或功能点数（举例来说）。用于管理规模和确定开发优先级。
在课程注册系统中，工作量用人员天数来确定。
风险
由开发团队根据项目遭遇意外事件的可能性来设置，这些事件包括超支、工期延误，甚至是项目取消。虽然可以对风险级别进行细分，但大多数项目经理都发现把风险归类为高、中、低就足够了。通过评测项目团队进度估计的不确定性（范围），一般都可以间接地对风险进行评估。
在课程注册项目中，项目经理把风险定义为高、中、低三个级别。
高 风险的影响严重，并且风险发生的概率也很高。
中 风险的影响不太严重，并且风险发生的概率也不太高。
低 风险的影响最小，并且风险发生的概率也很低。
目标发布版
记录将首次包括指定特性的产品版本。该字段可用于将前景文档中的特性分配给特定的基线发布版。如果将其与状态字段结合，项目团队就可以提出、记录和讨论发布版的各种特性，而不对其进行开发。只有状态被设置为“已并入”且目标发布版已确定的特性才将被实施。当进行规模管理时，可以增加目标发布版号，这样该项特性虽然仍保留在前景文档中，但将安排在以后发布。
在课程注册系统中，这些特性将计划包含在前 3 个发布版中。
R 1.0 计划课程注册发布版 1.0 的发布日程（1999 年 10 月）
R 2.0 计划课程注册发布版 2.0 的发布日程（2000 年 10 月）
R 3.0 计划课程注册发布版 3.0 的发布日程（2001 年 10 月）
其他 计划未来发布版 TBD 的日程
职责分配
在许多项目中，特性将被分配给“特性团队”，这些团队负责进一步获取需求，并编写软件需求和实施方案。这一简单的下拉列表将帮助项目团队中的每位成员更好地理解他们的职责。
用例需求属性
用例需求（在课程注册用例规约 [3 - 10] 和补充规约 [2] 中定义）将利用本节定义的属性来进行管理。这些属性有助于管理开发工作，决定迭代内容，以及将用例和它们特定的 Rose 模型相关联。
状态
在分析人员起草用例后设置。从用例的最初起草直到最后确认的整个过程中追踪用例的编制进度。
已提出 用例已经确定但尚未通过复审和批准。
已批准 用例已被批准进行进一步的设计和实施。
已确认 用例已在系统测试中得到确认。
优先级
由项目经理来设置。根据给用例分配开发资源和监测用例编制进度的重要性来确定用例的优先级。优先级一般根据用户考虑的利益、计划的发布和迭代、用例的复杂性（风险）、以及实施用例的工作量来确定的。
高 相对于确保密切监控用例实施并给任务适当地分配资源而言，用例具有较高的优先级。
中 相对于其他用例而言，用例具有中等优先级。
低 用例具有较低优先级。此用例的实施不太关键，而且可以在以后的迭代和发布中继续进行或重新安排。
工作量估计
由开发团队设置。由于有些特性所需的时间和资源多于其他特性，所以在评测复杂程度并预计在给定时间范围内能否完成哪些工作时，最佳的方式就是估计团队工作周数或个人工作周数、所需的代码行数或功能点数（举例来说）。用于管理规模和确定开发的优先级。项目经理利用这些工作量估计的结果来确定项目进度并有效地根据任务计划资源分配。
课程注册项目用人员天数来估计工作量（假定一个工作日有 7.5 个小时）。
技术风险
由开发团队根据用例遭遇意外事件的概率来设置，这些事件包括工作量超限、设计有瑕疵、存在大量缺陷、质量和性能低下等。诸如此类的意外事件通常是由没有很好地理解或定义需求、知识不足、缺乏资源、技术复杂以及新技术、新工具、新设备等引起的。
课程注册项目将每个用例的技术风险分成高、中、低三类。
高 风险的影响严重，并且风险发生的概率也很高。
中 风险的影响不太严重，并且风险发生的概率也不太高。
低 风险的影响最小，并且风险发生的概率也很低。
目标开发迭代
记录将实施用例的开发迭代。计划每个发布版的开发在项目构建阶段中将执行若干次开发迭代。
项目经理利用分配给每个用例的迭代数目来计划项目团队的活动。
当前的计划是课程注册项目在构建阶段要经历 3-4 次迭代。在每次迭代中，所选的用例集将要进行编码和测试。
迭代 E-1 为精化阶段安排的一次迭代，即迭代 1
迭代 C-1 为构建阶段安排的第一次迭代，即迭代 1
迭代 C-2 为构建阶段安排的第二次迭代，即迭代 2
迭代 C-3 为构建阶段安排的第三次迭代，即迭代 3
职责分配
用例被分配给个人或开发团队作进一步的分析、设计和实施。一个简单的下拉列表将帮助项目团队中的每位成员更好地理解他们的职责。
Rose 模型
确定和用例需求相关联的 Rose 用例模型。
测试用例属性
利用本节定义的属性来计划并追踪测试用例（在课程注册系统测试计划 [11] 中定义）。
测试状态
由测试负责人设置。追踪每个测试用例的状态。
未测试
尚未执行测试用例。
失败
测试已经执行，但失败了。
有条件的通过
测试已经完成，但还存在问题。测试之所以通过是因为完成了某些操作。
通过
测试成功地完成。
工作版本号
记录将要核实特定测试用例的系统工作版本。
课程注册系统将在构建阶段的几次迭代中进行实施。一次迭代通常需要 1-3 个工作版本。
工作版本 A 为系统工作版本 A 准备的测试用例
工作版本 B 为系统工作版本 B 准备的测试用例
工作版本 C 为系统工作版本 C 准备的测试用例
工作版本 D 为系统工作版本 D 准备的测试用例
工作版本 E 为系统工作版本 E 准备的测试用例
工作版本 F 为系统工作版本 F 准备的测试用例
工作版本 G 为系统工作版本 G 准备的测试用例
工作版本 H 为系统工作版本 H 准备的测试用例
工作版本 I 为系统工作版本 I 准备的测试用例
工作版本 J 为系统工作版本 J 准备的测试用例
工作版本 K 为系统工作版本 K 准备的测试用例
工作版本 L 为系统工作版本 L 准备的测试用例
测试者
被指派来执行并核实测试用例的个人。这一简单的下拉列表将帮助项目团队中的每位成员更好地理解他们的职责。
测试日期
计划的测试日期或实际的测试日期。
测试说明
所有与计划和执行测试相关的说明。
可追踪性标准
产品需求标准
在前景文档 [1] 中定义的产品需求将追踪到在用例规约 [3]、[4]、[5]、[6]、[7]、[8]、[9]、[10] 和补充规约 [2] 中相应的用例或补充需求。
每个产品需求追踪到一个或多个用例需求和补充需求。
用例需求标准
在用例规约 [3]、[4]、[5]、[6]、[7]、[8]、[9]、[10] 和补充规约 [2] 中定义的用例需求将追踪到在测试计划 [11] 中指定的相应测试用例。
每个用例需求追踪到一个或多个系统测试用例。
测试需求标准
在测试计划 [11] 中说明的测试用例被追踪回到通过特定测试用例进行核实的产品需求 [1] 和用例需求 [2]、[3]、[4]、[5]、[6]、[7]、[8]、[9]、[10]。
一个测试用例可以追踪回到一个或多个产品和用例需求。在测试用例正在核实一个派生需求或设计的情况下，该测试用例可能不具有追溯到原来产品需求或用例需求的可追踪性。
&copy;
1987 - 2001 Rational Software Corporation。版权所有。
Rational Unified Process
课程注册系统
前景文档
版本 1.0
修订历史记录
日期
版本
说明
作者
1/Dec/98 草案 初始草案 Sue Gamble
13/Dec/98 1.0 平级复审后的局部修订。
添加了性能需求。
Sue Gamble
目录
目标
范围
参考
定位
商机
问题说明
产品定位说明
用户描述
用户/消费者统计数据
用户简档
用户环境
关键用户需要
备选方案和竞争
产品概述
产品总体效果
功能摘要
假设与依赖关系
成本与定价
许可与安装
功能属性
产品特性
登录
课程注册
课程取消
学生收费
输入、更新和查看教授信息
查看学生成绩
选择要讲授的课程
输入、更新和查看学生信息
记录学生成绩
查看课程目录信息
查看课程表
监控课程是否满员
约束
质量范围
优先级
其他产品需求
适用的标准
系统需求
性能需求
环境需求
文档需求
用户手册
联机帮助
安装向导、配置和自述文件
标签与包装
前景
目标
本文档的目的是根据最终用户的需要来定义 Wylie 课程注册 (C-Registration) 系统的高级需求。
范围
本前景文档适用于将由 Wylie College 信息系统 (IT) 部门开发的 Wylie 课程注册系统。IT 部门将开发这套客户机服务器系统，以便同现有的课程目录数据库结合起来使用。
课程注册系统将为学生提供在线课程注册的服务。课程注册系统可以让教授选择其要讲授的课程并保存学生的成绩。
参考
适用的参考资料包括：
课程注册系统的系统商业理由，WyIT388，草案，1998，Wylie College IT。
课程收费接口规约，WC93332，1985，Wylie College Press。
课程目录数据库规约，WC93422，1985，Wylie College Press。
课程注册系统涉众请求文档，WyIT389，1.0 版，1998，Wylie College IT。
课程注册系统词汇表，WyIT406，1.0 版，1998，Wylie College IT。
课程注册系统需求属性指南，WyIT404，1.0 版，1998，Wylie College IT。
定位
商机
本项目将用一个最新的在线系统来代替现有课程注册系统的整个前端处理机，从而让学生和教授可以通过 PC 客户机来访问系统。
现有的注册系统从 1985 年投入使用，到目前处理 2000 年计划的学生和课程数据负载的能力已经捉襟见肘。另外，现有系统使用的是过时的大型机技术，该技术只支持通过注册办公室的职员来访问系统。而新系统将提供两种方式让所有的教授和学生访问系统：将个人计算机连接到 Wylie College 计算机网络以及连接到 Internet。
新系统将使 Wylie College 步入课程注册系统的领先行列，从而改善学校的形象，吸引更多的学生以及提高管理工作的效率。
问题说明
问题是 Wylie College 过时的、很大部分依靠手工进行的学生注册流程。
影响 学生、教授和大学管理部门。
其后果是 流程缓慢且费用高昂，学生和教授皆不满意。
成功的解决办法是 改善大学的形象，吸引更多的学生和提高注册管理部门的工作效率。
产品定位说明
针对于 Wylie College 的学生、教授和课程注册员。
谁 参加、讲授或管理大学课程。
课程注册系统 是一个工具。
因为 实现在线课程注册和访问课程及成绩信息。
不同于 已有过时的大型机注册系统。
我们的产品 任何一台 PC 只要通过 College LAN 或 Internet 连接，就能够向所有用户提供有关所有课程、注册、教师和成绩的最新信息。
用户描述
本节描述 Wylie 课程注册系统的用户。课程注册系统有 3 种类型的用户：课程注册员、学生和教授。
用户/消费者统计数据
大学用户群是一个庞大复杂的群体，他们要求在线课程注册系统能够提供巨大的灵活性和快速的响应时间。
这些用户受过教育，具有计算机知识，而且在大多数情况下，家里都拥有个人计算机。通过个人计算机在线注册课程和复查成绩，这种能力将大大提高课程注册的效率。
课程注册系统的初始发布版将仅限于 Wylie College。Wylie IT 部门正在考虑把以后的发布版销售给其他学校、学院和综合性大学。因此，课程注册系统将具有可扩展性，并且所有用户群体的数据（例如大学名称）都表驱动方式，在系统安装时很容易对数据进行修改。
用户简档
注册员：
注册员负责管理每个学期的课程注册。注册员通常是受过大学教育、具有丰富计算机技能的专业技术人员。目前的注册员已经接受老式的面向批的注册系统使用培训。
教授：
使用课程注册系统的教授受过良好教育，具有计算机知识而且熟悉 Wylie 注册流程。可以假设不是所有的教授家里都有个人计算机，而且不是所有的教授都能够访问 Internet。
学生：
每个学期有多达 2000 名学生将使用课程注册系统来注册课程和查看他们最终的成绩。学生们一般都受过教育，有计算机知识，而且能够访问 Internet。预计每个学期有 10% 的学生第一次在 Wylie 注册，因而对课程注册的流程不熟悉。
用户环境
用户群体位于 Wylie College 校园中。课程注册系统安装在学院管理总部大楼之外，连接校园的局域网。学生和教授可以通过学院图书馆和学生宿舍内的个人计算机自由地访问该局域网。
关键用户需要
通过对学生、教授以及课程注册员进行有代表性的抽样用户调查，确定现有课程注册系统存在的问题并征求用户的改进意见。全部的调查结果记录在涉众请求文档 [4] 中。调查结果的摘要按照相对重要性从高到低的顺序列出：
学生课程注册系统运行缓慢，效率低下。通常，学生需要填好课程注册单并交给注册员。注册员要花费多达 2 周的时间来处理这些表单，然后再花费 1 周的时间把确认信息反馈给学生。由此，如果课程满员或学生兴趣偏好转变引起课程表变更，那么都需要注册员花费三周的时间来重复整个处理工作。这使得给学生选择课程表的余地就非常有限。学生们希望通过在线访问，迅速确定选择哪些开设的课程以及任课教授。
建议能够尽快查看到学生成绩。期末考试成绩报告单通常在考期开始 8 周后邮寄给学生。在此期间内，学生们会不断地打电话给他们的教授，希望早点知道他们的分数。完成抽样调查的绝大多数学生都建议能够在线访问查看个人的课程成绩。
办工时间长，费用高。每个学期注册员和 2-3 个临时雇请的办事人员要花费 400 — 500 个小时来处理课程注册的文书工作。很大一部分时间是用来往课程注册主数据库中录入信息，以及为解决课程表冲突和课程开设问题将一部分学生重新登记到其他课程中。如果学生能够访问课程注册系统，则将有效地完全减少这项工作。
备选方案和竞争
用户群体对可行的备选方案或市售的解决方案一无所知。用户群体支持由学院内部进行系统开发的方案，以便降低费用，确保功能合适并保障对系统进行连续支持和维护。
产品概述
本节对课程注册系统的功能、外部收费系统和课程目录数据库系统的接口以及系统配置进行高度概括说明。
产品总体效果
课程注册系统将代替 Wylie College 现有的大型机课程注册系统。如下面环境图所示，新系统将和现有的收费系统和课程目录数据库系统交互（请参见图 6.1.1）。
如图 6.1.2 所示，课程注册系统由客户机构件和服务器构件组成。服务器构件位于 Wylie College UNIX 服务器中。服务器构件必须和位于 College DEC VAX 大型机上的收费和课程目录数据库系统交互。现有的 Open SQL Interface 支持该接口。
客户机构件在个人计算机上。学院的 PC 机将配置安装客户机构件。不属于学院的 PC 机必须通过 Internet 从 UNIX 服务器上下载客户机软件。只要 PC 机上安装了客户构件，那么用户就可以通过 College LAN 或 Internet 从 PC 机访问课程注册系统。必须输入有效的 ID 号和口令，才能访问系统。
图 6.1.1 课程注册系统环境图
图 6.1.2 课程注册系统概述
功能摘要
在本节的表中根据产生的利益和有关特性确定课程注册系统的主要功能。这些特性将在本文档的第 7 节作进一步的说明。有关术语的说明，请参考词汇表 [5]。
客户利益
支持功能
最新的课程信息 系统访问课程目录数据库以获得有关 Wylie College 开设的所有课程的最新信息。
对每门课程，学生和教授可以查看课程说明、先决条件、任课教师、上课地点和课程时间。
最新的注册信息 所有的课程注册被立即记录到注册数据库中，以提供最新的有关课程满员或课程取消的信息。
方便而且及时访问查看课程成绩 学生只要提供他们的用户 ID 和口令就可以查看到他们所有课程的成绩。
学生们可以通过 Internet 从任何一台学院 PC 或他们家里的 PC 访问课程注册系统。
教授们通过他们的 PC 机直接把所有学生的成绩输入到注册数据库中。
从任何一台学院 PC 机访问 学生们可以通过 Internet 从任何一台学院 PC 机或他们家里的 PC 机访问课程注册系统。
通过 Internet 在 PC 机上安装课程注册系统客户机构件是一个很方便执行的过程。
从家中的 PC 机进行访问非常容易方便 学生们可以通过 Internet 从任何一台学院 PC 或他们家里的 PC 访问课程注册系统。
安全和保密 需要提供有效的用户 ID 和口令才能访问课程注册系统。
学生成绩报告单信息受保护，未经许可不能访问。
即时反馈课程满员或课程取消的信息 所有的课程注册被立即记录到注册数据库中，以提供最新的有关课程满员或课程取消的信息。
假设与依赖关系
下列假设和依赖关系涉及到前景文档中所概述的课程注册系统的功能。
驻留在 College DEC VAX 大型机中现有的收费和课程目录数据库系统至少到 2005 年前将继续获得支持。
收费和课程目录数据库系统的外部接口按 [2] 和 [3] 进行定义，并且将不被修改。
假定学院将继续运行并支持现有的 UNIX 服务器和 DEC VAX 大型机至少到 2005 年。
假定到 2005 年之前将获得额外的资金来更换遗留的收费和课程目录数据库系统。
新注册系统在 2000 年一月份学期开始时是否能及时投入使用取决于投资在 1999 年 3 月 1 日以前是否获得批准。
成本与定价
由于投资资金有限，开发系统的费用不能超过 $1,200,000。
预计学院现有的计算机将用作目标计算机，因此就需要硬件预算。
许可与安装
系统使用的 1.0 版本没有许可要求，因为该版本仅用于 Wylie College。
客户机构件的安装必须过软盘、CD或从 Internet 上下载来进行。
服务器构件的安装必须提供两个选项，即保留现有注册数据库（不丢失任何数据）或者生成一个新的数据库。
功能属性
课程注册系统中已定义的功能指定了属性，这些属性可以用来对提议进行实施的产品进行评估、追踪、确定优先级和管理。在需求属性指南 [6] 中定义了适用于此开发的功能属性。
产品特性
本节定义并说明课程注册系统的功能。功能特性是给用户带来利益所必需的高级系统性能。
登录
学生、教授和课程注册员都必须提供有效的 ID 和口令才能进入课程注册系统。当用户申请进入学院时，他们将得到 ID 和临时口令。系统应允许用户修改他们的临时口令。
课程注册
系统根据学生的请求向学生显示可选的课程。学生应可以根据课程名称、课程代码和所在系来对课程进行查询。系统将接受学生的课程注册，并根据课程的开设情况、课程表冲突和完成必修课程等情况来进行核实。如果课程注册没有成功，那么系统应立即通知学生。
在注册期结束以前，系统应允许学生更改课程选择。
课程取消
系统应允许注册员取消课程。通常，注册员在注册期结束前检查所有的课程，并取消那些没有任课教师或者选课人数少于 3 人的课程。课程注册员通过电话或邮件通知选择了被取消课程的学生。
学生收费
在注册期结束后，系统将给收费系统发出通知。这些通知应包括学生姓名、地址、所选课程和收费金额。
输入、更新和查看教授信息
系统应接受和更新教授信息，包括姓名、地址、电话、传真和电子邮件地址。教授信息应能够让教授和课程注册员查看。
查看学生成绩
系统应允许学生查看某门课程的成绩或全部的成绩报告单。同时，系统应保护学生的成绩信息，除了学生本人和教授以外的其他用户不能访问这些信息。
选择要讲授的课程
系统应使教授能够在注册期结束前登记要讲授的课程。
输入、更新和查看学生信息
系统应接受和更新学生信息，包括学生的 ID、姓名、地址、电话、和电子邮件地址。学生信息应能够让教授和课程注册员查看。系统应确保学生只能访问他（她）本人的信息。注册员维护学生信息。
记录学生成绩
系统应接受、确认和保留教授输入的学生成绩。
查看课程目录信息
保存在课程目录数据库中的课程目录信息应根据用户的请求显示给用户。用户可以根据课程名称、课程代码、教授姓名和所在系来查询课程信息。
查看课程表
系统应根据学生的请求显示该学生全部课程的时间安排。
监控课程是否满员
系统应确保没有一门课程选修的学生人数超过 10 名。
约束
除了第 6 节中列出的假设和依赖关系以外，下列约束也适用于课程注册系统。
系统不需开发或购置任何硬件。
可用的课程信息限于为现有课程目录数据库所支持的数据类型。
质量范围
本节定义课程注册系统的质量范围，包括性能、强壮性、容错性、可用性以及类似特征。
可用性：系统在每周七天，每天二十四小时内都应可以使用。
易用性：系统应易于使用，并适合由具有计算机知识的学生和教授构成的目标市场的需要。
易用性：系统应包括提供给用户的联机帮助。学生和教授不需要借助书面的用户手册来使用系统。
可维护性：系统设计应以易于维护的目标。学院特有的所有数据应采用表驱动方式，不需要重新编译系统就可以进行修改。
优先级
本节提供有关建议使用的系统功能的相对重要性的指导说明。本前景文档中定义的功能应包括在系统最早的 2 个发布版中。第一个发布版本计划包括所有与学生注册有关的关键功能。
随着系统开发的进行，功能属性（参考本文档第 7 节）将用来权衡功能的相对重要性并计划发布版本的内容。利益、工作量和风险等属性被用于确定功能的优先级和目标发布版。
预计课程注册系统将通过发布 2-4 个发布版本来实现在 Wylie College 的全面使用。
发布版 1 必须至少包含如下所列的基本功能：
登录
课程注册
课程目录数据库的接口
维护学生信息
维护教授信息
发布版 2 应该包括：
提交学生成绩
查看成绩
选择要讲授的课程
发布版 3 的功能还没有确定。预计这个发布版将增强现有的功能。
在 2005 年发布的版本 4 的目标是替换遗留的收费系统和课程数据库系统。
其他产品需求
适用的标准
桌面用户界面应与 Windows 95/98 兼容。
系统需求
系统应与现有的课程目录数据库系统交互。课程注册系统应支持在 [3] 中所定义的数据格式。
系统应与现有的收费系统交互，并支持在 [2] 中定义的接口。
系统的服务器构件应在学院校园网服务器上运行，并运行在 UNIX 操作系统下。
系统的客户机构件应运行在配置 486 微处理器或更高配置的个人计算机上。
系统的客户构件最多要求 32 MB 内存和 20 MB 磁盘空间。
系统的客户机构件应在 Windows 95、Windows 98 和 Microsoft Windows NT 环境中运行。
性能需求
在任意既定时刻，系统最多可支持 2000 名用户同时使用中央数据库，并在任意时刻最多可支持 500 名用户同时使用本地服务器。
系统将能在十秒钟内提供对遗留课程目录数据库的访问。
系统应在 2 分钟内完成全部处理事务的 80%。
环境需求
无。
文档需求
本节说明课程注册系统的文档需求。
用户手册
用户手册应从学生、教授和注册员的角度说明系统的使用方法。用户手册应包括：
最低系统需求
PC 客户机的安装
登录
注销
所有的系统功能部件
客户支持信息
用户手册应采用 Wylie College 用户手册模板所定义的格式。
用户手册的内容量应在 50 — 100 页之间。用户手册的页面尺寸为 7×9 英寸。用户手册应提供硬拷贝，也可以通过联机帮助获得。
联机帮助
用户可以获得每项系统功能的联机帮助。用户手册中所涉及的每个主题也应可以通过联机帮助获得。
安装向导、配置和自述文件
服务器部分的安装向导应包括：
最低系统需求
安装指导
配置学院特有的参数
如何初始化课程注册数据库
如何保留现有的课程注册数据库
客户支持信息
如何定制升级
自述文件应在安装后可以显示。自述文件还应保留在磁盘上，用户在任何时候都可以查看它。自述文件应包括：
新发布版的特性
已知错误和解决方法
标签与包装
Wylie College 徽标在用户文档和显示屏幕中十分引人注目。
因为初始发布版只针对 Wylie College 而不是面向一般市场，所以没有编写产品的市场营销资料和宣传材料，也没有对产品进行包装。
&copy;
1987 - 2001 Rational Software Corporation。版权所有。
Rational Unified Process
K
Kevinjoan
Unregistered / Unconfirmed
GUEST, unregistred user!
课程注册系统
用例规约
查看成绩报告单用例
版本：草案
修订历史记录
日期
版本
说明
作者
21/Dec/98 草案 草案版本 S. Gamble
目录
简要说明
事件流
基本流 - 查看成绩报告单
备选流
没有可以查看的成绩信息
特殊需求
前置条件
登录
后置条件
扩展点
查看成绩报告单用例
简要说明
本用例允许学生查看他（她）过去学期已修课程的成绩报告单。
本用例的主角是学生。
事件流
当学生从主窗体中选择“查看成绩报告单”活动时，此用例就开始使用了。
基本流 — 查看成绩报告单
系统检索出学生上个学期所修完的每门课程的成绩信息。
然后系统准备和编排成绩单的格式，接着显示成绩信息。
当学生结束查看成绩信息后，他选择“关闭”。
备选流
没有可以查看的成绩信息
如果在基本流中，系统无法检索到学生上个学期的任何成绩信息，那么系统将显示一个消息。学生确认这条错误消息后，此用例即终止。
问题：学生是否可以访问过去各学期的成绩？
特殊需求
特殊需求将在下次迭代中确定。
前置条件
登录
在此用例开始前，学生要登录到系统。
后置条件
后置条件将在下次迭代中确定。
扩展点
业务用例的扩展点将在精化阶段中确定。
&copy;
1987 - 2001 Rational Software Corporation。版权所有。
Rational Unified Process
课程注册系统
用例规约
维护学生信息用例
版本：草案
修订历史记录
日期
版本
说明
作者
21/Dec/98 草案 草案版 S. Gamble
目录
1 简要说明
2. 事件流
基本流 - 添加学生信息
备选流
修改学生信息
删除学生信息
特殊需求
前置条件
登录
后置条件
扩展点
维护学生信息用例
简要说明
本用例允许注册员维护注册系统中的学生信息。其中包括添加、修改和从系统中删除学生信息。
本用例的主角是注册员。
事件流
当注册员从主窗体中选择“维护学生信息”活动时，用例就开始使用了。
基本流 - 添加学生信息
注册员选择“添加学生信息”。
系统会显示一张空白学生信息表。
注册员输入学生的下列信息：姓名、出生日期、社会保障号、目前状况和毕业日期。
系统验证数据以确保格式正确，并按照指定的姓名来搜索已经在系统中存在记录的学生信息。如果数据有效，那么系统将生成一个新的学生信息并分配一个由系统生成的唯一 ID 号。
每向系统中添加一个学生信息，都需要重复步骤 2-4。当注册员完成向系统添加学生信息时，此用例结束。
备选流
修改学生信息
问题：必须确保用于修改和删除学生信息的流类似于修改和删除教授信息的流。
删除学生信息
问题：必须确保用于修改和删除学生信息的流类似于修改和删除教授信息的流。
特殊需求
特殊需求将在下次迭代中确定。
前置条件
登录
在本用例开始前，注册员要登录到系统。
后置条件
后置条件将在下次迭代中确定。
扩展点
业务用例的扩展点将在精化阶段中确定。
&copy;
1987 - 2001 Rational Software Corporation。版权所有。
Rational Unified Process
课程注册系统
用例规约
提交成绩用例
版本：草案
修订历史记录
日期
版本
说明
作者
21/Dec/98 草案 草案版本 S. Gamble
目录
简要说明
事件流
基本流 - 提交成绩
备选流
特殊需求
前置条件
登录
后置条件
扩展点
提交成绩用例
简要说明
本用例允许教授提交上个学期结束授课的一个或多个班的学生成绩。
本用例的主角是教授。
事件流
当教授从主窗体中选择“提交成绩”活动时，此用例就开始使用了。
基本流 — 提交成绩
系统显示教授上个学期所讲授课程的列表。
教授选择某门课程。
系统检索出所有登记学习这门课程的学生名单列表。系统还检索出这门课程中每个学生的学习成绩信息。
系统显示每个学生及其过去学习该课程所获得的成绩。
对表中的每位学生，教授输入成绩：A、B、C、D、F 或 I。系统记录下该学生此门课程的成绩。如果教授想跳过某位学生，那么该生的成绩信息可以留为空白并在以后填写。教授也可以通过输入一个新成绩来修改学生的成绩。
备选流
问题：此用例的错误条件没有得到分析，需要在此进行补充。
特殊需求
特殊需求将在下次迭代中确定。
前置条件
登录
在本用例开始前，教授要登录到系统。
后置条件
后置条件将在下次迭代中确定。
扩展点
业务用例的扩展点将在精化阶段中确定。
&copy;
1987 - 2001 Rational Software Corporation。版权所有。
Rational Unified Process
课程注册系统
用例规约
选择讲授课程的用例
版本：草案
修订历史记录
日期
版本
说明
作者
21/Dec/98 草案 草案版本 S. Gamble
目录
简要说明
事件流
基本流 - 选择讲授课程
备选流
特殊需求
前置条件
登录
后置条件
扩展点
选择讲授课程的用例
简要说明
本用例允许教授从课程目录里选择他（她）在新学期适合任教而且也愿意讲授的课程（课程的时间和日期将在以后安排）。
教授是开始本用例的主角。课程目录系统是用例中包含的一个主角。
事件流
当教授从主窗体中选择“选择讲授课程”活动时，此用例就开始使用了。
基本流 — 选择讲授课程
系统检索并显示本学期教授胜任教学的课程的列表。系统还检索并显示教授以前选择讲授的课程的列表。
教授可以选择在新学期他（她）希望讲授的课程，或者取消选择。
对于被取消的课程，系统将教授的信息从该课程中删除。
系统核实所选课程之间不存在冲突（比如，相同的日期和时间），或者所选课程与教授以前登记讲授的课程没有冲突。如果没有冲突，系统为教授所选的每门课程更新课程信息。
备选流
问题：添加流以处理以下情况：
处理课程表安排的冲突
注册期已经结束
教授不胜任该课程的教学。
特殊需求
特殊需求将在下次迭代中确定。
前置条件
登录
在本用例开始前，教授要登录到系统。
后置条件
后置条件将在下次迭代中确定。
扩展点
业务用例的扩展点将在精化阶段中确定。
&copy;
1987 - 2001 Rational Software Corporation。版权所有。
Rational Unified Process
课程注册系统
用例规约
课程注册用例
版本：草案
修订历史记录
日期
版本
说明
作者
21/Dec/98 草案 草案版本 S. Gamble
目录
简要说明
事件流
基本流 - 创建课程表
备选流
修改课程表
删除课程表
课程目录系统不可用
特殊需求
前置条件
登录
后置条件
扩展点
课程注册用例
简要说明
本用例允许学生注册本学期所修的课程。如果在学期开始的选/退课期间情况发生一些变化，那么学生也可以修改或删除自己所选的课程。课程目录系统提供一个本学期所有课程的列表。
本用例主要的主角是学生。课程目录系统是用例中包含的一个主角。
事件流
当学生从主窗体中选择“维护课程表”活动时，此用例就开始使用了。
基本流 - 创建课程表
学生选择“创建课程表”。
系统会显示一张空白课程表。
系统从课程目录系统中检索可选课程的列表。
学生从可选课程列表中选择 4 门主修课程和 2 门选修课程。在完成选择后，学生选择“提交”。
每门已选的课程都将被添加到课程表中。
系统保存该课程表。
备选流
修改课程表
TBD。
删除课程表
TBD。
课程目录系统不可用
如果经过一定次数的尝试之后，系统仍然无法与课程目录系统通信，那么系统将向学生显示一条错误信息。学生确认这条错误消息后，此用例终止。
特殊需求
特殊需求将在下次迭代中确定。
前置条件
登录
在此用例开始前，学生要登录到系统。
后置条件
后置条件将在下次迭代中确定。
扩展点
业务用例的扩展点将在精化阶段中确定。
&copy;
1987 - 2001 Rational Software Corporation。版权所有。
Rational Unified Process
课程注册系统
用例规约
维护教授信息用例
版本：草案
修订历史记录
日期
版本
说明
作者
21/Dec/98 草案 草案版本 S. Gamble
目录
简要说明
事件流
基本流 - 添加教授信息
备选流
修改和删除教授信息
特殊需求
前置条件
登录
后置条件
扩展点
维护教授信息用例
简要说明
本用例允许注册员维护注册系统中的教授信息。其中包括添加、修改和从系统中删除教授信息。
本用例的主角是注册员。
事件流
当注册员从主窗体中选择“维护教授信息”时，本用例就开始使用了。
基本流 - 添加教授信息
注册员选择“添加教授信息”。
系统会显示一张空白教授信息表。
注册员为教授输入以下信息： 姓名、出生日期、社会保障号、目前状况和所在系。
系统验证数据以确保数据格式正确，并按照指定的姓名来搜索已经在系统中存有记录的教授。如果数据有效，系统将创建一个新的教授信息并分配一个由系统生成的唯一 ID 号。该号码将显示出来，这样就可以在以后的系统使用中使用它。
每向系统添加一个教授信息，都要重复步骤 2-4。当注册员结束向系统中添加教授信息时，此用例结束。
备选流
修改和删除教授信息
TBD
特殊需求
特殊需求将在下次迭代中确定。
前置条件
登录
在本用例开始前，注册员要登录到系统。
后置条件
后置条件将在下次迭代中确定。
扩展点
业务用例的扩展点将在精化阶段中确定。
&copy;
1987 - 2001 Rational Software Corporation。版权所有。
Rational Unified Process
课程注册系统
用例规约
登录用例
版本：草案
修订历史记录
日期
版本
说明
作者
21/Dec/98 草案 草案版本 S. Gamble
目录
简要说明
事件流
基本流 - 登录
备选流
无效的用户名/口令
特殊需求
前置条件
后置条件
扩展点
登录用例
简要说明
本用例说明用户如何登录到课程注册系统。
启用此用例的主角为学生、教授和注册员。
事件流
本用例以主角在登录表中键入他/她的名字和口令作为开始。
基本流 - 登录
系统验证主角的口令并允许他（她）登录到系统。
系统显示主窗体，同时用例结束。
备选流
无效的用户名/口令
问题：需要确定对于此应用程序来说口令安全措施是否是必要的。
特殊需求
特殊需求将在下次迭代中确定。
前置条件
前置条件将在下次迭代中确定。
后置条件
后置条件将在下次迭代中确定。
扩展点
业务用例的扩展点将在精化阶段中确定。
&copy;
1987 - 2001 Rational Software Corporation。版权所有。
Rational Unified Process
用例规约
查看成绩报告单用例
版本：草案
修订历史记录
日期
版本
说明
作者
21/Dec/98 草案 草案版本 S. Gamble
目录
简要说明
事件流
基本流 - 查看成绩报告单
备选流
没有可以查看的成绩信息
特殊需求
前置条件
登录
后置条件
扩展点
查看成绩报告单用例
简要说明
本用例允许学生查看他（她）过去学期已修课程的成绩报告单。
本用例的主角是学生。
事件流
当学生从主窗体中选择“查看成绩报告单”活动时，此用例就开始使用了。
基本流 — 查看成绩报告单
系统检索出学生上个学期所修完的每门课程的成绩信息。
然后系统准备和编排成绩单的格式，接着显示成绩信息。
当学生结束查看成绩信息后，他选择“关闭”。
备选流
没有可以查看的成绩信息
如果在基本流中，系统无法检索到学生上个学期的任何成绩信息，那么系统将显示一个消息。学生确认这条错误消息后，此用例即终止。
问题：学生是否可以访问过去各学期的成绩？
特殊需求
特殊需求将在下次迭代中确定。
前置条件
登录
在此用例开始前，学生要登录到系统。
后置条件
后置条件将在下次迭代中确定。
扩展点
业务用例的扩展点将在精化阶段中确定。
&copy;
1987 - 2001 Rational Software Corporation。版权所有。
Rational Unified Process
课程注册系统
用例规约
维护学生信息用例
版本：草案
修订历史记录
日期
版本
说明
作者
21/Dec/98 草案 草案版 S. Gamble
目录
1 简要说明
2. 事件流
基本流 - 添加学生信息
备选流
修改学生信息
删除学生信息
特殊需求
前置条件
登录
后置条件
扩展点
维护学生信息用例
简要说明
本用例允许注册员维护注册系统中的学生信息。其中包括添加、修改和从系统中删除学生信息。
本用例的主角是注册员。
事件流
当注册员从主窗体中选择“维护学生信息”活动时，用例就开始使用了。
基本流 - 添加学生信息
注册员选择“添加学生信息”。
系统会显示一张空白学生信息表。
注册员输入学生的下列信息：姓名、出生日期、社会保障号、目前状况和毕业日期。
系统验证数据以确保格式正确，并按照指定的姓名来搜索已经在系统中存在记录的学生信息。如果数据有效，那么系统将生成一个新的学生信息并分配一个由系统生成的唯一 ID 号。
每向系统中添加一个学生信息，都需要重复步骤 2-4。当注册员完成向系统添加学生信息时，此用例结束。
备选流
修改学生信息
问题：必须确保用于修改和删除学生信息的流类似于修改和删除教授信息的流。
删除学生信息
问题：必须确保用于修改和删除学生信息的流类似于修改和删除教授信息的流。
特殊需求
特殊需求将在下次迭代中确定。
前置条件
登录
在本用例开始前，注册员要登录到系统。
后置条件
后置条件将在下次迭代中确定。
扩展点
业务用例的扩展点将在精化阶段中确定。
&copy;
1987 - 2001 Rational Software Corporation。版权所有。
Rational Unified Process
课程注册系统
用例规约
提交成绩用例
版本：草案
修订历史记录
日期
版本
说明
作者
21/Dec/98 草案 草案版本 S. Gamble
目录
简要说明
事件流
基本流 - 提交成绩
备选流
特殊需求
前置条件
登录
后置条件
扩展点
提交成绩用例
简要说明
本用例允许教授提交上个学期结束授课的一个或多个班的学生成绩。
本用例的主角是教授。
事件流
当教授从主窗体中选择“提交成绩”活动时，此用例就开始使用了。
基本流 — 提交成绩
系统显示教授上个学期所讲授课程的列表。
教授选择某门课程。
系统检索出所有登记学习这门课程的学生名单列表。系统还检索出这门课程中每个学生的学习成绩信息。
系统显示每个学生及其过去学习该课程所获得的成绩。
对表中的每位学生，教授输入成绩：A、B、C、D、F 或 I。系统记录下该学生此门课程的成绩。如果教授想跳过某位学生，那么该生的成绩信息可以留为空白并在以后填写。教授也可以通过输入一个新成绩来修改学生的成绩。
备选流
问题：此用例的错误条件没有得到分析，需要在此进行补充。
特殊需求
特殊需求将在下次迭代中确定。
前置条件
登录
在本用例开始前，教授要登录到系统。
后置条件
后置条件将在下次迭代中确定。
扩展点
业务用例的扩展点将在精化阶段中确定。
&copy;
1987 - 2001 Rational Software Corporation。版权所有。
Rational Unified Process
课程注册系统
用例规约
选择讲授课程的用例
版本：草案
修订历史记录
日期
版本
说明
作者
21/Dec/98 草案 草案版本 S. Gamble
目录
简要说明
事件流
基本流 - 选择讲授课程
备选流
特殊需求
前置条件
登录
后置条件
扩展点
选择讲授课程的用例
简要说明
本用例允许教授从课程目录里选择他（她）在新学期适合任教而且也愿意讲授的课程（课程的时间和日期将在以后安排）。
教授是开始本用例的主角。课程目录系统是用例中包含的一个主角。
事件流
当教授从主窗体中选择“选择讲授课程”活动时，此用例就开始使用了。
基本流 — 选择讲授课程
系统检索并显示本学期教授胜任教学的课程的列表。系统还检索并显示教授以前选择讲授的课程的列表。
教授可以选择在新学期他（她）希望讲授的课程，或者取消选择。
对于被取消的课程，系统将教授的信息从该课程中删除。
系统核实所选课程之间不存在冲突（比如，相同的日期和时间），或者所选课程与教授以前登记讲授的课程没有冲突。如果没有冲突，系统为教授所选的每门课程更新课程信息。
备选流
问题：添加流以处理以下情况：
处理课程表安排的冲突
注册期已经结束
教授不胜任该课程的教学。
特殊需求
特殊需求将在下次迭代中确定。
前置条件
登录
在本用例开始前，教授要登录到系统。
后置条件
后置条件将在下次迭代中确定。
扩展点
业务用例的扩展点将在精化阶段中确定。
&copy;
1987 - 2001 Rational Software Corporation。版权所有。
Rational Unified Process
课程注册系统
用例规约
课程注册用例
版本：草案
修订历史记录
日期
版本
说明
作者
21/Dec/98 草案 草案版本 S. Gamble
目录
简要说明
事件流
基本流 - 创建课程表
备选流
修改课程表
删除课程表
课程目录系统不可用
特殊需求
前置条件
登录
后置条件
扩展点
课程注册用例
简要说明
本用例允许学生注册本学期所修的课程。如果在学期开始的选/退课期间情况发生一些变化，那么学生也可以修改或删除自己所选的课程。课程目录系统提供一个本学期所有课程的列表。
本用例主要的主角是学生。课程目录系统是用例中包含的一个主角。
事件流
当学生从主窗体中选择“维护课程表”活动时，此用例就开始使用了。
基本流 - 创建课程表
学生选择“创建课程表”。
系统会显示一张空白课程表。
系统从课程目录系统中检索可选课程的列表。
学生从可选课程列表中选择 4 门主修课程和 2 门选修课程。在完成选择后，学生选择“提交”。
每门已选的课程都将被添加到课程表中。
系统保存该课程表。
备选流
修改课程表
TBD。
删除课程表
TBD。
课程目录系统不可用
如果经过一定次数的尝试之后，系统仍然无法与课程目录系统通信，那么系统将向学生显示一条错误信息。学生确认这条错误消息后，此用例终止。
特殊需求
特殊需求将在下次迭代中确定。
前置条件
登录
在此用例开始前，学生要登录到系统。
后置条件
后置条件将在下次迭代中确定。
扩展点
业务用例的扩展点将在精化阶段中确定。
&copy;
1987 - 2001 Rational Software Corporation。版权所有。
Rational Unified Process
课程注册系统
用例规约
维护教授信息用例
版本：草案
修订历史记录
日期
版本
说明
作者
21/Dec/98 草案 草案版本 S. Gamble
目录
简要说明
事件流
基本流 - 添加教授信息
备选流
修改和删除教授信息
特殊需求
前置条件
登录
后置条件
扩展点
维护教授信息用例
简要说明
本用例允许注册员维护注册系统中的教授信息。其中包括添加、修改和从系统中删除教授信息。
本用例的主角是注册员。
事件流
当注册员从主窗体中选择“维护教授信息”时，本用例就开始使用了。
基本流 - 添加教授信息
注册员选择“添加教授信息”。
系统会显示一张空白教授信息表。
注册员为教授输入以下信息： 姓名、出生日期、社会保障号、目前状况和所在系。
系统验证数据以确保数据格式正确，并按照指定的姓名来搜索已经在系统中存有记录的教授。如果数据有效，系统将创建一个新的教授信息并分配一个由系统生成的唯一 ID 号。该号码将显示出来，这样就可以在以后的系统使用中使用它。
每向系统添加一个教授信息，都要重复步骤 2-4。当注册员结束向系统中添加教授信息时，此用例结束。
备选流
修改和删除教授信息
TBD
特殊需求
特殊需求将在下次迭代中确定。
前置条件
登录
在本用例开始前，注册员要登录到系统。
后置条件
后置条件将在下次迭代中确定。
扩展点
业务用例的扩展点将在精化阶段中确定。
&copy;
1987 - 2001 Rational Software Corporation。版权所有。
Rational Unified Process
课程注册系统
用例规约
登录用例
版本：草案
修订历史记录
日期
版本
说明
作者
21/Dec/98 草案 草案版本 S. Gamble
目录
简要说明
事件流
基本流 - 登录
备选流
无效的用户名/口令
特殊需求
前置条件
后置条件
扩展点
登录用例
简要说明
本用例说明用户如何登录到课程注册系统。
启用此用例的主角为学生、教授和注册员。
事件流
本用例以主角在登录表中键入他/她的名字和口令作为开始。
基本流 - 登录
系统验证主角的口令并允许他（她）登录到系统。
系统显示主窗体，同时用例结束。
备选流
无效的用户名/口令
问题：需要确定对于此应用程序来说口令安全措施是否是必要的。
特殊需求
特殊需求将在下次迭代中确定。
前置条件
前置条件将在下次迭代中确定。
后置条件
后置条件将在下次迭代中确定。
扩展点
业务用例的扩展点将在精化阶段中确定。
&copy;
1987 - 2001 Rational Software Corporation。版权所有。
Rational Unified Process