快好知 kuaihz

做需求分析,你要弄明白的5件事

首先说明一下笔者此次做需求分析的背景:要做的是一个网络报修管理平台,而本人未参与调研,手头得到的资料,有一个竞品的平台,以及另外一个竞品的整体建设方案,注意,平台和方案分属不同竞品,以及项目经理口述的客户需求,我们来看看通过这些材料,在需求分析阶段,需要弄明白哪几件事。

一、背景

做一个产品,我们首先需要了解做这个做这个产品的背景,也就是客户为什么需要这个产品呢?只有了解这些,我们才能有的放矢地来设计产品。

根据项目经理的口述以及各方资料,我们来整理一下产品背景:

“校园传统报修的用户痛点:填写纸质报修单、固定地点报修、分类报修信息低效易错、流程复杂、学校后勤服务工作不及时、水平低。针对这些问题,我们要打造一个网络报修管理平台,在报修用户和后勤之间建立起一座桥梁,对于简化报修流程,提高服务效率,起到良好的推动作用!”

二、用户

了解完背景以后,我们需要知道都有哪几类用户来用这个产品。

既然是网络报修管理平台,我们直观地想一下,最起码需要有报修人和维修人,然后除了业务前端之外,对于数据的管理和维护,我们需要搭建一个管理后台,既然有管理后台,最起码需要一个后台管理员,而这个后台管理员,肯定是由后勤管理部人员来担任的。

我们将用户暂且分为三类:报修人、维修师傅、后勤管理员。

三、流程

好了,背景和人说完了,我们该说事了。怎样把一件事说清楚呢,最直观的就是流程图了。

在这里顺便说一下,做流程图的五个步骤:

整个流程的起始点是什么?整个流程的终结点是什么?

在整个流程中,涉及到的角色都是谁?

在整个流程中,都需要做什么事情?

做每一件事情的条件是什么?

分别产出什么结果?

好,按照这个步骤,我们一步一步来梳理一下:

整个流程的起始点是有人发现东西坏了,申请报修;终结点是东西修好了,然后报修人给出评价;

整个流程中,涉及的角色就是咱们之前说的那三类了:报修人;维修师傅;后勤管理员;

在整个流程中,需要做的事情包括:申请报修、审批、派单、接单、维修填写耗材、评价;

条件这个就很好思考了,我们说两句就明白了:派单的条件是审批通过呀,审批不通过无法派单呀;评价的条件是维修完成呀。嗯,就说两句,其他自己想;

产出结果也说两句:审批通过的结果就是可以派单了,审批不通过的结果,当然就是退回,并给报修人发送消息通知,告知他报修审核未通过了。

好,接下来就是以流程图的形式,言简意赅地表达了,笔者习惯使用Visio,我们来look一下:

看图之前,再补充一点,需求中有提出,派单的形式包括自动派单和手动派单两种。

四、功能结构视图

好了,流程我们定完了以后,接下来就要开始做功能概设的工作了。

1. 目的意义

我们先来看一下功能视图的目的和意义。

目的: 主要是辅助设计和技术开发人员了解产品的全局结构。

意义:功能结构视图,在项目前期来说,是我们产品的功能概设,是我们设计原型之前的一种思路梳理方式;在项目后期来说,可以作为产品的功能目录,其作用可以理解为一本书的目录。

2. 方式方法

那么我们该怎么梳理功能结构视图呢?

道:道即思想,笔者在我的另一篇文章《三年产品经理的转正述职报告》中提到过怎样获取需求,即看一下市场上面有什么最新的技术,有什么更好的产品,我们取其精华,去其糟粕,以“拿来主义”的思想进行适用性创新,就可以调制我们自己的鸡尾酒了(这里提的一个概念是“创新”,我们所处的时代,“创造”或许已不复存在,对于这一论点,有兴趣的同学可以看一下凯文·凯利的《必然》)。

术:术即方法,梳理产品结构的层次依次为:产品—>模块—>子模块—>页面—>子页面—>元素—>操作。

器:器即工具,这个时候需要用到思维导图之类的工具了,晓庄同学习惯使用的是xmind。

3. 梳理思路

(1) 产品层面

通过以上分析,我们可以将产品形态分为三类:

报修人—移动前端;

维修师傅—移动前端;

后勤管理员—管理后台。

(2) 模块、页面层面

说一下笔者使用的方法:先罗列,再排列。

什么意思呢,就是先将用户通过产品,可以做或者说需要做哪些事给罗列出来,然后再进行排列组合即可。

报修人的移动前端:可以提交报修单、可以查看报修进度、可以给报修师傅留言、修完了可以进行评价、然后报修单不止一个,可以查看报修单的列表、通过列表可以查看详情。

维修师傅的移动前端:有人报修了,需要给维修师傅一个提醒;报修师傅可以对报修单进行处理,选择接收或者拒绝;并不能每次报修都能及时维修维修师傅可以填写一下修理时间反馈给报修人;报修人有留言了,维修师傅可以回复;修理过程中,维修师傅需要登记耗材;报修人评价完了,维修师傅可以查看。

后勤管理员的管理后台:从系统层面来说,用户管理,角色管理,权限管理,这些是必备的。

从业务层面来说,主线是维修单,首先需要对维修单进行管理,包括审批,派单;然后需要对维修师傅进行管理,这些维修师傅的基础数据,需要录入和维护;为了提升效率,每个维修师傅都是什么工种,这个可以搞一下,不然东西坏了,需要分配师傅,管理员哪知道谁可以去修;

同样的,维修区域和维修物品的基础数据及分类,后台也可以搞一下,不然报修人写个“学校南门从左边查第二栋楼有东西坏了”,这找地方都得找半天,带工具和材料,也不知道带什么,这多麻烦;好了,这些基本的业务都能够满足了,作为管理后台,统计分析是必备的,大概想一下,工作量统计、评价统计、故障物品统计、故障区域统计、耗材统计等这些可以搞一下。

(3) 元素、操作层面

好了,我们模块、页面层面的梳理完了,接下来就该梳理元素、操作层面的内容啦。方法呢,跟模块、页面层面的大同小异。

我们就拿提交报修单这个界面举个例子还分析一下,请往下看。

元素:先得告诉别人,什么东西需要修—报修物品;然后我们都讲究有图有真相的—上传照片;再然后得告诉别人到哪修—报修地址;最后别人到了,总得联系你—报修人姓名、电话;

操作:我们之前说了,报修的物品和地点,后台是有分类的,所以我们我们这里需要是选择的操作—下拉列表框;还有什么内容,想要补充一些的,需要有个备注功能—文本输入框;内容填完了,需要提交—提交按钮。

4. 上图

好了,按照以上的方法进行梳理,我们的功能结构视图就能够出来啦。是不是上面的内容看着有点乱,不过没关系,一切的混乱都是有序的开端,看下面的这张图,是不是就很清楚了。

关于管理后台的内容,大家可以试着自己梳理一下哦~~

五、信息结构视图

1. 目的意义

主要是辅助服务端技术人员创建或调整数据结构的参考文件。

信息结构图是一种接近数据库结构的图表,但是他并不是真正意义的数据库结构。技术人员会根据这张图表的内容再结合产品原型或需求文档,然后规划和设计出真正意义上的数据库结构。

2. 上图

主要是以面向对象的思想,整理出每个对象包含的属性,我们举一个例子:

六、结语

好了,我们今天讨论了需求分析阶段,需要弄明白的五件事,并且通过实际案例进行的剖析,想必大家看起来已经很清楚了。我们也可以看到,从前往后,内容都是逐渐丰富的。把这五件事搞定以后,就需要找领导们进行第一轮的评审,而下一阶段,就可以开始原型制作、概设、详设!

晓庄同学花了近两天的时间来整理这篇文章,如果对您有所帮助的话,也希望您能够打赏支持一下,晓庄同学不胜感激。学海无涯苦作舟,在前行的道路上,感谢有您一路相伴!

本站资源来自互联网,仅供学习,如有侵权,请通知删除,敬请谅解!
搜索建议:明白  明白词条  需求  需求词条  分析  分析词条  
设计

 Android 应用中十大常见 ...

[核心提示] Android 开发者关系团队每天都会试用无数的 App 或者受到无数的开发者发来的请求评测的 App,在评测如此之多的应用之后,他们总结出了10...(展开)

设计

 微信盈利模式——WeSense模...

不妨参照Google的AdSense,为微信大胆设想一个类似的盈利模型WeSense:公共账号预留广告位给微信,微信吸引广告主然后通过精准营销技术在公共账号的广...(展开)

设计

 深度解析:什么是支付核心?

文章主要是从八个方面来阐述什么是支付核心,它包括了一些什么内容?支付核心:一、支付核心和清算核心职责首先要明确一个概念:一个完整的支付清算系统结构内,各种特定业...(展开)