1, 确定和描述主角。
（1） 谁使用系统
（2） 谁从系统中得到信息
（3） 谁向系统提供信息
（4） 公司什么地方使用系统
（5） 谁支持维护系统
（6） 其他什么系统使用该系统
2，确定用例，写一个简洁的描述
确定用例可以通过回答以下问题来解决：
（1） 主角用系统作什么？
（2） 主角是否在系统中创建、存储、改变、删除或读取数据
（3） 主角是否需要通知系统外部事件或者变化？
（4） 是否需要通知主角系统内发生的事情
确定用例的名字：
以动词开头，说明主角用该用例作什么
Description：elaborates the intent of the use case.
3，确定主角和用例之间的关系（只有一个主角能够发起用例，但是一个用例可能有很多个主角）
分析每个用例，看看（1）主角和用例交互什么
（2）审查主角的预期行为来验证，主角是否参与了所有必要的用例，并到达了指定的结果。
4，Ouline the individual use cases略述单个用例
主要注意f flows of event
基本流：
（1） 什么事件发起该用例
（2） 用例如何结束
（3） 用例如何重复某种行为
替换流：
（1） 在用例中有可选环境吗？
（2） 可能发生什么偶然事件？
（3） What variants might happen?
（4） 什么可能出错
（5） 什么可能不发生
（6） 什么资源可能阻塞
5，细化用例
所有替换流All alternate flows(including exception conditions
前置和后置条件
前置条件：描述了在用例开始之前必须为真的条件
后置条件：描述了用例完成时系统的持续状态。
情节串联板定义了：
（1） Who the players are
（2） What happens to them
（3） How it happens
组织需求信息的要点：
（1） 对于复杂应用，必须获取需求并将其记录在文档、数据库、模型，或工具中
（2） 不同类型的项目要求不同的需求组织技术
（3） 复杂系统需要每个子系统都有规格说明
如何组织需求信息：
1,复杂硬软件系统的需求，先定义系统的top-level需求和feature,然后使用System engineering的方法把系统分为若干个子系统，为每个子系统写需求，并不涉及子系统的自系统，依次下去
2，组织可能含有相同功能的产品族，
（1） product-family vision document
（2） family-common use case model
（3） 为共享的功能定义common supplementary specification
（4） 对于家族中的每个产品,分别定义vision document, supplementary specification, and use-case model
关于前景文档Vision document：描述用户的需要，系统地feature，问题领域和solution space
控制在20-40页
前景文档应该是项目早期的主要工作重点
前景文档是对产品或应用中所有最重要内容的简洁描述。
Delta vision document: 只关注两件事情：什么被改变了，其他用来提示上下文信息的信息。
产品经理的职责：help software teams build products that customers want to buy.
确定项目范围：
Project scope is a function of:
(1) The functionality that must be delivered to meet user’s need.
(2) The resources available to the project.
(3) The time available in which to achieve the implementation.
项目范围来自以下因素：
（1） 资源（开发者，测试者，技术编写者，质量保证者等）
（2） 时间
如何确定：
（1） 制定需求基线
（2） 设定优先级
（3） 评估工作量
（4） 加入风险因素
