1、1软件需求（第 2 版）教案陶铮 2007 年 3 月目录1 软件需求基础知识 .21.1 软件需求的定义 .21.1.1 对需求的不同解释 .31.1.2 需求的层次 .31.1.3 不属于需求的内容 .61.2 需求的开发与管理 .61.2.1 需求开发 .61.2.2 需求管理 .71.3 所有项目都有需求 .81.4 优秀的团队遇到糟糕的需求 .81.4.1 用户参与不足 .91.4.2 用户需求扩展 .91.4.3 有歧义的需求 .101.4.4 镀金问题 .101.4.5 过于抽象的需求 .101.4.6 忽略了某类用户 .101.4.7 不准确的计划 .101.5 优质需求过程的
2、好处 .111.6 优秀需求的特点 .111.6.1 需求陈述的特点 .111.6.2 需求规格说明的特点 .1321 软件需求基础知识章首案例的概括总结见课件。本章要点：（1）需求的重要性 软件问题主要在于需求：许多软件问题都源于收集、记录、协商和修改产品需求过程中的方式不当。包括信息收集方式不正规，没有明确提出想要的功能，连假设也是未经沟通的错误假设，需求的定义不够充分，以及未经仔细考虑进行需求变更等。 需求问题造成很大的麻烦：软件项目中 40%60% 的缺陷都是由需求分析阶段的过失所致。 需求问题，一是轻视，而是不得方法：许多组织仍然没有采取有效手段来实施这两个必要的项目活动。由此导致的
3、结果是用户和开发者之间产生需求的鸿沟。（2）软件项目知识项目涉众 客户：为达到其公司的业务目标而投资项目或购买产品。 用户：直接或间接与产品打交道，是客户的一部分。 需求分析员：负责编写需求并传达给开发团队。 开发人员：设计、实现和维护产品。 测试人员：确定产品的行为是否与预计的相一致。 文档编制人员：负责编写用户手册、培训资料和系统帮助。 项目经理：制定项目计划并带领开发人员获得成功。 法律人员：确保产品符合所有相关法规。 生产人员：制造包含该软件的产品。 市场营销、技术支持及其它与产品和客户打交道的人员。理解涉众，关键在于“只有涉众承诺遵循有效的需求过程，才能为软件开发和项目管理活动奠定基
4、础。本章讲授内容： 软件需求工程的一些重要术语。 需求开发与需求管理。 注意潜在的与需求相关的问题。 完善的需求应该具备哪些特征。1.1 软件需求的定义术语混乱：3用户需求、软件需求、功能需求、系统需求、技术需求、业务需求或产品需求。一般的误解: 开发人员看到客户对需求说法，认为只是高级别的产品概念；用户看到的开发人员的需求描述，认为是用户界面设计。需求定义，即用文字进行规范地、正确地、完整地描述。需求必须被记录成文档。1.1.1 对需求的不同解释需求的几种定义，都很有参考价值。1. 咨询专家 Brian Lawrcnce 提出，需求是“任何促成设计决策的因素”。很多信息都属于这一范围。2.
5、IEEE 的软件工程标准术语表（ 199则将需求定义为： 用户为解决某个问题或达到某个目标而需具备的条件或能力。 系统或系统组件为符合合同、标准、规范或其它正式文档而必须满足的条件或必须具备的能力。 上述第一项或第二项中定义的条件和能力的文档表达。3. 作者对需求的理解：需求是产品为向涉众提供价值而必须具备的特性。4. 需求类型的多样性（Sommerville 和 Sawyer 1997）：需求是对应该实现什么功能的说明可以是对系统运行方式或系统特征与属性的描述；还可能是对系统开发过程的约束。1.1.2 需求的层次本节的内容十分重要。需求工程领域一些常用术语的定义。软件需求包括 3 个不同的层
6、次：1. 业务需求2. 用户需求3. 功能需求。除此之外，每个系统还有各种非功能需求。重要：图 1-1 中的模型给出了各种需求关系的示意图。图中的椭圆代表各类需求信息，矩形则是存储这些信息的载体（文档、图形或数据库）。4图 1-1 各种需求的关系图注：第 7 章中介绍了各种需求的示例。三大需求1. 业务需求（Business requirement ）表示组织或客户高层次的目标。业务需求通常来自项目的投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。本书规定用前景和范围（vision and scope）文档来记
7、录业务需求。见第 5 章的主题（作为实验 3 内容）。任务是：定义项目范围（随后会发生如何控制范围扩大的问题）。2.用户需求（user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用户需求描述的是软件使用者（用户）使用系统能够完成什么业务任务或信息处理工作。具体内容是用例、场景描述和事件-响应表等。见第 8 章（作为实验 4）。3.功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成那些满足业务需求的具体的任务。功能需求有时也被称作行为需求（behavioral requirement），描述的是
8、软件的行为性活动。功能需求描述的是开发人员需要实现什么。第 10 章将举例说明这点。如：“系统应该发送电子邮件来通知用户己接受其预定”。5术语系统需求（system requirement）用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件子系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。第 9 章中指出业务规则本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有
9、时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。功能需求记录在软件需求规格说明（SRS）中。SRS 完整地描述了软件系统的预期特性。 SRS 还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息（参见第 21 章），甚至可能是一叠索引卡片。 SRS 对于软件设计、开发、测试、质量保证、项目管理和其它相关的项目功能都十分重要。SRS 中还包含 非功能需求，包括性能指标和对质量属性的描述。质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。包括可
10、用性、可移植性、完整性、效率和健壮性，还包括系统外部界面，以及对设计与实现的约束。约束（constraint）限制了开发人员设计和构建系统时的选择范围。字处理程序的例子。业务需求：“产品允许用户轻松地更正文档中的拼写错误。”因此该产品的包装盒上列出了拼写检查器这一功能特性。用户需求：包括“找出拼写错误”和“把单词添加到词典中”这样一些任务，或者叫作用例。功能需求：如找到并突出显示拼错的单词，用对话框显示修改建议，用正确的单词替换整篇文档中同一单词的所有拼写错误。结合非功能需求，介绍：可用性（usability）的质量属性，它规定了业务需求中“有效”（efficiently）一词的含义。增加的内
11、容：（1） 可用性指标（2） 网站质量评价要素下面的内容，分散到业务需求、用户需求、功能需求中给予提示：管理人员或市场营销人员负责定义软件的业务需求，以提高公司的运营效率（对信息6系统而言）或产品的市场竞争力（对商业软件而言）。所有的用户需求都必须符合业务需求。需求分析员从用户需求中推导出产品应具备哪些对用户有帮助的功能。开发人员则根据功能需求和非功能需求设计解决方案，在约束条件的限制范围内实现必需的功能，并达到规定的质量和性能指标。图 1-1 中的模型，需要强调：（1） 是一个自顶向下的单向需求流，没能反映出业务需求、用户需求与功能需求之间可能存在的循环和迭代关系。（2） 范围问题：当一项新
12、的特性、用例或功能需求被提出时，需求分析员必须思考这样一个问题：“它在范围内吗？”。（3） 不能确定的，必须由业务需求的负责人或投资管理人来决定：是否扩大项目范围以容纳新的需求。这是一个可能影响项目进度和预算的商业决策。1.1.3 不属于需求的内容主要指明：需求分析内容不包含设计与实现技术的细节。需求规格说明中不包括（除已知约束外的）设计和实现的细节、项目的计划信息，以及测试信息（Lcffngwcll 和 Widrig 2000）。把这些内容与需求分开，就可以把需求活动的注意力集中到了解开发小组需要开发的产品特性上。项目中通常还包括其它类型的需求，如开发环境需求，进度或预算限制，帮助新用户跟上
13、进度的培训需求，或者发布产品使其转入支持环境的需求。这些都属于项目需求而不是产品需求，因此不属于本书讨论的范围。1.2 需求的开发与管理此部分内容属于软件工程分支领域，是今后的课题。需求领域的术语问题如此突出，甚至对这门学科的称呼都很混乱。有的作者称其为需求工程（SommCrville 和 Kotonya 1998）；也有人称之为需求管理（Leffngwell 和Widrig2000）。我找到一个好办法解决这个问题，就是把软件需求工程划分为需求开发（本书第部分讨论的内容）和需求管理（在第部分讨论），如图 1-2 所示。图 1-2 软件需求工程的组成71.2.1 需求开发此处内容，作为本课程实验
14、 3，4，5 的过程要求 要求在实验中体会下述活动：1. 确定你将要面对的各类用户。2. 了解用户的业务知识和用户的任务与目标。3. 分析自己获得的信息，把用户任务目标分解为用户需求与与功能需求（非功能需求）。4. 分析有关的质量属性及其重要性。5. 编写需求规格说明，配合模型的建立。6. 审阅需求文档，以确保在认识上与用户声明的需求相一致。需求开发可进一步细分为获取（Elicitation）、分析（analysis）、规格说明（specification）和确认（validation）（Abran 和 Moore 2001）。这些子学科涵盖了为软件和软件相关产品收集、评估和记录需求相关的所有
15、活动，包括： 确定产品将要面对的各类用户。 从各类用户的代表处收集需求。 了解用户的任务和目标，以及这些任务要实现的业务目标。 分析从用户处得到的信息，将用户的任务目标与功能需求、非功能需求、业务规则、解决方案建议及其它无关信息区分开来。 将顶层的需求分配到系统构架内定义好的软件组件中。 了解各质量属性的相对重要性。 协商需求的实现优先级。 将收集的用户需求表述为书面的需求规格说明和模型。 审阅需求文档，以确保在认识上与用户声明的需求相一致。应在开发小组接受需求之前解决所有分岐。强调：迭代（iteration）是需求开发成功的关键。1.2.2 需求管理需求管理的任务是“与客户就软件项目的需求达
16、成并保持一致”（Pau1k et a11995）。这种一致应体现在书面的需求规格说明和模型中。取得用户认可只满足了批准需求所需的一半条件，还必须让开发人员接受需求规格说明并同意在产品中加以实现。需求管理包括下列活动： 定义需求基线（某一时刻，对特定版本中己达成一致的需求内容的描述） 审查需求变更请求，评估其可能产生的影响以决定是否批准 以可控的方式将准的需求变更融入项目中8 保持项目计划与需求的同步 估计需求变更的影响，在此基础上协商新的需求约定 跟踪每项需求，找到与其对应的设计、源代码和测试用例（test casc） 在项目开发过程中，始终跟踪需求的状态和变更图 1-3 从另一个角度反映了需
17、求开发与需求管理间的区别。本书介绍了很多用于获取需求、分析需求、说明截验证和管理需求的特殊技巧。图！3 需求开发与需求管理的分界1.3 所有项目都有需求此处内容的本质是，需求的重要意义。 我们只要知道： 软件系统开发过程中最难的部分是什么？需求开发。 所有概念性工作中最难的是什么？建立详细的技术需求。 在无法确定所有的需求的情况下怎么办？采用迭代和增量方法，每次实现一部分需求，得到用户反馈后再进入下一循环。 没有理所当然的需求1.4 优秀的团队遇到糟糕的需求本节内容主要在于：需求开发不是个别人的事情，是一个软件团队全体的任务。需求问题导致返工，是很好的说明。图 1-4。9作为将来的职业，需要知
18、道这些知识，但本课不讲，自学。需求问题导致的主要后果是返工重复做您认为早已做好的事情。返工的成本占了总开发成本的 30%50%（Boehm 和 Papaccio 1988），而对于返工的情况，70%80%是因需求错误引起的（Leffngwel1 1997）。从图 1-4 可以看出，在项目末期才发现缺陷，对其进行改正的成本要比在缺陷刚产生不久时修改的成本高得多。防止需求错误的发生并及早发现它们，对于减少返工功效十分显着。试想如果能把返工减少一半，您的生活将会多么不同：您可以更快地开发出产品，即便不用通宵达旦地工作，您也能在同样的时间里开发出比原来更多更好的产品。需求实践中的种种不足会给项目的成功
19、带来很多风险。“成功”是指以商定的成本和进度交付满足用户对功能和质量的期望的产品。第 23 章中讲述了如何控制这些风险使项目不致因其而脱轨。以下几节将介绍一些最常见的与需求相关的风险。图 1-4 不同阶段改正缺陷的开销比较1.4.1 用户参与不足开发人员往往往往不重视用户的参与，原因是他们认为与用户打交道不像写代码那么有趣，或者自以为已经知道了用户想要什么。有些时候，与产品实际的使用者直接联系很困难，而用户代理方又不能完全理解用户的真正需求。用户参与不足将导致不能在项目早期及时发现需求中的缺陷，从而延误项目的完成。在整个项目开发过程中，开发团队必须始终与实际用户直接合作。第 6 章解释了这种合
20、作的不可替代性。1.4.2 用户需求扩展不依照对于需求的规模和复杂度的实际评估来制订计划，而不断修改需求又使情况变得更糟。原因主要是需求的不断发展与增加，项目往往会落后于计划的进度并超出预算。要控制项目范围的改变，首先应明确项目的业务目标、全局规划、范围、限制、成功标准以及产品的预计用途。然后参考这一框架对所有新特性和需求变更进行评估。还有软件开发中的质量问题：随着变更在产品内部的扩散，项目的原有结构可能逐渐瓦解。造成许多代码补丁，使得程序更难理解和维护。10 插入的代码可能导致模块违反强内聚和弱耦合这一设计原则。 要减少需求变更对质量造成的影响，处理变更时应该先对结构和设计进行适当的修改，而
21、不是直接修改代码。1.4.3 有歧义的需求歧义，是需求规约的大忌（LawrCncc 1995）。歧义表现为同一读者可以对一项需求声明作出多种解释，或者不同的读者对同一需求产生不同的理解。第 10 章列出了很多容易产生歧义、给读者造成负担的词语。产生歧义的另一个原因是需求不精确和没有充分细化。1.4.4 镀金问题以为 “用户肯定会喜欢的”，而实际上却是华而不实的需求就是所谓的“镀金问题（gold plating）”。注意：用户通常并不关心额外的功能。应该把创意和备选方案提交给客户。开发人员应该力求简洁，而不是自作主张去超越客户的需求。要避免镀金问题，就应该追溯每项功能的来源，弄清楚为什么添加该功
22、能。收集需求时，使用用例方法，有助于着重考虑可实现商业任务的功能需求。1.4.5 过于抽象的需求营销人员或经理经常喜欢只给出一个粗略的说明，希望开发人员在开发过程中充实它。这种方式只适合于那些研究性项目或需求特别灵活的项目。否则，这种做法会使开发人员受挫，让客户失望。1.4.6 忽略了某类用户这里描述的是“用户与产品的关系”。a) 如果一开始没能找出产品的所有重要用户群，就会有某些用户需求得不到满足。b) 确定所有用户群后，还要保证获得各类用户的需求用户所使用的产品特性、产品的使用频率以及用户自身的经验水平不尽相同。对某一产品，肯定存在下述情况：用户群体 产品特性 产品的使用频率 对该产品使用的经验ABC
