无论你怎样做，需求都会在项目过程中发生变化，这点毋庸置疑。

但是采用正确的方法进行需求管理，的确可以大大降低需求变更。为了保证正确理解了用户的需求，在需求访谈后，利用业务原型法来得到用户的确认不失为一种很好的方法。前面所说的低保真原型法就特别值得借鉴。

如何正确书写需求规格说明书，用甲乙双方都能接受的方式来准确无误地表达需求也很关键。结构化的需求表示方法，会采用一种类似于层次结构的方法来表达需求。就是先把需求按照功能来进行划分，再把功能一层一层地细分下去。需求的语法类似于下面微软研究院给出的一个营销系统的例子：

1）用户必须每天可以看到不同的地区的销售情况。

2）销售总监必须可以看到每个产品对利润的贡献。

这种需求表达方法最大的特点是站在系统的设计者的角度而不是用户的角度来表达需求。这种表达方式往往是利用逻辑性的语言来阐述需求，这是和人的左脑沟通的语言。而在实际中往往会忽略一些真实使用的信息，另外每个人的经历不同，对待同一句需求的理解也不尽相同。很可能就会导致最终设计者错误地理解了用户的真实需求，而最终实现者也可能会误解设计者的需求。为了消除这种需求描述方式带来的理解偏差，一个常见的思路就是把需求用更容易理解的语言表达出来，也就是用和人的右脑沟通的语言进行沟通。

目前在软件开发领域有两种比较流行的做法。

一种是使用面向对象方法（UML）的用例的方式来对需求进行建模。这种建模的方式首先要识别系统的真实用户，之后切换到用户的视角来看系统可以提供什么样的功能。

这种方法首先把系统和用户交互的业务功能用可视化的方法表达成一个椭圆型，这样更形象化。之后对每个用例，描述其使用时候的场景（Scenario），如下图所示。

用例场景描述了用户真实使用这个系统这个功能时候的场景，十分便于用户理解，因为这是一种典型的“右脑沟通”语言。

为了规范用例的格式，便于大规模系统各个使用者之间的交流，各个公司纷纷制定出来用例规范。

编写详细的或完整的用例，尚无通用的模板（template）。现在存在很多相互竞争的模板。同时，程序员们也被鼓励用那些适合于他们的工作或者他们所做项目的模板，相对于某个指定模板的细节来说，项目的标准化要重要得多，但是这些模板的关键部分都是大体相同的。

（1）用例规范。

典型部分包括：

用例名

迭代

综述

前置条件

触发器

基本事件流

备选路径

后置条件

业务规则

说明

作者和日期

不同的模板经常有其他部分，如，假设、异常、建议和技术要求，也会有行业细节部分。

用例名

用例名为用例提供了一个唯一标识。它要用动/宾格式书写，并且要充分，达到最终用户能够明白用例中描述的是什么。

迭代

迭代部分通常需要告知读者用例完成的阶段。最初，为业务分析和确定范围的用例和用于软件开发的用例肯定会有许多不同。老版本的用例可能还在当前文档中，因为它们对不同的用户群可能会有价值。

综述

综述部分用于在主体完成之前捕获基本场景。它提供了快速的总结，避免了读者浏览全部内容，能够很快地理解该用例的用途。

前置条件

前置条件部分用来表达当用户开始用例时某些条件必须为真。但是它们不是启动用例的触发器。

触发器(www.daowen.com)

触发器部分描述了启动用例的起始条件。

基本事件流

最低限度，每一个用例都需要描述一个主场景或者典型事件流。主事件流一般是一组有编号的步骤，如：

系统提示用户登录。

用户输入他的名字和密码。

系统验证用户信息。

系统使该用户登录入系统。

备选路径

用例可能包含第二条路径，或者和主题不同的备选场景。异常或当出错时会发生什么事情也需要描述出来，这种描述可以在备选路径中或者在它本身的部分。备选路径使用基本事件流中的序号来标示在哪一点上同基本场景不同，并且如果合适它从哪一点回到基本场景中。目的是避免不必要的重复信息。

备选路径的例子：

系统识别用户机器上的cookie

到步骤4（主路径）

异常路径的例子：

系统不能识别用户登录信息

到步骤1（主路径）

后置条件

后置条件部分总结了在场景结束后事务的状态。

业务规则

业务规则是一些成文的或未成文的规则，对于用例来说它决定了一个组织是如何执行业务的。业务规则是一个特殊种类的假定。它可能适用于某一个用例或者整个用例，甚至整个业务。

注释

经验告诉我们，不管采用何种模板，分析人员发现总有重要的信息不适合模板的结构。因此每一种模板通常包含了这种明显不能避免的信息的部分。

作者与日期

这部分列出创建用例的版本和谁书写的。还需要列出开发过程中从早期阶段开始的每个用例版本的日期。作者习惯在下面列出，因为它不被认为是重要的信息；用例是共同努力的结晶，并且它们被所有人拥有。

从工程的角度来讲，用例的这些要求规范更能保证软件设计和编写的质量。但是，如果把用例的作用定义为捕获用户准确需求的话，那么从心理学上讲，用例这些规范反而适得其反。因为这些规定和条条框框，会让人本能地束缚住右脑思维，不能体会到真正的使用场景。另外，这些规范过于形式化，也是一直为广大程序开发者所诟病的地方。好多时候，这些用例在整个软件开发中根本就不会被用到。这是因为，程序员在编写程序的时候，都会有固定的套路，例如编写一个查询功能，按照开发规范，会有容错机制，就是异常处理机制，相当于备选路径，而类似查询的功能的讨论都差不多，也就是设置查询条件，决定显示方式等，所以大部分查询类的功能，程序员即使不看用例说明，也不会有什么太大问题。因此，用例在这个意义上讲就有些形式主义了，只是浪费了大量的文档，为了完成软件工程规定而做。用例的出发点是好的，用户和设计者以及开发者之间假设一个沟通的桥梁，但是却导致正如敏捷的发起人Mike Cohn所说的那样：“用例使得用例的编写者过早地把注意力从业务目标转移到软件实现上。”而实际的问题是这种表示方法既没有充分发挥完全站在用户的角度看问题的作用，也没有很好地成为开发人员的参考。

为了解决这个问题，敏捷方法索性把里面捕获用户需求的地方抽取出来和用户交流，那就是用户故事方法。

（2）用户故事方法。

关于用户故事，Ron Jeffries用3个C来描述它。

1）卡片（Card）：用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。

故事的书写格式为

作为一个<角色>，我想要<活动>，以便于<商业价值>（As a<Role>，I want to<Activity>，so that<Business Value>）。

可以参考启动章节里面的虚拟用户的方法来创造典型用户档案。另外，可以在卡片上画低保真原型。

2）交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通。

3）确认（Confirmation）：通过验收测试确认用户故事被正确完成。