产品需求分析解析
产品需求分析：从用户到需求文档的历练
产品定位
这是产品设计的方向，也是需求文档和设计产出的判断标准。此外，产品定位也是团队成员形成统一的目标和对产品的认识，提高团队的凝聚力和工作效率，可以这么说，产品定位是需求中的需求。
那什么是产品定位呢？
一些产品经理和设计师沟通时候，往往会把功能、业务逻辑梳理得很清楚，但却忘记了把产品主要面向对象、他们的使用场景如何，还有产品的功能、特色等也说清楚，这就会导致设计师很难做决策。
这里可以看出，产品定位实际上就是关于产品的目标，范围、特征等约束条件，主要包括两个方面的内容：产品定义和用户需求。
产品定义由PM得出，用户需求由UED得出，但这一般只出现在大型项目or有充足团队配置的情况中，实战案例更多是PM一手操办，Orz，三头六臂的哪（P）吒（M）啊。
其中产品定义中的主要功能、产品特色和用户需求中的目标用户形成了产品定位中最核心的内容，是产品设计最主要的依据和方向。
产品定义
产品定义就是用一句话概括某个产品，一般可以这么说：
该产品主要面向XX用户提供XX功能，具有XX特色。
这里可能会有疑问，对于一些全用户的产品例如微信、淘宝怎样准确描述呢？这其实有个小小的误区，对于这些发展历程已久，业务迭代升级变化较大的产品，现在的意识形态早已不是当初的样子。微信当初不就是想取代手机短信的功能吗。所以产品定义也是会升级迭代的。
如果你的产品很难用一句话描述清楚，要么就是定位不清晰、方向不明确，要么你正在做的是类似微信一样的超级产品，企图连接一切。而对于创业者来说，连自己都无法流利简洁描述你的产品，那么跟着混的兄弟似乎就要对这个leader多一点存疑了。
举个栗子：陌陌
使用人群：80后、90后单身人群
主要功能：发展基于地理位置的陌生关系
产品特色：LBS搜索用户和群组
有了产品定义之后，可以迫使产品经理努力思考产品的方向和机会，在竞争中寻找差异化，也限定大致的范围，让团队不至于茫然。
用户需求
用户需求就是在具体场景中，目标用户的目标事件。根据一定方法（头脑风暴、调研访谈等），可以得出用户需求示意列表。
值得注意的是，用户类型不是绝对的互斥和独立，更多是以主要取向为区分标准，这不影响后面的筛选和匹配。
其中目标用户是最为关键的，明确目标人群可以使你更专注于服务某一类特定人群，这样更容易提升这类人群的满意度，也更容易使产品做到差异化和成功。
产品是给用户用的，钱也是用户掏的。选择哪种类型的用户作为目标用户，需要综合权衡用户对公司的价值和潜在用户量。
通常会优先考虑最右上角的用户（潜在量大，价值高）。
确定目标用户类型后，就可以筛选匹配出相应的场景和需求。整个过程包含大量思考和决策，因此产品经理需要做足准备工作，包括：了解市场调研结果（趋势、相关联行业或者产品的态势）、了解市场上同类产品的情况（竞品分析）、了解潜在用户的基本情况、了解公司、团队的优势和劣势等等。
需求来源
确定产品定位之后，然后通过不同的方式来收集大量的需求，然后根据这些需求的有效性和真实性、产品定位和项目资源情况进行筛选和匹配，提炼出产品需求，定义出优先级。从产品定位到需求优先级，整个过程不仅涉及对用户的分析和理解，还包括了对产品定位、项目资源的考虑。
需求来源可以大致分为以下几种，其中竞品分析、产品数据、用研是从产品层提出，老板敏锐的眼光则是“人为”思考的结果。
通过五花八门的渠道收集到一堆需求之后，不可能全部都能做，需要按照一定规则和流程，筛选出来最有价值的需求，将有限的投入产出最大化。
其中有一个较重要的环节，也是考验PM能力的地方，透过现象看本质，挖掘用户的真实需求（有个经典的故事：汽车之父亨利·福特曾有一个经典的句子：“如果我问客户他们想要什么，他们总是说想要更快的马。
这里谨记两条：
倾听用户不等于听从用户
用户想要什么不等于真实需求
需求文档
经历完需求筛选和优先级定义之后，通常可以得到需求列表，负责各个功能的产品经理就可以领任务去写PRD了（对于一般更新迭代的需求，可能筛选完之后只有一两条需求，优先级都不需要定义，就可以直接开写了）。
下面是标准需求文档的内容示例：
①文档备案：包括文档日期、版本号、修改人、修改内容和审核人等信息，一般以表格形式位于文档开头。
②目录：方便阅读
③背景描述：为什么要做这个产品/模块，市场行情，业务目标，产品定位等
④用户类型：简单地描述目标用户的情况
⑤项目时间安排：启动、结束等时间节点
⑥信息结构：简单理解为内容和页面的层级
⑦业务流程说明：以流程图形式说明业务各个状态间的切换逻辑（例如：游戏服务器满人时候需要切换到排队登录状态）
⑧需求详细说明：每一条需求的详细说明（包括：使用场景、UI描述、功能描述、优先级、输入/输出条件、处理流程、补充说明等）
⑨涉及关联业务部门的支持，还需要特别备忘。
如同设计稿，代码一样，需求文档很难一次成型，需要不断修改，在评审中发现问题是很正常的。
需求分析广义上看包括了需求获取和分析筛选两个方面。产品定位是确定产品需求的根本依据，而目标用户则是产品定位的标尺。要想得到正确的需求，PM需要全程参与，充分准备，深入到各个关节中，并且充分听取不同成员的意见。
上述方法论是标准化流程，实战运用，不同公司不同项目会有更接地气的一套过程，本文谨对新人作分享和启发之用。需求文档的撰写同理，引用在京东实习时候，曾经就PRD模版和导师有关一些讨论，最后导师给出的意见是：根据需求和进度来灵活变通，切勿迷恋所谓模版。尤其移动互联网时代。仅以此话与诸君分享。
文章内容提炼于刘津老师和李月老师的《用户体验设计师的成长之路》，力荐阅读原作，之后会出系列读书笔记，围绕用户体验设计相关话题而谈。
软件需求分析的详细流程
第一阶段：总体把握，了解概况 接手一个项目，不要着急去了解需求，这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的职能部门，最好能指定本次项目的接口人。 该阶段的主要工作方法：客户访谈 输出成果：业务流程报告/调查报告（对客户方的组织业务概况和企业现状的一些总结） 第二阶段：详细了解业务，梳理业务流程 通过第一阶段的调研，了解客户业务概况的前提下，经过充分的业务调研准备，开始进入正式的业务调研工作。这一阶段要对所有业务流程、业务单据、报表等进行详细的分析。整理出业务架构，尽可能多的与相关基层人员进行诱导式的访谈，与用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。对主要的业务流程要有原型DEMO让客户操作，发现问题，提出改进的意见和建议。 该阶段的主要工作方法：访谈、业务分析、原型设计演示 输出成果：调研分析报告、原型反馈报告、业务流程报告 第三阶段：需求细化和确认 这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表以及操作承建方提供的DEMO系统，来提出反馈意见，并对已经可接受的报告、文档签字确认。 实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统 输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认和存档）
产品需求分析思路
产品需求分析(上) –理论流程 作者: 唐杰 分类: 产品设计 发布时间: 2014-05-03 14:29 好几个朋友让我分享一下产品需求分析，我想了好久也没发现有什么可说的。这主要是我在工作中很少把需求分析当成规范性的操作流程，通常我都是在脑海里直接判断需求，而且在绝大多数的公司里，也没有规范的需求分析标准，常常都是由诸多因素直接影响并决定了需求。出现这样的情况，也是职业属性决定的，因为产品类的工作带有很多主观性因素。 既然要讲产品需求分析，那么就先要知道这在产品实现过程中处于哪个环节。无论是新产品还是迭代产品，首先由想法产生需求，然后需求汇集并分析，放弃掉不需要的，暂缓不紧急的，然后整理出需要下一步执行的，最终形成产品需求文档并实施。 在汇集分析之前，需求的产生来自各个方面，由不同的人产生想法并表述反馈给产品经理，因此产生需求，主要来自公司内部(老板、其他部门或同事)、产品经理自己(策划、挖掘)、外部(用户、客户、伙伴)。 通过上面的梳理，我们就清晰的认识到，产品需求分析实际上就是需求决策。无论是自己的创新想法，还是市场调研，或者说来自其他方面的需求，最终汇集到产品经理手里的需求分析，就是决策哪些要做、为什么要做、怎么做，同时也要给出哪些不能做、哪些暂缓做、为什么不能或暂缓。 需求分析之前我们先要对需求进行分类，每个公司或产品都有不一样的分类喜好，通常有功能类、数据类、运营类、体验类、设计类等等，分完类之后再对需求进行权重考虑并决策。 需求决策有三个基本考虑因素，分别是战略定位、产品定位、用户需求。这是一个层级的关系，战略定位决定了产品的位置，有些公司的产品在战略上只是需要有这样一个产品，也仅仅是需要有，有不代表非要做好，既然不要做好，也就不会有大的资源投入，更谈不上需求的迭代，所以战略定位是首要的需求决策因素。其次是产品定位，产品定位决定了哪些需求是必要的，哪些需求是多余的，同时也影响着用户需求的取舍。 基于三大考虑因素，我们对需求进行了筛选，之后还需要进行分位，即使用“四象限定位法”进行需求分位，将需求划分成“重要又急需、重要但不急需、不重要但急需、不重要也
客户需求分析
客户需求分析 客户需求分析($APPEALS)概述 $APPEALS是一种了解客户需求的、确定产品市场定位的工具。一般是使用在市场规划和产品规划的细分市场中，因为可以从多个维度，不同的权重来分析需求，所有$APPEALS一定会联系到细分市场，联系到竞争对手，涉及到差异化分析和蓝海的价值创新(减少，增加，剔除，创新)。差异化可以说是理解市场和分析市场中的一个重要内容，只有清楚了差异化才能够树立自己产品的核心竞争力。客户需求分析 ($APPEALS)的内容： $APPEALS方法是IBM在IPD总结和分析出来的客户需求分析的一种方法。它从8个方面对产品进行客户需求定义和产品定位。具体如下：$-产品价格（Price）；A-可获得性（Availability）；P-包装（Packaging）；P-性能（Performance）；E-易用性（Easy to use）；A-保证程度（Assurances）；L-生命周期成本（Life cycle of cost）；S-社会接受程度（Social acceptance）。客户需求分析($APPEALS)内容框架的目的 使用客户$APPEALS框架来确定客户的欲望与需要，建立针对每一个细分市场的产品包对应图。客户$APPEALS框架的目的主要包括以下方面的内容: 处理目标细分市场的全部客户欲望与需要建立客户驱动的需求集，作为投资的重点确定要想在所选细分市场获得成功必须达到的主要分界标准确定促使客户选择公司产品的主要差异 客户需求分析($APPEALS)的内容详解 $价格 这个要素反映了客户为一个满意的产品/交付希望支付的价格。用这个标准来要求供应商时，要从实际和感觉这两方面来考虑客户能接受的购买价格。将包括以下的数据评估：技术、低成本制造、物料、人力成本、制造费用、经验、自动化程度、简易性、可生产性等。 A保证
需求分析方法论
需求分析方法论 原则上，需求分析阶段IT中心应尊重需求方的项目管理和项目分析能力；在具体的任务开展上，以不干扰需求方的自主权为主，除非在项目过程中发现需求方的项目管理以及项目分析能力存在很大的差距和不足。 为了保证项目的成功，IT中心必须加强项目管理和项目分析工作，在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。 其中，需求分析是一个项目的开端，也是项目建设的基石。在以往的信息化建设失败的案例中，80％是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。而项目的整体风险往往表现在需求分析不明确、业务流程不合理，用户不习惯或不愿意去用应用管理软件。作为IT中心，必须提醒需求方重视需求分析的重要性，采用必要的手段和方法来进行需求调研，同时IT 中心也应深入具体的需求调研中去。只有这样才能切切实实地把握用户的需求和方向，才能在将来的功能界定、实施上有发言权。 一、如何进行需求分析 需求分析不象侦探推理那样需从蛛丝马迹着手，而是应该先了解宏观的问题，再了解细节的问题。 一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。 S={D1，D2，D3，…Dn} 问题域Di由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。 Di={P1，P2，P3，…Pm} 问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。 Pj={F1，F2，F3，…Fk} 需求说明书应该对于那些只想了解宏观需求的领导，和需要了解细节的技术人员都合适。在写需求说明书时应该注意两个问题： 1、最好为每个需求注释“为什么”，这样可让双方（IT中心、需求方）了解需求的本质，以便选用最合适的技术来实现此需求。 2、需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。 二、重点监控需求分析 由于项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软件需求分析的重要性是不言而喻的，同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。 1、用户说不清楚需求 有些用户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如总部各部门及各地的很多店铺在进行应用系统以及网络建设时，需求方的办公人员大多缺乏IT系统建设方面的专家和知识。此时，用户就会要求IT中心系统分析人员替他们设想需求。项目的需求存在一定的主观性，为项目未来建设埋下了潜在的风险。 2、需求自身经常变动 根据以往的历史经验，随着用户对信息化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。事实上，历史上没有一个软件的需求改动少于三次的！所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在系统选型及实施时，将软件的核心建筑在稳定的需求上，同时留出变更空间。IT中心在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分析的准备中来，以便协助需求方来界定“做什么”、“不做什么”的系统功能界限。 3、IT中心分析人员或用户理解有误 系统分析人员不可能都是全才，更不可能是行业方面的专家。用户表达的需求，不同的分析人员可能
产品需求分析解析
产品需求分析：从用户到需求文档的历练 产品定位 这是产品设计的方向，也是需求文档和设计产出的判断标准。此外，产品定位也是团队成员形成统一的目标和对产品的认识，提高团队的凝聚力和工作效率，可以这么说，产品定位是需求中的需求。 那什么是产品定位呢？ 一些产品经理和设计师沟通时候，往往会把功能、业务逻辑梳理得很清楚，但却忘记了把产品主要面向对象、他们的使用场景如何，还有产品的功能、特色等也说清楚，这就会导致设计师很难做决策。 这里可以看出，产品定位实际上就是关于产品的目标，范围、特征等约束条件，主要包括两个方面的内容：产品定义和用户需求。
产品定义由PM得出，用户需求由UED得出，但这一般只出现在大型项目or有充足团队配置的情况中，实战案例更多是PM一手操办，Orz，三头六臂的哪（P）吒（M）啊。 其中产品定义中的主要功能、产品特色和用户需求中的目标用户形成了产品定位中最核心的内容，是产品设计最主要的依据和方向。 产品定义 产品定义就是用一句话概括某个产品，一般可以这么说： 该产品主要面向XX用户提供XX功能，具有XX特色。 这里可能会有疑问，对于一些全用户的产品例如微信、淘宝怎样准确描述呢？这其实有个小小的误区，对于这些发展历程已久，业务迭代升级变化较大的产品，现在的意识形态早已不是当初的样子。微信当初不就是想取代手机短信的功能吗。所以产品定义也是会升级迭代的。 如果你的产品很难用一句话描述清楚，要么就是定位不清晰、方向不明确，要么你正在做的是类似微信一样的超级产品，企图连接一切。而对于创业者来说，连自己都无法流利简洁描述你的产品，那么跟着混的兄弟似乎就要对这个leader多一点存疑了。 举个栗子：陌陌 使用人群：80后、90后单身人群 主要功能：发展基于地理位置的陌生关系 产品特色：LBS搜索用户和群组 有了产品定义之后，可以迫使产品经理努力思考产品的方向和机会，在竞争中寻找差异化，也限定大致的范围，让团队不至于茫然。 用户需求
需求分析主要流程
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）：对（软件）系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场
产品需求分析与需求管理——如何搞定市场需求
产品需求分析与需求管理——如何搞定市场需求 主讲：董奎（十多年高科技企业的研发与管理实践经验，在某著名高科技企业工作期间，先后担当项目经理、系统工程师、产品经理、软件部经理） 课程对象：企业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.根据工程总目标，明确调研目标、层次; 2.根据目标设计调研方式,编写调研提纲，确定调研对象; 3.编写每阶段调研日记，汇总完善调研报告; 4.画出标准业务流程图，做到全面清晰； 5.绘制数据流程图； 6.以简明清晰的思路，浅显易懂的自然语言描述业务步骤； 7.找出业务关键点及瓶颈工序； 8.编写供参考的先进的方法与改进建议。 分阶段调研目标与规定 第一阶段：初步调研 调研目标 初步调研首要目标是对企业全局的了解，可具体分解为： 1.企业概况 2.企业的经营特点 3.企业的生产特点 4.企业的组织机构 5.企业行业地位 6.企业技术现状 调研对象 1. CIMS工程总负责人，必要时邀请总经理参加 2. 总部各职能科室负责人 调研方式 1. 参阅公司资料为主 2. 配合问答 调研范围 了解企业总体概况 调研时限 根据公司规模及组织结构的复杂程度，掌握在2～7天左右
调研提纲 一、针对企业概况，了解以下问题： 1.企业背景，历史演变过程 2.企业所属行业 3.企业的资产、产值、利税等生产经济指标 4.企业人数及素质 5.企业体制、组织机构 6.其它有关情况 二、针对企业经营特点做以下调研： 1.经营机制、目标 2.销售策略 3.财务制度、成本分摊办法、独立核算情况 三、针对企业生产特点做以下调研： 1. 企业产品的种类、型号、技术含量、结构特点、市场占有率 2.企业生产方式： ａ是离散、连续或半连续 ｂ生产批量：是多品种小批量还是单件大批量生产 ｃ是按订单还是按库存或其他方式组织生产 3.企业的产量、产值、利润目标 4.对产品使用安全性的要求，对使用环境的要求 四、针对企业组织机构做如下调研 1.绘制组织结构图 2.描述各职能科室职责 3.对企业的生产流程做简明调研 4.各分公司或子公司的总体概况、相互关系、与母体公司的关联程度 五、针对企业的行业了解下述情况 1.企业在行业及整个国民经济中的地位 2.产品的市场占有率 3.行业发展现状、企业的竞争目标 六、针对企业技术现状做如下调研 1.企业设备、先进、精密、自动化程度 2.计算机资源情况、数量、型号，可自动化系统的应用情况 3.技术人员的水平、能力 调研的注意事项 初步调研是针对公司总概况的调研，绝大部分公司对上述内容都有文件档案。顾问调研前一定要详细阅读相关资料，找出关键点与有疑问的地方重新拟定调研提纲，做到简洁、明快，尽量减少介绍人员对熟悉事物的反复介绍。 第二阶段：现状分析 在第一阶段的调研基础上对各职能科室及分公司做进一步调研
需求分析(一)概念、方法、实践步骤
需求分析(一)概念、方法、实践步骤 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）：对（软件）系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说
软件需求分析报告文档模板1
软件需求分析报告文档模板 姓名 日期
1. 引言 (3) 1.1编写目的 (3) 1.2项目风险 (3) 1.3文档约定 (3) 1.4预期读者和阅读建议 (3) 1.5产品范围 (4) 1.6参考文献 (4) 2. 综合描述 (4) 2.1产品的状况 (4) 2.2产品的功能 (5) 2.3用户类和特性 (5) 2.4运行环境 (5) 2.5设计和实现上的限制 (5) 2.6假设和约束(依赖) (6) 3. 外部接口需求 (6) 3.1硬件接口 (6) 3.2软件接口 (7) 3.3通讯接口 (7) 4. 系统功能需求 (7) 4.1说明和优先级 (8) 4.2激励／响应序列 (8) 4.3输入／输出数据 (8) 5. 其它非功能需求 (8) 5.1性能需求 (9) 5.2安全措施需求 (9) 5.3安全性需求 (9) 5.4软件质量属性 (9) 5.5业务规则 (9) 5.6用户文档 (10) 6. 词汇表 (10) 7. 数据定义 (10) 8. 分析模型 (11)
1. 引言 引言是对这份软件产品需求分析报告的概览，是为了帮助阅读者了解这份文档是如何编写的，并且应该如何阅读、理解和解释这份文档。 1.1 编写目的 说明这份软件产品需求分析报告是为哪个软件产品编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格，包括修正和(或)发行版本号，从而对该软件产品进行准确的定义。 如果这份软件产品需求分析报告只与整个系统的某一部分有关系，那么只定义软件产品需求分析报告中说明的那个部分或子系统。 1.2 项目风险 具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括： ●任务提出者； ●软件开发者； ●产品使用者。 1.3 文档约定 描述编写文档时所采用的标准(如果有标准的话)，或者各种排版约定。排版约定应该包括： ●正文风格； ●提示方式； ●重要符号； 也应该说明高层次需求是否可以被其所有细化的需求所继承，或者每个需求陈述是否都有其自己的优先级。 1.4 预期读者和阅读建议 列举本软件产品需求分析报告所针对的各种不同的预期读者，例如，可能包括： ●用户； ●开发人员； ●项目经理； ●营销人员； ●测试人员； ●文档编写入员。 并且描述了文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议。
产品需求文档系统需求分析说明书
系统需求分析说明书
文档历史记录 注：后期所加内容均绿色背景字体标注 目录 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目标&意义 项目目标： 完整保存教师信息；
聊天软件客户需求分析
聊天软件客户需求分析 文档编号： AX-TE-XQFX-001 记录号：文档版本： <文档版本> 文档密级： 2009年5月 项目编号文档编号项目名称聊天软件 标题需求分析报告 类别需求文档 当前阶段需求规划 摘要 当前版本 V1.0 日期 作者姜奇巍 文档拥有者姜奇巍 送交人员宋军 文件《聊天软件需求方案》 2009-06-07 创建 V1.0 vinson 1. 功能模块（子系统组成）.................................................................... ...................................................... 4 2. 网络拓扑 图 ..................................................................... ........................................................................ .... 4 3. 功能需求分 析 .....................................................................
........................................................................ 5 3.1 客户登 陆 ..................................................................... . (5) 3.1.1 客户登陆 / ...................................................................... (5) 3.1.1 关键数据...................................................................... .. (5) 3.1.2 用户交互界面...................................................................... (5) 3.1.3 业务处理描述...................................................................... (6) 3.2 聊天室功 能 ..................................................................... (6) 3.2.1 聊天室功能说明...................................................................... .. (6)
项目需求分析
需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到：SRS文档（system requirement Specification）；2.DRM文档；3. Acceptance Plan. 从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。 狭义上理解：需求分析指需求的分析、定义过程。 一、为什么要需求分析 需求分析就是分析软件用户需求是什么。如果投入大量的人力，物力，财力，时间，开发出的软件却没人要，从发重新开发过，这种返工是让人痛心疾首的。（相信大家都有体会）比如，用户需要一个for Linux 的软件，而你在软件开发前期忽略了软件的运行环境，忘了向用户询问这个问题，而想当然的认为是开发fox window的软件，当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，恨不行找块豆腐一头撞死。 需求分析之所以重要，就因为他具有决策性，方向性，策略性的作用，他在软件开发的过程中具有举足轻重的地位。大家一定要对需求分析具有足够的重视，在一个大型软件系统的开发中，他的作用要远远大于程序设计。 二、需求分析的任务 简言之，需求分析任务就是解决“做什么”的问题，就是要全面地理解用户的各项要求并准确地表达所接受的用户需求。 需求分析的过程 需求分析的工作，可分为四个方面：问题识别、分析和综合、制订规格说明、详审。问题识别 就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些要求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求（做什么），性能需求（要达到什么指标），环境需求（如机型，操作系统等，）可靠性需求（不发生故障的概率），安全保密需求，用户界面需求，资源使用需求（软件运行是所需的内存，CPU等），软件成本消耗与开发进度需求，预告估计以后系统可能达到的目标。 分析与综合
软件项目必须做客户需求分析
软件项目必须做客户需求分析 项目需求分析，深有感触，被这个问题整天困扰：客户需求，为什么总在变阿？做项目真辛苦阿！这样的感叹整天都挂在口上。客户需求变动确实是一个软件开发人员永远不变的话题。？到底要怎么做才能满足客户的需求？ 我们要揭露这个问题存在的根源。 需求分析，不仅仅是拿到客户的需求，更重要的是还需进行分析，了解细节，并就细节跟客户咨询，获取最详细的资料。客户所能提供给你的只是他们想到的功能需求，很多问题并不在他们考虑的范围之内，如果作为项目承担方没有去做分析，简单的按照功能要求去设计、规划，最终出来的系统是很难完全符合客户的业务流程的，这时，自然需要更改，被看成了需求的更改。其实，都是缺乏分析所一手造成的。问题等到系统出来了才被发现，这样的系统本身就是先天不足的了。 “其实问题出在开头，客户需求只是软件需求分析的一部分，虽然是比较重要的一部分，但也不要只是去记客户的需求，而是要把客户的需求进行分析” “客户本身是不怎么懂技术的，客户只知道自己的业务需求，而在软件设计时，是在把业务需求抽象到系统中实现的，把业务转变为逻辑时，一切都应该符合逻辑的，但客户的业务思想有时候在软件系统实现时会有问题的，这就需要分析时分析出来的。少了分析，问题也会在后面的开发中暴露出来，到时可就更麻烦了。” 还有客户的需求本身会有矛盾（这矛盾是指在逻辑角度来讲），客户本身是意识不到的，只有在分析设计时，才会分析出这里的矛盾，而这些问题，如果在期初时，软件负责人不分析，而是纯粹的“听从”客户要求去做，当暴露这些问题时，你怪客户也没用啊。 项目需求分析报告，在了解客户需求时，不要不动脑子，不要一味的点头说“I C”，其实在表面的业务里面可能包含着N多的细节，这些细节是需要你反问客户的，只有当你提的问题越多，最终获取的需求最具体，才能让项目越顺利。而且有很多问题，都是在你的反问中，客户也才开始思考本来没思考过的问题，客户也会找到一种合理的需求给你，有人会觉得这样了解客户需求未免太麻烦了。至于一些在技术上会遇到问题的地方，也要告诉客户，别以为到时候再说，客户是不关心你的技术细节的，但你如果给他解释的话，他也会试着理解的。 客户的需求本身是无休止，因为他们本身也在变，但当你期初的分析合理，后面的变动也将在逻辑上变动，相信代价已经不会那么大了。这其实也体现了系统的扩展性。 需求分析，是一个项目提出方和承担方相互沟通的过程，一方是系统的使用者，一方是系统的制造者，在系统制造过程中，只有双方相互配合，共同对系统进行设计才能最后达到使用的要求。客户是业务上的熟悉者，对业务流程有非常清晰的了解，但是，对于软件需求方
一种界面需求分析的方法
软件界面是人与计算机之间的媒介。用户通过软件界面来与计算机进行信息交换。因此，软件界面的质量，直接关系到应用系统的性能能否充分发挥，能否使用户准确、高效、轻松、愉快地工作，所以软件的友好性、易用性对于软件系统至关重要。目前国内软件开发者在设计过程中很注重软件的开发技术及其具有的业务功能，而忽略了用户对软件界面的需求，影响软件的易用性、友好性；对界面设计的研究也集中在界面设计技术、设计手段上面。软件开发人员在设计时以经验为参考依据，缺乏对实际用户需求的了解。而软件的友好性、易用性同用户特征紧密相联，同样的软件界面，不同用户可能有绝然相反的评价。因此分析用户特征、了解用户需求和操作习惯，是开发软件界面的必有步骤，必须引起足够重视。 本文讨论了一种界面需求分析的方法，意在探讨研究如何完成针对系统所有用户的界面需求定义,从而开发为用户所接受的界面。讨论该方法的目的在于帮助设计人员快速明确用户的界面需求，让用户充分参与到界面需求分析中，从而在最终界面需求说明中体现用户的思想，满足用户要求。 2、界面需求分析过程 2．1界面元素 通常一个软件界面的元素包括界面主颜色、字体颜色、字体大小、界面布局、界面交互方式、界面功能分布、界面输入输出模式。其中，对用户工作效率有显著影响的元素包括：输入输出方式、交互方式、功能分布，在使用命令式交互方式的系统中，命令名称、参数也是界面元素的内容，如何设计命令及参数也很重要。影响用户对系统友好性评价的元素则有：颜色、字体大小、界面布局等，这种划分不是绝对的，软件界面作为一个整体，其中任何一个元素不符合用户习惯、不满足用户要求都将降低用户对软件系统的认可度，甚至影响用户的工作效率，而使用户最终放弃使用系统。围绕界面元素所要达到的设计目的是让最终用户能够获得美感、提高工作效率、易于操作使用系统。 目前在界面元素的选择、布局设计等方面的研究进行得较多,内容涵盖了人机工程学、认知心理学、、美学、色彩理论等方面的探讨。
需求分析过程产物
《需求分析训练营》 学员手册
问题卡片问题概述 问题机会 编号VT-001 描述物资供应会出现脱节的情况，每月会出现1-2次。范围与 限制 针对体检业务所需的生产性物资。 问题影响了谁 体检科室、物资供应中心，体检客户 产生什么后果物资短缺会导致某些体检无法正常进行，或者无法及时得出体检结果，导致体检客户的满意度下降 解决方案要点通过安全库存（根据物资消耗速度和采购周期确定）的管理策略，确保避免物资供应脱节现象的出现 问题分析
问题卡片问题概述 问题机会 编号VT-002 描述团队体检的预约安排会出现撞单现象，太多预约安排在同一天范围与 限制 问题影响了谁 体检门店 产生什么后果1）体检部门出现忙时超负荷运转，并使散客接待量减少；闲时又出现资源浪费2）体检客户排队时间过长，导致满意度大幅下降 解决方案要点1）在客服中心内部实现预约时间的共享 2）根据体检门店的设施配置对体检总量进行有效控制 问题分析
项目名称填写人 问题卡片 问题概述 问题机会 编号VT-003 描述在手工作业下，门店管理标准化流程无法得以有效保障，信息无法有效采集和再利用范围与 限制 当前及未来的门店 问题影响了谁 客服中心、体检门店（包括服务中心、体检科室、综合科）、体检客户 产生什么后果1）流程不统一，降低效率 2）用户无法获得历史的体检结果 3）综合科医生无法有效地利用原有的健康建议 解决方案要点1）固化流程，使管理更加有效；同时支持灵活的流程定制 2）全面记录体检单、体检结果和诊断报告，为用户提供更多的增值服务，便于服务的继承和延续性 问题分析
项目名称填写人 Stakeholder列表 类别名称说明相关度筹码量使用者客服中心经理对电话销售、预约安排、客户服务进行管理高 物资供应中心经理对物资采购、申领、仓管进行管理高 财务部经理日常的财务管理，大客户的收费中 门店店长高 服务中心经理开单、收费、返回报告的管理中 体检科室主任执行体检、生成体检结果中 综合科主任出具诊断报告中