在这个阶段我们看到了用例的演进（通过可跟踪性和文档化）并且通过 ASDI 参与的用例的检查，我们快速的发现我们是自由主题方式的专家。这通常是软件开发项目中的最大挑战之一，因此早期的并有效地建立这种关系才是真正的胜利。我们与 ASDI 的关心通常是很好的。他们很快的理解并同意了基于 RUP 的开发过程而没有花费我们太多的精力。这是令人惊讶的，被他们给的首选的瀑布型的开发最终取得了这个和约。很多被 RUP 鼓励的迭代和增量开发的方法被良好的进行了调整，并且 ASDI 也看到可好处。
我们幸运的是工具的选择相当的简单，并在项目的早期被完成。Rational 的一些工具被用来节省我们的时间。在之前的项目中我们使用 Excel 来管理需求，但是我们发现 Rational RequisitePro 是一流的并是完整的方案。此外， Rational SoDA 报告可以大大的降低我们的文档生成的成本。因为这个项目是我们第一次使用 SoDA，我们非常高兴 ASDI 对标准的 SoDA 模板表示满意。
到现在为止，我们把焦点放到了需求相关的产物上，并且花费了相对来说不多的时间来评估技术并创建原型以支持工具的选择。现在对我们来说重要的是通过创建更有挑战的原型来揭示系统更加复杂的领域，并开始在实际的开发中使用工具。我们是否会用到 XML ？如果会用到，我们应该使用什么样的解释器？我们需要什么样的安全机制？我们应该使用 Enterprise JavaBeans 吗？象这些问题我们将很快有答案。
换句话说，是时候从分析转移到架构和设计了 — 尽可能快而不是晚，因为大多数的技术风险将在接下来的几周显现出来。我们有一个很好的功能基线包含一系列定义良好的用例。对于我们来说避免分析麻痹大意和维护前进的动力是重要的。
没有新的风险被识别出来；实际上我们的风险列表比以前更短了。因为 ASDI 同意对于这个项目 OODB 是不合适的，我们因此不再有技术上的风险要管理。他们也放松了对我们的交付产物的正规形式和他们预想的结构，并且他们毫无保留的批准了我们的基于 RUP 框架的文档。
在我们关心的剩余时间和工作量的问题上，当我们增加了对所需能够的理解和对技术熟悉后，我们觉得预算更加符合项目情况了。更进一步的技术探索勿庸置疑的将揭开新的挑战。
