软件需求分析概述
目录
需求规格说明书
软件需求分析
产品需求文档（PRD）
产品需求文档（PRD）是将商业需求文档（BRD）和市场需求文档（MRD）。
Royce（瀑布模型）
瀑布模型 RUP（Rational Unified Process）是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。
缺点：过于理想。
需求分析
需求分析是整个项目开发流程的第一个环节，它是在用户和软件开发组之间建立对用户的共同理解，由软件开发组进行分析、精化并详细描述后，按文档规范编写出《软件需求规格说明书》的过程。软件需求分析特别重要。
它是整个过程中最关键的一个过程。只有通过软件需求分析，才能把软件功能和性能的总体概念描述为具体的软件需求规格说明，从而奠定软件开发的基础。许多大型应用系统的失败，最后均归结到需求分析的失败：要么获取需求的方法不当，使得需求分析不到位或不彻底，导致开发者反复多次地进行需求分析，致使设计、编码、测试无法顺利进行；要么客户配合不好，导致客户对需求不确认，或客户需求不断变化，同样致使设计、编码、测试无法顺利进行。
需求分析是一项重要的工作，也是最困难的工作。总结了下面几个特点。
（1）用户与开发人员很难进行交流
在软件生命周期中，只有需求阶段是面向用户的。需求分析是对用户的业务活动进行分析，以便明确在用户的业务环境中软件系统应该“做什么”。但是在开始时，开发人员和用户双方都不能准确地提出系统要“做什么”，因为软件开发人员不是用户问题领域的专家，不熟悉用户的业务活动和业务环境，又不可能在短期内搞清楚；而用户不熟悉计算机应用的有关问题。由于双方互相不了解对方的工作，又缺乏共同语言，所以让技术人员跟用户沟通，就相当于鸡同鸭讲。
（2）用户的需求是动态变化的
对于一个大型而复杂的软件系统，用户很难精确、完整地提出它的功能和性能要求。一开始只能提出一个大概、模糊的功能，只有经过长时间的反复认识才逐步明确。有时进入到设计、编程阶段才能明确，更有甚者，到开发后期还在提新的要求。这无疑给软件开发带来困难。
（3）系统变更的代价呈非线性增长
需求分析是软件开发的基础。咱们假定在需求分析的阶段发现一个错误，解决它需要用一个小时的时间，到设计、编程、测试和维护阶段解决，则要花费2.5、5、25甚至100倍的时间。
软件需求
软件需求就是为了解决我们生活或工作中的特定问题。淘宝解决人们购物的问题，微信解决了人们社交的问题，滴滴解决了人们出行的问题。
软件需求包括两部分：功能性需求和非功能性需求。
功能性需求是对软件的一项基本需求，比如这个软件有什么核心功能，商品浏览，加入购物车，确认订单，在线支付，等等。
用户除了显性的需求之外，影性的需求，我们产品经理也需要考虑到，
隐性的需求又分为好多种，这节课只讨论关于软件质量属性的需求，我们也称为非功能性需求。
非功能性需求包括：系统的易用性、执行速度、可靠性，处理异常情况的能力与方式==等。在决定系统的成功或失败的因素中，满足非功能性需求往往比满足功能性需求更为重要。
属性
优先级
软件需求具有优先级，应该能够在有限的资源（资金、人员、技术）情况下进行取舍，确定需求的优先级是高，中，低
定量化
表述清楚，不能含糊、像那种他大舅他二舅都是他舅，的情况，咱们产品经理要避免
什么是量化的需求呢，举个例子，例如，我们规划的这个系统应支持2000个并发用户，系统回应时间应低于10秒，这就是需求的量化。
需求过程中的角色
需求过程的迭代
软件需求分析是一个不断认识和逐步细化的过程。可不是一成不变的，
需求的过程就是产品是逐步迭代的过程，每次迭代我们都需要提供更高质量和更详细的产品需求。
在很多情况下，对需求的理解会随着设计和实现的过程而不断深入，这也会导致了我们的原型，或者PRD经常的进行修改。原因可能来自于错误的分析、客户环境和业务流程的改变、市场趋势的变化等。无论什么原因把，咱们产品经理要认识到需求变化是必然的，我们要做的就是采取相应的措施减少需求变更对我们设计的产品造成的的影响。
进行变更的需求必须经过需求评审、需求跟踪和比较分析后才能实施，不能用户或者客户想着怎么变就怎么变。
需求来源
想知道需求是怎么来的，这个问题也涉及到了咱们前面说的需求过程中的角色。
给大家详细的说一说需求的来源：
软件的需求来源很多，咱们产品经理要尽可能多地识别显式的来源和潜在的来源，并评估这些来源对系统的影响。大饼老师经过整理之后，最典型的来源包括以下5种。
（1）高层意志
公司高层下达的一个目标，这是进行软件产品开发的一个最常见动机，但它们通常表达比较模糊。这也是正常的，企业高层的意志咱们打工的谁能摸得准，领导很多时候都是拍脑袋想问题，一天N个想法，所以我们产品经理就需要仔细地评估这些目标的价值和成本，做一个可行性的评估，我们用可行性评估的结果，来告诉他们，他们的哪些想法，针对于目前的企业情况是不适合实施的，哪些想法是当下迫在眉睫的首要目标。
（2）行业知识
产品经理需要获取业务领域内的相关知识，了解行业动向，当行业内有了新的知识，或者，行业知识放生了变化，并且与需求发生矛盾时，产品经理可以利用行业知识对各种需求进行权衡。
（3）用户群体
咱们产品经理获取需求很大绝大部分都是从用户群体里面获得的。
所以我们应充分考虑不同用户群体的需求，如果只强调某一角色的需求，忽略其他角色的需求，往往将导致互联网产品的失败。产品经理应从不同用户的角度去识别、表述他们的需求。用户的文化差异、客户的组织结构，常常会是我们软件产品难以正常实施的原因。
（4）运行环境
咱们的软件产品运行环境包括地域限制、实时性要求和网络性能等。就比如阿里的支付宝体系，支付宝的业务，早已经扩展到全世界，所以说，不同的地域限制，将有可能给产品经理带来新的需求
（5）组织环境
同为一款CRM客户关系管理系统，在不同的企业，会受到组织结构、企业文化和内部政策的影响。最经典的就是最*部门的项目，因为组织环境的影响会给我们产品经理带来新的需求，往往标准化的产品也需要按照实际的情况进行个性化的定制。
需求获取的方法
获取需求常用的方法，总结如下：
（1）实地参加
通过亲身参加业务工作来了解业务活动的情况。这种方法可以比较准确地理解用户的需求，但比较耗费时间，打个比方，你们公司是做出入境通讯服务，公司要研发一款适用于ipad端的软件产品，主要是给机场门店销售人员用来办理业务的，这种情况，你作为产品经理，可以亲临第一线，实际的参与进去，亲自体验一下销售人员是如何开展工作的，他们在工作中都遇到了哪些问题，哪些问题可以减少他们的工作量，提高他们的工作效率。
（2）开调查会
我还用刚才上面提到的例子，如果公司觉得实地参加，成本比较高，浪费时间，那么你可以邀请各门店的负责人开一个需求的调查会，开会地点和开会方式都比较灵活，具体情况，需要具体分析，如果离公司比较近，那就面对面在一个办公室里面聊，如果大家离的很远，位于全国各地，那么可以通过QQ群语音的方式。大饼老师建议大家，开会之前做好准备工作，提前整理好大纲。防止出现冷场的情况。
（3）请专人介绍
这个方式就最简单了，找一个最懂公司业务的人，跟他聊一聊，做好谈话记录。记不住的话，可以录个音。
（4）面谈
一对一，或者一对多，的当面聊天，头脑风暴，大家集思广益，但是产品经理最后要做好分析，哪些点子是由价值的，哪些点子是没有价值的。
（5）设计调查表请用户填写
就是大家常听说的网络调查问卷，现在互联网时代了，线下的调查问卷没人做，都是网络调查问卷，通过微信或者QQ的方式，这种方法还可以把，效果一般般，但是易于被用户接受，大饼老师做过这样的调查问卷，做问卷调查，我使用的是，问卷星，就是一个网站，免费的，能够把你设计的问卷分享到朋友圈，微博，让用户线上答题，同时也能通过后台看到最终的调查报告，挺好用的。
（6）查阅记录
打个比方啊，你是一名产品经理，你的工作职责是负责优化迭代公司的后台管理系统，你这个时候可以先不着急做需求调研，你可以查阅与原系统有关的数据记录，统计报表啊，历史订单啊，客服反馈的问题记录啊，根据自己的经验判断一下，原产品中是否有哪些不足。这也是一种常见的需求获取的办法。
如何表达需求
最好，最有效的手段就是，利用axure，所见即所得的特点，并辅助PRD，最终清晰，生动，精准的表达需求。
老一辈的需求分析人员，他们会采用，用例建模技术，大饼老师在大学的时候，学习过用例建模的技术，曾经一度认为是最有效的系统功能需求描述方法。
当然，截止到2018年，用例建模技术，依旧有人在用，大部分是外包公司，其中做对日软件外包的公司使用，用例建模技术的比较多。
做对日软件外包的公司，大部分好像都在东北，从侧面也能看出来，东北的IT/互联网行业还是很落后的。
卡诺模型（KANO模型）
什么是卡诺模型？
卡诺模型（KANO模型） 是东京理工大学教授狩野纪昭(Noriaki Kano)发明的对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。