第3章需求工程.pptx

《第3章需求工程.pptx》由会员分享，可在线阅读，更多相关《第3章需求工程.pptx（104页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、2023/4/51第3章 需求工程 内容提要内容提要n3.1 软件需求n3.2 需求工程过程n3.3 需求的获取n3.4 需求分析n3.5 需求定义n3.6 需求验证n3.7 需求管理n3.8 案例:小型教学管理系统n3.9 小结2023/4/52引言n软件需求是决定软件开发是否成功的一个关键因素n整个软件工程活动中，只有需求阶段可以称为需求工程。这体现了需求在整个软件工程过程中非同一般的重要性。n需求工程的所有过程包括:n需求获取需求获取n需求分析需求分析n需求定义需求定义n需求验证需求验证n需求管理需求管理2023/4/533.1 软件需求n关于软件需求定义：在IEEE软件工程标准词汇表（

2、1997年）中给出如下描述：（1）用户解决问题或达到目标所需的条件或能力。（2）系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力。（3）一种反映上面（1）或（2）所描述的条件或能力的文档说明。2023/4/543.1 软件需求n 从这个标准定义中可以看出需求的概念涵盖了两个方面:n用户角度（系统的外部行为）n开发人员角度（系统的内部特性）n通常，软件需求可以分为不同的层次：n业务需求n用户需求n功能需求n非功能需求2023/4/553.1 软件需求图图3.1 3.1 不同层次的软件需求及其关系不同层次的软件需求及其关系2023/4/563.1 软件需求n 业务需求反映

3、了组织机构或客户对系统和产品高层次的目标要求，它们在项目视图与范围文档中予以说明。n用户需求描述了用户使用产品必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。n功能需求和非功能需求定义了开发人员必须实现的软件功能，这些需求则体现在需求文档中。2023/4/573.1.1 业务需求 n业务需求说明了提供给客户和产品开发商的新系统的最初利益,它们在项目视图与范围文档中予以说明。n 项目视图和范围文档应该包括高层的产品业务目标，所有的使用实例和功能需求都必须能达到业务需求的需要。项目视图说明使所有项目参与者对项目的目标能达成共识。而范围则是作为评估需求或潜在特性的参考。2023/4/58

4、3.1.2 用户需求 n用户需求是从用户角度描述的系统功能需求和非功能需求，通常只涉及系统的外部行为，而不涉及系统的内部特性。用户需求文档描述了用户使用软件产品要完成的任务，用户需求描述的原则是：应该易于用户的理解，一般不采用技术性很强的语言，而是采用自然语言和直观图形相结合的方式进行描述。2023/4/593.1.3 功能需求 n功能需求描述系统所预期提供的功能或服务。即定义系统应该做什么，系统要求输入什么信息，输出什么信息，以及如何将输入变换为输出。它由开发的软件类型、软件未来的用户以及开发的系统类型决定。2023/4/5103.1.4 非功能需求 n 除了关心软件的功能和行为外，用户会将

5、更多注意力集中于诸如产品的易用性、运行速度、可靠性、如何进行异常处理等特性。因此，一个好的软件还必须满足一系列非功能需求。非功能需求是指那些不直接与系统具体工作相关的一类需求。主要涉及系统的总体特性，如可靠性、反映时间和储存空间等。2023/4/5113.1.4 非功能需求n 非功能需求涉及的面非常广，包括系统的性能，目标系统所受的限制条件和开发和维护软件的限制，还包括如安全规章、隐私权保护的立法等外部因素。n具体内容可由三个方面构成n产品需求n机构需求n外部需求2023/4/5123.1.4 非功能需求性能需求隐私需求安全需求道德需求立法需求互操作需求交付需求实现需求标准需求非 功 能 需

6、求机 构 需 求外 部 需 求产 品 需 求可用性需求可靠性需求效率需求移植性需求空间需求2023/4/5133.1.4 非功能需求n对于非功能需求的表述要求尽可能的量化且可验证。表3.1给出了一些可能用来指定非功能性系统特性的度量，据此可以检验系统是否满足了相应的需求。2023/4/5143.1.4 非功能需求特特 性性 度度 量量 指指 标标速 度每秒处理的事务 用户/事件响应时间 屏幕刷新时间规 模K字节 RAM芯片数易用性培训时间 帮助画面数可靠性失败平均时间 无效的概率 失败发生率有效性鲁棒性失败之后的重启次数 事件引起失败的百分比失败中数据崩溃的可能性可移植性依赖于目标的语句百分比

7、 目标系统数2023/4/5153.2 需求工程过程n软件需求工程是一门应用有效的技术和方法、合适的工具和符号，来确定、管理和描述目标系统及其外部行为特征的学科。n需求工程过程中，开发人员需要：n收集和分析各方面的需求n编写规格说明文档n并采用评审和商议等有效手段对其进行验证，最终形成一个需求基线n由于软件开发过程中经常发生需求变更的情况，因此必须有效地管理和控制这些变更。2023/4/5163.2 需求工程过程 n需求工程过程包括：1.需求获取 确定和收集与待开发的软件系统相关的用户需求信息。2.需求分析 对获得的用户需求信息进行分析和综合，找出错误和冲突及遗漏的地方，获得用户的准确需求，进

8、而建立软件系统的逻辑模型或需求模型。2023/4/5173.2 需求工程过程3.需求定义利用描述语言、标准格式书写软件系统的需求规格说明。4.需求验证审查和验证软件系统需求规格说明，进而确定需求规格说明是否正确描述了用户对软件系统的需求。5.需求管理需求管理的任务是：管理软件系统的需求规格说明，评估需求变更带来的影响及成本费用，跟踪软件需求的状态，管理需求规格说明的版本等。下面分别叙述需求工程的每一部分。2023/4/5183.3 需求的获取 n 需求获取是在问题及其最终解决方案之间架设桥梁的第一步。需求获取的关键在于通过与用户的沟通和交流，收集和理解用户的各项要求。2023/4/5193.3

9、.1 需求获取的过程n 需求获取的主要任务是与客户或用户沟通，了解系统或产品的目标是什么，客户或用户想要实现什么？n对于不同规模及不同类型的项目，需求获取的过程不会完全一样。下面给出需求获取过程的参考步骤。2023/4/5203.3.1 需求获取的过程1.开发高层的业务模型 所谓应用领域，即目标系统的应用环境，如银行、电信公司等。如果系统分析员对该领域有了充分了解，就可以建立一个业务模型，描述用户的业务过程，确定用户的初始需求。然后通过迭代，更深入地了解应用领域，之后再对业务模型进行改进。2.定义项目范围和高层需求在项目开始之前，应当在所有利益相关方中建立一个共同的愿景，即定义项目范围和高层需

10、求。项目范围描述系统的边界以及与外部事物（包括组织、人、硬件设备、其他软件等）的关系。高层需求不涉及过多的细节，主要表示系统需求的概貌。2023/4/5213.3.1 需求获取的过程 3.识别用户类和用户代表 需求获取的主要目标是理解用户需求，因而客户的参与是生产出优质软件的关键因素。因此，首先确定目标系统的不同用户类型；然后挑选出每一类用户和其他利益相关方的代表，并与他们一起工作；最后确定谁是项目需求的决策者。用户类可以是人，也可以是与系统打交道的其他应用程序或硬件部件。如果是其他应用程序或硬件部件，则需要以熟悉这些系统或硬件的人员作为用户代表。4.获取具体的需求 确定了项目范围和高层需求，

11、并确定了用户类及用户代表后，就需要获取更具体、完整和详细的需求。具体需求的获取方法下节详细介绍。2023/4/5223.3.1 需求获取的过程5.确定目标系统的业务工作流 具体到当前待开发的应用系统，确定系统的业务工作流和主要的业务规则，采取需求调研的方法获取所需的信息。例如，针对信息系统的需求调研方法如下：(1)调研用户的组织结构、岗位设置、职责定义，从功能上区分有多少个子系统，划分系统的大致范围，明确系统的目标。2023/4/5233.3.1 需求获取的过程 (2)调研每个子系统的工作流程、功能与处理规则，收集原始信息资料，用数据流来表示物流、资金流、信息流三者的关系。(3)对调研内容事先

12、准备，针对不同管理层次的用户询问不同的问题，列出问题清单。将操作层、管理层、决策层的需求既联系又区分开来，形成一个需求的层次。2023/4/5243.3.1 需求获取的过程 6.需求整理与总结 必须对上面步骤取得的需求资料进行整理和总结，确定对软件系统的综合要求，即软件的需求。并提出这些需求实现条件，以及需求应达到的标准。这些需求包括功能需求、性能需求、环境需求、可靠性需求、安全保密要求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求等。2023/4/5253.3.2 需求获取的常用方法需求获取的常用方法：1.用户面谈它是一种理解商业功能和商业规则的最有效方法。面谈过程需要认真的计划和

13、准备，其基本要点：（1）面谈之前：确立面谈目的；确定要包括的相关用户；确定参加会议的项目小组成员；建立要讨论的问题和要点列表；复查有关文档和资料；确立时间和地点；通知所有参加者有关会议的目的、时间和地点。2023/4/526（2）进行面谈时：衣着得体；准时到达、寻找异常和错误情况；深入调查细节；详细记录；指出和记录下未回答条目和未解决问题。（3）面谈之后：复查笔记的准确性、完整性和可理解性；把所收集的信息转化为适当的模型和文档；确定需要进一步澄清的问题域；适当的时候向参加会议的每一个人发一封感谢信。3.3.2 需求获取的常用方法2023/4/5273.3.2 需求获取的常用方法2.需求专题讨论

14、会需求专题讨论会也许是需求获取的一种最有力的技术。项目主要风险承担人在短暂而紧凑的时间段内集中在一起，一般为1 至2 天，与会者可以在应用需求上达成共识、对操作过程尽快取得统一意见。参加会议人员包括：主持人、用户、技术人员、项目组人员。2023/4/5283.3.2 需求获取的常用方法专题讨论会具有以下优点：（1）协助建立一支高效的团队，围绕项目成功的目标；（2）所有的风险承担人都畅所欲言；（3）促进风险承担人和开发团队之间达成共识；（4）揭露和解决那些妨碍项目成功的行政问题；(5)能够很快地产生初步的系统定义。2023/4/5293.3.2 需求获取的常用方法3.问卷调查可用于确认假设和收集

15、统计倾向数据，问卷需要快速回答，允许匿名方式。存在问题的是：相关的问题不能事先决定；问题背后的假设对答案造成偏颇，如这符合你的期望吗；难以探索一些新领域；难以继续用户的模糊响应。在完成最初的面谈和分析后，问卷调查可作为一项协作技术可以收到良好的效果。2023/4/5303.3.2 需求获取的常用方法4.现场观察掌握用户如何实际使用一个系统以及到底用户需要哪些信息，最好的办法是亲自观察用户是如何完成实际工作的。一般方法是：(1)对办公室进行快速浏览，了解布局、设备要求和使用、工作流总体情况；(2)安排几个小时观察用户是如何实际完成他们的工作，理解用户实际使用计算机系统和处理事务的细节；(3)像用

16、户一样接受训练和做实际工作，发现关键问题和瓶颈。2023/4/5313.3.2 需求获取的常用方法5.原型化方法n一个软件原型是所提出的新产品的部分实现n 建立原型可以解决在产品开发的早期阶段需求不确定的问题。如建立基于WEB 的应用系统原型，使用HTML 进行界面设计。2023/4/5323.3.2 需求获取的常用方法6.基于用例的方法n随着面向对象技术的发展，基于用例的方法在需求获取和建模方面应用越来越普遍。n用例建模是以任务和用户为中心的，开发和描述用户需要系统做什么。n用例有助于开发人员理解用户的业务和应用领域，并可以运用面向对象分析和设计方法将用例转化为对象模型。2023/4/533

17、3.3.2 需求获取的常用方法 用例建模的基本步骤：用例建模的基本步骤：（1 1）确确定定系系统统的的参参与与者者：参参与与者者是是与与系系统统交交互互的的外外部部实实体体，它它既既可可以以是是人人员员也也可可以以是是外部系统或硬件设备。外部系统或硬件设备。（2 2）确确定定场场景景：场场景景是是对对人人们们利利用用计计算算机机系系统统过过程程做做了了什什么么和和体体验验了了什什么么的的叙叙述述性性描描述述。它它从从单单个个参参与与者者的的角角度度观观察察系系统统特特性性的的具体化和非正式的描述。具体化和非正式的描述。（3 3）确确定定系系统统用用例例：用用例例描描述述了了一一个个完完整整的的

18、系系统统事事件件流流程程，其其重重点点在在于于参参与与者者与与系系统统之之间间的的交交互互而而不不是是内内在在的的系系统统活活动动，并并对对参参与者产生有价值的可观测结果。与者产生有价值的可观测结果。2023/4/5343.3.2 需求获取的常用方法（4）确定用例之间的关系：在确定出每一个参与者的用例之后，需要将参与者和特定的用例联系起来，最终绘制出系统的用例图。（5）编写用例描述文档：单纯使用用例图并不能提供用例所具有的全部信息，因此需要使用文字描述那些不能反映在图形上的信息。用例描述是关于角色与系统如何交互的规格说明，要求清晰明确，没有二义性。在描述用例时，应该只注重外部能力，不涉及内部细

19、节。2023/4/5353.4 需求分析 需求分析是指开发人员要准确理解用户的要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转换到相应的形式功能规约(需求规格说明)的过程。2023/4/5363.4.1 需求分析的特点需求分析的难点体现在：(1)问题的复杂性。这是由用户需求所涉及的因素繁多引起的，如运行环境和系统功能等。(2)交流障碍。需求分析涉及人员较多，如软件系统用户、问题领域专家、需求工程师和项目管理员等，这些人具备不同的背景知识，处于不同的角度，扮演不同角色，造成了相互之间交流的困难。2023/4/537 3.4.1 需求分析的特点 (3)不完备性和

20、不一致性：由于各种原因，用户对问题的陈述往往是不完备的，其各方面的需求还可能存在着矛盾，需求分析要消除其矛盾，形成完备及一致的定义。(4)需求易变性。用户需求的变动是一个极为普遍的问题，即使是部分变动，也往往会影响到需求分析的全部，导致不一致性和不完备性。为了克服上述困难，人们主要围绕着需求分析的方法及自动化工具(如CASE技术)等方面进行研究。2023/4/5383.4.2 需求分析的原则 目前存在着许多需求分析的方法，虽然各种方法都有其独特的描述方法，但不论采用何种方法，需求分析都必须遵循以下基本原则：2023/4/5393.4.2 需求分析的原则(1)能够表达和理解问题的数据域和功能域。

21、所有软件开发的最终目的都是为了解决数据处理的问题，数据处理的本质就是将一种形式的数据转换成另一种形式的数据，即通过进行一系列加工将输入的原始数据转换为所需的结果数据。需求分析阶段必须明确系统中应具备的每一个加工、加工的处理对象和由加工所引起的数据形式的变化。2023/4/5403.4.2 需求分析的原则（2)能够将复杂问题分解化简。为了便于问题的解决和实现，在需求分析过程中需要对于原本复杂的问题按照某种合适的方式进行分解(对功能域和数据域均可)。分解可以是同一层次上的横向分解，也可以是多层上的纵向分解。每一步分解都是在原有基础上对系统的细化，使系统的理解和实现变得较为容易。2023/4/541

22、3.4.2 需求分析的原则(3)能够给出系统的逻辑表示和物理表示。系统需求的逻辑表示用于指明系统所要达到的功能要求和需要处理的数据，不涉及实现的细节。系统需求的物理表示用于指明处理功能和数据结构的实际表现形式，通常由系统中的设备决定。如处理数据的来源，某些软件可能由终端输入，另一些软件可能由特定设备提供。给出系统的逻辑表示和物理表示对满足系统处理需求所提出的逻辑限制条件和系统中其他成分提出的物理限制是必不可少的。结构化分析方法和面向对象分析方法都遵循以上原则。2023/4/5423.4.3 需求分析的任务 n需求分析的基本任务是准确地回答“系统必须做什么?”这个问题。n需求分析的任务不是确定系

23、统怎样完成它的工作，而是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。需求分析阶段的具体任务：2023/4/5433.4.3 需求分析的任务1.确定对系统的综合需求有下述四个方面：（1）系统功能需求：应该划分出系统必须完成的所有功能。（2）系统性能需求：指待开发的软件的技术性能指标，如存储容量、运行时间等限制。（3）环境的需求。指软件运行时所需要的软、硬件(如机型、外设、操作系统和数据库管理系统等)的要求。2023/4/5443.4.3 需求分析的任务（4）将来可能提出的需求：应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。这样做

24、的目的是在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦需要时能比较容易地进行这种扩充和修改。2023/4/5453.4.3 需求分析的任务2.分析系统的数据要求n建立概念模型：分析系统的数据要求，通常采用建立概念模型的方法。n数据字典：复杂的数据由许多基本的数据元素组成，利用数据字典可以全面准确地定义数据。n有层次方框图和Warnier图：数据字典不够形象直观，为了提高可理解性，常常利用图形工具辅助描绘数据结构。常用的图形工具有层次方框图和Warnier图。2023/4/5463.4.3 需求分析的任务 3.导出系统的逻辑模型 综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常

25、用数据流图、数据字典和主要的处理算法描述这个逻辑模型。2023/4/5473.4.3 需求分析的任务4.编写文档编写文档的步骤如下：(1)编写“需求说明书”，把双方共同的理解与分析结果用规范的方式描述出来，作为今后各项工作的基础。(2)编写初步用户使用手册，着重反映被开发软件的用户功能界面和用户使用的具体要求，用户手册能强制分析人员从用户使用的观点考虑软件。(3)编写确认测试计划，作为今后确认和验收的依据。(4)修改完善项目开发计划。在需求分析阶段对开发的系统有了更进一步的了解，所以能更准确地估计开发成本、进度及资源要求，因此对原计划要进行适当修正。2023/4/5483.4.4 需求分析的方

26、法 需求分析方法有：n功能分解方法n结构化分析方法n信息建模方法n面向对象分析方法等。2023/4/5493.4.4 需求分析的方法1.1.功能分解方法功能分解方法n功能分解方法是：n 将一个系统看成是由若干功能构成的一个集合n 每个功能又可划分成若干个加工(即子功能)n 一个加工又进一步分解成若干加工步骤(即子加工)n功能分解方法有三个组成要素：n功能n子功能n功能接口2023/4/5503.4.4 需求分析的方法n功能分解方法优点：n用过程抽象的观点来看待系统需求，是符合传统程序设计人员的思维特征n分解的结果一般已经是系统程序结构的一个雏形，实际上它已经很难与软件设计明确分离。2023/4

27、/5513.4.4 需求分析的方法n功能分解方法缺点：n它需要人工来完成从问题空间到功能和子功能的映射，即没有显式地将问题空间表现出来，也无法对表现的准确程度进行验证n缺乏对客观世界中相对稳定的实体结构进行描述，而基点放在相对不稳定的实体行为上，因此，基点是不稳定的，难以适应需求的变化。2023/4/5523.4.4 需求分析的方法 2.2.结构化分析方法结构化分析方法n结构化分析方法是一种从问题空间到某种表示的映射方法n由数据流图表示软件的功能，是结构化方法中重要的、被普遍接受的表示系统n 它由数据流图和数据词典构成。这种方法简单实用，适于数据处理领域问题。2023/4/5533.4.4 需

28、求分析的方法n 结构化方法优点：对现实世界中的数据流进行分析，把数据流映射到分析结果中。n 结构化方法缺点：现实世界中的有些要求不是以数据流为主干的，就难于用此方法。n 结构化方法难点：该方法的一个难点是确定数据流之间的变换，而且数据词典的规模也是一个问题，它会引起所谓的“数据词典爆炸”，同时对数据结构的强调很少。2023/4/5543.4.4 需求分析的方法3.3.信息建模方法信息建模方法n信息建模方法是从数据的角度来对现实世界建立模型的，它对问题空间的认识是很有帮助的。n该方法的基本工具是ER图，其基本要素由实体、属性和联系构成。该方法的基本策略是从现实世界中找出实体，然后再用属性来描述这

29、些实体。2023/4/5553.4.4 需求分析的方法n信息建模方法的优点n 信息模型和语义数据模型是紧密相关的，有时被看作是数据库模型。n 在信息模型中，实体和关系形成一个网络，描述系统的信息状况，给出系统的信息模型。n信息建模方法的缺点n 信息建模和面向对象分析很接近，但仍有很大差距。在ER图中，数据不封闭，每个实体和它的属性的处理需求不是组合在同一实体中的n 没有继承性和消息传递机制来支持模型。但ER图是面向对象分析的基础。2023/4/5563.4.4 需求分析的方法4.4.面向对象方法面向对象方法n面向对象的分析是把ER图中的概念与面向对象程序设计语言中的主要概念结合在一起而形成的一

30、种分析方法。n在该方法中采用了实体、关系和属性等信息模型分析中的概念，同时采用了封闭、类结构和继承性等面向对象程序设计语言中的概念。2023/4/5573.4.5 需求分析过程n需求分析包括：提炼、分析和仔细审查已收集到的需求，以确 保所有的风险承担者都明白其含义并找出其中的错误、遗漏或其他不足的地方。需求分析的n目的在于：开发出高质量和具体的需求，这样就能做出实用的项目估算并可以进行设计、构造和测试。2023/4/5583.4.5 需求分析过程需求分析的主要过程包括：（1）定义系统的边界建立系统与其外部实体间的界限，明确接口处的信息流。（2）分析需求可行性分析每一个需求实现的可行性，确定与需

31、求实现相关的开发风险。2023/4/5593.4.5 需求分析过程（3）确定需求优先级由于软件项目受到时间和资源的限制，一般情况下无法实现软件功能的每一个细节，因此需求优先级有助于开发组织和版本规划，以确保在规定的时间和预算内达到最好的效果。（4）建立需求分析模型建立需求分析模型是需求分析的核心工作，它通过建立需求的多种视图，揭示出需求的不正确、不一致、遗漏和冗余等更深的问题。2023/4/5603.4.5 需求分析过程（5）创建数据字典数据字典定义了系统中使用的所有的数据项及其结构，以确保客户和开发人员使用一致的定义和术语。多年来，人们提出了许多分析建模的方法，其中占主导地位的是传统的结构化

32、方法和目前流行的面向对象分析方法，我们在后面的章节中分别介绍。2023/4/5613.5 需求定义n需求定义是将对系统分析的结果用标准化的文档，即软件需求规格说明书（SRS,Software Requirement Specification）的形式清晰地描述出来，以此作为审查需求分析阶段工作完成情况的依据和设计阶段开展工作的基础。n需求规格说明书是系统所有相关人员，包括用户和开发人员对软件系统共同理解和认识的表达形式，是需求阶段最重要的技术文档。2023/4/5623.5 需求定义 n需求规格说明书中应包括如下主要内容：需求规格说明书中应包括如下主要内容：(1)(1)引言：用于说明项目的开发

33、背景、应用范引言：用于说明项目的开发背景、应用范围，定义所用到的术语和缩略语，以及列出文围，定义所用到的术语和缩略语，以及列出文档中所引用的参考资料等。档中所引用的参考资料等。(2)(2)项目概述：主要包括功能概述和约束条件。项目概述：主要包括功能概述和约束条件。功能概述用于简要叙述系统预计实现的主要功功能概述用于简要叙述系统预计实现的主要功能和各功能之间的相互关系；约束条件用于说能和各功能之间的相互关系；约束条件用于说明对系统设计产生影响的限制条件，如管理模明对系统设计产生影响的限制条件，如管理模式、用户特点、硬件限制及技术或工具的制约式、用户特点、硬件限制及技术或工具的制约因素等。因素等。

34、2023/4/5633.5 需求定义n(3)具体需求：主要包括功能需求、接口定义、性能需求、软件属性及其他需求等。功能需求用于说明系统中每个功能的输入、处理、输出等信息，主要借助于数据流图和数据字典等工具进行表达；接口定义用于说明系统软/硬件接口、通信接口和用户接口的需求；性能需求用于说明系统对包括精度、响应时间、灵活性等方面的性能要求；软件属性用于说明软件对可使用性、安全性、可维护性及可移植性等方面的需求；其他需求主要指系统对数据库、操作及故障处理等方面的需求。2023/4/5643.5 需求定义编写需求规格说明的原则是：（1）只描述“做什么”而无须描述“怎么做”。（2）必须说明运行环境。（

35、3）考虑用户、分析员和实现者的交流：对形式化和自然语言之间作出恰当的选择；明确的理解最重要，不存在十全十美的软件规格说明书。（4）力求寻找到恰如其分的需求详细程度：一个有益的原则就是编写单个的可测试需求文档。建议将可测试的需求作为衡量软件产品规模大小的尺度。2023/4/5653.5 需求定义（5 5）文档段落不宜太长：记住：不要在需）文档段落不宜太长：记住：不要在需求说明中使用求说明中使用“和和/或或”、“等等等等”之类的之类的词。词。（6 6）避免使用模糊的、主观的术语：如用）避免使用模糊的、主观的术语：如用户友好、容易、简单、迅速、有效、许多、户友好、容易、简单、迅速、有效、许多、最新技

36、术、优越的、可接受的、最大化、最新技术、优越的、可接受的、最大化、最小化、提高等。最小化、提高等。在软件项目开发中，开发组织应该采用一在软件项目开发中，开发组织应该采用一种标准的软件需求规格说明的模板，教材种标准的软件需求规格说明的模板，教材给出一个标准的模版。给出一个标准的模版。2023/4/5663.6 需求验证 由于需求分析阶段取得的成果是软件设计和软件实现的重要基础，一旦前期的需求分析中出现了错误或遗漏，就会导致后期的开发工作停滞不前或人力、物力的巨大浪费，甚至造成软件开发工作失败的严重后果。为了提高软件质量，降低软件开发成本，确保软件开发的顺利进行，对获取的系统需求必须严格地进行验证

37、，以保证这些需求的正确性。需求验证一般应从下述几个方面进行。2023/4/5673.6 需求验证1.1.验证需求的一致性验证需求的一致性所谓一致性，是指目标系统中的所有需求所谓一致性，是指目标系统中的所有需求应该是和谐统一的，任何一条需求不能和应该是和谐统一的，任何一条需求不能和其他需求互相矛盾。其他需求互相矛盾。审查需求的一致性应该考虑以下几个的问审查需求的一致性应该考虑以下几个的问题：题：（1 1）文档的组织形式是否易于一致？）文档的组织形式是否易于一致？（2 2）不同功能的描述之间是否存在矛盾？）不同功能的描述之间是否存在矛盾？（3 3）是否存在有矛盾的需求描述或术语？）是否存在有矛盾的

38、需求描述或术语？（4 4）文档中是否存在时序上的不一致？）文档中是否存在时序上的不一致？2023/4/5683.6 需求验证2.验证需求的完整性 所谓完整性，是指目标系统的需求必须是全面的，需求规格说明书中应包括用户需求的每一个功能或性能。由于软件开发人员获得的需求信息主要来源于用户，而许多时候用户并不能清楚地认识到他们的需求，或不能有效地表达他们的需求，大多数用户只有在面对目标软件系统时，才能完整、确切地表述他们的需求，因此需求的完整性常常难以保证。2023/4/5693.6 需求验证审查需求的完整性应该考虑以下的问题：审查需求的完整性应该考虑以下的问题：（1 1）是否存在遗漏的功能或业务过

39、程？）是否存在遗漏的功能或业务过程？（2 2）在每个定义的功能之间是否有接口？）在每个定义的功能之间是否有接口？（3 3）是否有信息或消息在所定义的功能之）是否有信息或消息在所定义的功能之间传递？间传递？（4 4）是否定义了功能的使用者？）是否定义了功能的使用者？（5 5）是否已经清楚地定义了用户与功能之）是否已经清楚地定义了用户与功能之间的交互？间的交互？2023/4/5703.6 需求验证（6 6）是否定义了与外部过程和系统之间的）是否定义了与外部过程和系统之间的接口？接口？（7 7）所描述的功能是否可以映射到业务过）所描述的功能是否可以映射到业务过程中？程中？（8 8）文档中是否存在待确

40、定的需求引用？）文档中是否存在待确定的需求引用？（9 9）文档中是否存在未定义的术语和引用）文档中是否存在未定义的术语和引用？（1010）文档的各个部分都完整吗？）文档的各个部分都完整吗？（1111）需求包括非功能属性的说明吗？）需求包括非功能属性的说明吗？2023/4/5713.6 需求验证n 3.验证需求的正确性 所谓的正确性是指需求规格说明对系统功能、行为、性能等的描述必须与用户的期望相吻合，代表了用户的真正需求。审查需求的正确性应该考虑以下的问题：（1）用户参与需求过程的程度如何？（2）每一个需求描述是否准确地反映了用户的需要？（3）系统用户是否已经认真考虑了每一项描述？（4）需求可以

41、追溯到来源吗？2023/4/5723.6 需求验证n4.验证需求的无二义性 无二义性是指需求规格说明中的描述对于所有人都只能有一种明确统一的解释。审查需求的无二义性应该考虑的问题：（1）需求规格说明是否有术语词汇表？（2）具有多重含义或未知含义的术语是否已经定义？（3）需求描述是否可量化和可验证？（4）每一项需求都有测试准则吗？2023/4/5733.6 需求验证n 5.验证需求的可验证性可验证性是指需求规格说明中描述的需求都可以运用一些可行的手段对其进行验证和确认。审查需求的可验证性应该考虑的问题：（1）在需求文档中是否存在不可验证的陈述，诸如“用户界面友好”、“容易”、“简单”、“快速”、

42、“健壮”、“最新技术”等？（2）所有描述都是具体的和可测量的吗？2023/4/5743.6 需求验证n 6.验证需求的可修改性 可修改性是指需求规格说明的格式和组织方式应保证后续的修改能够比较容易和协调一致。审查需求的可修改性应该考虑的问题：（1）是否存在明显的需求交叉引用？（2）是否有内容列表和索引？（3）是否存在冗余的需求，即同一个需求的描述出现在文档的不同地方？如果存在，它们是交叉引用吗？2023/4/5753.6 需求验证 7.验证需求的可跟踪性可跟踪性是指每一项需求都能与其对应的来源、设计、源代码和测试用例联系起来。可跟踪性的两种形式：（1）每一项需求都可以在早期的文档中追溯到其来源

43、，例如备忘录、法规、会议记录等。（2）每一项需求都有唯一的名称或索引号，与后期实现对应。2023/4/5763.7 需求管理n需求工程分为n 需求获取n 需求分析 需求开发阶段n 需求定义n 需求验证n 需求管理：定义为：一个为系统的需求进行启发、组织、建档的系统方法，一个建立和维护客户和项目团队之间关于变更系统需求所达成的一致性的过程。2023/4/5773.7需求管理 需求管理包含5个特定实践，如图3.3所示。现简介如下。2023/4/5783.7需求管理 获得对需求的理解。在初步整理需求的基础上，项目小组和用户代表通过初步的分析讨论，对当前项目的需求达成共识，并在需求列表中作相应记录。获

44、取需求承诺。通过项目参与者的书面承诺，建立各方或各项工作的基准。管理需求变更。维护变更历史，为调整与控制提供数据。在需求变更后维护对需求的双向可追溯性。从软件可维护性的角度提出管理要求。标识项目工作（包括计划和产品）与需求的不一致性。若发现不一致性，即启动纠正措施。2023/4/5793.7需求管理 上述5个特定实践，可归结为以下3项活动，即需求确认、需求跟踪和需求变更。1.需求确认 包括图3.3中第1、2两个特定实践。需求确认实际上包含了两个重要工作：需求评审和需求承诺。由开发方和客户共同对主要需求文档“软件需求规格说明书”进行评审，双方达成共识后作出书面承诺，使需求文档具有商业合同效力。2

45、023/4/5803.7需求管理2.需求跟踪 包括图3.3的第4、5两个特定实践，即维护对需求的双向可追溯性和标识项目工作与需求的不一致性。为了有效地检验最终软件产品能否满足所有需求，对项目的需求要进行跟踪管理。跟踪的目的，是建立与维护“需求一设计一编程一测试”之间的一致性，确保所有工作成果都符合用户需求。为此可采用需求大纲中的需求跟踪矩阵，对每个需求追踪到实现该需求的设计、编码以及测试案例，从而验证该软件产品是否实现了所有需求，是否对所有需求进行过测试。2023/4/5813.7需求管理 3.需求变更 对许多项目来讲，需求的变更是合理的且不可避免的。但是如果不能控制这种变更将会导致项目陷入混

46、乱、不能按进度执行或软件质量低劣等问题。通过变更控制来管理需求文档，并提供支配下的规范的方式来统一需求变更，这样当需求因业务和技术的因素发生变化时，可以随时更新以与新的需求保持一致。2023/4/5823.7需求管理需求变更通常按变更申请-审批-更改-重新确认的流程进行。(l)变更申请 此时的状态为“请求变更”。首先由申请人提交需求变更申请书，其内容应该包括：变更源类型。指引起变更的原因类型，可分为需求变更、设计变更、代码优化、用户文档优化和计划变更等。变更优先级。依据变更的重要性、紧迫性和对关键业务的影响程度，以及对系统安全性和稳定性的影响程度，可分为critical、high、middle

47、和Low等4级。2023/4/5833.7需求管理 变更标志。分为新增、修改和删除。变更影响分析。包括变更影响的工作产品和负责人，对工作量和进度的影响，发生风险的可能性与影响程度，以及需要回测的范围。可能影响的工作产品。包括项目计划、需求文档、概要设计文档、详细设计文档、源代码和程序、测试计划和测试案例以及用户文档。2023/4/5843.7需求管理 上述申请书应由项目经理进行评估，其内容包括：该需求变更在技术上是否可行。对工期、成本、质量的影响。首先评估单个模块工期的影响，即实现该需求变更需要的成本和工作量：然后评估实现该需求变更对整体工期工作量和成本的影响。2023/4/5853.7需求管

48、理(2)变更审批 按照影响的大小由不同的负责人审批。对影响小的变更，由项目经理直接审批。对影响大的变更，提交软件变更控制委员会（Sofiware Change Control Board，SCCB）审批。项目SCCB仍无法决定的变更，再提交高层SCCB决定。2023/4/5863.7需求管理 所谓影响大的变更一般包括下列情况：变更影响的模块数超过10个或超过50%，或者可能影响软件系统的框架。变更会影响对客户的承诺。变更会带来“高”或者“高中”程度的风险。如果审批请求未通过，则该变更请求结束。2023/4/5873.7需求管理n(3)变更修改 如果需求变更已审批通过，应指定相关的责任人对产品进

49、行修改，并指定人员对更改后的产品进行审核。还应在产品列表中记录具体修改的产品名称、修改描述和是否完成修改的状态。包括：应及时更新相应的需求大纲和需求分析说明。如果影响项目计划的内容，修改项目计划，以反映需求的变更。如果影响到概要设计文档、详细设计文档、源代码和程序、测试计划和测试案例或者用户文档，它们也需要被及时更新。2023/4/5883.7需求管理 如果影响到测试，还需要进行回归测试。如果对文档进行修改，需在修改历史表格中注明修改人、修改时问以及修改原因。如果对原文件修改过大，必要时项目经理可以重新组织工作产品的评审。如果对代码进行修改，需要导出编译申请表，通知编译和测试。2023/4/5

50、893.7需求管理(4)变更关闭 如果修改后不需要进行测试，则当所有产品全部修改完成时，由最后完成修改的人关闭该变更。如果变更修改后提交测试，则由测试人员负责该变更是否最后关闭：如果测试未通过，则返回修改者继续修改。如果所有工作产品全部修改完成，并且测试通过，关闭该变更。2023/4/5903.7需求管理n在软件规模很小的时候，人们采用文档文件的方式来存储软件需求规格说明书和其他文档。但是，随着软件工程技术的发展，需求管理的任务越来越繁重，迫切需要研制需求管理工具来自动化地管理需求，提高工作效率。IBM Rational RequisitePro、Telelogic DOORSreg和Borl