精华内容
下载资源
问答
  • 业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统,即组织希望达到的目标。使用前景和范围(vision and scope)文档来记录...
    业务需求(Business requirement)表示组织或客户高层次的目标。
    
    业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统,即组织希望达到的目标。使用前景和范围(vision and scope)文档来记录业务需求,这份文档有时也被称作项目轮廓图或市场需求(project charter 或 market requirement)文档。  

    用户需求(user requirement)描述的是用户的目标,或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。  

    功能需求(functional requirement)规定开发人员必须在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求。功能需求有时也被称作行为需求(behavīoral requirement),因为习惯上总是用“应该”对其进行描述:“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。  

    系统需求(system requirement)用于描述包含多个子系统的产品(即系统)的顶级需求。系统可以只包含软件系统,也可以既包含软件又包含硬件子系统。人也可以是系统的一部分,因此某些系统功能可能要由人来承担
    展开全文
  • 本节试图从一个简单的“用户自助寄件”案例出发,分析业务需求、用户需求、功能需求之间的关系和差异,以及如何进行需求的分析和转化。 在产品的需求里面,经常有这三个概念:业务需求、用户需求、功能需求,但...

    本节试图从一个简单的“用户自助寄件”案例出发,分析业务需求、用户需求、功能需求之间的关系和差异,以及如何进行需求的分析和转化。

    在产品的需求里面,经常有这三个概念:业务需求、用户需求、功能需求,但往往,我们很容易搞混,不清楚他们之间的关系和差异,我们先引用一下比较官方的解释:

    业务需求( Business requirement )表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统,即组织希望达到的目标。

    用户需求( user requirement )描述的是用户的目标,或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。

    功能需求( functional requirement )规定开发人员必须在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求

    这个解释其实还是蛮明确的,其实理解这三者的关键点,是要先认清楚每个需求针对的对象不一样:

    • 业务需求———对应的是组织或者客户,实质就是业务的建设方;你也可以类比房地产市场的开发商;
    • 用户需求———对应的是使用产品的用户;你也可以类比买房的人;
    • 功能需求———对应的是产品,即产品要具备怎样的功能,才能满足相应的业务需求和用户需求;类比房地产市场,那就是房子本身。

    类比成房地产三个角色后,你发现,开发商通常的诉求是想多赚钱,买房的人诉求是买到物有所值,甚至物超所值的房子;但不管二者怎么想,最终都是需要通过房子来实现,必须建设的房子的属性达到某个标准才能满足二者的诉求;

    所以,这么一看,你就明白了,其实这三者之间的关系是:

    即,业务需求和用户需求,只有经过需求分析的转化,变成产品的功能需求后,才能得到实现。

    需求实例

    接下来,我们用一个简单的实例来进行说明:

    案例:用户自助寄件的需求

    业务建设方:某快递公司

    需求描述:目前很多城市的小区都已经有了快递柜,但快递柜主要是用于送件使用,而对于快递公司收件,用得比较少,某快递公司,就希望利用快递柜,来实现用户自助寄件的需求。

    首先,我们来分析其业务需求

    这个案例的业务建设方是:快递公司,其业务需求也很明确,就是:用户自助寄件。

    业务方之所以要建设这个需求,其目的是:希望利用快递柜,实现更高效的收件服务,减少人工上门收件的等待、低效、人力投入成本高等问题。

    其次,我们来看用户需求

    这个案例的用户,就是每一个要寄快递的人,那么他们的需求是什么了?

    他们的需求,其实就是在进行“自助寄件”的过程中,你尽量让我简单、易用,高效、快捷。

    接下来,我们进行需求分析的转化

    需求分析的转化,核心是两个点,一是对这个业务的场景进行充分的理解和认知,二是想明白业务场景中需求点,要通过何种方式来满足它。

    业务需求是“用户自助寄件”,这个业务要实现,我们结合寄快递的实际场景,其实还是蛮容易就能想到,有3个关键环节:

    1. 用户要填写单据:即填写收发件人的相关信息;
    2. 用户要能找到周边的快递柜,并且能打开它;
    3. 还需要进行计量、支付快递费的问题

    这三个环节,基本把这个业务的三个关键阶段说明出来了,它就是:填单——>找柜子放件——>支付。

    然后,逐一对三个阶段进行具体的分析:

    填单阶段:

    • 业务方需求:必须收件人、联系电话、寄件人信息清楚、明确等等。
    • 用户需求:能选的就选,能简单填写的就简单填。

    转化为功能需求,你发现,无非是通过表单形式让用户把相关信息填上来,而为了满足用户需求,你肯定需要设计对收件人的记忆功能,让用户填写一次,后续每次只需要选择而已(相关的细节还很多,这里只做举例)。

    找柜子放件阶段:

    • 业务需求:把最方便最合适的柜子告诉用户,并确保用户能安全、准确的找到快递柜、放入快递件;
    • 用户需求:我就想知道我要把快递件放到哪里,别让我多走;

    这个业务需求和用户需求说起来简单,转化成功能需求时,其实里面还蛮多细节的:

    1. 位置服务肯定需要,一是为满足发现柜子的需求,二是也有导航的需求;
    2. 如何打开柜子呢?从我们的产品经验或者竞品参考来看,可以有扫描开启、验证码等方式;
    3. 如何保证用户去到快递柜,一定就有其空的柜子可以给他放了,这里面就涉及一个快递柜忙闲资源的管理;

    所以,这里转化为功能需求时,你发现:有位置服务功能、扫描开启/验证码开启功能,柜子资源分配管理功能等;

    支付阶段:

    • 业务需求:根据收费标准,准确无误、及时收到用户快递费。
    • 用户需求:支付方便。
    • 功能需求:
    1. 如何来计量,由于是自助寄件,称重显然不合适,那么按体积是一种较简便的方式,而如何按体积了,其实根据可快递柜的柜子;
    2. 如何支付,这个还简单,可以使用比较常用的几种支付方式就好;

    以上,都只是简单的需求分析和转化的过程,实际的需求过程中,我们经常讲需要结合业务场景、用户场景把一些关键细节挖掘出来,并能在产品设计时考虑进去,以给用户一个良好的体验。

    业务场景细节的挖掘

    比如:在上面的开启柜子的方式中,到底用扫描开启还是验证码的方式呢?

    其实用“验证码开启”会更合适,因为会存在很多这样的场景,某个寄快递的人,刚好家里有人下楼,或者认识的邻居下楼,而快递柜就在小区门口,那么找人代劳一下放件是一种很正常的事情,那么这时候,使用验证码就是一种最合适、简便的方式。

    又比如:某用户希望自己的快递能更快的被寄出去。

    那么,如果在给用户呈现周边分布的快递柜的同时,还告诉用户,该快递柜的收件时间,目前快递员的分布位置,是不是能让用户更好的去选择呢。

    这样的细节还很多,需要在实际分析中,更好的去理解用户场景、挖掘细节,并逐步的完善。

    通过上面的分析,我们发现,只要你充分认清楚业务需求方的诉求、用户在执行具体任务时的诉求,并对产品的常规实现方式有了解的话,需求分析并不是一个多复杂的过程,就是这么一步步去推理、去转化的过程。

    而要把每个细节做透,就必须在实际中多去磨练,在生活中多体验,学会场景化的思维方式。

     

    转自:http://www.woshipm.com/pmd/587994.html

     

     

    相关阅读

    展开全文
  • 用户需求和产品需求

    千次阅读 2018-12-15 17:25:31
    这句话说出用户需求和产品需求的区别,也说出了产品经理存在的意义: 那就是从用户需求中找到用户真实的需求,转化为产品需求找到解决方案,再提供给用户。   用户需求和产品需求 首先我们先来了解下用户需求和...

    业界内有一句话说:用户跟福特要一匹更快的马,福特却给了用户一辆车。

    这句话说出用户需求和产品需求的区别,也说出了产品经理存在的意义:

    那就是从用户需求中找到用户真实的需求,转化为产品需求找到解决方案,再提供给用户。

     

    用户需求和产品需求


    首先我们先来了解下用户需求和产品需求的概念。

    用户需求:用户自以为的需求,并且经常表达为用户的解决方案;

    产品需求:经过我们的分析,找到的真实需求,并且表达为产品的解决方案。

    所以需求分析的实质就是从用户提出的需求出发,找到用户内心真正的渴望,再转化为产品需求的过程。

     

    举一个例子:

    之前项目中有一次客户要求我们把工具栏放到页面的顶部(用户需求),

    其实在我们这类系统里,常规的放置方法是将工具栏以图标形式镂空放置在地图之上,

    更改工具栏的位置工作量上来说并不大,但是很不符合一般人的操作习惯。

    于是我就和他沟通,了解为什么要这么做。

    交流后才知道是他觉得页面顶部没有内容,看起来觉得太空(真实需求),

    后来我联系美工在页面顶部加上LOGO,以及做了一些背景图片,顶部右侧添上用户管理和退出的按钮,(解决方案)

    就这样客户最后也满意了,我们也没必要将系统改成个“反人类”的版本。

     

    这是一个很简单的例子,但也是说明了一个道理:

    我们要听用户的,满足他们的需求,但不是就要照着他们说的做。

    用户在提需求时候,往往会带有他们的解决方案,而这个解决方案因为用户自身的局限性,

    比如用户是个业务专家,但对软件系统不了解;

    比如用户仅从自身角色出发,提出一个适用面很窄的用户需求;

    或者用户本身“审美”就有很大的问题等等。

    此时就应该发挥我们的作用,和用户交流,发现他们的真实需求,

    然后根据真实需求找到解决方案,反馈给用户,

    或者如果我们本身就有相应产品解决方案时候,引导用户采取我们的解决方案。

     

    伟大的需求分析师,可以无视用户想要的东西,去探究他内心真正的渴望,再给出更好的解决方案。

     

    项目和产品


    销售人员经常说:用户是为想要的东西买单,而不是需要的。

    换句话说就是用户是为自己提出的解决方案买单,而不是我们的解决方案。

    也就是我们赚的钱是从项目里来,按照客户提出的用户需求来做就行,为啥还需要进行分析呢?

     

    这其实就是项目和产品的区别。

    项目很简单,就是用户有了某个问题需解决,然后我们根据用户要求解决了这个问题,用户给了我们报酬,这就是项目。

    产品源于项目,毕竟做产品也是为了解决用户的需求,但产品需解决的一类用户最核心的需求。

    产品的周期一般来说都很长,成立时候一般都来源于一系列相关项目的整合,

    从某类业务的项目里提取出核心的产品需求,并给出解决方案。

    之后遇到同类项目时候,就从产品出发,根据项目实际情况稍作修改,就能给出项目的解决方案,

    然后再根据项目的情况,不断完善产品的解决方案,使得产品不断迭代、更新,能解决更多、更难的问题。

     

    而项目和产品的区别对企业来说就是一个短期利益和长期利益的区别。

    如果是一锤子买卖,卖出以后又不用售后,那么不妨用户用什么就给他什么,这样他掏钱最爽快,你也省心。

    典型的代表就是各种外包公司,不断地承接各种项目,用户说啥我就做啥,最后按期交工即可。

    这样公司的盈利模式就是线性模式的,一份时间,一套解决方案卖一份得钱。

    而另一类公司的盈利模式则是指数型的,开发一套产品,然后可卖给多个客户,规模化获利。

    比如某云平台厂家,在完成产品研发后,后期主要就是运营推广以及个性化定制服务,

    将一套云平台产品卖给多个用户,自然而然长期利益就更高。

     

    所以对于期望追求长期利益的公司,拥有自己的产品是非常必要的,做产品需求也是非常必要的。

     

    二手需求


    作为一个需求人员,在真实研发过程中,很多时候我们并没办法接触到真实的用户。

    我们参与到的产品可能会是比较成熟的老产品了,而我们的需求来源可能是销售人员,也可能是老板。

    并且提出的需求可能是几句口头上的话或者一封简单的邮件,这中间理解的偏差只能通过我们主动的、反复的沟通来弥补。

    遇到这种情况怎么办呢?

     

    首先我们应当了解需求来源,知道需求提出者是哪个公司的、哪个部门的,什么职位的人。

    因为对于一个产品而言,不同部门、不同职位的人思考的角度是不一样的,我们得把这些信息记录下来方面我们理解为什么用户会提这样的需求。

    比如销售人员,他们考核的指标就是把产品卖出去,卖点越多越好,至于之后的用户用得如何,他们并不关心;

    比如运维人员,他们关心的是产品的运行情况是否稳定,希望产品出的故障越少越好。

     

    然后对于需求的描述,将所有主观修饰的词语去掉,

    需求的描述尽量使用主谓宾的语法结构,对于形容词尽量定量地进行描述。

     

    最后就是站在用户的角色来思考问题。

    不妨拿到需求的时候,假设自己就是用户,然后问自己这样几个问题:

    我是谁?我为什么提这个需求?我在什么时候什么场景下遇到这个需求?我用这个需求解决什么问题?

     

    也就是传说中的5W1H法,

    即弄清楚了5W(who、why、when、where、what),才可能知道怎样(how)去解决这个问题。

    作为产品经理,首先就是要重视用户需求的收集,

    只有在充分理解用的需求之后,才有可能把用户需求转化为产品需求。

    展开全文
  • 无论你从事什么样的岗位,做什么样的事情,理解需求,懂得心里,是非常关键的。

         今天面试时,被提问对产品需求如何理解,当时我就有点蒙了,心里想产品需求不就是用户想要什么,然后对它进行分析吗?然后我就随性地说了一通,这令面试官很不满意。但是,我确实是凭空理解的,没有深入去思考这个问题。

          回寝后,我一直在想这个问题,上网查找了一些资料,比如人人都是产品经理,才发现原来产品需求分析的知识还是非常深的,而我只是粗浅地认为是分析简单地调研分析,这并没有什么特色。

           我自己重新整理和总结:

           一、需求的理解

           1.需求是什么?

           通俗地说,每当你想到“如果这样就好了”,这便是一个需求。

           比如,你饿了,你脑子里想“要是有饭吃就好了”,这就是一个实实在在的物质需求。

           2.需求分析是什么?

           其实就是对需求的理解或解读,当然跟理解的层次有关,对需求理解不同,导致的结果是不一样的。

           比如:上面饿了想吃饭这个解读,你可以简单理解为饿了想吃米饭,也可以进一步理解:饿了,这个用户是想吃什么样的主食(面条、饺子、玉米、白米饭等),就需要去分析这个用户的出身背景(比如哪个地方的人,当地口味是怎么样的)以及留心他平时的习惯(比如他的口味是什么样的)等。

          用户想要找东西——找到更符合要求的东西——推荐给他他所关注的东西——好东西推荐给好友。

           这边是用户需求逐步深入挖掘的典型案例,由最初的用户想找某一个东西,到最后好东西共享好友,让好友方便找东西,做到信息共享。

           当然用户在提出某一个需求想法的同时,也会提出自己认为正确的解决方案,但是这个方案并不一定就是我们可实现的产品原型。聆听用户需求,深度剖析用户底层需求要点找准用户痛点,这就是需求分析的精髓。

           二、解读用户

           

             一千个读者眼中有一千个哈姆莱特,用户需求千奇百怪,而产品不可能大而全的满足所有用户的所有需求,那么找准自己的目标用户群,很关键。怎么来做用户分析,用户分析的要点又是什么?

             (1)根据产品基本定位,明确用户分类;

             (2)不同用户群体的特征:年龄、性别、教育程度、消费能力、城市、共性习惯等;

             (3)不同用户群体想要什么;

             (4)用户想要的我们是否满足。

              案例解析:以蚂蜂窝为例,进行用户分析。

             定位:蚂蜂窝是一家旅游攻略、自助游、自驾游攻略、靠谱旅游社交媒体网站。

            用户群划分:

      •  分享类用户,爱旅游爱分享,喜欢分享各种旅行感受攻略等;
      • 浏览类用户,看旅行攻略和他人游记为主;
      • 旅行赚钱类,如背包客小鹏;
      • 软文推广类,旅行社/公司职员,旅行编辑,写旅行类文案推广;
      • 组队约伴型,组队旅行,顺便预定一个酒店。
           三、需求获取
            

           认识了解用户后,下一步就该了解各用户群体的需求,通过多种途径采集用户需求。我们常用的需求采集方法有:文献调研、用户访谈、问卷调查、竞品分析、运营数据分析及用户模拟(欢迎补充,请在下方评论区留言)。下面抽取几种典型的需求采集方法展开:

          1、文献调研

            查阅历史资料、行业报告、网络资讯等相关讯息,如《年度互联网用户行为分析报告》、《移动APP年度报告》等互联网行业报告,了解判断行业趋势、把脉用户习惯,粗略判别用户需求。PS:艾瑞咨询发布互联网报告较多,当然明确产品相关行业及目标用户后针对性的了解分析更为关键。

          2、用户访谈

           用户访谈分为2种形式,1V1的深度访谈和座谈会形式的焦点访谈。两种用户访谈的方式各有所长。下表对两种不同的访谈形式做详解:

     
    深度访谈
    焦点访谈
    访谈对象
    随机小白用户(蚂蜂窝的普通注册会员)
    代表性用户,每场人数8-10人为宜,相互间是陌生的,排除行业专家(普通注册会员、分享游记的专业驴友、旅游公司职员等几类典型用户)
    主持人
    提起思考点,引导用户多说,注意观察受访者的表亲、语气等,扮演倾听者的角色
    主导话题主线,但保持严格中立,注意追问,注意观察场上各人员,对意见领袖适当冷藏,激活沉默用户多发言,
    场地
    无要求
    专业焦点访谈室,分为前后两个部分,前边为访谈主场,后边为监控室。访谈主场以圆桌为佳,桌上备有少量水果、点心,营造轻松氛围;备有纸笔、录音笔、摄像头等;监控室为观察场上情况,整体把握调整话题方向所用。
    访谈提纲
    访谈提纲仅作参考,不限定,具体视现场情况访问员/主持人把控。1 验证你心中原定的需求点是否能得到认同;2 用户的心中是否有其他见解;3 开放性的问题多一点,让受访者思考;4问题尽量贴近生活。
    优点
    1V1深度访谈,获取更多用户信息,实时观察用户表情及特征,为判断需求真伪提供一定依据;场地无要求,易实施。
    不同代表性用户,易激发思考。
    缺点
    难以激发思考,需访问员注意启发式提问
    部分受访者易受意见领袖影响;主持人控场要求高。

           说明:()内以蚂蜂窝为案例

    3、问卷调查

           相比用户访谈,问卷调查是一种定量的调研方式,常用于用户访谈之后;通常先通过定性的用户访谈判断基本方向及要点,再通过问卷对各需求关键点进行定量验证,了解其特点后再次通过1V1的深度访谈把脉需求(一般在问卷调研过程中发掘深访对象)。当然视产品的具体情况选择最适合的方法。

          全流程的问卷调查,执行过程中一般会涵盖调研方案(调研时间、地点、主题、投放数量、受访者构成等)、问卷设计(问卷设计完成后,可小范围投放测试)、实际调研(网络、电话、实地)、问卷回收(审核问卷真实性、有效性)、问卷分析(分析调研数据,出具分析报告)几个方面。其中的问卷设计,有几个原则:1)问题通俗化,忌专业术语;2)选择题为主,问题设置由浅入深,逻辑性;3)选择题答案闭合,标准化。

    4、运营数据分析

           从运营数据报告中获取需求,一般针对已上线的产品/业务,通过现产品的运营监控,为产品迭代提供一定依据。通常来自于采集运营数据(如UV、PV、浏览轨迹、转化率等)和市场、客服等其他合作部门的建议反馈。

    案例解析:蚂蜂窝这一案例中的酒店预定、机票预定功能,如果订单数量很多,但最终完成支付的很少,可以怎么解决?

    1、 梳理下订单之后的各个环节,下单成功后,需要什么环节才能成功支付;

    2、 分析各个环节的转化率,找到用户流失的关键步骤;

    3、 从产品角度考虑产品功能优化,以降低用户流失。

    现场简要分析,用户流失可能因为:1)登录注册繁琐;2)支付方式太少;3)页面跳转环节过多等等。针对这几个问题,从用户需求的角度来看,1)简化登录注册,最好可以支持通用的如QQ、微博等社交类帐号;2)丰富支付方式,支持常用网银、支付宝等支付工具;3)简化非必要跳转页面。

    市场、客服等合作部门的反馈,因为市场、客服人员是与一线用户直接接触的,对于用户对产品的反馈和建议是能够快速掌握的,有时可能就是用户的一句抱怨,可能会给产品带来很大的价值,因此留意用户,接触用户也是非常关键的。

    5、竞品分析

           所谓的竞品分析就是找类似定位的产品,看别人的产品功能、设计,逆推用户需求发现竞品的闪光点,拿来用在自己的产品上。

            从领域、产品类型、未来规划的方向、相关功能等角度去找竞品;再从竞品的定位,具体功能,战略规划,运营推广等角度去分析。(ps:当今社会创新的成本太高,拿来主义式的微创新也是不错的选择)

            如本篇案例中的蚂蜂窝,竞品分析可对途牛网、悠哉网,去哪儿,酷讯,到到网,驴评网,蝉游记等产品的产品定位功能结构、产品规划等多维度分析,找到不同产品的优势,然后为我所用,基于此对蚂蜂窝进行优化改造。

    6、用户模拟

            用户模拟的目的是在具备产品核心定位后,融入用户角色,再不断的对产品核心理念做修正的一个过程。有两种方式,一种是1S变小白,自己化身用户,思考如果你是用户,你想用这个产品在什么场景下做什么;另外一种方式,代入用户角色,走进目标用户群,去体验感受用户的所有感知。

             四、需求评估


             通过多种需求采集方法收集了大量的用户需求后,在进行产品设计前,会预先对需求进行评估。需求评估的目的在于,对所有需求做评估,做优先级判断,判断哪些需求是必须要满足的,哪些是可以延迟一点满足的,而哪些又是可以不用考虑的。

    需求评估考虑的因素有:1)可行性(技术能否实现)、2)成本(人力成本、时间成本)、3)商业风险、4)是不是用户最迫切的需求(紧急性与重要性)

    我们常用的需求评估方法有KANO模型、需求减法、专家评估式:

    1、KANO模型

             KANO模型,是需求实现与用户满意度之间的关系模型图,把需求按照需求满足和满意度两个维度把需求划分为基本型需求、期望型需求和兴奋型需求三大类。同时用户的需求类型是随着时间变化的,也许期望型需求变成了基本型需求,兴奋型需求变成了期望型需求,需要重新挖掘用户的兴奋型需求。

    对于必须完成的需求,在产品发布时需要完成;同时完成尽可能多的期望型需求;如果时间允许,至少应该确定少量的兴奋点需求优先级,进入研发和发布计划;后续及时跟进用户的需求状态和类型,不断挖掘用户新的兴奋型需求。

    KANO模型分析可参见《如何解决“女生喜欢白马王子”的需求》

    2、需求减法

            有时候决定不做什么,比决定做什么更加重要。产品经理或多或少有一些”完美主义“情结,生怕缺少什么,增加不必要的功能。但是从成本、效率等多方面考虑,我们应该倾向于”轻产品“,根据一定的原则做需求减法,适当的砍掉一部分需求。

           需求减法的核心要点依旧是产品定位,围绕产品定位,根据产品价值,定义需求边界,把握核心需求,砍掉需求边界外一些无关紧要的需求。

          如阿里集团旗下的淘宝和阿里巴巴同为电商平台,为何阿里会搭建两个平台来开展电商业务?很清楚的定位,淘宝是2C阿里巴巴是2B,两者所面向的用户群体不一样,对于不同的买家和卖家的需求都会不一样。

    3、专家评估法

           专家评估法,顾名思义就是组织资深产品专家一起评估产品需求,决定做还是不做,是否值得去做,运用群体智慧的力量来决策产品需求。资深专家可以是技术专家、资深市场、资深客服等。

            尤其值得一提的是老板需求,老板作为一个特殊的客户,常常会对产品提出一些自己的设想,老板以他的经验、阅历及对市场的敏感度会做出一定的判断。针对老板需求在不影响整体产品逻辑的前提下可以适当考虑。如果偏离太远,可提供相应理由给老板定夺。

    五、需求管理

            在需求采集、需求评估的过程中,如何整体管理这些需求,在整个产品的生命周期里更好的跟踪把控需求进展。公司不同,个人习惯不同,对于需求管理的方法会有所不同,但是目的是一致的,实时把控跟踪需求。下面是几种使用较多的需求管理方式:

    需求卡片:描述需求来源、需求内容及需求优先级的需求卡片,一般会用于市场、客服等相关合作部门提交需求所用。

    需求矩阵:EXCEL表单的形式记录每条需求,追踪需求动向,包括相应提出人、需求描述、需求优先级、需求评审时间、开发时间、开发人员、测试人员等。

    需求文档:把整个产品拆成N个小功能模块,出具相应的需求文档,分阶段提供给开发、测试相关人员,在小公司小的产品中比较适用,但要求产品人员必须非常清楚产品的每个功能点,可以全盘考虑管理。

    测试用例:测试用例一般以用户场景的形式描述,使用测试用例的形式来记录需求,管理需求也不失为一种很好的方法。

    这便是通常大家提出的产品需求分析整体思路,其中个人理解核心在于:用户的解读和产品的定位

             由于本人即将从事软件行业,首先需要学习软件需求分析。不难发现,网上这类的资料和书籍也是到处都有,但是真正对于软件需求的深层次的理解,还是比较少的。大部分都是纯粹的一些空洞的语言。

             大体流程是:

    首先有用户需求

    然后由组织将用户需求转化为业务需求

    再由开发者将业务需求转化为功能需求

    功能需求映射到系统功能模块

    业务需求也有可能是基于的业务发展需要,由组织首先提出来的。

     

         业务需求(Business requirement)表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统,即组织希望达到的目标。使用前景和范围(vision and scope)文档来记录业务需求,这份文档有时也被称作项目轮廓图或市场需求(project charter 或 market requirement)文档。
    用户需求(user requirement)描述的是用户的目标,或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。
      功能需求(functional requirement)规定开发人员必须在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求。功能需求有时也被称作行为需求(behavīoral requirement),因为习惯上总是用“应该”对其进行描述:“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。


    什么是用户需求什么是功能需求?

    我觉得:

    用户需求针对的是人,描述的是用户想做某件事情所遇到的问题,或所想满足的欲望;

    而功能需求针对的是产品,描述是是产品如何解决用户所遇到的问题,或如何满足用户的欲望,是方式、方法;


    举个例子:


    用户需求:在决定购买之前,用户想方便地比较一下几个同系列商品,以此在选择的时候做出更明智的决定。

    功能需求:我们可以让用户把意向购买的商品,都放入“对比栏”,然后用户再点击“去对比”,就会在一个界面同时对比几个产品,就像中关村在线那样的做法。


    用户需求是前提条件,功能需求是落下来的产品部分,它是可以交付的。


    值得注意的一点是业务需求,有的时候用户需求与业务需求是有矛盾,那么功能需求怎么决定呢?

    举个例子:

    某个商品界面,我发现我的用户不是为了买最便宜的货,我决定产品不把最便宜的商品都展示出来,因为1、不希望让用户买最便宜货,2、一旦有太便宜的商品,用户就会形成心理落差,觉得贵的商品就不值钱(其实贵的商品的性价比比便宜的商品更高),3、我想提高单笔成交订单额度。

    所以我就会只展示出相对贵一点的商品。


    让用户减少选择,就有可能购买价值更贵的商品;(业务需要)

    如果把最便宜的商品也展示出来,这对于用户需求来说,是有价值的;(用户需要)

    但还是坚持了“贵一点”的策略,这就是业务需求主导了功能需求;


    业务需求 是什么?


    业务需求针对是公司,描述是公司想如何解决用户的问题,如何满足用户的欲望,并将利益最大化。重点是在后面,追求商业可行性与利益最大化。

    不过放心,大部分互联网公司,他的业务需求很简单:让功能需求最大化满足用户需求,不断追求用户体验,黏住用户后,再谋求规模化利润(比如:广告)。


            我原来对软件需求的定义或描述更多是偏于对现实世界的定义,而对软件架构的描述现实到实现之间的第一层抽象。在这里纠正一下即:用户需求是对现实世界的定义,而软件系统需求是现实到实现的第一层抽象,即业务建模和软件系统用例建模。在原来的软件工程里面我们更多谈到的一个词是系统分析员,我现在将其拆分为了软件需求BA系统架构SA两个角色。而实际上一个真正优秀的软件需求人员必须具备两方面的能力。

            从软件需求在整个软件生命周期中的定位来看,其上接业务,下接设计和技术。从这个概念上来讲软件需求人员必须具备业务和技术两个方面的能力。

            对于业务,首先要解决的是对业务的理解,然后才是在理解后业务的形式化表达和业务建模能力。而对业务如何理解,最核心的仍然是顶层的流程建模和分析能力,底层的业务活动和规则清晰的描述能力。在这里里面涉及到流程梳理和定义能力,业务单据和对象的抽取和定义能力,业务规则的清晰阐述能力,和流程配套的相关的岗位角色,交互等描述能力。要知道在这块往往并不需要太多的IT背景和软件工程的知识,更多的是对业务的熟悉,对流程管理和分析方法的了解。

            上面一步的业务更多的是属于顶层方面的内容,而第二个层面往往会过渡到系统软件需求层面的内容,在这里我们更加强调的是类似面向对象的用例分析和建模的方法,这包含了业务用例和系统用例分析和建模,是一种很好的形式化的方式来定义和描述业务的方法。包括从流程分析转入到用例,单个具体的用例分析和建模,每个用例详细的基本流,扩展流,业务规则,参与角色,界面原型,业务对象和对象属性等各个方面内容的描述,要知道我们做用例建模的目的是能够按用例驱动的核心,平滑的转入到架构设计中去,因此用例分析建模已经不是简单的描述现实世界的问题,已经涉及到业务或用户需求到系统需求的第一层抽象转换。

           要做好需求的第二步的事情,那么单纯的只有业务背景就不足够的,必须还具备相应的IT和软件工程的技术背景。这个背景往往并不是说要做过多久的软件设计开发,但是只是是做过,通过软件开发你能够很清楚的知道一个软件从需求调研和分析开始,最终是如何形成一个软件系统的。这个背景知识可以更加方便我们去考虑用例建模,去认识到为何要采用这种方式去用例建模,真正理解用例中每个描述点如何影响到最终业务系统的实现。

           没有技术背景很难真正成为一个优秀的软件需求分析师,最多也就是一个业务需求分析师。

            要知道,当你进行用户需求调研后,往往收集到的都是一个个的用户需求点,而一个软件需求分析员要做的是最终将这些需求实现为一个完整的业务系统。这里面就涉及到业务模块的划分,模块间的分析,需求层面的复用能力分析,各种性能,可靠性,安全等非功能性需求。这些更加已经是一个完全的系统分析方面的内容,或者说软件需求已经会兼顾部分软件架构设计的内容,因此作为一个软件需求人员更加需要去了解业务组件化,服务化,软件模块集成,复用等方面的技术内容。也需要去了解涉及到UCD,交互设计方面的内容,这些都是形成一个高质量的软件业务系统的重要输入。

             一个优秀的软件需求人员既不应该因为具备技术和开发背景而导致在需求分析和建模中的各种程序员思维,也不应该完全抛弃技术单纯的去描述业务不管实现的难易度。软件需求人员衔接了最终用户和内部的设计开发,是两者之间重要的沟通和协同桥梁。各种沟通和人际关系处理技巧,各种软技能的要求更是必不可少的,在此不再展开去描述。

           一个优秀的软件需求人员不存在是否能做新领域的软件需求的问题,因为最终真正有用的需求分析的方法论和模式,去理解和熟悉业务和快速形式化描述和建模的方法,有不断的实践总结出来的快速理解业务的能力




    展开全文
  • 需求分析是研发一个软件系统的前期工作,目的是搞清楚系统要做什么,用户的应用场景是什么等。稍微大一些的软件开发团队有专职的需求分析师,他们有的叫BA,有的叫SE;也有由开发骨干兼任的。   ...
  • 数据库设计(5)-理解用户需求

    千次阅读 2015-08-31 21:55:13
    从本次讲座开始我将引领大家开始数据库设计之旅,我们将从需求分析开始,途中将经过概念数据建模、多视图集成、ER模型转化为SQL、范式化等过程,最终得到完整、可用的SQL表。 需求分析在数据库生命...理解用户需求;2
  • 如何提高需求理解能力

    千次阅读 2017-10-31 14:20:35
    每个人这个问题可能都会有不同的体会。我的看法是,需求分析的意义在于准确无歧义地表达项目需要交付的产品,并且获得需求方的认可,从而为整个项目建立一个基准。指望需求不变化是几乎不可能的,不管是开发者还是...
  • 在开发过程中,开发人员、测试人员都需要阅读其他人写的需求规格说明书,...可以通过环境图,帮我们梳理清楚该软件与周边环境的关系,从宏观上软件所处的位置有所理解。如下图所示: 2 系统的目标是什么,即解决了客
  • 如何做需求分析

    万次阅读 多人点赞 2018-01-31 16:32:26
    今天我就针对这个话题结合我自己的一些理解和经历来梳理一下。  需求分析的目标是将产品的需求功能梳理,并且用通俗易懂的文字描述,为开发人员和测试人员提供依据。那么需求的分析梳理细化,直至成文这个过程,...
  • 马斯洛需求层次的理解

    千次阅读 2018-07-13 08:55:08
    谈谈我马斯洛需求层次的理解。生理需求:陌生人社交工具、美女直播、美食网站都在点点滴滴地满足我们的生理需求。所以陌陌、探探、珍爱网有市场;各种外卖软件如美团、百度、饿了么、大众点评为高频使用的产品;...
  • 很多开发人员来说,需求是个比较笼统、模糊的概念。如果不在开发运维的过程中,多揣摩多思考,那么需求这个东西就会变的越来越陌生,甚至觉得不那么重要,不那么相关! 那么到底需求是什么? 我说——需求,是...
  • 哔哩哔哩用户需求分析报告

    万次阅读 多人点赞 2020-05-03 18:42:57
    根据需求优先级列表排序和用户需求程度排序,基于目标群体的认知和日常使用,总结出以下几点优化建议: 内容方面 加强内容审查,同时加快内容审核。针对UP主上传的视频内容,可提供用户评分功能,低分视频...
  • 我们的软件产品或者项目,其需求都有三个层次,业务需求、用户需求和功能需求,除此之外,每个系统还有各种非功能需求。不是很了解的朋友,今天就和我和我们一起来了解一下吧!  下图是需求层次关系图,软件需求...
  • 【修炼五】用户需求&系统需求

    千次阅读 2013-05-26 11:55:33
    2013.5.26  需求阶段的工作是项目经理最繁忙的一个阶段,也是项目能否做好的一个重要分水岭。通常此阶段要完成系统需求的编写,工作思路的整理,工作计划的制定,人员工作... 因为用户需求是由主管/产品经理编写,
  • 用户需求转成产品需求

    千次阅读 2018-03-03 10:12:54
    推荐IT产业链平台【邀请产品经理】通常收集到的需求,绝大部分都是“ 用户需求 ”,所谓用户需求,是指听到用户说想要的东西,以及用户以为自己想要的东西,而产品经理要做的,就是思考如下三个问题:1、这个需求...
  • 用户故事拆分是敏捷实施的入门实践——没有用户故事拆分,就没有真正意义上的迭代,也就没法做到敏捷所倡导的快速反馈、快速学习和快速价值交付。INVEST 原则常常被看做是用户故事拆分的基本要求[1]。但是,不少敏捷...
  • 用户需求和产品需求的采集、分析、筛选和管理

    万次阅读 多人点赞 2016-05-22 13:02:35
    1 需求管理流程产品的需求管理有需求采集、需求分析和需求筛选几个阶段,经过这几个阶段之后才会进入立项...纵向来看,用户的研究有定量研究和定性研究,定性研究一般是用户研究较早阶段,从无到有,找出原因,偏于理解
  • 论界面设计与用户需求

    千次阅读 热门讨论 2016-08-18 17:14:28
     4、想的要比用户多:可以去猜测用户将来还要有什么需求,模拟用户的使用环境,这样在用户使用软件的时候就会触发用户的新鲜感,从而会感觉到软件的强大,使用户更加的喜欢你的软件(给用户留悬念)。 这...
  • 如何编写出好的用户需求文档

    千次阅读 2018-04-17 08:57:22
    许多软件开发团队没有需求工程师;开发人员捕获、编写和管理所有的需求。这在资源效率方面是有意义的:开发人员可以在正式编码之前,在系统停机时间收集和编写需求。然而这一做法的缺点是,通常程序员没有在编写需求...
  • 怎样挖掘用户需求

    千次阅读 2016-05-13 15:05:59
    需求分析在数据库生命周期中至关重要,通常也是涉及人员最多的...这次我们先讨论“理解用户需求”。  设计定制化产品——无论是一个数据库、一幅平面广告或一个玩具,都是一个“翻译”的过程。我们需要把浮现
  • 项目需求管理的认识和体会

    千次阅读 2018-06-12 17:33:55
    对需求的管理大概有那么几个活动,首先是需求获取,这是一个确定和理解客户的需要和期望的过程,为实现项目目标而定义、记录、分析干系人的需求; 其次,是要求获得相关人员对需求的认可和承诺;最后,即使是需求确定...
  • 1、用户需求说明书是用户的需求,需要和用户确认的。需求规格说明书是系统需求主要是对内的。需求管理的时候也需要用到用户需求。2、 优点:用户的语言与设计人员的语言是不同的,所以需要有面向不同人员的文档。 ...
  • 需求文档

    千次阅读 多人点赞 2019-03-29 18:10:18
    因为每个人的习惯和团队要求都是不一样的,所以产品需求文档没有统一的行业规范标准,无论以什么样的格式撰写产品需求文档,最终的目的都是让执行人员能够理解产品需求,根据需求完成产品。 产品需求文档的表现形式...
  • 我说CMMI2.0 之需求开发与管理

    千次阅读 2019-02-03 09:54:35
    它包含了需求获取、需求分析、需求描述、需求验证与确认、需求管理等五个需求工程的活动。   实践列表 RDM 1.1 Record requirements.  记录需求 RDM ...
  • 那些不属于这些类型的信息可能代表一个非软件项目的需求,例如,为使用新系统而进行的用户培训或者它仅仅是不重要的信息。 下面讨论在听取客户需求过程中的一些建议,这将有助于信息进行分类处理。 1) 业务需求...
  • 1、用户需求说明书是用户的需求,需要和用户确认的;需求规格说明书是系统需求主要是对内的。你考虑了一个对外一个对内。而且需求管理的时候也需要用到用户需求 2、 优点:用户的语言与设计人员的语言是不同的,...
  • 如何获取和发现用户需求

    千次阅读 2015-08-22 11:40:55
    20150816: 如何获取和发现用户需求这是自己写的第一篇文章,先简单写一些自己的想法:首先我把目光放在了需求,我认为需求可以分为显性需求和隐形需求,一般在初期,产品都会从主要满足用户的一个需求或者一系列需求...
  • 用户角色权限的简单理解

    千次阅读 多人点赞 2019-06-24 19:40:42
    用户角色权限,它们之间的关系是用户依赖于...2.有些用户只能或全部或部分栏目进行管理(添加删除修改) 3.有些用户只能浏览或全部或部分栏目的信息 基于角色的权限控制方法的思路 1.先设定角色(控制用户的横...
  • 1.4客户需求 二、快速原型模型 2.1什么是快速原型模型 2.2优缺点 2.3快速原型模型的思想产生、原理及运用方式 2.4类型 2.5开发步骤 三、增量模型 3.1什么是增量模型 3.2特点 3.3优缺点 3.4作用 四、螺旋...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 551,004
精华内容 220,401
关键字:

对用户需求的理解