论坛首页 综合技术论坛

我们应当怎样做需求调研:迭代

浏览 1765 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2012-02-12   最后修改:2012-05-01
前面我一直在反复强调这样一个观点,需求分析不是一蹴而就的,是一个反复迭代的过程。它将从第一次需求分析开始,一直持续到整个项目生命周期。为什么这样说呢?让我们一起来分析分析。

在第一次的需求分析阶段,我们在一段时期内需要与客户进行反复地讨论,这个过程往往是这样一个反复循环的过程:需求捕获->需求整理->需求验证->再需求捕获••••••

需求捕获,就是我们与客户在一起开研讨会,讨论需求的活动。客户可能会描述他们的业务流程,这时我们在纸上绘制简单的流程草图,及时地记录下来;客户在描述业务的同时,可能会反复提到一些业务名词,详细询问这些名词的含义,以及它们与其它名词的关系,用类图或者对象图绘制简单的草图;客户在描述业务的同时,还会提出今后的软件希望实现的功能,如能够展示某个报表、能够导出文件,以需求列表的形式记录下来。一个功能,在需求列表中会有多个需求,而每个需求应当能够用1、2句话,在20个字以内就可以描述清楚。需求列表是客户提出的最最原始的需求,他不掺杂任何分析设计,是我们的每项功能必须实现的内容。需求列表是需求验证以及日后的用户验收测试的依据,不论我们今后如何分析和设计这些功能,都要能如实地实现这个列表中提出的需求。(需求列表应当如何编写,将在后面的章节详细描述。)

需求整理,就是在需求研讨会后,需求分析人员对研讨内容的分析和整理的过程。首先,需求分析人员应当通过用例模型,划分整个系统的功能模块,以及各个模块的业务流程。用例模型分析是一个由粗到细的过程,这样一个过程也是符合人类认识世界的思维习惯的一个过程。最先,我们应当对整个系统绘制用例图,设计用例场景,并依次对这些用例进行用例描述、流程分析、角色分析等分析过程。当然,在整体用例分析的同时,我们还应当进行一个整体的角色分析,绘制一个角色分析图,进行一个流程分析,绘制一个流程分析图(可以是传统的流程图、UML中的行动图,甚至一个简单的示意图,等等)。

然后,我们再在整体用例图的基础上,依次对每个用例绘制用例图。每个用例图中,会更细致地划分出多个用例,并依次进行用例描述、流程分析、角色分析等分析工作。如此这般地不断细化,直到我们认为需求已经描述清楚为止。

在一个系统中,用例需要细化几次,是由这个用例的业务复杂程度决定的。对于一个简单的用例,只需要细化一次就够了;而对于比较复杂的用例,则需要细化2~3次,甚至更多。

用例分析的过程,之所以称之为分析,它掺入了很多需求分析人员对业务的理解与设计:模块如何划分、流程如何设计、业务如何转换,等等。用例分析,还需要让需求分析员与架构师、设计师等技术人员共同协作来完成,因为用例分析还包含对业务需求的技术可行性分析。只有一份可行的需求分析,才能为后续的设计开发扫清障碍,有效降低项目风险。最后,需求分析员应当将需求列表中的内容,逐一地与用例进行核对,以避免分析人员忽略用户的某项业务需求。(后面将详细描述用例模型的搭建过程。)

在用例分析的同时,需求分析人员还需要对业务中的相关事物,制作领域模型。领域模型,是对用户业务领域中相关事物、相互关系、相互行为操作的描述,它是以对象图和类图的形式表达的。需求人员对领域模型的分析,对业务理解的深度,对日后软件的设计,以及软件的功能扩展、升级演化,都起到了至关重要的作用。(后面将更加详细地讲述领域模型。)

最后,当我们完成了一系列的分析整理并形成文档以后,应当对及时地与客户进行反馈,确认我们的理解是否正确,也就是需求验证工作。需求验证工作应当贯穿整个研发周期,并且在不同时期表现出不同的形式。首先,在需求分析阶段,需求验证工作表现为对需求理解是否正确的信息反馈。需求分析人员与客户再次坐在一起,一项一项描述我们对需求的整理和理解,客户则时不时地对一些问题进行纠正,或者更加深入地加以描述。我们则认真地记录,回来整理,并等待下一次的验证。在需求分析后期,我们还可以制作一些简单的原型,更加形象地描述我们对需求的理解,会使我们与客户的沟通更加顺畅。随后的设计开发阶段,我们则应当以迭代开发的形式进行。每开发完一个迭代周期,将开发的成果与客户反馈。这样做的结果是,客户可以及时地提出我们对需求理解的偏差,或者及时提出对我们设计不满意的地方,使我们存在的问题得到及时地发现与解决。问题及时的解决,使我们修复问题的代价得以降至最小。之后,当开发进入到验收测试阶段,我们则是与客户一道,一项一项地验证我们的软件是否满足需求列表中要求的业务需求。最后,当软件迎来下一次升级开发时,我们将开启另一次轮回。

因此,需求分析就是按照这样的过程,每次多理解一些,再多理解一些,更多理解一些,逐渐深入的过程。每深入一步,我们的软件就更接近客户的满意。

我们应当怎样做需求分析
我们应当怎样做需求调研:初识
我们应当怎样做需求调研:拜访
我们应当怎样做需求调研:研讨会
我们应当怎样做需求调研:需求研讨
我们应当怎样做需求调研:迭代
我们应当怎样做需求调研:需求捕获(上)
我们应当怎样做需求调研:需求捕获(下)
我们应当怎样做需求分析:功能角色分析与用例图
我们应当怎样做需求分析:业务流程分析(上)
我们应当怎样做需求分析:业务流程分析(下)
我们应当怎样做需求分析:用例说明
我们应当怎样做需求分析:查询报表分析
我们应当怎样做需求分析:子用例与扩展用例
我们应当怎样做需求分析:行动图和状态图
我们应当怎样做需求分析:业务领域分析
我们应当怎样做需求分析:原文分析法
我们应当怎样做需求分析:领域驱动设计
我们应当怎样做需求分析:非功能需求
我们应当怎样做需求确认:需求列表
我们应当怎样做需求确认:一个需求列表的实例
我们应当怎样做需求确认:快速原型法
我们应当怎样做需求确认:需求规格说明书
我们应当怎样做需求确认:评审与签字确认会

(续)
论坛首页 综合技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics