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

品 3 上告 互联网产品维护性需求分析工作总结报告 徐琳 南京大学”软件学院 软件工程专业 WP1332026 1 项目需求工作介绍 我服务的项目是运营了十几年的 B28 网站的维护性需求需求分析工作分为两种: 一是老功能的维护， 而是相对应用独立的新功能的开发。相较全新项目而寺，维护性项目的更容易界定项目范围，功能点小， 但功能上线时间点紧、示求规则更加细致 近期项目第了一个买家积分体系的项目，主要是针对买家会员给予积分奖励，目的是提升网站买家活 斤度和芭性。 1.1 项目需求分析 项目需求分析工作流如下 三吾 6。 需求获取，本需求来源于产品部的规划 (2 青束分析，对表示进行业务建模，分析出的几间进行反复确认，最终划分出入求编写的用例 和页面:  (3 需求编写，对需求进行拆分细化形成需求规格说明节。有统一的需求模板，琐求模版中包含 青景、目的、功能涉及范围、建模、用例点、页面和非功能性需求。由于互诺网产品的特殊 性，不仅对功能规则有要求，对页面的用户体验同样重要，所以需求编写一般是按照用例和 页面两个维度编写 《4) 需求验收，需求提出者、开发人员和测试人员都有权评审俩求，并反馈意见，评估出合理意 见将进行需求变更; 《5) 需求归档，需求上线后，将需求内容以用例和页面为单位归入至需求库中，并做好归档记录.。 1.2 项目需求管理 除了项目需求开发的工作，平时还要做需求管理工作，可能不一定以单个项目为单位- (1) 需求基线，在项目需求验收阶段，当需求相关人员对需求做出确认后，需求将形成基线。形成 基线的需求将建立任务，并投入开发。 基线标识一一版本号:需求基线前，每一版需求编号从 0. 1 开始累加不能超过 0.9，需求确认后，不 管之前是什么版本涯求版本号改为 1.0 形成基线。 基线影响一一需求基线的形成不仅受制于相关人员的评审确认时间，还受限于项目计划时间。刚开始 分析时会制定需求分析时间，此时间的结束点以基线完成时间为准，对超过计划时间的需求需要做延期处 理- 52) 需求变更。 在需求基线形成后如果有任何人员提出修改意见，评估通过后则需求变更 需求变更记录: 需求变更原因、需求变更内容、变更提出人、变更确认人、和需求变更时间等供 QA 分 析用。  《3) 需求归踪，功能开发、测试完成后，示求人员对功能进行验证，提出问题解决后才可发布上线. 至此项目需求工作算是完成了! 2 项目需求工作优缺点 项目需求工作的优点比较明显的是体现的宏观上 人”有和需求工程的思想，对流程的制定和把握比较到位; 介”采用统一的需求模板且细分到用例点和页面的层次，迷度一致。易于管理 缺点主要体现在执行过程和方式的问题 个”需求获取的过程不是真正地需求获取，需求是经过产品经理处理之后转给需求人员，需求分析人 员缺失了真实数据调研和分析的基础，不利于需求人员对最优解决方案的制定 介。 需求分析计划时间的估算没有一个标准，常常依靠需求人员经验和项目进度拍肪袋决定 个”需求入写出的文档可读性不襄，由于采用统一的用例和页面的维度，对于维护需求，当出现一个 规则在多个用例中出现时，需要将多个用例一起列出《篇幅很长)，降低了读者的阅读效率 个需求归档无自动化工具，纯手工出档工作量大、过程复杂且会存在部分中油的情况 个 震求本身需求需求变更的跟踪分析较为缺乏，此项工作全赁震求人员自觉且无专业指导 3 经验总结 对于做自己公司的产品，新项目总是少的，新项目最终也要进入维护阶段，且维护的时间常党远大于