简介 除用例之外，还有其他一些重要的UP需求制品，本章将介绍这些制品，这些内容与案例研究关系密切，并且提供了更为完整的需求示例。
其他需求制品 用例不是要求的全部。
》补充性规格说明 捕获并确定了其他类型的需求，例如报表、文档、包装、可支持性说明、许可授权等
》词汇表 捕获术语和定义，它也可起到数据字典的作用
》设想 概括了对项目的“设想”，即执行摘要。该制品为 项目主要思想提供简洁描述
》业务规则（或领域规则）捕获了凌驾于特定应用之上的长期规则或政策，例如税法
这些示例的详尽程度 本书首要目标是介绍OOA/D基础知识，而不是本章所论述的次要POS需求细节。因此本章只展示部分示例，并不展示完整详尽的需求示例。
某些小节将作为承上启下的过渡小节，突出重点问题，提供对内容的感性认识，然后就会快速进入下面的内容。
准则：初始阶段是否应该对此彻底地进行分析 非也。UP是一种迭代和进化式方法，这意味着应该早在完整地分析和记录大多数需求之前，尽早进行具有产品品质的编程和测试。来自早期编程和测试的反馈使需求进化。
研究表明，在开始阶段，高阶粗粒度需求的“前十”列表是有帮助的。同样，在早期花费一定时间去理解非功能性需求（例如性能或可靠性）也是有帮助的，因为这对架构选择具有重要影响。
可靠性规格说明：是否矛盾？ 接下来所编写的需求示例可能会造成以下错觉：既然理解并良好定义了真实的需求，那么也可以用它来对项目进行可靠的预算和计划。这种错觉对非软件开发者来说尤其强烈，程序员会从其惨痛教训中认识到这种计划和预算是多么不可靠。
真正重要的是快速构建可以通过用户验收测试的软件，而且能够满足用户真实的目标，但在用户对软件进行评估或使用之前，无法确定这些目标。
编写设想和补充性规格说明是值得重视的，但是这些制品（或者任何需求）也并不是完全可靠的规格说明。只有编写代码、测试、获取反馈、进一步完成与用户和客户的协作并且对软件进行改写，才会真正达到目标。
这并不是要号召无序分析和思考就匆忙地去编码，而是建议轻度地处理需求，尽快开始编程，并且不断引入用户和测试以得到反馈。
准则：这些制品是否应该放在项目Web站点上 与普通的静态文档 不同，这些制品应该是超链接的，或者使用不用于字处理器或电子表格的其他工具进行记录。例如，其中大多数可以记录在WiKi Web上。
NextGen示例：（部分）补充性规格说明 P78
注解：补充性规格说明 补充性规格说明（supplementary specification）捕获了用例和词汇表难以描述的其他需求、信息和约束，其中包括系统范围的"URPS+"（可用性、可靠性、性能、可支持性和其他）等质量属性或需求。 在思考用例的时候，某用例专有的非功能性需求可以首先简要地写入用例，即用例的“特殊需求”小节。但是，在这种非正式描述后，应该将其归入补充性规格说明，以便所有非功能性需求集中在一处，避免重复。
补充性规格说明中的元素包括：
》“FURPS+”需求--功能性、可用性、可靠性、性能和可支持性
》报表
》硬件和软件约束（操作系统和网络系统等）
》开发约束（例如，过程或开发工具）
》其他设计和实现约束
》国际化问题（货币单位、语言）
》文档化（用户、安装和管理手册）和帮助
》许可和其他法律问题
》包装
》标准（技术、安全和质量）
》物理环境问题（例如，热度或振动）
》操作问题（例如，如何处理错误，或者每隔多久进行备份）
》特定应用领域规则
》所关注领域的信息（例如，信用卡支付处理的整个过程）
质量属性 有些需求可以称为系统的质量属性（quality attribute，或qualities attribute），包括可用性、可靠性等等。需要注意的是，这些指的是系统的质量，而非属性本身的质量，属性本身并没有高质量之说。
当我们带上“架构师的帽子”时，系统范围的质量属性（记录于补充性规则说明中）将特别重要，因为架构分析和设计极为关心在功能性需求语境下质量属性的确定和选择，第33章将对此进行介绍。
补充性规格说明中有功能性吗？难道不应该在用例中吗？ 某些功能或特性并不适合采用用例的形式描述，可以采用特性的方式来描述功能性。
UP当然也允许使用这种面向特性的方法来描述需求，在这种情形下，应在补充性规格说明中描述特性列表。
UP提倡但不是强求对功能性使用用例。用例是一种优秀的方法，可以通过产品使用的典型场景把一组相关特性集中起来思考。但是用例并不是永远适用。
应用专用的领域（业务）规则 一般来说，诸如税法等广泛应用的领域规则属于UP业务规则制品，UP将其作为核心的共享知识库。但是，对于更为局限的特定于应用的规则，例如如何计算某项商品折扣，可以记录在补充性规格说明中。
所关注领域的信息 这对于主题问题专家是具有价值的，他们可以编写（或提供URI）一些与新软件系统有关的领域解释（销售和账务，地下油/水/气流量的地球物理学知识），以便为开发小组提供背景信息和更为深入的理解力
NextGen示例：（部分）设想 P82
注解：设想 编写执行摘要对项目运行进行简要的描述，使主要成员建立起对项目的共同设想，也是同样有帮助的。 设想不应该占据很长的篇幅，也不应该试图详细描述公司的需求。设想应该概括用例模型和补充性规格说明中的一些信息。
涉众的关键高阶目标及问题 该小节总结高阶（通常高于特定用例）目标和问题，并且揭示了重要的非功能和质量目标，这些目标可能属于某个用例或跨越多个用例。
准则：有哪些简化的方法？ 特别是在输入定义高阶问题和确定目标的活动过程中，会发生创造性、研究性的小组工作。对于发现根源问题及目标、启发思路和定义优先级，存在一些有助于小组工作的技术：
》思维导图（mind mapping）
》产品设想包装制作（product vision box creation）
》鱼骨图（fishbone diagram）
》排列图(pareto diagram)
》集体讨论（brainstorming）
》多次投票表决（multi-voting）
》记点投票表决（dot voting）
》提名小组过程（nominal group process）
》集体编写（brainwritting）
》相关性分组（affinity grouping）
可以在Web上找到这些方法的具体介绍。推荐在同一讨论会上采用其中几种方法，以便从不同角度发现共同的问题和需求。
系统特性概要 为掌握主要特性而在设想文档中只列出用例名称是不够的，原因如下：
1、太详细或层次太低。人们想要的是主要思想的概要
2、用例名称可能掩盖了涉众真正关心的主要特性
3、有些值得注意的特性跨越了多个用例或者与用例无关
因此，使用特性作为替代的、补充性的方式来表示系统的功能，在这种语境下，更准确地说法是系统特性，即以高阶、简洁的语句对系统功能加以概括。更为正式地，在UP中，系统特性是“由系统提供的外部可观察到的服务，可以直接实现涉众的需求”
定义：特性是系统能够实行的行为上的功能。特性应该通过如下语言上的测试：系统实行<特性X>
将功能上的系统特性与各种非功能性需求和约束进行对比，例如“系统必须运行于Linux”，显然不能通过上述语言上的测试。例如，系统实现Linux。
准则：如何编写功能列表 通常可以使用两级层次结构来组织系统特性。但是，如果设想文档的层次多于两级，则显得过于详细。设想文档的系统特性应该对功能性进行概括，非不应分解为细粒度元素的冗长列表。
准则：在设想文档中包含的特性最好少于10个，因为更多的特性不能够被快速掌握。如果存在更多的特性，则需考虑对这些特性进行分组和概括。
准则：我们是否应该在设想文档中重复其他需求？ 准则：对于其他需求，要避免在设想和补充性规格说明（SS）中重复或近于重复。最好只在SS中记录这些需求。在设想文档中，可以指引读者到SS中阅读这些需求
准则：你应该先编写设想还是用例？ 不需要严格定义这种先后顺序。在开发者合作创建不同需求制品时，对一个制品的创建工作会影响并有利于澄清另一个制品。尽管如此，还是建议采用如下的顺序：
1、首先编写简要的设想草案
2、确定用户目标和对应的用例名称
3、详细编写一些用例，并且开始编写补充性规格说明
4、精化设想，对以上制品中的信息进行概括。
NextGen示例:（部分）词汇表 P87
注解：词汇表（数据字典） 词汇表（glossary）的最简形式是重要术语及其定义的列表。令人惊讶的一种常见情况是，不同涉众可以用略有不同的方式使用同一（通常是技术的或特定于领域的）术语。这一问题必须解决，以减少沟通上的问题和需求的二义性。 准则：及早开始编写词汇表。词汇表将很快成为关于细粒度元素细节信息的有效知识库。
词汇表作为数据字典 在UP中，词汇表也充当数据字典（data dictionary）的角色，即记录关于数据之数据，也就是元数据（metadata）的文档。在初始阶段，词汇表应该是术语及其描述的简单文档。在细化阶段，词汇表可以扩展为数据字典。
术语的属性包括：
》别名
》描述
》格式（类型、长度、单位）
》与其他元素的关系
》值域
》验证规则
注意，词汇表中的值域和验证规则是反映系统行为的需求的组成部分。
准则：我们是否可以在词汇表中记录组合术语 词汇表不仅用于记录原子术语，例如“产品价格”，它也能够并且也应该包括诸如“销售”（其中包含其他元素，例如日期和地点）的组合元素和用来描述用例参与者之间所传递的一组数据的简化名称。例如，在处理销售用例中，考虑如下陈述： 系统向外部支付授权服务发送支付授权请求，并请求批准支付。 “支付授权请求”是一组数据的别名，也需要在词汇表中加以解释。
NextGen示例：业务规则（领域规则） P88
注解：领域规则 领域规则指出领域或业务是如何运作的。尽管应用需求通常都会受到领域规则的影响，但是这些规则不是任何一个应用的需求。公司政策、物理法则（例如油在地上如何流动）和政府法律都是常见的领域规则。
领域规则通常称为业务规则（business rule），这也是其最常见的类型，但是这一术语并不是恰当的，因为大量软件应用不是面向业务问题的。
最好在单独的与应用无关的制品中确定和记录领域规则，这在UP中称为业务规则制品，这样便能够使分析在组织和项目范围内进行共享和重用，而不是只限定于特定项目的文档里。
规则强调了情节的连续性而不是细节，有助于澄清用例中的歧义。例如，在NextGen POS中，如果有人问事否应该在处理销售用例中加入另一路径，即不允许不记录签名的信用卡支付，业务规则给出了答案，其表明任何信用卡授权公司都不允许这种情况。
过程：迭代方法中的进化式需求 PPT6概括了制品示例及其在UP中的时限。通常，大多数需求制品始于初始阶段，并且主要在细化阶段开发。
初始阶段 涉众要决定项目是否值得深入调查。实质的调查活动在细化阶段发生，而不是初始阶段发生。在初始阶段，设想以某种形式概括了项目思想，以帮助决策者决定是否值得继续，并且从哪里着手。
因为大多数需求分析发生在细化阶段，所以在初始阶段应该只对补充性规格说明稍作开发，只需要突出重要的质量属性用以揭示主要风险和挑战。这些制品的输入可以在初始阶段的需求讨论会上产生。
细化阶段 通过细化阶段，基于对部分系统增量构建的反馈、调整以及在若干开发迭代中举行的多个需求讨论会，对“远景”和设想文档加以精化。通过进一步的需求调查和迭代开发，其他需求将更为清晰并且可以记录在补充性规格说明中。
在细化阶段结束时，完成并提交用例、补充性规格说明和设想是切实可行的，因为在此时，这些文档能够合理地反映稳定的主要特性和其他需求。尽管如此，补充性规格说明和设想不等同于冻结并“签署”了的规格说明；改写--并非僵化--是迭代开发和UP的核心价值。
所谓的“冻结签署”是在细化阶段结束时，就项目剩余时间里所要完成的事项与涉众达成一致意见，并且就需求和进度给予承诺（可能是以合同形式），这是完全切合实际的。在某一时刻（在UP中是细化阶段的结束时刻），我们需要对“什么、多少、何时”有可靠的认识。从这种意义上说，签署关于需求的合约时正常的，也是有必要的。同时还需要具备变更控制过程（UP中明确的最佳实践之一），以便正式地考虑和批准需求变更，避免混乱和不受控的变更。
“冻结签署”的事实还意味着如下几点：
》 在迭代开发和UP中，无论在需求规格说明上付出多少努力，还是不可避免地会存在一些变更，这应该可以被接受。这些变更可能是能够为所有者带来竞争优势的、新近发生的对系统投机性的改进，或者是由于加深了认识而引起的改进。
》 使涉众来进行评估、提供反馈以及掌握项目的方向以满足其真实意图，这是迭代开发的核心价值。“洗手不干”，不关注于参与项目，而是在一组冻结的需求上签字认可后就等待着项目结束，这样对涉众来说并没有好处，因为他们几乎不会得到真正满足其需要的结果。
构造阶段 通过构造阶段，主要需求（包括功能性需求和其他需求）应该已经稳定下来，虽然还不是终结，但是已经可以专注于次要的微扰事物了。因此，在此阶段，补充性规格说明和设想都不必进行大量改动。