前面我一直在反复强调这样一个观点,需求分析不是一蹴而就的,是一个反复迭代的过程。它将从第一次需求分析开始,一直持续到整个项目生命周期。为什么这样说呢?让我们一起来分析分析。
在第一次的需求分析阶段,我们在一段时期内需要与客户进行反复地讨论,这个过程往往是这样一个反复循环的过程:需求捕获->需求整理->需求验证->再需求捕获。
需求捕获,就是我们与客户在一起开研讨会,讨论需求的活动。客户可能会描述他们的业务流程,这时我们在纸上绘制简单的流程草图,及时地记录下来;客户在描述业务的同时,可能会反复提到一些业务名词,详细询问这些名词的含义,以及它们与其它名词的关系,用类图或者对象图绘制简单的草图;客户在描述业务的同时,还会提出今后的软件希望实现的功能,如能够展示某个报表、能够导出文件,以需求列表的形式记录下来。一个功能,在需求列表中会有多个需求,而每个需求应当能够用1、2句话,在20个字以内就可以描述清楚。需求列表是客户提出的最最原始的需求,他不掺杂任何分析设计,是我们的每项功能必须实现的内容。需求列表是需求验证以及日后的用户验收测试的依据,不论我们今后如何分析和设计这些功能,都要能如实地实现这个列表中提出的需求。(需求列表应当如何编写,将在后面的章节详细描述。)
需求整理,就是在需求研讨会后,需求分析人员对研讨内容的分析和整理的过程。首先,需求分析人员应当通过用例模型,划分整个系统的功能模块,以及各个模块的业务流程。用例模型分析是一个由粗到细的过程,这样一个过程也是符合人类认识世界的思维习惯的一个过程。最先,我们应当对整个系统绘制用例图,设计用例场景,并依次对这些用例进行用例描述、流程分析、角色分析等分析过程。当然,在整体用例分析的同时,我们还应当进行一个整体的角色分析,绘制一个角色分析图,进行一个流程分析,绘制一个流程分析图(可以是传统的流程图、UML中的行动图,甚至一个简单的示意图,等等)。
然后,我们再在整体用例图的基础上
在第一次的需求分析阶段,我们在一段时期内需要与客户进行反复地讨论,这个过程往往是这样一个反复循环的过程:需求捕获->需求整理->需求验证->再需求捕获。
需求捕获,就是我们与客户在一起开研讨会,讨论需求的活动。客户可能会描述他们的业务流程,这时我们在纸上绘制简单的流程草图,及时地记录下来;客户在描述业务的同时,可能会反复提到一些业务名词,详细询问这些名词的含义,以及它们与其它名词的关系,用类图或者对象图绘制简单的草图;客户在描述业务的同时,还会提出今后的软件希望实现的功能,如能够展示某个报表、能够导出文件,以需求列表的形式记录下来。一个功能,在需求列表中会有多个需求,而每个需求应当能够用1、2句话,在20个字以内就可以描述清楚。需求列表是客户提出的最最原始的需求,他不掺杂任何分析设计,是我们的每项功能必须实现的内容。需求列表是需求验证以及日后的用户验收测试的依据,不论我们今后如何分析和设计这些功能,都要能如实地实现这个列表中提出的需求。(需求列表应当如何编写,将在后面的章节详细描述。)
需求整理,就是在需求研讨会后,需求分析人员对研讨内容的分析和整理的过程。首先,需求分析人员应当通过用例模型,划分整个系统的功能模块,以及各个模块的业务流程。用例模型分析是一个由粗到细的过程,这样一个过程也是符合人类认识世界的思维习惯的一个过程。最先,我们应当对整个系统绘制用例图,设计用例场景,并依次对这些用例进行用例描述、流程分析、角色分析等分析过程。当然,在整体用例分析的同时,我们还应当进行一个整体的角色分析,绘制一个角色分析图,进行一个流程分析,绘制一个流程分析图(可以是传统的流程图、UML中的行动图,甚至一个简单的示意图,等等)。
然后,我们再在整体用例图的基础上