电子数据库？使用商业性的缺陷与变更跟踪工具（如 IBM Rational ClearQuest），允许在Web上提交变更请求，不需要本地软件安装，并且允许 CCB 进行查询以筛选变更请求并确定接受哪些，从而极大地简化了变更请求的管理。
然后项目团队需要决定 CCB 多久应碰一次面来检查变更请求，并且要决定在确定应该实现哪一个时所使用的标准。
技巧2：在加强已建立的变更请求过程中学会说"No"
作为开发人员，您在成功建立变更请求过程中扮演了关键角色。越是没有让 CCB 评估它们就接受和实施来自典型来源（如，销售人员、客户和高级经理等）的特别变更请求，项目团队就越感觉变更无穷无尽。同样，这只会增加直接奔您而来的特别请求的数量，因为请求者知道您是他们实现希望的特性所可以依赖的人。
为了帮助控制影响您项目团队的持续不断的变更，您必须学会向请求者说"不"，并且将他们引导到您已建立的变更控制过程。这看上去可能很容易，但是这通常会导致高压情形。比如，最成功的销售人员可能很有影响力和说服力，并且通常是很多特别请求的煽动者。销售人员通过说这样的话来施加压力，"如果您添加那个特性我就用不着 XYZ 账户了"或者"我最近从竞争对手那里丢掉了很多生意，因为我们没有 ABC 特性"。不管他的论据看上去多么充分，您和开发团队都必须表现出坚定的原则，并礼貌地将这些请求者引导到您已建立的变更控制过程中。这些请求者的行为不可能一夜之间改变，但是假以时日，一定会有所改观。
技巧3：建立和参与需求规格说明书检查
需求规格说明书检查是确认是否理解需求的简单有效的方法。作为开发人员，您知道不管何时收到一组需求您都会有很多问题，因为有些规格说明书不清楚或者是含糊的。与其猜测规格说明书的意图，从而增加不能交付客户期望的软件的风险并导致返工，不如为项目计划分配时间进行定期的需求规格说明书检查。这些检查不需要很正式，相反它们应该是一个开放的论坛，需求规格说明书的特定部分都可以拿来与指定的开发人员公开讨论，以保证人们清楚地理解了这些需求。
作为开发人员，应该主动参与这些检查会议，并且应该在对需求的解释的基础上准备一个初步的设计或者概念。该过程本质上是高度迭代的，因为在开发团队能够对需求有一个清楚的理解并且开始设计之前通常需要多次会议。同样，通过这些迭代，保证所有变更被正确捕获和记录就是分析人员的责任了。在您以及其他开发人员开始设计之前，整个项目团队必须对所有需求有一致的理解。
此外，需求规格说明书检查的迭代本性为项目团队提供了一种自我检查机制，保证了软件需求和初步设计的质量。通过保持这两个工件的同步，项目团队会保持同步前进，并增加交付成功解决方案的机会。因此，在实际阶段应该分配时间进行需求规格说明书检查。经常在设计阶段，很多开发人员在需求规格说明书检查中发现更多的含糊性需要澄清。这里再一次需要需求规格说明书检查。
技巧4：需要一个术语表
术语表是消除需求规格说明书中模糊性并避免误解的简单却强有力的手段，应该由分析人员拥有、开发和维护。由于时间的限制，项目团队成员可能不知道他们对同一需求有着不同的解释。术语表不需要列出需求规格说明书中用过的每一个词汇，但是它必须包含可能有歧义的词汇。术语表通过给出需求规格说明书中关键词汇的定义，消除了模糊性。如果术语表中的词汇有具体和重要的关系（比如，在构建财务应用中，客户可能只有一定数目的账户，并且同一账户不能被两个以上的人拥有），您可能希望用一个域模型来补充术语表。该域模型可视化地描述了客户与账户之间的一致关系，因为开发软件时需要考虑这些关系。
&nb