需求分析方法与规范
软件需求分析与规范
软件需求分析与规范一、引言在软件开发过程中，需求分析与规范起着重要的作用。
准确的需求分析可以确保软件开发的目标明确、需求明确，并为后续的开发工作提供必要的指导。
本文将讨论软件需求分析与规范的概念、方法和流程，以及其在软件开发中的重要性。
二、软件需求分析的概念软件需求分析是指对待开发软件的需求进行详尽的分析、定义和规范的过程。
通过需求分析，可以确保软件开发团队和客户对软件的功能、性能以及其他所需属性具有清晰的共识。
需求分析是软件开发的基础，是后续工作的依据。
三、软件需求分析的方法1. 需求获取：通过与客户和利益相关者的交流，收集和记录软件需求的信息。
可以采用访谈、问卷调查、文档分析等方法进行需求获取。
2. 需求分析：对收集到的需求进行分析，包括需求的功能性、非功能性要求等。
可以采用用例分析、数据流图等方法进行需求分析。
3. 需求规范：将需求以清晰、准确且易于理解的方式进行规范和文档化。
可以采用需求规范文档、用例图等方式进行需求规范。
四、软件需求规范的重要性软件需求规范是对需求进行详细描述和说明的文档，是软件开发过程中的重要组成部分。
具体而言，软件需求规范的重要性体现在以下几个方面：1. 目标明确：需求规范为开发团队提供了明确的目标和方向，使得他们可以更好地理解用户需求，以此为基础进行开发工作。
2. 沟通与共识：需求规范以统一的语言和形式描述了软件的需求，有助于开发团队与客户和利益相关者之间的沟通和共识形成。
3. 可追溯性：需求规范可以作为验证软件开发过程中阶段性完成情况的依据，以及后续验证软件是否满足需求的基准。
4. 保证质量：通过需求规范，可以减少需求的不明确性和冲突性，从而提高软件开发工作的质量和效率。
五、软件需求规范的内容软件需求规范的内容应该根据实际项目的需求进行调整和补充，但通常应包括以下几个方面：1. 系统概述：对软件系统的整体描述，包括系统的功能、目标用户、使用环境等。
2. 功能需求：对软件系统的各项功能进行详细的描述，包括每个功能的输入、输出、处理步骤等。
需求分析-怎么做需求分析
怎么做需求分析编辑导读：作为一个产品经理，每晚要接触到大大小小不同能源需求的需求。
要对这些需求或进行分析，才能更好地了解问题，从而制定相应的解决方案。
那么，怎么做需求分析呢？本文基于自身作战经验，对此展开分析，希望对你有帮助。
做这些同学不清楚如何做需求分析，希望通过本文简单的介绍可以帮助。
在寄送一个需求的时候，需要搞清楚这个需求的使用场景是什么，用户是谁，用来解决什么问题。
当我们清晰的了解问题从此以后，就可以对产生的原因进行分析，然后制定相应的解决方案。
在需求沟通时，需要挖掘用户资金需求的全球性需求吗？需要注意只需要挖掘弊端，不挖掘方案。
因为在问题级的探寻中用户是中所理性的，而在方案级的探讨中第二级用户是感性的。
用户只是环境问题专家，我们才是解决方案专家。
使用场景：细化业务场景，分析有多少个操作流程，整理用户预期的正常流程，再确认存在变化的情况。
存在问题：针对这些流程，从用户的角度思考当前存在的问题，会遇到什么问题。
解决方案：针对这些问题，思考系统提供更多除非提供什么样的功能。
需求分析时，确认重要干系人至关重要，决定着上线的介面功能是否满足了用户需求。
干系人分析需要侧重他们的关注点，就是正需求，不过他们的阻力点（担心点，负需求）也是十分重要的，这样的话用户特别关注不能怎么做。
1. 根据目标识别关键干系人读组织架构图，将相关业务部门负责人标识为关键标识干系人会。
标志牌如果这些部门有分支机构则分支机构负责人也标识为关键干系人。
意见领袖、业务专家字样为关键干系人。
2. 根据风险识别关键干系人对一大批基层用户带来造就影响的，则基层用户是关键干系人。
具有若所的，也是关键干系人。
技术开始实施存在风险的，开发团队也是关键干系人。
当系统复杂、涉及到不同的银行业务时，就需要通过业务子系统划分，将模块分解成更小的业务单元，以逐步解决系统风险问题过于复杂的问题。
根据系统特点，选择合适的划分策略进行分解。
对于积极支持管理业务的系统而言，最奇特的业务子系统划分策略就是按部门职能进行划分的。
软件需求分析与规范
1、i*框架（1）定义：i*框架是一种记录和分析目标和目标依赖关系的全面方法。
（2）基于建模语言GRL（3）对象：actor, goal, task, resource, softgoal（4）关系：Dependency（针对于actor）、Links（针对于除了actor的对象）（5）在i*框架中的建模构造的表示法：（6）Dependency：Goal dependency、Task dependency、Resource dependency、Softgoal dependency（7）Links：Means-end link、Contribution link、Task decomposition link（8）i*框架的两种目标模型：策略依赖模型（SDM）、策略原理模型（SRM）（9）i*中的一个战略依赖模型（SDM）的示例（10）i*中的一个战略基本原理模型（SRM）的示例2、KAOS框架（1）定义：KAOS建模语言是KAOS框架的一部分，用于引出、指定和分析目标、需求、场景和责任分配。
（2）六个互补的视图或子模型：目标模型、障碍模型、对象模型、代理模型、操作模型、行为模型（3）用于建模目标和将目标的责任分配给代理的KAOS框架的基本构造：（4）对象：Behavioural goal、Softgoal、Agent（5）关系：AND-decomposition、Alternative decomposition、Potential conflict、Responsibility assignment(relation of goals to agents)（6）在KAOS中的一个目标模型的示例（7）在KAOS中的职责分配示例3、简述需求工程包含哪些基本活动？每一项活动的主要任务是什么？（1）需求定义：定义项目的业务需求，明确项目的目标和范围。
（2）需求获取：需求获取是从涉众、文档资料或者环境中获取需求的过程，包括收集背景资料，定义项目前景和范围，选择信息来源，选择获取方法或技巧，记录获取结果。
第二章需求分析与规范(上)
1.需求分析的基本概念
1.3需求的种类 功能需求：比如在新建一个新学生记录时系 统能够自动参数一个学生序号； 性能需求：比如系统支持存放10万条学生记 录； 思考：如何定义和描述“可靠性”“可
用性”这样的一般性性能需求？结合战略 举措案例分析“可靠性”“可用性”
设计约束：比如使用的开发平台 商业约束：比如费用，时间，人力资源
2.需求分析的主要困难
2.3合作关系
• 如果需求分析员不能与用户建立良好的合作关系，那么他们在需求开发 过程中会很疲惫。 • 倘若用户不能很好地配合需求分析员，那并不表示他是个坏蛋。因为用 户有他自己的想法：
我回答了你们的问题，讲了该讲的。我们付钱给你们，难道还要我伺候你们 不成？我还要干自己的事情，别打扰我了。你们自己想办法把活干好吧 ……。
3.需求工程
3.4需求分析的工程化方法
• 需求分析不是艺术创作，需要有规范的基本方法，沟 通技巧可以因人而异，需求分析的过程和基本目标是 严肃而细致的。 • 需求的管理，变更和追踪是细致的工作，不能因为需 求项目的细小而放弃管理，放弃管理最终会使项目在 大量的细节中失败。记忆是不可靠的，没有详尽的记 录和确认只会使项目陷入争论和互相埋怨。 • 需求的工程化方法的目标是保证需求清晰，可控
2.需求分析的主要困难
2.4用户说不清楚需求
–
–
–
– –
讨论-评审-修改-确认-讨论-评审-修改……. 通过讨论出真知的方式，激发和挖掘出需求，不断的使 需求清晰起来。 沟通技巧（助产术,建议法） 和客户的沟通技巧在需求分析时占据着很重要的位臵。 需求理解与需求挖掘 可以广泛的借鉴其他系统的应用经验服务于当前项目 眼见为实：原型系统 由于各种原因，客户缺乏成功构建系统的动力或者主动性： 根据客观条件改善沟通关系
需求分析方法与规范
WENKU DESIGN
WENKU
REPORTING
https://
需求分析和评审
对整理后的需求进行深入分析，明确需 求的合理性、可行性和优先级，并进行 评审，确保需求的准确性和完整性。
需求文档化
将分析评审后的需求编写成正式的需 求文档，包括需求的描述、功能要求 、性能指标、界面设计等内容。
需求收集
通过与用户、市场调研、技术预 研等方式收集需求信息。
需求变更管理
在项目开发过程中，对需求变更 进行管理，确保需求的稳定性和 一致性。
WENKU DESIGN
WENKU DESIGN
2023-2026
ONE
KEEP VIEW
需求分析方法与规范
WENKU DESIGN
WENKU DESIGN
WENKU
REPORTING
https://
CATALOGUE
目 录
• 需求分析概述 • 需求分析方法 • 需求获取技术 • 需求规格说明编写 • 需求变更管理 • 需求管理工具
明确性
确保需求描述清晰、准确，避免歧义和模糊。
可测试性
确保每个需求都可以进行验证和测试。
完整性
确保需求覆盖了所有相关方面，无遗漏。
可追踪性
建立需求之间的追踪关系，以便于需求变更 的管理。
需求规格说明的评审与修改
评审
邀请相关利益相关者对需求规格说明进行评审，以确保其准确性和完整性。
修改
根据评审结果和其他反馈，对需求规格说明进行必要的修改和完善。
PART 05
需求变更管理
需求变更的原因与影响
外部环境变化
如政策调整、市场需求变化等。
内部需求变化
简述需求分析的方法
简述需求分析的方法需求分析（Requirements Analysis）是软件工程中的一个核心环节，是指对系统或软件的需求进行细致而全面的调查、分析和定义，以明确用户对系统的期望和要求。
在软件开发过程中，需求分析的准确性和全面性直接影响着后续的系统设计和开发工作。
本文将简述需求分析的方法。
需求分析的方法主要分为以下几种：一、访谈法：访谈法是需求分析中最常用的方法之一，通过与用户或相关利益相关者进行面对面的询问和交谈，以深入了解他们对系统或软件的需求和期望。
在访谈过程中，分析人员需要仔细听取用户的意见和建议，并且准确记录下来，以便后续的需求整理和分析。
二、问卷调查法：问卷调查法适用于需求范围较广、用户众多的情况下。
通过向用户发放问卷，让用户填写对系统或软件需求的评价和建议，以获得更广泛的意见和反馈。
在设计问卷时，需要注意问题的合理性和准确性，以确保收集到的信息具有较高的可信度和代表性。
三、观察法：观察法是通过观察用户在实际环境下的行为和操作来获取需求信息的方法。
通过观察用户在日常工作中的表现和需求，可以更直观地了解他们对系统或软件的要求。
具体观察的手段可以是实地观察、视频录像等。
观察法能够从真实的使用情况中发现用户的隐含需求，提高需求分析的准确性。
四、原型法：原型法是通过建立系统或软件的初步模型来明确需求的方法。
通过构建可交互的原型，用户可以更直观地感受到系统的功能和界面，从而提出更具体和准确的需求。
原型可以是草图、手绘图或者基于工具的屏幕原型等形式。
在原型法中，分析人员需要与用户密切合作，及时修正和改进原型，以满足用户的需求。
五、文档分析法：文档分析法是通过对已有的相关文档进行分析和归纳，提取其中的需求信息。
这些文档可以是需求规格说明书、用户手册、市场调研报告等。
通过文档分析，可以了解到项目的背景、现状、目标和约束等信息，为需求分析提供有力的支持。
分析人员需要仔细研读和理解各种文档，并将重要的信息进行整理和总结。
七步让你做好需求分析
七步让你做好需求分析确定项目目标第一步是与团队一起明确项目的目标和范围。
这些目标需要从多个利益相关者的角度进行审查，并且应该能够明确地解释给所有人。
一、了解业务需求首先，需要对项目的业务需求进行深入了解。
这包括对业务过程、业务规则、数据模型等方面的分析。
在这个阶段，可以与业务相关人员进行沟通，听取他们的意见和建议。
同时，可以借助各种工具和技术，如流程图、数据字典、用例图等来帮助理解业务需求。
二、分析用户需求除了业务需求，还需要对用户需求进行分析。
用户需求是指用户对系统或产品的期望和要求，包括功能需求、性能需求、可靠性需求、安全需求等。
在这个阶段，可以采用用户调研、问卷调查等方法，收集用户的反馈和建议。
同时，也可以通过竞品分析、市场研究等方式，了解用户的偏好和需求趋势。
三、制定需求规格说明书为了更好地明确项目目标，需要制定一份完整的需求规格说明书。
该文档应包括项目的业务需求、用户需求、功能列表、性能指标、安全要求等信息，以及各种约束条件和假设前提。
在制定需求规格说明书时，需要注意以下几点：1.明确需求的优先级。
不同的需求具有不同的重要性和紧急程度，需要按照一定的优先级进行排序。
2.确保需求可行性。
需求规格说明书中列举的需求应当是可行的，不要超出技术或资源的限制。
3.避免冲突和歧义。
需求规格说明书中应尽量避免冲突和歧义，以免后续开发过程中出现问题。
四、与利益相关者沟通在确定项目目标的过程中，需要与各方利益相关者进行充分沟通。
这包括业务代表、用户、开发团队、测试团队、运维团队等。
通过与他们的沟通，可以更好地理解各方的需求和期望，协调各方的利益关系，确保项目成功完成。
五、制定项目计划最后，确定项目目标之后，需要制定一个详细的项目计划。
该计划应包括项目的时间表、里程碑、资源分配、风险管理等方面的内容。
在制定项目计划时，需要充分考虑各方的需求和利益，确保项目目标得以实现。
总之，通过对业务需求和用户需求的分析，制定完整的需求规格说明书，并与各方利益相关者充分沟通，最终制定一个详细的项目计划，可以更好地确定项目目标。
需求分析的流程和规范
❖ 参了与问需需题求之求获后获取 才取者 能只 开的有 始重在 设他 计要系们性统理。解
跟谁谈需求 ❖ 客户是“上帝” 客户将决定是否掏钱，是否扣钱
❖ 最终用户直接使用软件，他们的评价直接影响付 款
“上帝”也不愿意在最终用户都不乐意的情况下 掏钱买软件，得罪人啊
❖ 别忽略了间接用户
间接用户经常是规范、标准的制定方 分功能性需求的重视者（信息中心）
❖ 业或务客需户求对需：系反 统求应 、的了 产目 品分标 高类组 层次织的结目构
它包括产品必须遵从的标准、规 范和约束，操作界面的具体细节 和构造上的限制；
❖ 下一层次需求：用户清楚要使用 该产品完成什么任务和一些非功 能性的特性需求，例如：程序的 易用性、健壮性和可靠性，而这 些特性都将使用户很好地接受具 有该特点的软件产品。
❖ 业了务用需户利求用决需系定求统用需户获要需取完求成，的它任描务述。
标要求，通常在项目定义与范围 文档中予以说明；
❖ 用户需求：描述了用户使用产品 必须要完成的任务，这在使用实 例或方案脚本中予以说明；
❖ 功能需求：定义了开发人员必须 实现的软件功能，使用户利用系 统能够完成他们的任务，从而满 足了业务需求
❖ 非现功给能用户性需的的行需求为求的和：执描分行述类的了操系作统等展，
❖ 项目范围：
乙方对需求的要求 “给多少钱办多少事，在合同约定的范围内谈需求，超过合同范
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
需求确认
客方项目负责人必须签字确认
需求跟踪
大于3人天（含）的需求变更必须SISO提交需求变更流程，客方项目负责人签字确认工作量
43
需求评审规范
44
需求评审流程
项目组编写《需求分析说明书》 项目组根据《项目需求评审检查单》的要求进行自查，自查结果记录到检查单里
注：检查单目前分三条技术线：Portal/BPM/JavaWeb，不同项目用不同的检查单。
10
需求概述
什么是需求? 跟谁谈需求? 怎样谈需求? 如何管理需求?
11
跟谁谈需求
客户、最终用户和间接用户
用户是一种泛称，它可细化为“客户”、“最终用户”和 “干系人” 掏钱买软件的用户称为客户 真正操作软件的用户称为最终用户。客户和最终用户可以 是同一人也可不是同一人 不是客户和最终用户，但对系统有一定影响的用户称为间 接用户（或干系人）
31
总结：需求获取方法
32
原型法
33
原型是什么
34
原型评价
35
原型法成功的要素
36
原型开发的工具
使用Dreamweaver/Frontpage制作Html页面 Microsoft Office Visio/Word 利用 龙博Ajax 所见即所得编辑生成页面
37
需求开发过程总结
目录
需求概述 需求分析规范
√ 需求分析模板
46
需求模板演示
《需求分析说明书-(通用模版v2.0).doc》 《需求分析说明书(for Java)-(模板v2.0).doc》样例展示 …
47
作业
参照需求v2.0模板，结合你以前实施或者接触过的项目实例，编写一份完整的项 目需求文档。 要求：
27
客户访谈技巧
28
客户访谈技巧
29
访谈演练
30
获取需求的5W1H方法
Why 顾客购买的目的？ What 顾客购买后要做什么？他需要什么功能？ Who 什么人使用？什么人付钱？ When 购买后什么时候使用？需要使用多久？ Where 在哪里使用？会不会换地方？ How 怎样使用？
38
需求概述
什么是需求? 跟谁谈需求? 怎样谈需求? 如何管理需求?
39
如何管理需求
40
目录
需求概述
√ 需求分析规范
需求分析模板
41
需求分析方法与业务建模
42
需求过程涉及的规范
项目立项
与商务、pmo共同确认需求范围，编写《需求范围说明书》，作为立项审批的重要输入条件
8
需求的重要性-项目需求与进度
项目管理涉及三方面问题：
进度安排 资源分配 质量管理（与需求保持一致）
每一个里程碑都意味着需求的解决又前进了一步，同时也会产生新 的需求和需求变化 项目实施的整个过程都可以通过需求管理进行监控
9
需求的重要性-项目需求与成本
需求“蔓延”会给项目带来额外的成本 如果没有有效的需求管理，需求变更带来的成本将难以控制
4
需求的特点
需求的阶段性 初期：宽泛的、抽象的需求 后期：详细的、具体的需求
5
需求的层次性
不同需求层次的衔接
所有的用户需求必须与售 前技术建议书一致 需求分析人员基于用户需 求提炼出功能需求 开发人员根据功能需求设 计、开发软件
技术建议书
用户需求
业务需求说明书 非功能性需求 约束条件 功能需求 系统需求 软件需求规格说明书
6
需求的重要性
项目需求与质量 项目需求与项目进度 项目需求与项目成本
7
需求的重要性-项目需求与质量
项目需求可以被定义为确保：
我们确知用户的需求是什么（质量） 满足项目需求的最佳实践方法（一致性）
质量的定义是“与需求保持一致” 在一个项目的生命周期里，需求是处于变化之中的 需求管理是项目质量的基础
24
非功能性需求
容量需求 性能需求 安全需求 高可用性需求 可靠性需求 可移植性需求 国际化需求 有关产品安装、配置、启动、关闭和监控操作等方面的需求 交付文档需求 … 详细见《需求分析说明书（模板）_v2.0.doc》
25
非功能性需求注意事项
26
客户访谈技巧
需求分析方法与规 范
1
目录
√ 需求概述
需求分析规范 需求分析模板
2
需求概述
什么是需求? 跟谁谈需求? 怎样谈需求? 如何管理需求?
3
什么是需求？
宽泛地讲，需求来源于客户的一些“需要”，这些“需要” 被分析、被确认后形成文档，该文档详细地说明了产品”必须或 应当“做什么。 不要认为需求就是一些零碎的对话、资料或邮件 需求是产品的根源，需求工作的优劣对产品的影响最大。
12
跟谁谈需求
13
与需求相关的组织
14
需求概述
什么是需求? 跟谁谈需求? 怎样谈需求? 如何管理需求?
15
怎样谈需求
16
甲方对需求的理解
17
乙方对需求的理解
18
需求获取的主要困难
19
需求获取的主要手段
20
访谈对象的选择
21
访谈准备
22
访谈准备举例
23
注意非功能性需求
需求计划
制定详细需求计划：
什么时候出需求调研表 什么时候做需求调研：需求调研的分工 什么时候做需求分析 什么时候做需求确认
需求调研
需求调研表模板参照PMTools中的样例模板，分技术线
需求分析
模板参照PMTools中的样例模板，分技术线
需求评审
必须满足需求评审规范，必须走SISO流程审批
必须是“完整”的项目需求，包含功能和非功能的需求，不能仅仅是一个小的需 求变更。 BPM、Portal、JavaWeb应用，题材不限。
48
面
PM邮件提交PMO、SA、总SA，附上《需求分析说明书》与记录的《评审检查单》 PMO、SA、总SA反馈评审意见 PM组织会议评审，针对有分歧的评审意见进行讨论，每一评审项有唯一的确认人， 由确认人给最终意见，PM负责记录汇总，更新《评审检查单》 PM提交SISO流程-需求评审。
45