作者主页(文火冰糖的硅基工坊)：文火冰糖（王文兵）的博客_文火冰糖的硅基工坊_CSDN博客
本文网址：https://blog.csdn.net/HiWangWenBing/article/details/126855421
目录
第1章 什么是需求分析
1.1 概述
1.2 需求分析的本质
1.3 需求分析的目标
1.4 架构师、需求工程师、产品经理、技术经理
第2章 复杂需要的需求分析步骤
2.1 总体流程
2.2 每个环节的流程
2.3 需求分析的三要素
2.4 需求分析与需求验证的对等关系
第3章 需求分析的总体方法
3.1 功能分解方法
3.2 结构化分析方法
3.3 信息建模法
3.4 面向对象的分析方法
第1章 什么是需求分析
1.1 概述
需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义、需求规范，从而确定系统必须做什么的过程。
需求分析是软件计划阶段（范围基线）的重要活动，也是软件生存周期中的一个重要环节，该阶段是分析系统在功能上需要“实现什么What”，而不是考虑如何How去“实现”。
1.2 需求分析的本质
把业务和用户层面的需求转换成软件或硬件系统级的方案性需求。
（1）首先，把用户或业务需求映射到特定的产品（产品经理）。相同的需求，可通过不同的产品实现。
（2）然后，再把用户或业务需求映射到产品内部的技术方案（系统工程师），系统工程师更熟悉产品内部的软硬件总体设计。
因此，需求分析工程师必须熟悉组织内的软件或硬件系统级架构和系统方案，熟悉组织的业务系统，否则很难把用户的业务需求转换成软硬件系统的需求。
（1）相同的用户需求，不同组织、不同公司，经过需求分析，可能会给出不同的解决方案和需要规范。
（2）相同的用户需要，相同的组织，不同的分析人员，可能会给出不同的解决方案 。
1.3 需求分析的目标
（1）功能描述
把用户对待开发软件提出的“要求”或“需要”进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软件需要实现哪些功能，完成哪些工作。
（2）非功能描述
软件的一些非功能性需求(如软件性能、可靠性、响应时间、可扩展性等)，作为软件设计的约束条件
（3）约束条件
一般也称做设计限制条件，通常是对一些设计或实现方案的约束说明。例如，要求待开发软件必须使用Oracle数据库系统完成数据管理功能，运行时必须基于Linux环境等。
（4）对外交互（给出了满足需求的解决方案，但不是代码实现）
运行时与其他软件或功能的交互关系等也是软件需求分析的目标。
- 系统外的交互场景
- 系统内的交互场景
1.4 架构师、需求工程师、产品经理、技术经理
第2章 复杂需要的需求分析步骤
2.1 总体流程
（1）可行性研究报告 -- 产品经理、系统架构师
针对某个需求，分析在产品、技术上、经济上是否可行所进行的科学分析和论证。
对于复杂的功能或产品，需要给出可行性研究报告。特别是需要通过新产品满足客户需要的时候，一定需要进行可行性研究，对可能的技术方案、经济价值进行可行性研究。
（2）需求和分析导出 =》 技术可行性分析 -- 架构师、系统工程师
对于大多数客户需要，是在已有的产品或系统上做增量开发，这时候，就不需要进行可行性研发，只需要分析技术的可行性分析即可。技术可行性分析是可行性研究报告的简化版。
简单化输出技术解决方案的基本模型和主要的技术影响面即可（即系统中哪些模块受到了影响）。
（3）需求描述（系统级需要） -- 系统工程师
如果技术是可行的，也标识出了对系统中不同模块的影响程度和影响范围（系统中哪些模块受到了影响）。
则需要进一步描述，描述对软件系统和硬件系统的需求。生产系统级需求的文档。
- 对系统外设备的接口
- 时序性的功能需求（纵向的端到端的场景）
- 非时序的功能需求（某个特定的条目）
- 非功能需求
- 约束条件
（4）需求有效性验证（对系统内主要受影响模块的需要） -- 系统工程师、软件设计师
只有描述了对系统中主要业务功能模块影响和需要，不同业务部门的开发人员，才能进行软件和编码实现。
对这部分的需要的分析，最终生产详细的软件系统需求规格说明书。
备注：至于规格需要细化到什么程度，不同任务由哪些角色来实施，完全取决于不同组织的业务类型和职能部门的组织方式。
2.2 每个环节的流程
（1）问题识别（不用总阶段，识别的问题不同）
就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求(做什么)、性能需求(要达到什么指标)、环境需求(如机型、操作系统等)、可靠性需求(不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求(软件运行是所需的内存、CPU等)、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。
分析与综合： （不用总阶段，细化的对象不同，分析的方法也不相同）
逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。
制订规格说明书： （不用总阶段，输出的文档也不相同）
即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。
评审： （不用总阶段，参与文档书写和评审的人也不完全相同）
对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析。
2.3 需求分析的三要素
（1）角色：某个需求动作的操作者
（2）操作：操作者执行期望执行的动作
（3）目的：说明执行此动作的目的
比如：作为维护员，我希望基站支持xxx功能，目的是为了让终端用户能够更快速的上网。
2.4 需求分析与需求验证的对等关系
所有不同层面的需要，都需要通过不同层面的测试来进行验证。
第3章 需求分析的总体方法
软件需求的分析与设计方法较多，一些大同小异，而有的则基本思路相差很大。
从开发过程及特点出发，软件开发一般采用软件生存周期的开发方法，有时采用开发原型以帮助了解用户需求。在软件分析与设计时，自上而下由全局出发全面规划分析，然后逐步设计实现。
从系统分析出发，可将需求分析方法大致分为：
功能分解方法、结构化分析方法、信息建模法和面向对象的分析方法。
3.1 功能分解方法
将新系统作为多功能模块的组合。
各功能义可分解为若干子功能及接口，子功能再继续分解。
便可得到系统的雏形，即功能分解——功能、子功能、功能接口。
3.2 结构化分析方法
结构化分析方法是一种从问题空间到某种表示的映射方法，是结构化方法中重要且被普遍接受的表示系统，由数据流图和数据词典构成并表示。
此分析法又称为数据流法。
其基本策略是跟踪数据流，即研究问题域中数据流动方式及在各个环节上所进行的处理，从而发现数据流和加工。
结构化分析可定义为数据流、数据处理或加工、数据存储、端点、处理说明和数据字典。
数据流图（Data Flow Diagram）：简称DFD，它从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。
3.3 信息建模法
它从数据角度对现实世界建立模型。
大型软件较复杂；很难直接对其分析和设计，常借助模型。
模型是开发中常用工具，系统包括数据处理、事务管理和决策支持。实质上，也可看成由一系列有序模型构成，其有序模型通常为功能模型、信息模型、数据模型、控制模型和决策模型。有序是指这些模型是分别在系统的不同开发阶段及开发层次一同建立的。建立系统常用的基本工具是E—R图。经过改进后称为信息建模法，后来又发展为语义数据建模方法，并引入了许多面向对象的特点。
信息建模可定义为实体或对象、属性、关系、父类型/子类型和关联对象。此方法的核心概念是实体和关系，基本工具是E-R图，其基本要素由实体、属性和联系构成。该方法的基本策略是从现实中找出实体，然后再用属性进行描述
3.4 面向对象的分析方法
面向对象的分析方法的关键是识别问题域内的对象，分析它们之间的关系，并建立三类模型，即对象模型、动态模型和功能模型。面向对象主要考虑类或对象、结构与连接、继承和封装、消息通信，只表示面向对象的分析中几项最重要特征。类的对象是对问题域中事物的完整映射，包括事物的数据特征(即属性)和行为特征(即服务)。
