项目需求分析是任何项目开始前的必经阶段,也别认为是项目开发中最重要的一环。书店和网络上关于如何进行需求分析的文章已经很多了。在这里我也谈一下自己的理解。
众所周知,在我们第一次从用户那里获取需求的时候,往往得到的是一些很模糊、笼统的要求,而且这些要求主要都是集中在功能要求方面,对性能要求则少有提及。比如我最近负责的一个项目,用户交过来的项目需求只有简简单单的一张A4纸,上面只提到6个方面的要求,这些需求都很模糊,更别提性能方面的要求了。要想根据这样的需求来开发一个系统难度和后果可想而知。
下面就以其中一个“用户管理”为例来说明我的方法,先简单介绍一下我的分析过程:
·这个功能到底是什么?
·这个功能由谁来做,功能操作的对象是谁?
·这个功能操作的前置条件是什么?
·这个功能操作的后续流程是什么?
分析过程:
(一)、是什么功能
很明显,从客户的要求上来看,系统必须提供一个可用对用户的日常行为、操作进行监权、限制、管理的功能。具体应该包括:
·显示用户:显式所有的活跃、锁定用户
·增加用户:增加一个下级用户,该用户具备有初始化属性,而且用户日后也可以修改部分属性。用户的活动状态可以由上级管理员控制
·修改用户:修改一个用户
·删除用户:删除一个用户
·权限控制:控制该用户可以做什么,不可以做什么
(二)、由谁来执行这项功能,功能操作的目标对象是谁
从“用户管理”这四个字来看,我们不难看出,具备用户管理这一个权限的用户肯定不能是普通用户,那么谁才具有管理用户的权限,又要有多少人来执行管理呢?管理的对象具体包括那些人呢?从这里开始我们就可以开始一步步扩展了。
首先我们来确定这个功能的执行者,经过和客户的讨论沟通,最终确定这系统的用户包括三种类型:
超级管理员--->部门管理员--->普通用户
也就是说具备管理权限的人只有两类:超级管理员和管理员,被管理的对象是普通用户。
(三)、执行这项功能的前置条件是什么
既然要执行“用户管理”,需要什么前置条件呢?很明显,用户必须首先是具备管理权限的用户、其次用户必须正确登陆系统(其中包括了用户名和密码验证、权限验证)。
OK,既然是用户必须首先登陆,那么系统必然要提供一个使用户能耐登陆的界面,同时对用户的用户名、密码、权限进行验证,不同的用户定向到不同的初始化页面,所以从这里我们又可以细化出一个需求:登陆验证
(四)、执行这项功能的后果是什么
管理员在登陆系统、执行相应的操作后有什么响应呢?总不能什么都不给吧,所以我们必须能够将用户操作的结果显式给用户。这就是功能执行的后续结果-从操作页面跳转到显式页面,显式当前修改用户或所有用户的状态。
在我们分析每一个需求的过程中,我们会不断得重复以上这四个步骤,直到我们觉得这个功能已经可以被抽象成一个单独的类或接口了,那意味着我们已经到了需求的叶子节点了(此处我用数据结构中的叶子节点形容已经不能或不需要再细分下去的需求了,其实在某些时候我们必须将某些非叶子节点当成叶子节点,否则需求无限制地细分下去,会没完没了的--这一点对于项目时间比较紧急或采用敏捷开发的项目来说更是如此,前者不用说,后者是因为敏捷软件开发认为不可能在项目的一开始就完全认清楚项目的所有需求,而是通过不断的迭代和重构来细化需求)。
从“用户管理”这4个简简单单的四个字开始,我们可以不断地发现需求点,然后把这些点按操作或时间顺序连接起来会形成一条线,接着再往下扩展,我们会发展需求由一条线变成了一棵树,随着系统其它各个子模块需求的进一步分析,树和树之间的需求会有交叉点,最终形成一张图。
(未完待续)
-------------------------------------------------------------
生活就像打牌,不是要抓一手好牌,而是要尽力打好一手烂牌。
posted on 2008-01-06 16:52
Paul Lin 阅读(463)
评论(0) 编辑 收藏 所属分类:
软件过程与软件方法