CAB与OOAD(上)续一
我们要求所记录的需求是准确的、清晰的、合理的。在此基础上，系统的需求制品主要包括：
GUI快速原型可以在白板或者草纸上进行绘制，如果是白板的话在大致定稿的情况下需要数码照片的留存，以便参考。也可以在Visio或者UIStudio上进行绘制。但是请注意这里的GUI快速原型并不构成最终制品的一部分，它只作为获取需求以及验证需求的手段。
关于用例，我们需要注明组成系统的主要用例简图。其中每一个用例都需要文本描述，这种描述可以是概述，也可以是基于Cockburn的用例格式。但是请注意，每一段用例文本一定要包含的三要素是：参与者对系统的操作、系统的操作、系统对参与者的返回信息。
术语表需要记录系统中存在的领域模型。它的主要目的是帮助涉众对所在的领域达成共识。术语表整理可以参照分类列表结合名词识别的方法完成。
补充规约主要用来记录系统中存在的非功能性需求。也可以在用例文本的尾部注明所属的补充规约文本。
对于需求我们需要注意，不要在一开始就想着完整的定义所有的需求。需求是变更的，因此我们需要在一开始尽可能的宽泛(宽泛的意思并非大概、也许，它是严谨的)的记录下我们当时可以发现的需求，寻找出它们中对于系统中最重要的部分，划分出需求的优先级来。根据优先级制作第一个迭代的产品，然后不断的反馈和改进，事实上这是避免浪费的最好方法。
1.2 分析
在分析这个部分我们的主要目的是将需求转化为分析类的方式：边界类、控制类和实体类。
边界类的主要来源是需求制品中的GUI快速原型。
实体类的主要来源则出自需求制品中的术语表。
控制类主要用来连接边界类和实体类，帮助它们进行沟通。
借助健壮性分析图，我们可以获取这些内容： 
主动边界类是主动参与者与系统沟通交互的部分，多指系统的界面部分。
被动边界类则是系统与被动参与者沟通交互的部分，多指与第三方系统的接口。
实体类是往往是系统中用来记录系统状态信息的部分。
控制类要承载的主要工作有两个小部分，一个是处理与边界类沟通的部分，另一个是与实体类沟通的部分。
1.3 简单设计
我们需要将分析类依据MVC或者是MVP模式的方式分配到系统的架构体系中。
多数情况下，主动边界类直接对应着View。而Model的部分主要由两个部分组成，一个部分是由实体类组成的领域模型包，另一部分则是将控制类切分，将与实体类相关的操作提取出来放置在Model模块中。剩下的另一个部分控制类则形成了Controller的部分。
