编辑导语:软件需求分析是对软件规划阶段建立的软件可行性分析进行提炼和细化，分析各种可能的解决方案，并分配到各个软件元素中。这是软件定义阶段的最后一步，就是确定系统必须做什么，即对目标系统提出完整、准确、清晰、具体的需求。
一.需求分析的定义
软件需求分析又称系统需求分析或需求分析工程，是开发人员准确了解用户和项目的具体需求，如功能、性能、可靠性等的过程。，通过深入细致的研究分析，将非形式化的用户需求表达转化为完整的需求定义，从而确定系统必须做什么。
软件开发一般包括:可行性分析、需求分析、软件设计、软件开发、软件测试、软件实现、软件服务等步骤。软件开发的第一步是需求共享。
用户需求分析是指在系统设计和开发之前和过程中对用户需求的调查和分析，是系统设计、系统改进和系统维护的基础。
需求意味着需要和欲望。需求是身体的客观需要，欲望是主观需要，包括人在胜利、环境、社会中的需要。
需求是产品的市场基础。一个成功的产品不仅能满足用户的物质需求，还能满足他们的精神和心理需求。
二、软件需求分析的目标
需求分析是软件规划阶段的重要活动，也是软件生命周期的第一步。在这个阶段，是分析系统在功能上需要“实现”什么，而不是考虑如何“实现”。
分析客户的信息需求，将客户不规则、随机的需求转化为规范、严谨、结构化的需求，将客户不正确的需求转化为正确的需求，将客户不现实的需求转化为可实现的需求，切断客户不必要的需求，弥补客户错过的需求。
此外，软件的一些非功能性需求、软件设计的约束、运行时与其他软件的关系也是软件需求分析的目标。
三。软件需求分析的原则
一般来说，需求分析应符合以下一般原则:
1.能够表达和理解问题的信息领域
信息域反映的是数据在用户业务系统中的流动以及数据处理的处理过程，所以信息域就是要解决“做什么”的问题。关键因素。根据信息领域所描述的信息流、信息内容和信息结构，我们可以充分理解系统的功能。
2.建立一个模型来描述系统的信息、功能和行为。
建立模型的过程是一个由粗到细的综合分析过程。通过加深对模型的理解，可以对实际问题有更深刻的理解。
3.能够将建立的模型以一定的形式进行分解。
分解是为了降低问题的复杂性，增加问题的可解性和可描述性。分解可以在同一层次进行，也可以在多个层次进行。
4.区分系统的逻辑视图和物理视图。
软件需求的逻辑视图描述的是系统要实现的功能和要处理的信息之间的关系，与实现细节无关，而物理视图描述的是处理功能和信息结构的实际形式，与实现细节有关。
需求分析只研究软件系统“做什么？”，先不说“怎么做？”。
四。软件需求分析的内容
需求分析的内容是为要开发的软件提供完整、清晰、具体的需求，确定软件必须实现哪些任务。
它分为三个方面:功能需求、非功能需求和设计约束:
1.功能需求
功能需求是软件必须完成什么，它必须实现什么功能，以及为了给用户提供有用的功能，它需要执行什么动作。
功能需求是软件需求的主体。开发人员需要亲自与用户沟通，验证用户的需求，从软件帮助用户完成交易的角度充分描述外部行为，形成软件需求规范。
2.非功能性需求
作为功能需求的补充，软件需求分析还应该包括一些非功能需求。
包括主要软件的性能要求、运行环境要求、软件设计必须遵循的相关标准和规范、用户界面设计的具体细节、未来可能的扩展方案等。
3.设计约束条件
也称为设计约束，它们通常是对某些设计或实现方案的约束。
比如要求要开发的软件必须使用Oracle数据库系统完成数据管理功能，运行时必须基于Linux环境。
五、软件需求分析过程
需求分析阶段的工作可以分为四个方面:问题识别、分析综合、规格制定和评估。
1.问题标识
它是从系统的角度来理解软件，确定所开发系统的综合需求，提出这些需求的实现条件和需求应满足的标准。
这些需求包括:功能需求、性能需求、环境需求、可靠性需求、安全保密需求、用户界面需求、资源使用需求、软件成本消耗和开发进度需求，以及系统预先可能达到的目标。
2.分析与综合
逐步细化所有软件功能，找出系统各要素、界面特性、设计约束之间的关系，分析是否满足要求，剔除不合理部分，增加所需部分。
最后综合了系统的解决方案，给出了待开发系统的详细逻辑模型。
3.制定规范。
也就是准备文档，描述需求的文档称为软件需求说明书。请注意，需求分析阶段的结果是需求规格，它将被提交到下一个阶段。
4.回顾
评估功能和其他需求的正确性、完整性和清晰性。审核通过后，才能进行下一阶段的工作；否则，将重新进行需求分析。
六。软件需求评估方法
需求分析方法通常包括:模糊聚类分析、质量功能展开、KANO模型分析、A/B测试。其中，卡诺模型是最常用的。
1.模糊聚类分析
它是通过分析客观事物的不同特征和接近程度，建立模糊相似度，对客观事物进行排列和分类的方法。
在用户需求分析的应用中，我们判断用户需求之间的相似性，然后进行统计并建立一个相似矩阵，再寻找需求组合之间的相似性，从而逐步将用户需求逐一分类。
最后得到一个关系图，以更加直观和自然的方式展示用户需求特征之间的异同。模糊聚类分析一般需要数学建模和需求分析。
2.质量功能展开
是指对用户对产品的需求进行多层次的演绎分析，转化为产品设计需求、工程部件特性、工艺需求和生产需求，用于指导产品设计，保证产品质量。这是一个面向用户的质量管理工具。
由于该方法使用的主要图形像房子一样，因此也称为“质量屋”，如下图所示:
3.卡诺卡诺模型
它是由Noriaki Kano博士提出的与产品性能相关的用户满意度模型。该模型能够很好地识别和分类用户需求，是对用户需求进行分类和优先排序的有用工具。通过分析用户需求对用户满意度的影响，反映了产品性能与用户满意度之间的非线性关系。
Noriaki Kano将影响满意度的因素分为五种类型，包括:必要需求、预期需求、吸引需求、无差别需求和逆向需求。
兴奋:用户意想不到的。不提供二次需求，满意度不会降低，但提供二次需求，满意度会大大提高。期望:当提供这个需求时，用户满意度会提高；当没有提供这个需求时，用户满意度会降低；基本需求:当这个需求被优化后，用户满意度不会提高；当这个需求没有提供时，用户满意度会大打折扣；无差异需求:无论这个需求提供与否，用户满意度都不会改变，根本不会在意；反向需求:用户根本没有这个需求，但是提供之后用户的满意度会降低。使用KANO模型评估需求主要侧重于对用户需求的分类和讨论。为了便于分析，我们可以设计相应的调查问卷。
在问卷中，你需要为产品的一个功能设置正反问句:“如果产品有这个功能，你怎么看？”“如果产品的这个功能不存在，你怎么看？”
每个问题采用态度量表的形式设计选项，即“我喜欢这个”、“我期待这个”、“我没意见”、“我能忍”和“我讨厌这个”。具体形式如下:
访谈调查结束后，根据分类矩阵，对研究问题进行分类，确定需求类型。卡诺模型的需求分类矩形如下:
利用问题结果项模型矩阵，我们可以清楚地看到哪些用户的需求是必须的，哪些用户是期望的，哪些是可有可无的，哪些用户是不确定的。
对用户的需求进行分类。在产品开发中，功能优先的顺序一般是:基本属性>预期属性>兴奋属性>无差异属性，去掉对可疑结果的需求和相反的需求。
4.A/B测试
就是分别制作两个或两个以上版本的Web或App界面或流程，让组成相同的访问者群体随机访问这些版本，收集每个群体的用户体验数据和业务数据，最终分析评估出综合成本较低的最佳版本，并正式采用。
常见的情况是在网站注册页面进行A/B测试，确定哪种方案注册率高，更能满足用户需求，实现商业利益最大化。
注意，在进行A/B测试时，每次只能测量一个变量，如果测试多个变量，就无法判断哪个变量导致了结果；测试环境要始终如一，比如测量时间要一致。
因为在不同的时间段，用户的访问次数会发生变化；测量的样本量要有统计意义，样本流量太小，不能反映在线用户的真实行为。
七、需求分析优先的方法
需求优先级的分析方法大致可以分为两类:定性分析法和定量分析法；
一种是根据分析人员的经验对需求进行主观优先级分类，称为定性分析法，如:四象限分析法、波士顿矩阵分析法；另一种是根据调查数据对调查数据进行分析，得到需求的优先分类，这种方法称为定量分析法，如卡诺模型。
1.四象限分析法
根据需求对业务的影响和需求实现的迫切程度，我们可以将需求分为如下四个象限，这也是经典的需求分类4分法。四象限分析是一种非常常用的需求优先级定性分析方法，如下所示:
而紧急的事情，影响了业务的正常运作，需要尽快处理；不重要但紧急的事情，虽然对业务影响不大，但需要尽快处理；重要而不紧急的事情，对业务影响大，但不需要短时间内完成；不急不重要，对业务影响不大，不需要短时间完成。
2.波士顿矩阵
波士顿矩阵是波士顿咨询公司发明的一种方法。最早用于分析市场增长率和市场份额，现在常用于分析需求。波士顿矩阵以两个维度将需求分为四个象限:用户价值维度和公司价值维度:
明星需求:对用户体验和公司战略有价值的需求。明星需求是双赢的需求，首先需要满足，比如一些促进用户活跃度和转化的需求，具体来说就是活跃度排名、优惠提醒等功能；需求:对用户体验有价值，但对公司战略和目标没有价值的需求。虽然这种需求看起来对公司没有直接价值，但是提升用户体验有助于提升用户的忠诚度，比如一些提升用户体验的需求。具体来说，它提供了多种快速登录方法和辅助输入功能等。金牛座需求:对用户体验没有价值甚至惹恼用户，但对公司战略有价值的需求。公司价值的体现，这样的需求要尽量考虑，避免影响用户。比如一些运营需求等。具体来说，收集用户信息等。瘦狗需求:对用户体验和公司战略没有价值的需求。这样的需求要过滤掉，比如一些伪需求。
3.卡诺卡诺模型法
Noriaki Kano将影响满意度的因素分为五种类型，包括:必要需求、预期需求、吸引需求、无差别需求和逆向需求。
八、如何确定软件需求
经过大量的需求调研工作，客户可能会提出大量的各种需求。
这些要求有的技术上可以实现，有的技术上不能实现；有的是管理上需要，有的是管理上不需要；有些合理，有些不合理。如何应对这些诉求？
本着“实现用户正确需求”的原则，对用户提出的需求进行严格的分析和筛选。
要想认清用户的需求，首先要认清用户。在进行需求调研的时候，我会和各种各样的人交流，他们的技能、技巧、性格、职位、工作内容都不一样。
但他们也有共同点:不做软件，不做需求分析。他们永远不会像你希望的那样描述需求。他们的需求是用自然语言描述的，抽象、粗略、随意。
这些抽象的、一般的、随意的用户需求转化为具体的、详细的、结构化的软件需求，这就是需求分析的重点。通常，从以下几点来识别和控制需求:
1.将抽象的需求具体化。
在需求调研的过程中，会发现用户提出自己的需求时，绝不会按照你希望的方式提出。有的人不知道你要什么，只是为了应付领导布置的任务，有的人职位较高，所以习惯从宏观的角度谈问题。所以在整理需求的时候，要把抽象的需求具体化。
2.构建由自然语言描述的需求
用户的需求总是很随意的，用正常交流的语言来描述。这个要求的主要特点是不严谨，容易有。这个需求不能由开发人员直接处理，开发人员需要的需求描述清楚，准确，不含糊。
作为用户和开发人员之间的桥梁，需求分析师有义务将用户用自然语言描述的需求结构化。将用户的描述翻译成更准确的语言，更接近IT人使用的语言。
3.注意避免误解。
理解偏差主要是因为需求分析师没有完全理解用户的需求。用户明明想表达这个意思，却被理解成另一个意思。
这是一个沟通问题，说话的人认为自己已经说清楚了，但偏偏双方就是没有真正理解对方，下面是我们需要注意的:
提高沟通技巧:站在对方的立场上思考问题。当双方都在描述某件事的时候，站在对方的角度去思考这些描述；提高沟通频率:一方面引导对方多说话，另一方面多问对方自己不明白或者觉得难以理解的地方，改变你的表达方式让对方确认是不是这个意思；学习对方领域的知识:用户有自己的知识领域，需求分析师也有自己的知识领域。前者全是业务术语，后者全是IT术语，有时候真的很难沟通。每个人的知识都不一样。想要交流顺畅，两个人知识重叠的地方越多越好。
4.确定项目范围之外的需求
用户的需求不可能是无限的，所有的需求都应该在项目的范围内。在做需求分析的时候，首先要确定项目目标，让用户知道需求边界在哪里。
这个项目要在项目一开始就经过双方的讨论和同意，后续的所有工作都要围绕这个目标来进行。原则是，即使你在这个阶段的目标已经达成之后，再设定新的目标，也不要不断修改一个目标。
5.识别错误的需求
对于那些不合逻辑的，不一致的，或者技术上不可能实现的，所有像这样的东西都被归类为错误的需求。
6.识别技术上无法实现的需求。
当需求者是面向用户的时候，它就代表了背后的整个RD团队。做好需求分析，需要对自己团队的技术能力有非常清晰的认识，什么能/不能做，或者什么能做但是需要太多成本等等。每个团队都有自己的技术边界。
九、整理需求
前期做了这么多收集工作，确定了需求，就要做好需求的梳理工作。需求整理并不是简单的把用户提出的所有需求都写下来，而是对整理过程进行全面的分析。
通过整理，使需求更有目的性、系统性、清晰性和易懂性。需求整理后，一般会生成需求调查报告和业务流程图，是后续工作的纲领性文件。
完成用户需求调查后，首先细化用户需求规格，对复杂的用户需求进行建模和分析，帮助软件开发人员更好地理解需求。
X.需求不明的影响
1.项目失控甚至未完成。
开发时间和成本失控。由于需求不完善，在开始开发之前，无法准确预估所需工作量，确定技术实现方案。在一步步开发的过程中，发现需求有漏洞，不断发现新的问题。
有时候因为一个简单的逻辑或者设计不清晰，沟通清楚之后，最后发现技术方案需要大幅度调整，很多项目会变得失控甚至烂掉。
2.技术性补脑需求
如果需求不明确，靠谱的技术生会考虑自己的逻辑和设计，按照自己的理解和想法去实现。
看似无忧，实则一千个观众有一千个哈姆雷特。一旦实现的逻辑不一定是产品预期的逻辑，到了测试环节，测试生也有自己的理解，导致花时间沟通统一意见，或者浪费时间返工修改。
3.高通信成本
项目规模越大，参与人员越多，矛盾越突出。
当面对大量的设计师，前端团队，后端团队，外部团队，测试团队等。，产品经理往往需要跟设计、技术、测试按需逻辑沟通，沟通的成本会很高。
4.产品逻辑很难追溯。
移动互联网时代，产品上线的迭代节奏非常快，产品的不断迭代更新或者人员的交接，往往需要回溯之前的上线逻辑。需求文档的缺失或不完善会导致线上逻辑的模糊，甚至导致后续产品需求设计的逻辑与线上的矛盾或冲突，给项目的发展带来麻烦。
参考资料:
《软件工程》赖军2016清华大学出版社《软件需求实用分析》杨长春2020清华大学出版社《产品交互设计基础》蒋晓2016清华大学出版社《开发制作app时需求不明确会有什么严重后果？本文最初由@发布両両両両両両両両両両両両両両両両両
