原型法是指在 获取一组基本的需求定义后，利用高级软件工具可视化的开发环境，快速地建立一个目标系统的最初版本，并把它交给用户试用、补充和修改，再进行新的版本开发。 反复进行这个过程，直到用户满意为止的一种方法。

先有成品，反复迭代

用例图(Use Case Diagram)是 由软件需求分析到最终实现的第一步 ，它描述人们如何使用一个系统。用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及用户需要为系统提供的服务，以便使系统的用户更容易理解这些元素的用途，也便于软件开发人员实现这些元素。用例图最常用来描述系统及子系统。

在实际项目中，原始需求的描述形式可能是文字、活动图、序列图或其它形式，不管使用哪种形式，术语不统一的现象非常常见。

为项目创建一个术语表。确保项目中的每个人都能以清晰一致的术语来理解和交流问题领域。

取款 银行客户将储蓄卡插入自助银行系统，系统提示用户输入密码。用户输入正确的密码，系统验证成功后，提示用户选择业务类型，用户选择“取款” 。系统提示用户输入取款金额，用户输入取款金额后，系统变更用户账户金额，然后给用户输出相应的钱。用户如果选择“打印凭条”，系统会为用户打印出凭证单。用户选择“退卡”，系统退出用户的银行卡。

取款：

下面的空白是老版本的属性，现在操作的话不要求；

== 泛化==[Generalization]，一般元素和特殊元素的关系。 关联[Association]，两个类之间存在着某种语义上的联系。

预建模是系统分析时候做的。由系统分析人员制作。 数据模型是在设计的时候做的。

系统需求分析的目的是把视角从业务组织转向新系统，站在最终用户及其它干系人的角度看问题。

系统用例是对（新）系统为系统执行者提供的价值的建模。

系统边界，即系统包含的功能与不包含的功能之间的界限。

通俗来说就是分割出系统内和系统外。

执行者[actor]是在系统之外，透过系统边界，与系统进行有意义交互的任何事物。

识别执行者的方法(思考+头脑风暴)

再谈用例（注意：这里是指系统用例，关注点由业务组织转向系统）

Ø系统用例是系统执行的一系列动作，这些动作可以生成“执行者”可观测的有价值的结果。 Ø通俗讲：系统用例是执行者通过系统可以达到的某个目标。

必须从执行者角度考虑:

识别用例的方法(思考+头脑风暴)

• 用例之间的关系：

思想：从现有的用例中抽取出公共的那部分信息，作为一个单独的用例。然后通过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

包含关系：使用包含用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基用例复用。

扩展关系：将基用例中一段相对独立并且可选的动作，用扩展用例加以封装，再让它从基用例中声明的扩展点上进行扩展，从而使基用例行为更简练和目标更集中。

泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。

• 执行者比用例明显。 • 执行者的个数远比用例的个数少。 • 找到一个执行者，就可以找到一堆用例。 • 执行者是系统外部人物的代表，所以当然是要先找到执行者，才能够从执行者的角度去寻找用例。

时间是特殊的系统执行者

用例名称必须是动宾短语。（打电话，提交电话单）

采用域建模中的名词术语。（统一术语）

慎用弱动词弱名词——会掩盖真正的业务。（语义不明确）

• 弱动词：进行、使用、复制、加载、生成…… • 弱名词：数据、报表、表格、表单、系统……

用例是执行者对系统的一个愿望。

完成这个愿望可能需要经过很多步骤，但任何步骤不能够完整的反映执行者的目标。

系统用例里出现了非价值用例，目的是重用。 下面与右面都对，但是建议右面那个。

所有用例应该都能追溯到愿景目标。（满足当时期望） 所有的愿景目标都应有对应的用例实现。

当存在大量用例时可以对用例进行分包

列席参与人主要是技术人员，一般不可以发言。

召集参加评审会的所有成员开一个简短的会议，讨论、 明确要评审的内容、评审的要点、评审时所需的资料、缺陷检查表

评审人员提前阅读和准备，才能提出有价值的建议

暴露问题、讨论问题，待审查文档应该符合：

评审中发现的错误必须得到重视和回应。

• 正确性； • 必要性； • 优先级； • 明确性； • 可测性； • 完整性； • 一致性； • 可修改性