需求分析的过程

一问题定位
我们以一个具体实例–余额宝，这个工具类的应用来切入
用户需求分析，宽泛->细化：
需要满足三方的需求，不仅仅是Alipay用户本身
1） Alipay用户：有一个界面，能够购买基金，每天看到理财收益
2） 基金公司：展示公司基金的收益率
3） 支付宝内部：
4） 银行：充入、提现
5） 商家：支付

1. 功能需求：
   1） 数据流转：点击之后展示页面，具体有多少钱，钱的取出逻辑
   2） 金额计算：按照不同的收益方式：T+0,T+1,金额如何计算
2. 性能需求：
   1） 用户量级：千万级别还是亿万级别，能否在这么大的用户量情况下，系统正常工作
   2） 利息计算精度：利率计算到小数点后4位，每日利息计算到小数点后2位，金额的累加要准确
   3） 系统安全性：与其他模块（余额、支付）的交互是否存在漏洞，钱的安全性是否得到保障
3. 功能点划分：在确定功能性能需求后，还需根据立项的大方向，抽取不同部分功能点，划归为一类
   1） 按照交互对象划分：B2B,C2B,B2C
   2） 按照模块划分，形成一个树形的结构，大分支下又有小的分支
   3） 按照立项划分：投资、理财
4. UI需求：
   1） 确定页面内容
   2） 确定配色和风格
   二、需求分析与逻辑模型建立
   分析与综合：逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型。
   对用户的需求进行鉴别、综合和建模，清除用户需求的模糊性、歧义性和不一致性，分析系统的数据要求，为原始问题及目标软件建立逻辑模型。分析人员要将对原始问题的理解与软件开发经验结合起来，以便发现哪些要求是由于用户的片面性或短期行为所导致的不合理要求，哪些是用户尚未提出但具有真正价值的潜在需求。
   需求分析概述
   （1）确定对系统的综合要求
   虽然功能需求是对软件系统的一项基本需求，但却并不是唯一的需求，通常对软件系统有下述几方面的综合要求。
   1.功能需求2.性能需求3.可靠性和可用性需求4.出错处理需求5.接口需求6.约束
   7.逆向需求8.将来可能提出的要求
   （2）分析系统的数据要求
   为了提高可理解性，常常利用图形化工具辅助描述数据结构，如层次图。
   （3）导出系统的逻辑模型
   综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、E-R图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。
   （4）修正系统开发计划
   根据在分析过程中获得的对系统的更深入的了解，可以比较准确地估计系统的成本和进度，修正以前定制的开发计划。
   逻辑模型实例
   层次图
   层次图用来描述软件的层次结构。虽然层次图的形式和描绘数据结构的层次方框图相同，但是表现的内容不同。层次图中的一个矩形框代表一个模块。
   三、文档规格化需求-
   即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。
   作用
   1通过此文档，以保证业务需求提出者与需求分析人员、开发人员、测试人员及其也相关利益人对需求达成共识；
   2反映出用户问题的结构，可以作为软件开发工作的基础和依据；
   3作为确认测试和验收的依据；
   4保证软件开发的质量、需求的完整与可追溯性
   主要包括两部分：
   一是对项目的介绍，包括项目概述、项目价值、项目背景、用户群体、定位、名词解释等；
   二是对软件需求的详细描述，包括功能需求和非功能需求。
   下面是一份比较常见的软件需求文档结构：目录
   1.项目概述2.项目价值3.项目背景4.功能概述4.1场景描述4.2功能总表4.3业务流程图4.4 功能描述4.5 数据监控需求5.用户界面6非功能需求7.附录
   功能需求一般是由功能详情和主流程说明两大部分。功能详情是所有的产品功能的描述和规划。功能详情包括以下内容：
   简要说明：介绍此功能的用途，包括其来源或背景，解决什么问题，功能的目的。
   场景描述，产品在哪种情况下会被用户使用，就是用户场景设计。
   前置条件：该需求实现依赖的前提条件。比如，上传照片时，需要存有图像文件。
   后置条件：操作后引发的后续处理。
   主流程：把主流放在最后是有道理的，结合上面所说的，做出主流程说明，对每个功能流程走向分点说明。
   四、软件需求评审
   软件评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。
   需求审查保证用户需求在市场/产品需求文档及其相关文档中得到准确、完整、无歧义的反映，并使各类开发人员在需求理解上达成一致。
   4.1需求评审重要性
5. 与市场、产品、开发等相关人员在需求理解上认识一致，以免后期的争吵。
6. 通过需求评审，更好的理解产品的功能性与非功能性需求，为制定测试计划打下基础。
7. 确定测试目标与范围。虽然此后需求会发生变更，但能得到有效控制，降低测试风险。
   可以直观感受到需求评审的必要：
   4.2评审人员组成
   需求评审人员基础组成为技术专业人员、记录员、主持人、内审员、作者、列席人员等。
   需求评审可能涉及的具体人员包括：需方的高层管理人员、中层管理人员、具体操作人员、IT主管、采购主管；供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家等等。在这些人员中由于大家所处的立场不同，对同一个问题的看法是不相同的，有些观点是和系统的目标有关系的，有些是关系不大的，不同的观点可能形成互补的关系。
   4.3需求评审标准
   正确性、完备性、易理解性、一致性、可行性、易修改性、易测试性、易追溯性
   4.4需求评审方法
   临时评审、轮查、走查、互为评审、同行评审、审查。
   4.5需求评审技术
   评审技术通常有检查表、场景分析、头脑风暴和工具等。
   检查表是一种常用的的质量保证手段，也是正式技术评审的必要工具，评审过程往往由检查表驱动。
   1.可靠性。人们借助检查表以确认被检查对象的所有质量特征均得到满足，避免遗漏任何项目。
   2.效率。检查表归纳了所有检查要点，比起冗长的文档，使用检查表具有更高的工作效率。
   4.6需求评审过程
   首先，对产品说明书进行高级审查，找出根本性的问题、疏忽或遗漏之处。
   假设自己是客户，研究现有的标准和规范、公司惯用语和约定、行业要求、政府标准、图形用户界面、安全标准、审查和测试类似软件。
   审查产品注意：规模、复杂性、测试性、质量和可靠性、安全性。
   过高级审查了解外部因素后，其次，对需求进行更细致的测试。经常使用检查列表进行检查。对照需求和检查表，逐条检查判断
8. 找到用户的原始素材对照，包括用户提供的材料、调研记录、用户沟通记录等（完整性）
9. 检查用词问题（明确性、易理解）详细
10. 检查需求规格说明书对需求的覆盖是否准确（必要性）
11. 检查软件使用环境的描述是否清楚（完整性）
12. 检查需求编号是否正确（可修改性）
13. 检查需求是否自相矛盾（一致性）
14. 检查系统允许的输入与预期输出（可测性）
15. 检查性能是否得到清晰的描述（完整性）
16. 检查需求的关注重点和实现先后顺序是否清晰描述（优先级）
17. 检查对系统的约束是否完整描述（可测性）