第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 章 面向问题域的需求 分析方法
需求分析方法
需求分析方法
首先，我们可以采用访谈法来进行需求分析。
访谈法是最直接、最常用的需求获取方法之一。
通过与用户、业务人员或相关专家进行面对面的交流，可以深入了解他们的需求和期望。
在访谈过程中，我们可以通过提问、观察和记录来获取相关信息，从而全面了解用户的需求。
其次，调查法也是一种常用的需求分析方法。
通过设计问卷调查或在线调查，我们可以收集到大量用户的意见和建议。
调查法可以帮助我们快速了解用户的需求和偏好，为产品设计提供重要参考。
另外，原型法也是一种有效的需求分析方法。
通过制作产品原型，我们可以让用户直观地感受到产品的功能和界面，从而及时获取用户的反馈意见。
原型法可以帮助我们快速验证需求，减少后期修改的成本。
此外，文档分析法也是一种常用的需求分析方法。
通过研究相关的文档资料，我们可以了解到产品的历史、现状和未来发展方向，为需求分析提供重要依据。
最后，用户故事法也是一种常用的需求分析方法。
通过编写用户故事，我们可以清晰地描述用户的需求和使用场景，为产品设计提供具体的参考依据。
用户故事法可以帮助我们更好地理解用户需求，提高产品的用户体验。
总的来说，需求分析是软件开发过程中至关重要的一环。
采用合适的需求分析方法可以帮助我们全面、准确地了解用户需求，为产品设计提供重要参考依据。
希望大家在实际工作中能够灵活运用这些方法，提高需求分析的效率和准确性。
- 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 问题域
需求分析文档、规格说明文档和程序之间的关 系
需求分析文档
需求规格 说明文档