1、第4章 需求开发和需求管理 第4章 需求开发和需求管理 4.1 从一幅幽默画看到的需求问题从一幅幽默画看到的需求问题 4.2 需求管理的困难性需求管理的困难性 4.3 管理需求的层次管理需求的层次 4.4 需求工程需求工程 4.5 如何获取需求如何获取需求 4.6 需求规格说明需求规格说明 4.7 需求管理需求管理4.8 小结小结 第4章 需求开发和需求管理 4.1 从一幅幽默画看到的需求问题从一幅幽默画看到的需求问题软件危机不是危言耸听，在软件开发过程中会发生各种各样的问题，甚至是挺荒唐的事，所以才有了如图4.1所示的这张经典的幽默画。该画讽刺了软件工程的低水平开发和管理。图4.1表明了软件
2、组织中各种角色对软件要实现的功能特性有不同的理解，经过各个环节，误差被不断放大，最终产生令人啼笑皆非的结果。分析其原因，有以下几条：客户没有把自己的需求描述清楚，一开始就有问题。项目经理没有认真倾听客户的需求，客户的需求打了折扣。第4章 需求开发和需求管理 分析人员进一步误解了客户的需求，设计的内容可能到了不可理喻的地步。程序员写的代码也是漏洞百出，使原来就很糟糕的功能设计雪上加霜。业务咨询师却将软件功能吹嘘得天花乱坠。项目过程中忽视文档，几乎是一片空白。软件在安装之后，某些功能不能正常工作，或几乎不可用。还是照样按照高科技产品收取客户的费用。技术支持人员可能将问题弄得更糟糕第4章 需求开发和
3、需求管理 图4.1 讽刺软件工程危机的著名幽默画(不同的角色对软件的理解不同，而且经过各环节放大后，误差被不断放大)第4章 需求开发和需求管理 4.1.1 每个项目都有需求每个项目都有需求Frederick Brooks在他1987年的经典文章No Silver Bullet:Essence and Accidents of Software Engineering中充分说明了需求过程在软件项目中扮演的重要角色：开发软件系统最困难的部分就是准确说明要开发什么。最困难的概念性工作便是编写详细技术需求，包括所有面向用户、面向机器和其他软件系统的接口。该工作一旦做错，最终会给系统带来极大损害，而且以
4、后再对它修改也极为困难。第4章 需求开发和需求管理 每个软件产品都是为了使用户能以某种方式改善其工作和生活，因此，花在了解用户需求上的时间便是项目成功的高层投资。对商业的最终用户应用程序，企业信息系统和软件作为一个大系统的某一部分的产品是显而易见的。但是，对开发人员来说，并没有编写客户认可的需求文档，又怎么知道项目何时结束呢？如果不知道什么对客户来说很重要，又怎么能使客户感到满意呢？而且，即便非商业目的的软件需求也是必需的，例如软件库、组件和工具等供开发小组内部使用的软件，当然也可能偶尔不需文档说明就与其他人意见接近一致，但是，更常见的是出现重复返工这种不可避免的后果。无论怎样，重新编制代码的
5、代价远远超过重写一份需求文档的代价。第4章 需求开发和需求管理 4.1.2 需求是软件项目成败的关键需求是软件项目成败的关键解决问题的第一步是理解问题。Standish Group公司在调查中让被调查人员确定项目的重要因素，项目分为“成功”、“遇到困难”(推迟且没有达到预期)以及“损坏”(被取消)。调查数据表明，与软件开发有关的、最常见、最严重的问题都与需求有关。Standish Group公司(1994)研究特别指出了三种最经常提到的使项目“遇到困难”的因素：缺乏用户输入：占所有项目的13%；不完整的需求和规格说明：占所有项目的12%；不断改变的需求和规格说明：占所有项目的12%。第4章 需
6、求开发和需求管理 当然，项目失败的原因还有很多，可能是不合理的进度或时间安排(4%)、人力和资源不足(6%)或技术技能不够(7%)，以及其他诸多原因。Standish的数据在业界具有代表性，研究表明至少三分之一的软件项目是因为与需求获取、需求文档和需求管理有关的原因而陷入困境的。很多项目都有进度的推迟或预算的超支，如果没有取消的话，Standish Group发现大公司9%的项目是按时在预算内交付的；小公司16%的项目是成功的。那么，项目最主要的“成功因素”是什么？根据Standish Group的研究，三个最重要的因素是：第4章 需求开发和需求管理 用户介入：占所有成功项目的16%；高层管理
7、支持：占所有成功项目的14%；需求陈述清晰：占所有成功项目的12%。根据IDC(International Data Corporation)的统计，80%失败的IT项目是由于需求分析做得不好，没有真正反映用户的需求。根据Standish Group的分析，项目失败最重要的8个原因中的5个都与需求有关：不完整的需求；缺少用户参与；不实际的客户期望；需求和规范的变更；提供不再需要的能力。第4章 需求开发和需求管理 此外，CHAOS大学工作人员Sanjiv指出：“如果没有搞定需求，则项目一定会失败；如果搞定需求，则项目一定会交付。”1995年，ESPITI(European Software Pr
8、ocess Improvement Training Initiative)调查了3800人以确定在产业中相对重要的软件问题，调查也印证了Standish Group公司的调查结果。相对而言，编码“不是问题”，问题在于需求阶段，需求分析无疑是软件项目的关键。很显然，完全可以把需求当作导致软件问题的最根本原因。因此，软件需求的重要性正在不断增强。第4章 需求开发和需求管理 4.1.3 软件需求的定义软件需求的定义软件需求包含着多个层次，不同层次从不同角度与不同程度反映问题的细节。IEEE软件工程标准词汇表(1997年)中将需求定义为：(1)用户解决问题或达到目标所需的条件或权能(Capabili
9、ty)；(2)系统或系统部件要满足合同、标准、规范或其他正式规定的文档所需的条件或权能；(3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。第4章 需求开发和需求管理 IEEE的定义包括从用户角度(系统的外部行为)以及从开发者角度(一些内部特性)来阐述需求。其中，一个关键的问题是要编写需求文档。如果未编写需求文档，只有一堆邮件、便条、会谈或一些零碎的对话记录，就要让人确信你已明白需求，那完全是在自欺欺人。Jones认为需求是“用户所需要的并能触发一个程序或系统开发工作的说明”。需求分析专家Alan Davis认为需求是“从系统外部发现系统所具有的满足用户的特点、功能、属性等”。这些定
10、义强调的都是产品是什么样的，而非产品是怎样设计、构造的。下面的定义从用户需要进一步转移到了系统特性：“需求是指明必须实现什么的规格说明，它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。”第4章 需求开发和需求管理 这些不同形式的定义表明：没有一个清晰、无二义性的“需求”术语存在，真正的“需求”实际上存在于人们的脑海中。任何文档形式的需求(例如需求规格说明)仅是一个模型，一种叙述。因此，要确保所有项目干系人在对描述需求的名词的理解上务必达成共识。第4章 需求开发和需求管理 4.2 需求管理的困难性需求管理的困难性需求分析是软件工程中最复杂和最难处理的过程。归结起来，需求分析的问题主要
11、体现在下面4个方面：(1)需求的复杂性。由于用户需求涉及的因素繁多，如运行环境和系统功能、性能等，就导致了需求分析的复杂化。因此，需要积极与用户交流，捕捉、分析和修订用户对目标系统的需求，以提炼出符合问题领域的用户需求。第4章 需求开发和需求管理(2)分析人员或客户理解有误。系统需求涉及人员较多，如软件系统的用户、问题领域专家、需求工程师和项目管理人员等，这些人员具有不同的背景和知识，处于不同的角度，扮演不同的角色，不可避免地造成了交流的困难。例如，软件系统分析人员不可能都是全才，对于客户表达的需求，不同的分析人员可能有不同的理解；客户大多不懂软件，可能会认为软件是万能的，会提出一些无法实现的
12、需求。第4章 需求开发和需求管理(3)不完整性和不一致性。每项需求都必须将要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。由于种种原因，用户对问题的陈述往往是不完整的，而且各方面的需求可能会互相矛盾。此外，用户需求必须和业务需求一致，功能需求必须和用户需求一致。严格遵守不同层次间的一致性关系，才可以保证最后开发出来的软件系统不会偏离最初的目标。(4)需求的易变性。随着客户对项目的理解越来越深刻，其需求也可能会随之改变，这些变化的可能性越大，项目风险就越大。在需求分析的时候要充分考虑到哪些需求是相对固定的，哪些需求可能发生变动，考虑到需求的可变性，在设计功能和数据库的
13、时候就不会因为后面的变动而影响整个工程。第4章 需求开发和需求管理 软件需求的特性，使得不重视需求过程的项目队伍将自食其果，需求工程中的缺陷将给项目成功带来极大的风险。下面讨论一些需求风险，这些都增加了需求管理的难度：1.缺乏足够的用户参与缺乏足够的用户参与客户经常不明白为什么要花费那么多工夫来收集需求和确保需求质量，开发人员可能也不重视用户参与。究其原因：一是与用户合作不如编写代码有趣；二是开发人员觉得自己已经明白用户需求了。某些情况下，与实际使用产品的用户直接接触很困难，而且用户也可能不太明白到底需要什么。无论怎样，还是应该让具有代表性的用户在项目早期直接参与到开发队伍中，并一同经历整个开
14、发过程，这有利于项目的成功。第4章 需求开发和需求管理 2.用户需求的不断扩展用户需求的不断扩展在开发中如果不断地补充需求，项目就越变越庞大，以致超过其计划安排及预算范围。计划并不总是贴近项目需求规模与复杂性的实际情况、风险、开发生产率及需求变更情况，这使得问题更难解决。事实上，问题的根源在于用户对需求的改变和开发者对新需求所作的修改。第4章 需求开发和需求管理 产品开发中不断延续的变更会使其整体结构日渐紊乱，补丁代码也使整个程序难以理解和维护。插入补丁代码也使模块违背了强内聚、松耦合的设计原则，而且，如果项目配置管理不完善的话，收回变更和删除特性也会带来问题。如果能尽早区别可能带来变更的特性
15、，就能开发一个更健壮的结构，并能更好地适应它，这样设计阶段的需求变更不会直接导致增加补丁代码，同时也有利于控制因变更导致的质量下降。第4章 需求开发和需求管理 3.模棱两可的需求模棱两可的需求模棱两可是需求规格说明中最可怕的问题。它的一层含义是指不同角色对需求说明产生了不同的理解；另一层含义是指单个角色能用不止一种方式来解释某个需求说明。模棱两可的需求会使不同的项目干系人产生不同的期望，会使开发人员为错误问题而浪费时间，并且使测试者与开发者所期望的也不一致。系统测试人员就经常对需求理解有误，以致不得不重写许多测试用例和重做许多测试。第4章 需求开发和需求管理 处理模棱两可的需求，一种方法是组织
16、一支从不同角度负责审查需求的队伍。仅仅靠简单浏览需求文档是不能解决模棱两可的问题的。如果不同的评审者从不同的角度对需求说明给予解释，使每个评审人员都有所了解，那么二义性就不会直到项目后期才被发现，那时才发现的话会使变更的代价很大。第4章 需求开发和需求管理 4.不必要的特性不必要的特性“镀金”是指开发人员力图增加一些“用户欣赏”，但并未在需求规格说明中涉及的新功能。经常发生的情况是用户并不认为这些功能很有用，以致在其上耗费的努力“白搭”了。开发人员应当为客户构思方案并考虑一些创新思路，具体确定哪些功能要在客户所需与开发人员所允许的时限之间求得平衡。开发人员应努力使其简单易用，而不要未经客户同意
17、，擅自脱离客户要求，自作主张。同样，客户有时也可能要求一些看上去很“酷”，但缺乏实用价值的功能，这些只能徒耗时间和成本。为了将“镀金”的危害尽量减小，应确信已明白：为什么要包括这些功能，以及这些功能的“来龙去脉”，使需求分析过程始终关注那些能使用户完成其业务任务的核心功能。第4章 需求开发和需求管理 5.过于精简的规格说明过于精简的规格说明有时，客户并不明白需求分析如此重要，于是只提供一份精简之至的规格说明，仅涉及产品概念上的内容，然后让开发人员在项目进展中去完善，结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明。这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况。在大多
18、数情况下，这样做会给开发人员带来挫折(使他们在不正确假设的前提下和极其有限的指导下工作)，也会给客户带来烦恼(他们无法得到设想的产品)。第4章 需求开发和需求管理 6.忽略了用户分类忽略了用户分类大多数产品是由不同的人使用其不同的特性，使用频繁程度也有差异，使用者受教育程度和经验水平也不尽相同。如果不能在项目早期就针对所有的主要用户进行分类的话，必然会导致有的用户对产品感到失望。例如，菜单驱动操作对高级用户太低效了，而含义不清的命令和快捷键又会使不熟练的用户感到困难。第4章 需求开发和需求管理 7.不准确的计划不准确的计划“这是我对新产品的看法，那么，能告诉我什么时候能完成吗？”许多开发人员都
19、遇到过这种难题。对需求分析缺乏理解会导致过分乐观的估计，当不可避免的超支发生时，会带来颇多麻烦。据报道，导致需求过程中软件成本估计极不准确的原因主要有五点：频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求规格说明和不完善的需求分析。第4章 需求开发和需求管理 对估计时间问题的正确响应应该是“等我真正明白你的需求时，就会告诉你”。基于不充分信息和未经深思的不成熟估计很容易延期。要做出估计时，最好是给出一个范围(例如最好的情况、很可能的情况、最坏的情况)或一个可信赖的程度(我有90%的把握，能在8周内完成)。通常没有准备的估计是作为一种猜测给出的，而用户却认为是一种承诺，因此，要尽量给出
20、可达到的预期期望并坚持达到该期望。第4章 需求开发和需求管理 4.3 管理需求的层次管理需求的层次软件需求包括三个不同的层次业务需求、用户需求和功能需求(也包括非功能需求)。业务需求反映了组织机构或客户对系统、产品高层次的目标要求，在项目视图与范围文档中予以说明。用户需求描述了用户使用产品必须完成的任务，在用例文档或场景说明中予以说明。功能需求定义了开发人员必须实现的软件功能，帮助用户能完成其任务，从而满足业务需求。对一个复杂产品来说，软件功能需求也许只是系统需求的一个子集，因为另一些需求可能来自于其他部件。软件需求各组成部分之间的关系如图4.2所示。第4章 需求开发和需求管理 在软件需求规格
21、说明(Software Requirements Specification,SRS)中描述的功能需求充分阐明了软件系统应该具有的外部行为。软件需求规格说明在开发、测试、质量保证、项目管理以及项目相关活动中都起到了重要的作用。作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等，包括产品必须遵从的标准、规范和合约，外部界面的具体细节，性能要求，设计或实现的约束条件及质量属性等。所谓约束，是指对开发人员在软件产品设计和构造上所具有的选择和限制。质量属性从多个角度对产品的特点进行描述，从而反映产品功能，这对用户和开发人员都极为重要。第4章 需求开发和需
22、求管理 需求并不包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明究竟想开发什么。项目也有其他方面的需求，如开发环境需求或发布产品及移植到支撑环境的需求等。第4章 需求开发和需求管理 图4.2 软件需求各组成部分之间的关系(三个层次的需求反映了不同层面的问题，软件功能需求也许只是系统需求的一个子集)第4章 需求开发和需求管理 4.4 需需 求求 工工 程程整个软件需求工程研究领域可划分为需求开发和需求管理两部分，如图4.3所示。第4章 需求开发和需求管理 图4.3 需求工程领域的组成(需求工程包括需求开发和需求管理，需求管理对需求开发获取的需求进行管理和跟踪
23、，并控制需求变更)第4章 需求开发和需求管理 需求开发可进一步分为：获取、分析、定义和验证需求四个阶段。它们包括软件类产品的需求收集、评价、编写文档等活动。需求开发活动包括下面几个方面：确定要开发产品的用户类；获取每个用户类的需求；了解实际用户任务和目标以及这些任务所支持的业务需求；分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息；将系统级的需求分为几个子系统，并将需求中的一部分分配给软件组件；第4章 需求开发和需求管理 了解相关质量属性的重要性；商讨实施优先级的划分；将收集的用户需求编写成规格说明和建立模型；评审需求规格说明，确保对用户需求达到共同的
24、理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。第4章 需求开发和需求管理 需求管理“建立并维护在软件工程中同客户达成的契约”，契约包含在编写的需求规格说明与模型中。客户的接受仅是需求成功的一半，开发人员也必须能接受，并真正把需求应用到产品开发中。通常的需求管理活动包括：定义需求基线；评审提交的需求变更，评估每项变更的影响以决定是否实施；以一种可控制的方式将需求变更融入到项目中；使当前的项目计划与需求一致；在基于对变更需求所产生影响的估计的基础上，协商新的承诺(约定)；第4章 需求开发和需求管理 让每项需求都能与对应的设计、源代码和测试用例联系起来以实现跟踪；在整个项目过程中跟踪需求状
25、态及其变更情况。从图4.4中可以了解需求开发和需求管理之间的区别。第4章 需求开发和需求管理 图4.4 需求开发与需求管理之间的界限(需求基线是需求开发的目标，是需求管理的基础)第4章 需求开发和需求管理 4.5 如何获取需求如何获取需求4.5.1 客户的需求观客户的需求观引起需求问题的一部分原因是混淆了不同层次的需求(业务、用户、功能)。Gerhard说明了一些业务需求，但他并不能清楚地描述用户需求，因为他并不是“化学制品跟踪系统”的实际使用者。只有实际用户才能描述他们用此系统完成什么任务，但他们又不能指出完成这些任务所需要的、所有的、具体的功能需求。第4章 需求开发和需求管理 4.5.2
26、与客户协商与客户协商客户是指直接或间接从产品中获得利益的个人或组织。软件客户包括提出要求、支付款项、选择、具体说明或使用软件产品的项目干系人或是获得产品所产生结果的人。Gerhard代表支付、采购或投资软件产品的一类客户，处于Gerhard层次上的客户有义务说明业务需求，他们应阐明产品的高层概念和将发布产品的主要业务内容。业务需求为后继工作建立了一个指导性的框架，其他任何说明都应遵从业务需求的规定，但是，业务需求并不能为开发人员提供很多开发所需的细节说明。第4章 需求开发和需求管理 用户需求必须从使用产品的用户那里收集。这些用户(通常称作最终用户)构成了另一种软件客户，他们能说清楚要使用该产品
27、完成什么任务和一些非功能特性，而这些特性有利于用户接受具有该特点的产品。说明业务需求的客户有时会试图替代用户说话，但是他们通常无法准确地说明用户需求。因为，用户需求应来自于真正使用产品的操作者。商业软件开发的情况有些不同，因为通常其客户就是用户。对于市场部这类客户代理，可能想确定究竟软件产品的购买者会喜欢什么。但是，即使是商业软件，也应该让实际用户参与到收集需求的过程中来。如果不这样做，产品很可能会因缺乏足够的用户提供的信息而出现很多隐患。第4章 需求开发和需求管理 优秀的软件产品是建立在优秀的需求基础之上的，高质量的需求来源于客户与开发人员之间有效的交流与合作。但是，开发人员与客户或客户代理
28、，如市场人员间的关系反而会成为一种对立关系，双方的管理者都只想自己的利益而搁置用户提供的需求从而产生摩擦，在这种情况下，不会给双方带来任何好处。只有当双方参与者都明白要成功自己需要什么，同时也应知道要成功合作方需要什么时，才能建立起一种合作关系。由于项目压力与日剧增，所有项目干系人很容易遗忘他们有着一个共同的目标。其实大家都想开发出一个既能实现商业价值，又能满足用户需要，还能使开发者感到满足的、优秀的软件产品。第4章 需求开发和需求管理 为产品需求签订协议是客户与开发人员关系中的重要部分，但这里存在这样一个问题：客户代表经常把“签字”看作是毫无意义的。“他们要我在一张纸的最后一行文字下面签上名
29、字，于是我就签了，否则这些开发人员不开始编码。”这种态度会给将来带来麻烦，例如，客户想更改需求或对产品有不满时。“不错，我是在需求上签了字，但我并没有时间去读完所有的内容。我是相信你们的，是你们非要让我签字的。”同样的问题也发生在管理人员身上。一旦有需求变更出现，他便指着软件需求规格说明说道：“你已经在需求上签字了，所以这些便是我们要开发的。如果你想要别的什么，你应该早点告诉我们。”第4章 需求开发和需求管理 这样的态度都是不正确的，不可能在项目早期就了解所有需求，而且毫无疑问，需求将会出现变更。在需求上签字是终止需求开发过程的正确方法，而参与者必须明白他们的签字意味着什么。更重要的是签字是建
30、立在一个需求基线上的，因此，在需求规格说明上签字应该这样理解：“我同意该文档描述了目前对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行，我知道变更可能需要重新协商成本、资源和项目工期、任务等。”第4章 需求开发和需求管理 对于基线达成一定的共识会易于接受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。给初步的需求开发工作画上一个双方都明确的句号将有助于形成良好的客户与开发人员之间的关系，为项目的成功奠定基础。第4章 需求开发和需求管理 4.5.3 需求获取技术需求获取技术需求获取技术包括下面两方面的工作：建立获取用户需求方法的框架；支持和监控需
31、求获取的过程。获取用户需求的主要方法是调查研究。(1)了解系统的需求。软件开发常常是系统开发的一部分，仔细分析研究系统的需求规格说明，对软件的需求获取是很有必要的。(2)市场调查。了解市场对待开发软件有什么样的要求，了解市场上有无与待开发软件类似的系统。如果有，再了解其在功能上、性能上、价格上的情况如何。第4章 需求开发和需求管理(3)访问用户和领域专家。分析从用户那里得到的信息，这是重要的原始资料。访问领域专家所得到的信息将有助于对用户需求的理解。(4)考察现场。了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。第4章 需求开发和需求管
32、理 在做调查研究时，可以采取下面的调查方式：制定调查提纲，向不同层次的用户发放调查表；按用户的不同层次分别召开调查会，了解用户对待开发系统的想法和建议；向领域专家或在关键岗位上工作的人个别咨询；实地考察，跟踪现场业务流程；查阅与待开发系统有关的资料；使用各种调查工具，如数据流图、任务分解图、网络图等。为了能够有效地获取和理清用户需求，应当打破用户(需方)和开发者(供方)的界限，共同组成联合开发小组，发挥各自的长处，协同工作。第4章 需求开发和需求管理 4.5.4 需求获取需求获取需求有三个层次：业务、用户和功能。在项目中它们有不同的来源，也有不同的目标和对象，需要用不同的方式编写文档。业务需求
33、(或产品视图和范围)不应包括用户需求(或用例)，而功能需求应该来源于用户需求。同时，还需要获取非功能需求，如质量属性等。需求获取主要包括下面的活动：(1)确定需求开发过程。对组织需求进行收集、分析、细化并验证，然后编写文档，对重要的工作和步骤给予一定的指导，将有助于分析人员的工作，而且也使收集需求活动的安排和进度计划更容易进行。第4章 需求开发和需求管理(2)编写项目视图和范围文档。项目视图和范围文档应该包括高层的业务目标，所有的用例和功能需求都必须遵从能达到的业务需求。项目视图使所有项目参与者对项目的目标能达成共识，而范围文档则作为需求或潜在特性的参考。(3)将用户群分类并归纳各自特点。为避
34、免出现某一用户群需求遗漏的情况，需要将可能使用产品的客户分成不同类别，他们可能在使用频率、使用特性、优先等级或熟练程度等方面都有差异，详细描述出他们的个性特点及任务状况，将有助于产品设计。第4章 需求开发和需求管理(4)选择每类用户的产品代表。为每类用户至少选择一位能真正代表他们需求的人作为用户代表，代表他们做出决策。这对内部信息系统开发来讲很容易实现，此时用户就是身边的雇员；对商业开发而言，就得在主要的客户或测试人员中建立起良好的合作关系，并确定合适的产品代表，他们必须一直参与项目的开发而且有权做出决策。(5)建立典型用户的核心队伍。把同类产品或产品的先前版本用户代表召集起来，从他们那里收集
35、目前产品的功能需求和非功能需求。与产品代表的区别在于，核心队伍成员通常没有决定权。第4章 需求开发和需求管理(6)让用户代表确定用例。从用户代表处收集他们使用软件完成工作任务的描述用例，讨论用户与系统间的交互方式和会话要求。在编写用例文档时可采用标准模版，在用例基础上可得到功能需求。(7)召开应用程序开发联系会议。应用程序开发联系会议(Joint Application Development,JAD)是范围广泛、简便的专题讨论会，也是分析人员与客户代表之间合作的一种方法，能由此拟出需求文档的底稿。该会议通过紧密而集中的讨论得以将客户与开发人员间的合作伙伴关系付诸于实践。第4章 需求开发和需求
36、管理(8)分析用户工作流程。观察用户完成业务的过程，画出简单的示意图(如数据流图)来描绘出用户什么时候获得什么数据，并怎样使用这些数据。编制业务过程流程文档将有助于明确产品的用例和功能需求，甚至可能发现客户并不需要一个全新的软件系统就能达到其业务目标。(9)确定质量属性和其他非功能需求。在功能需求之外考虑非功能的质量特点，将使产品达到并超过客户的期望。这些特点包括性能、有效性、可靠性、易用性等，在这些质量属性上客户提供的信息是非常重要的。第4章 需求开发和需求管理(10)检查当前系统的问题以进一步完善需求。客户的问题报告及补充需求为新产品或新版本提供了大量丰富的改进及增加特性的想法，负责提供用
37、户支持及帮助的人能为需求收集提供极有价值的信息。(11)跨项目重用需求。如果客户要求的功能与已有的产品很相似，就可以查看需求是否有足够的灵活性以允许重用一些已有的软件组件。第4章 需求开发和需求管理 4.5.5 需求分析需求分析需求分析包括提炼、分析和仔细审查已收集到的需求，以确保所有的干系人都明白其含义并找出其中的错误、遗漏或不足的地方。分析员通过评价来确定是否所有的需求和软件需求规格说明都达到了优秀需求说明的要求，目的在于开发出高质量的需求。通常，把需求中的一部分用多种形式来描述，如文本、图形等。分析不同的视图将揭示出一些更深刻的问题，这是单一视图无法提供的。分析还包括与客户的交流以澄清某
38、些混淆并明确哪些需求更重要，其目的是确保所有干系人尽早地对项目达成共识并对将来的产品有相同而清晰的认识。下面是需求分析的任务：第4章 需求开发和需求管理(1)绘制系统上下文示意图。该示意图是用于定义系统与外部实体间的界限和接口的简单模型，同时也明确了通过接口的信息流。(2)建立数据字典。数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应该定义客户数据项，以确保客户与开发小组使用一致的定义和术语。分析和设计工具通常包括数据字典组件。(3)为需求建立模型。需求的图形分析模型是软件需求规格说明极好的补充说明，能提供不同的信息，有助于找到不正确的
39、、不一致的、遗漏的和冗余的需求。需求模型包括数据流图、实体联系图、状态变换图、对话框图、对象图及交互作用图等。第4章 需求开发和需求管理(4)建立用户界面原型。当开发人员或用户不能确定需求时，开发用户界面原型一个局部的可能实现将使许多概念和可能发生的事更直观明了。用户通过评价原型使项目参与者能更好地相互理解要解决的问题，并找出需求文档与原型之间的冲突。(5)分析需求可行性。在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其他需求的冲突，对外界因素的依赖和技术障碍等。第4章 需求开发和需求管理(6)确定需求优先级。应用分析方法来确定用例、产品特性或单项需
40、求实现的优先级，以优先级为基础确定产品版本将包括哪些特性或哪些需求。当允许需求变更时，在特定的版本中加入变更，并在版本计划中做出安排。(7)使用质量功能展开。质量功能展开(Quality Function Deployment,QFD)是一种高级系统技术，将产品特性、属性与用户价值联系起来。QFD将需求分为三类：期望需求，即客户或许并未提及，但如果缺少则会让他们感到不满意的需求；普通需求；兴奋需求，即实现了会给客户带去惊喜，如果未实现也不会受到责备的需求。QFD技术提供了一种分析方法以明确哪些是客户最关注的特性。第4章 需求开发和需求管理 4.6 需求规格说明需求规格说明无论需求从何而来，也不
41、管是怎么得到的，都必须用统一的方式将它们编写成可视的文档。软件需求规格说明包含了软件的功能需求和非功能需求，必须为每项需求明确建立标准的风格，并在SRS中采用，以确保SRS风格的统一。下面是编写需求文档的几个方面：(1)记录业务规范。业务规范是关于产品的操作原则，比如谁能在什么情况下采取什么行动。将这些编写成SRS中的一个独立的部分，或独立的业务规范文档。某些业务规范将引出相应的功能需求，这些需求也应能追溯到相应的业务规范。第4章 需求开发和需求管理(2)采用SRS模板。在组织中要为编写软件需求文档定义标准模板，该模板为记录功能需求和各种其他与需求相关的重要信息提供了统一的结构，其目的并不是创
42、建一种全新的模板，而是采用一种已有的、可满足项目需要并适合项目特点的模板。很多组织一开始就采用IEEE标准830-1998描述的SRS模板，有时也要根据项目特点进行适当的改动。(3)为每项需求加上标记。制定一种风格来为SRS中的每项需求提供一个独立的、可识别的标记或记号，该风格应当很健全，允许增加、删除和修改。作了标记的需求能被跟踪、记录需求变更并为需求状态和变更活动建立度量。第4章 需求开发和需求管理(4)指明需求来源。为了让所有项目干系人明白SRS中为何提供这些功能需求，要让每项需求都能追溯到来源，这可能是一个用例或其他客户要求，也可能是更高层的系统需求、业务规范、政府规则、标准或其它外部
43、来源。(5)创建需求跟踪能力矩阵。建立一个矩阵，把每项需求与设计、实现和测试等部分联系起来，这样的需求跟踪能力矩阵同时也把功能需求和高层需求及其他相关需求联系起来了。在开发过程中就应建立这个矩阵，不要等到最后才去补建。第4章 需求开发和需求管理 4.6.1 软件需求规格说明的特性软件需求规格说明的特性1.完整性完整性每一项需求都必须将要实现的功能描述清楚，以便使开发人员获得设计和实现这些功能所需的信息。2.正确性正确性每一项需求都必须准确地陈述要开发的功能。判断正确与否的基准来源于需求，如客户或高层的系统需求规格说明。如果软件需求与对应的系统需求相抵触，就是不正确的。只有用户代表才能确定用户需
44、求的正确性，这就是为何一定要有用户积极参与的原因。没有用户参与的需求评审将导致类似说法：“那些毫无意义，这些才很可能是他们想要的。”其实这完全是评审者的凭空猜测。第4章 需求开发和需求管理 3.可行性可行性每一项需求都必须在已知系统和环境的权能和限制范围内可以实现。为避免不可行的需求，最好在获取需求(收集需求)过程中始终有一位项目组的成员与需求分析人员或考虑市场的人员一起工作，由他来负责技术可行性方面的检查。4.必要性必要性每一项需求都应把客户真正需要的和最终系统需要遵守的标准记录下来。“必要性”也可以理解为每项需求都是授权编写文档的“根源”，要使每项需求都能回溯到某项客户的输入，如用例或其它
45、来源。第4章 需求开发和需求管理 5.划分优先级划分优先级给每项需求、特性或用例分配一个实施优先级以指明它在特定产品中所占的分量。如果把所有的需求都看作同样重要，那么项目经理在组织开发或节省预算或任务调度中就会丧失控制的自由度。6.无二义性无二义性对所有需求说明都只能有一个明确、统一的解释，由于自然语言极易导致二义性，所以应尽量把每项需求用简洁明了的、用户的语言表达出来。避免二义性的有效方法包括对需求文档的正式审查、编写测试用例、开发原型以及设计特定的方案脚本等。第4章 需求开发和需求管理 7.可验证性可验证性检查每项需求是否能通过测试用例或其他验证方法的检验，如通过演示、检测等来确定产品是否
46、确实按需求实现了。如果需求不可验证，那么实施是否正确就无法判断，无法进行客观的分析。一份前后矛盾、不可行或有二义性的需求也是不可验证的。第4章 需求开发和需求管理 4.6.2 软件需求规格说明模板软件需求规格说明模板每个软件开发组织都应该在项目中采用一种标准的软件需求规格说明模板，有许多推荐的软件需求规格说明模板可以使用。图4.6为将IEEE 830标准改写并扩充的软件需求规格说明模板，可以根据项目的需要来修改这个模板。如果模板中某一特定部分不适合你的项目，那么就在原处保留标题，并注明该项不适用，这可以防止读者认为是否不小心遗漏了一些重要的部分。与其他任何软件项目文档一样，该模板包括一个内容列
47、表和一个修正的历史记录，该记录包括对软件需求规格说明所作的修改、修改日期、修改人员和修改原因等。第4章 需求开发和需求管理 图4.6 软件需求规格说明模板(以IEEE 830为模版的需求规格说明书的主要内容)第4章 需求开发和需求管理 4.6.3 编写需求文档的原则编写需求文档的原则编写优秀的需求文档没有固定的方法，最好是根据经验进行，可从过去遇到的问题中受益。很多需求文档通过使用有效的技术编写风格和使用用户术语而不是计算机专业术语的方式得以改进。在编写软件需求文档时，应牢记下面的建议：保持语句和段落的简短。采用主动语态的表达方式。编写具有正确的语法、拼写和标点的完整句子。使用的术语应该与词汇
48、表中所定义的一致。第4章 需求开发和需求管理 需求陈述应该具有一致的样式，例如“系统必须”或者“用户必须”，并紧跟一个行为动作和可观察的结果。例如，“仓库管理子系统必须显示一张指定的仓库中有库存的化学药品容器清单”。为了减少不确定性，必须避免模糊的、主观的术语，例如，用户友好、容易、简单、迅速、有效、支持、许多、最新技术、优越的、可接受的和健壮的等。当用户说“用户友好”或“快”或“健壮”时，你应该明确它们的真正含义并且在需求中阐明用户的意图。第4章 需求开发和需求管理 避免使用比较性的词汇，例如提高、最大化、最小化和最佳化等。应定量地说明所需要提高的程度或说清一些参数可接受的最大值和最小值。当
49、客户说明系统应该“处理”、“支持”或“管理”某些事情时，你应该能理解客户的意图。含糊的语句表达将引起需求的不可验证。由于需求的编写是层次化的，因此可以把顶层不明确的需求向低层细分，直到消除不明确性为止。编写详细的需求文档，所带来的益处是如果需求得到满足，那么客户的目的也就达到了，但是不要让过于详细的需求影响了设计。如果能用不同的方法来满足需求且这些方法都是可接受的，那么需求的详细程度也就足够了。然而，如果评审软件需求规格说明的设计人员对客户的意图还不甚了解，那么就需要增加额外的说明，以减少由于误解而产生返工的风险。第4章 需求开发和需求管理 4.6.4 需求验证需求验证验证是为了确保需求说明准
50、确、完整地表达了必要的质量特点。在阅读软件需求规格说明(SRS)时，可能觉得需求是对的，但实现时很可能会出现问题。当以需求说明为依据编写测试用例时，就可能会发现说明中的二义性。所有这些都必须修改，因为需求说明要作为设计和最终系统验证的依据。审查需求文档。对需求文档进行正式审查是保证软件质量的有效方法。组织一个由不同代表(如分析人员、客户、设计人员、测试人员)组成的小组，对SRS及相关模型进行仔细的检查。另外，在需求开发期间所做的非正式评审也是有益的。第4章 需求开发和需求管理 以需求为依据编写测试用例。根据用户需求要求的产品特性编写黑盒功能测试用例，客户通过使用测试用例以确认是否达到了期望的要
