软件工程：第四章 软件需求与获取分析(一)
软件工程中的软件需求获取与分析方法
软件工程中的软件需求获取与分析方法软件需求获取和分析是软件工程开发过程中至关重要的一环。
它是为了确保软件开发的成功和软件产品能够满足用户的需求而进行的。
本文将介绍几种常用的软件需求获取与分析方法。
一、用户需求访谈用户需求访谈是软件工程中最常用的需求获取方法之一。
它通过与用户进行面对面的交流，了解其对软件产品的期望、功能、界面设计等方面的要求。
在访谈过程中，可以通过提问、观察、记录等方式获取用户的需求信息，并加以整理和分析。
在进行用户需求访谈时，软件工程师需保持沟通的良好态度，尊重用户的观点和需求。
同时，要注意细节，准确记录用户的需求，以便后续的需求分析和软件设计。
二、问卷调查问卷调查是另一种常用的需求获取方法。
通过设计问题，向用户发放问卷，收集用户对软件产品的需求和意见。
问卷调查可以同时面向多个用户，获取多个用户的共同需求和差异化需求。
在设计问卷时，要注意问题的合理性和可操作性。
问题应该具体明确，避免主观和模糊的描述，以便用户能够明确表达自己的需求和意见。
三、原型设计原型设计是一种通过创建软件界面的模型来获取用户需求的方法。
软件工程师可以使用原型设计工具，如Axure、Sketch等，创建界面原型，展示给用户，并征求其意见和建议。
原型设计可以帮助用户更直观地理解软件的功能和操作流程，从而准确地表达自己的需求。
软件工程师可以通过用户的反馈，不断改进原型设计，直到满足用户的需求为止。
四、场景分析场景分析是一种通过模拟用户在特定场景下的需求和行为来获取需求的方法。
软件工程师可以通过观察和记录用户在特定场景中的工作流程，了解他们所需的功能和服务。
在进行场景分析时，要注意选取具有代表性的场景，并与用户充分沟通，确保对场景的理解和模拟的准确性。
通过场景分析，可以更全面地获得用户的需求，为软件开发提供参考。
五、迭代开发迭代开发是一种将软件需求获取与分析过程融入到软件开发过程中的方法。
软件工程师可以在每个开发迭代的过程中，与用户进行交流和需求确认，并根据用户的反馈进行相应的修改和调整。
软件工程中的用户需求获取与分析
软件工程中的用户需求获取与分析软件工程中的用户需求获取与分析是软件开发的重要环节之一，它是指通过各种途径，了解用户对软件的需求，它对于软件的质量、可靠性和可维护性都有着至关重要的作用。
第一节：用户需求的获取获取用户需求是软件开发的第一步，如果不能正确的获取用户需求，那么剩下的开发工作也就没有必要。
在获取用户需求的过程中，需要使用到各种方法，其中最常见的方法有：1.用户访谈法用户访谈法是通过与用户面对面的交流，了解用户的需求，这个过程中，需要注意保持耐心和客观，避免过度引导用户。
2.调查法调查法是通过问卷调查的方式，收集用户对软件的需求，这种方法适用于大规模的用户需求获取。
3.案例分析法案例分析法是通过分析用户已有的软件需求或者软件应用过程中的问题，来获取用户的需求。
4.焦点小组法焦点小组法是通过组织一些用户（或者用户代表）进行讨论，从而得出用户对软件的需求。
5.用户练习法用户练习法是通过让用户在使用软件前尝试使用一些操作手册或者演示版，从而获取用户对软件功能的需求。
通过上面的几种方法，就可以获取到用户对软件的需求，但是，获取到用户需求，并不意味着这些需求就是最终的需求，我们还需要对用户的需求进行分析、筛选和整合。
第二节：用户需求的分析与整合用户需求的分析与整合是一种综合性的工作，需要对用户提供的需求进行系统的分析，然后整合成系统的需求。
在用户需求的分析过程中，需要考虑以下几点：1.需求的真实性在用户提供需求的过程中，可能会存在一些过度的描述或者夸大实际需求的情况，需要通过多次电话或者面对面交流的方式，了解其真实需求。
2.需求的优先级每一个用户提出的需求都有其优先级，需要根据需求的紧急程度和相对重要性确定需求的优先级，从而使得开发人员有条理的进行开发。
3.需求的明确性在用户提供需求的过程中，可能会存在一些术语、缩写等难以理解的东西，需要针对性的进行解释和澄清。
4.需求的可行性在用户提出的需求中，会存在一些技术实现上不可行或者成本过高的需求，需要通过技术分析和项目预算来确认需求的可行性。
软件工程需求分析(精品PPT)
•将功能和信息结构分配到这些系统元素中 •需求分析的任务
•深入描述软件的功能和性能 •确定软件设计的约束和软件同其它系统元素的接口细节
•定义软件的其它有效性需求
第四页，共七十七页。
需求(xūqiú)分析的具体任务
•需求分析阶段的具体任务：
•确定对系统的综合要求
•系统功能要求
第四章 析根底
软件工程 需求分 (ruǎn jiàn ɡōnɡ chénɡ)
第一页，共七十七页。
第四章 需求分析 根底 (fēnxī)
• 需求(xūqiú)分析的任务与原那么〔重点〕 • 需求分析的任务 • 需求分析的过程 • 软件需求分析的原那么 • 初步需求获取技术 • 需求建模〔重点〕 • 问题抽象、问题分解与多视点分析 • 支持需求分析的快速原型技术 • 需求规格说明书
第二十六页，共七十七页。
教务管理系统调查分析过程 1、认真学习教务管理方面的知识，重点掌握其中
的名词和术语 2、收集目前教务管理方面资料和软件，了解其特
•了解系统的需求 •软件开发是系统开发的一局部,仔细分析研究系统的需求 规格说明,对软件的需求获取是很有必要的
第十六页，共七十七页。
✓需求调查对象
对组织的高层管理者，进行组织管理目标或经营方 针等组织战略问题的调查
对中层的管理者，进行全部业务流的调查 对业务工作人员，进行详细业务信息的调查
✓市场调查 了解市场对待开发软件有什么样的要求；了解市场上 有无与待开发软件类似的系统
第十页，共七十七页。
需求(xūqiú)分析流程
第十一页，共七十七页。
软件需求(xūqiú)分析的原那么
1、需要能够表达和理解问题的信息域和功能域 信息域应包括：
软件工程中的软件需求分析方法(一)
软件工程中的软件需求分析方法一、引言随着科技的不断发展，软件已经成为现代社会不可或缺的一部分。
在软件开发过程中，软件需求分析是一个至关重要的环节。
本文将介绍软件工程中常用的软件需求分析方法，包括用户访谈、原型设计、用例建模和需求文档等。
二、用户访谈用户访谈是软件需求分析中最常见的方法之一。
开发团队与真实用户进行面对面的交流，了解他们对软件的期望和需求。
通过用户访谈，开发团队可以收集到真实且详尽的用户需求，避免因为假设而造成的错误决策。
同时，用户访谈还能够建立起良好的沟通渠道，增强开发团队和用户之间的信任。
三、原型设计原型设计是一种通过创建一个初步的、可交互的软件模型来验证用户需求的方法。
开发团队可以使用各种原型设计工具，如Axure、Sketch等，来快速制作出一个界面简单、功能基本但能够展示核心需求的原型。
通过与用户进行交互，开发团队可以收集到更多实际的用户反馈，从而不断改进软件的设计。
四、用例建模用例建模是一种将用户需求转化为具体功能的分析方法。
通过用例建模，开发团队可以明确软件系统中的各项功能，并将其视为一个个场景描述。
用例建模能够帮助开发团队识别出关键的用户任务以及系统与外部实体之间的交互关系，从而更好地满足用户的需求。
同时，用例建模还可以为软件测试提供指导，确保软件的功能完备且符合用户期望。
五、需求文档需求文档是软件需求分析中必不可少的一环。
它是一个详尽的、可浏览和可验证的需求规范，包含了用户需求、功能描述、性能要求、界面设计等方面的内容。
需求文档的编写需要遵循一定的规范，如使用统一的术语、清晰的排版和易于阅读的格式。
通过编写需求文档，开发团队可以将用户需求转化为具体而可执行的任务，有利于软件开发的进程控制和迭代优化。
六、结论软件需求分析是软件工程中不可或缺的一步。
本文简要介绍了软件工程中常用的软件需求分析方法，包括用户访谈、原型设计、用例建模和需求文档。
每一种方法都有其独特的优势和适用场景，开发团队可以根据具体情况选择并结合使用。
软件工程4 需求获取
软件工程4 需求获取在软件工程的领域中，需求获取是项目成功的关键起点。
它就像是建造一座大厦前的蓝图规划，只有清晰、准确地理解了用户的需求，才能打造出符合期望的软件产品。
需求获取，简单来说，就是收集、理解和记录软件系统需要实现的各种要求和期望的过程。
这可不是一个轻松的任务，它需要与各种各样的人员进行交流，包括用户、客户、业务分析师、开发团队等等。
而且，这些人员对于需求的理解和表达可能各不相同，这就给需求获取带来了很大的挑战。
想象一下，你要为一家电商公司开发一个新的购物平台。
首先，你得和公司的管理层交流，了解他们对于业务增长、用户体验提升的期望，以及对于成本和时间的限制。
然后，你要和市场部门沟通，搞清楚他们对于品牌推广、客户吸引和留存的策略。
接着，和客服团队聊聊，听听他们在处理用户问题时遇到的痛点和改进的建议。
还不能忘了和实际的用户交流，了解他们在购物过程中的喜好、不满和需求。
在这个过程中，有效的沟通技巧是至关重要的。
你要能够倾听，理解对方的观点，并且通过提问来澄清模糊的地方。
比如说，用户说希望购物流程更简单，那你就得追问具体是哪些步骤他们觉得复杂，是搜索商品、下单支付还是售后服务？需求获取的方法也是多种多样的。
常见的有问卷调查、用户访谈、观察用户行为、分析现有系统等等。
问卷调查可以大规模地收集用户的意见和需求，但要注意问题的设计要清晰、简洁，避免引导性的问题。
用户访谈则能够更深入地了解用户的想法和动机，但需要访谈者有良好的引导和沟通能力。
观察用户行为可以让你看到用户在实际操作中的问题和习惯，但可能需要耗费较多的时间和精力。
分析现有系统则可以发现当前系统的优点和不足，为新系统的设计提供参考。
以一个在线教育平台为例，为了获取需求，可以先对现有的类似平台进行分析，看看它们的功能模块、界面设计、用户评价等。
然后，可以组织教师和学生进行访谈，了解他们在教学和学习过程中的需求和困扰。
比如，教师可能希望有更方便的课件制作和管理工具，学生可能希望有更多的互动方式和个性化的学习路径。
软件工程课件第四章
2020/5/20
信息科学与技术学院
6
制定测试计划
确定对各模块和系统联调的测试方案。 在软件开发的早期阶段考虑测试问题，
能促使软件设计人员在设计时注意提高 软件的可测试性 。
2020/5/20
信息科学与技术学院
7
书写文档
1.系统说明：概要设计说明书 2.用户手册 3.测试计划 4.详细的实现计划 5.数据库设计结果
第一，有效的模块化（即具有独立的模块）的软件比较容 易开发出来。
第二，独立的模块比较容易测试和维护。 模块的独立程度的度量标准:
内聚:衡量一个模块内部各个元素彼此结合的紧密程度； 耦合:衡量不同模块彼此间互相依赖（连接）的紧密程度。
2020/5/20
信息科学与技术学院
19
模块独立 – 耦合
耦合是对一个软件结构内不同模块之间互联程度的度量。 耦合强弱取决于模块之间接口的复杂程度，调用模块的方式， 以及通过接口的数据。实际上，耦合是接口数据对模块独立 性的影响。
2020/5/20
信息科学与技术学院
14
采用模块化的依据
容易被理解。 使问题复杂度降低，容易被实现。
设函数C（x）定义问题x的复杂程度，函数E（x） 确定解决问题x需要的工作量（时间），对于两个问题 p1和p2，如果
C（p1）> C（p2） 则： E（p1）> E（p2） 规律： C（p1＋p2）> C(P1) + C(p2) 必有： E（p1＋p2）> E（p1）+ E（p2）
如果两个模块中的每一个都能独立地工作而不需要另一个 模块地存在，那么它们彼此完全独立，这意味着模块间无任 何连接，耦合程度最低。但一个软件系统中的模块之间是彼 此协同工作的，不可能所有模块间没有连结。
软件工程需求分析文档
引言概述：正文内容：一、需求获取1. 介绍用户需求调研的重要性及流程。
用户需求调研是收集和理解用户需求的关键过程，可以通过面对面的访谈、问卷调查等方法来获取用户需求。
2. 分析用户需求的优先级。
区分用户的主要需求和次要需求，并确定其对软件系统的重要性，以便开发团队能够合理地分配资源。
3. 需求验证和确认。
在需求获取的过程中，将用户需求与实际可行性进行比较，确保需求的准确性和可行性。
二、需求分析1. 分析用户需求的功能性需求。
功能性需求是指软件系统实现的基本功能，开发团队需要仔细分析每个功能需求，并明确其具体实现方式。
2. 分析用户需求的非功能性需求。
非功能性需求包括性能要求、可用性要求、安全要求等，开发团队需要根据具体需求设定标准和指标。
3. 确定用户需求的边界和限制条件。
确定软件系统的界面范围、数据输入输出要求、运行环境等限制条件，以确保软件开发的可行性。
4. 使用案例建模分析用户需求。
使用案例建模是一种将用户需求转化为可执行操作的分析方法，开发团队可以通过绘制用例图和时序图来分析用户需求。
5. 分析用户需求的变更和迭代。
在需求分析过程中，需求的变更是正常的现象，开发团队应该及时跟进变更，并进行相应的调整。
三、需求确认1. 确认用户需求的正确性和完整性。
开发团队通过与用户进行沟通和确认，确保所分析的用户需求正确无误，且没有遗漏。
2. 确定用户需求的优先级和可行性。
在用户需求的确认过程中，开发团队和用户需求方共同讨论需求的优先级和可行性，以合理安排软件开发任务。
四、需求追踪1. 需求追踪的目的和意义。
需求追踪是跟踪需求的变更和开发情况的过程，可以帮助开发团队更好地管理需求和追踪项目进度。
2. 使用需求跟踪矩阵。
需求跟踪矩阵是一种工具，可以将不同的需求与软件开发的迭代过程进行对应，帮助开发团队更好地管理和追踪需求。
3. 管理需求的变更。
在软件开发过程中，需求的变更是正常的现象，开发团队应该及时记录和管理需求的变更，以确保软件开发的顺利进行。
软件工程中的需求获取与分析方法及工具
制作人： 时间：2024年X月
目录
第1章 软件工程概述 第2章 需求获取方法 第3章 需求分析方法 第4章 需求分析工具 第5章 需求分析的挑战与解决方案
第6章 总结与展望
第1章 软件工程概述
● 01
软件工程定义
软件工程是一种系统化、规范化、可靠化、高效率 的软件开发方法。它涉及软件开发、软件维护和软 件项目管理等多个方面，是一种综合性的学科。
不断更新知识
参与实践项目
学习新的需求获取技术
将学到的知识应用到实际项目 中
总结经验教训，不断改进
尝试新的需求分析工具与技术 分享经验与他人交流
根据项目反馈不断优化需求 保持需求管理流程的持续改进
需求管理的重要性
需求管理是软件工程中的基石，正确理解需 求并采用适当的方法工具，对项目成功至关 重要。
需求跟踪
需求变更跟踪
记录需求变更的原因 更新需求文档 通知相关人员
完整性和一致性
确保需求管理的完整性 验证需求间的一致性 追踪需求变更历史
项目管理
控制需求变更的影响 评估变更的成本和风险 制定变更管理计划
需求分析方法总结
分类
功能性、非功能性、约束性
建模
使用UML建模工具
验证
与用户确认需求准确性
第四章 需求分析工具
描述对系统设计和实现的限制
需求建模
需求建模是使用UML等建模工具，绘制用例图、类 图等表示需求的过程。这些模型帮助开发人员更好 地理解和分析需求，提高开发效率。
需求验证
准确性确认
验证需求是否准确 地描述了用户需求
一致性确认
保证需求之间没有 冲突或不一致
软件工程的需求获取与分析方法
执行顺序图展示了系统中各个对象之间的交互和消息传递顺序
数据流图
数据流
数据流图中的数据流代表系统 内部的信息传递
加工
源与目的
存储
加工表示系统对数据流进行的 处理和操作
源与目的表示数据流的来源和 去向
存储表示系统中数据的持久化 存储
需求验证
需求验证是确认需求是否符合用户期望的重要过程。 通过需求验证可以及早发现和纠正需求不一致或不完 整的问题，确保软件开发过程中满足用户需求。
●07
第七章 总结与展望
软件工程需求获取与分析方法总 结
本章对软件工程的需求获取与分析方法进行了全面的 介绍，包括需求建模、需求管理、需求规格化和软件 测试等方面。在实际项目中，充分理解和应用这些方 法能够提高软件开发效率，降低错误率，确保项目顺 利完成。
软件工程需求获取与分析方法重点
01
02
需求分析的工具
数据流图
用图形方式表示数据的流向和处理过程
数据字典
记录系统中用到的数据元素及其定义
状态转换图
描述系统中各个状态及状态之间的转换关系
总结
需求获取与分析是软件工程中非常关键的环节，只有 充分理解和捕捉用户需求，才能保证软件系统的质量 和用户满意度。通过适当的方法和工具，将用户需求 具体化和形式化，有助于开发团队更好地把握需求， 提高软件开发的成功率。
确保系统在各种情况下都能 保持数据安全
检验系统在负载下的性能表 现
谢谢观看！
常见软件开发方法
瀑布模型
阶段划分明确 适用于稳定需求
敏捷开发
快速响应需求变化 迭代交付
螺旋模型
风险管理 适用于大型项目
原型模型
预览效果 需求不明确时使用
软件工程第4章需求获取
国防科技大学计算机学院
11
4.1.2 用例图
• UML的用例模型由一到多幅用例图构成，它们表示从软件系统的 外部使用者的角度看到的各项系统功能，并清晰地说明软件系统 的边界，即，用例图中的所有用例的集合构成目标软件系统应该 提供的功能，除此之外软件系统不再承诺其他功能。
• 用例图的节点有执行者和用例两种。用例图的边表示执行者与用 例之间、两个用例之间、两个执行者之间的关系。下面结合图 4.1所示的用例图阐述UML用例图的概念、图元、使用方法及布局 规则。
• 需求获取是需求工程中后续活动（分析、规范化等）的基础，需求 工程又是后续软件开发活动的基础。
• 需求获取对于软件项目的成败具有决定性影响。 • 需求获取活动的主要完成者是来自软件开发方的需求工程师。 • 其他参与者包括来自委托方或投资方的客户，来自使用方的用户，
以及项目软件经理和质量保证工程师（见第十六章）。
第四章 需求获取 4.1 软件需求的初始表示 4.2 需求获取的过程模型 4.3 定义软件问题 4.4 创建框架用例 4.5 精化用例 4.6 评审用例模型
2020/8/20
国防科技大学计算机学院
1
第四章 需求获取
• 需求获取的目标是，完整地收集、整理利益相关方对目标软件系统 的需求，并以其容易理解的业务语言阐述这些需求，形成文档。
2020/8/20
国防科技大学计算机学院
6
用例
• 执行者是指外部用户或外部实体在系统的交互过 程中扮演的角色，它与软件系统交换信息并使用 软件系统的功能。 • 如果多个用户在使用目标软件系统时扮演同一角 色，这些用户用单一执行者表示。 • 如果一个用户扮演多种角色，则需要用多个执行 者来表示同一用户。 • 执行者可以是一类用户，也可以是其他软件系统 或物理设备。
软件工程——4.需求分析基础
软件工程——4.需求分析基础软件工程——4.需求分析基础1. 引言需求分析是软件工程中非常重要的一个阶段，它是确定软件系统应该做什么以及用户的期望和需求的过程。
该文档将介绍需求分析的基础知识和方法。
2. 需求分析的定义和目的需求分析是软件开发过程中的第一步，其主要目标是确定软件系统的功能和约束。
通过需求分析，可以明确软件系统的用户需求、业务需求和技术需求，为后续的设计、开发和工作提供基础。
需求分析的主要内容包括以下几个方面：- 用户需求的获取：通过与用户沟通、观察和调研等方式，获取用户对软件系统的期望和需求。
- 需求的分析和整理：对收集到的需求进行分析和整理，理清具体的功能和约束。
- 需求的验证和确认：与用户反复沟通，确保需求的准确和完整。
3. 需求分析的基本原则在进行需求分析时，需要遵循以下基本原则：3.1 明确需求的来源需求的来源可以是用户的需求、企业的需求、法律法规等。
需要明确需求的来源，以便更好地理解需求并确保满足各方的期望。
3.2 分析需求的重要性和优先级不同的需求具有不同的重要性和优先级。
需求分析人员需要根据实际情况，确定哪些需求是最重要的，哪些是次要的，以便在后续的开发过程中进行合理的资源分配。
3.3 避免冗余和矛盾的需求在需求分析过程中，可能会出现冗余和矛盾的需求。
需求分析人员需要及时发现和排除这些问题，确保需求的一致性和合理性。
3.4 考虑可行性和可实现性在进行需求分析时，需要考虑所提出的需求是否可行和可实现。
如果某个需求无法满足技术或资源上的限制，需要及时与用户沟通，并寻求解决方案。
4. 需求分析的常用方法需求分析的方法有很多种，下面介绍几种常用的方法：4.1 用户访谈用户访谈是获取用户需求的主要方法之一。
需求分析人员可以通过与用户面对面的交流，了解用户对软件系统的期望和需求。
4.2 原型设计原型设计是一种以图形表示的方法，用于展示软件系统的界面和功能。
通过原型设计，用户可以更直观地看到软件系统的样貌，从而更好地理解和确认需求。
软件工程(第3版)齐治昌—第4章需求获取
4.1 软件需求的初始表示
➢ 本节介绍软件需求的用例和用例的初始表示。
➢ 在需求获取过程中用到的UML图形机制主要是用 例图、类图与活动图。
2020/4/30
4
4.1.1 用例
（一）用例的概念
➢ 从外部用户的视角看，一个用例（use case）是 执行者(actor)与目标软件系统之间一次典型的交 互作用，其效果就是执行者在软件系统的帮助下 完成了某项业务功能，或达成了某项业务目标。
2020/4/30
8
用例
（二）用例与软件需求之间的关系
➢ 根据用例的定义易知，用例是功能性软件 需求的主体部分。
在用例驱动的需求工程中，用例描述将占据需 求获取结果文档的大部分篇幅。
全局性的业务规则、大部分非功能性的软件需 求并不适于在用例中描述。
某些仅作用于单个或少数用例的业务规则可以 直接在用例描述中出现，见例4.5。
➢ 在实际应用中，有些用例不由任何物理实体触发， 而是由时间或外部事件来触发，此时可设置定时 器（Timer）或事件发送者作为执行者。
➢ 如，如果要求在每学期第一周的星期日自动触发 “汇总选课计划”用例，那么该用例的执行者应 为定时器，见图4.1。
2020/4/30
7
用例
➢ 相对独立性和完整性是用例必备的两项特征，即， 用例表示执行者为达成一项相对独立、完整的业务 目标而与目标软件系统协同完成的功能。
2020/4/30
11
Registrar Student
设定课程信息 制订课表
制订选课计划 <<extend>>
制订选课计划[考虑学生数量限制]
ExcellentStudent
Teacher Timer
软件需求提取与分析
约束
约束不是行为，是设计或项目的限制条件，强调其限制 性，新系统的开发无法回避这些事实或因素。约束主要包括：
系统开发的资源约束：如网络环境、操作系统、数据库管 理系统、开发工具、硬件等。新系统的开发必须考虑这些资 源的有效利用和限制。
接口约束：本系统关联的系统是哪些，新系统可能接受其 它系统提供的数据作为输入，其输出数据作为其它系统的输 入。
场景可分为主要场景和次要场景。一个用例只有一个主要 场景，但可以包含多个次要场景。每个场景表示参与者达到 其目标的一个情节。在主要场景中，如果与某一步所希望的 事件不同，就会引出一个软次件需要求提场取景与分。析 。
需求建模方法—识别主要参与者
系统主要参与者就是系统的业务用户。在这里，我们反 复强调“业务用户”，因为开发一个软件系统的目的就是为他 们的业务工作服务的，这是系统的价值所在。
只有对用例表现出的情节进行真实、完整、准确地描述， 才能捕捉到对系统需求有价值的东西。
软件需求提取与分析
需求建模—用例的粒度
指导原则1：在进行需求获取时，应专注于“基本业务过程” （EBP）级别的用例。
基本业务过程：由一个人在某个时间某个地点执行的一项 任务，这个任务是对某一个业务事件的反应，而且可以增加 可度量的业务价值，并且能够保持数据状态的一致。
软件需求提取与分析
需求建模—用例
用例是参与者想要系统做的事情。具体表现为用户如何使 用系统来达到其目标的一组情节。
例如在超市，“处理销售”的用例描述为：一个顾客携带欲 采购的商品到达收费口。收银员使用系统输入商品信息，系 统给出商品的清单和累加值。顾客交款。收银员输入支付信 息，系统对付款信息进行计算，更新库存信息，并给出余额 信息；系统打印购物清单。顾客得到收据，然后携带商品离 开。
软件工程中的需求获取与分析方法
软件工程中的需求获取与分析方法在软件工程领域，需求获取与分析是项目成功的关键基石。
它就像是建筑工程中的蓝图设计阶段，决定了后续开发工作的方向和质量。
如果在这个阶段出现偏差或遗漏，可能会导致项目的延误、成本的增加，甚至最终无法满足用户的期望。
需求获取，简单来说，就是从各种渠道收集关于软件系统应该做什么的信息。
这个过程并不像表面看起来那么简单，它需要与众多的利益相关者进行有效的沟通和交流。
这些利益相关者可能包括最终用户、客户、业务经理、技术人员等等。
他们对于软件系统的期望和需求各不相同，而且往往是以一种非结构化、模糊的方式表达出来的。
比如说，最终用户可能会说“我希望这个软件能让我更轻松地完成日常工作”，但这并没有具体说明什么样的操作会让他们感到轻松，以及他们日常工作的具体流程和痛点是什么。
这就需要需求获取人员通过进一步的提问、观察和调研，来挖掘出更详细、更明确的需求。
在与利益相关者沟通时，有效的倾听是至关重要的。
需求获取人员不能仅仅是被动地接受信息，而要积极地与对方互动，理解他们的语境和意图。
同时，还要善于运用各种沟通技巧，比如开放性问题、引导性问题、重复和确认等，以确保获取到的信息是准确和完整的。
除了与利益相关者直接交流，还可以通过查阅相关文档、观察现有系统的运行情况、分析市场趋势等方式来获取需求。
比如，如果要开发一个与财务相关的软件，就可以查阅财务法规、行业报告等资料，了解财务管理的最新要求和趋势。
需求分析则是对获取到的需求进行深入的理解、整理和细化。
它的目的是将那些模糊、不明确的需求转化为清晰、具体、可度量的需求规格说明，为后续的设计、开发和测试提供准确的依据。
在进行需求分析时，首先要对需求进行分类和优先级排序。
有些需求是核心的、必须满足的，而有些则是次要的、可以在后续版本中实现的。
通过优先级排序，可以合理分配资源，确保在有限的时间和预算内满足最重要的需求。
然后，要对需求进行建模和文档化。
常用的建模方法包括用例图、活动图、数据流图等。
软件需求-第4课-软件需求获取概述(一)(第1版)
主要讨论问题
需求定义任务概述 问题分析的方法 需求定义的产物和要素 定义需求范围
第4章 软件需求获取概述
1 需求定义 需求定义任务概述 软件的生存周期
问题定义 计划时期 可行性研究 需求分析 开发时期 软件设计 编 测 运行时期 维 码 试 护 产品:战略规划报告
第4章 软件需求获取概述
1 需求定义 需求定义任务概述 需求定义任务的地位 严格说来，需求定义活动不属于需求工程范畴。它实际上是 立项管理阶段的产物，在一些软件工程的书籍中需求定义也称为 总体问题陈述或者总体目标或者战略规划（第3课实例中），通常 也可以称为业务需求（第2课） 但需求定义阶段的制品对于需求获取、分析和建模活动具有 重要的指导意义，产生直接的影响。如果该阶段的工作做得不好， 将会对系统开发带来严重的后果。目标和范围有问题，开发必然会 出现重大的修改。
第4章 软件需求获取概述
1 需求定义 需求定义任务概述 需求定义的理念 如果要对需求定义工作的着手点进行概括的话，就是6个字： 问题、机会、约束。对于信息系统而言，其构建要么是解决问题 的，要么是把握机会、创造机会的，但必须满足一定的约束条件。 由此首先应该明确要解决的问题是什么，或者要把握什么机会， 同时要明确解决问题或者把握机会都有什么约束。
第4章 软件需求获取概述
1 需求定义 问题分析的方法 (1) 在问题定义上达成共识 问题定义的经验一：需求定义阶段要善于将未知问题转换为 已知问题 将解决方案转换到已经掌握的方法或者手段上。在和用户沟通 时，应该注意将用户的需求转换成自己已有的产品或者已有的解决 方案上，而不是简单地重新开发。
第4章 软件需求获取概述
能指明解决的方向 P3. 决策者：生产的废品过多。
第4章 软件需求获取概述
软件工程：第四章软件需求与获取分析一
需求分析的过程 (6)文档需求 需哪些文档？ 文档针对哪些读者？
需求分析的过程 (7) 数据需求
输入、输出数据的格式？
接收、发送数据的频率？
数据的准确性和精度？
数据流量？ 数据需保持的时间？
需求分析的过程
(8) 资源需求
软件运行时所需的数据、软件。 内存空间等资源。 软件开发、维护所需的人力、支撑软件、开
目标系统的具体物理模型是由它的逻辑模 型经实例化，即具体到某个业务领域而得 到的
软件需求分析的目标和任务 软件需求分析的过程 软件需求分析的原则 软件需求获取技术 结构化分析方法 原型化方法 软件需求分析的工具 软件需求文档 软件需求评审
需求分析的过程
软件需求分析过程图
(11) 质量保证
系统的可靠性要求？ 系统必须监测和隔离错误吗？ 出错后，重启系统允许的时间？ 系统变化如何反映到设计中？ 维护是否包括对系统的改进？ 系统的可移植性？
需求分析的过程
问题识别的另一项工作是建立分析所需要的通信 途径，以保证能顺利地对问题进行分析。
需求分析的过程
(1) 通过对现实环境的调查，获得当前系统的物理模型
购
书
购
领
申
书
发
书
学 请 教务科 单 会计室 票 出纳员 单 教材科 书 学
生
107
206
206
303
生
张
王
李
赵
学生购买教材的物理模型
软件需求分析的目标和任务
(2) 去掉具体模型中非本质因素，抽象出当前系统的逻辑模型
购
书
购
领
申
书
发
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件需求的获取
获取用户需求的主要方法是调查研究。 调查研究的主要方法有: 调查研究的主要方法有 访问面谈 收集查问资料 深入现场,跟班作业
软件需求的获取
如何编写调查研究表? 如何编写调查研究表?
软件需求的获取
某出版社系统调查表
编号
1 2 3 4 5
提出问题 您在哪个部门工作？ 您在哪个部门工作？ 出版业务流程是什么？ 出版业务流程是什么？ 您每日都处理那些文件、数据、报表？ 您每日都处理那些文件、数据、报表？ 工作中手工处理特别麻烦的事情是什么？ 工作中手工处理特别麻烦的事情是什么？ 工作中手工处理什么问题解决不了？ 工作中手工处理什么问题解决不了？影响效率的问题 有哪些？ 有哪些？ 您认为提高工作效率，节省工作时间， 您认为提高工作效率，节省工作时间，减轻工作强度 可采取哪些办法？ 可采取哪些办法？
需求分析的过程 常用的分析方法
面向数据流的结构化分析方法 (SA) 面向数据结构的Jackson 面向数据结构的Jackson方法 (JSD) Jackson方法 面向对象的分析方法 (OOA) 等
需求分析的过程
(3) 编制需求分析阶段的文档 软件需求说明书 数据要求说明书 初步的用户手册 修改、完善与确定软件开发实施计划 修改、
需求分析的过程 (2) 性能需求
软件开发的技术性指标 例如： 例如： 存储容量限制 执行速度、 执行速度、相应时间 吞吐量
需求分析的过程 (3) 环境需求
硬件设备：机型、外设、接口、 硬件设备：机型、外设、接口、
地点、分布、温度、 地点、分布、温度、 湿度、磁场干扰等 湿度、
软件： 软件：
操作系统 网络 数据库
软件需求分析的目标和任务
软件需求分析的目标是深入描述软件的功能 和性能， 和性能，确定软件设计的约束和软件同其它系统 元素的接口细节，定义软件的其它有效性需求。 元素的接口细节，定义软件的其它有效性需求。
软件需求分析的目标和任务
软件需求的几点说明 需求分析研究的对象是软件项目的用户要求 准确地表达被接受的用户要求 确定被开发软件系统的元素
软件需求分析的目标和任务 软件需求分析的过程 软件需求分析的原则 软件需求获取技术 结构化分析方法 原型化方法 软件需求分析的图形工具 软件需求文档 软件需求评审
软件需求分析的目标和任务
课前讨论 1.用户在软件需求分析过程中重要吗? 1.用户在软件需求分析过程中重要吗?请 用户在软件需求分析过程中重要吗 说明理由 2.软件需求分析是软件工程过程中交换意 2.软件需求分析是软件工程过程中交换意 见最频繁的步骤, 见最频繁的步骤,为什么交换意见的途径 会经常阻塞？ 会经常阻塞？
需求分析的过程
问题识别的另一项工作是建立分析所需要的通信 途径，以保证能顺利地对问题进行分析。 途径，以保证能顺利地对问题进行分析。
需求分析的过程
(2) 分析与综合 从信息流和信息结构出发，逐步细化所有 从信息流和信息结构出发， 的软件功能，找出系统各元素之间的联系、 的软件功能，找出系统各元素之间的联系、 接口特性和设计上的约束， 接口特性和设计上的约束，分析它们是否满 足功能要求，是否合理。最终综合成系统的 足功能要求，是否合理。 解决方案，给出目标系统的详细逻辑模型. 解决方案，给出目标系统的详细逻辑模型.
需求分析的过程
(4) 需求分析评审
作为需求分析阶段工作的复查手段， 作为需求分析阶段工作的复查手段 ， 应该对功 能的正确性、文档的一致性、完备性、 能的正确性 、 文档的一致性 、 完备性 、 准确性和 清晰性，以及其它需求给予评价。 清晰性，以及其它需求给予评价。 为保证软件需求定义的质量， 为保证软件需求定义的质量，评审应以专门指定 的人员负责，并按规程严格进行。 的人员负责 ， 并按规程严格进行 。 评审结束应有 评审负责人的结论意见及签字。除分析员之外， 评审负责人的结论意见及签字 。 除分析员之外 ， 用户／需求者，开发部门的管理者，软件设计、 用户 ／ 需求者 ， 开发部门的管理者 ， 软件设计 、 实现、测试的人员都应当参加评审工作。 实现、测试的人员都应当参加评审工作。
需求分析的过程
(8) 资源需求
软件运行时所需的数据、软件。 软件运行时所需的数据、软件。 内存空间等资源。 内存空间等资源。 软件开发、维护所需的人力、支撑软件、开 软件开发、维护所需的人力、支撑软件、 发设备等。 发设备等。
需求分析的过程 (9) 安全保密要求
需对访问系统或系统信息加以控制吗？ 需对访问系统或系统信息加以控制吗？ 如何隔离用户之间的数据？ 如何隔离用户之间的数据？ 用户程序如何与其它程序和操作系统隔离？ 用户程序如何与其它程序和操作系统隔离？ 系统备份要求？ 系统备份要求？
需求分析的过程
1.你认为一个优秀系统分析员要有哪些素质? 2.为什么系统分析员工资比程序员高?
软件需求分析的目标和任务 软件需求分析的过程 软件需求分析的原则 软件需求获取技术 结构化分析方法 原型化方法 软件需求分析的工具 软件需求文档 软件需求评审
软件需求分析的原则
一.需要能够表达和理解问题的数据域和功能域 需要能够表达和理解问题的数据域 数据域和 数据域包括数据流,数据内容和数据结构. 数据域包括数据流,数据内容和数据结构.
购书单 审查并 学
生 开发票
发票
开领 书单
领书单
学 生
计算机售书系统的逻辑模型
软件需求分析的目标和任务
通常软件开发项目是要实现目标系统的物 理模型 目标系统的具体物理模型是由它的逻辑模 型经实例化，即具体到某个业务领域而得 型经实例化， 到的
软件需求分析的目标和任务 软件需求分析的过程 软件需求分析的原则 软件需求获取技术 结构化分析方法 原型化方法 软件需求分析的工具 软件需求文档 软件需求评审
软件需求分析的目标和任务
为什么需求分析比较困难? 为什么需求分析比较困难?
客户说不清楚需求 需求自身不断变动 分析人员或客户理解有误
软件需求分析的目标和任务
理解有误引出的二则笑话
1.有个外星人间谍潜伏到地球刺探情报， 1.有个外星人间谍潜伏到地球刺探情报，它给上司写了 有个外星人间谍潜伏到地球刺探情报 一份报告： 主宰地球的是车。它们喝汽油， 一份报告：“主宰地球的是车。它们喝汽油，靠四个轮 子滚动前进。嗓门极大，在夜里双眼能射出强光。 子滚动前进。嗓门极大，在夜里双眼能射出强光。…… 有趣的是，车里住着一种叫作‘ 的寄生虫， 有趣的是，车里住着一种叫作‘人’的寄生虫，这些寄 生虫完全控制了车。 生虫完全控制了车。” 2.有一个软件人员滔滔不绝地向客户讲解在“ 2.有一个软件人员滔滔不绝地向客户讲解在“信息高速 有一个软件人员滔滔不绝地向客户讲解在 公路上做广告”的种种好处，客户听得津津有味。最后， 公路上做广告”的种种好处，客户听得津津有味。最后， 心动的客户对软件人员说： 好得很， 心动的客户对软件人员说：“好得很，就让我们马上行 动起来吧。 动起来吧。请您决定广告牌的尺寸和放在哪条高速公路 我立即派人去做。 上，我立即派人去做。”
软件需求分析的目标和任务
软件需求分析的目标和任务
逻辑模型 现 行 系 统 目 标 系 统 描述重要的业务 功能， 功能，无论系统 是如何实施的。 是如何实施的。 描述新系统的主要 业务功能和用户新 的需求， 的需求，无论系统 应如何实施。 应如何实施。 物理模型
描述现实系统是如何 在物理上实现的。 在物理上实现的。 描述新系统是如何实 施的（包括技术）。 施的（包括技术）。
需求包括的内容(类型): 需求包括的内容(类型):
(1) 功能 (2) 性能 (3) 环境 (4) 界面 (5) 用户或人的因素 (6) 文档 (7) 数据 (8) 资源 (9) 安全保密 (10)软件成本消耗与开发进度 (10)软件成本消耗与开发进度 (11)质量保证 (11)质量保证
需求分析的过程 (1)功能需求 (1)功能需求 系统做什么？ 系统做什么？ 系统何时做什么？ 系统何时做什么？ 系统何时及如何修改或升级？ 系统何时及如何修改或升级？
需求分析的过程
软件需求分析过程图
编制需求 分析文档
问题识别
分析与综合
需求评审
需求分析的过程
(1) 问题识别 从系统的角度来理解软件并评审软件范围是 否恰当 确定对目标系统的综合要求，即软件的需求 确定对目标系统的综合要求， 提出这些需求实现条件， 提出这些需求实现条件，以及需求应达到的 标准
需求分析的过程
输入数据 转换1 中间数据 数据 存储 附加数据 转换2 结果数据
软件需求分析的原则
二.要能以层次化的方式对问题进行分解和不断细化
软件需求分析的原则
三.要给出系统的逻辑视图和物理视图 要给出系统的逻辑视图 逻辑视图和 逻辑视图给出软件要达到的功能和处理数据之 间的关系 物理视图给处理功能和数据结构的实际表示形 式
软件需求分析的目标和任务 需求分析过程示意图
(1) 通过对现实环境的调查，获得当前系统的物理模型 通过对现实环境的调查， 购 书 购 领 发 申 书 书 书 请 教务科 单 会计室 票 出纳员 单 学 教材科 107 206 206 303 生 王 张 李 赵
学 生
学生购买教材的物理模型
软件需求分析的目标和任务
需求分析的过程
(10) 软件成本消耗与开发进度需求 开发有规定的时间表吗？ 开发有规定的时间表吗？ 软硬件投资有无限制？ 软硬件投资有无限制？
需求分析的过程
(11) 质量保证
系统的可靠性要求？ 系统的可靠性要求？ 系统必须监测和隔离错误吗？ 系统必须监测和隔离错误吗？ 出错后，重启系统允许的时间？ 出错后，重启系统允许的时间？ 系统变化如何反映到设计中？ 系统变化如何反映到设计中？ 维护是否包括对系统的改进？ 维护是否包括对系统的改进？ 系统的可移植性？ 系统的可移植性？