打开项目视图

打开名为 StarDraw 的演示工程

打开名为 WorldHello_Branch 的分支（视图）

显示 Change Request 列表

Starteam 的视图中，左侧的面板显示的是文件夹列表，右侧上边的面板是主要的任务区，选择 Change Request 页，则查看当前目录下的 Change Request 列表。

缺陷控制目录下的 Change Request 列表

以 test1（测试工程师1）登录，提交新发现的 bug；

在模块1的目录下输入新的 Change Request。

输入 Change Request 的概要（synopsis），指定模块的负责人。如果不清楚负责人，可以指定开发经理（devleader）为该 Change Request 的负责人（Responsibility）。

输入该 Change Request 的详细描述、重现方法等信息。

完成该 Change Request 的提交。

开发经理收到邮件

测试工程师1 在 Starteam 中提交 Change Request，并指定负责人为开发经理（devleader）后，Starteam 自动向开发经理发送通知邮件。

开发经理收到邮件

开发经理将修正该 Change Request 的任务分配到相应的开发工程师

开发经理打开 Starteam 相应视图，属于其本人负责的 Change Request 加亮显示。

开发经理将该 Change Request 的负责人指定为 dev1 （开发工程师1）。

Starteam 的 Change Request 亦被版本控制

test1 用户提交的 Change Request，再经过 devleader 用户的修改，产生了两版本，如下：

右侧下方切换到 history 面板，显示两个版本。

比较两个版本的 Change Request 的差异。

开发工程师 1 收到开发经理的邮件

开发经理将Change Request 的负责人指定为 dev1 后，开发工程师 1 收到邮件。

开发工程师 1 收到邮件

开发工程师修正 Bug，回填 Change Request。

开发工程师将 Change Request 的状态修改为 "In Progress"，表明自己已经注意到该问题，并正在修改当中。

修改完毕、提交代码、重新编译产品之后，在 Solution（解决方案）域填写解决方案，并将 Change Request 的状态修改为 "Fixed"。Starteam 会自动向该 Change Request 的提出者 test1 发出该 Change Request 已经修复的 Email 通知。

测试工程师对修正进行测试，测试通过则将该 Change Request 状态设置为 "Verified Fixed"

测试工程师对该 Change Request 的修正进行测试，测试通过则将该 Change Request 状态设置为 "Verified Fixed"

测试经理（testleader）定期检查 Change Request 状态，复核并关闭 Change Request

测试经理可以利用 Starteam 的 Filter 中的 "By Status & Responsibility"，以分组的形式查看所有的 Change Request。对于长时间处于 "New" 和 "Open" 的 Change Request 要督促相关人员注意，对于处于 "Verified Fixed" 的 Change Request，要进行复核，对于确实完成修正的将状态改为 "Closed"。

按照状态和负责人格式查看 Change Request

对于处于 "Verified Fixed" 的 Change Request，要进行复核，对于确实完成修正的将状态改为 "Closed"