其他需求

除了用例织袜，还有其他一些重要的UP需求制品。

• 补充性规格说明：捕获并确定了其他类型的需求。
• 词汇表：捕获术语和定义，它也可起到数据字典的作用。
• 设想：概括了对项目的“设想”，即执行摘要。该制品为项目主要思想提供简洁描述。
• 业务规则：捕获了凌驾于特定应用之上的长期规则或政策。

如何完成这些示例

本书首要目标是介绍OOA/D基础知识，因此本章只展示部分示例，并不展示完整详尽的需求示例。

准则：初始阶段示范应该对此彻底地进行

非也。UP是一种地带和进化式方法，这意味着应该早在完整地分析和记录大多数需求之前，今早进行具有产品品质的编程和测试。来自早期编程和测试的反馈使需求进化。

但是，研究表明，在初始阶段，高阶粗粒度需求的“前十”列表使有帮助的。同样，在早期花费一定时间去理解非功能性需求也是由帮助的，因为这对价格选择具有重要影响。

可靠性规格说明：是否矛盾？

接下来所编写的需求示例可能会造成以下错觉：既然理解并良好定义了真实的需求，那么也可以用它来对项目进行可靠的预算和计划。早期详细需求对软件项目由帮助或可靠使错误认识。

真正重要的使快速构件可以通过用户验收测试的软件，而且能够满足用户真实的目标，但在用户对软件新型评估或使用之前，无法确定这些目标。

编写设想和补充行规格说明使值得重视的，这可以用于澄清什么使客户真正所要的，产品的冬季时什么，并且可以作为重要思想的知识库。但是这些制品也并不是完全可靠的规格说明。只有编写代码、测试、获取反馈、进一步完成于用户和客户的协作并且对软件进行改写，才会真正达到目标。

这并不是要号召无需分析和思考就聪明地区编码，二十建议轻度地处理需求，尽快开始编程，并且不断引入用户和测试以得到反馈。

准则：这些制品示范应该放在项目Web站点上

当然。这些数字制品通常应该只在线冀鲁豫项目的Web站点上。

NextGen示例：（部分）补充性规格说明

修订历史

简介

本文档记录了NextGen POS所有未在用例中描述的需求。

功能性

（通常跨越多个用例的功能性。）

1. 日志和错误处理： 在持久性存储中记录所有错误。
2. 可拔插规则：在几个用例（见定义）的不同场景点执行任意一组规则，以支持对系统功能的定制。
3. 安全性：任何使用都需要经过用户认证。

可用性

人性因素

顾客将能够看到POS大屏幕显示器的显示。因此：

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

快捷、无措的销售交易处理极为重要，因为购买者希望快速离开。否则会给它们的购买体验（和对销售员的评价）带来负面影响。

收银员的视线通常停留在顾客或商品。而不是计算机显示器上。因此，提示和告警应通过声音传递，而不仅仅是通过图像传递。

可靠性

1. 可恢复性:如果在使用外部服务（支付收钱啊、账务系统、...）时出现错误，为了完成销售交易，需要尝试采用本地方案（如果存储和转发）加以解决。对此需要更深入的分析...
2. 性能:正如“人性因素”一节中所提及的。购买者希望非常快速地完成销售处理过程。外部的支付授权时瓶颈之一。我们的目标时，90%的情况下，能够在之分钟之内完成授权。

可支持性

1. 可适应性：NextGen POS的不同客户在处理销售时尤其特有的业务规则和处理需求。因此，在场景中的几个预订指出（例如，当开始新的销售交易时，当增加新的商品时），需要能够启用可拔插的业务规则。
2. 可以配置性：不同的客户对其POS系统由不同的网络配置需求。例如，采用胖客户端或瘦客户端。两层或多层物理结构等等。除此之外，它们还要求具备修改配置的能力，一边适应其变更业务和性能的需求。因此，系统应该具备一定的可配置能力以适应这些需求。对此需要进一步分析，以发现哪些地方需要灵活性和灵活性的程度，以及实现这种灵活性所需的工作。

实现约束

NextGen 的领导层坚持采用Java技术的解决方案。他们任务采用Java技术除了易于开发外，还能够提高远期的一直和可支持行能力。

购买构件

• 税金计算器。必须支持用于不同国家的可拔插计算器。

免费开源构件

一般而言。我们建议在该项目中尽可能地使用免费的Java技术开源构件。

尽管协作对确定最终的设计和选择构件来说为时尚早，但是我们建议采用以下构件：

• JLog日志框架
• ...

接口

1. 重要硬件和接口
2. 触摸屏（操作系统将此视为普通监视器，且出门动作也视为书目标事件）。
3. 条形码激光扫描仪（通常附加在一种特殊键盘上。扫输入在软件中视为键盘输入）。
4. 票据打印机。
5. 信用卡/借记卡读卡器。
6. 签名读取装置（不含在版本1中）。
7. 软件接口：由于存在众多外部协作系统（税金计算器、账务、库存、...）。我们需要采用不同的接口，接入不同的系统。

应用的领域（业务）规则

（一般性规则参见单独的业务规则文档。）

法律问题

我们建议使用一些开源构件，但是要解决其许可限制的问题，一边使包含开源软件的产品能够转售。

法律规定，在销售交易中必须遵从所有税务规则。同时要注意的是，这些规则可以频繁变更。

所关注领域内的信息

1. 定价：

除了在“应用的领域规则”小节中的定价规则之外，还需要注意，产品有原始价格和可选的常设低标价之分。产品标示的价格（折扣前）是常设低标价。。由于账务和税务的源于，即使有常设地标价。也需要维护原始价格。

1. 信用卡和借记卡支付处理

当支付授权批准了信用卡或借记卡支付后。将由支付授权服务而不是买方来复杂对卖方的支付。因此，对于每笔支付。卖方都需要将授权服务的未付金额记录于其应收账户下。通常，授权服务在每晚执行电子转账操作。将卖方当天的应收总额转入其账户下。同时对每笔交易扣除（少量的）服务费。

1. 销售税

销售税的计算可能会十分复杂，并且会根据各级政府的立法而定期变更。因此，对税金计算采用第三方软件（存在许多可选的第三方软件）是明智之举。税金可能分别归属于城市、地区、省和国家。某些商品可能是无条件免税的。或者是根据买方或目标承受着（例如，承认或儿童）进行免税。

1. 商品表示： UPC、EAN、SKU、条形码和条形码读取装置

NextGen POS 要支持各种商品标识方案。对于出售的产品而言。UPC（通用产品代码）、EAN（欧洲物品编码）和SKU（库存单位）是三种常见的商品销售标识系统。JAN（日本物品编码）类似于EAN。

SKU 是由零售商定义地完全专用的标识。

无论如何，UPC和EAM具有标准和受规章限制的构件。参见www.adams1.com/pub/russadam/upccode.html或者 www.uc-council.org和www.ean-int.org获得详细信息。

注解：补充性规格说明

补充性规格说明捕获了用例或词汇表难以描述的其他需求、信息和约束，其中包括系统范围的“URPS+”等质量属性或需求。

需要注意的是，在思考用例的时候，某用例专有的非功能性需求可以首先简要地写入用例，即用例的“特殊需求”小节。但是，在这种非正式描述后，应该将其归入补充性规格说明，一边所有非功能性需求集中在一处，避免重复。

补充性规格说明中的元素包括：

• “FURPS+”需求
• 报表
• 硬件和软件约束
• 开发约束
• 其他设计和实现约束。
• 国际化问题
• 文档化和蚌湖。
• 许可和其他法律问题。
• 包装。
• 标准
• 物理环境问题。
• 操作问题。
• 特定应用领域规则。
• 所关注领域的信息。

质量属性

有些需求可以称为质量属性，这些指的是系统的质量，而非属性本身的质量，属性本身并没有高质量之说。

当我们带上“架构师的帽子”时，系统范围的质量属性将特别重要，业务架构分析和设计极为关心在功能性需求语境下质量属性的确定和选择。

补充性规格说明中由功能性吗？难道不应该在用例中吗？

某些功能或特性并不事和采用用例的形式描述。UP也允许使用面向特性的方法来描述需求，在这种情形下，应在补充性规格说明中描述特性列表。

应用专用的领域规则

一般来说，广泛应用的领域规则属于UP业务规则制品，UP将其作为核心的共享知识库。但是，对于更为局限的特定于应用的规则，可以记录在补充性规则说明中。

所关注领域的信息

这对于主题问题专家时具有价值的，他们可以编写一些于新软件系统有关的领域解释，以便为开发小组提供背景信息和更为深入的理解里。

NextGen 示例：（部分）设想

修订历史

简介

我们设想NextGen POS 时下一代POS应用，能够容错，具有灵活性以支持各种客户的不同业务规则。具有多中断和用户接口机制，并且能够与各种第三方支付系统进行整合。

定位

1. 商业机遇

就各种业务规则和网络设计而言（例如，瘦客户端或其他：两层、三层或四层架构）。现有的POS产品无法适应客户的业务。此外，在业务和终端增长时，现有产品不能很好地阔炸。而且，这些产品无法同时以在线和离线模式工作。不能动态地根据错误进行调整。现有参评都无法方便地与大量第三方系统集成。它们都不能采用新的中断技术。例如移动PDA，以上这些不灵活的情形无法满足市场的需求，因此需要一种POS来改变这种情形。

1. 问题综述

传统的POS系统灵活性、容错性差，并且难以与第三方系统集成。这就带来诸多问题，包括无法快速完成销售流程，无法加入软件不支持的处理过程以及不能支持及时准确的账务和库存数据管理（以便统计和计划）。这些问题会影响收银员、商店经理、系统㻺和企业管理人员。

1. 产品定位综述

2. 简洁地概括系统目标用户、出众的特性和与竞争者的差异。

3. 选择和竞争...

涉众描述

1. 市场统计...
2. 涉众（非用户）概要...
3. 用户概要...
4. 涉众的关键高阶目标及问题

通过专题专家和其他涉众参见的为期一天的需求讨论会，和对一些零售店的调查，得出以下关键目标和问题。

1. 用户级目标

用户（和外部系统）要求系统实现以下目标：

• 收银员：处理销售交易、处理退货、入款、出款。
• 系统管理员：管理用户、安全性和系统表。
• 经理：启动和关系
• 销售活动系统：分析销售数据

• ...

• 用户环境...

产品概览

1. 产品展望 NextGen POS系统通常安装在商店中。如果使用移动终端，则可以在商店网络临近的封闭区域内使用。包括商店内部或外部的封闭区域。系统能够与其他系统协作，为用户提供各种服务

1. 优点概述

1. 假设和依赖...
2. 成本和定价...
3. 许可和安装...

系统特性概要

• 记录销售交易。
• 支付授权（信用卡、加接口、支票）。
• 对用户、安全性、编码和约束表等进行系统管理。
• 对外部构件发生故障时，自动进行离线销售处理。
• 基于行业标准，与第三方系统进行实时交易，这些第三方系统包括库存、账务、人力资源、税金计算器和支付授权服务。
• 在处理场景中固定、公共的设定点定义和执行定制的“可拔插”业务规则。

其他需求和约束

包括设计约束、可用性、可靠性、性能、可支持行、设计约束、文档、包装等，参见补充性规格说明和用例。

注解：设想

当某个人加入项目团队时，对他说“欢迎！青岛项目网站上去阅读7页的设想文档。”，这种做法时有效的。编写执行摘要对项目进行简要的描述，使主要成员建立起对项目的共同设想，也是同样有帮助的。

设想不应该占据很长篇幅，也不应该试图详细描述公司需求。设想应该概括用例模型和补充性规格说明中的一些信息。

涉众的关键高阶目标及问题

改小节总结高阶（通常高于特定用例）目标和问题，并且揭示了重要的非功能和质量目标，这些飙可能属于某个用例或跨越多个用例。

有哪些简化的方法？

特别使在诸如定义高阶问题和确定目标的活动过程中，会发生创造性、研究型的小组工作。对于发现根源问题及目标、启发思路和定义优先级，存在一些有助于小组工作的技术：

• 思维导图
• 产品设想包装制作
• 鱼骨图
• 排列图
• 集体讨论
• 多次投票表决
• 记点投票表决
• 提名小组过程
• 集体编写
• 相关性分析

系统特性概要

违章网主要特性而在设想文档中只列出用例名称使不够的：

• 太详细或层次过低。人们想要的使主要思想的概要。
• 用例名称可能掩盖了涉众真正关系的主要特性。
• 有些值得注意的特性跨越了多个用例或与用例无关。

因此，使用特性作为替代的、补充性的方式来标识系统功能，在这种语境下，更准确地说法使系统特性，即以高阶、简洁的语句对系统功能加以概括。在UP中，系统特性是：由系统提供的外部可观察到的服务，可以直接实现涉众额需求。

特性是系统能够实行的行为是的功能。特性应该通过如下语言上的测试：系统实行XXX

准则：如何编写功能列表

最好使设想文档保持简洁。

通常可以使用两级曾是结构来组织系统特性。但是，如果设想文档层次多余两级，则显得过于详细。设想文档的系统特性应该对功能性进行概括，非不应分解为细粒度元素的融创列表。

在设想文档中包括的特性最好少于10个，因为更多个特性不能够被快速掌握。如果存在更多的特性，则需要考虑对这些特性进行分组和概括。

准则：我们是否应该在设想文档中重复其他需求

对于其他需求，要避免在设想和补充性规格说明中重复和近于重复，最好旨在SS中记录这些需求。在设想文档中，可以指引读者到SS中阅读这些需求。

准则：你应该先编写设想还是用例？

不需要严格定义这种先后顺序。在开发者合作创建不同需求制品是，对一个制品的创建巩固走会影响并有利于澄清另一个制品。尽管如此，还是建议采用如下的顺序：

1. 首先编写简要的设想草案
2. 确定用户目标和对应的用例名称
3. 详细编写一些用例，并且开始编写补充性规格说明。
4. 精化设想，对以上制品中的信息进行概括。

NextGen示例：（部分）词汇表

修订历史

定义

注解：词汇表（数据字典）

词汇表的最简形式是重要属于及其定义的列表。

及早开始编写词汇表。词汇表将很快称为关系细粒度元素细节信息的有效知识库

词汇表作为数据字典

在UP中，词汇表也充当数据字典的角色，即记录关于数据之数据，也就是元数据的文档。在初始阶段，词汇表应该是属于及其描述的简单文档。在细化阶段，词汇表可以扩展为数据字典。

术语的属性包括：

• 别名
• 描述
• 格式
• 与其他元素的关系
• 值域
• 验证规则

准则：我们是否可以在词汇表中记录组合术语

词汇表不仅用于记录原子术语，也能够并且也应该包括组合元素和用来描述用例参与者之间所传递的一组数据的简化名称。

NextGen示例：业务规则（领域规则）

修订历史

规则列表

（同时参见补充性规格说明中的特性应用规则）

注解：领域规则

领域规则指出领域或业务是如何运作的。经过需求通常都会收到领域规则的影响，但是这些规则不是任何一个应用的需求。公司政策、物理法则和政府法律都是场景的领域规则。

最好在单独的与应用无关的制品中确定和记录领域规则，这在UP中称为业务规则制品，这样便能够使分析在组织和项目范围内进行共享和宠用，而不是只限于特定项目的文档里。 规则强调了情节的连续性而不是斜街，有助于澄清用例中的歧义。

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

初始阶段

涉众要决定项目是否值得深入调查。实质的调查活动在细化阶段发生，而不是初始阶段发生。在初始阶段，设想以某种形式概括了项目思想，以帮助决策者决定是否值得继续，并且从哪里着手。

因为大多数需求分析发生在细化阶段，所以在初始阶段应该只对补充性规格说明稍作开发，只需要突出重要的质量属性用以揭示主要风险和挑战。

这些制品的输入可以在初始阶段的需求讨论会上产生。

细化阶段

通过细化阶段，基于对部分系统增量构件的返回、调整以及在若干迭代中举行的多个需求讨论会，对“远景”和设想文档加以精化。通过进一步的需求调查和迭代开发，其他需求将更为清晰并且可以记录在补充i选哪个规格说明中。

在细化阶段结束时，完成并提交用例、补充性规格说和设想时切实可行的。

所谓的“冻结签署”时在细化阶段结束时，就项目剩余时间里索要完成的事项与涉众达成一致意见，并且就需要和进度给与承诺，这是完全切合实际的。在某一时刻，我们需要对“什么、多少、何时”有可靠的认识。从这种意义上说，签署关于需求的合约时正常的，也是由必要的。同时还需要具备变更控制过程，一边正式地考虑和批准需求概念更，避免混乱和不受控的变更。

“冻结签署”的事实还意味着如下几点：

• 在迭代开始和UP中，无论在需求规格说明上付出多少能力，还是不可避免地会存在一些变更更，这应该可以被接受，这些概念更可能时能够为所有者带来竞争有时的、新进发生的对系统投机性的改进，或者时由于加深了认识而引起的改进。
• 使涉众来进行评估、提供反馈以及掌握项目的方向以满足其真实意图，这是迭代开发的核心价值。不关注与参与项目，二十在一组冻结的需求上签字认可后就等着项目结束，这样对涉众来说并没有好处，因为它们几乎不会得到真正满足其需要的结果。

构造阶段

通过构造阶段，主要需求应该以及稳定下来，虽然还不是中介，但是以及可以专注于刺刀的微扰食物链。因此，在该阶段，补充性规格说明和设想都不洗进行大量改动。

参考资料