软件需求基础知识教案

1、文档编码 : CY8A3C7Y9C1 HN8E5X1C9C8 ZH6J2V5X4F1软件需求（第 2 版）教案 陶铮 2022 年 3 月 目录 1 软件需求基础学问 . 2软件需求的定义 . 2对需求的不同说明 . 3需求的层次 . 3不属于需求的内容 . 6需求的开发与治理 . 6需求开发 . 6需求治理 . 7全部项目都有需求 . 8优秀的团队遇到糟糕的需求 . 8用户参加不足 . 9用户需求扩展 . 9有歧义的需求 . 10 镀金问题 . 10 过于抽象的需求 . 10 忽视了某类用户 . 10 不精确的方案 . 10 优质需求过程的好处 . 11 优秀需求的特点 . 11 需求陈述的

2、特点 . 11 需求规格说明的特点 . 13 第 1 页,共 13 页1 软件需求基础学问 章首案例的概括总结见课件； 本章要点： （1）需求的重要性 软件问题主要在于需求： 很多软件问题都源于收集, 记录, 协商和修改产品需求过 程中的方式不当； 包括信息收集方式不正规, 没有明确提出想要的功能, 连假设也 是未经沟通的错误假设, 需求的定义不够充分, 以及未经认真考虑进行需求变更等 ； 需求问题造成很大的麻烦： 失所致； 软件项目中 40% 60% 的缺陷都是由需求分析阶段的过 需求问题, 一是轻视, 而是不得方法： 很多组织仍旧没有实行有效手段来实施这两 个必要的项目活动；由此导致的结果

3、是用户和开发者之间产生需求的鸿沟； （2）软件项目学问项目涉众 客户：为达到其公司的业务目标而投资项目或购买产品； 用户：直接或间接与产品打交道,是客户的一部分； 需求 分析员：负责编写需求并传达给开发团队； 开发人员：设 计,实现和爱惜产品； 测试人员：确定产品的行为是否与 估量的相一样； 文档编制人员：负责编写用户手册,培训 资料和系统帮忙； 项目经理：制定项目方案并带领开发人 员获得胜利； 法律人员：确保产品符合全部相关法规； 生 产人员：制造包含该软件的产品； 市场营销,技术支持及其它与产品和客户打交道的人员； 懂得涉众,关键在于“只有涉众承诺遵循有效的需求过程,才能为软件开发和项目治

4、理 活动奠定基础； 本章讲授内容： 软件需求工程的一些重要术语； 需求开发与需求治理； 留意潜 在的与需求相关的问题； 完善的需求应当具备哪些特点； 软件需求的定义 术语纷乱： 用户需求,软件需求,功能需求,系统需求,技术需求,业务需求或产品需求； 第 2 页,共 13 页一般的误会 : 开发人员看到客户对需求说法,认为只是高级别的产品概念； 用户看到的开发人员的需求描述,认为是用户界面设计； 需求定义,即用文字进行规范地,正确地,完整地描述； 对需求的不同说明 需求的几种定义,都很有参考价值； 需求必需被记录成文档； 1. 询问专家 Brian Lawrcnce 提出, 需求是 “任何促成设

5、计决策的因素 ”；很多信息都 属于这一范畴； 2. IEEE 的软件工程标准术语表（ 199就将需求定义为： 用户为解决某个问题或达到某个目标而需具备的条件或才能； 系统或系统组件为符合合同, 件或必需具备的才能； 标准, 规范或其它正式文档而必需中意的条 上述第一项或其次项中定义的条件和才能的文档表达； 3. 作者对需求的懂得： 需求是产品为向涉众供应价值而必需具备的特性； 4. 需求类型的多样性（ Sommerville 和 Sawyer 1997 ）： 需求是 对应当实现什么 功能的说明 可以是对系统运行方式或系统特点与属性的描述； 仍可能是对系统 开发过程的约束； 需求的层次 本节的内

6、容特殊重要；需求工程领域一些常用术语的定义； 软件需求包括 3 个不同的层次： 1. 业务需求 2. 用户需求 3. 功能需求 ；除此之外,每个系统仍有各种非功能需求； 重要： 图 1-1 中的模型给出了各种需求关系的示意图； 图中的椭圆代表各类需求信息, 矩形就是储备这些信息的载体 （文档, 图形或数据库） ； 第 3 页,共 13 页图 1-1 各种需求的关系图 注：第 7 章中介绍了各种需求的示例； 三大需求 1. 业务需求（ Business requirement ）表示组织或客户高层次的目标； 业务需求通常来自项目的 或产品策划部门； 投资人 ,购买产品的 客户 ,实际 用户的治理

7、者 ,市场营销部门 业务需求描述了 组织为什么要开发一个系统,即组织期望达到的目标 ； 本书规定 用前景和范畴（ vision and scope ）文档来记录业务需求 ；见 第 5 章的主题 （作 为试验 3 内容）； 任务是：定义项目范畴 （随后会发生如何把握范畴扩大的问题）； 2.用户需求（ user requirement 须能完成的任务； ）描述的是用户的目标,或用户要求系统必 用户需求描述的是软件使用者 （用户）使用系统能够完成什么业务任务或信息处理工作； 具体内容是 用例,场景描述和大事 -响应表等；见第 8 章（作为试验 4）； 3. 功能需求（ functional requ

8、irement ）规定开发人员必需在产品中实现 的软件功能,用户利用这些功能来完成那些中意业务需求的具体的任务； 功能需求有时也被称作行为需求（ behavioral requirement ）,描述的是软件的行为性活 动； 功能需求描述的是开发人员需要实现什么 ；第 10 章将举例说明这点； 如： “系统应当发送电子邮件来通知用户己接受其预定 ”； 第 4 页,共 13 页术语 系统需求（ system requirement ） 用于描述包含多个子系统的产品（即系统）的顶级需求；系统可以只包含软件子系统, 也可以既包含软件又包含硬件子系统； 由人来承担； 业务规章 人也可以是系统的一部分,

9、 因此某些系统功能可能要 包括企业方针, 政府条例,工业标准,会计准就和运算方法等；第 9 章中指出业务规章 本身并非软件需求, 由于它们不属于任何特定软件系统的范畴； 然而, 业务规章常常会限制 谁能够执行某些特定用例, 或者规定系统为符合相关规章必需实现某些特定功能； 有时, 功 能中特定的质量属性 （通过功能实现） 也源于业务规章； 所以, 对某些功能需求进行追溯时, 会发觉其来源正是一条特定的业务规章； 功能需求记录在软件需求规格说明 （ SRS）中；SRS 完整地描述了软件系统的预期特性； SRS 仍可以是包含需求信息的数据库或电子表格； 或者是储备在商业需求治理工具 中的信息 （参

10、见第 21 章）,甚至可能是一叠索引卡片； SRS 对于软件设计, 开发,测试,质量保证,项目治理和其它相关的项目功能都十分重要； SRS 中仍包含 非功能需求,包括性能指标和对质量属性的描述； 质量属性（ quality attribute ）对产品的功能描述作了补充,它从不同方面描述了产 品的各种特性；包括可用性,可移植性,完整性,效率和健壮性,仍包括系统外部界面,以 及对设计与实现的约束； 约束（ constraint ）限制了开发人员设计和构建系统时的挑选范畴； 字处理程序的例子； 业务需求： “产品答应用户轻松地更正文档中的拼写错误； 了拼写检查器这一功能特性； 用户需求 ：包括 “

11、找出拼写错误 ”和 “把单词添加到词典中 ”因此该产品的包装盒上列出 ”这样一些任务, 或者叫作用例； 功能需求： 如找到并突出显示拼错的单词, 用对话框显示修改建议, 用正确的单词替换 整篇文档中同一单词的全部拼写错误； 结合非功能需求,介绍： 可用性（ usability ）的质量属性,它规定了业务需求中 义； 增加的内容： （1） 可用性指标 （2） 网站质量评判要素 “有效 ”（ efficiently ）一词的含 下面的内容,分散到业务需求,用户需求,功能需求中赐予提示： 治理人员或市场营销人员负责定义软件的业务需求, 以提高公司的运营效率 （对信息系 统而言）或产品的市场竞争力（对

12、商业软件而言）；全部的用户需求都必需符合业务需求； 需求分析员从用户需求中推导出产品应具备哪些对用户有帮忙的功能； 开发人员就依据功能 第 5 页,共 13 页需求和非功能需求设计解决方案, 在约束条件的限制范畴内实现必需的功能, 并达到规定的 质量和性能指标； 图 1-1 中的模型,需要强调： （ 1） 是一个自顶向下的单向需求流,没能反映出业务需求,用户需求与功能需求 之间可能存在的循环和迭代关系； （ 2） 范畴问题：当一项新的特性,用例或功能需求被提出时,需求分析员必需思 考这样一个问题： “它在范畴内吗？ ”； （ 3） 不能确定的,必需由业务需求的负责人或投资治理人来预备：是否扩大

13、项目 范畴以容纳新的需求；这是一个可能影响项目进度和预算的商业决策； 不属于需求的内容 主要指明：需求分析内容不包含设计与实现技术的细节； 需求规格说明中不包括（除已知约束外的）设计和实现的细节,项目的方案信息 ,以及 测试信息 （ Lcffngwcll 和 Widrig 2022 ）； 把这些内容与需求分开,就可以把需求活动的注 意力集中到明白开发小组需要开发的产品特性上 ；项目中通常仍包括其它类型的需求, 如开 发环境需求, 进度或预算限制, 帮忙新用户跟上进度的培训需求, 或者发布产品使其转入支 持环境的需求；这些都属于项目需求而不是产品需求,因此不属于本书争论的范畴； 需求的开发与治理

14、 此部分内容属于软件工程分支领域,是今后的课题； 需求领域的术语问题如此突出, 甚至对这门学科的称呼都很纷乱； 有的作者称其为需求 工程（ SommCrville 和 Kotonya 1998 ）；也有人称之为需求治理 （ Leffngwell 和 Widrig2022）； 我找到一个好方法解决这个问题, 就是把软件需求工程划分为需求开发 （本书第部分争论 的内容）和需求治理（在第部分争论）,如图 1-2 所示； 图 1-2 软件需求工程的组成 需求开发 此处内容,作为本课程试验 3,4, 5 的过程要求 第 6 页,共 13 页要求在试验中体会下述活动： 1. 确定你将要面对的各类用户； （

15、非功 2. 明白用户的业务学问和用户的任务与目标； 3. 分析自己获得的信息, 把用户任务目标分解为用户需求与与功能需求 能需求）； 4. 分析有关的质量属性及其重要性； 5. 编写需求规格说明,协作模型的建立； 6. 批阅需求文档,以确保在熟识上与用户声明的需求相一样； 需求开发可进一步细分为猎取（ 和确认（ validation ）（ Abran Elicitation ）,分析（ analysis ）,规格说明（ specification ） 和 Moore 2022 ）；这些子学科涵盖了为软件和软件相关产品 收集,评估和记录需求相关的全部活动,包括： 确定产品将要面对的各类用户； 从

16、各类用户的代表处收集 需求； 明白用户的任务和目标,以及这些任务要实现的业 务目标； 分析从用户处得到的信息,将用户的任务目标与功能需求,非功能需求,业务规章,解 决方案建议及其它无关信息区分开来； 将顶层的需求支配到系统构架内定义好的软件组件中； 明白各质量属性的相对重要性； 协商需求的实现优先 级； 将收集的用户需求表述为书面的需求规格说明和 模型； 批阅需求文档, 以确保在熟识上与用户声明的需求相一样； 解决全部分岐； 强调： 迭代（ iteration ） 是需求开发胜利的关键； 需求治理 需求治理的任务是 “与客户就软件项目的需求达成并保持一样 应在开发小组接受需求之前 ”（ Pau

17、1k et a1 1995）；这 种一样应表达在书面的需求规格说明和模型中； 取得用户认可只中意了批准需求所需的一半 条件,仍必需让开发人员接受需求规格说明并同意在产品中加以实现； 需求治理包括以下活 动： 定义需求基线（某一时刻,对特定版本中己达成一样的需求内容的描述） 审查需求变更恳求,评估其可能产生的影响以预备是否批准 以可控的方式将准的需求变更融入项目中 保持项目方案与需求的同步 估量需求变更的影响,在此基础上协商新的需求商定 跟踪每项需求,找到与其对应的设计,源代码和测试用例（ test casc） 在项目开发过程中,始终跟踪需求的状态和变更 图 1-3 从另一个角度反映了需求开发与

18、需求治理间的区分；本书介绍了很多用于猎取需求, 第 7 页,共 13 页分析需求,说明截验证和治理需求的特殊技巧； 图！ 3 需求开发与需求治理的分界 全部项目都有需求 此处内容的本质是,需求的重要意义； 我们只要知道： 软件系统开发过程中最难的部分是什么？ 需求开发； 全部概念性工作中最难的是什么？ 建立具体的技术需求； 在无法确定全部的需求的情形下怎么办？ 接受迭代和增量方法, 每次实 现一部分需求,得到用户反馈后再进入下一循环； 没有理所当然的需求 优秀的团队遇到糟糕的需求 本节内容主要在于： 需求开发不是个别人的事情,是一个软件团队全体的任务； 需求问题导致返工,是很好的说明；图 1-

19、4； 作为将来的职业,需要知道这些学问,但本课不讲,自学； 需求问题导致的主要后果是返工 重复做您认为早已做好的事情； 返工的成本占了总 开发成本的 30% 50%（ Boehm 和 Papaccio 1988）,而对于返工的情形, 70% 80%是因 第 8 页,共 13 页需求错误引起的（ Leffngwel1 1997）；从图 1-4 可以看出,在项目末期才发觉缺陷,对其 进行改正的成本要比在缺陷刚产生不久时修改的成本高得多； 防止需求错误的发生并及早发 现它们, 对于削减返工功效特殊显着； 试想假如能把返工削减一半, 您的生活将会多么不同： 您可以更快地开发出产品, 即便不用通宵达旦地

20、工作, 您也能在同样的时间里开发出比原先 更多更好的产品； 需求实践中的种种不足会给项目的胜利带来很多风险； “胜利 ”是指以商定的成本和进度 交付中意用户对功能和质量的期望的产品；第 23 章中表达了如何把握这些风险使项目不致 因其而脱轨；以下几节将介绍一些最常见的与需求相关的风险； 图 1-4 不同阶段改正缺陷的开销比较 用户参加不足 开发人员往往往往不重视用户的参加, 缘由是他们认为与用户打交道不像写代码那么有 趣,或者自以为已经知道了用户想要什么 ； 有些时候, 与产品实际的使用者直接联系很困难, 而用户代理方又不能完全懂得用户的 真正需求； 用户参加不足将导致不能在项目早期准时发觉需

21、求中的缺陷, 从而延误项目的完 成；在整个项目开发过程中,开发团队必需始终与实际用户直接合作； 第 6 章说明白这种合作的不行替代性； 用户需求扩展 不依照对于需求的规模和复杂度的实际评估来制订方案, 而不断修改需求又使情形变得 更糟；缘由主要是需求的不断进展与增加,项目往往会落后于方案的进度并超出预算； 要把握项目范畴的转变,第一应明确项目的业务目标,全局规划,范畴,限制,胜利标 准以及产品的估量用途；然后参考这一框架对全部新特性和需求变更进行评估； 仍有软件开发中的质量问题： 随着变更在产品内部的扩散, 项目的原有结构可能逐步瓦 解；造成很多代码补丁,使得程序更难懂得和爱惜； 插入的代码可

22、能导致模块违反强内聚和弱耦合这一设计原就； 要削减需求变更对质量造成的影响, 处理变更时应当先对结构和设计进行适当的 修改,而不是直接修改代码； 第 9 页,共 13 页有歧义的需求 歧义,是需求规约的大忌 （LawrCncc 1995 ）； 歧义表现为同一读者可以对一项需求声 明作出多种说明,或者不同的读者对同一需求产生不同的懂得； 第 10 章列出了很多简洁产生歧义,给读者造成负担的词语；产生歧义的另一个缘由是 需求不精确和没有充分细化； 镀金问题 以为 “用户确定会宠爱的 ”,而实际上却是华而不实的需求就是所谓的 “镀金问题 （gold plating ） ”； 留意： 用户通常并不关怀

23、额外的功能； 应当把创意和备选方案提交给客户； 开发人员应 该力求简洁,而不是自作主见去超越客户的需求； 要防止镀金问题,就应当追溯每项功能的来源,弄清晰为什么添加该功能； 收集需求时,使用用例方法,有助于着重考虑可实现商业任务的功能需求； 过于抽象的需求 营销人员或经理常常宠爱只给出一个粗略的说明,期望开发人员在开发过程中充实它； 这种方式只适合于那些争论性项目或需求特殊灵敏的项目； 挫,让客户败兴； 忽视了某类用户 这里描述的是“用户与产品的关系”； 否就, 这种做法会使开发人员受 a 假如一开头没能找出产品的全部重要用户群,就会有某些用户需求得不到满 足； b 确定全部用户群后,仍要保证

24、获得各类用户的需求 用户所使用的产品特性,产品的使用频率以及用户自身的体会水平不尽相同； 对某一产品,确定存在下述情形： 用户群体 产品特性 产品的使用频率 对该产品使用的体会 A B C 不精确的方案 不能充分懂得需求,就会作出过于乐观的估量,最终不行防止地陷入超支的泥潭； 造成软件成本估算失败的最主要缘由包括频繁变更需求, 遗漏需求,未与用户充分沟通, 第 10 页,共 13 页需求的说明不精确,以及对需求的分析不透彻； 给出估算结果时,应当供应范畴（最好的情形,最可能和最糟的情形）或把握程度； 优质需求过程的好处 软件需求过程到底该是怎样的？我们将通过试验课程尝试建立； 但目前条件限制,

25、 我们 仍难以体会一下的好处： 削 减需求缺陷 削减开发过 程中的返工 削减不必要 的特性 降低改进成本 加 快开发进度 提高沟通效 率 把握需求范畴的转变 项目更有序 对系统测试 的评估更精确 提高客户和开发人员的中意度 优秀需求的特点 本节重要,但很多内容需要在实践中懂得； 如何才能将好的需求规格说明与那些有问题的区分开来？这一节第一对说明中的单条 需求（即需求声明）特点进行争论,然后将介绍 SRS 作为整体应具备的特点；假如想知道 您的需求是否具备这些特点, 最好的方法就是请几位项目相关人员认真批阅您的 SRS；不同 的人会发觉不同的问题； 例如, 分析员和开发人员无法精确判定完备性和正

26、确性, 而用户就 无法评判技术可行性； 需求陈述的特点 抱负情形下,每一项用户需求,业务需求和功能需求都应具备以下性质； 完整性 每一项需求都必需完整地描述即将交付使用的功能； 它必需包合开发人员设计和实现这 项功能需要的全部信息； 假如发觉缺少某项信息,应使用 TBD（ to be determined ,待定） 这一标准符号加以标明 ；在开发系统的任一部分之前都必需解决需求中全部的 TBD ； 正确性 每一项需求都必需精确地描述将要开发的功能； 第 11 页,共 13 页判定正确性的参考是需求的来源,照实际用户和高级的系统需求； 需求规约必需经过用户或用户信任的代理人的批阅； 可行性 需求

27、必需能够在系统及其运行环境的已知才能和约束条件内实现； 在需求的猎取阶段, 应支配一名开发人员始终和营销人员或需求分析员协同工作, 由开 发人员来进行可行性检查, 判定技术上能够实现哪些需求, 或者什么功能需要额外的成本才 能实现； 评估需求可行性的方法包括增量开发方法和 概念证明（ proof-of-concept ）原型； 概念证明（ proof-of-concept 必要性 ）,基于建模 -使用 -开发 -证明 -试验运行 -验证结果的工程方法； 每一项需求记录的功能都必需是用户的真正需要, 或者是为符合外部系统需求或某一标 准而必需具备的功能 ；每项需求都必需来源于有权定义需求的一方；

28、 对每项需求都必需追溯 至特定的客户需求的来源,譬如用例,业务规章或其它来源； 有优先次序 为每一项功能需求, 特性或用例指定一个实现优先级, 以说明它在产品的某一版本中的 重要程度； 假如全部需求都被视为同等重要, 项目经理就很难实行措施应对预算削减, 进度 拖后,人员流失或开发过程中需求增加等情形； 注 第 14 章将更具体地争论如何设置优先级； 补充学问：软件爱惜与软件产品版本升级； 软件爱惜与软件产品版本升级有确定关系：例如： 如小爱惜前的版本号为 ,就小爱惜后的版本号为 ； 如大爱惜前的版本号为 ,就大爱惜后的版本号为 ； 一般而言,版本号中小圆点的左一位,表示该软件产品的第几个版本；版本号中小圆点 的右一位,表示该版本的大修改次数；版本号中小圆点的右二位,表示该版本的小修改 次数；即一个版本的大修改最多是 9 次,小修改最多是 81 次； 只有当该软件产品的运行环境发生大转变时,或者该软件产品的功能变化超过 30%时, 其版本才能升级,此时,版本号中小圆点的左一位才能加 无歧义 1,由 V1.11 变为 ；