2022年软件需求基础知识

《2022年软件需求基础知识》由会员分享，可在线阅读，更多相关《2022年软件需求基础知识（13页珍藏版）》请在金锄头文库上搜索。

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有歧义的需求 . 10 1.4.4镀金问题 . 10 1.4.5过于抽象的需求. 10 1.4.6忽略了某类用户. 10 1.4.7不准确的计划 . 10 1.5优质需求过程的好处. 11 1

2、.6优秀需求的特点. 11 1.6.1需求陈述的特点. 11 1.6.2需求规格说明的特点. 13 精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 1 页，共 13 页1 软件需求基础知识章首案例的概括总结见课件。本章要点：（1）需求的重要性软件问题主要在于需求：许多软件问题都源于收集、记录、 协商和修改产品需求过程中的方式不当。包括信息收集方式不正规，没有明确提出想要的功能，连假设也是未经沟通的错误假设，需求的定义不够充分， 以及未经仔细考虑进行需求变更等。需求问题造成很大的麻烦：软件项目中40%60%的缺陷都是由需求分析阶段的过失所致。需求问题

3、， 一是轻视， 而是不得方法： 许多组织仍然没有采取有效手段来实施这两个必要的项目活动。由此导致的结果是用户和开发者之间产生需求的鸿沟。（2）软件项目知识项目涉众客户：为达到其公司的业务目标而投资项目或购买产品。用户：直接或间接与产品打交道，是客户的一部分。需求分析员：负责编写需求并传达给开发团队。开发人员：设计、实现和维护产品。测试人员：确定产品的行为是否与预计的相一致。文档编制人员：负责编写用户手册、培训资料和系统帮助。项目经理：制定项目计划并带领开发人员获得成功。法律人员：确保产品符合所有相关法规。生产人员：制造包含该软件的产品。市场营销、技术支持及其它与产品和客户打交道的人员。理解涉众

4、，关键在于“只有涉众承诺遵循有效的需求过程，才能为软件开发和项目管理活动奠定基础。本章讲授内容：软件需求工程的一些重要术语。需求开发与需求管理。注意潜在的与需求相关的问题。完善的需求应该具备哪些特征。1.1软件需求的定义术语混乱：用户需求、软件需求、功能需求、系统需求、技术需求、业务需求或产品需求。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 2 页，共 13 页一般的误解 : 开发人员看到客户对需求说法，认为只是高级别的产品概念；用户看到的开发人员的需求描述，认为是用户界面设计。需求定义，即用文字进行规范地、正确地、完整地描述。需求必须被记录成

5、文档。1.1.1对需求的不同解释需求的几种定义，都很有参考价值。1.咨询专家 Brian Lawrcnce提出， 需求是 “ 任何促成设计决策的因素” 。很多信息都属于这一范围。2.IEEE 的软件工程标准术语表（199则将需求定义为：用户为解决某个问题或达到某个目标而需具备的条件或能力。系统或系统组件为符合合同、标准、规范或其它正式文档而必须满足的条件或必须具备的能力。上述第一项或第二项中定义的条件和能力的文档表达。3.作者对需求的理解：需求是产品为向涉众提供价值而必须具备的特性。4.需求类型的多样性（Sommerville和 Sawyer 1997 ）： 需求是 对应该实现什么功能的说明

6、可以是对系统运行方式或系统特征与属性的描述；还可能是对系统开发过程的约束。1.1.2需求的层次本节的内容十分重要。需求工程领域一些常用术语的定义。软件需求包括3 个不同的层次：1.业务需求2.用户需求3.功能需求。除此之外，每个系统还有各种非功能需求。重要： 图 1-1 中的模型给出了各种需求关系的示意图。图中的椭圆代表各类需求信息，矩形则是存储这些信息的载体（文档、 图形或数据库） 。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 3 页，共 13 页图 1-1 各种需求的关系图注：第 7 章中介绍了各种需求的示例。三大需求1. 业务需求（ Bu

7、siness requirement）表示组织或客户高层次的目标。业务需求通常来自项目的投资人 、购买产品的 客户 、实际 用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。本书规定 用前景和范围（vision and scope ）文档来记录业务需求。见 第 5 章的主题 （作为实验 3 内容）。任务是：定义项目范围（随后会发生如何控制范围扩大的问题）。2.用户需求（ user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用户需求描述的是软件使用者（用户）使用系统能够完成什么业务任务或信息处理工作。具体内容

8、是 用例、场景描述和事件-响应表等。见第8 章（作为实验4）。3. 功能需求（ functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成那些满足业务需求的具体的任务。功能需求有时也被称作行为需求（behavioral requirement），描述的是软件的行为性活动。 功能需求描述的是开发人员需要实现什么。第 10 章将举例说明这点。如： “ 系统应该发送电子邮件来通知用户己接受其预定” 。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 4 页，共 13 页术语 系统需求（ system req

9、uirement）用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件子系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。第9 章中指出业务规则本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而， 业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时， 功能中特定的质量属性（通过功能实现） 也源于业务规则。 所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。功能需求记录在软件需求规格说明（SRS）中

10、。SRS完整地描述了软件系统的预期特性。SRS还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息 （参见第 21 章），甚至可能是一叠索引卡片。SRS对于软件设计、 开发、测试、质量保证、项目管理和其它相关的项目功能都十分重要。SRS中还包含 非功能需求，包括性能指标和对质量属性的描述。质量属性（ quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。包括可用性、可移植性、完整性、效率和健壮性，还包括系统外部界面，以及对设计与实现的约束。约束（ constraint）限制了开发人员设计和构建系统时的选择范围。字处理程序的例子。

11、业务需求： “ 产品允许用户轻松地更正文档中的拼写错误。” 因此该产品的包装盒上列出了拼写检查器这一功能特性。用户需求 ： 包括 “ 找出拼写错误 ” 和“ 把单词添加到词典中” 这样一些任务， 或者叫作用例。功能需求： 如找到并突出显示拼错的单词，用对话框显示修改建议，用正确的单词替换整篇文档中同一单词的所有拼写错误。结合非功能需求，介绍：可用性（ usability ）的质量属性，它规定了业务需求中“ 有效 ” （efficiently ）一词的含义。增加的内容：（1）可用性指标（2）网站质量评价要素下面的内容，分散到业务需求、用户需求、功能需求中给予提示：管理人员或市场营销人员负责定义软

12、件的业务需求，以提高公司的运营效率（对信息系统而言）或产品的市场竞争力（对商业软件而言）。所有的用户需求都必须符合业务需求。需求分析员从用户需求中推导出产品应具备哪些对用户有帮助的功能。开发人员则根据功能精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 5 页，共 13 页需求和非功能需求设计解决方案，在约束条件的限制范围内实现必需的功能，并达到规定的质量和性能指标。图 1-1 中的模型，需要强调：（1）是一个自顶向下的单向需求流，没能反映出业务需求、用户需求与功能需求之间可能存在的循环和迭代关系。（2）范围问题：当一项新的特性、用例或功能需求被提出

13、时，需求分析员必须思考这样一个问题：“ 它在范围内吗？” 。（3）不能确定的，必须由业务需求的负责人或投资管理人来决定：是否扩大项目范围以容纳新的需求。这是一个可能影响项目进度和预算的商业决策。1.1.3不属于需求的内容主要指明：需求分析内容不包含设计与实现技术的细节。需求规格说明中不包括（除已知约束外的）设计和实现的细节、项目的计划信息，以及测试信息 （Lcffngwcll和 Widrig 2000 ）。 把这些内容与需求分开，就可以把需求活动的注意力集中到了解开发小组需要开发的产品特性上。项目中通常还包括其它类型的需求，如开发环境需求， 进度或预算限制，帮助新用户跟上进度的培训需求，或者发

14、布产品使其转入支持环境的需求。这些都属于项目需求而不是产品需求，因此不属于本书讨论的范围。1.2需求的开发与管理此部分内容属于软件工程分支领域，是今后的课题。需求领域的术语问题如此突出，甚至对这门学科的称呼都很混乱。有的作者称其为需求工程 （SommCrville和 Kotonya 1998 ） ； 也有人称之为需求管理 （ Leffngwell和 Widrig2000 ） 。我找到一个好办法解决这个问题，就是把软件需求工程划分为需求开发（本书第部分讨论的内容）和需求管理（在第部分讨论），如图1-2 所示。图 1-2 软件需求工程的组成1.2.1需求开发此处内容，作为本课程实验3，4，5 的过

15、程要求精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 6 页，共 13 页要求在实验中体会下述活动：1.确定你将要面对的各类用户。2.了解用户的业务知识和用户的任务与目标。3.分析自己获得的信息，把用户任务目标分解为用户需求与与功能需求（非功能需求）。4.分析有关的质量属性及其重要性。5.编写需求规格说明，配合模型的建立。6.审阅需求文档，以确保在认识上与用户声明的需求相一致。需求开发可进一步细分为获取（Elicitation ）、分析（ analysis ）、规格说明（ specification ）和确认（ validation）（Abran

16、和 Moore 2001 ）。这些子学科涵盖了为软件和软件相关产品收集、评估和记录需求相关的所有活动，包括：确定产品将要面对的各类用户。从各类用户的代表处收集需求。了解用户的任务和目标，以及这些任务要实现的业务目标。分析从用户处得到的信息，将用户的任务目标与功能需求、非功能需求、业务规则、解决方案建议及其它无关信息区分开来。将顶层的需求分配到系统构架内定义好的软件组件中。了解各质量属性的相对重要性。协商需求的实现优先级。将收集的用户需求表述为书面的需求规格说明和模型。审阅需求文档， 以确保在认识上与用户声明的需求相一致。应在开发小组接受需求之前解决所有分岐。强调：迭代（ iteration）是

17、需求开发成功的关键。1.2.2需求管理需求管理的任务是“ 与客户就软件项目的需求达成并保持一致” （Pau1k et a11995）。这种一致应体现在书面的需求规格说明和模型中。取得用户认可只满足了批准需求所需的一半条件，还必须让开发人员接受需求规格说明并同意在产品中加以实现。需求管理包括下列活动： 定义需求基线（某一时刻，对特定版本中己达成一致的需求内容的描述） 审查需求变更请求，评估其可能产生的影响以决定是否批准 以可控的方式将准的需求变更融入项目中 保持项目计划与需求的同步估计需求变更的影响，在此基础上协商新的需求约定 跟踪每项需求，找到与其对应的设计、源代码和测试用例（test cas

18、c） 在项目开发过程中，始终跟踪需求的状态和变更图 1-3 从另一个角度反映了需求开发与需求管理间的区别。本书介绍了很多用于获取需求、精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 7 页，共 13 页分析需求、说明截验证和管理需求的特殊技巧。图！ 3 需求开发与需求管理的分界1.3所有项目都有需求此处内容的本质是，需求的重要意义。我们只要知道：软件系统开发过程中最难的部分是什么？ 需求开发。所有概念性工作中最难的是什么？ 建立详细的技术需求。在无法确定所有的需求的情况下怎么办？ 采用迭代和增量方法，每次实现一部分需求，得到用户反馈后再进入下一循环

19、。没有理所当然的需求1.4优秀的团队遇到糟糕的需求本节内容主要在于：需求开发不是个别人的事情，是一个软件团队全体的任务。需求问题导致返工，是很好的说明。图1-4。作为将来的职业，需要知道这些知识，但本课不讲，自学。需求问题导致的主要后果是返工 重复做您认为早已做好的事情。返工的成本占了总开发成本的30% 50%（Boehm 和 Papaccio 1988），而对于返工的情况，70%80%是因精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 8 页，共 13 页需求错误引起的（Leffngwel1 1997）。从图1-4 可以看出，在项目末期才发现缺陷

20、，对其进行改正的成本要比在缺陷刚产生不久时修改的成本高得多。防止需求错误的发生并及早发现它们， 对于减少返工功效十分显着。试想如果能把返工减少一半，您的生活将会多么不同：您可以更快地开发出产品，即便不用通宵达旦地工作，您也能在同样的时间里开发出比原来更多更好的产品。需求实践中的种种不足会给项目的成功带来很多风险。“ 成功 ” 是指以商定的成本和进度交付满足用户对功能和质量的期望的产品。第23 章中讲述了如何控制这些风险使项目不致因其而脱轨。以下几节将介绍一些最常见的与需求相关的风险。图 1-4 不同阶段改正缺陷的开销比较1.4.1用户参与不足开发人员往往往往不重视用户的参与，原因是他们认为与用

21、户打交道不像写代码那么有趣，或者自以为已经知道了用户想要什么。有些时候， 与产品实际的使用者直接联系很困难，而用户代理方又不能完全理解用户的真正需求。 用户参与不足将导致不能在项目早期及时发现需求中的缺陷，从而延误项目的完成。在整个项目开发过程中，开发团队必须始终与实际用户直接合作。第 6 章解释了这种合作的不可替代性。1.4.2用户需求扩展不依照对于需求的规模和复杂度的实际评估来制订计划，而不断修改需求又使情况变得更糟。原因主要是需求的不断发展与增加，项目往往会落后于计划的进度并超出预算。要控制项目范围的改变，首先应明确项目的业务目标、全局规划、范围、限制、成功标准以及产品的预计用途。然后参

22、考这一框架对所有新特性和需求变更进行评估。还有软件开发中的质量问题：随着变更在产品内部的扩散，项目的原有结构可能逐渐瓦解。造成许多代码补丁，使得程序更难理解和维护。插入的代码可能导致模块违反强内聚和弱耦合这一设计原则。要减少需求变更对质量造成的影响，处理变更时应该先对结构和设计进行适当的修改，而不是直接修改代码。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 9 页，共 13 页1.4.3有歧义的需求歧义，是需求规约的大忌（LawrCncc 1995 ）。歧义表现为同一读者可以对一项需求声明作出多种解释，或者不同的读者对同一需求产生不同的理解。第

23、10 章列出了很多容易产生歧义、给读者造成负担的词语。产生歧义的另一个原因是需求不精确和没有充分细化。1.4.4镀金问题以为“ 用户肯定会喜欢的” ，而实际上却是华而不实的需求就是所谓的“ 镀金问题（gold plating） ” 。注意： 用户通常并不关心额外的功能。应该把创意和备选方案提交给客户。开发人员应该力求简洁，而不是自作主张去超越客户的需求。要避免镀金问题，就应该追溯每项功能的来源，弄清楚为什么添加该功能。收集需求时，使用用例方法，有助于着重考虑可实现商业任务的功能需求。1.4.5过于抽象的需求营销人员或经理经常喜欢只给出一个粗略的说明，希望开发人员在开发过程中充实它。这种方式只适

24、合于那些研究性项目或需求特别灵活的项目。否则，这种做法会使开发人员受挫，让客户失望。1.4.6忽略了某类用户这里描述的是“用户与产品的关系”。a)如果一开始没能找出产品的所有重要用户群，就会有某些用户需求得不到满足。b)确定所有用户群后，还要保证获得各类用户的需求用户所使用的产品特性、产品的使用频率以及用户自身的经验水平不尽相同。对某一产品，肯定存在下述情况：用户群体产品特性产品的使用频率对该产品使用的经验A B C 1.4.7不准确的计划不能充分理解需求，就会作出过于乐观的估计，最终不可避免地陷入超支的泥潭。造成软件成本估算失败的最主要原因包括频繁变更需求、遗漏需求、未与用户充分沟通、精选学

25、习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 10 页，共 13 页需求的说明不精确，以及对需求的分析不透彻。给出估算结果时，应该提供范围（最好的情况、最可能和最糟的情况）或把握程度。1.5优质需求过程的好处软件需求过程究竟该是怎样的？我们将通过实验课程尝试建立。但目前条件限制， 我们还难以体会一下的好处：减少需求缺陷减少开发过程中的返工减少不必要的特性降低改进成本加快开发进度提高沟通效率控制需求范围的改变项目更有序对系统测试的评估更准确提高客户和开发人员的满意度1.6优秀需求的特点本节重要，但许多内容需要在实践中理解。如何才能将好的需求规格说明与那些

26、有问题的区分开来？这一节首先对说明中的单条需求（即需求声明）特点进行讨论，然后将介绍SRS 作为整体应具备的特点。如果想知道您的需求是否具备这些特点，最好的办法就是请几位项目相关人员仔细审阅您的SRS。不同的人会发现不同的问题。例如， 分析员和开发人员无法准确判断完备性和正确性，而用户则无法评价技术可行性。1.6.1需求陈述的特点理想情况下，每一项用户需求、业务需求和功能需求都应具备下列性质。完整性每一项需求都必须完整地描述即将交付使用的功能。它必须包合开发人员设计和实现这项功能需要的所有信息。如果发现缺少某项信息，应使用TBD （to be determined，待定）这一标准符号加以标明。

27、在开发系统的任一部分之前都必须解决需求中所有的TBD 。正确性每一项需求都必须准确地描述将要开发的功能。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 11 页，共 13 页判断正确性的参考是需求的来源，如实际用户和高级的系统需求。需求规约必须经过用户或用户信任的代理人的审阅。可行性需求必须能够在系统及其运行环境的已知能力和约束条件内实现。在需求的获取阶段，应安排一名开发人员始终和营销人员或需求分析员协同工作，由开发人员来进行可行性检查，判断技术上能够实现哪些需求，或者什么功能需要额外的成本才能实现。评估需求可行性的方法包括增量开发方法和概念证明（

28、 proof-of-concept）原型。概念证明（ proof-of-concept），基于建模 -使用 -开发 -证明 -试验运行 -验证结果的工程方法。必要性每一项需求记录的功能都必须是用户的真正需要，或者是为符合外部系统需求或某一标准而必须具备的功能。每项需求都必须来源于有权定义需求的一方。对每项需求都必须追溯至特定的客户需求的来源，譬如用例、业务规则或其它来源。有优先次序为每一项功能需求、特性或用例指定一个实现优先级，以表明它在产品的某一版本中的重要程度。 如果所有需求都被视为同等重要，项目经理就很难采取措施应对预算削减、进度拖后、人员流失或开发过程中需求增加等情况。注 第 14 章

29、将更详细地讨论如何设置优先级。补充知识：软件维护与软件产品版本升级。软件维护与软件产品版本升级有一定关系：例如：若小维护前的版本号为V1.00，则小维护后的版本号为V1.01；若大维护前的版本号为V1.01，则大维护后的版本号为V1.11。一般而言，版本号中小圆点的左一位，表示该软件产品的第几个版本。版本号中小圆点的右一位，表示该版本的大修改次数。版本号中小圆点的右二位，表示该版本的小修改次数。即一个版本的大修改最多是9 次，小修改最多是81 次。只有当该软件产品的运行环境发生大改变时，或者该软件产品的功能变化超过30% 时，其版本才能升级，此时，版本号中小圆点的左一位才能加1，由 V1.11

30、 变为 V2.00。无歧义一项需求声明对所有读者应该只有一种一致的解释，然而自然语言却极易产生歧义。编写需求时应该使用用户所在领域的、简洁明了的语言。“ 易理解 ” 是与 “ 无歧义 ” 相关的一个需求质量目标： 必须能够让读者理解每项需求究竟是指什么。应该在词汇表中列出所有专用的和可能让用户感到迷惑的术语。可验证性看看您能 否设计一些测试方法或使用其它验证方法，如检查或演示来判断产品是否正确实现了需求。 如果某项需求不可验证，那么判定其实现的正确与否就成了主观臆断，而不是精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 12 页，共 13 页客观分

31、析。但是，不完备、不一致、不可行或有歧义的需求也是不可验证的。1.6.2需求规格说明的特点仅仅写好每条需求声明是不够的。需求规格说明中所包含的整体需求集还必须具备下列特性。完整性不能遗漏任何需求或必要的信息。第 7 章中会推荐几种寻找被遗漏需求的方法。一致性需求的一致性是指需求不会与同一类型的其它需求或更高层次的业务、系统或用户需求发生冲突。 必须在开发前解决需求不一致的问题。只有经过调查才能知道需求正确与否。可修改性必须 能够对 SRS作必要的修订， 并可以为每项需求维护修改的历史记录。这要求对每项需求进行惟一标识，与其它需求分开表述，从而能够明确地提及它。每项需求只能在SRS中出现一次。

32、如果有重复的需求，很容易因为只修改其中一项而产生不一致。可以将相关需求合并到原声明中来避免对需求的重复声明。使用目录和索引可以使SRS更易于修改。需求信息，是软件工程管理信息的基础，也是主线。研究如何管理好需求信息，也许是克服软件工程许多问题的一个途径科研课题，论文？可跟踪性需求如果是可跟踪的，就能找到它的来源、它对应的设计单元、实现它的源代码以及用于验证其是否被正确实现的测试用例。可跟踪的需求都有一个固定的标识符对其惟一标识。记录这类需求应采用结构化、精细准确的方式。注 第 10 章讨论如何编写高质量的功能需求，第20 章介绍了如何跟踪需求。没有人能写出每项需求都具备上述所有理想特性的SRS 。但是，只要在编写和审阅需求时始终记住这些特点，就能写出更好的需求文档，开发出更好的产品。精选学习资料 - - - - - - - - - 名师归纳总结 - - - - - - -第 13 页，共 13 页