需求的收集

定义

进行需求采集之前,首先要清楚“需求”是什么意思,不然像是无头苍蝇只能到处乱撞了。

需求:需即需要,求即欲求,即个体客观或主观上的一种诉求。一般源自于用户理想上与现实中的差距所导致。

举个栗子:有志青年小明一直是简书的忠实用户,他自己也热爱写简书,从小就有个理想能够写出让大家喜爱的文章。现在,他遇到了简书,发现他的梦想好像触手可及,那就是写出一篇好文章登上简书首页。但现实是,小明从高中毕业之后就没写过什么文章,读书又少,该怎样才能写文章写上简书首页呢?

这里的“上简书首页”就是小明的需求。

方法

  • 一对一面谈 最常用的收集需求的技巧就是和客户坐下来问他们需要什么。讨论应该根据你要找的需求的类型事先计划好。有很多很好的方法来计划面谈,但通常你要问无确定答案的问题以使面谈者开始说话,并随后问探索性的问题来揭示需求。
  • 小组会谈  小组会谈与一对一面谈相似,除了不止一个人要谈以外——通常是两到四个。这些会谈在每个人都级别相当或者角色相同的时候会很有效。小组会谈要求更多的准备和更多的程序以便从所有参与者获取你所需要的信息。你能够在一个较短的时间内发掘出一大堆需求,如果你能使小组保持重点的话。
  • 促进会议  在促进会议上,你将更大的组(五或六人)为一个共同的目标带到一起。这种情况下,你试着以比单独和每一个人会谈更快的方式从小组获得一系列共同的需求。
  • 联合应用开发(JAD)  JAD会议与一般的促进会议相似。但是,小组通常会留在会议中直至会议目标完成。对于一个需求JAD会议,参与者要留在会议中直到一整套需求文档化并得到认可。
  • 问卷调查 问卷调查更加非正式,而它们是从远方投资人或那些只有次要内容输入整体需求的人那里获取需求的很好工具。问卷调查还可以用来从成百上千的人里获取信息。
  • 原型设计 原型设计是个相对现代的收集需求的技巧。在这种方法中,你收集初步的需求以便用来建立一个初始版本的解决方案——一个原型。你把这个拿给客户看,他看后给你另外的需求。你改程序并与客户再来一个回合。这个重复的过程持续到产品符合业务需要的临界质量或者既定次数的迭代。
  • 使用案例 使用案例基本上是描述离散过程如何工作的故事。故事包括人物(演员)并且从用户的角度描述这个解决方案如何工作。使用案例可以便于为客户阐明,尽管使用案例可能需要加以提炼后加进更加具体详细的需求。
  • 跟着周围的人 这一技巧在当前进程里获取信息时特别有帮助。你会发现,比如,有些人习惯于他们的日常工作而很难解释他们在做什么或为什么做。你可能需要在弄清整体概念以前看着他们开展他们的工作。有些时候,你可能还想要参与实际工作过程来获得今天业务功能运转如何的手感。
  • 招标(RFPs)  如果你是一个供应商,你会通过一份RFP收到需求。这份需求列表是给你用来对比你自己的能力以确定你距离客户的需求有多接近。
  • 头脑风暴  有些项目上,需求不像它们被“发现”那样地被“揭示”。换句话说,解决方案是全新的而且需要创建成一系列能被人认可的构想。在这类项目里,简单的头脑风暴可以作为起点。合适于主题的有关专家到一个房间里并开始有创造性的头脑风暴来看看解决方案可能会是什么样子。所有的想法产生以后,参与者排序选出解决方案中他们认为的最好的一个。得出的共识的最佳构想就作为初始需求。

手段

六西格玛

思维导图

脑图

参考

http://www.b2bkk.com/com/a2015jingyi/news/itemid-1685746.html

http://www.woshipm.com/it/336490.html

http://www.tuicool.com/articles/JvuYbm

http://www.woshipm.com/pmd/93345.html

时间: 2024-08-05 08:53:13

需求的收集的相关文章

软件项目需求开发过程实践之业务建模用例图

本次软件工程项目是重建办公业务流程管理平台,需要在继承原370个流程基础上,还需要提供快速流程开发能力,并要求体现出流程管理的规范性,以及流程的执行力.效率.效益,最终为企业管理创新提供流程再造的能力. 在项目前期及需求分析阶段,开发人员致力于"降低成本",以最小的代价完成项目,其可预见性的软件产品是经过系统平台升级的,并经过改良的第二个办公业务流程管理平台.按客户验收要求,"只能打60分,是不能给予验收". 在软件开发中,需求工作致力于解决"产品好卖&q

日志收集以及分析:Splunk

写代码的人都知道日志很重要,机器不多的时候,查看日志很简单,ssh 上去 grep + awk + perl 啥的 ad hoc 的搞几把就行,但面对上百台甚至上千台机器时,如何有效的收集和分析日志就成了个很头疼的事情.日志处理必然有如下过程: 从各个服务器读取日志 把日志存放到集中的地方 挖掘日志数据,用友好的 UI 展示出来,最好能做到实时的输入表达式做过滤.聚合 下面分三个方面聊聊,整个过程是需要多方配合的,包括写日志.读日志.转储日志.分析日志,注意聊这些的背景是互联网行业,机器多,日志

《软件需求与分析》

我们应当怎样做需求调研:初识 需求调研是需求分析最重要的一环,也最集中地体现了需求分析的特点——既是一份体力活儿,更是一份技术活儿.它既要求我们具有一种理解能力.设计能力,更要求我们具有一种与人交往.沟通的能力.开始首先是需求的收集,需求收集可以通过调查表,业界标准,会议讨论沟通等多种方式进行.需求收集第一是要能够很好的描述现状,第二是要搞清楚用户的期望.调查用户的操作习惯以及可以用同类软件的优点参考. 我们应当怎样做需求调研:拜访 首先是给客户留下了一个良好的印象,这是一个开端,但要在他们心目

说说#条目化需求#

之1:需求不再是传统的SRS文档,而是一条一条的,能够逐条查询,编辑,修改,状态跟踪.比如scrum提出的Backlog中的user story. 之2: 需求条目的层级划分,一级的划分往往是不够的.第一级需求往往收集原始需求素材,难以控制其范围和规模,所以不便于直接开发:第二级需求经过第一级的过滤整理,适合提供给程序开发.在敏捷里常见划分出epic和story,在cmmi中分成了客户需求,产品需求,组件需求. 不同组织在第一级和第二级之间还会安排中间的级别,这是为了更贴合组织情况.但是从精益的

需求管理与分析——需求池

产品经理会聆听用户声音进行需求收集,但是真正的需求需要我们去优化.真正优化的应该是从需求的收集到最终形成功能融入到产品中的这个过程.下面做一个简单科学的流程.一.需求收集· 从用户.市场.竞品.同事.朋友等渠道无差别收集各类问题.建议.与想法,另外通过数据分析和解读出来的需求也可以添加进去.· 尽量详细的记录需求的相关属性信息,如提出人信息.需求场景.需求描述等等.二.需求分析针对上面采集的需求,我们进行需要进行初筛和评审.1.初筛PM每天(或每周)对需求池中的粗略的筛选.主要做以下几件事:·

客户需求整理术

当通过客户需求调查收集到大量的外部客户和内部用户需求之后,需要对这些信息进行整理.归纳,以便能够充分利用这些宝贵的信息进行后续的需求分析.所谓整理,就是把相似的观点.信息放置在一起,这既是一个资料整理过程,又是一个对资料的初步分析过程. 在进行需求整理时,最为常见的方法就是亲和图."亲和"表示"自然的吸引",通过把需求按照其相互亲和性归纳整理为有有意义的类别,可以使需求更加清晰准确,从而达成一致意见,以利于确定最终的优化需求. A 整理步骤 在整理前,需要准备即时贴

ELK 二进制安装并收集nginx日志

对于日志来说,最常见的需求就是收集.存储.查询.展示,开源社区正好有相对应的开源项目:logstash(收集).elasticsearch(存储+搜索).kibana(展示),我们将这三个组合起来的技术称之为ELKStack,所以说ELKStack指的是Elasticsearch(java).Logstash(jruby).Kibana技术栈的结合, ELK5.X搭建并收集Nginx日志 ELK ELK5.X搭建并收集Nginx日志一.基础环境配置及软件包下载 二.安装Elasticsearch

ELK部署生产实践部署(1)

具体文档参照我的笔记 ### 日志采集前规范解决事项: 1.开发人员不能登录线上服务器查看详细日志. 2.各个系统都有日志,日志数据分散难以查找. 3.日志数据量大.查询速度慢 4.日志数据大量延迟 5.服务器时间不同步,导致日期错误 ### 解决问题 1. 方便快速查看各种日志 2. 故障发生,处理故障时才去查看日志,没有完整的日志告警机制 3. 节点多.日志分散.收集日志难度加大.没有统一规范存取路径 4. 运行日志.错误日志.需要固定存放位置 ### 部署环境 [[email protec

数据流图的绘制——软考探究(二)

软考中第一道大题就是数据流图的设计,这道题总体来说就是对参考人耐心.细心.信心的一次考验. 概念: 从我个人理解来说,数据流图的绘制就是对一个系统中各个角色(实体)所涉及到的操作(加工)的罗列,其中要记录下操作中使用和产生的文档.资料(文档.资料).下面从数据流图的图标说起,数据流图中的图形有矩形.椭圆形.箭头.缺口的四边形 矩形:代表实体 圆角矩形:代表具体的加工,试题中通过动词的形式体现: 箭头:代表数据流,旁边需要注明数据流的名称: 缺口的四边形:代表系统中需要和生成的资料.文档: 做题要