需求调研和分析杂记

标签: constraints产品数据结构产品设计游戏
1575人阅读 评论(3) 收藏 举报
分类:

老调牙的调子,需求调研和分析是系统成败的关键,如何做调研和分析的方法非常多,就从业务的角度来说,难度并没有坊间传言的那么大,涉及到政治,那就是另外一回事情了,这里不讨论。那如何进行呢?

1、首先确定系统的大致范围(目标)(即做什么(Do what))(这个时候的目标当然是粗粒度的,就是所谓大的用例)和如何做(有什么资源)
这里的做什么和如何做,包含了项目管理的三大要素:范围,时间和成本。这里的如何做指的是能够提供多少资源(多少预算,多少人,多少时间等),所以这步很关键,因为在后面的分析中需要以此作为筛选需求的依据。

2、对用例进行分析

A) 哪些人用这个功能(角色)?(who)
用什么?(Which)
怎么用?how (when,where,precondition,constraints)
涉及到谁?Which And Who
他们之间如何协调,谁先谁后,有什么条件和约束?(业务流程Business Process)
前提是什么?涉及哪些对象(资源(人,才,物))
使用环境?environment(往往会涉及到非功能性需求和为配合环境的部分功能要求)
B)针对每个角色进行分析

B1)用什么?(怎么参与)(做什么?)(角色在这个用例中的位置,使用这个功能的什么操作,什么数据?)

用什么?(Which Operation),怎么用?how (when,where,precondition,constraints)
涉及到谁?(Which objects),

B2)怎么用?前提是什么?涉及哪些对象?操作步骤如何?每步操作需要的数据和约束是什么?会产生哪些数据?得到什么样的结果?如果涉及到人机交互,那么交互的方式如何?
C)迭代
在上述的分析过程中,用例会细化成小用例(功能),角色也会更加具体化,重复上述过程,直到不需要分解为止。

3、结果:业务约束,流程,数据结构与数据流,相关纸质,电子文件等。

在分析过程中一个重要的原则就是时刻要记住系统需要解决的问题是什么,对那些与系统目标暂时无关的东西应该放在一边(但不能忘记,因为这些东西里面可能会产生新的需求,新的项目)。一般的业务系统首先要满足的日常业务的支撑,因此对这类系统进行需求分析的最基本的方法就是收集他们如何手工做(或已有的系统怎么做),然后在这些需求的基础上进行优化(怎么做得更好?业务重组)。需求分析的另外一个要点就是在需求调研的时候不能只听不问,所以在需求调研之前应该做足功课,以防真正调研的时候被客户牵着鼻子走。这对于项目型和非项目型的产品都一样重要。

 

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:1691088次
    • 积分:23233
    • 等级:
    • 排名:第287名
    • 原创:606篇
    • 转载:14篇
    • 译文:0篇
    • 评论:526条
    博客专栏
    最新评论