通过用例组织需求
首先，最最重要的是，我们必须有一份愿景：一家企业的愿景就是里程碑似的战略目标（Microsoft：让每个桌面都有一台电脑），同样，开发一个软件系统的愿景也是它的战略目标。识别愿景的时候，可以问3个问题：
1.为什么要开发这个系统
2.谁出钱买这个系统
3.怎样才会觉得值
这些问题不但要提给自己，更要以各种方式提给客户，来求证他们心目中期待的软件给他们带来的价值。这并不意味着客户说什么是什么，他们嘴里说的和潜意识中期望的往往并不一样。比如提出要把信息电子化的人，真正想要的可能是快捷的查询和可靠的保存。因此不要让虚假的愿景蒙蔽了，注意，真正的愿景目标必须是可度量的（否则以后怎么判断是否达到了这个目标？）
确立了愿景之后，我们就可以着手识别和组织需求了。用例是一种有效的表达需求的手段，它帮助甚至是”强迫“我们从用户的视角来思考问题，使需求真正体现对用户的价值。用例本身提供了形式化的表示规范，这个规范体现了需求的组织层次：
在这种形式下，所有的需求都是围绕用例来组织的。
通过用例组织需求可以分为以下几个步骤：
1.识别执行者：这一步的关键在于确认”边界“——执行者一定要在边界之外，并且这个边界是从责任上划分的，不是从物理上划分的；另外要注意的一点就是要避免“不甘心”心理——由于执行者直接与系统交互，他们往往是一些打工者，或者代办人，例如银行的职员，而直接顾客或者老板却不是执行者（注意这里与业务建模时的区别），这是正常现象。
2.识别用例：这一步的关键是“价值”——已经反复强调过了，只有为执行者提供了完整的价值动作，才能提取为用例；而且，这一价值必须是由软件系统提供的，而不仅仅是用户要求的。识别用例常犯的错误是把操作步骤当用例，特别是把“增删改查”操作统统当成用例来看，事实上，这些CRUD操作很有可能不足以构成用例（不足以向执行者提供价值），即使能构成用例，用一个“管理××”的用例来表示也足够了。
3.书写用例文档：用例文档不等于用例图，用例图只是总的组织结构。一份标准的用例文档应当包含以下内容：
描述用例时要考虑到涉众利益，并且需要平衡涉众利益。经典定义：“Cockburn：用例是涉众之间达成的契约，以执行者为达成特定目标和系统交互的方式演绎“—— 这句写得实在太精彩了！
“ 4.通过关系整理用例：特别注意不要滥用用例之间的关系，越简单易理解越好。
5.用例的排序和分包：通过对用例进行排序，可以确定以后迭代开发的次序
