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