1、1软件需求（第 2 版），清华大学出版社，2004-11-1【原书名】 Software Requirements,Second Edition 原书信息 【原出版社】 Microsoft Press 【作者】 （美）Karl E.Wiegers 【译者】 刘伟琴 刘洪涛 【开本】 185260 【页码】 357 1 软件需求基础知识 .11.1 软件需求的定义 .31.1.1 对需求的不同解释 .41.1.2 需求的 层次 .41.1.3 不属于需求的内容 .61.2 需求的开发与管理 .61.2.1 需求开发 .71.2.2 需求管理 .71.3 所有项目都有需求 .81.4 优秀的团队遇
2、到糟糕的需求 .91.4.1 用户参与不足 .91.4.2 用户需求扩展 .101.4.3 有歧义的需求 .101.4.4 镀金问题 .101.4.5 过于抽象的需求 .111.4.6 忽略了某类用户 .111.4.7 不准确的计划 .111.5 优质需求过程的好处 .111.6 优秀需求的特点 .121.6.1 需求陈述的特点 .121.6.2 需求规格说明的特点 .131 软件需求基础知识“您好。是 Phil 么？我是人力资源部的 Maria。我 们使用您做的 人事管理系统时遇到点问题。有位女职员想把名字改成 Sparklc Starlight，可我们在系统里怎么都改不过来。能帮帮忙吗？”
3、“她嫁了一个姓 starlight 的人么？ ”“没有，她没结婚，只是改了名字。”Maria 答道，“所以才有这样的麻烦。好像只有在婚姻状况改变时才能改名字。”“是的。我从来没想过谁会无缘 无故地改名字。我 们讨论系 统的时候您可没跟我提过这种可能。所以只能从修改婚姻状况的对话框进入修改名字的对话 框。 ”“谁都可以改名字。只要他愿意，随时都行，这是合法的。我以为您知道呢。 ”Maria 说， “星期2五之前必须搞定，不然 Sparklc 就兑换不了支票。您能在那之前把这个错误改过来么？”“这根本就不是错误！”Phil 反驳道，“我从来不知道您需要这个功能。我正忙看做一个新的性能评估系统。而且
4、我还要对 人事管理系统进行一些修改，”（话筒里传来翻纸的声音），“对，这就有一个。月底没准能改好，这周肯定不行，抱歉。下回早点儿告诉我，麻烦把问题写下来。”“我怎么跟 Sparkle 说？”Maria 问， “光不了支票她就得赊账。”“搞清楚，Maria，速可不是我的错。 ”Phil 抗议了，“如果您当时告诉我要能随时修改姓名，就不会有今天的事。您不能怪我没猜到您的想法。”Maria 很生气却无可奈何，只好气冲冲地 说：“好了。就是 这 种事让我恨透了计算机。改好了马上通知我，这总可以吧。”如果您曾经有过这种客户经历，您肯定明白这种连最基本的操作都完不成的软件多么让人烦恼。即便开发人员最终可能
5、会帮您改好，您通常也不愿总求助于他。然而，站在开发人员的立场，如果系统完成后才从用户那里得知需要什么功能，也的确很难接受。已经完全按最初的要求实现了系统，却不得不停下手头的项目去修改系统以便满足用户的新需求，这也是件很讨厌的事。许多软件问题都源于收集、记录、协商和修改产品需求过程中的方式不当。前面 Phil和 Maria 的例子中就有这些方面的问题，包括信息收集方式不正规，没有明确提出想要的功能，假设是未经沟通的错误假设，需求的定义不够充分，以及未经仔细考虑进行需求变更等。很少有人会甩给建筑商 30 万美金而不详细说明自己对房子的想法和要求。相反，他们会不厌其烦地提出各种细节要求。要对房子进行
6、改造就得掏钱，购房者尽管不情愿，却都能理解。然而，在软件开发中遇到同样问题时，人们却常常轻率地将其忽略。软件项目中40%60%的缺陷都是由需求分析阶段的过失所致（Davls 1993；LcRngwcll 997）。对欧洲软件行业所做的大规模调查显示：确定和管理用户需求是问题最多的两个环节（ESPITI 1995）。尽管如此，许多组织仍然没有采取有效手段来实施这两个必要的项目活动。由此导致的结果常常是用户和开发者之间产生需求的鸿沟二者对产品需求的理解相去甚远。软件或系统项目涉众（stake ho1dcr，产品或项目相关人员）的利益之间的相互作用在需求过程中表现得最为强烈。项目涉众包括： 客户：为
7、达到其公司的业务目标而投资项目或购买产品。 用户：直接或间接与产品打交道，是客户的一部分。 需求分析员：负责编写需求并传达给开发团队。 开发人员：设计、实现和维护产品。 测试人员：确定产品的行为是否与预计的相一致。 文档编制人员：负责编写用户手册、培训资料和系统帮助。 项目经理：制定项目计划并带领开发人员获得成功。 法律人员：确保产品符合所有相关法规。 生产人员：制造包含该软件的产品。 市场营销、技术支持及其他与产品和客户打交道的人员。如果处理得当，各方利益的相互作用将能够使产品获得成功，同时使客户感到满意，并使开发人员充满成就感；否则，就会导致误解、挫折和矛盾，从而降低产品的质量和商业价值。
8、由于需求是软件开发和项目管理活动的基础，所以涉众必须承诺遵循有效的需求3过程。但是开发和管理需求绝非易事，没有任何捷径与魔法。由于很多组织被一些同样的问题所困扰，所以我们可以寻找共同的解决方法，以用于多种不同的情况。本书介绍了很多这类方法。虽然都是以新系统的开发为背景引入这些方法，但其中大部分其实也适用于项目维护和选用现成的商业软件（参见第 16 章）。这些需求开发及管理方法并非只适用于采用顺序式瀑布型开发生命周期的项目，即使采用增量开发模式的项目开发小组也需要知道每次该增加什么功能。本章将帮助您： 理解软件需求工程的一些重要术语。 区分需求开发与需求管理。 保持对潜在的与需求相关的问题的警觉
9、性。 了解完善的需求应该具备的特征。为自己把脉只要对照下面各项来检查最新的项目，就能对组织的项目需求状况作出快速评估。如果项目中有 3 项与以下情况符合，那就读读这本书吧。 项目的前景（vision）和范围（scope）未曾明确定义。 客户太忙，没时间与需求分析员和开发人员一起讨论需求。 用户代理，如生产经理、开发经理、用户负责人或营销人员，自诩可以代表用户，其实他们不能准确说出用户的需要。 需求只存在于组织中那些所谓专家的脑子里，没有被记录下来。 客户坚持所有需求都很重要，不愿排出它们的优先次序。 开发人员在编码过程中发现需求有歧义，缺少足够的信息，只能去猜测。 开发人员与客户沟通时只关心用
10、户界面，忽略了用户需要用软件去做什么。 客户签字确认了需求却又一直提出修改要求。 项目范围接受需求变更而扩大，却没有相应地增加投入或减裁功能，进度因此被延误。 需求变更的请求被弄丢，开发人员和客户都不了解所有变更请求的状态。 开发人员按客户要求实现的功能无人问津。 需求规格说明（SRS）中的要求都实现了，客户却不满意。1.1 软件需求的定义软件行业存在这样一个问题，用于描述需求工作的术语没有统一的定义。对同一项需求，不同的人会有不同的描述，称其为用户需求、软件需求、功能需求、系统需求、技术需求、业务需求或产品需求。客户对需求的定义，在开发人员看来可能只是高级别的产品概念；而开发人员的需求概念对
11、用户来说也许就是详细的用户界面设计。定义的多样性导致了令人迷惑和沮丧的沟通问题。需求必须被记录成文档，这一点很重要。我曾在一个项目中经历过开发人员的角色轮换。每次轮换后，新任需求分析员都跑来对客户说：“我们来谈谈需求吧。”客户不胜其烦，回答也变得很不客气：“我早就把需求告诉您那些前任了，赶紧把系统给我做出来！”实际情况是没有谁把需求写下来，所以每位新任分析员都只能从头开始。仅凭一堆电子邮件、4语音邮件、便条、会议记录，以及对走廊中几次交谈的模糊印象就自称掌握了需求，那纯属自欺欺人。1.1.1 对需求的不同解释咨询专家 Brian Lawrcnce 提出，需求是“任何促成设计决策的因素”。很多信
12、息都属于这一范围。IEEE 的软件工程标准术语表（ 199则将需求定义为： 用户为解决某个问题或达到某个目标而需具备的条件或能力。 系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。 上述第一项或第二项中定义的条件和能力的文档表达。这一定义既体现了用户对需求的看法（系统的外部行为），也代表了开发人员的观点（一些深层的特性）。术语用户隶属于涉众，因为并非所有涉众都是用户。我对需求的理解是：产品为向涉众提供价值而必须具备的特性。下面这条定义则确认了需求类型的多样性（Sommerville 和 Sawyer 1997）：需求是对应该实现什么功能的说明可以是对系统运行
13、方式或系统特征与属性的描述；还可能是对系统开发过程的约束。很显然，对于需求是什么没有一个统一的定义。为便于交流，我们需要协商决定一组限定词用来修饰“需求”这个内涵丰富的术语，并认识到用可通用的形式记录需求的重要性。注意 不要一厢情愿地认为项目涉众对需求的理解是一致的。应该事先给出定义，才能保证大家谈论的是同一个问题。51.1.2 需求的层次本节将给出我对需求工程领域一些常用术语的定义。软件需求包括 3 个不同的层次业务需求、用户需求和功能需求。除此之外，每个系统还有各种非功能需求。图 1-1 中的模型给出了各种需求关系的示意图。和其他所有模型一样，这个模型也不能面面俱到，但它确实有助于理解需求
14、的整体概念。图中的椭圆代表各类需求信息，矩形则是存储这些信息的载体（文档、图形或数据库）。图 1-1 各种需求的关系图注：第 7 章中介绍了各种需求的示例。业务需求（Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目的投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。我喜欢用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。如何生成这份文
15、档是第 5 章的主题。定义项目范围是控制范围扩大这个常见问题的第一步。用户需求（user requirement ）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什6么。例如，在航空公司、汽车出租公司或酒店的网站上“预订”就是一个用例。注 第 8 章专门讨论了用户需求。功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（behavioral requirement），因为习惯上总
16、是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户己接受其预定”。功能需求描述的是开发人员需要实现什么。第 10 章将举例说明这点。术语系统需求（system requirement）用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件子系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。我们小组曾编写过一个用来操纵实验室设备的软件。它能控制这些设备给整排烧杯加入精确数量的化学药品（把这项乏味的工作自动化）。我们根据整个系统的需求推导出软件子系统的功能需求：向硬件发送信号来移动加药的喷头，读取定位传感器，开泵和关泵。业务规则
17、包括企业方针、政府条例、工业标准、会计准则和计算方法等。第 9 章中指出业务规则本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。功能需求记录在软件需求规格说明（SRS）中。SRS 完整地描述了软件系统的预期特性。以下提到 SRS 时都把它当作文档，其实，SRS 还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息（参见第 21 章）；而对于小型
18、项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到SRS。除了功能需求外，SRS 中还包含非功能需求，包括性能指标和对质量属性的描述。质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界之间的外部界面，以及对设计与实现的约束。约束（constraint）限制了开发人员设计和构建系统时的选择范围。人们经常谈论到产品特性。所谓特性（feature ），是指一组逻辑上相关的功能需求，它们为用户提
19、供某项功能，使业务目标得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和与用户的任务相关的需求不完全是一回事。Web 浏览器的收藏夹和书签，拼写检查，宏录制，汽车的电动车窗，免税代码的在线更新，电话的快速拨号功能以及病毒特征的自动更新都是产品特性的例子。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。为了更好地掌握前面提到的几类需求，我们举一个字处理程序的例子。它可能有这样一项业务需求：“产品允许用户轻松地更正文档中的拼写错误。”因此该产品的包装盒上列出了拼写检查器这
20、一功能特性。对应的用户需求则可能包括“找出拼写错误”和“把单词添加7到词典中”这样一些任务，或者叫作用例。拼写检查器有多项独立的功能需求对应于各种操作，例如找到并突出显示拼错的单词，用对话框显示修改建议，用正确的单词替换整篇文档中同一单词的所有拼写错误。还有一项称为可用性（usability）的质量属性，它规定了业务需求中“有效”（efficiently）一词的含义。管理人员或市场营销人员负责定义软件的业务需求，以提高公司的运营效率（对信息系统而言）或产品的市场竞争力（对商业软件而言）。所有的用户需求都必须符合业务需求。需求分析员从用户需求中推导出产品应具备哪些对用户有帮助的功能。开发人员则根
21、据功能需求和非功能需求设计解决方案，在约束条件的限制范围内实现必需的功能，并达到规定的质量和性能指标。图 1-1 中的模型显示的是一个自顶向下的单向需求流，没能反映出业务需求、用户需求与功能需求之间可能存在的循环和迭代关系。当一项新的特性、用例或功能需求被提出时，需求分析员必须思考这样一个问题：“它在范围内吗？”。如果答案是肯定的，则该需求属于需求规格说明，反之则不属于。但答案也许是“不在，但应该在”，这时必须由业务需求的负责人或投资管理人来决定：是否扩大项目范围以容纳新的需求。这是一个可能影响项目进度和预算的商业决策。1.1.3 不属于需求的内容需求规格说明中不包括（除已知约束外的）设计和实
22、现的细节、项目的计划信息，以及测试信息（Lcffngwcll 和 Widrig 2000）。把这些内容与需求分开，就可以把需求活动的注意力集中到了解开发小组需要开发的产品特性上。项目中通常还包括其他类型的需求，如开发环境需求，进度或预算限制，帮助新用户跟上进度的培训需求，或者发布产品使其转入支持环境的需求。这些都属于项目需求而不是产品需求，因此不属于本书讨论的范围。1.2 需求的开发与管理需求领域的术语问题如此突出，甚至对这门学科的称呼都很混乱。有的作者称其为需求工程（SommCrville 和 Kotonya 1998）；也有人称之为需求管理（Leffngwell 和Widrig2000）。
23、我找到一个好办法解决这个问题，就是把软件需求工程划分为需求开发（本书第部分讨论的内容）和需求管理（在第部分讨论），如图 1-2 所示。图 1-2 软件需求工程的组成81.2.1 需求开发需求开发可进一步细分为获取（Elicitation）、分析（analysis）、规格说明（specification）和确认（validation）（Abran 和 Moore 2001）。这些子学科涵盖了为软件和软件相关产品收集、评估和记录需求相关的所有活动，包括： 确定产品将要面对的各类用户。 从各类用户的代表处收集需求。 了解用户的任务和目标，以及这些任务要实现的业务目标。 分析从用户处得到的信息，将用户
24、的任务目标与功能需求、非功能需求、业务规则、解决方案建议及其他无关信息区分开来。 将顶层的需求分配到系统构架内定义好的软件组件中。 了解各质量属性的相对重要性。 协商需求的实现优先级。 将收集的用户需求表述为书面的需求规格说明和模型。 审阅需求文档，以确保在认识上与用户声明的需求相一致。应在开发小组接受需求之前解决所有分岐。迭代（1tcrat1On ）是需求开发成功的关键。需求开发计划应包含多个周期，每个周期包括研究需求，细化高层需求以及请用户确认需求的正确性。这一过程很费时而且可能会遇到挫折，但却是定义软件新产品时消除不确定性所必需的过程。1.2.2 需求管理需求管理的任务是“与客户就软件项
25、目的需求达成并保持一致”（Pau1k et a11995）。这种一致应体现在书面的需求规格说明和模型中。取得用户认可只满足了批准需求所需的一半条件，还必须让开发人员接受需求规格说明并同意在产品中加以实现。需求管理包括下列活动： 定义需求基线（某一时刻，对特定版本中己达成一致的需求内容的描述） 审查需求变更请求，评估其可能产生的影响以决定是否批准 以可控的方式将准的需求变更融入项目中 保持项目计划与需求的同步 估计需求变更的影响，在此基础上协商新的需求约定 跟踪每项需求，找到与其对应的设计、源代码和测试用例（test casc） 在项目开发过程中，始终跟踪需求的状态和变更图 1-3 从另一个角度
26、反映了需求开发与需求管理间的区别。本书介绍了很多用于获取需求、分析需求、说明截验证和管理需求的特殊技巧。9图！3 需求开发与需求管理的分界1.3 所有项目都有需求在 1987 年发表的那篇经典文章“没有银弹：软件工程本与未”中，Frederick Brooks 雄辩地指出了需求在软件项目中的重要地位：软件系统开发过程中最难的部分是对要开发什么作出准确的判断。所有概念性工作中最难的是建立详细的技术需求，包括所有与用户、机器和其他软件系统的接口。这部分工作的错误对最终系统的破坏最大，也最难纠正。开发应用软件或包含软件的系统是为了帮助用户改善生活。花在了解用户需求上的时间是保证项目成功的高回报的投入
27、。如果不记下与客户商定的需求，开发人员怎么可能让客户满意？即便是开发非商业用途的软件，如开发小组内部使用的函数库、软件组件和工具，也应该充分理解需求。在开始开发软件之前，往往无法确定所有的需求。这种情况下，可以采用迭代和增量方法，每次实现一部分需求，得到用户反馈后再进入下一循环。但是不能以此为借口直接开始编码，不事先仔细分析下一次循环的需求。编码迭代的代价要比设计思想的迭代高得多。人们有时会拒绝花时间记录需求。其实记录需求并不难，难的是发现需求。记录需求主要是阐明、详细描述和抄录需求等工作。对产品需求的充分理解能够确保开发团队有的放矢，找出问题的最佳解决方案。有了需求，就可以按优先次序排列工作
28、，对项目所需的人力和资源进行估算。不了解需求，就无法确定项目何时能够完成以及是否达到目标，并且无法在范围必须缩小时做出取舍。没有理所当然的需求我最近遇到这样一个开发小组，他们使用自己开发的软件工程工具，其中包括一个源代码编辑器。不幸的是，尽管大家都认为该工具应该具有代码打印功能，但谁都没有明确指出这一点。结果，在组织代码评审时，开发人员只能亲手抄写代码。即使是不言自明或理所当然的需求，如果没有把它写下来，软件没能满足用户的要求10也就不足为怪了。要经常问问“我们作了哪些假设？”，让隐藏的想法显现出来。在讨论需求的过程中，如果遇到假设，要把它记下来并进行确认。开发一个换代系统时，必须研究原有系统
29、的特性后再决定是否在新的系统中保留它们，而不是想当然。1.4 优秀的团队遇到糟糕的需求需求问题导致的主要后果是返工重复做您认为早已做好的事情。返工的成本占了总开发成本的 30%50%（Boehm 和 Papaccio 1988），而对于返工的情况，70%80%是因需求错误引起的（Leffngwel1 1997）。从图 1-4 可以看出，在项目末期才发现缺陷，对其进行改正的成本要比在缺陷刚产生不久时修改的成本高得多。防止需求错误的发生并及早发现它们，对于减少返工功效十分显著。试想如果能把返工减少一半，您的生活将会多么不同：您可以更快地开发出产品，即便不用通宵达旦地工作，您也能在同样的时间里开发出
30、比原来更多更好的产品。需求实践中的种种不足会给项目的成功带来很多风险。“成功”是指以商定的成本和进度交付满足用户对功能和质量的期望的产品。第 23 章中讲述了如何控制这些风险使项目不致因其而脱轨。以下几节将介绍一些最常见的与需求相关的风险。图 1-4 不同阶段改正缺陷的开销比较1.4.1 用户参与不足客户常常不能理解为什么必须下这么大力气去收集需求和保证需求质量。开发人员往往往往不重视用户的参与，原因是他们认为与用户打交道不像写代码那么有趣，或者自以为已经知道了用户想要什么。有些时候，与产品实际的使用者直接联系很困难，而用户代理方又不能完全理解用户的真正需求。用户参与不足将导致不能在项目早期及时发现需求中的缺陷，从而延误项目的完成。在整个项目开发过程中，开发团队必须始终与实际用户直接合作。第 6 章解释了这种合作的不可替代性。1.4.2 用户需求扩展由于开发过程中需求的不断发展与增加，项目往往会落后于计划的进度并超出预算。出现这种情况是因为没有依据对需求的规模和复杂度的实际评估来制订计划，而不断修改
