互联网产品维护性需求分析.docVIP

互联网产品维护性需求分析工作总结报告 徐琳 南京大学 软件学院 软件工程专业 MP1332026 项目需求工作介绍 我服务的项目是运营了十几年的B2B网站的维护性需求，需求分析工作分为两种：一是老功能的维护，而是相对应用独立的新功能的开发。相较全新项目而言，维护性项目的更容易界定项目范围，功能点小，但功能上线时间点紧、需求规则更加细致。 近期项目做了一个买家积分体系的项目，主要是针对买家会员给予积分奖励，目的是提升网站买家活跃度和黏性。 项目需求分析 项目需求分析工作流如下： 需求获取：本需求来源于产品部的规划； 需求分析：对需求进行业务建模。分析出的疑问进行反复确认，最终划分出需求编写的用例和页面； 需求编写：对需求进行拆分细化形成需求规格说明书。有统一的需求模板，需求模版中包含背景、目的、功能涉及范围、建模、用例点、页面和非功能性需求。由于互联网产品的特殊性，不仅对功能规则有要求，对页面的用户体验同样重要，所以需求编写一般是按照用例和页面两个维度编写； 需求验收：需求提出者、开发人员和测试人员都有权评审需求，并反馈意见，评估出合理意见将进行需求变更； 需求归档：需求上线后，将需求内容以用例和页面为单位归档至需求库中，并做好归档记录。 项目需求管理 除了项目需求开发的工作，平时还要做需求管理工作，可能不一定以单个项目为单位。 （1）需求基线：在项目需求验收阶段，当需求相关人员对需求做出确认后，需求将形成基线。形成基线的需求将建立任务，并投入开发。 基线标识——版本号：需求基线前，每一版需求编号从0.1开始累加不能超过0.9，需求确认后，不管之前是什么版本需求版本号改为1.0形成基线。 基线影响——需求基线的形成不仅受制于相关人员的评审确认时间，还受限于项目计划时间。刚开始分析时会制定需求分析时间，此时间的结束点以基线完成时间为准，对超过计划时间的需求需要做延期处理。 （2）需求变更：在需求基线形成后如果有任何人员提出修改意见，评估通过后则需求变更。 需求变更记录：需求变更原因、需求变更内容、变更提出人、变更确认人、需求变更时间等供QA分析用。 （3）需求跟踪：功能开发、测试完成后，需求人员对功能进行验证，提出问题解决后才可发布上线。 至此项目需求工作算是完成了！ 项目需求工作优缺点 项目需求工作的优点比较明显的是体现的宏观上 有需求工程的思想，对流程的制定和把握比较到位； 采用统一的需求模板且细分到用例点和页面的层次，粒度一致、易于管理 缺点主要体现在执行过程和方式的问题 需求获取的过程不是真正地需求获取，需求是经过产品经理处理之后转给需求人员，需求分析人员缺失了真实数据调研和分析的基础，不利于需求人员对最优解决方案的制定 需求分析计划时间的估算没有一个标准，常常依靠需求人员经验和项目进度拍脑袋决定 需求编写出的文档可读性不高，由于采用统一的用例和页面的维度，对于维护需求，当出现一个规则在多个用例中出现时，需要将多个用例一起列出（篇幅很长），降低了读者的阅读效率 需求归档无自动化工具，纯手工出档工作量大、过程复杂且会存在部分遗漏的情况 需求本身需求需求变更的跟踪分析较为缺乏，此项工作全凭需求人员自觉且无专业指导 经验总结 对于做自己公司的产品，新项目总是少的，新项目最终也要进入维护阶段，且维护的时间常常远大于线项目的时间，所以学习做维护项目更重要。下面是几点做维护项目的总结 （1）项目开始阶段，需求范围尽早明确。这对新项目和维护项目都很重要。例如，上个积分体系项目中，我将原先系统一个长期不使用的小功能给删除了，尽管需求有做确认并讲解，但是用户仍然忽略或者当时没有评估出这个功能取消后的影响，造成功能上线时用户又说要用，强烈要求恢复被取消功能。但难说这个责任在谁，但事实却不仅造成用户体验上的不好也让浪费了研发的工作量。 （2）需求变更的控制，需求变更不是坏事，如果一次变更能对效果有很大的纠正与提高，那就是值得并且应该去做的变更。但是需求人员常常也会犯些完美主义的毛病，都希望自己负责的项目功能是完善的，可是没有完善的功能，只能时刻提醒自己要在项目进度和功能完善之间找平衡点。或者有些不重要的功能体验可以规划二期来实现。 （3）项目结束后的经验总结。目前对于项目好的、坏的都没有什么提高和规避，对每个项目总结，将出现问题的地方拿出来讨论，达成共识，做下一步的改进计划和改进措施。 存在困难 需求获取常常来源于外部，而且这个工作职能有人工来处理，不同经验背景的需求人员可能获取到的信号时不一样的，所以获取需求本身就很困难。 知识领域的全面性，功能不仅仅决定于业务领域还常常受限于技术实现，如果需求人员不懂技术或业务，那需求变更便会经常发生。 需求管理过程工具的使用较少，目前的需求归档没有标准，都是人工处理，造成项目需求