来自于项目甲方，还是直接或间接的用户、经理、高级经理、操作人员、支持人员、测试人员，与你的系统有联系的其它系统的开发人员，或是维护人员？这是所有的正式需求的来源吗？事实上，提供需求、解释需求、指定需求和排列需求优先级是项目甲方的职责所在。此外，项目甲方有权利要求开发队伍投入时间去辨别和理解这些需求。要想以这种轻巧建模的方式获得成功，理解这个概念是非常重要的。项目甲方负责提供需求，开发组负责理解和实施。
这是否就意味着你可以坐等你的项目甲方来告诉你他们需要什么呢？当然不是。针对他们所告诉你的内容，你可以提出问题，进行分析，促使他们给出更具体的内容，甚而至于可以提出你自己的见解使之改变初衷。你可以建议增加一些新的需求，请注意你所提出的仅是建议，他们可以考虑作为正式的需求加以接受（可能会作出修改）或拒绝。为了找出潜在的需求，你应该经常与甲方保持联系，并借助于一些已有的文档，比如公司政策法规、以前的系统，或者公开的可用资源，比如web上的信息、书籍、杂志或你竞争对手的产品和服务。再次声明，你的项目甲方是需求的最终决定者，而不是你。我不能不强调这一点。
那么项目甲方又从哪里知道他们的需求呢？“我真希望我能这样做”，他们经常会这样抱怨现有的系统，因为他们的竞争对手能做到，但他们却不能；或者想避免过去所出现的问题；或者仅仅是想多增加一个新的功能。一些甲方，尤其是操作人员和高级IT部门经理，可能需要集成现有或即将上马的系统；或者由于某项（象必须削减计算机数量）政策而带来的需求。值得注意的是你的项目甲方应该基于大量的依据明确地阐明需求，而这些依据是应该存在的，你可以通过与之交流确定这一点。
我的经验告诉我在项目中邀请相关方面的专家的加入对找出潜在的需求是很有价值的。例如构建一个电子商务系统，我会邀请有国际化软件设计经验的人员、税法专家或者供应专家的加入。当你对系统中的某些方面不熟悉时（有可能这是你首次构造面向世界各地用户的电子商务系统），这个方法尤其有效。我经常会邀请一些外部的专家和几个甲方在一起交流一两天，来帮助我们检查是否由于我们的经验欠缺而遗漏了什么。这对于确保我们的系统是否完整是一个很重要的方式，特别是在最初定义项目所应包括的范围。这同样也能够帮助甲方进一步的思考。但是，你意识到其中存在危险吗？你所邀请的外部专家提出一些建议可能听上去是非常好的，但目前根本就用不上的。换句话说，你依然得从这些专家意见中精挑细选。
一些基本原理
项目甲方的积极参与对构造需求是非常关键的。实际操作中要做到这点存在着两个问题：第一，甲方自身的提供需求的能力以及他们（或者你）是否愿意积极地参与进来。从我的经验来看，一些项目组并没有足够的途径与甲方联系（或不知道甲方在哪），这完全是项目组自身的问题。你的项目肯定有资金，不是吗？这些资金一定是来自于以某种形式存在的项目甲方，所以他们是确实存在的。同样，用户也是肯定存在的。即使你的系统是面向大众，也至少存在着潜在的用户，你可以找到他们，同他们交谈。所以一定存在着你可以向之询问的人。你可能会说，“有时要找出这些人有一定困难”，“要让他们参与进来不是很好办”。是的，确实存在这样的难处，想办法克服它。在“解决需求分析建模中的常见难题”一节中我谈到了一些解决办法，包括没有足够的途径与甲方联系的问题。我的原则是，如果你的项目甲方不能或不愿意参与，这就意味着你的项目失去了内部支持这条成功的条件，因此你要么解决这个问题要么干脆取消这个项目，以减少损失。如果你听之任之，至少你不能宣称使用的是灵巧建模（Agile Modeling）的开发方法（甲方的积极参与是其中的一项核心内容，在AM的开发方法中必须实施）。
那怎么才算项目甲方积极地参与进来了呢？图1使用UML活动图（UML activity diagram）大体上描述了需求阶段的流程，标示出开发人员与甲方各自应承担的任务。图中的虚线把这两部分任务分开来。从图中可以看出有一些任务是共同承担的，如想法或建议的确定（identifying ideas or suggestions）、潜在需求的讨论（discussing a potential requirement）、建模（modeling），可能还有文档的开发（potentially documenting）。项目甲方单独负责指定需求的优先级，系统是为他们开发的，这当然是他们的责权所在。同样的，开发人员负责估计实现这个需求所需的资源，因为他们是实际工作人员。如果自己不作估计而采用来自于项目组外部的估计，这是不合理的也是不可取的。虽然需求的优先级确定和估算超出了AM的讨论范围，但是你可以在如XP和UP这样的软件流程（Software Process）中找到它，理解它们对于整个需求分析是很重要的。AM并不是一个软件流程，它只是应用于这些软件流程中的一种建模方法。
我的观点是：项目甲方应该加入需求的建模和文档开发中来，积极地参与，而不仅仅是提供信息。为达到这点，肯定需要开发人员对甲方进行培训、导引和指导，这是完全可能做到的。我曾经见过一些刚起步的小公司、大企业和政府机构中的甲方能够以非常高的效率建造需求模型以及将这些需求文档化。在电信业，在金融业，在制造业，在军队里我都看见这样的人存在。为什么这点这么重要？因为你的项目甲方才是需求的真正专家。他们知道他们想要的是什么（参见“解决需求分析建模中的常见难题”，如果他们不知道)。而且只要你愿意，他们是能够学会如何建造需求模型和将它们写下来（译注，这样你们之间就可以同一种语言进行沟通）。从轻巧的观点看，这是很有意义的，因为有更多的人将会分担需求建模的工作。
为了让项目甲方更容易地参与进来，消除行业术语方面的障碍，你应该遵循使用最简单的工具这一做法。表1列出了许多需求阶段的artifact，他们都可以用简单或复杂的工具得到。对于每一种artifact，表中都给出了对应的简单工具。图2和图3是使用简单工具的两个例子。图2表示的用粘贴纸针模拟出一个显示界面。图3是使用索引卡片建立概念模型的例子。当你在需求分析阶段引入新的技术时，比如一些可以制作很好的使用案例图的绘制工具或有强大功能的CASE工具，这就会使得你的项目甲方很难加入进来。因为他们不但要学习建模的技术，而且还要学习如何使用这些工具。使用越简单的工具，进入的门槛也就越低，由此你才有更多的机会去增进相互之间的有效协作。
3 两个CRC卡片
我坚信需求的建立是独立于技术的。面向对象的需求、结构化的需求、基于组件的需求，这些都属于实现技术的范畴。虽然你可以选择某种技术来分析需求建立需求，但必须牢记你所真正关心的是需求本身。下面所讲的所有技术，你可以选择其中一种或几种来进行需求建模的工作。
但有时你又不得不抛开“建立与技术无关需求”的想法。比如一个很普遍的限制就是大多数的项目可以从已有的基础技术上获益。在这个层次上，需求仍然是独立于技术的。但如果你仍执著要抛开已有的一些基础技术，比如某个版本的Sybase数据库或要与SAP R/3给出的模块集成，而非得从最底层开始，那就过头了。只要你知道你在做的是什么就可以了，但不要经常性地这样干。
记住从小事做起。越小的需求（象特性(features)或者用户故事(user stories)），相对于越大的需求（象使用案例(use case)）就越易于估计和实现。平均的来说，一个使用案例涵盖的功能要多于一个使用情景，这就是“大”的含义。
对于需求跟踪表（requirements tracebility matrix）的使用也需要三思而后行。跟踪能力是指能够由项目进行中所生产的某个artifact的某一方面追踪到另一个与其相关的artifact，而需求跟踪表就是用来记录这些关联关系的。它从每个需求为起点，可以追溯到所有与之相关的分析模型、架构模型、设计模型、源代码或者测试用例。使用跟踪表的组织为了保证各个阶段artifact（包括跟踪表本身）的一致性，必须要经常进行更新工作，而不是仅在受到影响时才改动。使用它的好处是你可以很容易地分析出系统中的哪些部分将会受到该需求改变的影响。但是，如果你有一两个熟悉系统的人（译注：当然你得留住他们），当系统需要改变时，通过他们来进行评估影响会更容易而且费用也会更低。在我看来，给予跟踪表的评价过高了，因为维护它所带来的开销远大于所得到的好处，即便你有特殊的工具去做这件事情。让你项目的管理层认识到它真正的价值和代价所在，让他们来作决定是否使用它。毕竟，跟踪表是一份有效的文档。他们可以据此做出决定。
需求的类型
我认为需求可以分为两类：行为类型的（behavioral）和非行为类型的（non-behavioral）。行为类型的需求描述的是用户如何与系统交互（用户界面）、如何使用该系统（用法）、或者是系统如何实现一个业务功能（业务规则）。非行为类型的需求描述的是系统的技术方面，典型的如可用性、安全性、性能、互用性、可信度和可靠性。要注意的是这两类需求有时并不一定能够完全分开来。对存取数据速度的性能要求明显是技术方面的需求，但它也会反映为用户 界面的响应时间，从而影响到可用性和某些用法。访问权限管理，比如谁能够获取特定的信息，这明显是一个行为类型的需求。但它也同样涉及到安全性这个非行为类型的需求。别紧张，不要死揪住这类问题。关键的是能够确定和理解所给出的需求。如果你把一个需求分错了类，谁又会真的去关心呢？
可能的需求分析的artifact
由于存在几种类型的需求，有可能其中一些或全部适合于你的项目；又因为每种模型都有长处和缺点，你应该综合利用这些模型，取长补短，以发挥最好的效率。表1列出了一些常用的需求分析建模的artifact，更详细的描述可见Artifacts for Agile Modeling 一文。表中的“简单工具”一栏指出生成相应artifact所常用的简单工具（使用简单工具的重要性在“一些基本原理”一节中讨论过）。
|
artifact |
类型 |
简单工具 |
描述 |
|
业务规则定义Business rule definition |
行为类型 |
索引卡片（Index card） |
业务规则是软件必须满足的一条有效的原则或政策。 |
|
变化案例 change case |
两者之一 |
索引卡片（Index card） |
变化案例常用来描述新的潜在的需求，或对已有需求的修改。 |
|
CRC模型 CRC model |
两者之一，通常是行为类型 |
索引卡片（Index card） |
CRC模型是一组标准的索引卡片。每一张卡片被分为三个部分，分别是类的名称，类的职责，以及该类的合作者。类是一类相似对象的抽象，职责是该类所知道的或要去做的，合作者是另外一个与该类有交互的类。在需求建模过程中，CRC模型用在概念建模中，用来揭示某一领域内的概念和它们之间高层的关系。 |
|
约束定义Constraint definition |
两者之一 |
索引卡片（Index card） |
约束是对你提供解决方案的自由度的限制。把约束作为全局的需求对你的项目来说是很有效的。 |
|
数据流图 Data flow diagram（DFD） |
行为类型 |
白板 |
数据流图展现系统中数据在处理过程间、实体间、以及数据存储站间的流动情况。它常用来描述系统的环境，指出与你的系统相交互的主要外部实体。 |
|
基本用户界面原型Essential UI prototype |
两者之一 |
粘贴纸 |
基本用户界面原型是低精度的。它表现的是界面背后的大致想法，而非细节。 |
|
基本使用案例Essential use case |
行为类型 |
纸张 |
一个使用案例（use case）就是针对一个参与者（actor）的一连串动作，通过使用案例可对该参与者的价值进行测量。基本使用案例是一个简化了的、抽象的、一般化的用案例。它以与特定技术和实现无关的方式攫取一个使用者的意图。 |
|
特性 Feature |
两者之一，常用于行为类型 |
索引卡片（Index card） |
从用户的角度来看，特性是一个小的、有用的结果。一个特性是可以用于计划、报告和跟踪的一个计量单位。它是可理解的和可衡量的，可以在两个星期内完成（同其它几个特性一起)（Coad, Lefebvre, &Deluca, 1999）。（译注：一个特性在大多数情况下等同于一个功能） |
|
技术方面的要求 Technical requirement |
非行为类型 |
索引卡片（Index card） |
技术上的要求是属于系统中非功能性的部分，比如性能上的问题、可靠性的问题或者技术环境方面的问题。 |
|
使用情景 Usage scenario |
行为类型 |
索引卡片（Index card） |
一个使用情景通过一个或多个的使用案例或用户故事描绘一条单一的逻辑路径。一个使用情景可以表示一个使用案例中的基本路线，即愉快路径；或者该使用案例中的其它路径；或者一条跨越几个使用案例或用户故事的路径。 |
|
使用案例图 Use case diagram |
行为类型 |
白板 |
使用案例图由一些使用案例、参与者和它们之间的关系组成。或者还会有一个系统边界盒。建模时，数据流图用来描述系统的环境，指出与系统相关的主要外部实体。 |
|
用户故事 User story |
两者之一 |
索引卡片（Index card） |
一个用户故事就是你与项目甲方进行的一次谈话的备忘录。它是高层次的需求，包括行为需求、业务规则、约束和技术要求。 |
表 1 可选的需求建模artifact
应该注意的是，并不意味着你需要将所有上面所列出的都用在任何一个项目中。熟悉你的模型这条原则（见The Principles of Agile Modeling一文）说的就是你要知道每个artifact适合在什么时候用。你对模型了解得越多，就越能够根据实际情况运用正确的artifact。
artifact的选择往往被所采用的底层软件开发流程所左右。在主页上，我简要地说明了AM与其它有着完整生命周期的软件开发流程一起使用的情况，比如XP或UP。通常不同的底层软件开发流程对需求分析artifact有着不同偏好，象XP使用用户故事而UP用使用案例。这也是你在为需求建模时应该考虑的问题。详细内容请参见AM and XP和AM and UP。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/