收集需求是产品经理的基本工作；对初入行的产品经理来说，收集需求甚至是核心工作。那么，怎样才能把收集需求这项工作做好呢？
实际工作中，如果放任需求方提需求，则提上来的需求有时是一句话，有时是一张图，有时是一段录音，信息缺失常常特别严重。
若将这些信息作为需求收集起来，没有任何意义。信息严重不足的需求，产品经理无法进行需求分析，从而对需求做出判断。产品经理还得一个一个重新跟需求方沟通，不如不做。
因此，想做好需求收集工作，就需对提交的信息有一定的要求，来确保核心信息的完整性。有了这个要求，即使由于一些原因，需求提交者无法按要求提交（比如老板安排，就可能无法要求对方填个表），产品经理自己也可以通过沟通了解清楚相应的信息。
那么，一个提交上来的需求，需要包含哪些核心信息呢？
个人认为，一个需求至少要有这些核心信息。
每个信息项都有其相应的作用，下面是简单的解释。
需求提交者：知道是谁提交的，在需求不清楚的时候，能找到对应的人进行深入沟通。
提交日期：便于产品经理进行统计。同时，与期望完成日期对照，也便于产品经理了解需求的紧急性。
期望完成日期：可以帮助产品经理了解提交者的心理预期。
所在部门：需求提交者所在部门不同，对需求描述的倾向性会有所不同。了解提交者的部门，对后续需求判断会很有帮助。
优先级：优先级可以帮助产品了解此需求在提交者心中的重要程度。简单地分为高中低就好。更细致的划分，多数人区分不出来。
用户：每个需求一定有其用户。可以是某类用户，也可以是某个具体用户。若是某个具体用户或代表性用户，最好能够获取到对方的联系方式，以便于有需要时进行更深入的沟通。
场景：在场景中，需要告知用户在什么时候、什么地方、因为什么、做了什么事儿。可以说，这是需求的核心。描述的越细致越好。
问题：在上述场景下，用户遇到了什么困难/问题？是想做某事发现做不了，还是能做发现操作不便，还是做了但是没成功？描述的越详细越好。
当前解决方案：遇到问题/困难后，用户是怎么解决的？有可能，需求的解决方案就蕴藏在用户的解决思路或方案中。
希望解决方案：虽然，多数时候，用户给不出很好的解决方案，但了解对方的想法，能给产品经理提供不同的思路。
覆盖范围：有这个需求的人有多少？需求覆盖的用户范围不同，优先级会有不同。影响10个人和影响10万人，优先级绝对不是一个档次。
发生频次：这个需求发生的频次是多少？低频需求和高频需求，解决方案上会有很大的不同。高频需求要尽可能地提升效率和体验，低频需求可能就可以适当放宽。
当前方案耗时：如果当前解决方案可行，完成一次任务要花多少时间？对于提升效率的需求来说，当前方案的完成时间至关重要，是后续判断新方案是否有效的重要参照。
备注：若有需要补充信息，则可填写到备注中。
