需求分析
需求分析的过程，大部分是客户无感知的，只能体现在最终的输出物中。
总纲
我个人认为主要分为产品（含PaaS）、业务和报表三块。
产品需要考虑：
- 现有的PaaS配置能力
- 标准产品逻辑（标准产品已有能力要补充到需求规格中）
- 公共需求的抽象（分页、导入导出等）
业务需要考虑：
- 流程和分支节点
- 事件触发（时间or操作）
- 特殊字段维护（如订单类型，是通用字典维护，还是专用页面维护，或者写入数据库不提供UI界面维护，甚至直接代码写死）
报表需要考虑：
- 周期（日报、周报、月报）
- 样式（动态列头？）
- 明细流水
- 统计抽取
- 历史数据处理
- 性能
功能清单
在需求分析过程中，有很重要的一个点，就是给需求排优先级，尝试切分部分需求。这个在立项时候甲乙双方就有约定，但调研过程往往有变数。所以需要基于调研情况，重新排优先级，切分阶段。
一般都会分成两期上，一期先上某个渠道，搭建好基础。需求的优先级，基本上对内不对外。即便一期的内容，乙方内部也是要排优先级的。每一期的功能清单，都不包含优先级。最终计划怎么排，哪些功能可以如期上，乙方内部要心里有数。
最终输出功能清单是全量的，一般附带在需求规格中。但是会加上标注，区分每一期的内容。这个功能清单基本是页面级别的，颗粒度比较粗。
业务解决方案
售前阶段已有解决方案，是比较靠近标准产品和行业的。而业务解决方案则是落地，贴近企业实务。基本上，是调研汇报内容的总结和升华。
部分项目中，这个由项目经理编写，产品做辅助支撑。产品需要提供各个业务的流程图和设计原型，匹配业务诉求。
另外部分重点项目，这个由产品独立解决。这种方案有点偏咨询，除了本次调研的业务还涉及其他的相关系统。要基于行业营销信息化的认知，去构建大营销系统的蓝图。所以什么AI、数据中台，统统都上。
原型验证
原型验证基本上是和业务解决方案同时开始的，业务解决方案中包含重点业务的原型图。一旦业务解决方案得到认可，就开始细致的原型验证阶段。这个阶段客户会开始看UE，原型的改动非常多。
举个例子，B端是非常喜欢单据式布局的。一方面是使用习惯，另一方面是单据布局直观紧凑。尤其是APP端，经常出现客户选择表格布局替代卡片布局的情况。
需求规格说明书
CMMI的定义中，交付物包含用户需求规格说明书和产品需求规格说明书。实际项目中的需求规格说明书，基本上是用户需求规格说明书。这是常态，只有基于业务的描述才能和甲方进行确认。但很多研发是没有业务背景的，看这份用户需求很难直接进行概要设计。基于成本考虑，部分细节会一并在这份用户需求规格上。
所以，我们看到的项目的需求规格，大部分时候是四不像的大杂烩。一般包含：用户需求规格说明书+字段细分说明（部分会省略）+接口说明+状态流程说明（审批流、订单业务流等）。却又缺少了关键的需求建模信息（主要是领域建模），研发要频繁的找产品问业务，才能进行概要设计。
项目的需求规格，基本上是和原型同步启动的。但我个人建议是原型验证后，再贴原型图。最好文档基本确认完成，再贴原型图。期间原型图可以生成html打包，邮件给甲方查阅。不这么做，就是以下的情况：
- 以会议纪要的形式记录改动点，晚上回去后要先原型。原型改好要截图，贴到PRD。但经常出现，原型图和PRD字段不匹配。
- 以屏幕扩展的方式投屏，客户要修改的，现场标记或者改好。回去匆忙改原型，准备后面的原型验证。后面再补PRD，很容易造成遗漏（因为是密集的原型验证，这期间客户不看PRD，导致PRD和原型脱节）。
- 原型验证完成，开始评审PRD。开启审阅+批注后，打开和保存文档不是一般的卡
补充说明：
产品需求规格中，需求建模主要包含用例图（内部WBS拆解够细，可不出）、类图（可简化为ER图）、序列图（可简化为活动图）、状态图。以订单领域为例：
- 用例图，订单的所有用例，如查看查询、新增、编辑、导入、导出、审核、发货、收货
- 类图，订单类的成员名和字段类型乃至长度，以及审批单、发货单、送货单、收货单等附属单据信息。
- 序列图，订单的全流转过程。
- 状态图，订单的先后状态和触发状态变更的操作
