浅谈IT项目需求分析

在IT项目建设中,需求分析是最初也是最基础的一个步骤,需求分析人员是客户与研发之间沟通的桥梁,是项目研发成败的关键一环。

客户在建设IT项目时,业务人员为统一的需求出口口径,业务人员熟悉业务,知道业务的要求是什么,了解业务的痛点在哪。但需求背后的本质需求,业务人员多数时候是没有想清楚的,这个时候就需要我们的需求分析人员帮助客户了解他自己到底需要一个什么样的IT系统。比如公司业务迅速发展,业务增长较快,但随之而来的售后服务问题也越来越多,服务运营人员数量有限根本忙不过来。现有IT支撑系统手段较为薄弱,系统与系统之间没有关联,服务人员需要来回切换查找不同的信息,综合不同信息来解决问题,问题处理效率低下。由于客户投诉不能及时解决,产生积压,导致客户问题处理时效越来越长,客户投诉愈演愈烈,形成恶性循环。业务人员反馈说需要一个服务支撑系统,能够综合各类信息,快速解决业务故障问题,同时如果能够优化一下业务流程,降低客户投诉率是最好不过的了。当研发拿到这样的一个需求后,肯定是一个头大的状态,但如果需求分析师告诉研发,现在客户需要一个业务故障处理系统,包括业务概览、业务信息查询、业务故障诊断工具、故障处理记录查询、故障分析几个模块,每个模块分别的功能包括......,每个功能的要求是......,那么这个时候,研发人员的思路便清晰了,需求分析人员就是这么个桥梁。

需求分析既然这么重要,那么如何帮客户分析清楚想要的东西、如何设计系统功能,如何设计功能细节,则变的尤为关键,总的来说,可概括为如下几点:

  • 学习业务,站在客户角度考虑问题
  • 提炼需求,将需求转换为系统功能
  • 深入设计,完善各类功能的各项细节

学习业务,站在客户角度考虑问题

学习业务,了解业务,成为客户行业的"专家",虽然不在业务一线工作,但需要理解业务一线的工作情况,熟悉业务背景、明确业务对象、定位好业务人员角色,站在客户角度去熟悉业务,考虑问题、定位问题、解决问题,针对流程繁琐的业务,可在思路上对业务流程进行改进,乃至在业务发展上,也有一定的见解,着对系统的规划演进起到重要作用。

提炼需求,将需求转换为系统功能

第二点,提炼需求,将需求转换为系统功能,这一步对于经验较为丰富的需求分析人员来讲,那就是水到渠成的事情,什么样的业务对应大概什么类型的功能,当接到项目需求的时候,心里其实已经有个谱了,需求调研分析阶段,只不过是对自己思路的验证、已有产品的功能对应,在尽可能小的工作量下,对现有产品的功能进行改进,如此而已。但同时也会引发另一个问题,那就是思路固化、闭门造车,一套原型走天下,一条胡同走到头,其结果不能说不好,但总归是少了点创新的意思。

针对刚接触的新人来说,借鉴同事前辈的经验是个很不错的选择,在前辈的基础上加以思考,择优弃弊,将其转换为自己的一套思路方法。当然也可以根据自己对业务的理解,一点点进行梳理,比如前面所举得例子中提到,运营人员需要到多个系统来回查询不同的信息,综合不同的信息来解决问题,那么基于这个痛点,是否可以将业务人员关注的信息给集成起来呢,提供一个查询的功能,只需要查询一次就可以看到所有关注的信息。具体的来说提供一个业务信息查询功能,支持多个条件的自定义查询如按照业务标识进行查询、按照业务类型进行某一类查询,以表格的方式进行呈现,可点击某一条具体业务查看详情,呈现的详细信息包括业务名称、业务类型......等信息。那么为了集成各类信息,如何从外部各个系统获取这些信息呢,用什么接口合适,具体字段指标的格式、定义是否统一呢,指标采集周期如何,数据采集到系统后是否要进行标准化的处理呢?数据经过标准化之后是否要统一进行数据汇聚计算呢?系统内的功能如何使用这些数据呢,详细的说,就是到哪张表里获取哪些字段。

明确了数据从数据源、指标定义、数据周期、数据抽取方式、数据标准化方式、数据入库、数据汇聚方式后,我们系统的数据基础已经打好了,后面就是系统功能如何基于我们的数据基础进行系统逻辑计算,简单点来说直接到哪个表里获取哪些字段,复杂点来说综合不同数据信息进行各类业务逻辑处理。如刚才所举例的例子,各类数据都统一按照系统自有的数据模型采集入库后,一个简单的查库就可以满足了。

深入设计,完善各类功能的各项细节

在将需求提炼为系统功能后,更进一步的就是功能的详细设计,这一步是逻辑的体现,很大程度决定了测试的工作量多少,功能设计的不够完善,很多细节没有考虑到,研发在开发阶段,也会有诸多问题,特别的可能会影响整个功能模块的设计。拿上面所举的例子来说,我们要实现一个业务信息的查询功能,分为查询条件、表格列表、详情呈现三大要求。

查询条件:包含业务标识查询,业务类型查询两种,业务标识需要支持关键字模糊查询,业务类型为固定的类别,因此考虑下拉条件查询,下拉字典有.....,业务标识与业务类型为且的关系

表格列表:默认列表的呈现字段有...,默认呈现顺序如刚才所列,可按照某某字段进行倒叙、升序排序,字段过长时部分隐藏呈现,单页最多呈现20条,采用分页/滑动条的方式

详情呈现:详情包括***几大类,**类中的字段信息有......(呈现的样式、布局可简单在DMEO中设计,详细的由UI来设计)

如上我们便将几个功能点的一般详细要求思考清楚了,那么基于基本的功能要求之外,是否可考虑在进一步的功能优化、或者说扩展呢,比如查询结果的导出、详情信息分享、表格默认呈现字段自定义等等,这些就需要结合业务要求进行设计和考虑了。

总结

其实需求的调研分析,很多类型都是通用的,比如拓扑类的、图表类的、表格类的、报表类的等等,每个类型考虑的要点多数情况下是想通的,因此我们可以针对不同类型出具一个需求调研分析的模板,来快速进行思路整理和分析,也同时能够快速教会新人上手工作。

 

 

 

  • 1
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值