第7章 其他需求

除用例之外，还有其他一些重要的UP需求制品，本章主要介绍这些次要的需求主体而不是OOA/D。

其他需求制品

• 用例不是要求的全部
• 补充性规格说明捕获并确定了其他类型的需求，例如报表、文档、包装、可支持性说明、许可授权等等。
• 词汇表捕获术语和定义，也起到数据字典的作用。
• 设想概括了对项目的“设想”，即执行摘要。该制品为项目主要思想提供简介描述。
• 业务规则捕获了凌驾于特定应用之上的长期规则或政策，例如税法。

准则

1. 初始阶段是否应该对此彻底地进行分析。
   答：否，UP是一种迭代和进化式方法，这意味着应该早在完整地分析和记录大多数需求之前，尽早尽心具有产品品质的变成和测试。来自早期变成和测试的反馈使需求进化。但是在开始阶段花费一定时间去理解非功能性需求（例如性能或者可靠性）也是有帮助的，因为这对架构选择具有重要影响。
2. 这些制品是否应该放在项目web站点上。

补充性规格说明

示例

修订历史

简介

本文档记录了销售系统所有未在用例中描述的需求。

功能性

（通常跨越多个用例的功能性）
1.日志和错误处理
在持久性存储中记录所有错误。
2.可拔插规则
……

可用性

人性因素
顾客可以看到大屏幕显示器的显示，所以：

• 应该在1米外轻松看到文本
• 避免使用色盲人群难以辨认的颜色

快捷的交易处理很重要，因为购买者希望快速离开。
收银员的视线通常提供留在顾客或商品上，因此提示和警告可以通过声音而不仅仅是图像。

可靠性

1.可恢复性：系统出现错误，需要采用某个方案解决，对此需要更深入的分析。
2.性能：目标是90%的情况下能在1分钟内完成支付授权。

可支持性

1.可适应性：不同的客户在处理销售时可能有特别的规则和需求；
2.可配置性：不同的客户对销售系统有不同的配置需求，对此需要进一步分析；

实现约束

领导坚持采用JAVA

购买构件

计算器、扫描枪等

免费开源构件

建议采用以下免费的开源构件：……

接口

1.硬件接口：

• 触摸屏
• 扫描仪
• 票据打印机
• 信用卡读卡器
• ……

2.软件接口
不同的接口接入不同的软件系统

应用的领域（业务）规则

法律问题

使用的构件其许可问题、税务规则问题，这些规则可能会频繁变更。

所关注领域内的信息

1.产品的定价：……
2.信用卡和借记卡的支付处理：……
3.销售税：……
……

注解

• 补充性规格说明捕获了用例或词汇表难以描述的其他需求、信息和约束，其中包括系统范围的“URPS+”（可用性、可靠性、性能、可支持性和其他）等质量属性或需求。
• 某些用例的非功能性需求首先写入用例的“特殊需求”小节，同时需要写入补充性规格说明，以便将所有非功能性需求集中一处。
• 补充性规格说明中的元素包括：
  
  • “FURPS+”需求——功能性、可用性、可靠性、性能和可支持性：UP提倡但不是强求对功能性使用用例，有些功能性用例比较适合在补充性规格说明中描述；
  • 报表；
  • 硬件和软件约束（操作系统和网络系统等）；
  • 开发约束（过程或开发工具）；
  • 其他设计和实现约束
  • 国际化问题（货币单位、语言）；
  • 文档化（用户、安装和管理手册等）和帮助；
  • 许可和其他法律问题；
  • 包装；
  • 标准（技术、安全和质量）；
  • 物理环境问题；
  • 操作问题（如何处理错误或多久进行备份）；
  • 特定应用领域规则：比如税法、如何计算某商品折扣；
  • 所关注领域的信息（例如信用卡支付的过程）：一些重要文献、公式、定理等资料的引用；

设想

示例

修订历史

同补充性规格说明

简介

设想是下一代销售系统，并且能实现更加灵活的业务规则，支持第三方系统整合。

定位

1.商业机遇
2.问题综述：传统系统的缺点。

涉众描述

某些目标及其目前没能解决的问题，分类写到这里，例如涉众目标、用户级目标、用户环境等。

产品概览

1.产品展望；
2.优点描述；
3.假设和依赖；
4.成本和定价；
……

系统特性概要

系统可以实行<特性X>

其他需求和约束

注解

• 设想应该概括用例模型和补充性规格说明中的一些信息；
• 对于一些需求，要避免在设想和补充性规格说明中重复，最好是在补充性规格说明中记录这些需求，然后在设想文档中指引读者去补充性规格说明中去阅读这些需求。

词汇表

示例

修订历史

同补充性规格说明

定义

注解

• 不同涉众可以用略有不同的方式使用同一术语，这个问题必须解决，以减少沟通上的问题和需求的二义性；
• 及早开始编写词汇表；
• 词汇表也充当数据字典的角色，即记录关于数据的数据；
• 术语的属性包括：别名、描述、格式（类型、长度、单位）、与其他元素的关系、值域、验证规则
• 组合术语：例如支付授权请求是一组数据的别名，需要在词汇表中加以解释；

业务规则

示例

修订历史

同上

规则列表

注解

• 规则有助于澄清用例中的歧义，例如允许不签名的信用卡支付服务，规则中会给出答案，不允许这样的情况。

过程：迭代方法中的进化式需求

• 初始阶段决定是否要深入调查，对补充性规格说明稍作开发。