原始需求收集卡片模板

<

模板修改记录

版本 作者 日期 修改理由 主要修改内容

本模板在格式上有以下一系列约定：

a) 用“< >”括起来的内容，是编写指导，在使用本模板编制的文档中应予以删除或

去掉“< >”后予以适当沿用。

b) 如果某章节内容无需填写，而且本模板又没有特殊要求或说明，则在该章节下写

“无”，而不要将该章节删除或不填写任何内容（即留白。留白将使评审员或读者无法判断：是本章节内容无需填写还是因为疏忽而忘了填写？）。

在使用时，建议打印出本模板的最后一页（称之为卡片），需求收集人使用卡片记录收集结果。 >

1

需求编号：<用于唯一识别本需求，采用分级编码的方式。规则为“RR-XXXX-nnnn”，其中，“RR”为固定前缀，代表“原始需求”。半角减号“-”为连接符。“nnnn”为流水号。“XXXX”为某种类别符，可以省略，变成“RR-nnnn”。格式：直接接在“需求标识：”后写，下同。>

需求名称：<用一句话概述本需求将要做什么。一般采用动宾结构。>

目的：<描述为何要实现本需求，可以从“实现后的价值”、“不实现的损失”等角度描述。如“解决XX问题”、“任何时候都能XXX”等等。对应于某些同类文档中的“需求的优点”。如果是普遍的目的或不言自明，则可以填写“不关心”。2.0新增字段，很重要，对需求取舍有重要影响>

<目的：

a) 实现负荷均衡，增强整个系统的稳定性和可靠性。 b) 减少硬件资源。 >

需求描述：<描述本需求将要做什么。如有对协议/标准/规范等的引用，应在此处列出协议/标准/规范等的名称、篇/章节号。>

应用场合：<描述在什么情况下需要用到本需求。实践中本字段经常被误称为“应用场景”（所谓场景，是指“实体与环境的交互序列”。而此处，是指本需求在什么场合下被使用）。如果不是特别场合，则可以填写“不关心”。2.0新增字段，很重要，对需求取舍有重要影响>

<应用场合： >

使用频度：<可选。描述本需求被使用的频繁程度，可根据产品的实际情况取值，如“经常”、“偶尔”、“不关心”或“高”、“中”、“低”、“不关心”等。>

期望完成时间：<描述本需求最晚的交付时间。该域是需求论证时确定优先级的一个重要依据。一般不直接给出某个具体的时间点（如果在正式的文本中已经确定了交付时间，则应明确列出。格式为YYYY/MM/DD），推荐使用“第一个版本”、“第二个版本”等。默认为“第一个版本”。>

特殊需求：<描述与本需求密切相关的其它属性，如性能、质量属性、成本、体积、重量、功率、冷却、制造、服务、环境（特殊的温度、湿度、压力、照明、振动、辐射、声、光、电等）、地理、民族语言文化特点、宗教、风俗习惯（包括与本需求相关的好恶等）、法律、法规、经济发展状况等。格式：应使用简短的语句分段描述，一段只描述一种属性。>

市场状况：<描述竞争对手的实现情况、用户对本需求的评价（如“必须提供”、“允许替代”、“无所谓”）等。格式：应使用简短的语句分段描述，一段只描述一条信息。>

需求来源：<描述需求来源信息，以方便后续需求开发工作的开展。可以选择的需求来源有：与用户交流、竞争对手产品分析、我司产品分析、市场调查、市场预测与分析、开局与维护、工作中的思考、协议/标准/规范、其它。>

注释和问题：<描述需求的可能演进（进一步发展及变化）、当前已经发现的相关问题、进一步工作需要注意的事项、本需求依赖哪些其它需求（只有实现了这些需求，本需求才能

2

实现）、对设计方案的建议等，也可以介绍需求相关的某些概念、术语、定义等。格式为：应使用简短的语句分段描述，一段只描述一个问题。>

<注释和问题： >

联系人：<描述需求联系人信息，以方便后续需求开发工作的开展。主要描述：人名、电话、eMail、职务、单位等。格式：“联系人：XX；电话；eMail；职务；单位”。>

收集日期：<描述需求收集日期。格式为：YYYY/MM/DD>

3

需求标识：RR- 需求名称： 目的：

需求描述：

应用场合：

使用频度：高、中、低、不关心。<请选择>

期望完成时间： <一般填写“第一个版本”、“第二个版本”等，如为具体时间，则格式为YYYY/MM/DD。>

特殊需求：

市场状况： 竞争对手实现情况：

用户对本需求的评价：<可为“必须提供”、“允许替代”、“无所谓”，并描述其原因>

需求来源：与用户交流、竞争对手产品分析、我司产品分析、市场调查、市场预测与分析、开局与维护、工作中的思考、协议/标准/规范、其它。<请选择>

注释和问题：

联系人： < XX；电话；eMail；职务；单位>

收集日期：

4