产品经理的需求技能，包含需求获取、需求筛选、需求分析、需求执行，这一系列过程是对产品经理综合素质的一个考验和全面衡量。如：对知识的要求，对行业市场的理解和经验。
而且在这整个过程中，我们如何快速、高效的完成需求工程，也对我们有着越来越高的要求。
一、写需求的八项思路
1、合理的建立全局观，把握整体框架;
2、合理的建立业务模型;
3、合理的拆分系统需求;
4、合理的预留系统扩展;
5、合理的处理好业务流，信息流，以及数据流;
6、合理的遵从：业务原理(逻辑)”→系统实现原理(逻辑)，然后细分到-模块实现原理(逻辑)、具体到-界面交互原理(逻辑);
7、合理的编排需求的优先级次序;
8、合理的做好需求被KO掉的准备。
二、写需求的十点注意
1、写文档，一定不在拘泥于工具，在于思路;但用好工具，会使你的需求加速;
2、写文档，一定先定义流程，后定义交互原型，原型仅是需求交互的载体;
3、写文档，一定要划分好优先前后级，核心的、主要的需求先走，其它的可以缓后;
4、写文档，，一定要基于可开发，不能天马行空。(IDEA阶段可以天马行空);
5、写文档，一定要规范，目录、层级都清晰，写出来别人是要看的;
6、写文档，一定要清晰明了，不在于是否写的多，在于是否真正说明了问题;
7、写文档，一定要学习竞争者的长处，可以把好的东西借鉴过来，吸取精华;
8、写文档，一定要落实到每个细节，需求都不完善，成品何来完善;
9、写文档，一定要自己多看，自己给自己找茬，把问题止步于自己;
10、写文档，一定要注意版本管理，并做好版本修订等工作。
三、写需求的八个步骤
第一步：需求分析(业务模型、业务机制、系统功能、系统逻辑);
第二步：确定产品定义;
第三步：确定用户目标和用户任务;
第四步，确定产品具体定位;
第五步，确定设计产品用例、流程;
第六步，确定设计产品原型;
第七步，打包需求说明文档;
第八步，最后确定产品优先级(核心的、主要的、扩展的);
四、写需求的正确方法 (参考)
宗旨：通过工具—把思想有逻辑、有细节的合理的组织到一起!
1、熟悉项目发生的相关业务行为。
言下之意，就是说：我们要做的是什么项目，我们这个项目主要是做什么业务，具体业务我们怎么通过更合适的框架、平台去实现它、支撑它。简而言之的要求：
面向业务(对象)，进行业务行为(设计)，也是需求的开始，
比如：通过use case 可以很容易，很清晰的将整个业务员系统直观、规范的表达出来，按照模块建立各个package,从而将复杂的业务通过case直观的表现出来。
2、将业务，从产品层面肢解开来，做到抽丝剥茧部分与整体统一 很笼统的说，就是流程问题。
流程就是逻辑，你只有制定合理的、符合业务实际情况。符合系统实现(可实现、容易或稳定实现)的流程，才会更好支持日后的业务系统和管理系统服务实际的业务。 不管是进销存、还是SAP原理其实都是相通的。
3、把项目条目化，条理化，目录结构具体规定好。
有了上面主要的CASE和流程的保障，接下来就应该要从系统的功能方面做条目化的规划制定了。功能怎么排列，设置更符合业务的使用逻辑，怎么样让使用者更容易、直观的入手，怎么样一个很好的B/S或C/S的功能界面呈现到前台。
4、前台结构布局，合理规范的将系统脱去朦胧的华纱。
众所周知开发者和使用者是不知道这个地方应该有哪些功能，到了这一步了有哪些功能，数据提交失败有什么提示，不会使用有什么帮助或提示操作、入口。
所以做为产品人员我们要充分的考虑到上述到这些东西，对于从业人员来说这也是我们最基本的素要体现。很多人都说，要符合业务系统，要符合使用习惯，要符合浏览或人机传播，口碑，品牌形象习惯，总是就是人性化的去把这个东西设计的更合理，更易用，更有亲和。
5、穿针织网，把需求综合起来，整理成最终的产品需求文档
该做的做了，然后开始做到一个文档里，写明项目名称，把CASE/l流程、目录放近去，把项目背景、需求的各个约束、规则的界定、文字的补充说明交代清楚，同时把模块的字段，状态，对应该操作。所以模块设计的页面地址整理好，一份色香味齐全的文档就出炉了。
版权声明：本文为博主原创文章，未经博主允许不得转载。
偶尔也要现实和虚伪一点，因为不那样做的话，很难混。
