最近开始学习UML,在<UML与模式应用>中看到有关于其他需求的部分,觉得这点还是比较容易被忽略的.在这里, 提出来和大家共享,呵呵...Ready？GO！
    第七章—其他需求
     除了用例之外，还有一些其他的重要的UP需求制品，这里谈到的是一些次要的需求主题而不是OOA/D。这些内容与案例研究的关系密切，能提供更为完整的需求。

     其他需求制品包括：
                                        补充性规格说明
                                         词汇表
                                         设想
                                          业务规则

    下面介绍一些一些次要需求方面的内容：
     1）准则：初始阶段是否应该对此彻底地进行分析
                        非也。UP是一种迭代和进化式开发，这意味着应该早在完整地分析和记录大多数需求之前，迟早进行具有产品品质的编程和测试。但是，研究表明，在开始阶段，高阶粗粒度需求的“前十”列表是有帮助的。

           可靠性规则说明：是否矛盾？
           真正重要的是快速构建可以通过用户验收测试的软件，而且能够满足用户真实的目标，但在用户对软件进行评估式使用之前，无法确定这些目标。编写设想和补充性规格说明是值得重视的，这可以用于澄清什么是客户真正所要的，产品的动机是什么，并且可以作为重要思想的知识库。但是这些制品也江不是完全可靠的规格说明。只有编写代码、测试、获取反馈、进一步完成与用户和客户的协作并且对软件进行改写，才会真正达到目标。
         下面，来了解一下补充性规格说明吧。。。

         补充性规格说明：捕获了用例或词汇表难以描述的其他需求、信息和约束，其中包括系统范围的“URPS+”（可靠性、可用性、性能、可支持性和其他）等质量属性或需求。
补充性规格说明包括：
                                      “FURPS+”需求—功能性、可用性、可靠性、性能和可支持性
                                           报表
                                           硬件和软件约束
                                           开发约束
                                           其他设计和实现约束
                                           国际化问题
                                           文档化
                                           许可和其他法律问题
                                           包装
                                           标准
                                           物理环境问题
                                           操作问题
                                           特定应用领域规则
                                           所关注领域的信息
其中可用性、可靠性等等属于质量属性。

下面来谈谈什么是设想
系统设想：
主要是用来描述系统特性概要的，但是为了主要特性而在设想文档中只列出用例名称是不够的。
原因是：
1）太详细或层次过低。人们想要的是主要思想的概要。而用例可能会有30~50个之多
2）用例名称可能掩盖了涉众真正关心的主要特性。
3）有些值得注意的特性跨越了多个用例或者与用例无关。
因此，使用特性作为替代的、补充性的方式来表示系统功能，在这种语境下，更准确地说是系统特性，即以高阶、简洁的语句对系统功能加以概括。
在设想文档中包含的特性最好少于10个，因为更多的特性不能够被快速掌握。如果存在更多的特性，则需考虑对这些特性进行分组和概括。

下面来讨论一个问题：你应该先编写设想还是用例？
不需要严格定义这种先后顺序。在开发者合作创建不同需求制品时，对一个制品的创建工作会影响并有利澄清另一个制品。建议采用如下的顺序：
                                                      1）首先编写简要的设想草案
                                                       2）确定用户目标和对应的用例名称
                                                       3）详细编写一些用例，并且开始编写补充性规格说明
                                                       4）精化设想，对以上制品中的信息进行概括

词汇表：词汇表的最简形式是重要术语及其定义的列表。
准则—及早开始编写词汇表。词汇表将很快成为关于细粒度元素细节信息的有效知识库

领域规则：通常称为业务规则，这也是其最常见的类型。规则强调了情节的连续性而不是细节，有助于澄清用例中的歧意。

下面来讨论一下迭代方法中的进化式需求
初始阶段：涉众要决定项目是否值得深入调查。在初始阶段，设想民某种形式概括了项目思想，以帮助决策者决定是否值得继续，并且从哪里着手。在初始阶段应该只对补充性规格说明稍做开发，只需要突出重要的质量属性用以提示主要风险和挑战。
细化阶段：基于对部分系统增量构建的反馈，调整以及在若干开发迭代举行的多个需求讨论会，对“远景”和设想文档加以精化。通过进一步的需求调查和迭代开发，其他需求将更为清晰并且可以记录在补充性规格说明中。
构造阶段：通过构造阶段，主要需求应该已经稳定下来，虽然还不能终结，但是已经可以专注于将要的微扰事物了。在该阶段，补充性规格说明和设想都不必进行大量改动。

以上是有关于UP开发中的一些其他需求，不知道对大家有没有帮助，呵呵。。。