--------------------------------------------------------------------------------

作者：林星　来源：IBM China　http://www.csai.cn　2003年4月2日

和业务建模时期不同的是，我不再花费笔墨讨论需求要如何做，因为做法、注意点和业务建模时期并没有什么太大的区别。而在完整的流程上，像RUP、XP之类的方法学可比我讲的要好的多。因此，我会把焦点集中在我在实际工作中的一些困惑，以及一些思考。

1、"和其它阶段的关系"的再思考

上一篇的末尾我们简单的讨论了细节需求阶段和其它阶段的关系。对于软件过程的各个阶段，不同之处只是注重的焦点不同而已。在业务建模阶段，我们关注于系统的整体需求；在细节需求阶段，我们更关注于需求的细节部分。其它的阶段也是一样，架构阶段，所关注的当然是如何设计出一个合适的架构；到了设计阶段，注意力就转移到了如何设计方面。 当然，焦点的不同，导致了各个阶段所需要的技能和工具也不尽相同。业务建模阶段需要你有整体的把握能力，你可以使用简单的用例图，基本的用户素材等工具。细节需求阶段则要求你能够充分的挖掘需求和进行良好的沟通。相应的，在架构、分析、设计等阶段，也会有不同的需要。

各个阶段的实质就是注重点的不同，这对于大多数的软件开发而言都是一样的。不论你采用的过程是传统的，还是迭代的。

2、架构

Martin Fowler在他的ISA中写到：

I'm using architecture to mean the important design decisions, the ones that shape most aspects of a software system. These are often the harder decisions to change later on in the project (although often not as hard as people think). As a result these are ones where it's useful to start in the right direction, and thus knowing about architecture is a valuable skill for any software developer.

架构并不神秘，无非是一个决策而已，只是这项决策对软件特别重要就是了。软件开发人员可能根本没有主动的进行架构设计，但是他的行为，已经潜移默化的进行了；而还有一些人，总在谈论着架构，但是并不了解这个词的含义。

春运就要到了，学生也要赶着回家。如何选择回家的交通工具就是一个重要的决策。路程的远近、不同交通工具的价格都是显式的，比较容易知道的。而以往的经验也告诉你，火车票比较便宜，但是比较紧张，花费时间较长，整个过程也不舒服；飞机票比较贵，但是容易买到，花费时间少，整个过程很舒服。这时候你就要做出正确的决策，为回家选择一个正确的架构。你可能考虑的因素有哪一些？以下就列出了一些可能的因素：

拥挤程度，大家都知道春运时那种情况；

购买票的难易程度，火车票需要很早就要预定了；

是否有额外的渠道，比如你能够买到飞机的学生票；

经济实力，经过了一个学期的花销之后，现在还剩多少生活费；

根据这些因素，以及这些因素对你的影响程度，即优先级，你可以自己估算出一个或几个可能的架构方案。而这种架构的选择，直接影响到你之后的行为，也影响到行为的结果。

开发软件和买票回家又能有什么区别呢？一样要考虑成本、结果、时间。所不同的只是复杂了：需要专业技能，有很多不确定的因素。

那么我这里谈论架构的问题，和需求有什么关系呢？在上面的例子中，大家可以看到架构是根据什么决定的？是因素。因素的本质是什么？就是需求。因素，就是需求。所以，需求决定架构。上一篇中，我谈到说，在进行细节需求之前，一定要定出架构。当然，这时的架构可能只是一张草图。为什么？因为我们已经进行了业务建模，对项目有了一定的认识，对用户的需求也有一定的把握，成本、范围、时间等要素也都清楚了（如果你还不了解这些，请你回到业务建模阶段，你的工作还没有结束）。这个时候，决定架构的因素已经形成了，可以进行架构的设计了。

需求能够决定架构，架构反过来也能够影响需求。最明显的一个例子就是用户界面的设计。虽然用户界面主要来自于需求，但是不同的架构对用户界面也会有影响，例如基于浏览器的客户端，和基于Windows界面客户端能够提供的界面就不同。

在XP中，这种的架构设计，被称为Architecture Spike。为什么叫做Spike呢？就是说你需要专研，解决一些主要的问题，但你并不是提供一个完整的解决方案。例如，在项目的初期，如果你对新近的服务器和操作系统不了解，你肯定会花时间去了解，去试用，去测试；如果对数据库不了解，你也肯定会试着使用看看。这种行为，就是Spike。所以呢，架构的设计只是很初步的设计，而不是一个完善、定型了的设计。这一点要注意。

架构的选择和开发人员的经验和能力非常有关系。一般来说，它需要开发人员具有相关的经验。提供架构的厂商多如牛毛，如何选择，也是一项学问。比如，数据仓库的平台，选择的品种就很多；而Web Server的选择也是五花八门；操作系统也是一样。这些又都是和架构息息相关的。

3、模式

武功有招式，下棋有棋谱。不论是招式，还是棋谱，都是针对某一种问题的特定解决方案。在软件开发领域，这种解决方案就被称为模式。

"每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心，这样，你就能一次又一次的使用该方案而不必做重复的劳动"[AIS，77]

这句话源自模式的鼻祖――Christopher Alexander。而在软件开发领域，最值得一提的著作，就是GoF写的『设计模式』一书。在该书中，作者描述了23种的设计模式，可以说，这些模式奠定了面向对象设计的基础。而另一本值得阅读的著作，就是Martin Fowler所著的『分析模式』。

在软件设计中，我们遇到各种各样的问题，我们可能缺乏经验，或能力有限。这非常的正常。但是现实是，我们生产出的代码由于设计方面的缺陷，往往不够清晰，容易出错，难以扩展。相信只要是开发过软件的人，都遇到过这种问题。于是，我们就希望能够看看其他人，是如何处理这种问题的。这里的"其他人"指的可能是技术专家，也可能是经历过同种问题的人，他们对你遇到的问题有能力，有经验来解决。他们提出的解决方案往往是非常成熟的，能够解决你目前遇到的问题，也能够解决你目前尚未遇到的问题。

这对你的吸引力是很大的。那么，我们谈论模式，模式来源于何处呢。注意，模式是针对某一类的问题的解。这里的问题，所指的就是需求。比如说，客户希望能够在软件中实现不同的税率计算方法，那么，我们很自然的就可以想到Strategy模式；当客户的产品有一个很复杂的单位换算机制的之后，我们也能够很自然的想到Quantity模式。使用模式，能够使我们迅速的把握需求的解决方法。另一方面，模式往往告诉我们比目前的问题更多的方面，因为模式都是大家的经验沉淀。如上所说，它还可以解决你目前没有遇到的问题。因此，我们还可以从模式中发现出更深的需求。

另外一点也很重要，虽然它和需求的关系不大。模式往往都有一个模式名称。这就形成了一种沟通的语言。比如我们在下象棋的时候，只要说"马后炮"，谁都知道这是什么意思，绝对不需要呢详细的解说每一步棋子的走法。对于软件开发也是一样的。我和我的同伴会心的一笑，说："Factory Method。"两个人都能够理解这是什么意思，因为这是一种共通的语言，它代表了背后隐藏的各种类的关系和代码实现。这在软件开发中非常的重要。当然，这有个前提，大家都对模式有一个通透的了解。

4、简单设计

模式属于设计的一环，所以前面我们讨论的其实就是设计和需求的关系。这一小节我们还是讨论这个话题。但是侧重点有所不同。XP中有一个原则：KISS。不是kiss哦。它是Keep it simple and stupid的缩写。除了XP，其它的敏捷方法都提倡简单设计，反对过分设计（over build）。也就是说，针对目前的需求，设计目前的软件。

很多的软件人员都是完美主义者，他们喜欢完美的设计，然后把这种设计提供给用户。这种思想就是过分设计的开始。不必要的功能浪费了客户的投资。我们在做需求的时候，很经常发现开发人员随意的向客户推销一些新功能，或是在设计时，过多的考虑未来可能出现的需求变动。

所以，简单设计的意思，就是要针对目前客户提出的需求进行设计，不要过多的考虑目前没有提到的功能。

5、如何统一

细心的读者看到这里可能已经是疑窦丛生了。一边是鼓励使用、设计最完美的方案；另一方面，又强调简单。似乎是自我矛盾。不错这其中是由矛盾的地方，但也有一致的地方。因此，在使用先进的模式和保持设计的简单性之间，我们需要权衡。

一次，我们看到了一个关于权限设置的模式，我们觉得这个模式非常的好，它提供了类似于UNIX操作系统那样的权限控制，可以很随意的增加组、用户，并能够在文件级别上设置权限。我们如获至宝，觉得这是一个非常有用的模式。于是，我们花了一些时间将之实现，并打算应用于新的软件中。

在实际中，我们发现没有一个用户需要如此强大的功能，他们所需要的可能仅是密码控制，或是简单的用户管理。如此复杂的功能对他们来说没有任何的意义。完美的模式在现实中遭到了冷遇。

实际上，用户目前不需要这项功能，并不意味着他以后不需要这项功能。用户的计算机程度提高的很快，我们估计，再过那么一两年，用户可能就非常需要这项功能来管理他那日益庞大的员工队伍了。但是目前，这项功能对用户来说，设置复杂，所以他们并不愿意接受这个"有价值"的功能。

最后，我们想到了一个解决的办法，我们为这一项功能定义了一个通用的接口。通过这个接口，你可以实现复杂的功能，也可以实现简单的功能。总之，你只要是实现了接口的方法就行了。接口的方法很多，但是在目前的简单的实现中，可能就仅仅是一个返回语句，并没有很多的实现。相应的，用户的也仅仅需要使用简单的方法，诸如addUser()，updatePasswd()等。界面也做了简化的处理。

通过这种方法，我们可以在用户需要的时候，替换掉权限模块，对其它的应用并不影响。当然，其中有很多的细节需要注意。在完成之后，我们还发现了另一个副产品：整个的权限控制模块是高内聚，低耦合的。

模式，就好比螺帽的设计图纸，它规定了螺帽的技术规格，但是没有规定具体的尺寸。对应于不同的需要，我们可以设计出不同大小的螺帽以供使用。图纸只需要一份就可以了，并不需要为每一种尺寸的螺帽画一张图纸。

因此呢，一个经历了实践检验的模式，往往功能强大。但是它可以有多种不同的实现。有哪一条法律规定你必须完全的实现一种模式呢。在实际使用中，你需要权衡模式使用的成本和效益。你会发现，在很多情况下，你还是实现了模式，但只是模式的一个框架，或一部分，但是这在目前就够用了。而当需求变动，或新的需求出现的时候，你可以很方便的在原有搭起的框架上添砖加瓦。一切都是那么的自然。比如，在一个进销存的软件中，存在一个运输选择算法，目前的运输途径就一种，但是很有可能会增加新的途径。这时候，你就决定采用Strategy模式。但是你只是实现了一个简单的框架，只有一个具体子类，来实现目前的算法。当新的运输途径出现时，你需要增加一个算法，你就可以再增加一个子类，只要实现的接口相同，改动是不会影响到系统其它的部分的。

6、测试

测试是非常重要的，是软件成败的关键。但是目前国内对测试并不关注，或是假装关注。这样就无法保证软件的质量。测试有很多种，我们这里要说的是和需求息息相关的测试，就是接收测试（Acceptance Test）（关于这个词，可能不同的文章会有不同的译法）。

Surely you aren't going to assume you're getting what you need. Prove that it works! Acceptance tests allow the customer to know when the system works, and tell the programmers what needs to be done.

上面这段话摘自『XPInstalled』。接收测试有两个作用：首先是让客户明白系统能够做什么，然后是让程序员明白该让系统做些什么。

有一种测试的方法是把测试留到最后才做，让客户去发现错误。千万别这么做。原先花费1块钱就可以改正的错误，到了这个时候，可能需要花费1000块钱才能解决。这是软件开发的放大效应。因为很多的工作已经基于这个错误建立了，开发人员也已经对这个错误没有映像了。

XP中有一个很重要的价值，叫做反馈（Feedback）。Kent Beck在Extreme Programming Explained中有句话讲得非常好："乐观是编程的职业病，反馈则是其处方。"从需求的识别，到根据需求构建的系统交付给客户，客户提出意见。这就是一个反馈过程。反馈过程所花费的时间越少越好。接受测试就是解决客户反馈的一个有效的手段。客户编写可重复的测试脚本，开发人员开发出的软件要经受这个测试脚本的考验。这种的反馈速度是很高的，能够有效的解决反馈的问题。

因此，客户在要求实现需求时，同时也有义务提供相关的接收测试：

if it's worth having the programmers build it, it's worth knowing that they got it right.

一个有价值的功能一定是可测试的，如果不是，那么这个功能要么是没有价值，要么是尚未描述清楚。

要注意，这个测试必须是可重复的。这是因为需求的易变性。需求在不断变化，这就意味着代码在不断的变化。因此，原先已经用接收测试证明过了的代码还需要再次证明。这就要求测试是可以重复的。

大量的测试，甚至重复的测试引出了一个新的问题：全凭手工进行测试会浪费大量的时间。因此，易变的需求对测试提出了一个新的要求：自动化测试。只有自动化的进行测试，才可以完成如此大量的测试工作。目前，最好的自动化测试工具，应该就是Xunit系列。关于这方面的问题，大家可以参考相关的资料，这里我们不作深入的讨论。

接收测试最可能的一种形式就是自然语言的说明，外带一组的测试数据。需要强调的一点是，这个测试数据一定要包括输入和输出。这样才可以做出比较。如果只有输入没有输出。测试很可能就是白费劲。所以，计算这个输出是手工计算的，它也是必要的。

除了接收测试，还有一个很重要的概念就是单元测试（Unit Test）。但是单元测试和设计的关系比较大，和需求没有过多的关系，我们这里就只是点一下。大家如有兴趣，可以参考相关的资料。

7、分解

对于需求来说，需要用到的最多的技能可能就是分解的技能了。可以说软件科学最重要的思想就是"分而治之"的思想。不是吗？面向对象是不是一种分解的思想。类、组件、包，这种层级结构不正是体现了"分而治之"吗？当然我这里可能把包和组件弄混淆了。但我的主要目的是要指出这种分解的方法在软件开发中是无处不在的。对于需求也是一样。我们最早做的业务建模就是为了得到一个系统的概貌图。然后到了细节需求阶段，我们会把这张图放大，细分，一直到我们有把握处理为止。

如何把100块砖累起来呢？如果一块一块的累，那很容易就倒了。一种比较好的做法，就是先10块10块的打包，这样，100块砖就变成了10个砖包，再把它们累起来就容易的多了。面向对象其实就是这么做的，当然，面向对象的实现比累砖要难多了。

我们看看XP中是如何处理分解的。XP中最大的周期叫做发布版（release），一个发布版需要一个月或几个月的时间，一般不超过6个月。发布版的末期，需要向客户提供一个可以运行的软件的发布版。然后，XP还定义了次级的周期，称为迭代（iteration），一次的迭代大概需要一周或几周的时间。每一次的迭代都是一个"伪发布版"（pretend release），就是说，迭代的最后也必需要提供一个可以工作的软件，这个软件随时都可以发布。为了定义一次迭代中要处理的事情，XP还定义了素材（story），一份素材代表了客户希望在软件中出现的一项功能（feature），一份素材是很小的，它只需要花费一个开发人员几天或几周的时间。素材已经很小了，但是还需要细分到任务（task），一项任务只需要1到4天的工作量。这并不是最小的单位，XP还把任务划分到测试（test），但这已经到个人级别上了。

我们看到，XP从客户到每一个开发人员，定义了5级的单位，并把时间精确到了天、小时。所以我有时候听人说，XP好像对开发人员的要求不严格。错了，XP可以说是目前要求最为严格的方法，这种分类方法可见一斑。这种分类有什么好处呢？

首先，我们来看发布版，发布版的最短时间是一个月，也就是说，最频繁是一个月向客户交付一次软件。这样，就在很大程度上保证了反馈的迅速进行。避免了传统的开发方法中最后客户发现问题时已经太迟了的现象。

再看迭代，迭代之所以被称为伪发布版，就是因为它的产出物的性质和发布版是一样的。都是可以交付的产品，但是迭代的功能比较少，没有必要交付给客户。我们知道，在传统的软件开发中，整合是一个大问题。整合必然会出现问题，但是没人知道问题在哪儿。所以呢，XP通过不间断的整合，避免了这个问题。

但是，迭代的周期如此之短，能够做些什么呢。这就是素材出现的原因。素材由客户提出，由客户决定优先级，由客户决定放在哪一次的发布版和迭代中。同时，如上面我们谈到的，客户需要为素材制定接收测试。

一份素材的周期是几天或几周，而一次迭代的时间也就几周。这说明素材对迭代而言，单位过大了。所以要把素材再次分解为任务。每一个任务都需要一个开发人员认领，签字。在分解素材的过程中，我们可以发现有一些任务是多个素材共享的，这个概念和用例中的使用的概念是一致的。开发人员会估计自己的任务所需要的时间。从而得出一个迭代周期的总时间。这个时间的估计是基于以往的经验的，因此随着项目的进行，这个估计往往会越发的准确。

我们这里讲XP的分解哲学，并不是要求大家也依样画葫芦，你真要那样做也不行。因为XP的各项实践都是一体的，只有实现了所有的实践，才能体现其威力。我们这样断章取义是行不通的。但是其中的思想我们是可以借用的。分解、归类、排序、估计。这种分析问题的方法，也是我们值得借鉴的。这里有几点要注意：

最早的分解依据往往是客户要求的时间。例如，客户希望在3个月内看到什么什么。在客户和开发放商议之后，决定制定两次的发布版。这个决定虽然开发方可以提供参考意见，但是决定权在客户方；

素材的提出，素材的优先级，素材的安排，这些都是客户的权利。客户也有权利取消、增加、修改素材，或是改变其优先级；

客户投入多少，就能够看到多少的软件。客户也可以取消目前的项目，而且，先前的投资也会有相应部分的软件产出；

对于开发时间的估计是开发人员的权力，其它任何强加于开发人员的时间安排都是不对的；

任务的选择也是出于开发人员自愿的原则；

如果开发人员估计出的总的时间和迭代的预计的时间有出入，绝对不能牺牲开发人员的额外时间换取迭代在限定时间内完成。这种做法无异于饮鸩止渴。比较好的做法是去掉一些任务。

8、客户如何参与

这是一个纯粹的补充问题。一次，一位读者写信来问我，中国的客户素质比较低，对计算机不了解，XP强调的现场客户现实中根本做不到。

XP要求开发人员在开发软件的过程中随时予以支持。诚然，要做到这一点是很难的。我自己也遇到过这种难题，知道问题的棘手程度。我想，这个问题可以分为两个方面。

一种是定制的软件。对于这种项目，你需要解决用户的参与问题，往往客户方的老总愿意投入资金，但是却不愿意投入支持的人力。我也曾见过客户方专门招了一个应届生来对付需求的情况。遇到这种情况，如果你没有能力克服它，那么这个项目绝对是失败的。即便项目最后成功了，申请了什么"重大攻关"之类的奖项，你我都很清楚，这只不过是表面功夫而已。造成这种问题的原因有很多，你需要分析它们，列举出最深层的原因，并且保证列出的这些原因之间并不会相互影响。然后再试着来解决它。一般而言，如果客户方是真正愿意实现这个软件的话，事情并不是不可解决的。

另一种是产品化的软件。我们可以把这种软件的客户分为三类：市场人员、领域专家、最终用户。市场人员往往对软件有最初的认识，但是这种认识往往不够深入。所以，在开发产品化的软件时，一定要配备专门的市场人员，他们对客户的需求最了解，是需求的第一手来源。既然你的老板想要开发这个软件，说明对软件的未来市场有期待，市场人员加入的要求应该是可以得到满足的。其次是领域专家，现在很多的软件公司都配备有领域专家，他们的作用可不小，和市场人员相比，他们也同样熟悉需求，因为他们自己就是资深的用户，并且他们还熟悉理论，能够为软件开发出大力气。最后是最终用户，前面的两类人的参与还不够，如果最终用户不认可软件，那还是没有用。所以，要求市场人员找寻可能的目标客户，试用软件，提出意见，是非常重要的。我们常说的Beta测试也就是这样做的。

9、结语

最早这片文章的想法是来自于一个信贷系统（以文章的观点来看，这个系统是一个失败的案例）。除此之外，还加上了一些以前的项目的经验，以及朋友的一些经验。最后综合成了这一篇文章。

这个系列的文章的写作时间的跨度很长。在这个期间，我的思想也经历一个很大的转变，所以在写作中也出现过对已经完稿的部分大肆删修的情况。这篇文章虽名为『需求的实践』，但所提到的各种想法、方法，都有理论的依据。当然也是参考了很多的资料。而我个人的能力又极为有限，所以有些时候是心有余而力不足。在这样的情形下，文章难免会出现很多的错误。还希望能得到读者们的谅解和指正。

在写作的过程中，也有很多的热心人写来信件，其中好些还成为了好朋友。曾经想把里面的问题整理出来，但是由于疏忽，其中的一部分已经找不到了。希望还能有机会做这件事情。

参考资料：

Karl Wieger:《Software Requirements》

Scott W. Ambler: AgileModeling: http://www.agilemodeling.com

Scott W. Ambler: The Object Primer 2nd Edition

Jacobson, I., Booch, G., and Rumbaugh, J. (1999). The Unified Software Development Process

GOF:《Design Patterns: Elements of Reusable Object Oriented Software》

Eric Gamma, Kent Beck: Junit: http://www.junit.org

Kent Beck，Martin Fowler:《Planning Extreme Programming》

作者简介：

林星，辰讯软件工作室项目管理组资深项目经理，有多年项目实施经验。辰讯软件工作室致力于先进软件思想、软件技术的应用，主要的研究方向在于软件过程思想、Linux集群技术、OO技术和软件工厂模式。您可以通过电子邮件 iamlinx@21cn.com 和他联系。

如果想了解更多相关内容请访问:

http://51cmm.csai.cn/Requirement/No025.htm

--------------------------------------------------------------------------------

作者：金芝　来源：计算机世界　http://www.csai.cn

　　需求工程无疑是当前软件工程中的关键问题，从美国于1995年开始的一项调查结果就足以看出这一点。在这项调查中，他们对全国范围内的8000个软件项目进行跟踪调查，结果表明，有1/3的项目没能完成，而在完成的2/3的项目中，又有1/2的项目没有成功实施。他们仔细分析失败的原因后发现，与需求过程相关的原因占了45%，而其中缺乏最终用户的参与以及不完整的需求又是两大首要原因，各占13%和12%。

　　需求工程又是软件工程中最复杂的过程之一，其复杂性来自于客观和主观两个方面。从客观意义上说，需求工程面对的问题几乎是没有范围的。由于应用领域的广泛性，它的实施无疑与各个应用行业的特征密切相关。其客观上的难度还体现在非功能性需求及其与功能性需求的错综复杂的联系上，当前对非功能性需求分析建模技术的缺乏大大增加了需求工程的复杂性。从主观意义上说，需求工程需要方方面面人员的参与（如领域专家、领域用户、系统投资人、系统分析员、需求分析员等等），各方面人员有不同的着眼点和不同的知识背景，沟通上的困难给需求工程的实施增加了人为的难度。

　　最初，需求工程仅仅是软件工程的一个组成部分，是软件生命周期的第一个阶段。虽然大家也都知道需求工程对软件整个生命周期的重要性，但对它的研究远远没有对软件工程的其他部分的研究那么深入。

　　在传统软件工程生命周期中，涉及需求的阶段称作需求分析。一般来说，需求分析的作用是：

　　● 系统工程师说明软件的功能和性能，指明软件和其他系统成分的接口，并定义软件必须满足的约束；

　　● 软件工程师求精软件的配置，建立数据模型、功能模型和行为模型；

　　● 为软件设计者提供可用于转换为数据设计、体系结构设计、界面设计和过程设计的模型；

　　● 提供开发人员和客户需求规格说明，用于作为评估软件质量的依据。

　　但从当前的研究现状来看，需求工程的内容远不止这些。需求工程是系统工程和软件工程的一个交叉分支，涉及到软件系统的目标、软件系统提供的服务、软件系统的约束和软件系统运行的环境。它还涉及这些因素和系统的精确规格说明以及系统进化之间的关系。它也提供现实需要和软件能力之间的桥梁。 　　需求工程的基本活动包括：

　　● 抽取需求；

　　● 模拟和分析需求；

　　● 传递需求；

　　● 认可需求；

　　● 进化需求。

　　每个活动都有它基本的动机、任务和结果，也有各自的困难所在。

　　首先，开始一个项目是因为要对现行系统进行改造。要改造一个系统是因为现行系统存在需要解决的问题。如：现行系统与当前情况不符合、出现新的商机或者可能节省时间、资金和资源等，这就是抽取需求的动机。在这个阶段，需求工程师的任务是认识问题之所在，获取足够多的知识，最后成为问题领域的专家。需求工程师常采用W6H方法去认识问题领域，即6个以W打头的问题，一个以H打头的问题，如表1所示。

　　需求抽取是非常困难的，其主要原因有：

　　● 缺乏领域知识，应用领域的问题常常是模糊的、不精确的；

　　● 存在多个知识源，而且多知识源之间可能有冲突；

　　● 存在多个知识源，而且多知识源之间可能有冲突；

　　● 面对的客户可能有偏见，如不能提供你需要了解什么或不想告知你需要了解的事情。

　　需求抽取的方法一般有问卷法、面谈法、数据采集法、用况法、情景实例法以及基于目标的方法等，还有知识工程方法，如：场记分析法、卡片分类法、分类表格技术和基于模型的知识获取等。

　　需求工程的第二个阶段是模拟和分析需求，目前有许多工作都以此为目标进行。需求分析和模拟的出发点在于：

　　● 指导抽取；

　　● 帮助需求工程师了解进展；

　　● 帮助发现问题；

　　● 帮助检查对问题的理解。

　　需求分析和模拟又包含三个层次的工作。首先是需求建模。需求模型的表现形式有自然语言、半形式化（如图、表、结构化英语等）和形式化表示等三种。自然语言形式具有表达能力强的特点，但它不利于捕获模型的语义，一般只用于需求抽取或标记模型。半形式化表示可以捕获结构和一定的语义，也可以实施一定的推理和一致性检查。形式化表示具有精确的语义和推理能力，但要构造一个完整的形式化模型，需要较长时间和对问题领域的深层次理解。对需求概念模型的要求包括：

　　● 实现的独立性:不模拟数据的表示和内部组织等；

　　● 足够抽象：只抽取关于问题的本质方面；

　　● 足够形式化：语法无二义性，并具有丰富的语义；

　　● 可构造性：简单的模型块，能应付不同复杂程度和规模的描述；

　　● 利于分析：能支持二义性、不完整性和不一致性分析；

　　● 可追踪性:支持横向交叉索引并能与设计或实现等建立关联；

　　● 可执行性：可以动态模拟，利于与现实相比较；

　　● 最小性：没有冗余的概念。

　　需求模拟技术又分为企业模拟、功能需求模拟和非功能需求模拟等。

　　企业模拟是一种软系统方法，涉及整个组织，从各个不同的视点分析问题，包括目标、组织结构、活动、过程等。有的企业模拟还建立可执行的领域模型。采用企业模拟方法产生的不仅仅是规格说明，还可以得到许多关于企业运作的状况分析。目前代表性的工作包括：信息模拟、组织模拟和目标模拟等。

　　功能需求模拟从不同视点为模拟软件提供服务，包括结构视点和行为视点等，主要方法有：结构化分析、面向对象分析和形式化方法。结构化分析是一种面向数据的方法，以数据流为中心。其核心概念包括：进程、数据流、数据存储、外部实体、数据组和数据元素。有代表性的模拟工具有：数据流图、数据字典、原始进程规格说明。面向对象分析以对象及其服务作为建模标准，比较自然，对象也具有相对的稳定性。主要模拟的元素有：对象、类、属性、关系、方法、消息传递、Use Cases等。其主要原理包括分类继承层次、信息隐藏、汇集关系等。形式化方法从广义上说，是应用离散数学的手段来设计、模拟和分析，得到像数学公式那样精确的表示。从狭义上说，就是使用一种形式语言进行语言公式的形式推理，用于检查语法的良构性并证明某些属性。形式化方法一般用于一致性检查、类型检查、有效性验证、行为预测以及设计求精验证。引入形式化机制的目的是： 　　● 减少二义性，提高精确性；

　　● 为验证打下基础；

　　● 允许对需求进行推理；

　　● 允许执行需求。

　　但是人们常常不用形式化手段，因为：

　　● 形式化涉及太多细节，分析的级别较低；

　　● 形式化的核心问题是一致性和完整性，而不是获取需求；

　　● 没有合适的工具；

　　● 要求更多的代价。

　　传递需求的主要任务是书写软件需求规格说明，其目的是：

　　● 传达对需求的理解；

　　● 作为软件开发项目的一份契约；

　　● 作为评价后续工作的基线；

　　● 作为控制需求进化的基线。

　　对需求规格说明感兴趣的群体包括：用户、客户；系统分析员、需求分析员；软件开发者、程序员；测试员；项目管理者。

　　认可需求就是让上述人员对需求规格说明达成一致，其主要任务是冲突求解，包括定义冲突和冲突求解两方面。常用的冲突求解方法有：协商、竞争、仲裁、强制、教育等，其中有些只能用人的因素去控制。

　　进化需求的必要性是明显的，因为客户的需要总是不断（连续）增长的，但是一般的软件开发又总是落后于客户需求的增长，如何管理需求的进化（变化）就成为软件进化的首要问题。对传统的变化管理过程来说，其基本成分包括软件配置、软件基线和变化审查小组。当前的发展是软件家族法，即产品线方法。多视点方法也是管理需求变化的一种新方法，它可以用于管理不一致性并进行关于变化的推理。

如果想了解更多相关内容请访问:

http://51cmm.csai.cn/Requirement/No017.htm

如果想了解更多相关内容请访问:

http://51cmm.csai.cn/Requirement/No023.htm

需求的实践（5）

细节需求时期

--------------------------------------------------------------------------------

来自：IBM China 作者：林星 [2003/04/02]

和业务建模时期不同的是，我不再花费笔墨讨论需求要如何做，因为做法、注意点和业务建模时期并没有什么太大的区别。而在完整的流程上，像RUP、XP之类的方法学可比我讲的要好的多。因此，我会把焦点集中在我在实际工作中的一些困惑，以及一些思考。

1、"和其它阶段的关系"的再思考

上一篇的末尾我们简单的讨论了细节需求阶段和其它阶段的关系。对于软件过程的各个阶段，不同之处只是注重的焦点不同而已。在业务建模阶段，我们关注于系统的整体需求；在细节需求阶段，我们更关注于需求的细节部分。其它的阶段也是一样，架构阶段，所关注的当然是如何设计出一个合适的架构；到了设计阶段，注意力就转移到了如何设计方面。 当然，焦点的不同，导致了各个阶段所需要的技能和工具也不尽相同。业务建模阶段需要你有整体的把握能力，你可以使用简单的用例图，基本的用户素材等工具。细节需求阶段则要求你能够充分的挖掘需求和进行良好的沟通。相应的，在架构、分析、设计等阶段，也会有不同的需要。

各个阶段的实质就是注重点的不同，这对于大多数的软件开发而言都是一样的。不论你采用的过程是传统的，还是迭代的。

2、架构

Martin Fowler在他的ISA中写到：

I'm using architecture to mean the important design decisions, the ones that shape most aspects of a software system. These are often the harder decisions to change later on in the project (although often not as hard as people think). As a result these are ones where it's useful to start in the right direction, and thus knowing about architecture is a valuable skill for any software developer.

架构并不神秘，无非是一个决策而已，只是这项决策对软件特别重要就是了。软件开发人员可能根本没有主动的进行架构设计，但是他的行为，已经潜移默化的进行了；而还有一些人，总在谈论着架构，但是并不了解这个词的含义。

春运就要到了，学生也要赶着回家。如何选择回家的交通工具就是一个重要的决策。路程的远近、不同交通工具的价格都是显式的，比较容易知道的。而以往的经验也告诉你，火车票比较便宜，但是比较紧张，花费时间较长，整个过程也不舒服；飞机票比较贵，但是容易买到，花费时间少，整个过程很舒服。这时候你就要做出正确的决策，为回家选择一个正确的架构。你可能考虑的因素有哪一些？以下就列出了一些可能的因素：

拥挤程度，大家都知道春运时那种情况；

购买票的难易程度，火车票需要很早就要预定了；

是否有额外的渠道，比如你能够买到飞机的学生票；

经济实力，经过了一个学期的花销之后，现在还剩多少生活费；

根据这些因素，以及这些因素对你的影响程度，即优先级，你可以自己估算出一个或几个可能的架构方案。而这种架构的选择，直接影响到你之后的行为，也影响到行为的结果。

开发软件和买票回家又能有什么区别呢？一样要考虑成本、结果、时间。所不同的只是复杂了：需要专业技能，有很多不确定的因素。

那么我这里谈论架构的问题，和需求有什么关系呢？在上面的例子中，大家可以看到架构是根据什么决定的？是因素。因素的本质是什么？就是需求。因素，就是需求。所以，需求决定架构。上一篇中，我谈到说，在进行细节需求之前，一定要定出架构。当然，这时的架构可能只是一张草图。为什么？因为我们已经进行了业务建模，对项目有了一定的认识，对用户的需求也有一定的把握，成本、范围、时间等要素也都清楚了（如果你还不了解这些，请你回到业务建模阶段，你的工作还没有结束）。这个时候，决定架构的因素已经形成了，可以进行架构的设计了。

需求能够决定架构，架构反过来也能够影响需求。最明显的一个例子就是用户界面的设计。虽然用户界面主要来自于需求，但是不同的架构对用户界面也会有影响，例如基于浏览器的客户端，和基于Windows界面客户端能够提供的界面就不同。

在XP中，这种的架构设计，被称为Architecture Spike。为什么叫做Spike呢？就是说你需要专研，解决一些主要的问题，但你并不是提供一个完整的解决方案。例如，在项目的初期，如果你对新近的服务器和操作系统不了解，你肯定会花时间去了解，去试用，去测试；如果对数据库不了解，你也肯定会试着使用看看。这种行为，就是Spike。所以呢，架构的设计只是很初步的设计，而不是一个完善、定型了的设计。这一点要注意。

架构的选择和开发人员的经验和能力非常有关系。一般来说，它需要开发人员具有相关的经验。提供架构的厂商多如牛毛，如何选择，也是一项学问。比如，数据仓库的平台，选择的品种就很多；而Web Server的选择也是五花八门；操作系统也是一样。这些又都是和架构息息相关的。

3、模式

武功有招式，下棋有棋谱。不论是招式，还是棋谱，都是针对某一种问题的特定解决方案。在软件开发领域，这种解决方案就被称为模式。

"每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心，这样，你就能一次又一次的使用该方案而不必做重复的劳动"[AIS，77]

这句话源自模式的鼻祖――Christopher Alexander。而在软件开发领域，最值得一提的著作，就是GoF写的『设计模式』一书。在该书中，作者描述了23种的设计模式，可以说，这些模式奠定了面向对象设计的基础。而另一本值得阅读的著作，就是Martin Fowler所著的『分析模式』。

在软件设计中，我们遇到各种各样的问题，我们可能缺乏经验，或能力有限。这非常的正常。但是现实是，我们生产出的代码由于设计方面的缺陷，往往不够清晰，容易出错，难以扩展。相信只要是开发过软件的人，都遇到过这种问题。于是，我们就希望能够看看其他人，是如何处理这种问题的。这里的"其他人"指的可能是技术专家，也可能是经历过同种问题的人，他们对你遇到的问题有能力，有经验来解决。他们提出的解决方案往往是非常成熟的，能够解决你目前遇到的问题，也能够解决你目前尚未遇到的问题。

这对你的吸引力是很大的。那么，我们谈论模式，模式来源于何处呢。注意，模式是针对某一类的问题的解。这里的问题，所指的就是需求。比如说，客户希望能够在软件中实现不同的税率计算方法，那么，我们很自然的就可以想到Strategy模式；当客户的产品有一个很复杂的单位换算机制的之后，我们也能够很自然的想到Quantity模式。使用模式，能够使我们迅速的把握需求的解决方法。另一方面，模式往往告诉我们比目前的问题更多的方面，因为模式都是大家的经验沉淀。如上所说，它还可以解决你目前没有遇到的问题。因此，我们还可以从模式中发现出更深的需求。

另外一点也很重要，虽然它和需求的关系不大。模式往往都有一个模式名称。这就形成了一种沟通的语言。比如我们在下象棋的时候，只要说"马后炮"，谁都知道这是什么意思，绝对不需要呢详细的解说每一步棋子的走法。对于软件开发也是一样的。我和我的同伴会心的一笑，说："Factory Method。"两个人都能够理解这是什么意思，因为这是一种共通的语言，它代表了背后隐藏的各种类的关系和代码实现。这在软件开发中非常的重要。当然，这有个前提，大家都对模式有一个通透的了解。

4、简单设计

模式属于设计的一环，所以前面我们讨论的其实就是设计和需求的关系。这一小节我们还是讨论这个话题。但是侧重点有所不同。XP中有一个原则：KISS。不是kiss哦。它是Keep it simple and stupid的缩写。除了XP，其它的敏捷方法都提倡简单设计，反对过分设计（over build）。也就是说，针对目前的需求，设计目前的软件。

很多的软件人员都是完美主义者，他们喜欢完美的设计，然后把这种设计提供给用户。这种思想就是过分设计的开始。不必要的功能浪费了客户的投资。我们在做需求的时候，很经常发现开发人员随意的向客户推销一些新功能，或是在设计时，过多的考虑未来可能出现的需求变动。

所以，简单设计的意思，就是要针对目前客户提出的需求进行设计，不要过多的考虑目前没有提到的功能。

5、如何统一

细心的读者看到这里可能已经是疑窦丛生了。一边是鼓励使用、设计最完美的方案；另一方面，又强调简单。似乎是自我矛盾。不错这其中是由矛盾的地方，但也有一致的地方。因此，在使用先进的模式和保持设计的简单性之间，我们需要权衡。

一次，我们看到了一个关于权限设置的模式，我们觉得这个模式非常的好，它提供了类似于UNIX操作系统那样的权限控制，可以很随意的增加组、用户，并能够在文件级别上设置权限。我们如获至宝，觉得这是一个非常有用的模式。于是，我们花了一些时间将之实现，并打算应用于新的软件中。

在实际中，我们发现没有一个用户需要如此强大的功能，他们所需要的可能仅是密码控制，或是简单的用户管理。如此复杂的功能对他们来说没有任何的意义。完美的模式在现实中遭到了冷遇。

实际上，用户目前不需要这项功能，并不意味着他以后不需要这项功能。用户的计算机程度提高的很快，我们估计，再过那么一两年，用户可能就非常需要这项功能来管理他那日益庞大的员工队伍了。但是目前，这项功能对用户来说，设置复杂，所以他们并不愿意接受这个"有价值"的功能。

最后，我们想到了一个解决的办法，我们为这一项功能定义了一个通用的接口。通过这个接口，你可以实现复杂的功能，也可以实现简单的功能。总之，你只要是实现了接口的方法就行了。接口的方法很多，但是在目前的简单的实现中，可能就仅仅是一个返回语句，并没有很多的实现。相应的，用户的也仅仅需要使用简单的方法，诸如addUser()，updatePasswd()等。界面也做了简化的处理。

通过这种方法，我们可以在用户需要的时候，替换掉权限模块，对其它的应用并不影响。当然，其中有很多的细节需要注意。在完成之后，我们还发现了另一个副产品：整个的权限控制模块是高内聚，低耦合的。

模式，就好比螺帽的设计图纸，它规定了螺帽的技术规格，但是没有规定具体的尺寸。对应于不同的需要，我们可以设计出不同大小的螺帽以供使用。图纸只需要一份就可以了，并不需要为每一种尺寸的螺帽画一张图纸。

因此呢，一个经历了实践检验的模式，往往功能强大。但是它可以有多种不同的实现。有哪一条法律规定你必须完全的实现一种模式呢。在实际使用中，你需要权衡模式使用的成本和效益。你会发现，在很多情况下，你还是实现了模式，但只是模式的一个框架，或一部分，但是这在目前就够用了。而当需求变动，或新的需求出现的时候，你可以很方便的在原有搭起的框架上添砖加瓦。一切都是那么的自然。比如，在一个进销存的软件中，存在一个运输选择算法，目前的运输途径就一种，但是很有可能会增加新的途径。这时候，你就决定采用Strategy模式。但是你只是实现了一个简单的框架，只有一个具体子类，来实现目前的算法。当新的运输途径出现时，你需要增加一个算法，你就可以再增加一个子类，只要实现的接口相同，改动是不会影响到系统其它的部分的。

6、测试

测试是非常重要的，是软件成败的关键。但是目前国内对测试并不关注，或是假装关注。这样就无法保证软件的质量。测试有很多种，我们这里要说的是和需求息息相关的测试，就是接收测试（Acceptance Test）（关于这个词，可能不同的文章会有不同的译法）。

Surely you aren't going to assume you're getting what you need. Prove that it works! Acceptance tests allow the customer to know when the system works, and tell the programmers what needs to be done.

上面这段话摘自『XPInstalled』。接收测试有两个作用：首先是让客户明白系统能够做什么，然后是让程序员明白该让系统做些什么。

有一种测试的方法是把测试留到最后才做，让客户去发现错误。千万别这么做。原先花费1块钱就可以改正的错误，到了这个时候，可能需要花费1000块钱才能解决。这是软件开发的放大效应。因为很多的工作已经基于这个错误建立了，开发人员也已经对这个错误没有映像了。

XP中有一个很重要的价值，叫做反馈（Feedback）。Kent Beck在Extreme Programming Explained中有句话讲得非常好："乐观是编程的职业病，反馈则是其处方。"从需求的识别，到根据需求构建的系统交付给客户，客户提出意见。这就是一个反馈过程。反馈过程所花费的时间越少越好。接受测试就是解决客户反馈的一个有效的手段。客户编写可重复的测试脚本，开发人员开发出的软件要经受这个测试脚本的考验。这种的反馈速度是很高的，能够有效的解决反馈的问题。

因此，客户在要求实现需求时，同时也有义务提供相关的接收测试：

if it's worth having the programmers build it, it's worth knowing that they got it right.

一个有价值的功能一定是可测试的，如果不是，那么这个功能要么是没有价值，要么是尚未描述清楚。

要注意，这个测试必须是可重复的。这是因为需求的易变性。需求在不断变化，这就意味着代码在不断的变化。因此，原先已经用接收测试证明过了的代码还需要再次证明。这就要求测试是可以重复的。

大量的测试，甚至重复的测试引出了一个新的问题：全凭手工进行测试会浪费大量的时间。因此，易变的需求对测试提出了一个新的要求：自动化测试。只有自动化的进行测试，才可以完成如此大量的测试工作。目前，最好的自动化测试工具，应该就是Xunit系列。关于这方面的问题，大家可以参考相关的资料，这里我们不作深入的讨论。

接收测试最可能的一种形式就是自然语言的说明，外带一组的测试数据。需要强调的一点是，这个测试数据一定要包括输入和输出。这样才可以做出比较。如果只有输入没有输出。测试很可能就是白费劲。所以，计算这个输出是手工计算的，它也是必要的。

除了接收测试，还有一个很重要的概念就是单元测试（Unit Test）。但是单元测试和设计的关系比较大，和需求没有过多的关系，我们这里就只是点一下。大家如有兴趣，可以参考相关的资料。

7、分解

对于需求来说，需要用到的最多的技能可能就是分解的技能了。可以说软件科学最重要的思想就是"分而治之"的思想。不是吗？面向对象是不是一种分解的思想。类、组件、包，这种层级结构不正是体现了"分而治之"吗？当然我这里可能把包和组件弄混淆了。但我的主要目的是要指出这种分解的方法在软件开发中是无处不在的。对于需求也是一样。我们最早做的业务建模就是为了得到一个系统的概貌图。然后到了细节需求阶段，我们会把这张图放大，细分，一直到我们有把握处理为止。

如何把100块砖累起来呢？如果一块一块的累，那很容易就倒了。一种比较好的做法，就是先10块10块的打包，这样，100块砖就变成了10个砖包，再把它们累起来就容易的多了。面向对象其实就是这么做的，当然，面向对象的实现比累砖要难多了。

我们看看XP中是如何处理分解的。XP中最大的周期叫做发布版（release），一个发布版需要一个月或几个月的时间，一般不超过6个月。发布版的末期，需要向客户提供一个可以运行的软件的发布版。然后，XP还定义了次级的周期，称为迭代（iteration），一次的迭代大概需要一周或几周的时间。每一次的迭代都是一个"伪发布版"（pretend release），就是说，迭代的最后也必需要提供一个可以工作的软件，这个软件随时都可以发布。为了定义一次迭代中要处理的事情，XP还定义了素材（story），一份素材代表了客户希望在软件中出现的一项功能（feature），一份素材是很小的，它只需要花费一个开发人员几天或几周的时间。素材已经很小了，但是还需要细分到任务（task），一项任务只需要1到4天的工作量。这并不是最小的单位，XP还把任务划分到测试（test），但这已经到个人级别上了。

我们看到，XP从客户到每一个开发人员，定义了5级的单位，并把时间精确到了天、小时。所以我有时候听人说，XP好像对开发人员的要求不严格。错了，XP可以说是目前要求最为严格的方法，这种分类方法可见一斑。这种分类有什么好处呢？

首先，我们来看发布版，发布版的最短时间是一个月，也就是说，最频繁是一个月向客户交付一次软件。这样，就在很大程度上保证了反馈的迅速进行。避免了传统的开发方法中最后客户发现问题时已经太迟了的现象。

再看迭代，迭代之所以被称为伪发布版，就是因为它的产出物的性质和发布版是一样的。都是可以交付的产品，但是迭代的功能比较少，没有必要交付给客户。我们知道，在传统的软件开发中，整合是一个大问题。整合必然会出现问题，但是没人知道问题在哪儿。所以呢，XP通过不间断的整合，避免了这个问题。

但是，迭代的周期如此之短，能够做些什么呢。这就是素材出现的原因。素材由客户提出，由客户决定优先级，由客户决定放在哪一次的发布版和迭代中。同时，如上面我们谈到的，客户需要为素材制定接收测试。

一份素材的周期是几天或几周，而一次迭代的时间也就几周。这说明素材对迭代而言，单位过大了。所以要把素材再次分解为任务。每一个任务都需要一个开发人员认领，签字。在分解素材的过程中，我们可以发现有一些任务是多个素材共享的，这个概念和用例中的使用的概念是一致的。开发人员会估计自己的任务所需要的时间。从而得出一个迭代周期的总时间。这个时间的估计是基于以往的经验的，因此随着项目的进行，这个估计往往会越发的准确。

我们这里讲XP的分解哲学，并不是要求大家也依样画葫芦，你真要那样做也不行。因为XP的各项实践都是一体的，只有实现了所有的实践，才能体现其威力。我们这样断章取义是行不通的。但是其中的思想我们是可以借用的。分解、归类、排序、估计。这种分析问题的方法，也是我们值得借鉴的。这里有几点要注意：

最早的分解依据往往是客户要求的时间。例如，客户希望在3个月内看到什么什么。在客户和开发放商议之后，决定制定两次的发布版。这个决定虽然开发方可以提供参考意见，但是决定权在客户方；

素材的提出，素材的优先级，素材的安排，这些都是客户的权利。客户也有权利取消、增加、修改素材，或是改变其优先级；

客户投入多少，就能够看到多少的软件。客户也可以取消目前的项目，而且，先前的投资也会有相应部分的软件产出；

对于开发时间的估计是开发人员的权力，其它任何强加于开发人员的时间安排都是不对的；

任务的选择也是出于开发人员自愿的原则；

如果开发人员估计出的总的时间和迭代的预计的时间有出入，绝对不能牺牲开发人员的额外时间换取迭代在限定时间内完成。这种做法无异于饮鸩止渴。比较好的做法是去掉一些任务。

8、客户如何参与

这是一个纯粹的补充问题。一次，一位读者写信来问我，中国的客户素质比较低，对计算机不了解，XP强调的现场客户现实中根本做不到。

XP要求开发人员在开发软件的过程中随时予以支持。诚然，要做到这一点是很难的。我自己也遇到过这种难题，知道问题的棘手程度。我想，这个问题可以分为两个方面。

一种是定制的软件。对于这种项目，你需要解决用户的参与问题，往往客户方的老总愿意投入资金，但是却不愿意投入支持的人力。我也曾见过客户方专门招了一个应届生来对付需求的情况。遇到这种情况，如果你没有能力克服它，那么这个项目绝对是失败的。即便项目最后成功了，申请了什么"重大攻关"之类的奖项，你我都很清楚，这只不过是表面功夫而已。造成这种问题的原因有很多，你需要分析它们，列举出最深层的原因，并且保证列出的这些原因之间并不会相互影响。然后再试着来解决它。一般而言，如果客户方是真正愿意实现这个软件的话，事情并不是不可解决的。

另一种是产品化的软件。我们可以把这种软件的客户分为三类：市场人员、领域专家、最终用户。市场人员往往对软件有最初的认识，但是这种认识往往不够深入。所以，在开发产品化的软件时，一定要配备专门的市场人员，他们对客户的需求最了解，是需求的第一手来源。既然你的老板想要开发这个软件，说明对软件的未来市场有期待，市场人员加入的要求应该是可以得到满足的。其次是领域专家，现在很多的软件公司都配备有领域专家，他们的作用可不小，和市场人员相比，他们也同样熟悉需求，因为他们自己就是资深的用户，并且他们还熟悉理论，能够为软件开发出大力气。最后是最终用户，前面的两类人的参与还不够，如果最终用户不认可软件，那还是没有用。所以，要求市场人员找寻可能的目标客户，试用软件，提出意见，是非常重要的。我们常说的Beta测试也就是这样做的。

9、结语

最早这片文章的想法是来自于一个信贷系统（以文章的观点来看，这个系统是一个失败的案例）。除此之外，还加上了一些以前的项目的经验，以及朋友的一些经验。最后综合成了这一篇文章。

这个系列的文章的写作时间的跨度很长。在这个期间，我的思想也经历一个很大的转变，所以在写作中也出现过对已经完稿的部分大肆删修的情况。这篇文章虽名为『需求的实践』，但所提到的各种想法、方法，都有理论的依据。当然也是参考了很多的资料。而我个人的能力又极为有限，所以有些时候是心有余而力不足。在这样的情形下，文章难免会出现很多的错误。还希望能得到读者们的谅解和指正。

在写作的过程中，也有很多的热心人写来信件，其中好些还成为了好朋友。曾经想把里面的问题整理出来，但是由于疏忽，其中的一部分已经找不到了。希望还能有机会做这件事情。

参考资料：

Karl Wieger:《Software Requirements》

Scott W. Ambler: AgileModeling: http://www.agilemodeling.com

Scott W. Ambler: The Object Primer 2nd Edition

Jacobson, I., Booch, G., and Rumbaugh, J. (1999). The Unified Software Development Process

GOF:《Design Patterns: Elements of Reusable Object Oriented Software》

Eric Gamma, Kent Beck: Junit: http://www.junit.org

Kent Beck，Martin Fowler:《Planning Extreme Programming》

作者简介：

林星，辰讯软件工作室项目管理组资深项目经理，有多年项目实施经验。辰讯软件工作室致力于先进软件思想、软件技术的应用，主要的研究方向在于软件过程思想、Linux集群技术、OO技术和软件工厂模式。您可以通过电子邮件 iamlinx@21cn.com 和他联系。

如果想了解更多相关内容请访问:

http://51cmm.csai.cn/Requirement/No001.htm

需求的实践（5）

细节需求时期

--------------------------------------------------------------------------------

来自：IBM China 作者：林星 [2003/04/02]

和业务建模时期不同的是，我不再花费笔墨讨论需求要如何做，因为做法、注意点和业务建模时期并没有什么太大的区别。而在完整的流程上，像RUP、XP之类的方法学可比我讲的要好的多。因此，我会把焦点集中在我在实际工作中的一些困惑，以及一些思考。

1、"和其它阶段的关系"的再思考

上一篇的末尾我们简单的讨论了细节需求阶段和其它阶段的关系。对于软件过程的各个阶段，不同之处只是注重的焦点不同而已。在业务建模阶段，我们关注于系统的整体需求；在细节需求阶段，我们更关注于需求的细节部分。其它的阶段也是一样，架构阶段，所关注的当然是如何设计出一个合适的架构；到了设计阶段，注意力就转移到了如何设计方面。 当然，焦点的不同，导致了各个阶段所需要的技能和工具也不尽相同。业务建模阶段需要你有整体的把握能力，你可以使用简单的用例图，基本的用户素材等工具。细节需求阶段则要求你能够充分的挖掘需求和进行良好的沟通。相应的，在架构、分析、设计等阶段，也会有不同的需要。

各个阶段的实质就是注重点的不同，这对于大多数的软件开发而言都是一样的。不论你采用的过程是传统的，还是迭代的。

2、架构

Martin Fowler在他的ISA中写到：

I'm using architecture to mean the important design decisions, the ones that shape most aspects of a software system. These are often the harder decisions to change later on in the project (although often not as hard as people think). As a result these are ones where it's useful to start in the right direction, and thus knowing about architecture is a valuable skill for any software developer.

架构并不神秘，无非是一个决策而已，只是这项决策对软件特别重要就是了。软件开发人员可能根本没有主动的进行架构设计，但是他的行为，已经潜移默化的进行了；而还有一些人，总在谈论着架构，但是并不了解这个词的含义。

春运就要到了，学生也要赶着回家。如何选择回家的交通工具就是一个重要的决策。路程的远近、不同交通工具的价格都是显式的，比较容易知道的。而以往的经验也告诉你，火车票比较便宜，但是比较紧张，花费时间较长，整个过程也不舒服；飞机票比较贵，但是容易买到，花费时间少，整个过程很舒服。这时候你就要做出正确的决策，为回家选择一个正确的架构。你可能考虑的因素有哪一些？以下就列出了一些可能的因素：

拥挤程度，大家都知道春运时那种情况；

购买票的难易程度，火车票需要很早就要预定了；

是否有额外的渠道，比如你能够买到飞机的学生票；

经济实力，经过了一个学期的花销之后，现在还剩多少生活费；

根据这些因素，以及这些因素对你的影响程度，即优先级，你可以自己估算出一个或几个可能的架构方案。而这种架构的选择，直接影响到你之后的行为，也影响到行为的结果。

开发软件和买票回家又能有什么区别呢？一样要考虑成本、结果、时间。所不同的只是复杂了：需要专业技能，有很多不确定的因素。

那么我这里谈论架构的问题，和需求有什么关系呢？在上面的例子中，大家可以看到架构是根据什么决定的？是因素。因素的本质是什么？就是需求。因素，就是需求。所以，需求决定架构。上一篇中，我谈到说，在进行细节需求之前，一定要定出架构。当然，这时的架构可能只是一张草图。为什么？因为我们已经进行了业务建模，对项目有了一定的认识，对用户的需求也有一定的把握，成本、范围、时间等要素也都清楚了（如果你还不了解这些，请你回到业务建模阶段，你的工作还没有结束）。这个时候，决定架构的因素已经形成了，可以进行架构的设计了。

需求能够决定架构，架构反过来也能够影响需求。最明显的一个例子就是用户界面的设计。虽然用户界面主要来自于需求，但是不同的架构对用户界面也会有影响，例如基于浏览器的客户端，和基于Windows界面客户端能够提供的界面就不同。

在XP中，这种的架构设计，被称为Architecture Spike。为什么叫做Spike呢？就是说你需要专研，解决一些主要的问题，但你并不是提供一个完整的解决方案。例如，在项目的初期，如果你对新近的服务器和操作系统不了解，你肯定会花时间去了解，去试用，去测试；如果对数据库不了解，你也肯定会试着使用看看。这种行为，就是Spike。所以呢，架构的设计只是很初步的设计，而不是一个完善、定型了的设计。这一点要注意。

架构的选择和开发人员的经验和能力非常有关系。一般来说，它需要开发人员具有相关的经验。提供架构的厂商多如牛毛，如何选择，也是一项学问。比如，数据仓库的平台，选择的品种就很多；而Web Server的选择也是五花八门；操作系统也是一样。这些又都是和架构息息相关的。

3、模式

武功有招式，下棋有棋谱。不论是招式，还是棋谱，都是针对某一种问题的特定解决方案。在软件开发领域，这种解决方案就被称为模式。

"每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心，这样，你就能一次又一次的使用该方案而不必做重复的劳动"[AIS，77]

这句话源自模式的鼻祖――Christopher Alexander。而在软件开发领域，最值得一提的著作，就是GoF写的『设计模式』一书。在该书中，作者描述了23种的设计模式，可以说，这些模式奠定了面向对象设计的基础。而另一本值得阅读的著作，就是Martin Fowler所著的『分析模式』。

在软件设计中，我们遇到各种各样的问题，我们可能缺乏经验，或能力有限。这非常的正常。但是现实是，我们生产出的代码由于设计方面的缺陷，往往不够清晰，容易出错，难以扩展。相信只要是开发过软件的人，都遇到过这种问题。于是，我们就希望能够看看其他人，是如何处理这种问题的。这里的"其他人"指的可能是技术专家，也可能是经历过同种问题的人，他们对你遇到的问题有能力，有经验来解决。他们提出的解决方案往往是非常成熟的，能够解决你目前遇到的问题，也能够解决你目前尚未遇到的问题。

这对你的吸引力是很大的。那么，我们谈论模式，模式来源于何处呢。注意，模式是针对某一类的问题的解。这里的问题，所指的就是需求。比如说，客户希望能够在软件中实现不同的税率计算方法，那么，我们很自然的就可以想到Strategy模式；当客户的产品有一个很复杂的单位换算机制的之后，我们也能够很自然的想到Quantity模式。使用模式，能够使我们迅速的把握需求的解决方法。另一方面，模式往往告诉我们比目前的问题更多的方面，因为模式都是大家的经验沉淀。如上所说，它还可以解决你目前没有遇到的问题。因此，我们还可以从模式中发现出更深的需求。

另外一点也很重要，虽然它和需求的关系不大。模式往往都有一个模式名称。这就形成了一种沟通的语言。比如我们在下象棋的时候，只要说"马后炮"，谁都知道这是什么意思，绝对不需要呢详细的解说每一步棋子的走法。对于软件开发也是一样的。我和我的同伴会心的一笑，说："Factory Method。"两个人都能够理解这是什么意思，因为这是一种共通的语言，它代表了背后隐藏的各种类的关系和代码实现。这在软件开发中非常的重要。当然，这有个前提，大家都对模式有一个通透的了解。

4、简单设计

模式属于设计的一环，所以前面我们讨论的其实就是设计和需求的关系。这一小节我们还是讨论这个话题。但是侧重点有所不同。XP中有一个原则：KISS。不是kiss哦。它是Keep it simple and stupid的缩写。除了XP，其它的敏捷方法都提倡简单设计，反对过分设计（over build）。也就是说，针对目前的需求，设计目前的软件。

很多的软件人员都是完美主义者，他们喜欢完美的设计，然后把这种设计提供给用户。这种思想就是过分设计的开始。不必要的功能浪费了客户的投资。我们在做需求的时候，很经常发现开发人员随意的向客户推销一些新功能，或是在设计时，过多的考虑未来可能出现的需求变动。

所以，简单设计的意思，就是要针对目前客户提出的需求进行设计，不要过多的考虑目前没有提到的功能。

5、如何统一

细心的读者看到这里可能已经是疑窦丛生了。一边是鼓励使用、设计最完美的方案；另一方面，又强调简单。似乎是自我矛盾。不错这其中是由矛盾的地方，但也有一致的地方。因此，在使用先进的模式和保持设计的简单性之间，我们需要权衡。

一次，我们看到了一个关于权限设置的模式，我们觉得这个模式非常的好，它提供了类似于UNIX操作系统那样的权限控制，可以很随意的增加组、用户，并能够在文件级别上设置权限。我们如获至宝，觉得这是一个非常有用的模式。于是，我们花了一些时间将之实现，并打算应用于新的软件中。

在实际中，我们发现没有一个用户需要如此强大的功能，他们所需要的可能仅是密码控制，或是简单的用户管理。如此复杂的功能对他们来说没有任何的意义。完美的模式在现实中遭到了冷遇。

实际上，用户目前不需要这项功能，并不意味着他以后不需要这项功能。用户的计算机程度提高的很快，我们估计，再过那么一两年，用户可能就非常需要这项功能来管理他那日益庞大的员工队伍了。但是目前，这项功能对用户来说，设置复杂，所以他们并不愿意接受这个"有价值"的功能。

最后，我们想到了一个解决的办法，我们为这一项功能定义了一个通用的接口。通过这个接口，你可以实现复杂的功能，也可以实现简单的功能。总之，你只要是实现了接口的方法就行了。接口的方法很多，但是在目前的简单的实现中，可能就仅仅是一个返回语句，并没有很多的实现。相应的，用户的也仅仅需要使用简单的方法，诸如addUser()，updatePasswd()等。界面也做了简化的处理。

通过这种方法，我们可以在用户需要的时候，替换掉权限模块，对其它的应用并不影响。当然，其中有很多的细节需要注意。在完成之后，我们还发现了另一个副产品：整个的权限控制模块是高内聚，低耦合的。

模式，就好比螺帽的设计图纸，它规定了螺帽的技术规格，但是没有规定具体的尺寸。对应于不同的需要，我们可以设计出不同大小的螺帽以供使用。图纸只需要一份就可以了，并不需要为每一种尺寸的螺帽画一张图纸。

因此呢，一个经历了实践检验的模式，往往功能强大。但是它可以有多种不同的实现。有哪一条法律规定你必须完全的实现一种模式呢。在实际使用中，你需要权衡模式使用的成本和效益。你会发现，在很多情况下，你还是实现了模式，但只是模式的一个框架，或一部分，但是这在目前就够用了。而当需求变动，或新的需求出现的时候，你可以很方便的在原有搭起的框架上添砖加瓦。一切都是那么的自然。比如，在一个进销存的软件中，存在一个运输选择算法，目前的运输途径就一种，但是很有可能会增加新的途径。这时候，你就决定采用Strategy模式。但是你只是实现了一个简单的框架，只有一个具体子类，来实现目前的算法。当新的运输途径出现时，你需要增加一个算法，你就可以再增加一个子类，只要实现的接口相同，改动是不会影响到系统其它的部分的。

6、测试

测试是非常重要的，是软件成败的关键。但是目前国内对测试并不关注，或是假装关注。这样就无法保证软件的质量。测试有很多种，我们这里要说的是和需求息息相关的测试，就是接收测试（Acceptance Test）（关于这个词，可能不同的文章会有不同的译法）。

Surely you aren't going to assume you're getting what you need. Prove that it works! Acceptance tests allow the customer to know when the system works, and tell the programmers what needs to be done.

上面这段话摘自『XPInstalled』。接收测试有两个作用：首先是让客户明白系统能够做什么，然后是让程序员明白该让系统做些什么。

有一种测试的方法是把测试留到最后才做，让客户去发现错误。千万别这么做。原先花费1块钱就可以改正的错误，到了这个时候，可能需要花费1000块钱才能解决。这是软件开发的放大效应。因为很多的工作已经基于这个错误建立了，开发人员也已经对这个错误没有映像了。

XP中有一个很重要的价值，叫做反馈（Feedback）。Kent Beck在Extreme Programming Explained中有句话讲得非常好："乐观是编程的职业病，反馈则是其处方。"从需求的识别，到根据需求构建的系统交付给客户，客户提出意见。这就是一个反馈过程。反馈过程所花费的时间越少越好。接受测试就是解决客户反馈的一个有效的手段。客户编写可重复的测试脚本，开发人员开发出的软件要经受这个测试脚本的考验。这种的反馈速度是很高的，能够有效的解决反馈的问题。

因此，客户在要求实现需求时，同时也有义务提供相关的接收测试：

if it's worth having the programmers build it, it's worth knowing that they got it right.

一个有价值的功能一定是可测试的，如果不是，那么这个功能要么是没有价值，要么是尚未描述清楚。

要注意，这个测试必须是可重复的。这是因为需求的易变性。需求在不断变化，这就意味着代码在不断的变化。因此，原先已经用接收测试证明过了的代码还需要再次证明。这就要求测试是可以重复的。

大量的测试，甚至重复的测试引出了一个新的问题：全凭手工进行测试会浪费大量的时间。因此，易变的需求对测试提出了一个新的要求：自动化测试。只有自动化的进行测试，才可以完成如此大量的测试工作。目前，最好的自动化测试工具，应该就是Xunit系列。关于这方面的问题，大家可以参考相关的资料，这里我们不作深入的讨论。

接收测试最可能的一种形式就是自然语言的说明，外带一组的测试数据。需要强调的一点是，这个测试数据一定要包括输入和输出。这样才可以做出比较。如果只有输入没有输出。测试很可能就是白费劲。所以，计算这个输出是手工计算的，它也是必要的。

除了接收测试，还有一个很重要的概念就是单元测试（Unit Test）。但是单元测试和设计的关系比较大，和需求没有过多的关系，我们这里就只是点一下。大家如有兴趣，可以参考相关的资料。

7、分解

对于需求来说，需要用到的最多的技能可能就是分解的技能了。可以说软件科学最重要的思想就是"分而治之"的思想。不是吗？面向对象是不是一种分解的思想。类、组件、包，这种层级结构不正是体现了"分而治之"吗？当然我这里可能把包和组件弄混淆了。但我的主要目的是要指出这种分解的方法在软件开发中是无处不在的。对于需求也是一样。我们最早做的业务建模就是为了得到一个系统的概貌图。然后到了细节需求阶段，我们会把这张图放大，细分，一直到我们有把握处理为止。

如何把100块砖累起来呢？如果一块一块的累，那很容易就倒了。一种比较好的做法，就是先10块10块的打包，这样，100块砖就变成了10个砖包，再把它们累起来就容易的多了。面向对象其实就是这么做的，当然，面向对象的实现比累砖要难多了。

我们看看XP中是如何处理分解的。XP中最大的周期叫做发布版（release），一个发布版需要一个月或几个月的时间，一般不超过6个月。发布版的末期，需要向客户提供一个可以运行的软件的发布版。然后，XP还定义了次级的周期，称为迭代（iteration），一次的迭代大概需要一周或几周的时间。每一次的迭代都是一个"伪发布版"（pretend release），就是说，迭代的最后也必需要提供一个可以工作的软件，这个软件随时都可以发布。为了定义一次迭代中要处理的事情，XP还定义了素材（story），一份素材代表了客户希望在软件中出现的一项功能（feature），一份素材是很小的，它只需要花费一个开发人员几天或几周的时间。素材已经很小了，但是还需要细分到任务（task），一项任务只需要1到4天的工作量。这并不是最小的单位，XP还把任务划分到测试（test），但这已经到个人级别上了。

我们看到，XP从客户到每一个开发人员，定义了5级的单位，并把时间精确到了天、小时。所以我有时候听人说，XP好像对开发人员的要求不严格。错了，XP可以说是目前要求最为严格的方法，这种分类方法可见一斑。这种分类有什么好处呢？

首先，我们来看发布版，发布版的最短时间是一个月，也就是说，最频繁是一个月向客户交付一次软件。这样，就在很大程度上保证了反馈的迅速进行。避免了传统的开发方法中最后客户发现问题时已经太迟了的现象。

再看迭代，迭代之所以被称为伪发布版，就是因为它的产出物的性质和发布版是一样的。都是可以交付的产品，但是迭代的功能比较少，没有必要交付给客户。我们知道，在传统的软件开发中，整合是一个大问题。整合必然会出现问题，但是没人知道问题在哪儿。所以呢，XP通过不间断的整合，避免了这个问题。

但是，迭代的周期如此之短，能够做些什么呢。这就是素材出现的原因。素材由客户提出，由客户决定优先级，由客户决定放在哪一次的发布版和迭代中。同时，如上面我们谈到的，客户需要为素材制定接收测试。

一份素材的周期是几天或几周，而一次迭代的时间也就几周。这说明素材对迭代而言，单位过大了。所以要把素材再次分解为任务。每一个任务都需要一个开发人员认领，签字。在分解素材的过程中，我们可以发现有一些任务是多个素材共享的，这个概念和用例中的使用的概念是一致的。开发人员会估计自己的任务所需要的时间。从而得出一个迭代周期的总时间。这个时间的估计是基于以往的经验的，因此随着项目的进行，这个估计往往会越发的准确。

我们这里讲XP的分解哲学，并不是要求大家也依样画葫芦，你真要那样做也不行。因为XP的各项实践都是一体的，只有实现了所有的实践，才能体现其威力。我们这样断章取义是行不通的。但是其中的思想我们是可以借用的。分解、归类、排序、估计。这种分析问题的方法，也是我们值得借鉴的。这里有几点要注意：

最早的分解依据往往是客户要求的时间。例如，客户希望在3个月内看到什么什么。在客户和开发放商议之后，决定制定两次的发布版。这个决定虽然开发方可以提供参考意见，但是决定权在客户方；

素材的提出，素材的优先级，素材的安排，这些都是客户的权利。客户也有权利取消、增加、修改素材，或是改变其优先级；

客户投入多少，就能够看到多少的软件。客户也可以取消目前的项目，而且，先前的投资也会有相应部分的软件产出；

对于开发时间的估计是开发人员的权力，其它任何强加于开发人员的时间安排都是不对的；

任务的选择也是出于开发人员自愿的原则；

如果开发人员估计出的总的时间和迭代的预计的时间有出入，绝对不能牺牲开发人员的额外时间换取迭代在限定时间内完成。这种做法无异于饮鸩止渴。比较好的做法是去掉一些任务。

8、客户如何参与

这是一个纯粹的补充问题。一次，一位读者写信来问我，中国的客户素质比较低，对计算机不了解，XP强调的现场客户现实中根本做不到。

XP要求开发人员在开发软件的过程中随时予以支持。诚然，要做到这一点是很难的。我自己也遇到过这种难题，知道问题的棘手程度。我想，这个问题可以分为两个方面。

一种是定制的软件。对于这种项目，你需要解决用户的参与问题，往往客户方的老总愿意投入资金，但是却不愿意投入支持的人力。我也曾见过客户方专门招了一个应届生来对付需求的情况。遇到这种情况，如果你没有能力克服它，那么这个项目绝对是失败的。即便项目最后成功了，申请了什么"重大攻关"之类的奖项，你我都很清楚，这只不过是表面功夫而已。造成这种问题的原因有很多，你需要分析它们，列举出最深层的原因，并且保证列出的这些原因之间并不会相互影响。然后再试着来解决它。一般而言，如果客户方是真正愿意实现这个软件的话，事情并不是不可解决的。

另一种是产品化的软件。我们可以把这种软件的客户分为三类：市场人员、领域专家、最终用户。市场人员往往对软件有最初的认识，但是这种认识往往不够深入。所以，在开发产品化的软件时，一定要配备专门的市场人员，他们对客户的需求最了解，是需求的第一手来源。既然你的老板想要开发这个软件，说明对软件的未来市场有期待，市场人员加入的要求应该是可以得到满足的。其次是领域专家，现在很多的软件公司都配备有领域专家，他们的作用可不小，和市场人员相比，他们也同样熟悉需求，因为他们自己就是资深的用户，并且他们还熟悉理论，能够为软件开发出大力气。最后是最终用户，前面的两类人的参与还不够，如果最终用户不认可软件，那还是没有用。所以，要求市场人员找寻可能的目标客户，试用软件，提出意见，是非常重要的。我们常说的Beta测试也就是这样做的。

9、结语

最早这片文章的想法是来自于一个信贷系统（以文章的观点来看，这个系统是一个失败的案例）。除此之外，还加上了一些以前的项目的经验，以及朋友的一些经验。最后综合成了这一篇文章。

这个系列的文章的写作时间的跨度很长。在这个期间，我的思想也经历一个很大的转变，所以在写作中也出现过对已经完稿的部分大肆删修的情况。这篇文章虽名为『需求的实践』，但所提到的各种想法、方法，都有理论的依据。当然也是参考了很多的资料。而我个人的能力又极为有限，所以有些时候是心有余而力不足。在这样的情形下，文章难免会出现很多的错误。还希望能得到读者们的谅解和指正。

在写作的过程中，也有很多的热心人写来信件，其中好些还成为了好朋友。曾经想把里面的问题整理出来，但是由于疏忽，其中的一部分已经找不到了。希望还能有机会做这件事情。

参考资料：

Karl Wieger:《Software Requirements》

Scott W. Ambler: AgileModeling: http://www.agilemodeling.com

Scott W. Ambler: The Object Primer 2nd Edition

Jacobson, I., Booch, G., and Rumbaugh, J. (1999). The Unified Software Development Process

GOF:《Design Patterns: Elements of Reusable Object Oriented Software》

Eric Gamma, Kent Beck: Junit: http://www.junit.org

Kent Beck，Martin Fowler:《Planning Extreme Programming》

作者简介：

林星，辰讯软件工作室项目管理组资深项目经理，有多年项目实施经验。辰讯软件工作室致力于先进软件思想、软件技术的应用，主要的研究方向在于软件过程思想、Linux集群技术、OO技术和软件工厂模式。您可以通过电子邮件 iamlinx@21cn.com 和他联系。

如果想了解更多相关内容请访问:

http://51cmm.csai.cn/Requirement/No025.htm

软件需求工程过程

--------------------------------------------------------------------------------

来自：中国UML论坛

软件需求工程过程(SREP)

一、 开始：

1. 项目经理根据项目特点，指定对过程表格的具体要求；

2. 项目经理制订项目的标准，包括：DTS(缺陷类型)、TRA(风险类型)、TRS(需求类型)等，在过程表格中按标准引用.

二、 计划：

1. 计划经理估算需求开发时间；

2. 计划经理完成：SPT(进度计划)、TPT(任务计划)，将计划数据录入PDS(项目计划摘要). 三、 需求获取：

1. 软件需求工程师搜集系统概要信息，填写REQ(需求获取概貌)；

2. 软件需求工程师搜集用户需求，分类并清晰地把需求写入REA(需求获取/分析)、RES(需求获取情节)、UIR(用户交互需求)；

3. 检查需求获取过程，并填写REC(需求获取检查)；

4. 如果检查不通过，从1.重头开始过程；

5. 软件需求工程师填写TRL(时间记录日志)、PIP(过程改进建议)；

6. 计划经理整理本阶段数据，录入SPT、TPT.

四、 需求分析：

1. 软件需求工程师进行需求分析，建立分析模型，数据字典及项目词汇表，完成REA（分析模型的具体要求，请分别参见结构化分析和面向对象分析的具体作业指导书）；

2. 软件需求工程师将发现的需求的冲突、交迭、冗余或矛盾，记入NCR；

3. 检查需求分析，完成RAC(需求分析检查)；

4. 如果检查不通过，从1重头开始过程；

5. 软件需求工程师填写TRL、PIP；

6. 计划经理整理数据，录入TPT、SPT.

五、 协商：

1. 软件需求工程师利用NCR，与风险承担者协商解决需求分析中发现的问题，将决议录入NCR；

2. 软件需求工程师根据决议，修改REA等相关文档；

3. 如果有新的需求引入，需要重新进行需求分析阶段；

4. 软件需求工程师填写TRL、PIP；

5. 计划经理整理数据，录入TPT、SPT.

六、 需求评审：

1. 评审小组负责人拟定检查清单，为成员分派检查任务，制订评审日程表；

2. 评审员各自评审分派的内容，将发现的问题录入DRL(缺陷记录日志)；

3. 评审小组负责人组织评审会议，各小组成员提交DRL并讨论；

4. 评审小组以IRF形式提交检查报表；

5. 软件需求工程师根据IRF修订相关文档；

6. 计划经理整理数据，录入TPT、SPT。

七、 需求文档编写：

1. 软件需求工程师综合考虑功能需求和非功能需求，编写《软件需求说明书》

《软件需求说明书》的编写格式与要求，请参见具体的作业指导书。

2. 利用RDC检查《软件需求说明书》是否全面、正确并可执行；

3. 如果检查不通过，从1重头开始过程；

4. 软件需求工程师填写TRL、PIP；

5. 计划经理整理数据，录入TPT、SPT。

八、 需求确认：

1. 评审小组，对需求进行确认：

l 确认每一个需求及相互关系；

l 需求的总体质量达到标准。

将结果写到RVC。

2. 软件需求工程师根据RVC，修订需求文档，并最终通过；

3. 软件工程师为每一个需求设计测试用例，并录入TRF；

4. 相关人员填写TRL、PIP；

5. 计划经理整理数据，录入TPT、SPT。

九、 配置管理：

1. RD(需求文档)成为基线后，即纳入到配置管理；

2. 如果需要对基线RD(需求文档)进行修改，填写CCP；

3. 配置管理人员征求需求开发小组和其他相关人员(风险承担者)关于CCP的意见；

4. 如果所有人员通过CCP，则将需求文档的配置管理取出，并填写CCF；

如果否决需求，则填写RRF；

5. 软件需求工程师修改RD以适应新的需求 (可能包括REA等)；

6. 评审小组对修改的RD执行第八步；

7. 相关人员填写TRL、DRL.

十、 事后分析：

1. 计划经理将DRL、TRL、需求增长率，整理到PPS；

2. 小组分析SREP过程，找出需要改进的地方，填写PIP，并提交质量经理；

3. 小组建立未来过程的改进目标.

名词解释：

1．风险承担者 指从项目中直接或间接受益的人员,例如：用户，管理人员，开发人员等.

如果想了解更多相关内容请访问:

http://51cmm.csai.cn/Requirement/No023.htm

--------------------------------------------------------------------------------

金芝（转载自计算机世界）

　　需求工程无疑是当前软件工程中的关键问题，从美国于1995年开始的一项调查结果就足以看出这一点。在这项调查中，他们对全国范围内的8000个软件项目进行跟踪调查，结果表明，有1/3的项目没能完成，而在完成的2/3的项目中，又有1/2的项目没有成功实施。他们仔细分析失败的原因后发现，与需求过程相关的原因占了45%，而其中缺乏最终用户的参与以及不完整的需求又是两大首要原因，各占13%和12%。

　　需求工程又是软件工程中最复杂的过程之一，其复杂性来自于客观和主观两个方面。从客观意义上说，需求工程面对的问题几乎是没有范围的。由于应用领域的广泛性，它的实施无疑与各个应用行业的特征密切相关。其客观上的难度还体现在非功能性需求及其与功能性需求的错综复杂的联系上，当前对非功能性需求分析建模技术的缺乏大大增加了需求工程的复杂性。从主观意义上说，需求工程需要方方面面人员的参与（如领域专家、领域用户、系统投资人、系统分析员、需求分析员等等），各方面人员有不同的着眼点和不同的知识背景，沟通上的困难给需求工程的实施增加了人为的难度。

　　最初，需求工程仅仅是软件工程的一个组成部分，是软件生命周期的第一个阶段。虽然大家也都知道需求工程对软件整个生命周期的重要性，但对它的研究远远没有对软件工程的其他部分的研究那么深入。

　　在传统软件工程生命周期中，涉及需求的阶段称作需求分析。一般来说，需求分析的作用是：

　　● 系统工程师说明软件的功能和性能，指明软件和其他系统成分的接口，并定义软件必须满足的约束；

　　● 软件工程师求精软件的配置，建立数据模型、功能模型和行为模型；

　　● 为软件设计者提供可用于转换为数据设计、体系结构设计、界面设计和过程设计的模型；

　　● 提供开发人员和客户需求规格说明，用于作为评估软件质量的依据。

　　但从当前的研究现状来看，需求工程的内容远不止这些。需求工程是系统工程和软件工程的一个交叉分支，涉及到软件系统的目标、软件系统提供的服务、软件系统的约束和软件系统运行的环境。它还涉及这些因素和系统的精确规格说明以及系统进化之间的关系。它也提供现实需要和软件能力之间的桥梁。 　　需求工程的基本活动包括：

　　● 抽取需求；

　　● 模拟和分析需求；

　　● 传递需求；

　　● 认可需求；

　　● 进化需求。

　　每个活动都有它基本的动机、任务和结果，也有各自的困难所在。

　　首先，开始一个项目是因为要对现行系统进行改造。要改造一个系统是因为现行系统存在需要解决的问题。如：现行系统与当前情况不符合、出现新的商机或者可能节省时间、资金和资源等，这就是抽取需求的动机。在这个阶段，需求工程师的任务是认识问题之所在，获取足够多的知识，最后成为问题领域的专家。需求工程师常采用W6H方法去认识问题领域，即6个以W打头的问题，一个以H打头的问题，如表1所示。

　　需求抽取是非常困难的，其主要原因有：

　　● 缺乏领域知识，应用领域的问题常常是模糊的、不精确的；

　　● 存在多个知识源，而且多知识源之间可能有冲突；

　　● 存在多个知识源，而且多知识源之间可能有冲突；

　　● 面对的客户可能有偏见，如不能提供你需要了解什么或不想告知你需要了解的事情。

　　需求抽取的方法一般有问卷法、面谈法、数据采集法、用况法、情景实例法以及基于目标的方法等，还有知识工程方法，如：场记分析法、卡片分类法、分类表格技术和基于模型的知识获取等。

　　需求工程的第二个阶段是模拟和分析需求，目前有许多工作都以此为目标进行。需求分析和模拟的出发点在于：

　　● 指导抽取；

　　● 帮助需求工程师了解进展；

　　● 帮助发现问题；

　　● 帮助检查对问题的理解。

　　需求分析和模拟又包含三个层次的工作。首先是需求建模。需求模型的表现形式有自然语言、半形式化（如图、表、结构化英语等）和形式化表示等三种。自然语言形式具有表达能力强的特点，但它不利于捕获模型的语义，一般只用于需求抽取或标记模型。半形式化表示可以捕获结构和一定的语义，也可以实施一定的推理和一致性检查。形式化表示具有精确的语义和推理能力，但要构造一个完整的形式化模型，需要较长时间和对问题领域的深层次理解。对需求概念模型的要求包括：

　　● 实现的独立性:不模拟数据的表示和内部组织等；

　　● 足够抽象：只抽取关于问题的本质方面；

　　● 足够形式化：语法无二义性，并具有丰富的语义；

　　● 可构造性：简单的模型块，能应付不同复杂程度和规模的描述；

　　● 利于分析：能支持二义性、不完整性和不一致性分析；

　　● 可追踪性:支持横向交叉索引并能与设计或实现等建立关联；

　　● 可执行性：可以动态模拟，利于与现实相比较；

　　● 最小性：没有冗余的概念。

　　需求模拟技术又分为企业模拟、功能需求模拟和非功能需求模拟等。

　　企业模拟是一种软系统方法，涉及整个组织，从各个不同的视点分析问题，包括目标、组织结构、活动、过程等。有的企业模拟还建立可执行的领域模型。采用企业模拟方法产生的不仅仅是规格说明，还可以得到许多关于企业运作的状况分析。目前代表性的工作包括：信息模拟、组织模拟和目标模拟等。

　　功能需求模拟从不同视点为模拟软件提供服务，包括结构视点和行为视点等，主要方法有：结构化分析、面向对象分析和形式化方法。结构化分析是一种面向数据的方法，以数据流为中心。其核心概念包括：进程、数据流、数据存储、外部实体、数据组和数据元素。有代表性的模拟工具有：数据流图、数据字典、原始进程规格说明。面向对象分析以对象及其服务作为建模标准，比较自然，对象也具有相对的稳定性。主要模拟的元素有：对象、类、属性、关系、方法、消息传递、Use Cases等。其主要原理包括分类继承层次、信息隐藏、汇集关系等。形式化方法从广义上说，是应用离散数学的手段来设计、模拟和分析，得到像数学公式那样精确的表示。从狭义上说，就是使用一种形式语言进行语言公式的形式推理，用于检查语法的良构性并证明某些属性。形式化方法一般用于一致性检查、类型检查、有效性验证、行为预测以及设计求精验证。引入形式化机制的目的是： 　　● 减少二义性，提高精确性；

　　● 为验证打下基础；

　　● 允许对需求进行推理；

　　● 允许执行需求。

　　但是人们常常不用形式化手段，因为：

　　● 形式化涉及太多细节，分析的级别较低；

　　● 形式化的核心问题是一致性和完整性，而不是获取需求；

　　● 没有合适的工具；

　　● 要求更多的代价。

　　传递需求的主要任务是书写软件需求规格说明，其目的是：

　　● 传达对需求的理解；

　　● 作为软件开发项目的一份契约；

　　● 作为评价后续工作的基线；

　　● 作为控制需求进化的基线。

　　对需求规格说明感兴趣的群体包括：用户、客户；系统分析员、需求分析员；软件开发者、程序员；测试员；项目管理者。

　　认可需求就是让上述人员对需求规格说明达成一致，其主要任务是冲突求解，包括定义冲突和冲突求解两方面。常用的冲突求解方法有：协商、竞争、仲裁、强制、教育等，其中有些只能用人的因素去控制。

　　进化需求的必要性是明显的，因为客户的需要总是不断（连续）增长的，但是一般的软件开发又总是落后于客户需求的增长，如何管理需求的进化（变化）就成为软件进化的首要问题。对传统的变化管理过程来说，其基本成分包括软件配置、软件基线和变化审查小组。当前的发展是软件家族法，即产品线方法。多视点方法也是管理需求变化的一种新方法，它可以用于管理不一致性并进行关于变化的推理。

如果想了解更多相关内容请访问:

http://51cmm.csai.cn/Requirement/No017.htm