参考Volere需求规格说明书.docx

参考Volere需求规格说明书
===== = 前言 ===== =

参照Suzanne Robertson,James Robertson著，王海鹏译的**《掌握需求过程（第3版）》**内容中的“附录A Volere需求规格说明书模板”进行编制。

此附录是编写严格和完整的需求规格说明书的指南。

=== Volere需求分析 ===

Volere是在需求工程和业务分析领域，经过多年实践、咨询和研究得到的成果。
Volere需求规格说明书模板的第一个版本是1995年发布的，自那开始，成千上万的组织机构
将该模板作为发现、组织和沟通需求的基础，节省了工作量。

=== 需求类型 ===

为了易于使用，我们将需求划分为一些类型，这样比较方便。这种视角的好处有两点：有助于
发现需求，有助于对需求分组，将特定专业相关的需求放在一起。

“功能性需求”是产品的基础或本质主题事务。他们描述了产品必须做的事情，或必须采取的
处理动作。

“非功能性需求”是功能必须具备的一些属性，如性能和易用性等。不要被这个不幸的名称所
蒙蔽，对于产品的成功来说，这些需求及功能需求同样重要。

“项目限制条件”是由于构建产品的预算或时间而导致的对产品的约束。

“设计限制条件”限制了产品设计的方式。例如，产品可能必须实现在一个手持设备中，主要
顾客将使用这种手持设备；或者必须利用原有的服务器和桌面计算机，或其他硬件、软件和业务
方式。

“项目驱动”是及业务相关的动力。例如，项目目标是一种项目驱动，所有利益相关者也是，
每个人都有不同的理由。

“项目问题”定义了项目执行要面对的情况。我们将项目问题作为需求的一部分，目的是展示
一幅完整的图景，说明对项目的成功和失败产生影响的所有因素，并展示经理们如何利用需求作
为项目管理的收入信息。

=== 测试需求 ===
Volere理念是开始编写需求时就立即开始测试需求。通过加入需求的“验收条件”使需求变得
可测试。验收条件用于对需求进行测量，这样就能确定给定的解决方案是否满足需求。
如果某项需求无法找到验收条件，那么这项需求要么有二义性，要么还没有被很好理解。所有
的需求都必须测量，都必须带验收条件。

=== 需求项框架 ===
需求项框架是编写每项原子需求的指南。该框架（也称为“白雪卡”）的组成部分在这里确定。
你可能决定添加更多的属性，以便你的环境提供必要的可追踪性。例如，实现该需求的产品，
实现该需求的软件版本，或对该需求感兴趣的部门。还可以添加其他属性，但添加时要有节制：
不要随意添加属性，除非它们确有帮助。每个属性你都需要维护。
这个需求项框架可以自动化，也应该自动化，通过Excel可以实现白雪卡。
{{:平台_模板库:图标:白雪卡.jpg?direct&500|}}

===== = 项目驱动 ===== =
===== 1.项目的目标 =====
关注客户要你构建新产品的根本理由。它描述了客户面对的业务问题，解释了产品将如何解决该问题。

==== 1a.该项目工作的用户业务或背景 ====
=== 内容 ===
对开展的业务、它的上下文以及触发开发工作的情况的简短描述。
同时也应描述用户希望用交付的产品来完成怎样的工作。
=== 动机 ===
应该考虑用户的问题是否严重，是否应该解决和为什么应该解决。
也许没有问题，但是重要的商业机会，你的客户希望开拓。如果是这样，描述该机会。
或者，项目要探究或调查可能性。在这种情况下，项目的交付物不是新的产品，
而是一份文档，提供了产品能满足（或不能满足）的需求。
=== 形式 ===
简短的文字描述通常足以说明对项目的理解。你可以加入当前状况模型、业务过程模型、
当前文档的例子、当前状况的照片和视频、网站地址和组织机构图，来支持这段描述。

==== 1b.项目的目标 ====
=== 内容 ===
描述我们希望该产品做什么，以及它将为工作的整体目标带来什么好处。本节不要太冗长，简短地解释项目目标，常常比长而杂乱的论述
更有价值。
简短准确的目标让利益相关者更清楚，更有机会就目标达成一致。

=== 动机 ===
在开发过程中可能会迷失这个目标，这样的危险是存在的。
随着开发工作的进行，随着顾客和开发者不断发现更多的可能性，系统可能在建造过程中偏离最初的目标。
这不是件好事，除非客户有意要更改目标。
有可能需要指定一个人作为目标的监管员，但也可能只需要将目标公开，并定期提醒开发人员注意这些目标。
在每次复查会议上，都应该强制承认这些目标。
=== 例子 ===
对于在线订购产品的顾客，我们希望做出立即和完整的响应。

目标是通过准确预报和调度道路除冰，减少道路事故。

=== 测量指标 ===
任何合理的目标都必须可测量。如果希望检验项目是否成功，这一点就是必需的。
业务通过这个项目所获得的好处，必须由测量指标来量化。
如果项目值得去做，就必须有过硬的业务理由。

假定项目的任务目标是：
对于在线订购产品的顾客，我们希望做出立即和完整的响应。
必须问一下这个目标给组织机构带来的好处。如果立刻得到响应会让顾客更满意，那么测量指标必须量化这种满意。例如，可以测量回头
业务的增长（因为开心的顾客会再次光临）、调查表中顾客满意评分的增加、回头顾客所带来的收入增加等。
问一下涉及哪一种目标。
Δ服务目标：通过量化为客户所做的事来测量。
Δ收入目标：量化一段时间内的收入或收入的增长。收入目标也可以通过市场份额来量化。
Δ法律目标：这不是量化，而是知道产品满足一项法规（可以是当地的法律，或行业和组织机构的标准）。

目标坚定、合理且可测量，这对于后续开发是至关重要的。

=== 形式 ===
你可以用“目标、好处、测量指标（Purpose, Advantage, Measurement, PAM）”的方式来组织你的目标。
Δ目标：一句话解释组织机构投资这个项目的理由。
Δ好处：一句话描述如果项目成功，组织机构将实现的好处。
Δ测量指标：一句话或一张图表，量化新产品将提供的好处。
其他形式的目标也可以采用某种目标模型。例如“扩展的企业建模语言（Extended Enterprise Modeling Language, EEML）”包含一
种目标建模技术。如果你的组织机构在使用企业建模，那么就为企业战略目标及单个项目目标提供了联系。

===== 2.利益相关者 =====
本节描述了利益相关者，即及产品有利益关联的人。你值得花足够的时间准确的确定并描述这些人，因为不知道他们的后果可能非常严重。
==== 2a.客户 ====
=== 内容 ===
这一项给出了客户的姓名（有时称为发起人）。可以有多个姓名，但如果超过3个，本项就会失去意义。
=== 动机 ===
客户对接受该产品有最终决定权，因此必须对提交的产品满意。可以认为客户是对产品进行投资的人。如果产品是为内部使用而开发的，那
么客户和顾客的角色由相同的人来担当。如果无法找到一个客户的姓名，那么也许就不该构建该产品。
=== 考虑 ===
有时候如果为外部用户构建一个软件包或产品，客户是市场部门。在这种情况下，必须指定市场部门的某个人作为客户，并记下姓名。
=== 形式 ===
加标注的组织机构图，说明客户在组织机构中的位置。
列出一些决定，由客户负责做出。
你也可以包含一张图表，展开复查点，并分列出你要提交给客户的东西，作为项目进度的指示器。
==== 2b.顾客 ====
=== 内容 ===
打算购买该产品的人。对内部使用的开发来说，顾客和客户可能是相同的人。客户也可能是一位经理，决定他手下的人是否要采用新的/改
变过的产品。如果开发一个大量部署的产品，本节将描述一位假想用户，作为产品顾客的原型（参见第2e小节）。
=== 动机 ===
顾客最终决定是否从客户那里购买该产品。只有理解了顾客以及他在使用产品时的期望，才能收集到正确的需求。
=== 形式 ===
列出顾客要负责做出的决定。你也可以包含一张图表，展示复查点，并分列出你要提交给客户的东西，作为项目进度的指示器。这可能包括
一些可能的原型或者模拟器，你会在项目过程中提交给顾客。
==== 2c.其他利益相关者 ====
=== 内容 ===
其他的一些人或组织结构的角色和名称（如果可以得到），他们或者受到产品的影响，或者需要他们提供输入信息以便构建产品。
例如，利益相关者可能包括：
□ 客户/发起人
□ 顾客
□ 主题事物专家
□ 公众人员
□ 当前系统的用户
□ 市场营销专家
□ 法律专家
□ 领域专家
□ 易用性专家
□ 外部机构的代表
□ 业务分析师
□ 设计师和开发者
□ 测试人员
□ 系统工程师
□ 软件工程师
□ 技术专家
□ 系统设计师
完整清单访问：，下载利益相关者分析模板。
对于每一类利益相关者，提供下面的信息：
□ 利益相关者标识（角色/职务、人名和组织机构名称的组合）；
□ 项目需要的指示；
□ 利益相关者/知识组合的涉及程度；
□ 利益相关者/指示组合的影响程度；
□ 在相同知识方向具有兴趣的利益相关者直接处理冲突的协议。

=== 动机 ===
不能找齐所有利益相关者会导致遗留需求。
=== 形式 ===
利益相关者图包含每个角色的名称，以及这个角色提供的知识。下面的图示一个通用利益相关者图。你可以用它作为检查清单，将角色名
称换成你的项目中具体的人/角色/组织结构。确定利益相关者还有另外一种方式，就是利益相关者分析表。从可以下载一
份示例。带注释的组织机构图对于确定利益相关者也有是有的。
{{ :平台_模板库:图标:通用利益相关者图.png?nolink |}}

=== 2d.产品的直接操作用户 ===
=== 内容 ===
产品的特殊类型的利益相关者列表—潜在用户的列表。针对每种类型的用户，提供以下信息。
□ 用户姓名/分类：最可能是一个用户团体的名称，如学校里的儿童、道路工程师或项目经理。
□ 用户的角色：总结用户的职责。
□ 主题相关经验：总结用户在业务方面的知识。按照新手、熟练工或专家来评级。
□ 技术经验：描述用户在相关技术方面的经验。按照新手、熟练工或专家来评级。
□ 其他用户特征：描述任何可能对产品的需求和最终设计产生影响的其他特征。例如，身体能力/障碍、智力能力/障碍、对工作的态度、
对技术的态度、物理位置、教育程度、语言技能、年龄段、性别、种族群体。
=== 动机 ===
用户是为了完成工作而及产品交互的人，利用用户的特征来确定产品的易用性需求。用户也被称为参及者。
=== 例子 ===
用户的来源可能很广，有时甚至预料不到。考虑到用户可能是办公室职员、商店店员、经理、接受过专门训练的操作员、普通公众、随意
的用户、路人、文盲、手工艺者、学生、测试工程师、外国人、儿童、律师、远程用户、通过电话线或因特网使用该产品的人、救险工作人员
等。
=== 形式 ===
简单的列表或者表格，包含每个用户角色的用户特征+用户名称/代表。

==== 2e.假想用户 ====
=== 内容 ===
为假想用户编写一个故事，包括假想者用户的姓名、年龄、工作、家庭、爱好、居住地、喜欢的食物、喜欢的音乐、喜好、厌恶、度假地、
对技术的态度、对金钱的态度、或其他任何的特征，这些特征可能影响此人对产品的看法。如果用一张照片（从网上下载）来代表这个想象的
人，会有帮助。
=== 动机 ===
有一个或多个（不超过3个）假想用户，你可以让需求针对你试图满足的人。如果你正在为大众消费品或公众使用的产品确定需求，这就是
一种特别有效的技术。
=== 形式 ===
一段概述，包含了此人的人生故事，包括照片。这段概述可以是一份文档，用于对项目参及者介绍假想用户。你也可以将这段概述制作成大
尺寸（A3）的卡片，在会议上展示，并提醒参及者你们要发现谁的需求。另外一种办法是建立一个故事板，说明假想用户的生活。此外，你也可
以为假想用户创建一个网站，添加此人的日常生活故事，让他或她变得生动。刻画和探讨这个假想客户的各种方式，都是为了帮助人们将假想用
户想象成一个真正的用户，得到具体的真实需求，而非空泛的需求。
==== 2f.对用户设定的优先级 ====
=== 内容 ===
在每类用户后面附上一个优先级。说明用户的重要性和优先权。按以下优先级划分用户。
关键用户：这些用户对产品的后续成功是至关重要的。给由这类用户提出的需求更高的重要性。
次要用户：他们将使用该产品，但他们意见对产品的长期成功并无影响。如果次要用户的需求和关键用户的需求发生冲突，应该优先考虑关
键用户的需求。
不重要的用户：这类用户的优先级也是最低的。这包括不常用的，未授权的和没有技能的用户，以及误用了该产品的用户。
=== 动机 ===
如果认为某些用户对产品或组织更重要，那么应该写明，因为这会影响设计该产品的方式。例如，我们需要知道，是否有一个大顾客曾经特
别询问过该产品，并且如果他们得不到想要的东西，结果会造成更严重的业务损失。
某些用户可能被列为对产品没有重要影响的类别。这表示这些用户会使用该产品，但在产品中没有被赋予利益。换言之，这些用户不会抱
怨，也不会对产品作出什么贡献。来自于这些用户的任何特殊需求都只有最低的设计优先级。
=== 形式 ===
在用户特征表（参见第2d小节）中包含用户重要性评分，为项目核心团队提供信息，根据组织机构的文化，这可能是敏感信息。
==== 2g.用户参及程度 ====
=== 内容 ===
如果合适，在每一类用户后面附上参及程度的说明，用户将以这样的程度参及提供需求，描述希望这些用户提供的贡献—例如，业务知识、
界面原型、或易用性需求。如果可能，评估为了能够确定完整的需求，这些用户至少必须花多少时间。

=== 动机 ===
许多项目因为缺少用户参及而失败，有时候是因为要求的参及程度没有明确。如果用户必须在完成他们的日常工作和进行新项目之间进行选
择，日常工作通常处于优先位置。这要求项目从一开始就明确具体的用户资源分配。
=== 形式 ===
在用户特征表中（参见第2d小节），包含预估的用户参及时间，以及你希望该用户提供的知识。
==== 2h.维修用户和技术服务人员 ====
=== 内容 ===
维护用户是特殊类型的直接操作用于，他们的需求集中在产品的维护和变更上。
=== 动机 ===
许多这类需求将通过考虑不同类型的维护需求来发现，但是，如果我们确定了维护产品的人的特征，就有助于触发一些可能遗漏的需求。
=== 形式 ===
在用户特征表中（参见第2d小节）包含维护用户。----
===== = 项目限制条件 ===== =
===== 3.强制的限制条件 =====
本节描述对产品最终设计的限制条件。限制条件是全局的，它们是适用于整个产品的因素。产品必须在声明的闲置条件下构建。通常你知道
这些限制条件，或在项目进行之前就有要求。它们可能是由管理层确定的，值得认真考虑，它们限制了你能做的事，从而塑造了产品。限制条件
像其他类型的需求一样，有描述、理由和验收标准，编写的格式一般及功能性需求和非功能性需求的格式一样。
==== 3a.解决方案的限制条件 ====
=== 内容 ===
规定解决问题必须采取的方式。描述强制使用的技术或解决方案，包括使用的版本号。还应该解释使用该技术的原因。
=== 动机 ===
确定指导最终产品的限制条件。客户、顾客或用户可能有一些设计偏好，或者只有特定的解决方案才可以接受。如果不满足这些限制条件，
解决方案将不会被接受。
=== 考虑 ===
我们希望定义一个边界，在此边界范围内我们可以解决问题。注意，任何人如果有在某项技术方面的经验，都会倾向于从该项技术的角度来
看需求。这种倾向性导致人们出于错误的原因强加一些解决方案限制条件，假限制条件很容易就潜入到需求规格说明书中。解决方案限制条件应
该只限于那些绝对不可商榷的解决方案。换言之，不论如何解决这个问题，都必须使用这种特定的技术。其他任何解决方案都是不可接受的。
=== 形式 ===
在需求表或数据库中，将限制条件需求作为一种特殊类型的原子需求。关于原子需求的属性，参见本模板开始处的原子需求框架实例。同时
请参考网站上关于原子需求的文章。限制条件的另一种形式可以是新产品/更新的系统架构图（参见第3b小节和3c小节）。

==== 3b.当前系统的实现环境 ====
=== 内容 ===
描述安装产品的技术环境和物理环境。这包括自动的、机械的、组织的和其他设备，以及非人员的相邻系统。
=== 动机 ===
描述产品必须适应的技术环境。该环境成为产品的设计限制条件。需求规格说明书的这一部分为设计者提供了足够的环境信息，以使产品能
成功地及它周围的技术实现互操作。
=== 例子 ===
这可以显示为一张图，用一些图表来代表每一个独立的设备或人（处理节点）。在处理节点间添加接口，并说明他们的形式和内容。
=== 考虑 ===
当前系统的所有组成部分，无论是何种类型，都应该包含在实现环境的描述中。
如果产品将会影响当前组织，火堆当前组织很重要，在此处将包括一张组织机构图。
=== 形式 ===
用一张图来展示每个硬件和软件组件/子组件/设备/构建块，它们将用于产品实现，具体使用什么图取决于组织机构和项目的工作方式。这
里重要的问题在于，让决定如何实现功能需求和非功能需求的人，对实现环境理解无误。常常使用几种UML图，包括类图、组件图、组件结构
图、部署图和包图。也可以使用其他多种自定义的图。
==== 3c.伙伴应用或协作应用 ====
=== 内容 ===
描述那些不属于产品的一部分的应用程序，单产品必须及这些应用程序协作。这些可能是外部应用程序、商业软件包或已存在的内部应用程
序。
=== 动机 ===
提供由于伙伴应用程序引起的设计限制条件。通过描述这些伙伴应用或对它们建模，将发现潜在的集成问题并对它们加以重视。
=== 例子 ===
这一部分可以通过包含书面的描述、模型或对其他规格说明书的引用来完成。描述必须包含对产品有影响的所有接口的完整规格说明。
=== 考虑 ===
查看工作上下文范围模型，以确定是否某个相邻系统应该被作为伙伴应用对待。也可能需要查看某些工作细节来发现相关的伙伴应用。
=== 形式 ===
一张图或一张表，确定带构建的产品及其他相邻系统间所有接口。要记住，相邻系统可能是软件、人或硬件。一些相邻系统是在组织机构内
部的，因此可能更易于理解或受到影响。另一些相邻系统可能在组织机构之外，可能很难甚至不能影响。产品范围图（参见8a小节的例子）常用
于确定及伙伴应用或写作应用之间的接口。
==== 3d.立即可用的软件 ====
=== 内容 ===
描述商业的、开源的，或其他立即可用的软件（OTS），这些软件必须用于实现产品的某些需求。也包含采用费软件的立即可用的构件，
如硬件或其他商业产品，作为解决方案的一部分。
=== 动机 ===
确定并描述商业的、免费的、开源的或其他产品，它们将成为最终产品的一部分。这些产品的特征、行为和接口是设计的限制条件。
=== 考虑 ===
在收集需求时，你可能会发现需求及该OTS软件的行为特征有冲突。请记住使用OTS产品是在全部需求已知之前就强制决定的。因为这一
发现，必须考虑该OTS软件是否是一个可行的选择。如果使用该OTS软件是不能商榷的，那么冲突的需求必须放弃。
注意，发现需求的策略会受到使用OTS的决定的影响。在这种情况下，调查工作上下文范围比较OTS产品的能力是并行的。根据OTS团建的
全面程度，也许可以去发现匹配和不匹配之处，而不必以原子细节的方式编写每项业务需求。不匹配之处就是要确定的需求，这样就可以决定
是通过修改OTS软件来满足这些需求，还是修改这些业务需求。
既然在软件领域有如此之多的诉讼，就应该考虑使用OTS是否会让自己卷入法律诉讼。第17小节包含这方面的内容。
=== 形式 ===
模型或书面文档，指明利用这个OTS软件产品能实现的功能需求或非功能需求。如果该OTS产品有结构良好的需求规格说明书和系统架构
模型，那么该模型将有助于你确定该产品能满足哪些需求。如果该产品的文档不是可追踪的、组织良好的，那么你就需要对自己的需求做更多
的细节工作，才能发现在怎样的层面上可以将你的需求映射到该OTS产品上。另一种形式是有一个或几个人，是这种OTS产品的专家，他们可以
回答你的问题，这样就不必为了神秘的市场营销文档而困惑。

==== 3e.预期的工作地点环境 ====
=== 内容 ===
描述用户工作和使用该产品的工作地点。此处应该描述任何可能对产品设计产生影响的工作地点特征，以及工作地点的社会和文化环境。
=== 动机 ===
确定工作地点的特点，这样产品可以为补偿一些困难条件而设计。
=== 考虑 ===
物理工作环境限制了工作完成的方式。产品应该克服存在的任何困难，但是可以考虑重新设计工作场地，而不是让产品来满足它。
=== 形式 ===
□ 工作场地的书面描述。
□ 丰富的图片展示工作产地的所有组成部分。
□ 工作场地的照片。
□ 工作场地的视频。
==== 3f.进度计划限制条件 ====
=== 内容 ===
任何已知的最后期限，或商业机会的时限，都应该在此处说明。
=== 动机 ===
确定会影响产品需求的关键事件和日期。如果最后期限的事件很短，那么需求必须保持在构建事件允许的范围之内。
=== 考虑 ===
通过给出日期并描述为什么它是关键的，说明存在的最后期限。同时也会确定最后期限之前的一些日期，在这些日期里应该可以提供产品的
某些部分用于测试。
也应该对不能遵守最后期限所带来的影响问一些问题：
□ 如果我们不能在年底之前完成构建该产品，会发生什么？
□ 如果我们不能在圣诞购物季开始之前拥有该产品，在财务上会发生什么影响？
□ 产品的哪些部分对圣诞购物季最为关键？
=== 形式 ===
书面陈述，给出最后期限的日期和理由，以及不能满足最后期限所产生的影响。

==== 3g.该产品的财务预算是多少 ====
=== 内容 ===
该产品的预算，以金钱或可利用资源的形式说明。
=== 动机 ===
需求不能超出预算。这可能限制了产品能包含的需求的数量。
知道预算的意图在于确定是否真的需要该产品。
=== 考虑 ===
目的是限制无节制的野心，防止团队在智能买一架Cessna时，去收集空客380的需求。在预算范围内构建产品是否实际？如果答案是否定
的，则要么是客户并没有真正下决心构建产品，要么是客户认为该产品没有足够的价值。不论哪种情况，都应该考虑是否值得继续下去。
=== 形式 ===
书面陈述，给出预算的金额和资金的来源。

==== 3h.企业限制条件 ====
=== 内容 ===
本节包含企业特定的需求，该企业投资于你的项目。
=== 动机 ===
理解一些有时候似乎是无关或没有道理的需求，因为它们及项目的目标没有明显的关系。
=== 考虑 ===
你是否打算在Macintosh上开发产品，而办公室经理曾宣布只允许用Windows系统的计算机？
是否一名董事也是另一个公司董事会的成员，该公司生产的产品类似于你要构建的产品？
无论你是否同意这些企业需求对结果几乎没有影响，事实是系统必须符合这些企业需求，即使你能找到更好、更有效或更经济的解决方案。
在这里探讨一些问题，可以省去将来的麻烦。
企业需求可能完全及组织机构内部的政策有关。在其他情况下，你需要考虑客户的组织机构的政策，或国家的政策。关于企业需求，另一种
看法是将它们作为限制条件，它们由战略决定来确定，在你的项目能控制的范围之外。

===== 4.命名惯例和定义 =====
根据我们的经验，所有项目都有自己独特的词汇表，通常包含各种缩写和简写。如果不能正确理解这些项目特有的术语，肯定会导致误解、
浪费时间、团队成员间的沟通问题，最终得到质量糟糕的规格说明书。
==== 4a.定义利益相关者在项目中使用的所有术语，包括同义词 ====
=== 内容 ===
一个词汇表，包括在需求规格说明书中使用的所有名称的含义。选择名称要小心，避免不同的，不希望的含义。
如果你在研究的工作已经有一份术语表，那就用它作为起点。随着分析的推进，这份词汇表应该扩大和改进，但目前，它应该介绍利益相
关者使用的术语，以及这些术语的含义。这个词汇表反映出工作领域当前使用的术语，也可以基于你的行业中使用的标准名称。
对于每一项，编写一段描述。相应的利益相关者必须同意这段术语含义的描述。
我们建议你加上所有的缩写和简写。我们常常遇到有些团队成员使用缩写，但承认他们不知道这些缩写的含义。本节让你有地方记录这些
缩写。

=== 动机 ===
名称十分重要，它们能反映含义，如果定义得好，可以省掉数小时的解释。在项目的这个阶段注意名称将有助于尽早澄清一些误解。
随着详细工作的推进，词汇表为更准确的业务/工作数据模型和数据字典（参见第7小节的模板）提供了输入信息。随着分析数据字典的演
进，词汇表中的许多定义在字典中得到扩展，添加它们的构成数据。

=== 考虑 ===
利用已有的参考资料和数据字典。虽然，最好不要对已有的术语进行重命名，除非它们很模糊，容易引起歧义。
在项目的开始就要强调避免有二义性的词和同义词。解释它们会怎样增加项目的成本。
=== 形式 ===
已有的术语词汇表，行业字典的链接，或问题域常用术语清单，并用一句话来描述每个术语的含义和目的。
===== 5.相关事实和假定 =====
相关事实是一些外部的因素，对产品有影响，但不会在需求模板的其他部分提及。它们不一定会转化为需求，尽管也可能会转化。相关事实
提醒开发者注意一些情况和事实，它们会对需求产生影响。
==== 5a.事实 ====
=== 内容 ===
本节确定一些事实，它们对产品有影响，但不是强制性的需求限制条件。事实为规格说明书的读者提供更多的背景知识，
以理解业务问题。
=== 动机 ===
相关事实为规格说明书的读者提供了背景信息，可能对需求有所贡献。它们将对该产品的最终设计产生影响。

==== 5b.业务规则 ====
=== 内容 ===
这些业务规则可能影响工作/业务/领域，即需求的来源。相关的业务规则将触发需求。
=== 动机 ===
在需求发现过程的各个阶段，都会提及业务规则。一条业务规则是否及你在做的项目有关，通常很难立即弄清楚。本节提供一个地方来记录
业务规则，随着对工作的理解逐渐加深，再重新审视它们，利用它们作为触发器，来发现相关的需求。
=== 形式 ===
描述业务规则的书面陈述，该规则的理由，该规则的权威性。在新项目开始时，确定是否已经确定了一些相关的业务规则。如果是这样，这
些业务规则可以考虑进行需求复用。如果你的项目发现了新的或变更的业务规则，就添加到企业的“业务规则手册”中。业务规则手册是所有项目
的输入，也由所有项目更新。
==== 5c.假定 ====
=== 内容 ===
开发者所做的假定的清单。这些假定可能是关于预期的操作环境的，也可以是任何对产品有影响的事情。作为管理预期的一部分，假定还
包含关于产品不会做什么的说明。
=== 动机 ===
让人们声明他们所做的假定。同时，让项目中的每个人意识到所做的假定。
=== 考虑 ===
我们常常无意识地作出假定。有必要及项目团队的成员交谈，以发现他们所作的任何无意识的假定。询问利益相关者（包括技术上的和业
务上的）以下问题。
□ 预计会得到哪些软件工具？
□ 会有任何新的软件产品吗？
□ 预计会用一种新的方式来使用现有的一个产品吗？
□ 是否认为我们将能够处理一些业务变更？
在项目早期声明这些假定是很重要的。也可以考虑假定正确的可能性，如果可能的话，列出假定没有发生时可以采取的其他选择。
这些假定应该是暂时性的。也就是说，在规格说明书发布时，它们应该都得到澄清：假定应该要么成为一项需求，要么成为一项限制件。
例如，如果假定及一个伙伴产品的功能有关，那么这种功能应该已经证实是具备的，这成为使用它的一项限制条件。相反，如果购买的产品不
合适，那么构建所需的功能就会成为项目团队的一项需求。

=== 形式 ===
一段描述假定的书面陈述，以及假定未能成真时对项目的影响。根据假定的复杂性，有可能需要包含对其他文档或人员的引用。
可以用一些因果图来分析和分享对假定的理解，如Peter Senge的动态模型。

----
===== = 功能需求 ===== =
===== 6.工作的范围 =====
工作的范围确定了要研究的业务领域的边界，大致描述了它如何适应环境。在理解了工作和它的限制条件之后，就可以建立产品的范围（参
见本模板的第8小节）。
==== 6a.当前的状况 ====
=== 内容 ===
这是对原有业务处理过程的分析，包含人工的和自动的处理过程，这些过程可能被新产品取代或改变。在Volere BrownCow Model中，这
个视图被称为“现在如何”（How-Now）视图。业务分析师可能已经完成了这方面的调研，作为项目业务用例分析的一部分。这里也适合建立一些
业务处理过程模型。这些模型包括角色、个人、部门、技术和过程。它们展示了工作流和过程组件之间的依赖关系。
=== 动机 ===
如果项目打算对原有的人工或自动化系统进行变更，就需要理解建议的变更所带来的影响。研究当前的状况奠定了基础，以便理解建议所带
来的影响，并选择最佳的替代方案。业务过程建模并非总是导致创建软件。相反，某些过程变更和角色分配方式，可能是进行必要改进的最佳方
式。
=== 形式 ===
有很多不同的表示法适用于创建业务过程模型。例如活动图、业务过程图、泳道图和数据流图。
==== 6b.工作切分 ====
=== 内容 ===
工作上下文范围图确定了为构建该产品需要调查的工作。注意这包括的范围超出了目标产品，
如果我们不了解产品将支持的工作，就不太可能构建及它的环境无缝集成的产品。
{{ :平台_模板库:图标:气象预报服务.jpg?direct&500 |}}

=== 动机 ===
清楚地定义工作研究和需求工作的边界。如果没有这种定义，我们就不太可能构建及它的环境无缝集成的产品。
=== 考虑 ===
上下文范围图中使用的名称，应该及第4节中的命名惯例保持一致，最终应在第7小节的数据字典中定义。
如果没有这些定义，上下文范围模
型就缺少必需的严格性，有可能被误解。相关的利益相关者必须同意上下文模型中展示的接口定义。
=== 形式 ===
□ 一张图，展示工作及相邻系统之间的输入和输出流。
□ 一张表，确定工作及相邻系统之间的所有输入和输出流。
输入和输出的名称最终在数据字典中定义（参见第7b小节）。

==== 6c.确定业务用例 ====
=== 内容 ===
一个事件清单，确定工作系统要响应的所有业务事件。业务事件是真实世界中发生的对工作产生影响的事情。当到了工作做某事的时间
时，也会发生业务事件。例如，产生每周的报表，提醒没有付款的顾客，检查设备的状态等。对每个事件的反应被称为一个业务用例（BUC），
它代表了工作的一部分功能。
该事件清单包括下列元素。
□ 事件名称
□ 来自相邻系统的输入（及上下文范围图中的名称相同）
□ 对相邻系统的输出（及上下文范围图中的名称相同）
□ 对业务用例的简单