需求分析心得

category: 需求分析。

用户故事贯穿于需求分析、开发、测试、验收，用户故事至关重要，用户故事提倡大家共同编写

分析时要充分去想象分析出来的结果，在脑子中全面模拟使用一下看有没有什么问题，该说明的一定要详细说明

不管是什么问题，我们都应该能够经过仔细分析，得出相对比较好的答案，然后可以跟用户确认（确认的时候，如果用户有疑问，我们也会因为经过了仔细分析而可以努力说服用户让用户理解并支持这个决策），而不能等待用户去决策

根据目标去检查或复查需求分析结果是否通过（指出哪些目标不能很好满足即可），同时分析也是要紧紧围绕目标展开

需求分析不是功能特性越多越好，而是应该紧紧围绕需要解决的核心问题，找到精简的方案快速高效地解决，时机不成熟或模棱两可的功能尽量不要提前分析进去（每次迭代都用最精简的方法实现肯定需要且成熟的功能），当思绪开始发散延伸时要及时回到需求解决的问题

分析的时候可以向用户要一些相关数据便于分析

需求分析一般需要画 rose 中的三种图：用例图（表达系统有哪些用户及各用户可以使用哪些功能）、活**（表达主要业务流程）、状态图（详细表达各状态之间跳转关系）

从职位上看，职位越高，在系统中做得事情越少，在分析时要注意是否符合了这个原则

用户提出的需求往往包含两部分内容，在分析时需要分析出来：一部分是用户希望解决的问题，另一部分是用户想到的解决方案，其中第一部分必须分析出来，然后才能去考虑第二部分（用户的解决方案是否合适，是否要考虑更周全的解决方案）

涉及到修改已有数据的界面中，建议增加“重置”按钮

在查询界面中，可以增加“重置”按钮来恢复到默认查询条件

可以在分析过程中及时进行需求总结，这样等分析完后很多业务点就整理出来了，便于开发与测试（最好是边分析边总结在 mindmanager 文档中，同时制作 ppt 时将注意事项写上）

在开发过程中，分析人员需要对正在开发的需求进行更深入的细化，有些还需要与用户进行讨论，并且在论坛上将讨论历史与结果进行记录，有更新时及时提醒相关人员

能否把需求分析做得很好（其它角色也一样），根本在于你要完全用心，像做艺术品一样对待，像培养自已的孩子一样去做

系统需要提供清晰简洁的功能入口，并且尽可能多的途径

慎重考虑是否提供删除功能，一般情况下使用人对删除都有种恐惧感，因为删除后什么东西都没了，很危险，因此一般不敢使用，因此建议提供类似作废之类的功能

开。始分析前需要先明确系统或模块需要提供的功能（用例图），根据它去检查分析是否能够满足这些功能要求

需求分析文档（mindmanager）和业务原型文档（ppt）最好是同步出，这样便于用户确认以及项目经理审核

检查需求分析时，重点指出是否有哪些业务点未满足，或者业务点分析得不合理

需求分析人员应该花时间去学习软件界面设计（怎么样的界面是简洁、易用的）

分析中最重要的是花很多时间从多种角度（业务流程、易用性、管理、人员培养、工作效率。去仔细地思考、分析，将思考过程中的问题或重点记录下来并努力去攻克；对于已经分析出来的结果，不断地进行自我否定，这样才能够不断地推动分析往更完美的方向发展

对于业务流程比较复杂的需要有一份完整周全的状态图（用 rose 或 visio 中的 uml 状态图），状态理清理全后，从大方向上就能够保证系统符合业务要求，状态或流程要很清晰并且不断优化

状态之间的流转需要考虑到调整或修改的情况（有可能是因为操作失误，或者调整了流程）

对于状态之间的跳转，一般对于管理者应该可以很灵活地调整到任何一个状态（管理本身就会碰到意外或未知的业务或流程，这里的状态调整不能限制死）

状态图中需要依次考虑各状态是否可以跳到其它状态及自身状态，全部考虑完后，整个流程基本上清楚完整了，而且在开发的时候就很容易决定工具栏按钮是否启用

有时候需要从某些人是否会成为瓶颈的角度去判断某些状态是否会多余

分析中很重要的一个工作是把原来有很多功能的需求，合理地拆分到合理的功能模块，或者放到合理的阶段去实施

有时候按角色去组织功能模块可能会更易于使用

功能模块的切分的时候尽量要保证胖瘦合理，太胖太瘦都不美

如果it系统把所有工作都做到，可能要花费很大的成本（时间、人力、费用等），分析时候要把握一下，哪些让it系统去做，哪些人工去做

对于一些需求，如果做到系统中，会增加系统的复杂度，但使用价值又不高，那么尽量选择暂时不加到系统（只是说暂时不做，不代表永远不做）