新增功能、功能改进、体验提升、BUG修复、内部需求等。
(我们公司主要是按需求来源划分的需求类型,业务需求、UI优化、QA优化、技术优化、产品优化、用户建议,和需求来源整合在一起,属于需求来源的一部分)
此需求添加到需求池的时间,而不是需求提出人初次提出的时间。目的统计需求明确到需求上线的周期。
需求池中的需求优先级可以用高、中、低来初步进行确定哪个需求的优先级更高。通过需求评审后的需求,优先级更应该按照1、2、3、4的顺序进行排列。假设用高、中、低来确认需求优先级,会存在什么问题呢?当确定下个版本上线5个功能点(其中2个高、2个中、1个低),由于开发进度和开发资源的问题,5个功能点中只能如期上线3个功能点,那么就需要考虑在2个中的需求中先上线哪个?这样的话,前期按照高、中、低来评审需求优先级就存在不严谨性。
待讨论、暂缓、拒绝、已明确。已明确的需求基本上下一步就是进行版本规划了,这时候需要重新评估需求优先级(用1、2、3、4数字标识),定哪个版本上线、版本啥时候发布。
其他任何信息,如:需求期望完成时间、被拒绝原因、暂缓原因。