XXXX单项需求卡片
单项需求卡片模板
描述（What）（最重结构，不要加入主观的修饰语句
原因（Why）（需求人员要保持怀疑的心，很多时候理由是假想出来的）
为什么会有这样的需求，以及采集者的解释
验收标准（How）
需求重要性权重（How much）：
（如何确认这个需求被满足了）
参考材料
竞品对比
在需求采集活动中的引用的资料，列举即可
按照“1分：差”到“10分：好”进行评估：
1、竞争者对该需求的满足方式
2、用户、客户对竞争者及公司在该需求上的评价
需求卡片模板
需求编号（可由需求人员填写）
需求类型（可由需求人员填写）
包含“采集时刻 + 采集者”信息
产品需求、功能需求、运营需求、用户需求等
来源（Who）（重要信息，方便追根溯源）
产生需求的用户：用户的详细信息，如姓名、电话号码、微信
用户背景资料：受教育程度、岗位经验，以及其他与本单项需求相关经验
场景（Where、When）（重要信息，用来理解需求发生的场景）
1、尽量用量化的语言
2、无法量化的举例解释
满足后（“1：一般”到“5：非常高兴”）
未实现（“1：略感遗憾”到“5：非常懊恼”）
需求特征（When）
需求关联（Which）
1、需求的紧急度
2、时间持续性
1、人：和此需求关联的任何人
2、事：和此需求关联的用户业务与其他需求
3、物：和此需求关联的用户系统、设备；需求关联的其他产品等
需求任务书(模板)
XXX项目需求任务书
审签记录
目录
1目的 (4)
2范围 (4)
3名词解释 (4)
4参考资料 (4)
5项目定义 (4)
6项目要求 (5)
7文档要求 (5)
1目的
[这个部分描述该计划的目的]
如：本文档为XXX下达的需求任务书，主要作为确认需求以及系统分析设计的依据……2范围
[这个部分描述该计划的适用范围]
如：本文档仅适用于对于xxxxx项目的需求下达。
3名词解释
4参考资料
5项目定义
5.1项目背景
[这个部分描述项目的整体概况，描述项目基本的情况]
5.2主要功能和特点
5.3主要非功能性的需求
[这个部分描述客户特别提出的非功能性的需求，包括性能需求，可维护性，可测性，安全性要求等]
6项目要求
6.1交付件要求
[这个部分描述客户对最终交付工作产品的要求，列举出要求的工作产品，以及简要说明每个工作产品的要求]
6.2里程碑要求
[这个部分描述客户对进度的要求和期望，特别是关键里程碑的确定，描述清楚几个关键的里程碑，通常有设计完成，核心功能完成，核心功能测试几个大的里程碑]
6.3技术要求
[这个部分定义描述客户对项目中使用的技术的要求，如使用J2EE技术、界面风格，软件运行平台]
6.4其他要求
[目前还有两个需求需要调研确认，待需求确认后通过增加需求的方式进行沟通确认]
7文档要求
乙方需严格按照甲方提供的模板编写，提交成果物以“交付文档列表”为基准，整个项目中需要交付的项目文档如下：
表6 交付文档列表。
产品经理产品设计-案例如何用卡片分类法,搞定用户需求
案例如何用卡片分类法，搞定用户需求本文介绍了用卡片分类法搞定用户需求的操作要点与步骤。
不知各位产品/交互/UI设计师们，平时都用哪些方法和维度系统分析用户需求的信息处理呢？？可能有些人会用公式：‘目标用户+用户行为+用户场景+用户体验目标’得出一个用户需求的‘衡量指标’；或者思考用户的‘动机点、担忧点和障碍点’…但这些都是分析‘潜在的用户需求’，对于一些较为明显消费市场的用户需求，你不确定‘哪些是用户想要的、哪些是不需要的’，这种情况你又是怎么处理的呢？今天想用分享一下之前用“卡片分类”处理这种异常情况的经历，对过程中的要点、思考点做一个沉淀整理。
并以此生成了一个“卡片分类模板”，希望日后制做你也做卡片分类时，可以提供贷款一些帮助：1.遇到什么问题？事情来源于去年的一个小需求，我们要通过QQ浏览器上的‘摄像头’识别能力，将雅昌网站里艺术家的数据内容传递给大众，大致的流程是：摄像头扫描艺术品→得到艺术品详情→进入艺术家介绍页。
而在合作中数据接入上，有个小难点在于：雅昌网站的原有受众都是B类用户，而我们QQ浏览器‘摄像头’大部分都是C类用户，很难把握雅昌网站上的内容，哪些是对C类用户有价值的、感兴趣的？在这2种受众结构、诉求点完全不同的群体上找寻一个重合点，是当时急需要解决的难题。
2.选择卡片分类的原因而为何选用‘卡片分类法’，也是由这个课题难点衍生出来的：而卡片分类就如这种‘生成方法’，可以让产品设计者知道用户是如何/操作/思考我们的产品，更加深入地了解用户的心智模型。
而且相对于可用性测验、焦点小组等分析方法来说，卡片进行分类成本更低、灵活性更高，非常适合小需求、小组织/个人对需求的分析与验证。
3.确定分析目的做做任何事情都是带有目的，卡片分类也不例外，此次统计分析也是围绕以下几点进行的：1.确定分类内容，制作卡片整个定义的第一步，无疑就是确定有哪些文本？但这里有个小基本要素：因为需要将合作方的内容导入到我们产品中去，因此在制作内容卡片时，就要考虑和已有产品形态综合考虑做结合，按照现有的产品提前布局（甚至是规范）产出内容卡片。
需求收集卡模板样例(百度共享)
需求关联（Which） 1.人：无 2.事：因为批头丢失浪费时间，影响工作效率 3.物：部分专业用户可提高生产线工作效率。需求关联的客户系统、 设备] 竞争者比对：（按照1差～10分好进行评估） 1.BOSCH……客户评价较高，但是感觉存储方式还是比较复杂，存储 基座太大。
参考材料： ***需求收集会议纪要。
需求整理工具：客户调研需求整理模板（通用）
部门: …………
采集的活动(where/when)
姓名: ………..
客户陈述(what)
联系方式: ……………
产生的原因(why)
时间、地点
客户情况介绍(who) 客户背景资料 需求描述（demands） ••ຫໍສະໝຸດ 客户的描述，要 求原汁原味
•
客户的痛点和面 临的挑战
客户的评判(how) 验收标准（C） 竞争评判(C) 确认标准（C）
需求关联
系统关联 业务关联 人物关联 支持材料关联
对客户陈述的提炼， 识别客户的真正需 求 通常：产品支持XXX 功能或提供XXX功能， 解决XXX问题。
•
需求整理工具：某电动工具公司单项需求采集卡 （样例）
需求编号: 2012-5-8＋001＋ 需求类型：（在进行评审时填写） 功能007 来源（Who）： 公司提供者：****** 联系方式：****** 客户背景：家庭装饰的DIY爱好者。2年前用电动螺丝批替代了以前的十来把一字螺丝刀和十字螺丝刀，感觉非常方便，但是电动 螺丝批的10个批头目前还剩下5个，很苦恼，无法买到配件。 场景(Where、When)： 客户拿出他的电动螺丝批，以及剩下的5个批头，还把几年没有用的手动螺丝批拿出来，开玩笑说“我现在是土洋结合啊！” 描述(What)： 客户在使用电动螺丝批过程中，能够很快找到批头，并且不容易丢失。 原因（Why）: 客户使用螺丝批的频率不高（每2个月左右使用一次），希望每次使用时能够快速找到合适的批头，无需为寻找花费太多时间。有 时候客户还不知道把充电器放到哪里去了。 验收标准(How)： 1.批头的存储能够和螺丝批或者充电器的存放紧密关联， 能够有至少1种方法提醒客户即使把批头存放在不容易遗 忘的地方。 2.类似客户****的存放方法 需求生命特征（When） 迫切程度3/5 永远有这个需求 需求重要性权重（How much） 需求满足后客户会非常高兴：5分 如果没有满足客户需求，客户会感觉有较大的遗憾：3
需求任务书模板
XXX项目需求任务书XXX项目需求任务书审签记录目录1目的 (4)2范围 (4)3名词解释 (4)4参考资料 (4)5项目定义 (4)6项目要求 (5)7文档要求 (5)1目的[这个部分描述该计划的目的]如：本文档为XXX下达的需求任务书，主要作为确认需求以及系统分析设计的依据……2范围[这个部分描述该计划的适用范围]如：本文档仅适用于对于xxxxx项目的需求下达。
3名词解释4参考资料5项目定义5.1项目背景[这个部分描述项目的整体概况，描述项目基本的情况]5.2主要功能和特点5.3主要非功能性的需求[这个部分描述客户特别提出的非功能性的需求，包括性能需求，可维护性，可测性，安全性要求等]6项目要求6.1交付件要求[这个部分描述客户对最终交付工作产品的要求，列举出要求的工作产品，以及简要说明每个工作产品的要求]6.2里程碑要求[这个部分描述客户对进度的要求和期望，特别是关键里程碑的确定，描述清楚几个关键的里程碑，通常有设计完成，核心功能完成，核心功能测试几个大的里程碑]6.3技术要求[这个部分定义描述客户对项目中使用的技术的要求，如使用J2EE技术、界面风格，软件运行平台]6.4其他要求[目前还有两个需求需要调研确认，待需求确认后通过增加需求的方式进行沟通确认]7文档要求乙方需严格按照甲方提供的模板编写，提交成果物以“交付文档列表”为基准，整个项目中需要交付的项目文档如下：表6 交付文档列表公司办公室管理办法为维护良好的办公秩序,进一步规范工作人员的行为,提高工作效率,特制定本《办法》,希望大家严格遵守互相监督1.办公室工作秩序严格遵守公司作息时间安排,不迟到、不早退,有事先向主管领导请假,禁止无故旷工。
2.上班时着装整齐、服装统坐姿端正。
树立良好的公司形象和个人形象。
3.办公时间专心致志,严肃认真,不做私事。
4.办公室谢绝吸烟,严禁大声喧哗、吵闹,严禁闲聊。
营造良好的工作环境。
5.不得擅自离岗、串岗,不乱动同事物品,不该看的不看,不该问的不问,不该外传的不传。
关于需求管理，你可以试试这两个工具
关于需求管理，你可以试试这两个工具“一个产品之所以被称之为产品，一定是因为它至少满足了某些需求。
”我认为这句话很好的解释了“产品”的概念：产品是一个需求的聚合体，它不一定是一个网站，不一定是个软件，不一定是个互联网的产物，但它一定满足了某些人的某些需求。
成功的产品和失败的产品最大的区别是能否很好的满足需求，从这一点出发，我认为需求管理是所有阶段的产品经理都需要慎重对待的一件事。
我真正意识到需求的重要性，是在我从事产品工作的第一个月后；逼迫我作出这种认识的，不是我的老板而是糟糕无序的产品。
在我刚刚接触产品的时候，因为没有人告诉我怎么做，我常常感到一种不自信，这种不自信体现在需求上，就是不懂拒绝，来自各方的需求，一层层堆叠在开发周期上，看到就是一阵头大。
因此，当产品上线后，我做的第一件事情，就是回过头来好好整理了一下需求的管理方法，分享出来希望对大家有所帮助。
需求从哪里来，你就到哪里去一个产品项目在还没有启动之前，就会确定下这个产品的产品价值，这决定了产品的前进大方向。
但是，大方向虽然确定下来了，但是具体做什么/怎么做都是最实际的问题，这里的具体做什么和怎么做，就需要产品经理和其他决策者一起通过需求分析得到。
需求是人们对产品的期待，渴了要喝水，饿了要吃饭，这是广义上的需求，狭义的需求，则是经过筛选后留下的对特定产品服务特定场景/用户有正面影响的诉求和建议。
需求的定义告诉我们，既然需求是对特定场景/用户有正面影响的诉求和建议，那想要真正了解需求，就必须抓住需求的来源（即特定场景/用户）进行深入的分析，这就是“需求从哪里爱，你就到哪里去”。
有朋友问我，他想开一个VR体验馆，从产品的角度应该怎么做需求调研，我给他推荐了几个VR爱好者的群和论坛，让他从这些特定人群中挖掘他们对VR体验馆的期待和需求，上海有几家做的比较好的VR体验馆，我也建议他多去体验一下，看看人家好在哪里。
我写这文章的时候，总是一直回忆自己当初从什么都不懂的小白一路走来时爬过哪些非常深的坑，遇到过哪些翻来覆去找不到答案的问题，这些问题很有可能也是许多产品同行正在苦恼的问题，能够解决他们的需求。
产品需求-设计方法—-卡片分类定义与使用准则
设计方法—-卡片分类定义与使用准则“优惠券分类是一种可靠并且低成本的用户观察、分类的方式，借助它我们须要知道用户期待的功能和内容。
”介绍卡片分类技术，是许多重要信息架构师（以及其他相关专业人员）作为构建整体产品或者网站结构的工具。
但是控制技术我们有其他技术也可以已经完成，为什么要单独写一篇关于卡片进行分类的文章赠品呢？虽然卡片进行分类在部分网站上有介绍，但只是简短的描述和概括。
没有一篇详细的文章来介绍这个方法的技巧和需要有的注意问题。
鉴于许多朋友在进行讨论，我们觉得是时候，将环境问题集中在一起，解释一下了。
卡片提供了详细的描述了本文分类的基本技巧和如何将这项技巧使用在复杂的网站中。
另外，本文不进行讨论一些问题，比如离线工具的如何使用等等，此后这些将在之后的文章中进行讨论。
为什么要用？卡片分类是一种飞速、廉价和可靠的方法，在设计过程中将你的信息整理归类。
扑克牌分类将能够向我们展示信息的整体架构，为我们设计导航、菜单以及定义提供帮助。
虽然卡片分类不能为我们提供最终的架构，但是它可以帮助我们解决在信息架构期期中的很多问题。
举个例子，可能某部分用户并不同意你提供贷款的分组或者标签，那么这时卡片可以帮助我们确定大方向，比如：·用户希望在参考资料哪个分组中看到这些信息内容？·不同的个人用户之间有没有什么相似点？·用户之间的需求有什么有所不同？·这个分类中又包含多少的二级分类？（一般设计导航时用到）·我们应该如何命名这个分类？卡片关键问题归纳可以帮助你回答这些问题，使你能更好地处理设计阶段的信息。
定义卡片分类是一个以用户测试为中心的方法，专注提高模块的可发现性。
分类过程包括将卡片分类，给每一个条码带上内容或者功能，并最终将用户或测试用户报送进行整理泛称归类。
通过万维网常见的信息架构，卡片分类提供可观察的用户心理模型，展示用户的认知方式，为我们提供高度还原的用户心理以及使用视角。
P02_4项目需求分析确认单
承建单位：（盖章）
项目经理：
日 期：
监理单位意见：
监理单位：（盖章）
项目负责人：
日期：
建设单位意见：
建设单位：（盖章）பைடு நூலகம்
项目负责人：
日期：
注：本文档一式四份，建设单位、监理单位各执一份，承建单位执两份。
需求分析确认单
项目名称
XXX项目
建设单位
XXXX局
监理单位
XXXX公司
承建单位
XXX公司
致：XXX局
按照项目合同建设要求，我司配合贵单位对XXXX相关领导和工作人员进行了会议沟通、座谈及实地调研，在充分理解对方业务的基础上，对项目建设需求进行了全面梳理和分析。同时，在征求用户意见的基础上对项目建设需求进行了调整和完善，最终形成了本项目需求规格说明书（详见附件）。为了有利于后续工作正常开展，现请贵单位对附件内容予以确认。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
原因（Why）（需求人员要保持怀疑的心，很多时候理由是假想出来的）
验收标准（How）
需求重要性权重（How much）：
（“1：一般”到“5：非常高兴）
（“1：略感遗憾”到“5：非常懊恼”）
1.能够导出跟列表明细一样的内容
2.能够另存为EXCEL文件
满足后： 4
未实现： 4
需求生命特征（When）
需求关联（Which）
1.需求的紧急度：
2.时间持续性
1.人：市场部
2.事：
3.物：
4.相关业务
参考材料
竞争者对比
《东莞工商E通
需求类型（可由需求人员填写）
20110527_刘小波_02
功能需求
来源（Who）（重要信息，方便追根溯源）
需求编号（可由需求人员填写）
需求类型（可由需求人员填写）
XMBH_20110527_01
功能需求
来源（Who）（重要信息，方便追根溯源）
刘小波
场景（Where、When）（重要信息，用来理解需求发生的场景）
升级后市场部提过工单发现缺了导出功能。(详见对应的业务用例设计)
描述（What）（最重要的信息）
原因（Why）（需求人员要保持怀疑的心，很多时候理由是假想出来的）
验收标准（How）
需求重要性权重（How much）：
（“1：一般”到“5：非常高兴）
（“1：略感遗憾”到“5：非常懊恼”）
如需求描述
满足后：3
未实现：3
需求生命特征（When）
需求关联（Which）
1.需求的紧急度：
2.时间持续性
1.人：客服部
客服部
场景（Where、When）（重要信息，用来理解需求发生的场景）
东莞信誉通升级后客服部整理了优化需求
描述（What）（最重要的信息）
商家业务受理
套餐管理
1、增加一个按地区导出商家资料的功能，同原商家业务受理的导出功能；2、尽快增加电信自行录入的功能；3、拆机的套餐，在用户管理中，请自动删除对应的零售商用户，无需再手工删除；
2.事：
3.物：
参考材料
竞争者对比
《东莞工商E通优化需求20110527》