需求分析方法和实践技巧

一、需求分析的重要性

1. 需求传递过程容易失真，分析好就能尽可能的避免失真。
2. 需求分析没有分析透彻，往往南辕北撤，或者成本被层层放大；所以在需求和方案可行性多花点时间是值得的，磨刀不误砍柴工嘛。

二、理解需求

        需求的定义，需求是对问题的反应，问题是现实和理想的落差，解决客户的问题是产品进步的驱动力。如何去解决问题需要结合现实(问题的特性)和解决方案的可行性以及公司的规划(好的东西是否需要拿出来用，用了是否就拿不到钱了，哈哈哈...)。

三、需求分类和属性

1. 需求分类
   1. 功能性需求，系统提供的服务，描述了系统的输入、输出、异常。
   2. 非功能性需求，系统的质量，用户关心的属性（可靠性、易用性、规格、性能）；开发者关心的属性（可维护性、可移植性、可复用性、可测试性）。
2. 需求的属性，需求具有一些重要的属性，大部分的管理需求的活动，就是围绕需求的属性展开的。功能属性包括二重性、明确性、颗粒度，质量属性包括多维性、潜在性、演进性、时效性、易变性、关联性。
   1. 二重性，问题+解决方案，关键是要注意深挖根因；客户提出问题是希望解决自己的问题，这是提需求的根本出发点。针对问题可以有多个解决方案，但要注意解决方案的可行性和最优方案以及最简方案；需要记住的是方案是为需求服务的，更重要的是为了解决用户的问题；
   2. 明确性，需求需要清晰，包括可理解、可实施、所涉及的范畴等；需求明确是精确实现的前提。
   3. 颗粒度，需求有大小之分，大小程度称为需求的颗粒度；需求最终是需要可衡量的，表示何为大，何为小，需要有具体的数据指标。
   4. 多维性，就是可以从多个不同角度看待同一组需求。每条需求本身有具体的客户、产品与技术、所属地区等具体特征，这些都是需求分析的维度。每次分析需求都需要从一个维度去分析，分析完再从另一个维度去分析；不同维度的不具有可比性。
   5. 潜在性，也称约束性，浮于表面的“问题”都隐藏着复杂的背景，比如地域特征、行业特点、温度要求、机房空间要求、设备兼容性，这些都是背后的“故事”。潜在需求可能是客户确实需要的，但对现实环境的了解，潜意识认为不可能得到满足的需求。客户不提及，但问到时会得到肯定的答案。
   6. 演进性，随着时间的推移，问题、解决方案、需求澄清分析会越来联系紧密，最终达到融合。
   7. 时效性，需求具有一定的时间有效期，比如奥运会设计，过了奥运会，设计就失去了意义。
   8. 易变性，需求的变化（比较少见，需要客观分析）；解决方案的变化（频率很高，需要理解需求，澄清需求，做好最佳的解决方案；最好识别需求的易变部分，这部分作为可扩展）
   9. 关联性，需求的细粒度部分可能存在关联，甚至彼此矛盾

四、分析需求

1. 需求分析的定义、质量准则及流程
   1. 需求的分析定义，准确理解用户的需要，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转化到相应的形式功能规约（需求规格说明）的过程。
   2. 分析的原则，面向客户视角，和技术可行性、实现代价相结合，需求不断迭代及早确认需求。
   3. 需求分析的步骤，问题识别(手机用户需要，确定业务目标，并提出这些需求的实现条件，以及需求应该达成的标准) 》分析与综合(需求细化，，并综合系统解决方案，给出详细算法模型；需求优先级排序，以便需求落实管理) 》规格说明(需求规格说明书) 》评审确认(确保对需求达成共同的理解和认识，对需求描述的正确性完整性和清晰性，以及其它需求给与评价)
2. 需求分析的思路，愿景 》目标/原型 》特性/场景 》模块/功能 》用例
3. 需求分析的方法
   1. 场景分析法，交互过程中，从不同场景全面了解系统使用过程中可能发生的情况，把握用户真实意图；针对不同场景做好场景问题管理，建立不同场景示例。
   2. 用例分析方法，用例图是SA、SE、开发、测试、材料等团队之间常用的高效“沟通”手段；有4要素(使用者、系统、用例、action)，一个用例代表系统对外提供的一个服务；在分析用例时，需要定义好系统边界，从大的模块或子系统考虑，识别4要素；一个用例包含一到多个场景，包括主要场景和可选场景还有异常场景，还要考虑用例的前置条件和后置条件等约束条件。
   3. F-F需求分析方法，为了吸引和留住客户，对新feature的需求加大，形成了featurn驱动，以function为中心得设计方法；从需求简单分解到以功能为中心得好处有，有助于防止架构腐化(模块化，可重用，松耦合，系统简单化，特别适用于生命周期长的系统)，有利于设计责任田的形成(有利于设计人员的成长，先专注一个领域，然后逐渐成长掌握整个系统)，有利于测试设计(功能之间的分拆以及交互关系，可以设计出高效的用例)。系统特性就是卖点。
   4. UCD方法，包括UI以及UX，适用于界面交互的场景，产品设计出原型设计(基本功能)，然后逐步细化给出较详细页面设计和模型，最后强化用户的易用性；后面就可以跟踪用户使用并迭代输出。
   5. OOA需求分析方法，特征与原则，这个对于面向对象语言开发者应该很熟悉，不介绍了。

五、需求管理

        为什么要需求管理，主要需求存在不稳定、变化传达不及时、分解不充分、需求描述不准确，如此多变的需求如果都要涉及，那是很痛苦的，那么通过版本迭代，需求价值排序就显得尤为重要，这样使每次需求实现都不变杂变乱，有条不紊的持续推进，大家都高兴，问题都发到一堆，都要兼顾，那就搞不好事了。

六、引导需求

        需求并不是一成不变的，也没有完美的需求，需要理解用户的痛点，对症下药；对于不懂或好的建议要敢于提出，对于晦涩的需求要敢于质疑，不能拿到需求就做。

1. 洞察发，洞察就是对事物因果关系的观察和推演，生成具有理性理解和分析的输出结果。
2. 替代法，需求替代，有时是一剂良药。
3. 分割法，复杂需求分割为多个相对简单部分的方法。