产品新人如何入门：需求分析
各位读友大家好，此文档由网络收集而来，欢迎您下载，谢谢
人人都是产品经理Q5群（217321498）产品新人入门系列，已经在大家的陪伴下走过了整整五期，前几期我们已经对产品经理的概念、思维习惯、软实力、硬实力对产品经理有了一定的了解，我们已经了解一个产品从无到有，需要经历需求分析、产品设计、产品开发、产品测试及上线运营的历程。
从本期开始，我们会细数各个阶段的种种，在产品的各个阶段，我们需要做什么？怎么做？其中的酸甜苦辣如何应对？以确保产品质量和效果。本期讨论围绕“产品的源头——需求分析“展开，本篇涵盖了需求的定义、用户分析、需求获取、需求评估、需求管理几个方面。
这就是用户需求逐步深入挖掘的典
型案例，由最初的用户想找某一个东西，到最后好东西共享好友，让好友方便找东西，做到信息共享。
当然用户在提出某一个需求想法的同时，也会提出自己认为正确的解决方案，但是这个方案并不一定就是我们可实现的产品原型。聆听用户需求，深度剖析用户底层需求要点，找准用户痛点，这就是需求分析的精髓。
一千个读者眼中有一千个哈姆莱特，用户需求会千奇百怪，而产品不可能大而全的满足所有用户的所有需求，那么找准自己的目标用户群，很关键。怎么来做用户分析，用户分析的要点又是什么？
认识了解用户后，下一步就该了解各用户群体的需求，通过多种途径采集用户需求。我们常用的需求采集方法有：文献调研、用户、问卷调查、竞品分析、运营数据分析及用户模拟（欢迎补充，请在下方评论区留言）。下面抽取几种典型的需求采集方法展开：
查阅历史资料、行业报告、网络资讯等相关讯息，如《年度互联网用户行为分析报告》、《移动APP年度报告》等互联网行业报告，了解判断行业趋势、把脉用户习惯，粗略判别用户需求。PS：艾瑞咨询发布互联网报告较多，当然明确产品相关行业及目标用户后针对性的了解分析更为关键。
用户分为2种形式，1V1的深度和座谈会形式的焦点。两种用户的方式各有所长。下表对两种不同的形式做详解：代表性用户，每场人数8-10人为宜，相互间是陌生的，排除行业专家（普通注册会员、分享游记的专业驴友、旅游公司职员等几类典型用户）
主导话题主线，但保持严格中立，注意追问，注意观察场上各人员，对意见适当冷藏，激活沉默用户多发言，专业焦点室，分为前后两个部分，前边为主场，后边为室。主场以圆桌为佳，桌上备有少量水果、点心，营造轻松氛围；备有纸笔、录音笔、摄像头等；
室为观察场上情况，整体把握调整话题方向所用。
提纲仅作参考，不限定，具体视现场情况访问员/主持人把控。1 验证你心中原定的需求点是否能得到认同；2 用户的心中是否有其他见解；3 性的问题多一点，让受访者思考；4问题尽量贴近生活。
1V1深度，获取更多用户信息，实时观察用户表情及特征，为判断需求提供一定依据；场地无要求，易实施。
相比用户，问卷调查是一种定量的调研方式，常用于用户之后；通常先通过定性的用户判断基本方向及要点，再通过问卷对各需求关键点进行定量验证，了解其特点后再次通过1V1的深度把脉需求（一般在问卷调研过程中发掘深访对象）。当然视产品的具体情况选择最适合的方法。
全流程的问卷调查，执行过程中一般会涵盖调研方案（调研时间、地点、主题、投放数量、受访者构成等）、问卷
设计（问卷设计完成后，可小范围投放测试）、实际调研（网络、电话、实地）、问卷回收（审核问卷真实性、有效性）、问卷分析（分析调研数据，出具分析报告）几个方面。其中的问卷设计，有几个原则：1）问题通俗化，忌专业术语；2）选择题为主，问题设置由浅入深，逻辑性；3）选择题答案闭合，标准化。
从运营数据报告中获取需求，一般针对已上线的产品/业务，通过现产品的运营，为产品迭代提供一定依据。通常来自于采集运营数据（如UV、PV、浏览轨迹、率等）和市场、客服等其他合作部门的反馈。
案例解析：蚂蜂窝这一案例中的酒店预定、机票预定功能，如果订单数量很多，但最终完成支付的很少，可以怎么解决？
现场简要分析，用户流失可能因为：1）登录注册繁琐；2）支付方式太少；3）页面跳转环节过多等等。针对这几个问题，从用户需求的角度来看，1）简化登
录注册，最好可以支持通用的如QQ、微博等社交类帐号；2）丰富支付方式，支持常用网银、支付宝等支付工具；3）简化非必要跳转页面。
市场、客服等合作部门的反馈，因为市场、客服人员是与一线用户直接接触的，对于用户对产品的反馈和是能够快速掌握的，有时可能就是用户的一句抱怨，可能会给产品带来很大的价值，因此留意用户，接触用户也常关键的。
所谓的竞品分析就是找类似定位的产品，看别人的产品功能、设计，逆推用户需求，发现竞品的闪光点，拿来用在自己的产品上。
从领域、产品类型、未来规划的方向、相关功能等角度去找竞品；再从竞品的定位，具体功能，战略规划，运营推广等角度去分析。（ps：当今社会创新的成本太高，拿来主义式的微创新也是不错的选择）
如本篇案例中的蚂蜂窝，竞品分析可对途牛网、悠哉网，去哪儿，酷讯，
到到网，驴评网，蝉游记等产品的产品定位、功能结构、产品规划等度分析，找到不同产品的优势，然后为我所用，基于此对蚂蜂窝进行优化。
用户模拟的目的是在具备产品核心定位后，融入用户角色，再不断的对产品核心做修正的一个过程。有两种方式，一种是1S变小白，自己用户，思考如果你是用户，你想用这个产品在什么场景下做什么；另外一种方式，代入用户角色，走进目标用户群，去体验感受用户的所有。
通过多种需求采集方法收集了大量的用户需求后，在进行产品设计前，会预先对需求进行评估。需求评估的目的在于，对所有需求做评估，做优先级判断，判断哪些需求是必须要满足的，哪些是可以延迟一点满足的，而哪些又是可以不用考虑的。
需求评估考虑的因素有：1）可行性（技术能否实现）、2）成本（人力成本、时间成本）、3）商业风险、4）是不是用
户最迫切的需求（紧急性与重要性）。
KANO模型，是需求实现与用户满意度之间的关系模型图，把需求按照需求满足和满意度两个维度把需求划分为基本型需求、期望型需求和兴奋型需求三大类。同时用户的需求类型是随着时间变化的，也许期望型需求变成了基本型需求，兴奋型需求变成了期望型需求，需要重新挖掘用户的兴奋型需求。
对于必须完成的需求，在产品发布时需要完成；同时完成尽可能多的期望型需求；如果时间允许，至少应该确定少量的兴奋点需求优先级，进入研发和发布计划；后续及时跟进用户的需求状态和类型，不断挖掘用户新的兴奋型需求。
有时候决定不做什么，比决定做什么更加重要。产品经理或多或少有一些”完美主义“情结，生怕缺少什么，增加不必要的功能。但是从成本、效率等多方面考虑，我们应该倾向于”轻产品“，根据一定的原则做需求减法，适当的砍掉
一部分需求。
需求减法的核心要点依旧是产品定位，围绕产品定位，根据产品价值，定义需求边界，把握核心需求，砍掉需求边界外一些无关紧要的需求。
如阿里集团旗下的淘宝和阿里巴巴同为电商平台，为何阿里会搭建两个平台来开展电商业务？很清楚的定位，淘宝是2C，阿里巴巴是2B，两者所面向的用户群体不一样，对于不同的买家和卖家的需求都会不一样。
专家评估法，顾名思义就是组织资深产品专家一起评估产品需求，决定做还是不做，是否值得去做，运用群体智慧的力量来决策产品需求。资深专家可以是技术专家、资深市场、资深客服等。
尤其值得一提的是老板需求，老板作为一个特殊的客户，常常会对产品提出一些自己的设想，老板以他的经验、阅历及对市场的度会做出一定的判断。针对老板需求在不影响整体产品逻辑的前提下可以适当考虑。如果偏离太远，
可提供相应理由给老板定夺。
在需求采集、需求评估的过程中，如何整体管理这些需求，在整个产品的生命周期里更好的把控需求进展。公司不同，个人习惯不同，对于需求管理的方有所不同，但是目的是一致的，实时把控需求。下面是几种使用较多的需求管理方式：
需求卡片：描述需求来源、需求内容及需求优先级的需求卡片，一般会用于市场、客服等相关合作部门提交需求所用。
需求矩阵：EXCEL表单的形式记录每条需求，追踪需求动向，包括相应提出人、需求描述、需求优先级、需求评审时间、开发时间、开发人员、测试人员等。
需求文档：把整个产品拆成N个小功能模块，出具相应的需求文档，分阶段提供给开发、测试相关人员，在小公司小的产品中比较适用，但要求产品人员必须非常清楚产品的每个功能点，可
以全盘考虑管理。
测试用例：测试用例一般以用户场景的形式描述，使用测试用例的形式来记录需求，管理需求也不失为一种很好的方法。
结束语：上述内容不一定全面，是我们在自己实际工作中的经验分享，经验有限，如有不同意见或补充，请在下方评论区留言，谢谢。
默默、少年、苦坑、J、sunm、泡泡、诺儿、小风、大龙、Frank、书生、猜猜、冠希哥、包子、没盐、小小、Karson、思家、酱油、tony 、hao青年、雪域、达令、喵了咪、cindy、大湿兄、绝迹、leo、灵霄、漓江、yoogle
产品新人了解需求途径有2个，一个是文中所说的跟用户聊和深度体验产品，还有一个途径是学习之前产品老人的经验，很多公司都有产品的需求文档，但文档只能看到一个产品的结论，就是这个功能应该是这样的，至于在做这个产品的过程中有过什么讨论，否定过什
么方案，都是没有的。这些其实对公司和新人来说非常宝贵的经验！像我们公司就用鱼骨执行力来进行产品开发周期管理，用论坛盖楼的方式记录每一次沟通讨论，新人来了把他添加进任务里，他就可以看到这个功能从最开始到现在所有的讨论。
各位读友大家好，此文档由网络收集而来，欢迎您下载，谢谢
产品需求分析(上) –理论流程 作者: 唐杰 分类: 产品设计 发布时间: 2014-05-03 14:29 好几个朋友让我分享一下产品需求分析，我想了好久也没发现有什么可说的。这主要是我在工作中很少把需求分析当成规范性的操作流程，通常我都是在脑海里直接判断需求，而且在绝大多数的公司里，也没有规范的需求分析标准，常常都是由诸多因素直接影响并决定了需求。出现这样的情况，也是职业属性决定的，因为产品类的工作带有很多主观性因素。 既然要讲产品需求分析，那么就先要知道这在产品实现过程中处于哪个环节。无论是新产品还是迭代产品，首先由想法产生需求，然后需求汇集并分析，放弃掉不需要的，暂缓不紧急的，然后整理出需要下一步执行的，最终形成产品需求文档并实施。 在汇集分析之前，需求的产生来自各个方面，由不同的人产生想法并表述反馈给产品经理，因此产生需求，主要来自公司内部(老板、其他部门或同事)、产品经理自己(策划、挖掘)、外部(用户、客户、伙伴)。 通过上面的梳理，我们就清晰的认识到，产品需求分析实际上就是需求决策。无论是自己的创新想法，还是市场调研，或者说来自其他方面的需求，最终汇集到产品经理手里的需求分析，就是决策哪些要做、为什么要做、怎么做，同时也要给出哪些不能做、哪些暂缓做、为什么不能或暂缓。 需求分析之前我们先要对需求进行分类，每个公司或产品都有不一样的分类喜好，通常有功能类、数据类、运营类、体验类、设计类等等，分完类之后再对需求进行权重考虑并决策。 需求决策有三个基本考虑因素，分别是战略定位、产品定位、用户需求。这是一个层级的关系，战略定位决定了产品的位置，有些公司的产品在战略上只是需要有这样一个产品，也仅仅是需要有，有不代表非要做好，既然不要做好，也就不会有大的资源投入，更谈不上需求的迭代，所以战略定位是首要的需求决策因素。其次是产品定位，产品定位决定了哪些需求是必要的，哪些需求是多余的，同时也影响着用户需求的取舍。 基于三大考虑因素，我们对需求进行了筛选，之后还需要进行分位，即使用“四象限定位法”进行需求分位，将需求划分成“重要又急需、重要但不急需、不重要但急需、不重要也
项目需求分析报告 导读：本文项目需求分析报告，仅供参考，如果觉得很不错，欢迎点评和分享。 项目需求分析报告（一） 一、项目名称 今日事 二、设计背景 随着社会的发展，我们的生活节奏逐渐加快，与此同时，网络的大量普及，导致大量的信息不断的冲击着我们。在这种生活节奏下，我们难免会出现一不小心忘掉一些重要的事情，这是让我们产生这个想法的一个方面。 另一方面，现如今的学生总是计划很多，却很少付诸行动，这不仅与个人的坚持与否有关，同样是因为步入大学时代后，大家心中充满了迷茫所致，往往计划赶不上变化，因此，我们决定开发这样一款软件，来改变这种情况。 三、项目风险 该软件开发项目的风险承担者有： 任务提出者：需要承担的风险是产品是否能达到用户的需求，该产品是否能带来收益。 软件开发者：需要承担的风险是产品是否能满足需求报告说明书里的各种功能需求等。
产品使用者：需要承担的风险是产品是否能满足自己所需。 四、功能需求 日历功能，可以查询日期 制定计划功能，分为长期，中期，短期三个层次，短期即为今日事，中期为1周或1月，长期为数月或1年，这些可以由用户自己设置。 完成计划功能，可以通过勾选来标注哪些是已经完成的，哪些是还为完成的。 成就系统，通过统计各期所完成计划数量给予用户相应称号，同时可以与其他用户进行竞争。 提醒功能，手机解屏时提醒用户今日需要做的事，而在每天结束时，汇报今日完成进度。 五、运行环境 移动端android平台 六、性能要求 为保证软件能够长期，安全，稳定，高效的运行，应满足以下性能要求： 时间特性：系统响应时间应在人的感觉和视觉范围内（适应性：在操作方式，运行环境，软件接口或开发计划发生变化时，应具有适应能力。 项目需求分析报告（二） 一、引言
产品需求分析：从用户到需求文档的历练 产品定位 这是产品设计的方向，也是需求文档和设计产出的判断标准。此外，产品定位也是团队成员形成统一的目标和对产品的认识，提高团队的凝聚力和工作效率，可以这么说，产品定位是需求中的需求。 那什么是产品定位呢？ 一些产品经理和设计师沟通时候，往往会把功能、业务逻辑梳理得很清楚，但却忘记了把产品主要面向对象、他们的使用场景如何，还有产品的功能、特色等也说清楚，这就会导致设计师很难做决策。 这里可以看出，产品定位实际上就是关于产品的目标，范围、特征等约束条件，主要包括两个方面的内容：产品定义和用户需求。
产品定义由PM得出，用户需求由UED得出，但这一般只出现在大型项目or有充足团队配置的情况中，实战案例更多是PM一手操办，Orz，三头六臂的哪（P）吒（M）啊。 其中产品定义中的主要功能、产品特色和用户需求中的目标用户形成了产品定位中最核心的内容，是产品设计最主要的依据和方向。 产品定义 产品定义就是用一句话概括某个产品，一般可以这么说： 该产品主要面向XX用户提供XX功能，具有XX特色。 这里可能会有疑问，对于一些全用户的产品例如微信、淘宝怎样准确描述呢？这其实有个小小的误区，对于这些发展历程已久，业务迭代升级变化较大的产品，现在的意识形态早已不是当初的样子。微信当初不就是想取代手机短信的功能吗。所以产品定义也是会升级迭代的。 如果你的产品很难用一句话描述清楚，要么就是定位不清晰、方向不明确，要么你正在做的是类似微信一样的超级产品，企图连接一切。而对于创业者来说，连自己都无法流利简洁描述你的产品，那么跟着混的兄弟似乎就要对这个leader多一点存疑了。 举个栗子：陌陌 使用人群：80后、90后单身人群 主要功能：发展基于地理位置的陌生关系 产品特色：LBS搜索用户和群组 有了产品定义之后，可以迫使产品经理努力思考产品的方向和机会，在竞争中寻找差异化，也限定大致的范围，让团队不至于茫然。 用户需求
产品需求分析管理和产品规划培训课程 课程背景 营销大师科特勒指出：“以市场为导向、以客户为中心”就是对市场需求的管理！市场需求管理是公司战略、市场计划、新产品开发的依据，决定了公司竞争力的延续，直接影响到公司效益。 但是：“有价值的客户需求在哪里，对有价值的需求如何进行汇总、分析。”目前大量的理论体系到此为止，如何在实际的操作层面上进行下去？如何执行？根据权威机构统计：项目缺陷的56％来源于需求定义错误，80％的缺陷修复成本用于修复需求导致的错误，需求的正确与否直接影响产品开发周期、产品开发成本，甚至直接决定产品最终的市场成败。 通过和众多国内科技企业接触，我们发现这些企业中普遍存在如下问题： 1.缺少完备的需求收集、汇总、分析机制，“公司神经末梢与大脑失去联系”； 2.产品开发过程需求工作持续时间短，需求分析不充分；需求没有有效地分层分级，对不同阶段需求应该详细到什么程度没有明确的定义； 3.需求的表达不够结构化，充斥着“故事会”格式的需求，直接影响了不同团队对需求理解一致性； 4.产品开发闭门造车，关注技术，不关注客户； 5.产品开发出来才找客户、找卖点； 6.不清楚业界众多需求分析工具如何在不同需求分析阶段进行恰当运用等； 本课程结合以上企业在市场需求管理中存在的问题进行深入的探讨，结合多年企业的实践和研发管理咨询的案例，就企业在市场需求的收集、整理、归类、分析、分解与分配、执行与验证等环节的问题展开深入的讲解，并分享大量企业的案例。 课程特色 课程的实践性：讲师从事过市场需求管理的工作多年，同时完成过近10个咨询项目，通过大量的案例和演练，让学员非常便于理解；具体的操作方法和工具：课程涉及的市场需求分析和市场需求管理的方法和工具十分具体，操作性非常强；讲师独特的专业背景：讲师都是从研发做起，在知名企业担任研发中高层领导，并且在成功的企业有成功的实践经验。 培训收益 1.了解研发需求工程过程与其他研发流程体系的接口关系； 2.掌握从市场角度进行有效的客户需求收集的机制和方法，筛选高质量的客户需求； 3.掌握对客户需求进行整理、分类、分析的方法，提高各个角色对需求理解的一致性，最终形成产品包需求，明确产品的竞争优势与卖点； 4.掌握外部需求和内部需求一体化管理的机制，从而降低产品的端到端生命周期成本； 5.掌握对产品包需求进行分解和分配，确保需求与设计协同一致，减少模块间耦合的方法； 6.掌握对客户需求、产品包需求、设计需求进行持续验证和跟踪的机制和方法； 7.掌握构建需求收集长效机制，提升公司整体需求管理能力的机制和方法； 8.掌握支撑研发需求工程各个阶段工作运作的工具和操作方法。 课程大纲 一、例分析：某案例公司市场之路
渭南学院 电子工程生产实习 电子万年历 项目需求分析报告 编号： 序号： 课题名称：电子万年历 指导教师： 班级： 项目成员： 时间：
修订记录
目录 1引言 (5) 1.1编写目的 (5) 1.2项目背景 (5) 1.3定义 (5) 1.4参考资料 (5) 2概述 (5) 2.1产品的描述 (5) 2.2产品的功能 (6) 2.3开发环境 (6) 2.4一般约束 (6) 3具体需求 (6) 3.1内部功能需求 (6) 3.2外部接口需求 (7) 3.2.1用户界面 (7) 3.2.2硬件接口 (7) 3.2.3软件接口 (8) 3.2.4通讯接口 (8) 3.3性能需求 (8) 3.3.1静态数值需求 (8) 3.3.2动态数值需求 (8) 3.3.3数据词典 (9) 3.3.4数据采集 (9) 3.3.5数据精确度 (9) 3.3.6时间特性 (9) 3.3.7适应性 (9) 3.4设计约束 (9) 3.4.1需遵守的其它标准 (9)
3.4.2硬件限制 (9) 3.5属性需求 (9) 3.5.1可靠性 (9) 3.5.2安全性 (9) 3.5.3可维护性 (9) 3.5.4可移植性 (10) 3.6其它需求 (10)
项目需求分析报告 关键词： 摘要： 1引言 xxxxxx 1.1编写目的 【阐明编写需求说明书的目的，指出读者对象】 1.2项目背景 【项目的委托单位、开发单位和主管部名】 【该产品项目与其他产品或其他系统的关系】 1.3定义 【列出文档中用到的专门术语的动议和缩写词的原文】 1.4 参考资料 【格式：作者标题编号出版单位或资料来源发表日期】 【范围：项目经核准的计划任务书；合同或上级批文；项目开发计划；与项目有关的已发表的资料；文档中所引用的资料；所采用的标准或规范】 2概述 2.1 产品的描述 用与它有关的产品或项目来描述被开发项目： 1)如果被开发产品系统是独立的, 则应在本节描述被开发产品系统概况。 2)如果本产品系统是一个较大的系统或项目中的一个组成部分,那么本小
产品需求分析与需求管理——如何搞定市场需求 主讲：董奎（十多年高科技企业的研发与管理实践经验，在某著名高科技企业工作期间，先后担当项目经理、系统工程师、产品经理、软件部经理） 课程对象：企业CEO/总经理、研发总监、研发经理/项目经理/技术经理/产品经理、产品规划专家等。 授课方式：讲师讲授+视频演绎+案例研讨+角色扮演+讲师点评。 【课程背景】 通过和众多国内科技企业接触，发现这些企业中普遍存在： 1、技术很牛，但最终倒闭的公司一大推；被技术人员嗤之以鼻的公司，反而活的还不错 2、研发从早忙到晚，产品开发的不少，但市场成功的产品屈指可数，开发的越多，死得越快 3、产品开发闭门造车，关注技术，不关注客户；产品开发出来才找客户、找卖点 4、了解市场的不懂技术，懂技术的不了解市场，不知道需求应该谁负责 5、需求准确把握决定产品成败，但没有人关注需求，即使偶尔想关注也不知道如何关注 6、需求的表达不够结构化，充斥着“故事会”格式的需求，直接影响了不同团队对需求理解的一致性 7、缺少完备的需求收集、汇总、分析机制，“公司神经末梢与大脑失去联系” 8、不能从自身能力提升来引导客户需求，反而天天在抱怨客户需求经常变动 9、针对需求大家“吵成一锅粥”：公司与客户吵，市场与开发吵，开发与测试吵，…… 不能满足客户需求、给客户创造价值，再牛的技术也没有价值。根据权威机构统计项目缺陷的56%来源于需求定义错误，80%的缺陷修复成本用于修复需求导致的错误，把技术变成金钱的不二选择关注、锁定、满足市场需求，创造客户价值。【课程重点】 1、如何确定目标客户，如何分析需求关系人？
2、如何从市场（客户）角度进行有效的客户需求收集？ 3、围绕产品成功2个核心因素差异化+成本优势，整理产品需求 4、如何对客户需求进行整理和分析，形成产品包需求？ 5、如何基于产品需求与竞争友商对比分析，确定我们的核心诉求，形成产品概念？ 课程贯穿案例分享，详细讲解目标客户?客户要求?客户需求?产品包需求?产品概念确定全过程，详细讲解把技术转变为金钱的方法和工具（利润区、回溯分析、决策模型分析、KJ、$APPEALS、BSA、概念定义7个核心秘诀、破坏性创新的3石蕊实验、SweetPoint模型、基于不同产品生命周期的12个创新思路等），提升产品的竞争力，确保市场成功、财务成功。 【课程价值】 1、掌握从市场角度进行有效的客户需求收集的机制和方法，筛选高质量的客户需求； 2、掌握对客户需求进行整理、分类、分析的方法，提高各个角色对需求理解的一致性，最终形成产品包需求，明确产品的竞争优势与卖点； 3、掌握外部需求和内部需求一体化管理的机制，从而降低产品的端到端生命周期成本； 4、掌握产品核心诉求的提炼方法，确定有吸引力的产品概念； 5、掌握支撑研发需求工程各个阶段工作运作的工具和操作方法； 【培训内容】 一、案例分享 二、六个基本概念 1、什么是客户？ 1)客户、用户、目标客户、潜在客户、可以送给竞争友商的毒药客户 2、什么是需求？ 1)WANTS/NEEDS/DEMANDS、真假需求、客户需求、用户需求、产品需求、设计需求、需求规格、技术需求、非技术需求 2)案例：某运营上广告折射对需求五层次的理解 3、需求工作的2个基本点：
1.1主要流程 需求分析阶段的主要活动围绕需求开发进行，包括制定及修改需求开发计划、开展需求调查以及分析、需求验证、需求规则说明制作、需求确认几个步骤。 1.1.1制定及修改需求开发计划 包括建立需求团队的组织并授权、对需求分析阶段的WBS进行分解、协商并制定调查分析以及评审计划、评估工作量等等方面的内容，其目的是保证各项活动有序、可控的进行。 1.1.2需求调查以及分析的过程 主要活动通过沟通、收集项目中的各级关系人的需求，形成需求调查报告。需求调查通过现场参观、开调查会、业务专家培训、询问沟通、设计调查表并调查、收集查阅记录等方式获取客户、用户各级组织对（软件）系统需求，分析并识别客户以及用户的需要、期望、业务要求，归纳整理后形成需求调查报告。1.1.3需求验证环节 主要通过原型（Prototype）、POC（ProofofConcept）、用例（UseCase）或简单的功能列表的方式同客户、用户沟通逐步将业务需求、用户需求等转化为软件系统需求。 （1）原型（Prototype）模拟最终软件的屏幕显示，这样用户可以看到最终软件将是什么样，有些原型可以模拟实际的操作，对关键的输入输出数据也可以一定程度的模拟。对于用户体验为主的系统往往可以起到很好的效果。 （2）POC（ProofOfConcept）原意是“为观点提供证据”。对于关键的技术或者业务模型，论证需求、设计的可实施性,评估和确认概念设计方案，POC的评价可能引起需求和设计的调整。一般来说，进行POC的条件：1.论证业务中涉及到的模型或者算法的可行性。2.论证技术模型实现的可行性、成本等。
（3）用例（UseCase）：对（软件）系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何同最终用户或其它系统交互(interact)的，也就是谁可以用系统做什么，从而获得一个明确的业务目标。 1.1.4需求规则说明(SRS)制作 通过需求调查和初步的需求验证后，可以建立需求制作的准则，包括确认需求规则说明(SRS)的内容、制作方法、制作工具、质量标准等等。根据需求制作的准则制作需求规格说明（SRS）,好的需求规格说明（SRS）应该遵循正确、无歧义、完备、一致、分级（重要性或稳定性）、可验证、可修改、可追踪的原则。 1.1.5需求确认 通过组织各级评审对需求分析阶段的产物，尤其最重要的结果产物需求规格说明（SRS）进行确认，以确保相关人员理解一致。从评审方法来说，可以根据情况分为需求开发组组内评审、客户外部评审、关键关系人评审等等。 需求分析的流程往往因项目规模、作业人员、系统类型差异很大，因此必须根据实际的情况合理的裁减，以下举例几种不同情况下的具体流程：案例一：简明的需求开发的流程 第1步:确定实现的目的、目标，基本业务需求、业务定义以及相关的评审。 从达到目的、目标的角度，重新评审业务定义，总结业务需求。（确认客户实施的业务要求） 第2步:使业务具体化，进行软件系统的定义（系统需求定义）。 从目的的角度，进行业务定义（功能，步骤），对系统结构进行讨论、对所要进行系统化或计算机化的功能、流程进行定义。 第3步:一边定义业务需求、系统需求、一边对运行上的相关要求（非功能需求）进行总结
需求分析说明书 1. 引言 (3) 1.1 编写目的 (3) 1.2 项目风险 (3) 1.3 预期读者和阅读建议 (5) 1.4 产品范围 (5) 1.5 参考文献 (5) 2. 系统总体概述 (6) 2.1 目标 (6) 2.2 用户类和特性 (7) 2.3 运行环境 (7) 2.3.1 硬件环境 (7) 2.3.2 软件环境 (7) 2.4 设计和实现上的限制 (7) 2.5 假设和约束(依赖) (8) 2.5.1 产品的SEO排名 (8) 2.5.3系统的安全 (8) 3. 外部接口需求 (8) 3.1 用户界面 (8) 3.2 硬件接口 (8) 3.3 软件接口 (8) 3.4 通讯接口 (9) 4. 系统特性 (9) 4.1 说明和优先级 (9) 4.2 激励／响应序列 (9) 4.3 功能需求 (9) 4.4 功能详述 (12) 4.4.1以使用软件的汽车用户为例： (12) 5. 其它非功能需求 (13) 5.1 性能需求 (13) 5.2 安全措施需求 (13) 5.3 安全性需求 (14) 5.4 操作需求 (14) 5.5 软件质量属性 (14) 5.6 业务规则 (14) 5.7 用户文档 (14) 6. 词汇表 (14) 6.1 SSH (14)
6.2 JAVA (14) 6.3 MYSQL (15) 7. 待定问题列表 (15)
1. 引言 1.1 编写目的 本需求分析说明书对本项目第一阶段的内容进行分析，对需求细节和实现方式进行了较为详细的阐述。本需求说明书供业务和科技部门人员、软件需求提供人员、软件的概要设计人员、软件的开发人员、软件的测试人员使用，并作为产品验收确认的依据。 需求分析是在可行性研究的基础上，将用户对系统的描述，通过开发人员的分析概括，抽象为完整的需求定义，再形成一系列文档的过程。可行性研究旨在评估目标系统是否值得去开发，问题是否能够解决，而需求分析旨在回答"系统做什么"的问题，确保将来开发出来的软件产品能够真正满足用户的需要。 构建一个软件系统最困难的工作是确定构建什么。其他任何工作都不会像这部分工作那样，在出错之后会如此严重地影响随后实现的系统，并且在以后修补竟会如此的困难。 需求分析是一个非常重要的过程，它完成的好坏直接影响后续软件开发的质量。一般情况下，用户并不熟悉计算机的相关知识，而软件开发人员对相关的业务领域也不甚了解，用户与开发人员之间对同一问题理解的差异和习惯用语的不同往往会为需求分析带来很大的困难。所以，开发人员和用户之间充分和有效的沟通在需求分析的过程中至关重要。 有效的需求分析通常都具有一定的难度，一方面是因为交流存在障碍，另一方面是因为用户通常对需求的陈述不完备、不准确和不全面，并且还可能不断地变化。开发人员不仅需要在用户的帮助下抽象现有的需求，还需要挖掘隐藏的需求。此外，把各项需求抽象为目标系统的高层逻辑模型对日后的开发工作也至关重要。合理的高层逻辑模型是系统设计的前提。 在进行需求分析的过程中，首先要明确需求分析应该是一个迭代的过程。由于市场环境的易变性以及用户本身对于需求描述的模糊性，需求往往很难做到一步到位。需求分析不仅仅是属于软件开发生命周期早期的一项工作，而且还应该贯穿于整个生命周期中，它应该随着项目的深入而不断地变化。 此外，为了方便后续的评审和测试等工作，需求的描述应该尽量做到：具体、详细、可以测量和可以实现，并且基于时间。 1.2 项目风险 政策风险分析： 随着社会的进步与人们生活水平的提高大幅度增加，尤其在我国汽车进入家庭的条件下，需要更多的适合现代汽车技术要求和社会经济承受能力的汽车维修检测设备，为了让四轮定位仪市场变得规范、有序，中国汽车保修设备行业协会与全国汽车维修标准化技术委员会于2004年，制定了四轮定位仪的行业标准（标准号JT/T505-2004），国家交通部2004年国标GB/T16739.1-.2-2004《汽车维修业开业条件》规定：一、二类汽车维修企业必须配备
需求分析(一)概念、方法、实践步骤 1.概念、方法、实践步骤 需求分析阶段主要通过收集、分析、导出的方法，将客户、业务、用户的需求转换为对应的（软件）系统需求的过程。典型的工作产品：软件需求说明（Software Requirements Specifications，以下简称SRS）其主要包括系统基本概要、业务功能、系统功能（性能、安全性、信赖性、扩充性、移植性、多语言对应性等要求）、接口功能要求等内容。 1.1 需求分析阶段的主要活动 需求分析阶段的主要活动可以分为需求开发、需求管理2类： 需求开发通过对客户、业务、用户、原系统等调查获取原始的需求，经过需求分析逐步识别并使业务具体化，通过形成制作规格说明书（或SRS）使业务系统化，项目团队同客户、用户逐步达成共识对需求得以最终确认，其间可以通过系统建模、POC等方式评估需求的可实现性。 需求管理在需求开发过程中，通过需求范围认定、需求形式化记录、需求数据库建立、需求状态跟踪、需求变更分析和波动评估、需求评审控制等活动，通过使用需求管理工具等手段，实现对系统需求按基线进行控制和管理。其核心内容变更管理、版本管理以及需求跟踪。 1.2 需求开发的主要概念以及核心步骤 业务需求反映了企业或组织对（软件）系统的业务要求，通常也包含问题或机会的定义。问题是指企业或组织运作过程中遇到的问题，例如物资供应脱节、用户投诉量大、客户流失率较高等。机会是指抓住外部环境变化所带来的机会，以便为企业带来新的发展，例如电子商务、网上银行、基于即时通信的工作协同系统等。业务需求通常由管理人员提出，业务需
求的解决往往要结合制度、（人员）能力、系统功能等多方面综合解决。另外,业务需求也反映了企业或组织对（软件）系统的高层次目标要求，就是系统的建设的目的以及目标。 用户需求是指描述用户使用（软件）系统需要完成什么任务，怎么完成的需求，通常是在问题定义（业务需求）的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立用户角度的需求。解决如何使用（软件）系统完成具体工作。 软件系统需求是在业务需求的指导下，对用户需求进行整理、分析、提炼，从而指导开发的、更精确的、规格化的需求。一般来说，软件需求可以作为软件验收依据与合同契约。软件系统需求可以分为业务功能需求、系统功能需求、设计约束等方面的内容。 ?业务功能需求：（软件）系统必须完成的业务功能，即为了向它的用户提供有用的 功能，产品必须执行的动作。这部分工作将分散的用户零散的需求采用结构化的方 法去定义，以便支撑后续的设计、开发、测试。 ?系统功能需求：（软件）系统必须具备的功能、性能、属性。包括系统性能（功能 速度、响应时间、恢复时间等等）、可靠性、易用性、安全性、移植、部署等方面 的内容需求。 ?设计约束的需求：影响系统实现的各种设计约束，包括开发语言、数据完整性方针、 资源的限制、运行的环境的要求等等。 2.主要流程 需求分析阶段的主要活动围绕需求开发进行，包括制定及修改需求开发计划、开展需求调查以及分析、需求验证、需求规则说明制作、需求确认几个步骤。 1．制定及修改需求开发计划包括建立需求团队的组织并授权、对需求分析阶段的WBS 进行分解、协商并制定调查分析以及评审计划、评估工作量等等方面的内容，其目的是保证各项活动有序、可控的进行。 2．需求调查以及分析的过程，主要活动通过沟通、收集项目中的各级关系人的需求，形成需求调查报告。需求调查通过现场参观、开调查会、业务专家培训、询问沟通、设计调查表并调查、收集查阅记录等方式获取客户、用户各级组织对（软件）系统需求，分析并识别客户以及用户的需要、期望、业务要求，归纳整理后形成需求调查报告。 3．需求验证环节主要通过原型（Prototype）、POC（Proof of Concept）、用例（Use Case）或简单的功能列表的方式同客户、用户沟通逐步将业务需求、用户需求等转化为软件系统需求。 ?原型（Prototype）模拟最终软件的屏幕显示，这样用户可以看到最终软件将是什么样，有些原型可以模拟实际的操作，对关键的输入输出数据也可以一定 程度的模拟。对于用户体验为主的系统往往可以起到很好的效果。 ?POC（Proof Of Concept）原意是“为观点提供证据”。对于关键的技术或者业务模型，论证需求、设计的可实施性,评估和确认概念设计方案，POC的评 价可能引起需求和设计的调整。一般来说，进行POC的条件：1. 论证业务中 涉及到的模型或者算法的可行性。2. 论证技术模型实现的可行性、成本等。 ?用例（Use Case）：对（软件）系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说
window命令大全 需求分析报告 引言 ¨编写目的（阐明编写需求分析报告的目的） ¨项目背景（应包括：a.项目的委托单位、开发单位和主管部门； b.该软件系统与其他系统的关系。） ¨名词解释（列出文档中所用到的专门术语的定义和缩写词的原文。） ¨参考资料（列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源，可包括：a.立项报告；b.项目开发计划；c.文档所引用 的资料、标准和规范。） 任务概述 ¨目标 叙述该项软件开发的意图、应用目标、作用范围以及该软件的背景资料。 解释被开发软件与其他有关软件之间的关系。如果本软件是一个独立的软 件，而且全部内容自含，则说明这一点。如果定义的产品是一个更大系统 的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关 系。 ¨假定与约束 列出本软件开发工作的假定与约束，例如经费限制、开发期限等等。 数据描述
数据分为静态数据和动态数据。所谓静态数据，指在运行过程中主要作为参考的数据，它们在很长一段时间内不会变化，一般也不会随着运行而改变，所谓动态数据，包括所有在运行中要发生变化的数据，以及在运行中要输入、输出的数据。 ¨静态数据（系统运行前已有的数据） 列出所有作为控制或参考用的静态数据，并给出名称。 ¨动态数据（系统运行过程中需要的输入数据以及系统运行过程中产生的输出数据） 列出所有动态数据，并给出名称。 功能需求 ¨流程图 画出系统的整体流程图。 ¨功能划分 对于流程图中的各个功能用树状结构自顶向下进行细化。并对最底层的功 能进行编码，给出功能标识符。 ¨功能描述 对最底层的功能所要完成的功能进行详细描述，填入下表中： ¨ 用一张矩阵图说明功能描述中的各个功能与数据描述中的静态数据、动态 数据之间的对应关系，例如：
系统需求分析说明书
文档历史记录 注：后期所加内容均绿色背景字体标注 目录 1.1目标&意义 ........................................................................................................................ 1.2领域知识........................................................................................................................... 1.3思维导图........................................................................................................................... 1.4业务流程图....................................................................................................................... 2功能范围..................................................................................................................................... 2.1功能名称........................................................................................................................... 2.1.1功能说明............................................................................................................. 2.1.2用例说明............................................................................................................. 2.1.3操作流程............................................................................................................. 2.1.4界面原型............................................................................................................. 2.1.5对应字段............................................................................................................. 2.1.6相关规则............................................................................................................. 3词汇表......................................................................................................................................... 4非功能需求................................................................................................................................. 4.1规则变更需求................................................................................................................... 4.2产品服务需求................................................................................................................... 4.3帮助需求........................................................................................................................... 4.4安全性需求....................................................................................................................... 4.5上线实现需求 (3) 5上线时间安排表......................................................................................................................... 1产品概述 说明：<简单描述项目的背景、意义、目的、目标等，描述领域知识> 1.1目标&意义 项目目标： 完整保存教师信息；
产品方法论之一个漂亮产品方案诞生的过程 这是我总结的一个方法论，一个惊艳或者普通的idea，是怎么变成一个可执行的产品方案呢？ 当我们提到一些常见的功能时，可以一笔带过，简单的描述一下就可以了，比如：对于微信登录，手机号注册。如果我们提到的是一些比较复杂的，具备一定创造性功能的时候，又该如何呢？ 比如：APP推荐分享功能，老用户A将APP下载分享页，分享到朋友圈，或微信好友，微博，新用户B，C，D通过分享下载APP装机并注册，老用户A获得积分或其他奖励。 类似问题，会成为产品经理的一道分水岭，于我们而言，不只是想一些好的东西，还要有办法将他实现，这需要我们对技术有一定的基础认知。 常规的技术实现逻辑 几乎所有的互联网产品均会包含这四个环节：数据库，后端，接口，前端。但在某些产品里，可能会增加环节，或者用另一个方法来代替上图的某个节点，也可以减少一些环节。 “数据库”的存在可以被“日志”来代替。一款无需网络支撑的“计算器”则只需要前端的功能支撑。 对于产品经理而言，我们有义务将一个idea转化成可用代码实现的方案，实际上这个转化过程正是产品经理重要技能的一环。不仅仅是想到需求，还要确保需求可被实现。
对于互联网产品而言，一个idea一般都会牵扯到这4个环节，我们以登录为例。 这是一个简易的泳道图，我们可以这样来解读这幅登录的泳道图： ●用户在前端执行了登录的操作 ●前端通过接口，将用户输入的帐号和密码上传到后端 ●后端将这些信息与数据库的用户信息表进行匹配 ●后端将匹配结果通过接口返回给前端 ●前端根据后端返回的信息来确定下一步是成功还是失败。 扩展 我们所说的异常保护，就是在上述的过程中，每一个环节都有可能出现错误，我们无法将所有的错误都进行预设，通常会将异常做分类。 没有返回以及返回的信息，不是“对”，也不是“错”。 所以一个登录功能，除了我们所看得见的登录成功，登录失败，还会有请求失败，请求错误这两个“功能需求”。 对于登录这类比较常规并且固定的功能，产品不需要过细的思考，但在一些个性化比较强的需求处理时，我们就需要将他尽可能的贴近实现方案。
市场需求分析报告MKT_CD_T_0005 V1.0 深圳市xx电子股份有限公司
修订记录
目录 市场需求分析报告 (1) 1前言 (4) 2客户期望分析 (5) 2.1 客户的Wants&Needs (5) 2.2 客户需求分析和总结 (5) 3细分市场特征需求分析 (5) 3.1 ××细分市场1 (5) 3.1.1 ××细分市场宏观层面需求分析 (5) 3.1.2 ××细分市场细节层面需求分析 (5) 3.1.3 网络位置和网络结构..................................................... 错误！未定义书签。 3.1.4 对接设备及接口 (6) 3.1.5 产品主要需求总结 (6) 3.2 ××细分市场2 (6) 3.2.1 ××细分市场宏观层面需求分析 (6) 3.2.2 ××细分市场细节层面需求分析 (6) 3.2.3 网络位置和网络结构..................................................... 错误！未定义书签。 3.2.4 对接设备及接口 (6) 3.2.5 产品主要需求总结 (6) 4目标市场准入需求分析 (7) 4.1.1 准入要求 (7) 4.1.2 测试标准 (7) 4.1.3 准入需求描述 (7) 5解决方案配套需求分析 (7) 5.1 解决方案配套描述 (7) 5.2 配套要求总结 (7) 6E2E交付需求分析 (8) 7商业模式需求分析 (8) 8价格需求分析 (8) 9现有产品组合需求满足度评估分析 (8) 9.1 我司市场需求满足度评估 (8) 9.2 竞争对手市场需求满足度评估 (9) 9.3 竞争力需求分析 (9) 10需求汇总和策略分析 (9) 11文档评审Checklist (9) XXX 产品市场需求分析报告
《需求分析训练营》 学员手册
问题卡片问题概述 问题机会 编号VT-001 描述物资供应会出现脱节的情况，每月会出现1-2次。范围与 限制 针对体检业务所需的生产性物资。 问题影响了谁 体检科室、物资供应中心，体检客户 产生什么后果物资短缺会导致某些体检无法正常进行，或者无法及时得出体检结果，导致体检客户的满意度下降 解决方案要点通过安全库存（根据物资消耗速度和采购周期确定）的管理策略，确保避免物资供应脱节现象的出现 问题分析
问题卡片问题概述 问题机会 编号VT-002 描述团队体检的预约安排会出现撞单现象，太多预约安排在同一天范围与 限制 问题影响了谁 体检门店 产生什么后果1）体检部门出现忙时超负荷运转，并使散客接待量减少；闲时又出现资源浪费2）体检客户排队时间过长，导致满意度大幅下降 解决方案要点1）在客服中心内部实现预约时间的共享 2）根据体检门店的设施配置对体检总量进行有效控制 问题分析
项目名称填写人 问题卡片 问题概述 问题机会 编号VT-003 描述在手工作业下，门店管理标准化流程无法得以有效保障，信息无法有效采集和再利用范围与 限制 当前及未来的门店 问题影响了谁 客服中心、体检门店（包括服务中心、体检科室、综合科）、体检客户 产生什么后果1）流程不统一，降低效率 2）用户无法获得历史的体检结果 3）综合科医生无法有效地利用原有的健康建议 解决方案要点1）固化流程，使管理更加有效；同时支持灵活的流程定制 2）全面记录体检单、体检结果和诊断报告，为用户提供更多的增值服务，便于服务的继承和延续性 问题分析
项目名称填写人 Stakeholder列表 类别名称说明相关度筹码量使用者客服中心经理对电话销售、预约安排、客户服务进行管理高 物资供应中心经理对物资采购、申领、仓管进行管理高 财务部经理日常的财务管理，大客户的收费中 门店店长高 服务中心经理开单、收费、返回报告的管理中 体检科室主任执行体检、生成体检结果中 综合科主任出具诊断报告中
需求分析报告 1.引言 1.1目的 说明编写这份报告的目的，指出预期的读者。 1.2背景 指出待开发的软件系统的名称；行业情况；本项目的任务提出者、开发者、用户；该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3参考资料 列出编写本报告时参考的文件(如经核准的计划任务书或合同、上级机关的批文等)、资料、技术标准，以及他们的作者、标题、编号、发布日期和出版单位。 列出编写本报告时查阅的Intenet上杂志、专业著作、技术标准以及他们的 1.4术语 列出本报告中用到的专门术语的定义。 2.任务概述 2.1目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中的其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。
2.2系统（或用户）的特点 如果是产品开发，应列出本软件的特点，与老版本软件（如果有的话）的不同之处，与市场上同类软件（如果有的话）的比较。说明本软件预期使用频度； 如果是针对合同开发，则应列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件预期使用频度。这些是软件设计工作的重要约束。 3.假定和约束 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。 4.需求规定 4.1软件功能说明 逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明产品的容量，包括系统应支持的终端数和应支持的并行操作的用户数等指标。 4.2对功能的一般性规定 本处仅列出对开发产品的所有功能（或一部分）的共同要求，如要求界面格式统一，统一的错误声音提示，要求有在线帮助等。 4.3对性能的一般性规定 4.3.1 精度 说明对该系统的输入、输出数据精度的要求，可能包括传输过程中的精度。 4.3.2 时间特性要求 说明对于该系统的时间特性要求。 4.3.3 灵活性 说明对该系统的灵活性的要求，即当需求发生某些变化时，该系统对这些变化的适应能力。 4.4输入输出要求 解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。 对系统的数据输出及必须标明的控制输出量进行解释并举例。
软件产品需求分析过程思考 很多人认为,软件的需求过程只有在做企业的软件时才用的上,因为要和客户打交道,要定需求才开发系统,原则上这样去做企业软件是没有问题,需求的过程管理,更多的是为了界定需求的边界防止客户扯皮的问题,也为以后的系统现实阶段奠基石.而网站,互联网的产品更多的好像没有这个需求的过程,我做的那个JJY 的产品,基本上需求是是大家凑出来,过程基本上没有,需求的过程控制的很一般.没有内功,不知道以后在产品需求发生变化或扩大时会有什么问题发生. 以下是做企业软件的需求过程管理以作为参考: 众所周期，软件需求分析是软件生命周期的第二阶段，主要对前期软件定义及计划阶段提到的任务及计划进行概要的补充，需求分析的主要任务不是确定将来的系统怎么完成某项工作，这是设计阶段的事情，而是明确系统将要完成什么功能，对目标系统将要完成的功能提出完整、准确的描述等;在我们国内很多软件公司里，需求分析阶段与设计阶段没有明确的界线，需求分析阶段的很多工作，都会放到设计阶段来做或干脆不做，一般很少严格按照软件工程的方法来执行(通过CMM认证的软件公司还好些)，大多数人理解下的需求分析阶段的任务主要还是分三部分：需求的收集、需求整理与编写及最终的评审，在此就这几个阶段中经常遇到的问题作一下大体描述。 一、需求的收集 无论是老产品的改造还是新产品的开发，都需要收集大量的需求作为改造的重点对象，需求的收集也可笼统的分二大部分：内部需求与外部需求;内部需求一般包括软件在维护过程中客户反馈的未处理的需求、公司内部其它各部门在实施软件过程中反馈的需求及设计或研发人员在工作当中总结的对软件易用性、效率等方面的需求，还包括研究竞争对手的软件而得出的需求等;外部需求一般包括软件实施人员或代理商对产品提出的改造建议、设计人员直接到客户现场调研、通过与客户沟通而得到的需求等。在收集需求的过程中常会遇到以下几方面的问题： 1、误解客户需求，一般情况下需求分析人员与客户在业务术语表达上有所不同，交流过程中可能会理解有误，特别对于有二义性的需求，会导致分析人员误解客户的需求，也可以理解为需求表达比较模糊，不同的人有不同的理解。 2、需求的不确定性，一是分析人员对需求把握不准，有些从各个渠道反馈回来的需求有些失真，不能完全表达客户的意愿;二是客户需求的变动较大，不确定，不到真正实用很难表达清楚要实现的功能。 3、对时间的合理规划，收集过程中经常感觉时间太紧，无法完整的收集到客户的需求，这一点主要还是跟事先没有计划好有关，需求的收集是一个长期的过程，而不是在某一时间段内就能收集完的，好的需求在于平时的积累，是在日常维护工作中逐渐收集形成的。