1.初始阶段

主要解决的问题：

涉众是否就项目设想基本达成一致，项目是否值得继续进行认真研究。

持续时间：

很短，如果项目必须开发的话，那么基本很短。

要做的工作：

1.对10%～20%的用例。（高风险和优先级的用例）

产品：

1.用例模型。

包括大部分的参与者，目标和用例名称。

以摘要形式编写的用例，10～20%详细编写的用例。

确定大多数具有影响和风险的质量需求。

2.补充规格说明书。

3.设想说明书。

4.风险列表。

5.界面原型。

6.对候选的高层架构给出建议。

7.候选工具列表。

需求管理：

一种系统的方法来寻找，记录，组织和跟踪系统不断变更的需求。

   

用例

2008年11月28日

14:37

   

应用于需求的发现和记录工作中。

用例强调了用户的目标和观点。

参与者：具有行为的事物。

1.主要参与者，具有用户目标，并通过系统的服务实现。 ！用户目标驱动用例。

2.协助参与者，为系统提供服务。！明确外部接口和协议。

3.幕后参与者，在用例行为中具有影响和利益。

场景：参与者和系统之间的一系列特定的活动和交互。

   

用例：一组用例的实例，其中每个实例都是系统执行的一系列活动，这些活动产生了对某个参与者而言，可观察的返回值。

用例是文本文档，而非图形，用例建模主要是编写文本的活动。

用例的组成部分。

• 范围
• 级别。
  • 用户用例。业务用例。
  • 子系统。
• 主要参与人员。涉众及其关注点列表。
  • 用例包含：所以涉众及其关注点。
• 前置，后置条件。
  • 前置条件：被假设已经成立，并且用例中不会去检查。作用是，需要引起注意的假设（必须的先决条件）。
  • 后置条件：用例成功结束后，必须为真的内容。也就是涉众的需求。
• 基本流程。
  • 采用相同语法描述的，描述了满足涉众关注点的基本成功路径。
    • 准则：将所有条件，分支写到扩展部分。
• 扩展部分。
  • 描述了其他场景和分支。成功与失败。
  • 准则：描述条件时，要使用系统能够检测到的条件。
    • 如：没有收到空间服务的响应。
    • 不好的如：空间服务崩溃了。
• 用例书写准则
  • 以无用户界面约束的本质风格编写用例，并集中于参与者的意图。
  • 编写简洁的用例。
  • 编写黑盒用例。使用黑盒用例定义系统职责。
  • 采用参与者和参与者目标的视点。
    • 要关注参与者的目标。而不是去关注用例本身，做有价值的事。
    • 关注参与者需要的有价值的返回结果。
  • 使用动词开头。
  • 为每个目标定义一个用例，除了CUID，统一为管理。
  • 有些关注问题最好是作为非功能性需求在补充规格说明中描述，如用户要求显示作品列表，这样的问题属于可用性需求。
• 用例驱动开发！

     

     

     

   

补充性规格说明书

2008年12月2日

14:57

1.包括系统范围的 Urps+ ，可用性，可靠性，性能，可支持性，其他。

   

设想

2008年12月2日

15:10

   

一般顺序如下：

1.编写简要的设想草案。

2.确定用户目标和对应的用例名称。

3.详细编写一些用例，并且开始编写补充性规格说明。

4.精化设想，对以上制品中的信息进行概括。