“原始需求”概述
在软件工程术语中，“原始需求”并不是个常见的说法。
定义：原始需求是由用户或者用户代表提出的功能或性能需求或其他非功能需求，需求可以未经总结或提取。
目的：原始需求调查和管理的主要任务在于收集需求素材，并保证经认可的原始需求获得了实现。
原始需求的来龙去脉
流程规定
根据产品规划，产品经理划定需求提供者的范围，这个范围一般为顾客，最终用户，开发人员，生产人员，测试人员，供货商，营销人员，维护人员，和其它相关人员，要把潜在客户划分出来，这类客户是指当前还没有采购本部门任何产品的客户。
通过各种方式，产品经理收集原始需求，录入，要把需求提供者信息与其提供的原始需求一起记录。
产品经理或项目组将原始需求录入，初始状态是"已建议"，原始需求编号是自动生成的流水号；
要求将所有原始需求录入。如果原始需求为其他项目组定制，则须注明其他项目组名称和相关的交付包。
产品经理根据项目组讨论和自身判断，针对录入的原始需求，处理是否采纳此原始需求，如果采纳，原始需求的状态是"活动的"，如果拒绝，状态是"已关闭"。如果一个原始需求是由潜在客户提出的，则一般要求是由两个或两个以上的潜在客户提出，或得到其它需求提供者的佐证，才能被采纳。如果某原始需求只由一个潜在客户提出，且得不到佐证，不建议采纳。
当项目组认为原始需求得到满足之后，将原始需求状态置为 "已解决"，此时至少要有一个功能点或者需求用例和这个原始需求对应，否则不允许改变状态。
原始需求"已解决"之后，产品经理或产品经理的授权代理人参考测试报告，并通过功能展示逐条评审原始需求的完成情况，如果符合，进行"已关闭"操作，原始需求的状态变为"已关闭"，否则把状态改回"活动的"，要求项目组重新实现原始需求。
原始需求采纳标准
必须条件
- 语法通顺，表述清楚，没有歧义；
- 需求的范围已经明确说明或可以推断是有限的，可控的；
- 此需求必定存在至少一种用户场合是适用的；
- 此需求描述的是产品本身，而不是开发产品的某个过程；
- 此需求不包含设计实现的内容；
- 此需求不存在重复的需求，即没有冗余；
- 此需求不是发现的缺陷；
- 推测此需求的技术实现在项目当前限制范围之内是可行的。
推荐条件
- 需求来自2个或2个以上来源；
- 需求是场景化描述的；
- 需求是付款用户提出的；
- 需求是竞争对手产品的卖点；
- 提出需求的用户有行业前景，比如海关，公安，税务等等；
- 已经有明确的性能需求。
- 满足推荐条件越多，优先级越高。
原始需求核心要求
原始需求最核心的要求不在于已经采纳的原始需求，恰恰在于被拒绝的原始需求。只有知道了哪些原始需求被拒绝了或者延迟了，才能相信所采纳的原始需求是真正要做的。
只记录经过选择采纳了的原始需求的做法只能保证这些原始需求得到实现，不能保证恰当的、合适的原始需求得到了采纳。而原始需求最关键的地方在于如何寻找最恰当的原始需求，其次才是实现原始需求。
因此，原始需求应当全面的记录来自于各方对产品的要求，无论这个要求是否可行，是否合理，是否要做，是否优先。
在记录时，为了不影响后续人员的判断，要尽量传递用户的真实意思，采用用户的语言，保持“原始”。
以产品经理、项目经理为首的产品开发相关人员应当第1时间记录原始需求，积累好原始需求，当要选择做的时候，再来做谨慎的选择。
只有全面的收集记录的原始需求，才能有产品全面的判断和选择，进而开发出受到客户欢迎的产品。
原始需求收集卡格式
本模板在格式上有以下一系列约定：
- 用“< >”括起来的内容，是编写指导，在使用本模板编制的文档中应予以删除或去掉“< >”后予以适当沿用。
- 如果某章节内容无需填写，而且本模板又没有特殊要求或说明，则在该章节下写“无”，而不要将该章节删除或不填写任何内容（即留白。留白将使评审员或读者无法判断：是本章节内容无需填写还是因为疏忽而忘了填写？）。
在使用时，建议打印出本模板的最后一页（称之为卡片），需求收集人使用卡片记录收集结果。
模板修改记录
作者 日期 修改理由 主要修改内容 --- ------- ---- -------- -----------
需求编号：
<用于唯一识别本需求，采用分级编码的方式。规则为“RR-XXXX-nnnn”，其中，“RR”为固定前缀，代表“原始需求”。半角减号“-”为连接符。“nnnn”为流水号。“XXXX”为某种类别符，可以省略，变成“RR-nnnn”。格式：直接接在“需求标识：”后写，下同。>
需求名称：
<用一句话概述本需求将要做什么。一般采用动宾结构。>
目的：
<描述为何要实现本需求，可以从“实现后的价值”、“不实现的损失”等角度描述。如“解决XX问题”、“任何时候都能XXX”等等。对应于某些同类文档中的“需求的优点”。如果是普遍的目的或不言自明，则可以填写“不关心”。2.0新增字段，很重要，对需求取舍有重要影响。>
<例如：
- 实现负荷均衡，增强整个系统的稳定性和可靠性。
- 减少硬件资源。>
需求描述：
<描述本需求将要做什么。如有对协议/标准/规范等的引用，应在此处列出协议/标准/规范等的名称、篇/章节号。>
应用场合：
<描述在什么情况下需要用到本需求。实践中本字段经常被误称为“应用场景”（所谓场景，是指“实体与环境的交互序列”。而此处，是指本需求在什么场合下被使用）。如果不是特别场合，则可以填写“不关心”。2.0新增字段，很重要，对需求取舍有重要影响>
使用频度：
<可选。描述本需求被使用的频繁程度，可根据产品的实际情况取值，如“经常”、“偶尔”、“不关心”或“高”、“中”、“低”、“不关心”等。>
期望完成时间：
<描述本需求最晚的交付时间。该域是需求论证时确定优先级的一个重要依据。一般不直接给出某个具体的时间点（如果在正式的文本中已经确定了交付时间，则应明确列出。格式为YYYY/MM/DD），推荐使用“第一个版本”、“第二个版本”等。默认为“第一个版本”。>
特殊需求：
<描述与本需求密切相关的其它属性，如性能、质量属性、成本、体积、重量、功率、冷却、制造、服务、环境（特殊的温度、湿度、压力、照明、振动、辐射、声、光、电等）、地理、民族语言文化特点、宗教、风俗习惯（包括与本需求相关的好恶等）、法律、法规、经济发展状况等。格式：应使用简短的语句分段描述，一段只描述一种属性。>
市场状况：
<描述竞争对手的实现情况、用户对本需求的评价（如“必须提供”、“允许替代”、“无所谓”）等。格式：应使用简短的语句分段描述，一段只描述一条信息。>
需求来源：
<描述需求来源信息，以方便后续需求开发工作的开展。可以选择的需求来源有：与用户交流、竞争对手产品分析、我司产品分析、市场调查、市场预测与分析、开局与维护、工作中的思考、协议/标准/规范、其它。>
注释和问题：
<描述需求的可能演进（进一步发展及变化）、当前已经发现的相关问题、进一步工作需要注意的事项、本需求依赖哪些其它需求（只有实现了这些需求，本需求才能实现）、对设计方案的建议等，也可以介绍需求相关的某些概念、术语、定义等。格式为：应使用简短的语句分段描述，一段只描述一个问题。>
联系人：
<描述需求联系人信息，以方便后续需求开发工作的开展。主要描述：人名、电话、eMail、职务、单位等。格式：“联系人：XX；电话；eMail；职务；单位”。>
收集日期：
<描述需求收集日期。格式为：YYYY/MM/DD>
网友评论