产品需求

1.axute的使用方法； 2.普通线框图的使用； 3.高保真原型图； 4.交互思维。 Axure RP8 是美国Axure Software Solution公司的旗舰产品，是一个快速的原型工具，主要针对负责定义需求、定义规格、设计功能、设计界面等 Axure改变我们的工作方式： —决策层 直观的理解系统行为，帮助决策。 —产品经理 提高了各岗位间的沟通效率，降低沟通成本，保证项目进程。 —需求人员 更加有效的与用户沟通，减少误解，保证需求质量。 —设计开发 更加有效的协作沟通，降低沟通成本，减少误解，避免返工。 —用户 更加直观的感受系统，尽早反馈用户的需求与系统的不足。 互联网产品五要素 战略层：需要明确用户需求和产品目标 用户需求：用户需要从我们产品得到什么，获取方法：用户细分、市场调研、现场调查、用户测试等 产品目标：我们要从这个产品获得什么 范围层：需要明确功能需求和内容需求 功能需求，需要和软件开发同步，应该强调维护和及时更新，反映实际的产品，应根据人力、成本等确定功能需求，避免造成资源浪费、以及成本的不可控。 内容需求常常伴随着功能需求，例如支持IE6/Windows等。 结构层：分为交互设计和信息架构，确定呈现给用户的模式和顺序 交互设计：描述可能的用户行为，系统如何配合和响应这些行为 信息架构：确定呈现给用户的模式和顺序 框架层：分为界面设计和导航设计 界面设计

　　一个完整的开发流程应该有这四步：分析->设计->编码->测试。很多开发团队往往只有编码这边，弱化了其他步骤，他们拿到需求就开始写代码， 写着写着发现有问题，要么是遇到一个难点解决不了，要么是发现要返回修改以前写过的代码， 要么是发现有大量的重复代码，又不知道怎么封装，只能将错就错。做好了分析和设计编码时就不会有这么多问题， 做好了测试产品bug就少，产品质量才高。 下面我分别详细讲解一下这四步。 分析 　　分析的时候，我们要分析需求和难点。 　　分析需求的方法是做需求陈述处理，前面我提到过， 要区分做什么和怎么做，把这两部分独立出来，做什么是固定不变的， 而怎么做可能会经常变。我们再熟悉一下举的那个例子：我们要做一个成员列表（如图1-44），产品经理告诉我们要按姓名拼音排序。 图1-44 成员列表的例子 　　我们有时候不能直接听产品经理的，如果真写死成按姓名拼音排序就没有可扩展性了，比如某一天产品经理又告诉你需要把VIP会员提前，那么你只能再去修改排序的程序。这个需求始终不变的是排序，按姓名拼音只是排序的一种方法，我们在设计数据库时应该把排序字段设置为数字而不是拼音，再写一个拼音转换为数字的算法即可，这样在后面排序规则变化，比如VIP会员要提前，只是修改对应用户数据库的排序字段数值即可，不用大改程序。 　　我们可以用xmind做需求分析，

产品经理经常需要与RD进行需求沟通，有个很有名的幽默漫画是这样画的。 产品的需求，经由产品经理定义成产品规格后，开始找RD讨论。而一切的错，也就从客户（或Product Manager）口中的需求开始。 PM：「我们要发展一种在无重力状态下也可以使用的多功能原子笔，也就是说墨水不会因处在无重力下就无法送达笔尖。」 RD：「这个想法做不到。因为OOXX，所以XXOO」 PM：「可是之前看日本技术展的时候，他们有展示不受重力影响的液体封装技术。你们要不要研究研究，这么快就说做不到，会不会太草率？」 RD心理在干：「你到底有没有听懂我讲话啊？就不可行啊！讲不听。就说产品经理每次都在外面看到什么新玩意，就自己High了起来。明明是外行又要装内行，专门想出一些怪东西来整我们！」 PM又说：「客户说他们对这种产品有很大的需求，这个订单对我们公司很重要。」PM开始拿客户需求这个神主牌来压。 PM心里也干：「这些RD超没干劲，每次开需求给他们，他们东闪西躲，就是不想做事情，老是说做不到，明明就有人做的到。RD都欺负PM在开发知识上不如RD。可恶！」 上面的需求沟通，到底出了什么问题？ 曾经有人教过Mr PM，跟RD沟通，要「态度柔软，但立场坚定」，或是「要怀疑RD说的每一个做不到，要常常找出别人做得到的证据，逼RD就范」 。 PM和RD的关系，就在这些经验传承之下，越来越紧张，不是你压倒我

随着互联网的发展，CRM系统已经被越来越多的企业所认可、接受，被当做一种先进的企业管理理念。但是，由于每个企业的产品及业务流程不同，都有自己独特的功能需求，需要进行定制开发CRM，才能符合企业的发展。那么，CRM系统开发一般需要多久？成本怎么算？ 实际上，决定CRM管理系统开发时间长短的主要有三大因素：需要CRM具备什么功能、产品系统开发难易程度以及所要求的质量。在不明确这三个条件时，是无法告知明确的时间的。 1、功能不同 ：不同开发者对于CRM管理系统的功能需求不同，一般来说，系统功能数量越多，所需的时间就越长，功能数量越少，开发时间也就相对少。 2、产品系统 ：每个开发者开发出来的产品使用的平台都是不同的，所以需要开发不同系统，但不同系统的产品开发难易程度是不一样的，所以需要投入的开发时间也是不同的。 3、质量要求 ：不同开发者对于CRM管理系统有着不同的质量要求，一般而言，要求越高，开发公司需要投入的时间成本就长，要求越低，需要投入的精力就越少，开发时间也就越短。 当然，除了以上三大主要因素，影响开发CRM系统时间长久的因素也还有很多，比如说，哪种搭建方式、需要哪些权限以及需要使用的人数等等，这些都会影响到开发的时间和开发的成本的。所以说，市场上不同的客户开发CRM管理系统，开发周期也是不一样。 在如今这个互联网时代，企业采用CRM系统是必然选择

1、问：你在测试中发现了一个bug，但是开发经理认为这不是一个bug，你应该怎样解决？ 首先，将问题提交到缺陷管理库里面进行备案。 然后，要获取判断的依据和标准： 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据； 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷； 根据用户的一般使用习惯，来确认是否是缺陷； 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷； 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。 等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。 2、问：给你一个网站，你如何测试？ 首先，查找需求说明、网站设计等相关文档，分析测试需求。 制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试 设计测试用例： 功能性测试可以包括，但不限于以下几个方面： 链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回。 提交功能的测试。 多媒体元素是否可以正确加载和显示。 多语言支持是否能够正确显示选择的语言等。 界面测试可以包括但不限于一下几个方面： 页面是否风格统一，美观 页面布局是否合理

PRD（Product-Requirement-Document，产品需求文档），这对于任何一个产品经理来说都不会陌生的一个文档，一个PRD是衡量一个产品经理整体思维的标准，一个PRD可以看出一个产品经理在某个领域的专业性，同时也可以反应出一个产品经理的整体产品思维。 产品经理的整体思维体现在： 1、提炼核心需求 2、思考满足核心需求的方式 3、评估方式优劣选定方案 4、思考功能概要 5、思考支撑功能和关联功能 6、细化设计功能 7、子功能（功能间迭代） PRD其实就是将以上的思维整体走向写出来，同时将产品的思想提炼出来，用文字表示给开发者，给UI、给视觉、给老板……PRD给的是一种思想，将产品的整体思想和核心需求灌输给产品的相关人员，都说PRD是个承上启下的功能，因为上接MRD，下对MRD进行技术性的描述。 网上已经有太多互联网公司的PRD文档，淘宝、百度、腾讯等这类大型互联网公司都有自己的PRD规范，适合企业的需要的PRD才是真正PRD。以淘宝的PRD为例，讲解一下PRD的主要内容。 1、文件命名（编号） 文件的编号很关键，因为产品迭代过程会有不同的文件版本，一般命名规则“公司名+产品名+PRD+D1.0”（以第一版为例），这样命名有利用版本号的迭代，如果是小的产品需求变动可以直接命名为“公司名-产品名-PRD-D1.01”，如果涉及到功能需求增加可以命名为“公司名-产品名

　对于即将步入前端行业的学员，在这里有三个词分享给大家： 沟通，努力，多看。 　　1、沟通。沟通是在工作当中是很重要的一个环节，沟通好了事半功倍，沟通不好事倍功半。在网站开发的整个环节当中前端能接触到的有产品，设计，后台，测试这些岗位的人。产品会根据客户的需求或者是老板的需求把项目的产品原型，需求文档，交互文档给到你们，然后就是各自看各自的，如果有问题大家开会或者QQ群讨论，能修改的修改，修改不了的那就是前端和后台抓耳挠腮的把困难解决掉，而在这个过程中需要的就是良好的沟通，你得说明白你哪些模块有问题，有什么问题能解决还是不能解决，如果说实在的实现不了，那么需求必须的改了，但是一般情况下都是你技术的提升，而不是产品改需求。 　　这个是说的是比较好的情况，产品原型，需求文档，交互文档都有，有些时候是这样的 　　甚至有的时候根本就没有原型图什么什么的，没有，完全没有。这个时候最主要还是详细的沟通，耐心的把所需要了解的环节说清楚，最好是记录下来。更糟糕的是这个公司没有没有专门的产品经理，而是项目经理兼任来管，那么如果项目经理不懂的技术，恰巧在他的职权范围内有决策权，那这个就更加难沟通了。如果你们之间出现了冲突，而你们呢谁都不想拖鞋，那么这个时候就自然而然的把球给了你们的高级的上司那里。那么这个时候就更需要你扎实的技术功底或丰富的行业经验跟老板也好，项目经理也好把问题阐述表达清楚了

1：如何对需求不确定的创新产品进行分析和设计？简要总结一下有哪些方法和策略 1）预测需求：也许本产品比较超前，但是基本上他都是由之前或者现在的产品演变过来的，所以参考已有的产品，并且根据科技发展的轨迹，来预测将来那个时候人们使用这个产品会需要什么功能，以此为基础进行设计 2）参考同类产品：也许你提出的创新性想法已经或多或少的在别人的产品中体现了，仔细分析这些产品，从中总结出自己需要的数据。 有了上面的思想再按照需求分析的步骤一步步进行分析： 需求调研的第一步是调查系统需求，调查系统需求的方法，在前面的课程我们已经讨论过了。在这里主要采用与用户的面谈方式，通过与用户的面谈，找出系统的相关事件，并写出事件列表。 需求调研的第二步是依据前面给出的事件列表，归纳和抽象出系统相关角色，建立角色列表。归纳和抽象系统相关角色，要注意角色不是指具体的人和事务，而是表示人或事物在系统中所扮演的角色。 需求调研的第三步是建立角色用例图，角色用例图是系统需求的功能模型，描述了角色的行为及角色间的关系。每个用例需要给出用例规约，用例规约描述了用例的用例名称、参与角色、与其它用例间的关系、前置条件、后置条件、操作流程、输入与输出数据项等内容。 需求调研的第四步是根据角色和用例模型建立类图模型。一般说来，前面分析的系统角色就是系统中的对象，也称为类。类图模型描述了类的名称、属性及行为，以及类与类之间的关系。

https://www.fun48.com/article-877927-1.html 一、需求分析是什么 需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。 二、软件需求的分类 功能需求 非功能需求：如性能要求 设计约束：用何语言实现 三、对需求不确定的创新产品进行分析和设计的方法和策略 需求分析阶段的工作可以分成 4 个方面： （1）问题识别：用于发现需求、描述需求，主要包括功能需求、性能需求、环境需求、 可靠性需求、安全保密需求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求， 以此来预先估计以后系统可能达到的目标。 （2）分析与综合：也就是对问题进行分析，然后在此基础上整合出解决方案。 常用的方法有面向数据流的结构化分析方法（Structured Analysis， SA），面向数据结构的 Jackson 方法，面向对象的分析方法（Object Oriented Analysis， OOA），以及用于建立动态模型的状态迁移图和 Petri 网。 （3）编制需求分析的文档：也就是对已经确定的需求进行文档化描述，该文档通常称为“需求规格说明书”。 （4）需求分析与评审：它是需求分析工作的最后一步

一、 如何对需求不确定的创新产品进行分析和设计？ 1、对于需求不确定的创新产品进行分析和设计，首先我们要做的一定是 尽可能的明确需求。首先需要思考产品的用户是谁？产品的客户是谁 ？ 　　我们必须清楚地意识到，用户在大多数情况下并不等于客户，公司为办公软件买单，但是公司的员工使用办公软件。产品首先要做的是讨好用户还是客户，这对于后期需求的搭建尤为重要。 能够帮助客户解决问题的产品才是最好的产品，如果这个产品能够节省用户的时间给用户生活带来便利，那么用户就倾向于使用这个产品。我们必须抓住用户的迫切需求，搞懂他们在现阶段遭遇的难题，然后在产品里面去解决这些问题。 2、 确定了产品的目标对象，收集和整理需求 3、 任何需求尽可能地形成正规的需求分析文档，并且不断迭代，反复多次地确认 。 　　在需求分析阶段对需求的明确将在很大一个程度上减轻后期的工作负担。具体的需求采集方式分为以下几种： 　　（1）用户访谈 　　（2）可用性测试 　　（3）问卷调查 　　（4）数据分析 　　提出“需求采集人人有责”的概念，这样，我们才能“尽可能多地采集”。 4、 对需求进行整理。 　　产品经理要有自我判断和思辨的能力，更多的时候，用户并不知道他们自己真实的想要的东西到底是什么，也并不知道怎么样才是对这个产品更好的，产品经理必须要沉淀他们的需求。“少即是多”，并不是所有的需求都需要实现的