第11章 面向问题域的需求分析方法
需求分析方法
需求分析方法需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。
（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。
需求分析阶段结束后，要求得到：1.SRS文档(System Requirement Specification); 2.DRM 文档；3.Acceptance Plan.从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
狭义上理解：需求分析指需求的分析、定义过程。
一、为什么要需求分析需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了。
需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位.大家一定要对需求分析具有足够的重视.在一个大型软件系统的开发中,他的作用要远远大于程序设计.二、需求分析的任务简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求.三、需求分析的过程需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审。
问题识别就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标.分析与综合逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型).制订规格说明书即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交.评审对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。
简述需求分析的方法
简述需求分析的方法需求分析是项目开发中的重要环节，它的目的是准确定义和理解用户的需求，为后续的设计和开发提供指导。
在需求分析过程中，选择适合的方法可以提高效率并减少后期修改的风险。
本文将简述几种常用的需求分析方法。
一、访谈法访谈法是需求分析的常用方法之一。
通过与用户进行面对面的交流，收集和理解用户的需求。
在访谈过程中，要注重细致入微的询问，尽可能获取到足够的信息。
访谈的对象可以包括项目的发起人、使用人员和相关专家等。
通过访谈，可以直接获得用户的意见和建议，充分了解用户对系统功能和性能的期望。
二、问卷调查法问卷调查法可以帮助需求分析人员系统地收集用户的需求信息。
在设计问卷时，需要明确问题的目标和范围，合理选择问题的类型和选项。
通过对大量用户的调查，可以获取到更广泛的需求信息。
问卷调查还可以通过统计分析，得出用户需求的优先级和权重，为后续的设计和开发提供参考。
三、用户观察法用户观察法是通过观察用户在实际使用环境中的行为和操作来获取需求信息。
通过亲临现场观察，可以发现用户的真实需求和实际问题。
观察的重点可以包括用户的工作流程、操作习惯、痛点和不满意之处等。
通过用户观察，可以更准确地了解用户的需求，从而设计出更符合实际情况的系统功能。
四、原型演示法原型演示法是一种通过制作原型来验证和确认需求的方法。
通过制作初步的系统原型，可以让用户和开发人员更加直观地了解系统的功能和交互方式。
在原型演示中，可以邀请用户参与测试和反馈，及时发现和修正问题。
通过迭代和改进原型，可以逐步明确和完善用户的需求。
五、核查文档法核查文档法是通过分析和核对相关文档来获取需求信息。
这些文档可以包括需求规格说明书、用户手册、使用案例等。
通过仔细研读文档，可以发现其中隐含的需求和潜在问题。
核查文档时，需求分析人员应该注重细节，确保全面准确地理解和理解需求。
六、焦点小组讨论法焦点小组讨论法是指将一群相关用户或专家组织起来进行讨论和交流的方法。
软件工程课本讲解面向对象的OMT方法
化旳动态模型 + 细化旳功能模型。
16
第11章 面向对象的OMT方法
对象模型化技术OMT 对象模型化技术把分析时搜集旳信息构造在三类
模型中，即对象模型、功能模型和动态模型。
这个模型化旳过程是一种迭代过程。
17
第11章 面向对象的OMT方法
图11.4 三元关联 29
第11章 面向对象的OMT方法
角色为关联旳端点，阐明类在关联中旳作用和角 色。不同类旳关联角色可有可无，同类旳关联角色不 能省。角色旳表达如图11.5所示。
教师
讲授
课程
主讲
内容
图11.5 关联旳角色旳表达
30
第11章 面向对象的OMT方法
2) 受限关联
受限关联由两个类及一种限定词构成，限定词是 一种特定旳属性，用来有效地降低关联旳重数，限定 词在关联旳终端对象集中阐明。
技术之上旳，OMT措施旳基础是开发系统旳3个模型，再 细化这3种模型，并优化以构成设计。对象模型由系统中 旳对象及其关系构成，动态模型描述系统中对象对事件旳响应及对 象间旳相互作用，功能模型则拟定对象值上旳多种变换及变换上旳
约束。
6
第11章 面向对象的OMT方法
11.1.2 系统分析
分析旳目旳是拟定一种系统“干什么”旳模型，该模型经过 使用对象、关联、动态控制流和功能变换等来描述。分析过程是 一种不断获取需求及不断与顾客磋商旳过程。
8
第11章 面向对象的OMT方法
3. 构造动态模型
构造动态模型旳环节如下： (1) 准备经典交互序列旳脚本。 (2) 拟定对象间旳事件并为各脚本安排事件跟踪。 (3) 准备系统旳事件流图。 (4) 开发具有主要动态行为旳各个类旳状态图。 (5) 检验状态图中共享事件旳一致性和完整性。 最终得到：动态模型 = 状态图 + 全局事件流图。
软件需求分析面向问题域的需求分析方法-文档资料
10.6 问题框架实例间的关系及其组合
问题框架实例的组合 主要考虑在组合各个独立的问题框架实例 时，如何使不同的问题框架实例在整体上保持 协调，从而使它们能与原来的整个问题及其问 题域保持一致。
特点
将关注的重点定位在问题及其相关的问题 域上，通过对问题及其问题域进行合理的分类， 为分析人员提供解决具体问题的相关指南。同 时从问题域的角度出发，使用户能参与整个需 求过程，有利于更直观和真实地反映问题域的 信息和用户的需求。
15
10.5 PDOA方法的分析步骤
1. 2. 3.
步骤
搜集需求信息，界定和描述问题及问题域； 划分问题域并开发相关问题框架； 根据问题框架的类型进一步描述问题域的相关特 性。
3
10.1 问题域
需求分析文档、规格说明文档和程序之间的关 系
需 求 分 析 文 档
需 求 规 格 说 明 文 档
程
序
问 题 域
接口
机 器 域
4
10.2 问题域的划分
对于复杂问题的分析，一般的做法是采用 “分而治之”的策略。人们一般采用层次式 功能分解的方法。
1. 2.
3.
确定系统所需的各项功能； 若某些（或个）功能对应于一个足够小的具体实 现单元，则由该实现单元直接实现这些（或个） 功能； 否则，把功能分解为一系列子功能，并重复步骤2 和3，直到所有子功能可分别对应一个足够小的具 体实现单元。
21
10.6 问题框架实例间的关系及其组合
交互方面，两个问题框架实例相关本质上 是指它们的机器与机器之间存在由并行的划分 所引发的并发关系，这类似于两个并发进程间 的关系。 形式上两个问题框架实例间的关系可分为 三种类型：无关、具有公共的域、一个问题框 架实例的需求是另一个问题框架实例中的域。
简述需求分析的方法
简述需求分析的方法需求分析是软件开发过程中至关重要的一步。
它涉及对需求进行收集、分析和定义，以确保产品能够满足用户的期望和需求。
本文将简要介绍一些常用的需求分析方法，以帮助开发人员更好地理解和应用这些方法。
一、用户访谈用户访谈是需求分析中最常见的方法之一。
通过与用户直接交流，开发人员可以深入了解用户的需求和期望。
访谈可以采用面对面的方式，也可以通过电话或在线方式进行。
通过询问用户的问题，并仔细聆听他们的回答，开发人员可以获取关键的需求信息，并了解用户的痛点和需求的优先级。
二、文档分析在需求分析过程中，开发人员可以对现有的文档进行分析，以获取对系统需求有关的信息。
这些文档可以包括用户手册、操作手册、业务规范等。
通过仔细阅读和分析这些文档，开发人员可以较全面地了解用户的需求，以及系统所需具备的功能和性能要求。
三、场景模拟场景模拟是一种通过设定特定场景并让用户参与其中的方法。
通过模拟真实的使用场景，开发人员可以观察用户在特定情况下的行为和反应，并从中获取用户需求的洞察。
例如，可以设置实验室环境，让用户在特定的操作流程下测试软件，并倾听他们的反馈。
通过这种方法，开发人员可以更加准确地了解用户的需求和期望。
四、原型开发原型开发是通过制作一个简化版的产品原型，以获取用户反馈和需求的方法。
开发人员可以通过软件工具或手工制作一个简单的界面原型，以模拟待开发产品的功能和交互流程。
然后，开发人员可以邀请用户测试原型并提供反馈意见。
通过这种方法，开发人员可以迅速获取用户的需求，以便在后续的开发过程中进行相应的调整和优化。
五、焦点小组讨论焦点小组讨论是一种集中用户参与的需求分析方法。
开发人员可以组织一组来自用户群体的代表，共同参与讨论产品需求和期望。
通过集思广益的方式，开发人员可以获取来自不同用户的不同意见和建议，并最终形成一个更加全面和准确的需求规格。
六、需求优先级排序在需求分析过程中，开发人员常常需要面对多个需求，并对其进行优先级排序。
需求分析的方法有哪些
需求分析的方法有哪些需求分析是软件开发过程中至关重要的一步，目的是明确开发的目标和用户需求，从而为软件设计、开发和测试提供指导。
需求分析的方法可以分为以下几种：一、观察法（Observation Method）：通过观察用户现有的工作环境和过程，了解用户的实际需求。
可以通过直接观察、访谈、问卷调查等方式获取用户需求，发现用户需求与实际操作之间的差距。
二、访谈法（Interview Method）：与用户进行面对面的访谈，通过提问和交流，深入了解用户的需求和期望。
可以通过个别访谈、小组访谈、专家访谈等方式进行。
三、问卷调查法（Questionnaire Method）：通过设计问卷，向用户、管理人员、领导等相关人员发送，收集用户的需求和意见。
问卷调查可以同时收集大量用户的意见和需求，并进行统计分析。
四、头脑风暴法（Brainstorming）：邀请开发团队成员和用户一起进行头脑风暴，发散思维，集中讨论潜在的需求和解决方案。
可以通过自由发挥、集体讨论、循环补充等方式，激发创新想法和发现新的需求。
五、场景分析法（Scenario Analysis）：通过描述用户在特定场景下的操作和需求，更好地理解用户的使用环境和需求背景。
可以通过需求故事板、情景模拟、用户故事等方式，描述用户和系统之间的交互过程。
六、原型法（Prototype Method）：通过制作简化的原型，向用户展示系统的功能和界面。
用户可以通过实际操作和体验，更准确地表达自己的需求和期望。
可以通过低保真原型、高保真原型、交互式原型等方式制作。
七、模型法（Modeling Method）：通过建立数学模型、数据模型、过程模型等形式，对用户需求进行分析和建模。
可以通过数据流图、用例图、活动图、领域模型等方式，对需求进行形式化描述和分析。
八、软件工程方法（Software Engineering Method）：包括系统开发生命周期中的各种管理和技术方法，如需求管理、变更管理、需求跟踪、质量保证等。
第11章 面向问题域的需求分析方法汇总
2019/3/6
21
11.6 问题框架实例间的关系及其组合
交互方面，两个问题框架实例相关本质上 是指它们的机器与机器之间存在由并行的划分 所引发的并发关系，这类似于两个并发进程间 的关系。 形式上两个问题框架实例间的关系可分为 三种类型：无关、具有公共的域、一个问题框 架实例的需求是另一个问题框架实例中的域。
2019/3/6
3
11.1 问题域
需求分析文档、规格说明文档和程序之间的关 系
需 求 分 析 文 档
需 求 规 格 说 明 文 档
程
序
问 题 域
接
口
机 器 域
2019/3/6
4
11.2 问题域的划分
对于复杂问题的分析，一般的做法是采用 “分而治之”的策略。人们一般采用层次式 功能分解的方法。
1. 2.
需求式行为问题框架图
带连接域的需求式行为问题框架图
2019/3/6 9
11.4 问题框架的类型
命令式行为问题框架 思想：存在客观世界的某个部分，其行为 要依据操作者发出的命令来控制。问题是要建 立一个机器，该机器接受操作者的命令并施加 相应控制。
命令式行为问题框架图
2019/3/6 10
11.4 问题框架的类型
特点
将关注的重点定位在问题及其相关的问题 域上，通过对问题及其问题域进行合理的分类， 为分析人员提供解决具体问题的相关指南。同 时从问题域的角度出发，使用户能参与整个需 求过程，有利于更直观和真实地反映问题域的 信息和用户的需求。
2019/3/6
15
11.5 PDOA方法的分析步骤
1. 2. 3.
第 11 章 面向问题域的需求 分析方法
需求分析方法
需求分析方法
首先，我们可以采用访谈法来进行需求分析。
访谈法是最直接、最常用的需求获取方法之一。
通过与用户、业务人员或相关专家进行面对面的交流，可以深入了解他们的需求和期望。
在访谈过程中，我们可以通过提问、观察和记录来获取相关信息，从而全面了解用户的需求。
其次，调查法也是一种常用的需求分析方法。
通过设计问卷调查或在线调查，我们可以收集到大量用户的意见和建议。
调查法可以帮助我们快速了解用户的需求和偏好，为产品设计提供重要参考。
另外，原型法也是一种有效的需求分析方法。
通过制作产品原型，我们可以让用户直观地感受到产品的功能和界面，从而及时获取用户的反馈意见。
原型法可以帮助我们快速验证需求，减少后期修改的成本。
此外，文档分析法也是一种常用的需求分析方法。
通过研究相关的文档资料，我们可以了解到产品的历史、现状和未来发展方向，为需求分析提供重要依据。
最后，用户故事法也是一种常用的需求分析方法。
通过编写用户故事，我们可以清晰地描述用户的需求和使用场景，为产品设计提供具体的参考依据。
用户故事法可以帮助我们更好地理解用户需求，提高产品的用户体验。
总的来说，需求分析是软件开发过程中至关重要的一环。
采用合适的需求分析方法可以帮助我们全面、准确地了解用户需求，为产品设计提供重要参考依据。
希望大家在实际工作中能够灵活运用这些方法，提高需求分析的效率和准确性。
简述需求分析的方法
简述需求分析的方法需求分析是软件开发过程中非常重要的一步，它是为了确定用户对系统或产品的需求和期望，并将之转化为可衡量的要求和目标。
在需求分析中，有一些常用的方法可以帮助开发团队更加准确地理解用户需求，下面将简要介绍几种常用的需求分析方法。
首先，用户访谈是一种常见的需求分析方法。
通过与用户直接交流，开发团队可以深入了解用户的需求和期望。
在访谈中，开发团队可以提出问题，引导用户详细描述他们的需求，并进一步探索隐藏的需求。
通过用户访谈，可以有效地收集到用户真实的需求信息，并为后续的需求分析提供重要的参考。
其次，场景分析是另一种常用的方法。
场景分析通过模拟用户的使用场景和操作流程，帮助开发团队理解用户如何使用产品，并从中发现用户的需求。
通过观察用户在真实环境中的行为，开发团队可以更好地了解用户需求，并根据观察结果进行进一步的分析和设计。
此外，原型设计也是一种重要的需求分析方法。
在原型设计中，开发团队可以根据用户需求快速制作出初步的原型，以便用户更好地理解和反馈。
通过原型设计，开发团队可以验证用户需求的可行性，并及时调整和完善产品的功能和界面设计。
另外，文档分析也是一种常用的需求分析方法。
在文档分析中，开发团队可以收集和分析相关的需求文档、用户手册、市场调研报告等资料，从中寻找用户需求的线索。
通过深入研读文档，开发团队可以更好地理解用户需求的背景和上下文，并从中提取出关键的需求信息。
最后，同类产品分析也是一种重要的需求分析方法。
通过研究和分析同类产品，开发团队可以了解市场上已有产品的特点和用户反馈，从中挖掘用户的潜在需求。
通过同类产品分析，开发团队可以找到产品的差距和创新点，为后续的需求分析和产品设计提供有益的参考。
综上所述，需求分析是软件开发不可或缺的一环。
通过用户访谈、场景分析、原型设计、文档分析和同类产品分析等方法，开发团队可以更加准确地了解用户需求，为后续的设计和开发工作提供有价值的指导。
在实际应用中，可以根据具体的项目特点和需求情况，结合多种分析方法来进行需求分析，以获得更全面准确的需求信息，为开发团队提供有力支持。
面向问题域的需求分析方法(改)
面向问题域的需求分析工具
原型设计
通过创建原型来模拟 实际系统的功能和行 为，以便更好地理解 用户需求和期望。
调查问卷
设计调查问卷来收集 用户对系法
通过观察用户在实际 操作中的行为和表现， 深入了解用户需求和 痛点。
专家评审
邀请领域专家对问题 进行评估和建议，提 供专业化的需求分析 和建议。
为了更好地适应变化，未来的需求分 析方法需要进一步加强与领域知识的 结合，提高对问题本质的把握能力。
此外，还需要加强需求分析方法与其 他软件开发过程的有效集成，以提高 软件开发的效率和软件质量。
THANKS
感谢观看
面向问题域的需求分析方法强调了与领域专家的紧密合作，通过深入了解领域知识，能够更准确地把握 问题的本质和需求。
在实际应用中，面向问题域的需求分析方法已经取得了显著的效果，为解决复杂问题提供了有效的支持。
展望
随着技术的不断发展和问题域的日益 复杂，面向问题域的需求分析方法将
面临更多的挑战和机遇。
同时，随着人工智能和机器学习技术 的进步，可以利用这些技术来辅助需 求分析，提高分析的准确性和效率。
面向问题域的需求分 析方法(改)
目录
• 引言 • 问题域定义 • 需求分析方法 • 面向问题域的需求分析 • 案例研究 • 总结与展望
01
引言
主题简介
需求分析是软件开发过程中的重要环节，旨在明确用户 需求，为后续设计和开发提供依据。
面向问题域的需求分析方法是一种针对特定问题领域的 分析方法，通过对问题领域的深入理解，挖掘用户需求， 为解决问题提供有效支持。
需求分析的方法
访谈
通过与用户代表进行 面对面的交流，了解 他们的需求和期望。
软件工程中的软件需求分析方法
软件工程中的软件需求分析方法在软件工程中，软件需求分析是项目开发的关键步骤。
它的主要目标是识别、评估和记录软件系统所需的功能和性能。
软件需求分析方法涉及到一系列的活动，包括需求获取、需求分析、需求规范和需求验证等。
本文将介绍几种常用的软件需求分析方法，以帮助读者更好地了解软件工程中的软件需求分析。
一、问题域分析法问题域分析法是一种通过对软件系统所处的业务领域进行详细调查和分析来获取需求的方法。
它着重于理解用户所在的行业环境、业务流程和业务规则等。
通过与用户、领域专家和相关人员进行面谈和访谈，需求分析人员可以获得关于业务需求的详细信息。
在这个过程中，需求分析人员需要收集并整理各种相关文档和资料，如业务流程图、数据模型和现有系统的使用情况等。
通过问题域分析法，分析人员可以更好地理解用户需求，并将其转化为软件需求规格的形式。
二、原型法原型法是一种通过构建软件原型来获取和验证需求的方法。
它将软件开发过程中的快速原型开发技术与需求分析相结合，可以帮助需求分析人员更好地理解用户需求，并及时根据用户的反馈进行调整。
在原型法中，需求分析人员首先通过与用户沟通和访谈，收集和整理需求信息。
然后，利用原型工具或编程语言构建一个简化的系统原型，以便用户能够直观地感受系统的功能和界面。
在用户与原型进行交互的过程中，需求分析人员会根据用户的反馈及时进行修改和优化。
通过原型法，可以减少需求分析过程中的误解和沟通障碍，提高需求获取的效果。
三、场景分析法场景分析法是一种通过描述和分析用户在特定场景下的需求来获取和验证需求的方法。
它通过模拟用户在特定操作环境下的使用情景，帮助需求分析人员更好地理解用户需求和行为模式。
在场景分析法中，需求分析人员会与用户进行面谈，并通过观察用户的日常工作环境和任务流程来获取需求信息。
然后，将这些信息描述为一系列的场景，包括用户角色、任务步骤、输入和输出等。
通过对这些场景进行分析和比较，需求分析人员可以得到用户需求的共性和差异，并将其转化为软件需求规格的形式。
软件工程中的需求分析方法
软件工程中的需求分析方法需求分析是软件工程中非常关键的一步，它确保软件开发团队和客户之间对软件需求达成一致，为软件项目提供明确的目标和方向。
本文将介绍软件工程中的主要需求分析方法，并分析其特点和适用场景。
一、原型方法原型方法是一种快速开发和迭代的需求分析方法。
此方法通过创建原型来帮助软件开发人员和用户共同探索需求，快速获得反馈并进行调整。
原型可以是纸质原型、静态原型或可交互的原型。
通过与用户互动，原型方法能够更好地理解用户需求，从而提高软件开发的成功率。
原型方法的优点是快速、灵活和易于理解。
它能够帮助软件开发团队更早地了解用户需求，发现潜在问题，并及时进行调整。
然而，原型方法也存在一些局限性，例如原型可能无法全面展示软件的所有功能，用户反馈可能不够准确和全面。
二、面向对象方法面向对象方法是一种基于对象概念的需求分析方法。
在面向对象方法中，系统被分解为一组相互关联的对象，对象具有属性和方法，它们通过消息传递进行通信。
通过面向对象方法，软件开发团队可以更好地理解系统的结构和行为，并抽象出重要的概念和对象。
面向对象方法的优点是可重用性和可扩展性，它可以将复杂的系统问题分解为简单的对象，使软件开发过程更加模块化和可管理。
然而，面向对象方法也需要开发团队具备一定的面向对象设计和编程技能。
三、数据流图方法数据流图方法是一种基于数据流和转换的需求分析方法。
此方法通过表示系统中的数据流和处理过程来描述系统的功能和行为。
数据流图能够清晰地展示数据的来源、流向以及被处理的方式，帮助软件开发团队更好地理解系统的功能和交互。
数据流图方法的优点是简单直观，易于理解和交流。
它能够帮助软件开发团队和用户共同探讨系统的需求，发现潜在的问题，并进行合理的调整。
然而，数据流图方法可能难以应对较为复杂的系统，对于系统的非功能性需求描述也有一定局限性。
四、用例方法用例方法是一种基于功能需求的需求分析方法。
在用例方法中，系统功能被表示为一组用例，每个用例描述了系统和用户之间的交互过程。
第10章_面向问题域的需求分析方法
10.5PDOA方法的分析步骤
PDOA方法的基本过程可分为三步 1）搜集需求信息，界定和描述问题及问题域； 2）划分问题域并开发相关问题框架； 3）根据问题框架的类型进一步描述问题域的 相关特性 以某校园通系统为实例，来说明PDOA方法的 工作原理
10.6问题框架实例间的关系及其组合
问题框架实例间的关系 静态形式：两个问题框架实例在形式上相互关 联是指它们所对应的问题图之间相互关联。 两个问题框架实例相关形式上表现为它们具有 一个或多个公共的域；一个问题框架实例所包 含的需求，或者说它所对应的子问题应满足的 需求是另一个问题框架实例中的域
命令式行为问题框架 命令式行为问题框架的直观思想是：存在客观 世界的某个部分，其行为要依据操作者发出的 命令来控制。问题是要建立一个机器，该机器 接受操作者的命令并施加相应控制。其问题框 架见P(138)
信息显示问题框架 直观思想：存在客观世界的某个部分，关于其 状态和行为的特定信息被连续的需要。问题是 要建立一个机器，该机器从客观世界中获得相 关信息，并按所要求的格式呈现在所要求的地 方。其问题框架见P(138)
问题框架实例的组合与基于问题框架划分问题 及其问题域相辅相成，它主要考虑在组合各个 独立的问题框架实例时，如何使不同的问题框 架实例在整体上保持协调，从而使它们能与原 来的整个问题及其问题域保持一致。问题框架 实例间的组合与它们之间存在的关系密切相关， 不同类型的关系所对应的组合问题不同.详情 请看书本第151—152页
第10章面向问题域的需求分析方法
10.1问题域 10.2问题域的划分 10.3问题框架 10.4问题框架的类型 10.5PDOA方法的分析步骤 10.6问题框架实例间的关系及其组合
10.1问题域
问题域是指与问题相关的部分现实世界。问题域与问 题相互依存，问题处于一定的问题域之中，脱离了问 题域，问题就无法存在。问题域也是与特定的问题相 关的现实世界，脱离特定的问题考虑纯粹的问题域没 有任何意义。问题域包括所有与秒速期望效果有关的 事物，可用来产生这些效果的方法也是问题域的一部 分。 用来产生相关效果的方法可分为直接方法和间接方法。 直接方法是指机器的输入/输出设备，间接方法则包括 用户以及可以执行任务的其他计算机等。 用户需求可视为通过计算机程序在问题域中施加的效 果，这些效果是对用户预期的描述。
软件需求工程 第11章 面向问题域的需求分析方法
问题框架可根据问题域特征、接口特征和需求特征定义一个直观的、可标识的问题类。对于上面所提 及的五类基本问题，可以用五个不同的基本问题框架分别进行描述。 在形式上，一个问题框架类似于一个问题图。 与问题图稍微不同的是,问题框架中对每个域1的类型与共享现象的类型都进行了描述。 问题框架不对应具体问题,其中的组成元素也不具有任何实际的意义。 具体应用一个问题框架于某个实际问题称为实例化该问题框架,实例化后的结果称为问题框架实例。
11ቤተ መጻሕፍቲ ባይዱ4 问题框架的类型
信息显示问题框架的其他两种变体
除带连接域的变体外,信息显示问题框架还有两种常见的变体。第一种变体引进一 个模型域,并将信息显示问题框架用两个子框架表示,其中第一个子框架对现实世界 进行建模，生成一个反映现实世界的模型域; 第二个子框架基于该模型域显示需求 中所要求的信息，如图所示：
11-2 问题域的划分
11-2 问题域的划分
分治策略
对于复杂问题的分析，一般的做法是采用“分而治之”的策略。人们一般采用层次式功能 分解的方法。 1. 确定系统所需的各项功能； 2. 若某些（或个）功能对应于一个足够小的具体实现单元，则由该实现单元直接实现这些 （或个）功能； 3. 否则，把功能分解为一系列子功能，并重复步骤2和3，直到所有子功能可分别对应一个 足够小的具体实现单元。
问题框架是一种模式，它捕获并定义了常见的简单子问题的类型。问题框架的作用类似于设计模式,只 是前者用于问题的分析和描述,后者用于解决方案的设计。
11-4 问题框架的类型
如何利用需求分析解决问题
如何利用需求分析解决问题需求分析是一项重要的任务，旨在确定用户对产品或服务所需的功能、性能和特性。
通过深入了解用户的需求，需求分析可以帮助我们有效解决问题、提供更好的解决方案，并确保项目成功。
本文将介绍如何利用需求分析来解决问题。
一、明确问题在进行需求分析之前，首先需要明确问题的范围和实质。
问题可以来自用户的需求、产品的缺陷、流程的问题等。
明确问题的范围有助于聚焦分析的重点和目标。
二、调研用户需求需求分析的核心在于了解用户的需求。
为了获取用户需求的准确信息，可以采取多种方式，如用户访谈、问卷调查、观察用户操作等。
通过这些调研手段，我们可以获取用户的功能需求、非功能需求、期望以及对解决方案的具体要求等。
三、分析用户需求在收集到用户需求的基础上，需要对其进行整理和分析。
将用户需求分类，归纳出共同的需求，去除冲突和重复的需求。
同时，还需要将用户需求与产品的可行性、技术可行性进行匹配，确保提供的解决方案能够满足用户需求并可实现。
四、定义解决方案根据分析得出的用户需求，可以制定相应的解决方案。
解决方案应该明确提出产品或服务的功能、性能和特性，并与用户需求相对应。
解决方案应该能够解决问题，提供有效的解决方案，并满足用户的期望。
五、验证解决方案在定义解决方案之后，需要进行验证。
验证的目的是确认解决方案是否能够满足用户的需求。
可以通过原型测试、用户反馈、功能测试等方式进行验证。
根据验证结果，我们可以及时调整解决方案，确保最终提供的解决方案能够解决问题并满足用户的需求。
六、沟通和协作需求分析是一个复杂的过程，需要与多个利益相关者进行沟通和协作。
需求工程师、设计师、开发人员、产品经理等之间需要密切合作，确保全员理解用户需求，并能按照用户需求提供相应解决方案。
通过有效的沟通和协作，可以减少需求误解和偏差，提高解决问题的效率。
七、持续优化需求分析并非一次性的任务，在产品或服务的生命周期中需要不断进行优化。
根据用户的反馈和市场的变化，持续分析用户需求，更新解决方案，以适应变化的环境。
简述需求分析的方法
简述需求分析的方法需求分析是软件开发过程中的重要环节，它旨在明确系统或软件产品的需求，为后续的设计、开发和测试工作提供指导。
通过合理的需求分析方法，可以确保软件开发过程高效有序，并且最终交付的产品能够满足用户的需求。
本文将简述几种常用的需求分析方法。
一、用户需求调研方法用户需求调研是需求分析的起点，通过对用户的观察、访谈、问卷调查等方式，了解用户的需求和期望。
常用的用户需求调研方法包括：1. 用户观察法：通过观察用户在日常生活或工作中的行为，了解用户的需求和使用习惯。
2. 用户访谈法：与用户进行面对面的访谈，深入了解用户的需求、问题和期望，并进行记录和整理。
3. 问卷调查法：通过设计问卷并发放给用户，收集用户的意见和需求，并进行统计和分析。
二、功能需求分析方法功能需求是软件或系统必须要具备的功能特性，通过功能需求分析方法可以明确系统的功能范围和细节。
常用的功能需求分析方法包括：1. 需求可追踪矩阵法：将需求转化为矩阵形式，通过需求矩阵可以追踪每个功能需求的来源、变更和实现情况。
2. 功能分解法：将系统的功能进行层级划分和拆分，形成功能树或功能图，清晰地展示系统的功能结构和依赖关系。
三、非功能需求分析方法非功能需求主要包括性能、可靠性、安全性等系统质量属性相关的需求。
通过非功能需求分析方法可以明确系统的性能要求、安全等级等。
常用的非功能需求分析方法包括：1. 负载测试法：通过模拟真实使用场景，测试系统在不同负载下的性能表现，包括响应时间、并发处理能力等。
2. 故障注入法：通过人为制造故障或异常情况，模拟系统的不同运行状态，评估系统的可靠性和恢复能力。
四、数据需求分析方法数据需求分析是指确定系统所需的数据和数据处理方式。
通过数据需求分析方法可以帮助开发团队设计数据结构和数据处理流程。
常用的数据需求分析方法包括：1. 数据流程图法：通过绘制数据流程图，描述数据的流动和处理过程，明确数据的输入、输出和处理方式。
面向对象的需求分析方法
面向对象的需求分析方法面向对象的需求分析方法的核心是利用面向对象的概念和方法为软件需求建造模型。
它包含面向对象风格的图形语言机制和用于指导需求分析的面向对象方法学。
面向对象的思想最初起源于 20世纪 60年代中期的仿真程序设计语言Simula67。
20世纪80年代初出现的Smalltalk 语言及其程序设计环境对面向对象技术的推广应用起到了显著的促进作用。
20世纪90年代中后期诞生并迅速成熟的UML （Unifie d Modeling Language，统一建模语言）是面向对象技术发展的一个重要里程碑。
UML 统一了面向对象建模的基本概念、术语和表示方法，不仅为面向对象的软件开发过程提供了丰富的表达手段，而且也为软件开发人员提供了互相交流、分享经验的共用语言。
本章首先介绍面向对象的主要概念和思想。
在概述了UML的全貌之后，以“家庭保安系统”为实例，介绍与需求分析相关的部分 UML语言机制以及基于UML的面向对象的需求分析方法和过程。
第一节面向对象的概念与思想一、面向对象的概念关于“面向对象”，有许多不同的看法。
Coad和 Yourdon给出了一个定义：“面向对象 = 对象 + 类 + 继承 + 消息通信”。
如果一个软件系统是使用这样4个概念设计和实现的，则认为这个软件系统是面向对象的。
一个面向对象的程序的每一成分应是对象，计算是通过新的对象的建立和对象之间的消息通信来执行的。
1.对象（object）一般意义来讲，对象是现实世界中存在的一个事物。
可以是物理的，如一个家具或桌子，如图 5-1-1所示，可以是概念上的，如一个开发项目。
对象是构成现实世界的一个独立的单位，具有自己的静态特征（用数据描述）和动态特征（行为或具有的功能）。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
性。
2020/8/4
16
11.5 PDOA方法的分析步骤
问题及问题域的界定与描述
1. 下文图界定并描述整个问题及其问题域存在的不 足：
1. 只描述了与解系统直接相连的域，而没有描述与解系统 间接相连的其它域，这导致一些对于理解用户需求、甚 至与用户需求直接关联的域可能会因此被忽略掉。
2. 只描述了系统外部可见的域，而没有描述在系统运行后 才生成的域；
2020/8/4
12
11.4 问题框架的类型
工件问题框架 思想：需要一个工具，让用户创建并编辑
特定类型的计算机可处理的文本或图形对象或 简单结构，以便它们随后能被拷贝、打印、分 析或按其它方式使用。问题是要建立一个机器， 该机器可以充当这个工具。
工件问题框架图
2020/8/4
13
11.4 问题框架的类型
3. 只描述了域与解系统之间的关系，而没有描述域与域之 间的关系；
4. 没有对问题进行任何具体的描述。
2020/8/4
17
11.5 PDOA方法的分析步骤
2. 问题图 M. Jackson等认为问题及其问题域的界定和
描述必须以问题为中心，而不是以解系统为中心， 并提出了采用问题图的形式来界定和描述问题及 其问题域。
问题框架实例间的关系 一个问题框架实例对应一个问题图，因而
两个问题框架实例在形式上相互关联是指它们 所对应的问题图之间相互关联。
两个问题框架实例形式上相关的另一种情 况是一个问题框架实例所包含的需求，或者说 它所对应的子问题应满足的需求是另一个问题 框架实例中的域。
2020/8/4
21
11.6 问题框架实例间的关系及其组合
需求式行为问题框架图
带连接域的需求式行为问题框架图
2020/8/4
9
11.4 问题框架的类型
命令式行为问题框架 思想：存在客观世界的某个部分，其行为
要依据操作者发出的命令来控制。问题是要建 立一个机器，该机器接受操作者的命令并施加 相应控制。
命令式行为问题框架图
2020/8/4
10
11.4 问题框架的类型
将每个子问题看成是整个问题的一个投影， 通过不同角度的投影，将整个问题分解为一系 列相互关联的子问题。其中子问题的需求是整 个需求的一个投影，它的接口也是整个问题接 口的一个投影。同时，在划分子问题的过程中， 以已知解决方案的问题或以已知解决方案的相 似问题为导向，来对未知解决方案的整个待求 解问题进行恰当的分析和划分。
问题图形式上是由机器、问题域和需求以及 它们之间的关系组成。
2020/8/4
18
11.5 PDOA方法的分析步骤
校园通的问题图
2020/8/4
19
11.5 PDOA方法的分析步骤
基于问题框架的问题域划分
1. 由内到外的划分； 2. 由外到内的划分； 3. 基于节奏的划分。
2020/8/4
20
11.6 问题框架实例间的关系及其组合
变换问题框架 思想：存在一些计算机可读的输入文件，
其数据必须被变换以给出所需要的特定输出文 件，输出数据必须遵守特定的格式，并且必须 按照特定的规则从输入数据中导出。问题是要 建立一个机器，该机器从输入中产生所需要的 输出。
变换问题框架图
2020/8/4
14
11.5 PDOA方法的分析步骤
特点 将关注的重点定位在问题及其相关的问题
2020/8/4
7
11.3 问题框架
问题框架是一种模式，它捕获并定义了常 见的简单子问题的类型。
问题框架的组成元素及其关系
2020/8/4
8
11.4 问题框架的类型
需求式行为问题框架 思想：存在客观世界的某个部分，其行为
要受到控制，以使得它满足特定的条件。问题 是要建立一个机器，该机器施加所需要的控制。
信息显示问题框架 思想：存在客观世界的某个部分，关于其
状态和行为的特定信息被连续的需要。问题是 要建立一个机器，该机器从客观世界中获得相 关信息，并按所要求的格式呈现在所要求的地 方。
信息显示问题框架图
2020/8/4
11
的信息显示问题框架图
程
序
问题域
接口
机器域
2020/8/4
4
11.2 问题域的划分
对于复杂问题的分析，一般的做法是采用 “分而治之”的策略。人们一般采用层次式 功能分解的方法。
1. 确定系统所需的各项功能；
2. 若某些（或个）功能对应于一个足够小的具体实 现单元，则由该实现单元直接实现这些（或个） 功能；
3. 否则，把功能分解为一系列子功能，并重复步骤2 和3，直到所有子功能可分别对应一个足够小的具 体实现单元。
第 11 章 面向问题域的需求 分析方法
1
第 11 章 面向问题域的需求分析方法
11.1 问题域 11.2 问题域的划分 11.3 问题框架 11.4 问题框架的类型 11.5 PDOA方法的分析步骤 11.6 问题框架实例间的关系及其组合
2020/8/4
2
11.1 问题域
问题域 与问题相关的部分现实世界。
2020/8/4
5
11.2 问题域的划分
层次式分解方法的不足 把高层功能分解成子功能的方式可能有多
种，但没有任何方法可以提前告知这些分解方 式中哪一个好或哪一个差，直到进入实现阶段 时才可评价所采用的分解方式是否恰当，而此 时分解活动早已结束。
2020/8/4
6
11.2 问题域的划分
并行划分
域上，通过对问题及其问题域进行合理的分类， 为分析人员提供解决具体问题的相关指南。同 时从问题域的角度出发，使用户能参与整个需 求过程，有利于更直观和真实地反映问题域的 信息和用户的需求。
2020/8/4
15
11.5 PDOA方法的分析步骤
步骤
1. 搜集需求信息，界定和描述问题及问题域； 2. 划分问题域并开发相关问题框架； 3. 根据问题框架的类型进一步描述问题域的相关特
问题与问题域之间的相互关系 问题域和问题相互依存，问题处于一定的
问题域之中，脱离了问题域，问题就无法存在。 问题域也是与特定的问题相关的现实世界，脱 离特定的问题考虑纯粹的问题域没有任何意义。
2020/8/4
3
11.1 问题域
需求分析文档、规格说明文档和程序之间的关 系
需求分析文档
需求规格 说明文档