写需求规格说明书/产品定义的个人总结

产品定义与需求规格说明书的区别

1、产品定义：主要用于指导产品框架的搭建，通常用于领导决策是否需要投入人员进行后续开发；
通常侧重业务逻辑描述、产品规划的思路描述；
不侧重界面实现、细节业务逻辑；
2、需求规格说明书：主要用于指导开发团队进行开发，实现最终系统；
通常侧重每个业务细节，尤其是数据流是否闭环、业务逻辑是否清晰一致、团队之间理解是否达成一致等，但需求文档的颗粒度和公司的管理模式、团队的合作模式有很大关系。
情景1：需求交底通过原型进行沟通，主要的业务逻辑需求文档写清楚即可，细节内容可通过原型批注或文档后补的形式完成。
情景2：需求交底通过文档进行沟通，则要求将交底的内容写得做清楚或沟通的足够清楚，后续在文档中进行补充。
情景3：迭代式开发，则只需要将文档中每次迭代的内容写清楚或者原型绘制清楚，团队之前能够达成一致即可。

产品定义规范

1、产品定义通常偏向业务角度的描述，通过怎样的解决方案解决用户的哪些痛点；一般辅助产品规划文档一起评审。
2、产品定义是整个产品的核心框架，大的业务逻辑一定要和多方领导进行明确沟通，开发技术人员若能提前沟通也能减少后期很多沟通问题。
3、产品定义的输出对象一定要明确，是给谁看的，才能明确文档写得颗粒度是怎样的，毕竟不同公司的模式可能有所差异。

需求规格说明书规范

1、需求文档通常是用于指导开发的，所以一定要尽可能的想清楚业务细节，若无法想清楚也可以多沟通交流，毕竟很难做到一次性完成所有业务细节的设计。
2、需求文档中一般涉及业务框架图、业务流程图、数据流程图、用例图等等。
特别注意，用例图和用户角色相关，一定要明确每个用例的参与角色。
3、需求文档一定要明确用户类型、用户角色，不同用户角色需求不同。
4、需求文档中的数据流、业务流程图一定要绘制，这样能让你有个清晰的整体认识。
5、个人建议不要上来就写文档，建议先拿原型图去绘制整个系统，原型不用细纠UI效果、交互等问题，只要能快速把自己的业务逻辑穿清楚即可，当然如果时间充足或者公司规章制度要求，可以多花时间思考业务，再通过绘制原型图去验证自己的业务或者梳理自己的业务，最后通过写文档再查漏补缺。