需求工程
第3章需求工程概论
➢ 以便开发人员在代码生成后能够通过测试结果向客户表 明软件系统已完整地实现了所有需求。
2024/6/7
24
小结
➢ 软件需求指，利益相关方对目标软件系统在功能、 性能、质量等方面的期望，以及对目标软件系统 在运行环境、资源消耗等方面的约束。
➢ 软件需求可划分为功能需求、质量需求和约束性 需求三种类型。
2024/6/7
23
需求工程过程
➢ 联合工作组被分成两个小组，分别处理用户配置和 传感器监测子系统。
➢ 分组的目的是对子问题的需求进行获取、分析、规范化 等项工作。
➢ 在各子系统的需求已基本明确并形成需求模型后，联合 工作组还应就子系统的整合及需求验证标准展开讨论。
➢ 子系统整合包括：子系统接口之间的一致性检查、子系 统合成后系统功能和行为的完整性检查。
2024/6/7
27
问题A 图书馆管理()
一个小型图书馆管理系统，需完成以下工作： (1)借书、还书； (2)图书馆中增加/删除一本书； (3)照作者名或专业领域检索一批书； (4)出被某位读者借出的一批书； (5)出最近借走某本图书的读者。 该系统有两类用户：图书管理员与普通读者。 功能(4)可供普通读者查找他们自己借出的书目。 功能(1)、(2)、(5)只供图书管理员使用。 该系统必须满足以下限制： (1)馆中所有未借出的书籍能够供读者随时借阅。 (2)在同一时刻，一本书不能既被借出，又可供借阅。 (3)一个读者一次借出的书籍数目不能超过预定值。
➢ 质量需求和约束性需求统称为非功能需求。
➢ 软件需求的质量要素包括正确性、完全性和可行 性。
➢ 为了获得高质量的需求模型，需求工程师必须掌 握与用户/客户交流的技巧。
需求工程
1a.客人已经预定 问题：客人标识不明确。
系统采用模糊匹配算法
需求开发-需求分析
需求分析是需求开发中的核心任务，是业务分析，选择一种业 务导向的线索将零散的需求串起来，形成一个体系完整、内容 清晰的框架，以指导后续的设计、开发工作。
需求开发-需求验证
• 需求验证是需求开发的最后一个环节，它是一个质量关。 其目标是发现尽可能多的错误，减少因为需求的错误而带 来的工作量浪费。最有效的工具即为评审（Review,复查）
子任务： 1.查找客房 问题：客人会要求相邻的客房 客人会商量价格 2.记录客人，标记房间为“已入住” 3.提供钥匙 问题：客人忘记归还钥匙 客人需要两套钥匙 任务变体： 方案示例： 系统在酒店图上显示空闲客房 系统显示折扣价格（依时间、天气等因素 而定） 标准的表单数据输入 系统打印电子钥匙 每位客人一套钥匙
需求捕获的常用方法
最重要的技巧：沟通
1主动性
2计划性 3科学性
需求捕获的记录工具
项目
任务 目的 触发 前提 频率
内容
对该业务活动进行命名
说明
一定要使用业务术语
以业务活动的工作意义进行概述 说明的是意图并非动作 进行该业务活动 触发本业务活动的时机、场景 任务发生的频率 系统实现时要判断的前置条件 说明了业务前提 这是一种非功能性需求 系统需要专门进行处理 相当于用例的基本事件流
需求工程概述
目录
Contents
培训目的
需求工程
常见问题
需求定义
需求捕获
需求验证
需求管理
1
2
3
4
5
6
7
培训目的
更新 观念 提高 重视程度
加强 执行力
需求工程的概念
需求工程的概念需求工程是一种软件工程领域的方法论，旨在确保软件开发过程中所产生的需求能够被准确地理解，并基于这些需求建立稳定、可靠、高效的软件系统。
需求工程的核心目标是满足用户需求，并且将其转化为明确的软件要求，使开发人员、测试人员和其他利益相关者能够基于这些要求开展有效的工作。
在软件开发中，需求工程是一项至关重要的工作，因为它直接关系到软件的质量和功能。
需求工程包括需求获取、需求分析、需求规格说明和需求验证四个核心环节。
需求获取是指收集和整理用户和利益相关者的需求，为软件开发过程建立基础。
它可以通过多种方式实现，比如面对面交流、访谈、问卷调查、文档分析等。
在需求获取中，关键是了解用户的目标、愿望、需求以及对软件的期望，以便后续的需求分析。
需求分析是对获取的需求信息进行筛选、分类、分析和整理的过程。
通过需求分析，可以为软件开发过程建立统一的目标和愿景，并清晰地了解软件所需的各种功能和需求。
在需求分析中，具有经验和专业知识的开发人员可以从用户需求中识别出各种隐含的需求和关键性需求，从而确保软件在开发和测试过程中不会出现重大差错。
需求规格说明是描述和记录软件需求的一种方法，通常使用需求文档的形式来实现。
在需求规格说明中，必须准确地描述软件系统需要实现的各种功能、约束和对用户的支持等方面。
通过需求规格说明，开发人员可以更好地理解软件需求，并明确确定软件的功能、性能等方面。
需求验证是验证软件开发过程是否成功地实现了用户的需求。
在需求验证过程中，开发人员、测试人员和用户进行沟通和测试，确保软件能够有效实现所有的系统、功能、性能和用户需求。
通过需求验证，可以发现和收集软件开发中的错误或不适当的需求，并及时做出相应的调整和修改，以保证软件的质量和成功上线。
总之，需求工程是软件开发的重要部分，必须严格遵守，以确保开发出高质量和灵活的软件系统，并为团队创建稳定、可靠、高度可重复性和可扩展的开发流程。
软件工程需求工程基础知识
软件工程需求工程基础知识软件工程是一门综合性的学科，其中需求工程是软件开发过程中至关重要的一部分。
在软件工程领域，需求工程基础知识的掌握对于确保软件项目成功和满足用户需求至关重要。
本文将介绍软件工程需求工程的基础知识。
一、需求工程的定义和重要性需求工程是通过与相关利益相关方沟通、分析和建模，以及定义软件需要满足的功能和性能等客观和主观需求的过程。
在软件开发过程中，需求工程是确保软件项目成功和满足用户需求的关键环节。
需求工程的目标是建立正确、一致、可追溯和可验证的需求规格说明，以确保软件开发团队理解用户需求，并能将其转化为可实现的软件系统。
二、需求工程过程需求工程过程包括需求获取、需求分析、需求规格说明、需求验证和需求管理等阶段。
1. 需求获取：需求获取是通过与相关利益相关方进行沟通和交流，从不同角度了解用户需求的过程。
常用的需求获取技术包括访谈、问卷调查、观察等。
2. 需求分析：需求分析是对获取到的需求进行梳理和整理的过程。
通过需求分析，可以识别出需求之间的关联性、冲突以及优先级等。
3. 需求规格说明：需求规格说明是对需求进行详细描述和规范化的过程。
常见的需求规格说明技术包括用例图、用例描述、数据流图等。
4. 需求验证：需求验证是确保需求规格说明的正确性和完整性的过程。
在需求验证阶段，可以通过检查、测试、评审等方式验证需求是否满足系统性能和用户需求。
5. 需求管理：需求管理是对需求进行跟踪、变更控制和配置管理的过程。
通过需求管理，可以确保需求在软件开发生命周期内得到有效管理和控制。
三、需求工程的关键技术1. 需求建模：需求建模是用于描述和分析软件需求的技术。
常见的需求建模技术包括数据流图、用例图、类图等。
2. 需求跟踪：需求跟踪是通过定义需求和设计元素之间的关系，实现对需求变更的管理和控制。
需求跟踪能够帮助开发团队追踪需求实现的状态和进程。
3. 用户界面设计：用户界面设计是通过用户友好的界面来满足用户需求的过程。
需求工程的7个主要活动
需求工程的7个主要活动⑴获取需求。
深入实际，在充分理解用户需求的基础上，获取足够多的问题领域的知识，积极与用户交流，捕捉、分析和修订用户对目标系统的需求，并提炼出符合解决领域问题的用户需求。
需求获取的方法一般有问卷法、面谈法、数据采集法、用例法、情景实例法以及基于目标的方法等。
⑵需求分析与建模。
对已获取的需求进行分析和提炼，进行抽象描述，建立目标系统的概念模型，需求概念模型的要求包括实现的独立性:不模拟数据的表示和内部组织等；需求模拟技术又分为企业模拟、功能需求模拟和非功能需求模拟等。
进一步对所建立的模型（原型）进行分析。
需求模型的表现形式有自然语言、半形式化(如图、表、结构化英语等)和形式化表示等三种。
⑶需求规格说明。
对需求模型进行精确的、形式化的描述，为计算机系统的实现提供基础。
⑷确认需求。
以需求规格说明为基础输入，通过符号执行、模拟或快速原型等方法，分析和验证需求规格说明的正确性和可行性，确保需求说明准确、完整地表达系统的主要特性，就是对需求规格说明与用户达成一致。
其主要任务是冲突求解，包括定义冲突和冲突求解两方面。
常用的冲突求解方法有：协商、竞争、仲裁、强制、教育等，其中有些只能用人的因素去控制。
⑸需求管理。
在整个需求工程过程中，贯穿了需求管理活动。
需求管理主要包括跟踪和管理需求变化，支持系统的需求演进。
由于客户的需要总是不断（连续）增长的，但一般的软件开发又总是落后于客户需求的增长，如何管理需求的进化(变化)就成为软件管理的首要问题。
对于传统的变化管理过程来说，其基本成分包括软件配置、软件基线和变化审查小组。
当前的发展是软件家族法，即产品线方法。
多视点方法也是管理需求变化的一种新方法，它可以用于管理不一致性，并进行关于变化的推理。
进化需求是十分必要的。
软件工程中的需求工程
软件工程中的需求工程在软件工程中，需求工程是一个关键的阶段，它在软件开发过程中起到了至关重要的作用。
需求工程是指对软件系统所需功能、性能和约束条件的识别、规范、文档化以及维护的过程。
在本文中，我们将探讨需求工程的定义、重要性以及常用的需求工程方法。
一、需求工程的定义需求工程是软件开发过程中的第一步，它旨在确保软件系统能够满足用户的需求和期望。
换句话说，需求工程是为了确定和理解用户对软件的需求，以便设计和开发人员可以据此创建出满足这些需求的软件系统。
二、需求工程的重要性1. 确保软件系统满足用户需求：需求工程的首要目标是确保软件系统能够满足用户的需求，避免开发出无用的软件或者与用户期望不符的软件。
2. 降低开发成本和风险：通过需求工程的精确分析和规范，可以减少开发过程中的错误和漏洞，提高开发效率，降低开发成本。
此外，需求工程还可以帮助开发团队识别和解决潜在的风险。
3. 促进团队合作和沟通：需求工程强调与用户、开发人员和其他利益相关者的密切合作和沟通。
这有助于增强团队的合作意识，提高沟通效率，确保各方对需求的理解保持一致。
4. 改进软件质量：需求工程可以帮助开发团队在早期识别和解决软件系统中存在的问题。
通过细致地分析需求并制定详细的需求规范，可以提高软件质量，减少后续开发过程中的修复和调整。
三、常用的需求工程方法1. 用户访谈和调查：通过与用户进行面对面的交流和深入的访谈，开发团队可以了解用户的实际需求和期望。
此外，还可以借助调查问卷等方式收集用户意见和反馈。
2. 需求文档化：将用户需求转化为可执行的需求文档，包括功能需求、非功能需求和约束条件等。
这些文档可以作为软件开发的指导和参考，确保开发人员和用户对需求有共同理解。
3. 原型开发：通过创建初步的软件原型，可以将抽象的需求具象化，方便用户和开发人员进一步理解和确认需求。
原型开发可以迅速反馈用户需求和期望，帮助开发团队及时调整和改进。
4. 需求验证和验证：需求验证是指与用户和其他利益相关者一起验证需求是否准确、完整和一致。
需求工程
需求工程任务
需求工程为以下工作提供了良好的机制： 理解客户需要什么，分析要求，评估可行 性，协商合理的方案，无歧义地详细说明 方案，确认规格说明，管理需求以至将这 些需求转化为可运行系统。需求工程过程 通过执行七个不同的活动来完成：起始、 导出、精化、协商、规格说明、确认和管 理。
起始
通常都是当确定了商业要求或发现了潜在 的新市场、新服务时项目才开始。业务领 域的共利益者定义业务用例，确定市场的 宽度和深度，进行粗略的可行性分析，并 确定项目范围的工作说明。 在项目起始阶段，软件工程师会询问一些 似乎与项目无直接关系的问题。目的是对 问题、方案需求方、期望方案的本质、客 户和开发人员之间初步的交流和合作的效 果建立基本的谅解。
首次提问
最后一组问题关注于沟通活动本身的效率。
你是回答这些问题的合适人选吗？你的回答 是“正式的”吗？ 我的提问和你想解决的问题相关吗？ 我的问题是否太多了？ 还有其他人员可以提供更多的信息吗？ 还有我应该问的其他问题吗？
首次提问
ቤተ መጻሕፍቲ ባይዱ
这些问题将有助于“打破坚冰”，并有助 于交流的开始，而且这样的交流对需求导 出的成功至关重要。但是，会议形式的问 与答并非一定是会取得成功的好方法。事 实上，Q&A会议应该仅仅用于首次接触， 然后就应该用需求诱导形式（包括问题求 解、协商和规格说明）取代。
可用的跟踪表
特征跟踪表：显示需求与重要的、客户可 见的系统/产品特征的关系。 来源跟踪表：标识每个需求的来源。 依赖跟踪表：指明需求之间是如何相互关 联的。 子系统跟踪表：按照需求所控制的子系统 对需求分类。 接口跟踪表：显示需求与内部和外部系统 接口的关系。
需求工程培训课件
。
04
需求工程实践与案例分析
需求工程实践方法
需求调研
通过访谈、问卷、观察等方式收集用户 需求和业务需求，了解现状和问题。
需求规格编写
编写详细的需求规格说明书，包括功能 需求、性能需求、接口需求、数据需求 等。
需求分析
对收集到的需求进行分析，将用户需求 转化为系统需求，确定系统的功能、性 能、安全等要求。
详细描述：当一个项目缺乏有效的需求 管理机制时。开发团队可能无法有效地 跟踪、管理、控制和沟通需求
1. 建立完善的需求管理流程，以确保所 有需求得到跟踪、评估、优先级排序和 变更管理。
06
需求工程发展趋势与展望
需求工程的发展趋势
多元化发展
需求工程正朝着多元化、个性化的方向发展，以满足不同 领域、不同场景的需求。
需求规格编写
需求验证
编写详细的需求规格说明书，确定系统功能 的具体实现方式、输入输出要求、界面设计 要求等。
通过原型或测试用例等方式验证需求的正确 性和完整性，确保系统能够满足用户需求。
需求工程实践案例二：网上购物系统
需求调研
收集购物网站用户的购物习惯、支付方式、物流 需求等信息，了解用户对于购物系统的期望和需 求。
需求工程实践案例三：医院管理系统
需求调研
需求分析
需求规格编写
需求验证
收集医院工作人员的医疗流程、 药品管理、病历管理等信息，了 解医院对于管理系统的期望和需 求。
确定系统需实现的功能包括挂号 、问诊、开药、收费、病历管理 等，分析系统的性能要求、安全 要求和数据要求。
编写详细的需求规格说明书，确 定系统功能的具体实现方式、输 入输出要求、界面设计要求等。
提高软件质量
需求工程
� 什么是需求工程
� 把所有与需求直接相关的活动通称为需求工 程。通常是一些过程的集合：需求获取(需求引出)、需求
分析和编写软件规格说明书(SRS)及验证(包括鉴定和证实)。
� 需求工程中的活动可分为两大类，一类属于 需求开发，另一类属于需求管理。
11
需求工程
需求开发
需求管理
需求获取
需求分析 编写规格说明
⑸ 将系统级的需求分为几个子系统，并将需求中 的一部份分配给软件组件。 ⑹ 了解相关质量属性的重要性。 ⑺ 商讨实施优先级的划分。 ⑻ 将所收集的用户需求编写成规格说明和模型。 ⑼ 评审需求规格说明，确保对用户需求达到共同 的理解与认识，并在整个开发小组接受说明之前 将问题都弄清楚。
需求管理的目的是维护需求并且确保能把对需求的更改反映到项目 计划、活动和工作产品中。
需求
设计
编码 开发测试 系统测试 实际运行
5
在软件工程中，所有的相关共利益者(stakeholder) 都感兴趣的就是需求分析阶段。
这些相关共利益者包括客户、用户、业务或需 求分析员(负责收集客户需求并编写文档，以及负责客 户与开发机构之间联系沟通的人)、开发人员、测试人 员、用户文档编写者、项目管理者和客户管理者。
� 按照《客户访谈记录分析表》模板填写记录。
� 如果同一部门意见不一致，则由部门领导确定意 见；
� 如果不同部门意见不一致，则应再召开部门间会 议统一意见。
� 注意：这时的会议需要不同部门的领导参加，并 且不同部门的与会人的级别应相同。如会议上不 能统一意见，则报请上级确定。
� 需求开发人员需抽象和总结用户的直接活动，以 确保所获取的需求具有普遍性。主要观察业务流 程、业务发生频率、业务量及业务信息
需求工程
需求工程支持系统化的需求建模过程和途径,为软件需求模型提供预定义的语义解释和预定义的语义约束,支 持需求提供者和系统开发者从语义上正确地理解所获得需求信息的含义,使得需求提供者可以正确地判断当前已提 供的需求信息是否真正表达了他们自己的意图,也使得系统开发者可以了解自己对需求提供者所提供需求信息的理 解程度。软件项目成功的关键是开发者真正理解并在软件中正确地表达用户的意图。
需பைடு நூலகம்工程
一门学科技术
01 概念
03 方法 05 作用
目录
02 发展 04 阶段 06 内容
需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目 标系统的所有外部特征的一门学科。它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束， 形成需求文档，并对用户不断变化的需求演进给予支持。
（1）软件需求规格说明正确描述了预期的满足各方涉众需求的系统能力和特征。 （2）从系统需求、业务规则或其他来源中正确的推导出软件需求。 （3）需求是完整的、高质量的。 （4）需求的表示在所有地方都是一致的。 （5）需求为继续进行产品设计和构造提供充分的基础。
需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，确保产品依据需求文档进行开发，建立与 维护“需求——设计——编程——测试”之间的一致性，确保所有工作成果符合用户需求。需求跟踪是一项需要 进行大量手工劳动的任务，在系统开发和维护的过程中一定要随时对跟踪链信息进行更新。需求跟踪能力的好坏 会直接影响产品质量，降低维护成本，容易实现复用，同时，需求跟踪还需要建设方的大力支持。
范。为了提高目标软件需求规格的质量,需求工程提出了以下几种方法。
结构化需求抽取方法
软件工程的核心概念
软件工程的核心概念软件工程是指通过系统化的、规范化的、可度量的方法，应用科学和工程原理，对软件的开发、运维和维护进行管理的一门学科。
软件工程的核心概念包括需求工程、设计、编码、测试、维护等。
本文将依次介绍这些核心概念及其在软件工程实践中的重要性。
一、需求工程需求工程是软件工程的起点，它主要关注于确定和分析用户需求。
在软件工程实践中，需求工程通过调查、访谈、问卷调查等方式与用户进行沟通，确保软件系统能够满足用户的期望和需求。
在需求工程阶段，需求工程师需要准确地收集和分析用户需求，并将其转化为具体、可测量的需求规格。
只有明确的需求才能为软件设计和开发提供有效的依据。
二、设计设计是软件工程的核心环节之一。
通过设计阶段，开发团队将需求规格转化为具体的系统设计方案。
在设计过程中，要考虑系统的架构、模块划分、数据结构、算法设计等方面。
良好的设计能够提高系统的可维护性、可扩展性和性能等方面的指标。
设计还需要进行合理的模块划分和接口设计，以便团队成员之间能够协同工作，提高开发效率。
三、编码编码阶段是将设计方案转化为计算机可执行的代码的过程。
在编码过程中，开发人员需要遵循编码规范，编写清晰、可读性强的代码，并采用合适的注释和代码标识来提高代码的可管理性。
编码过程中还需要进行代码的单元测试，及时发现和修复问题。
编码是软件工程实践中最为直接的环节，编写高质量的代码对于软件系统的稳定性和可靠性至关重要。
四、测试测试是软件工程质量保证的重要环节。
在测试阶段，测试人员需要根据需求规格和设计方案设计测试用例，并在实际环境中执行测试以验证系统的功能、性能、兼容性等。
通过测试，能够发现并修复软件中的缺陷和问题，提高软件的质量。
测试需要全面、有效地覆盖系统的各个功能模块，确保软件能够稳定运行。
五、维护软件维护是软件工程的最后一个环节，也是软件生命周期中最长、最耗费人力和资源的阶段。
维护旨在保证软件系统能够持续稳定地运行，并根据用户需求进行功能扩展或修复bug。
需求工程
5
系统功能描述为：用户输入用户名和密码，
系统在用户信息中核对，如果正确，则登陆
成功；如果不正确，则提示登陆失败，不能 进入系统。
6
借书功能如何描述？
用户功能描述：读者将借书证和要借的书给管理员，
管理员扫描借书证和书的条码，验证是否可借，如果
允许借出，则借书成功，读者借到书，否则，借书失
败。
7
系统功能描述：管理员输入读者号以及书号 ，系统根据读者信息中验证此读 者是否可借 书，在图书信息中验证此书是否可以被借， 如果验证成功，则生成一条借书记录，借书 成功；否则借书不成功。
11
二、需求分析过程
通过与用户交流获取真正需求(problem recognition) 评估和分析(evaluation and synthesis) 建模(modeling) 写出需求规格说明文档(specification) 复查(review)
12
3.1需求分析(requirement anaysis)
3、关系：数据对象之间相互连接的方式。
一对一（1：1） 一对多（1：N) 多对多（M:N)
31
E-R图形表示
⑴ Entities ⑵ Relations
1 1
Student , Instructor 例：
,
3.4实体关系图
Class
例：
1
Enrolled in
Teach
N
MN⑶ Attri源自utes370层DFD
3.5数据流图 存款/取 款单 存款/取款 信息
储户
储蓄系统
储户
存款成 功信息
p4
帐号信息 及存款额 存款/取 p1 款单 接收并分类
1层DFD
需求工程
一1.软件危机指的是在计算机软件的开发和维护过程中所遇到的一系列严重问题12）用户对已完成的系统常常不满意；3）软件的质量不可靠；4）软件的可维护程度较低；5）软件常常没有适当的文档资料；6）软件的成本不断提高；7）软件开发生产的效率较低；3.需求开发包括：需求获取、需求分析、需求规格说明和需求验证4个部分；需求获取：目的从项目的张罗规划开始建立最初的原始需求。
需求分析：目的保证需求的完整性和一致性；需求规格说明：目的将完整、一致的需求与能够满足需求的软件行为以文档的方式明确地固定下来；需求验证：目的保证需求及其文档的正确性，即需求真实地反映了用户的真实意图；以及通过检查和修正保证需求及其文档的完整性和一致性；4.软件的模拟特性：软件在运行中表现出来的特性、行为应该和应用的实际情况保持一致。
5.需求工程与系统工程的关系传统的需求处理是软件工程的需求阶段；但系统化的需求工程将软件需求开发和系统需求开发结合起来，在系统工程的开始阶段起到了重要的作用。
需求工程处于系统的起始阶段，包括系统需求开发和软件需求开发两个部分。
6.需求工程的重要性软件开发是利用通用的计算机结构，构建一个有用的软件系统，来满足人们的某些目的，定义问题就是需求工程的任务。
开发软件系统最为困难的部分就是准确说明开发什么。
最为困难的概念性工作便是编写出详细技术需求。
⏹容易忽略需求工程重要性的地方❑问题广为人知问题小而简单第二章1.需求的定义：（1）用户为了解决问题或达到某些目标所需要的条件或能力；（2）系统或系统部件为了满足合同、标准、规范或其它正式文档所规定的要求而需要具备的条件或能力；（3）对（1）或（2）中的一个条件或一种能力的一种文档化表述。
2.需求的分类⏹功能需求：和系统主要工作相关的需求。
功能需求主要表现为系统和环境之间的行为交互。
业务需求：是系统建立的战略出发点，表现为高层次的目标，描述了组织为什么要开发系统。
用户需求：执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么。
需求工程
• 需求跟踪是指通过比较需求文档与后续工作成果之间的对 应关系，确保产品依据需求文档进行开发，建立与维护 “需求——设计——编程——测试”之间的一致性，确保 所有工作成果符合用户需求。需求跟踪是一项需要进行大 量手工劳动的任务，在系统开发和维护的过程中一定要随 时对跟踪联系链信息进行更新。需求跟踪能力的好坏会直 接影响产品质量，降低维护成本，容易实现复用，同时， 需求跟踪还需要建设方的大力支持。
开发系统描述
系统需求 开发系统设计 子系统组件需求 （子系统需求） 开发子系统设计 子系统组件需求 （下层子系统需求）
抽象模型
解 决 方 案 领 域
系统设计 框架
子系统设 计框架
二、需求的重要性
• 美国于1995年开始的一项调查的结果有力的证明了需求的 重要性。 • 在调查中，他们对全国范围内的 8000 个软件项目进行跟 踪调查，结果表明，有1/3的项目没能完成，而在完成的 2/3 的项目中，又有1/2的项目没有成功实施。他们仔细 分析失败的原因后发现，与需求过程相关的原因占45%， 而其中缺乏最终用户的参与以及不完整的需求又是两大首 要原因，各占13%和12%。
三、需求开发
• 3、需求文档编写阶段
编写原则
◆明确认识 ◆认清对象 ◆抓住要点 ◆具体描述
三、需求开发
• 3、需求文档编写阶段 明确认识
对于编写需求文档的人员来讲，所要关注的问题是：最终需要的是什么， 大致的模型，而不用去在意这个过程怎么实现。 前提：需求的讨论与沟通 （1）总的需求的可行性 （2）核心功能的实现 （3）思路的调整或细节化补充 （4）找出最优方案
三、需求开发
• 1、需求获取
（一）访谈与调查
• 在具体的实践中，通常采用折衷的方法，即适当地计划好面谈，但不 要过于详细，允许有一定的灵活性。一般按照如下原则进行准备： – 所提问的问题应该循序渐进，从整体的方面开始提问，接下来的 问题应有助于对前面的问题更好的理解和细化； – 不要限制用户对问题的回答，这有可能会引出原先没有注意的问 题； – 提问和回答在汇总后应能够反映用户需求的全貌
软件工程第三章需求工程
软件工程第三章需求工程在软件工程中，需求工程是至关重要的一环。
它就像是一座建筑的蓝图，为后续的设计、开发、测试等工作指明了方向。
如果需求工程做得不好，就好比在没有清晰规划的情况下盲目施工，结果必然是混乱和低效的。
需求工程主要包括需求获取、需求分析、需求规格说明和需求验证这几个关键步骤。
需求获取是需求工程的起点。
这可不是一件简单的事情，它需要与各种利益相关者进行有效的沟通和交流。
这些利益相关者可能包括客户、用户、业务经理、技术专家等等。
他们对于软件系统的期望和需求各不相同，因此获取到全面、准确的需求信息是一个挑战。
在与利益相关者交流时，我们需要运用各种技巧。
比如，倾听是非常重要的。
要让他们能够畅所欲言，表达出自己的真实想法和需求。
同时，提问也是必不可少的。
通过有针对性的问题，可以引导他们深入思考，挖掘出一些潜在的需求。
此外，观察他们的工作流程和操作习惯，也能为获取需求提供有价值的线索。
需求分析是对获取到的需求进行深入理解和梳理的过程。
这就像是把一堆杂乱无章的拼图碎片整理成一幅完整的画面。
我们需要识别出需求中的关键元素，理解它们之间的关系，并且找出可能存在的冲突和不一致。
为了进行有效的需求分析，我们常常会使用一些工具和技术。
比如，用例图可以帮助我们清晰地描述系统的功能和用户与系统之间的交互。
数据流图则能够展示数据在系统中的流动和处理过程。
状态转换图可以用于描述系统中对象的状态变化。
通过这些工具，我们能够更直观地理解需求，发现潜在的问题。
需求规格说明是将分析后的需求以一种清晰、准确、无歧义的方式记录下来。
它就像是一份合同，明确了软件系统应该具备的功能和性能。
需求规格说明通常包括功能需求、非功能需求、约束条件等内容。
功能需求描述了系统应该完成的具体任务和操作。
非功能需求则关注系统的性能、可靠性、可维护性、安全性等方面的要求。
约束条件可能包括技术限制、预算限制、时间限制等。
在编写需求规格说明时，语言要简洁明了，避免使用模糊不清的词汇和语句。
软件工程中需求工程的研究与应用
软件工程中需求工程的研究与应用现如今，软件已经是人们日常生活中不可或缺的一部分。
随着社会发展和科技进步，软件的规模和种类越来越多，软件质量的要求也越来越高。
而软件工程中，需求工程是软件开发生命周期中至关重要的一个环节。
在这篇文章中，我们将探讨需求工程的研究与应用。
一、需求工程是什么？需求工程是软件工程中的一个重要领域，它主要涉及软件产品开发过程中的需求分析、需求规格说明和需求验证等活动。
它的目标是确定用户或客户所需的功能、服务和性能，以便在软件产品的开发中加以考虑和实现。
同时，需求工程也包括评估和管理需求，以确保软件开发的正确性、可行性和优势性。
二、需求工程的重要性在软件开发过程中，需求工程是至关重要的一个环节。
它确保软件产品能够满足用户的需求和期望，同时也对软件的质量和可维护性产生了影响。
以下是需求工程在软件开发中的几个重要作用：1. 帮助确定用户需求和期望需求工程中通过对用户需求和期望的分析，帮助开发团队更好的理解和捕捉用户对软件功能、服务和性能的需求。
只有在准确理解用户需求的基础上才能开发出满足用户要求的软件产品。
2. 提升软件的质量和可维护性通过好的需求工程，能够在软件开发过程中避免代码漏洞、质量问题和可维护性方面的问题。
在需求工程的过程中，开发团队可以管理需求变更，并保障最终交付的软件产品是有效、可靠和可维护的。
3. 降低项目成本需求工程依赖于分析和理解项目需求，定制更好的工艺和流程，以提高开发效率和降低项目成本。
在需求工程中，项目团队可以通过提高价值的规范和流程来帮助自己在开发过程中高效地解决问题。
三、需求工程的组成和活动需求工程是一个包括多个活动和方法的领域，它以如下几个组成部分串联到一起：1. 需求收集需求收集是需求工程中最关键的一个环节。
在这个过程中，开发团队会与用户和利益相关者交流和讨论，以形成对项目需求的共识。
这个过程会涉及各种方法，包括问卷调查、面谈、聚焦小组等等。
2. 需求分析与规格说明在需求收集之后，开发团队需要对需求进行分析和规格说明的编写。
浅谈需求工程的定义及其内容、现状(精)
浅谈需求工程的定义及其内容、现状2.1需求工程概述 2.1.1需求工程的概念需求工程是指应用已验证的有效的技术、工具、方法进行需求分析，确定客户要求，帮助分析人员理解问题，并定义目标系统的所有外部特征的一门学科。
它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。
需求工程的概念最初来自于计算机软件系统工程，主要用于解决计算机软件系统开发过程中的需求问题。
随着需求工程的发展，人们认识到需求工程研究的对象不仅局限于计算机软件系统，也适用于一般的系统和组织。
近几年，需求工程与组织管理的联系得到了来自流程再造、组织变更、设计理论等领域研究人员和业内人士的关注，需求工程现在已经发展到了与系统和组织等方面相关的更广阔的视角。
2.1.2需求工程的国内外发展现状需求工程是随着计算机的发展而发展的，在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，需求分析很少受到重视。
后来软件开发引入了生命周期的概念，需求分析成为其第一阶段。
随着软件系统规模的扩大，需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。
人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。
80年代中期，形成了软件工程的子领域——需求工程(requirement engineering,RE)。
进入90年代以来，需求工程成为研究的热点之一。
从1993年起每两年举办一次需求工程国际研讨会(ISRE)，自1994年起每两年举办一次需求工程国际会议(ICRE)，在1996年Springer-Verlag发行了一新的刊物——《Requirements Engineering》。
一些关于需求工程的工作小组也相继成立，如欧洲的RENOIR(Requirements Engineering Network of International Cooperating Research Groups)，并开始开展工作。
国际组织对需求工程的定义
国际组织对需求工程的定义需求工程是指在软件开发过程中，对用户需求进行识别、分析和规范化的过程。
国际组织对需求工程的定义主要包括以下几个方面。
需求工程被定义为一种系统化的方法和过程，用于收集、分析、规范和管理软件系统的需求。
国际组织强调了需求工程的系统性和方法性，意味着需求工程需要遵循一定的步骤和规范，以确保对需求的全面和准确理解。
需求工程的定义还强调了需求工程的目标是建立一个准确、一致、完整和可追踪的需求规范。
这意味着需求工程不仅仅是对需求进行收集和分析，还需要对需求进行规范化和管理，以确保需求的准确性和一致性。
此外，需求规范应该是完整的，即包含了系统的所有功能和性能需求，并且需求之间应该是一致的。
最后，需求应该是可追踪的，即每个需求都可以追溯到相应的用户需求或系统目标。
国际组织还强调了需求工程与软件开发过程中其他过程的关系。
需求工程被定义为与软件开发过程中其他过程（如设计、实施、测试等）密切相关的过程。
这意味着需求工程不是一个孤立的过程，而是与软件开发过程中的其他过程相互作用和影响的。
因此，需求工程需要与其他过程紧密合作，确保软件系统按照用户需求进行开发和交付。
国际组织还强调了需求工程的重要性和价值。
需求工程被定义为软件工程中最重要和最困难的过程之一。
这是因为需求工程的成功与否直接关系到软件系统最终是否能够满足用户的需求和期望。
因此，需求工程在软件开发过程中起着至关重要的作用，对于提高软件质量、降低开发成本和满足用户需求具有重要的价值和意义。
国际组织对需求工程的定义包括了需求工程的系统性和方法性、需求规范的准确性和一致性、需求的完整性和可追踪性、需求工程与其他软件开发过程的关系以及需求工程的重要性和价值。
这些定义为需求工程的实施和应用提供了指导和参考，对于软件开发的成功具有重要的意义。
需求工程
1可检验性因素：可检验的需求，使开发人员能够确认自己所开发的软件会满足用户需求，测试人员也会根据需求进行测试，是否能够正常运行，是否能够给当地处理例外条件，是否能够使用数据集合的各种取值。
2可行性因素：每一项需求都必须是在已知系统和环境的限制范围内可以实施的，为避免不可行的需求最好在获取需求工程中始终有一位软件开发小组的技术人员与需求分析人员或市场人员在一起工作由他负责检查技术可行性。
3业务需求：表示某个组织或客户高层次的目标。
通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。
4用户需求：描述的使用户的具体目标，或用户要求系统必须能够完成的任务。
通常用例、场景描述都是表达用户需求的有效途径。
5功能需求：规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。
通常功能需求描述的是开发人员需要实现的内容。
6可用性：系统的可用行是体现系统成功与否的重要指标。
用户端权利法则使前提并非需求。
7有效性划分成性能和可伸缩性两个子范围：性能：系统的运行情况，平稳缓慢地运行，系统可以达到响应时间的目标，应用程序的设计符合性能要求，利用缓存；可伸缩性：系统在小范围内运行相当快，当扩展至每秒每分钟或者每小时成千上万个活动，设计达到吞吐量目标复制系统来实现线性扩展，存在瓶颈。
8快速应用开发模型（RAD）包含几个阶段：需求计划阶段、用户描述、构建阶段、结束。
9快速应用开发模型（RAD）优点：采用高效率的开发工具，从而减少了整个产品的开发周期，提高了生产率，降低了成本；用户能够持续地参与开发，提高了用户参与程度，从而使用用户的满意度上升，保证了系统能够满足用户的需求；工作重点从文档转为构建，所见即所得。
10快速应用开发模型（RAD）缺点：如果用户不能持续地参与整个生命周期中，最终产品会受到负面影响；要求系统能适当模块化，如果没有可重用的组件，它的效率就会下降；盲目应用时，会缺乏成本概念和项目完成的时间限制，项目有永远不能完结的风险；对于大型的但可伸缩的项目，RAD需要足够的人力资源以创建足够的RAD组；RAD要求承担必要的快速活动的开发者和用户在一个很短的时间框架下完成一个系统，如果两方中的任何一个没有完成约定，都会导致RAD项目失败快速应用开发模型（RAD）模型的使用背景、条件：系统可模块化（基于组件的结构）和可缩放；用户能参与到整个生命周期中；项目开发周期很短，通常约60天；项目团队熟悉问题领域，能熟练使用开发工具。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
11/63
需求规约(Specification)
• 通过建立完整的信息描述、详细的功能和 行为描述、性能需求和设计约束的说明、 合适的验收标准，给出对目标软件的各种 需求 • 软件需求规约是分析任务的最终产物 • 需求规约作为用户和开发者之间的一个协 议，在之后的软件工程各个阶段发挥重要 作用
12/63
– – – – – 确定系统或产品范围的限制性描述 与系统或产品有关的人员及特征列表 系统的技术环境的描述 系统功能的列表及应用于每个需求的领域限制 一组描述不同运行条件下的应用场景以及为更好地定 义需求而开发的系统原型
• 需求获取收集的“原始材料”为进行需求 分析提供了基础
9/63
需求分析与协商
17/63
回顾：需求的各种形式
• 从高度抽象的系统服务或系统目标到对某 一系统功能的精确约束 • 原始需求
– – – – 客户对软件系统及新的工作方式的期望目标 客户单位已经存在的日常工作方式和业务规则 系统所属领域固有的法规、标准或惯例等 一般目标：更快、更好、更安全
• 需求文档
– 自然语言描述 – UML图等图形表示 – 业务规则表格
30/63
组成联合小组
• 突出客户在需求分析乃至项目开发 中的作用 • Facilitated Application Specification Techniques (FAST)
– 打破用户和开发者的界限，共同组成一个联合小组 – 发挥各自的长处，共同负责项目的推进
– 有助于发挥各自优势并增进解和协调
28/63
需求调研例—学生选课系统-2
• 第三阶段：基本了解需求后就一些关键细 节通过问卷进行明确
– 在已经了解总体选课人数之后，需要进一步了解通 常情况下的选课持续时间、是否按院系逐步开放选 科、选课人数的一般分布等—与性能设计密切相关 – 推荐关键管理人员使用USB Key设备，经济上是否 可以接受 – ……
软件工程
第3章 需求工程
需求:成功的软件开发的前提
软件质量=
系统所实现的需求/客户所期望的需求
• 软件项目投标及签订合同的基础 • 软件系统实现的基础 • 系统确认移交的基础
2/63
需求的定义
• IEEE Standard Glossary of Software Engineering Terminology
– 产品项目：一般是根据公司战略和市场需求研发，旨在进 行批量出售或推广的项目 – 工程项目：一般是根据与用户签定的合同研发，旨在满足 特定用户需求的项目
20/63
需求获取方法与Biblioteka 略• • • • • 建立顺畅的通信途径 深入客户方进行访谈与调查 观察用户操作流程 组成各方联合小组 使用基于用况(Use Case)的方法
• 需求分析处理的是未整理的原始需求，此时 发现的问题是客户的问题 • 需求确认的对象是经分析后形成的需求规格 说明，此时发现的问题是需求分析人员的问 题，此外还需要考虑需求文档是否满足相应 的质量标准
14/63
15/63
• 在实际的开发过程中，获取、分析、建 模、编写规约和验证这些需求开发活动 不会是线性地、顺序地完成。实际上， 这些活动是交叉的、递增的和反复的。
⑤
⑥
32/63
用况(Use Case)
• 分析员可以根据所获取的需求创建一组标 识一串待建造系统的使用场景 • 创建用况模型的主要步骤如下：
1) 确定谁会直接使用该系统，即参与者（Actor） 2) 选取其中一个参与者 3) 定义该参与者希望系统做什么，参与者希望系统作的每件 事将成为一个用况 4) 对每件事来说，何时参与者会使用系统，通常会发生什么， 这就是用况的基本过程 5) 描述该用况的基本过程
21/63
建立顺畅的通信途径
• 建立分析所需要的通信途径，以 保证能顺利地对问题进行分析
22/63
访谈与调查
• 访谈/调查计划：从初步的需求了解 出发，制订需要了解或讨论的问题 的顺序和范围等
– 有利于保证访谈的效率和全面性，但灵活性不足
• 在具体的实践中，通常采用折衷的 方法，即适当地计划好面谈，但不 要过于详细，允许有一定的灵活性
• 对需求进行分类组织，分析需求之间的 关系 • 检查需求的一致性、重叠和遗漏的情况 • 根据用户的需要对需求进行排序。 • 在需求获取阶段，经常出现以下问题：
– 提出的要求超出软件系统可以实现的范围或实现能力 – 不同的用户提出了相互冲突的需求
10/63
系统建模
• 建模工具的使用在用户和系统分析人员之 间建立了统一的语言和理解的桥梁 • 系统分析人员借助建模技术对获取的需求 信息进行分析和表达，排除错误和弥补不 足，确保需求文档正确反映用户真实意图 • 常用的分析和建模方法有面向数据流方法、 面向数据结构方法和面向对象的方法
27/63
需求调研例—学生选课系统-1
• 第一阶段：了解基本情况
– 请教务处老师介绍背景，如学生总数、课程数量、 选课相关的基本制度等
• 第二阶段：制订访谈计划，深入讨论 相关需求
– – – – 除了学生还有哪些相关用户? 选课规则(学分、课程人数限制等)、退课规则 了解客户对系统的期望：准确、访问速度快… ……
23/63
访谈与调查的原则
• 所提问的问题应该循序渐进，从整体 的方面开始提问，接下来的问题应有 助于对前面的问题更好的理解和细化 • 不要限制用户对问题的回答，这有可 能会引出原先没有注意的问题 • 提问和回答在汇总后应能够反映用户 需求的全貌——不断汇总-反馈-汇总
24/63
访谈与调查的具体形式-1
5/63
内容摘要
• 需求工程概述 • 需求获取 • 需求分析、协商与建模 • 需求规约与验证 • 需求管理
6/63
• Alan Davis 把需求工程定义为“直到 （但不包括）把软件分解为实际架构构 件之前的所有活动” (强调做什么) • Herb Krasner定义了需求工程的五阶段 生命周期：需求定义和分析、需求决策、 形成需求规格、需求实现与验证、需求 演进管理 • Matthias Jarke和Klaus Pohl提出了三 阶段周期的说法：获取、表示和验证 • … …
– 用户解决一个问题或达到一个目标所需要的 一种状况或能力 主观需求 – 系统为了满足一种约定、标准、规格说明或 其它正式文件而必须满足或拥有的一种状况 或能力 客观需求 – 以上两种状态或能力的文档化表示
需求文档
3/63
功能性需求和非功能性需求
• 功能性需求
– 系统需要提供的服务或功能：如图书检索 – 系统对特定输入的处理方式：如对非法输入的提示 – 系统在特定环境下的行为：如长时间无操作时的屏保
7/63
需求工程的六个阶段
• • • • • • 需求获取：资料收集 需求分析与协商：理解分析整理 系统建模：用模型描述(写下来) 需求规约：完善需求文档并定稿 需求验证：验证确认 需求管理：整体规划及变更管理
8/63
需求获取
• 系统分析人员通过与用户的交流，了解业 务现状以及对待开发系统的期望
• 会议讨论法
– 适用于需求调研早期 – 特点：需求获取的信息量大，但有时全面性和深 入性不足 – 做好调研计划，同时掌握好计划与灵活性的平衡
• 一般由客户方的基本情况介绍开始 • 随着情况了解的深入，分析人员逐渐成为主导： 要求分析人员有较强的理解和交流能力、思维敏 锐，能够有效地引导并把握讨论的议题和方向
• 客户要求高安全性，而开发组反馈推荐解决方案是使用 USB Key这样的硬件证书进行身份验证和加密传输，但可 能会到来额外的运营开销，需要客户确认是否能够接受
26/63
访谈与调查的具体形式-3
• 原型系统
– 由开发小组快速开发一个近似的功能原型(往往以操 作界面为主)，分析人员与客户围绕着原型系统的演 示进行需求讨论 – 适用于客户仅有一些宏观的设想而自身需求还不明 确的情况下 – 特点：能够帮助客户将自己的设想落实为具体需求， 能够有效激发客户的思维，但需要额外的原型开发 开销 – 要求分析人员自身对需要有较强的认识，基本能够 把握客户的潜在想法或者开发方有类似的成品软件
33/63
用况的描述方法
•
处理销售：顾客携带所购商品到达收银 摘要方式：简洁的一段式概要，通常用 台。收银员用POS系统记录每件商品。系 处理退货： 于主成功场景，例如《处理销售》 统逐行显示细目并显示总价。顾客输入 主成功场景： 支付信息。系统对支付信息进行验证和 – 快速了解主题和范围 顾客携带商品到收银台退货。收银员 记录。系统更新库存信息。顾客从系统 使用 POS系统记录并处理每件退货商品。 非正式方式：以非正式的段落方式覆盖 得到购物收据并携带商品离开。 替换场景： 用例中的不同场景，例如《处理退货》 如果顾客使用信用卡付款，而其信用 – 进一步细化用户需求并与用户进行确认 卡账户退款交易被拒绝，则告知客户并使 详述方式：在需求分析阶段还将进一步 用现金退款。 细化 如果……
需求验证
• 需求开发阶段工作的复查手段 • 对功能的正确性、完整性和清晰性， 以及其它需求给予评价 • 为保证软件需求定义的质量，评审应 以专门指定的人员负责(应该是需求 分析人员之外的其他人员)，并按规 程严格进行
13/63
需求确认与需求分析
• 二者密切相关
– 都需要对系统需求中的遗漏和冲突进行识别 和分析 – 区别
34/63
•
•
内容摘要
• 需求工程概述 • 需求获取 • 需求分析、协商与建模 • 需求规约与验证 • 需求管理
35/63
需求分析原则
• 必须能够表示和理解问题的信息域(数据) • 必须能够定义软件将完成的功能 • 必须能够表示软件的行为(作为外部事件 的结果) • 必须划分描述数据、功能和行为的模型 (分离描述)，从而可以分层次地揭示细节 • 分析过程应该在基本信息基础上不断细化