记录这三年，关于项目管理上的一些心得体会 – 需求篇
对于需求，我们可以根据不同的角色、理解拆分成三个过程：
简单来说就是：
需求分析原始需求、
需求拆分为系统需求、
需求实现为功能需求
**
需求分析
**：
将客户需求 输出成 需求描述。
需求经理需要把 用户需求（User Story） 转换成 客户能够接受的 初始需求 IR（Initial Requirement）
对于用户来说，我只管提 我的原始需求是什么
需求经理要记录 用户的IR 并在输出件中标记明确 这几个点是 用户原始需求
需求拆分
有了初始需求(IR) 后，SE 就需要将 初始需求，结合自身对系统整体架构的理解，拆分成 SR（System Requirement）
意思就是说：为了满足 客户的原始需求 （IR），SE 需要把 IR 进行拆分，结合自身对系统整体架构的理解，拆分为系统所需要支持的几个大的功能点，逐一诺列
需求实现
有了 SR后，需求经理SE，根据客户需求，再结合自身系统特点，对SR 进行进一步拆分和细化，此时，对 SE就提出了较高的要求：SE需要根据 IR 和 SR ，场景化考虑每一个情况，并做详尽的 AR （Allocation Requirement）输出
此时输出的内容就是：
要么充分结合系统已有功能 明确指出哪里哪里 哪个功能的什么场景下，后端接口做扩充、前端功能做扩展
要么充分考虑用户所需内容需求，结合自己系统功能，指出，什么什么场景下，调用什么什么接口，然后成功的时候干嘛干嘛 失败的时候干嘛干嘛
上述三个步骤，大概输出件长成这样（华为内部资料，无法附件形式分享，见谅）
当然，上述这一套是华为的输出件和流程、我们也可以根据项目的特性不同，单独输出《需求功能点》、《需求规格说明书》、《原型图》，这些总结留到后面再单独总结阐述
需求变更的管理与执行
当需求存在变更的情况下，正常情况下，华为的执行顺序是这样的（华为内部称之为 CR(Change Requirement) ）：
1、交付经理 和 售前，根据客户需求，初拟《需求变更确认表》
2、然后和客户确认，表中内容是否就是客户想变更的内容
3、确认后，将表内容发回，由SE 评定工作量（其实就是白花花的银子）
4、评定完成后，将 工作量更新进入《需求变更确认表》内，和客户进行确认 和 签字
5、当客户侧的 CR完成后，SE将 最新变更内容 更新进入 需求表，进入迭代
（内部附件，无法分享出来）
需求细节点输出件
我们都知道，需求的最后澄清，不能光靠 上述的《UserStory 列表》，很多项目最后的需求澄清，是靠 传统的 SRS文档（Software Requirements Specification）。
它起到的作用是：申明清楚，有哪些硬件、哪些功能、性能要求是什么、输入输出、接口需求、警示信息、保密安全、数据与数据库、文档和法规的要求等等
而在和华为打交道的这段期间， 我接触到的新的东西：FRS（Function Requirements Specification）
它其实就是 我们传统意义上的 ：《详细设计文档》
更多的更加细致的边界限制、描述原始需求、展示对应UI图或原型图、实现逻辑，是靠FRS 来限制的，而研发除了在项目启项之初，充分吸收 User Story以外，更多的是通过 FRS 来查看 整体SE规划的实现思路是什么，调用什么接口，满足什么边界值等等
当然，更高级的项目中，原型图内，还会附带 整体系统的逻辑跳转地图（进入系统长什么样、点击这个按钮弹什么、点击这个进入哪个页面），清晰的不要不要的。
