前面我一直在反复强调这样一个观点,需求分析不是一蹴而就的,是一个反复迭代的过程。它将从第一次需求分析开始,一直持续到整个项目生命周期。为什么这样说呢?让我们一起来分析分析。
在第一次的需求分析阶段,我们在一段时期内需要与客户进行反复地讨论,这个过程往往是这样一个反复循环的过程:需求捕获->需求整理->需求验证->再需求捕获••••••
需求捕获,就是我们与客户在一起开研讨会,讨论需求的活动。客户可能会描述他们的业务流程,这时我们在纸上绘制简单的流程草图,及时地记录下来;客户在描述业务的同时,可能会反复提到一些业务名词,详细询问这些名词的含义,以及它们与其它名词的关系,用类图或者对象图绘制简单的草图;客户在描述业务的同时,还会提出今后的软件希望实现的功能,如能够展示某个报表、能够导出文件,以需求列表的形式记录下来。一个功能,在需求列表中会有多个需求,而每个需求应当能够用1、2句话,在20个字以内就可以描述清楚。需求列表是客户提出的最最原始的需求,他不掺杂任何分析设计,是我们的每项功能必须实现的内容。需求列表是需求验证以及日后的用户验收测试的依据,不论我们今后如何分析和设计这些功能,都要能如实地实现这个列表中提出的需求。(需求列表应当如何编写,将在后面的章节详细描述。)
需求整理,就是在需求研讨会后,需求分析人员对研讨内容的分析和整理的过程。首先,需求分析人员应当通过用例模型,划分整个系统的功能模块,以及各个模块的业务流程。用例模型分析是一个由粗到细的过程,这样一个过程也是符合人类认识世界的思维习惯的一个过程。最先,我们应当对整个系统绘制用例图,设计用例场景,并依次对这些用例进行用例描述、流程分析、角色分析等分析过程。当然,在整体用例分析的同时,我们还应当进行一个整体的角色分析,绘制一个角色分析图,进行一个流程分析,绘制一个流程分析图(可以是传统的流程图、UML中的行动图,甚至一个简单的示意图,等等)。
然后,我们再在整体用例图的基础上,依次对每个用例绘制用例图。每个用例图中,会更细致地划分出多个用例,并依次进行用例描述、流程分析、角色分析等分析工作。如此这般地不断细化,直到我们认为需求已经描述清楚为止。
在一个系统中,用例需要细化几次,是由这个用例的业务复杂程度决定的。对于一个简单的用例,只需要细化一次就够了;而对于比较复杂的用例,则需要细化2~3次,甚至更多。
用例分析的过程,之所以称之为分析,它掺入了很多需求分析人员对业务的理解与设计:模块如何划分、流程如何设计、业务如何转换,等等。用例分析,还需要让需求分析员与架构师、设计师等技术人员共同协作来完成,因为用例分析还包含对业务需求的技术可行性分析。只有一份可行的需求分析,才能为后续的设计开发扫清障碍,有效降低项目风险。最后,需求分析员应当将需求列表中的内容,逐一地与用例进行核对,以避免分析人员忽略用户的某项业务需求。(后面将详细描述用例模型的搭建过程。)
在用例分析的同时,需求分析人员还需要对业务中的相关事物,制作领域模型。领域模型,是对用户业务领域中相关事物、相互关系、相互行为操作的描述,它是以对象图和类图的形式表达的。需求人员对领域模型的分析,对业务理解的深度,对日后软件的设计,以及软件的功能扩展、升级演化,都起到了至关重要的作用。(后面将更加详细地讲述领域模型。)
最后,当我们完成了一系列的分析整理并形成文档以后,应当对及时地与客户进行反馈,确认我们的理解是否正确,也就是需求验证工作。需求验证工作应当贯穿整个研发周期,并且在不同时期表现出不同的形式。首先,在需求分析阶段,需求验证工作表现为对需求理解是否正确的信息反馈。需求分析人员与客户再次坐在一起,一项一项描述我们对需求的整理和理解,客户则时不时地对一些问题进行纠正,或者更加深入地加以描述。我们则认真地记录,回来整理,并等待下一次的验证。在需求分析后期,我们还可以制作一些简单的原型,更加形象地描述我们对需求的理解,会使我们与客户的沟通更加顺畅。随后的设计开发阶段,我们则应当以迭代开发的形式进行。每开发完一个迭代周期,将开发的成果与客户反馈。这样做的结果是,客户可以及时地提出我们对需求理解的偏差,或者及时提出对我们设计不满意的地方,使我们存在的问题得到及时地发现与解决。问题及时的解决,使我们修复问题的代价得以降至最小。之后,当开发进入到验收测试阶段,我们则是与客户一道,一项一项地验证我们的软件是否满足需求列表中要求的业务需求。最后,当软件迎来下一次升级开发时,我们将开启另一次轮回。
因此,需求分析就是按照这样的过程,每次多理解一些,再多理解一些,更多理解一些,逐渐深入的过程。每深入一步,我们的软件就更接近客户的满意。
分享到:
相关推荐
我们应当怎样做需求分析 我们应当怎样做需求调研:初识 3 我们应当怎样做需求调研:拜访 5 我们应当怎样做需求调研:研讨会 6 我们应当怎样做需求调研:需求研讨 8 我们应当怎样做需求调研:迭代 10 我们应当怎样做...
系统分析是传统软件工程生命周期里的一个环节,亦即:分析-->设计-->开发-->测试,当然,整个过程会有迭代和变更,但仍...系统分析的成果是需求分析说明书,该文档必须正确、详细、完整地对软件要实现的需求進行说明。
为了解决运送不相容货物的带时间窗的多行程车辆路径问题,需要制定一个明确的路径规划来服务一组客户,以满足客户运送不相容的大宗货物的需求。车辆在工作日期间允许执行多个行程,目的就是最大限度地减少使用车辆的...
凯夫 使用Docker-Compose迭代... 它通过分析和协调项目源撰写文件中的更改来自动推断关键配置参数。 可以手动覆盖配置参数,以更好地控制Kubernetes上的云应用程序部署。 Kev减少了团队中对Kubernetes专业知识的需求。
Snapseed:针对批量处理照片需求的功能迭代.pdf
阿里巴巴智能选品,为企业提供比价寻源功能 (12.3-11月迭代) 必有业务订单流程(12.3-3月迭代) 采购订单支持excel导入(12.3-4月迭代) ...采购需求分析可用量参数增加要货待入量、配货待入量、配货待出量
企业级研发项目管理系统-唛盟xm属于唛盟生态的专业子系统之一,以研发管理为核心,涵盖项目规划、需求管理、开发迭代、版本控制、缺陷跟踪、测试管理、工时管理、效能分析等环节,实现项目全过程、全方位管理的一站...
为什么要迭代? 迭代的基本流程 产品决策:需求的分析/评估 Feature-List的确定 开发流程及版本跟进技巧 上线接收反馈/评估
机械行业周报:受益于军机迭代和民机交付,高温合金需求快速增长.pdf
针对物流网络需求的不确定性, 以区间的形式度量各种变量, 建立基于重心法的物流网络区间节点决策模型。考虑物流网络实践应用性特征, 对区间解的性质判定及关系比较进行标定, 实现求解模型的确定性转换。将区间运算与...
图书管理系统是典型的信息管理系统。系统介绍了图书系统的开发... 利用其提供的各种面向对象的开发工具,首先在短时间内建立系统应用原型,然后,对初始原型系统进行需求迭代,不断修正和改进,直到形成用户满意的可行系统。
涵盖项目规划、需求管理、开发迭代、版本控制、缺陷跟踪、测试管理、工时管理、效能分析等环节,实现项目全过程、全方位管理的一站式研发管理解决方案
在这其中,作为沟通桥梁的需求分析同样可以应用敏捷的过程方法参与到生命周期的演进。敏捷需求分析将在需求时机与过程、文档要求、变更、参与者角色等方面展现其不同传统的特性。本文将结合电信业背景及企业实际情况...
在这其中,作为沟通桥梁的需求分析同样可以应用敏捷的过程方法参与到生命周期的演进。敏捷需求分析将在需求时机与过程、文档要求、变更、参与者角色等方面展现其不同传统的特性。本文将结合电信业背景及企业实际情况...
,需求分析就是:观察——筛选——判断——迭代。这同样是一个产品的从零到一的发展历程,每一步都任重而道远。今天终于要完结了,内心还是忐忑不安的,一方面特别兴奋,能够将自己的学习与实践经验认真总结,并得到...
课程设计报告要有需求分析,总体分析,模块的划分,对各功能模块有详细说明,输入/ 输出说明,附程序源代码,对程序中的算法、设计的精巧之处有所论述。 一、面向过程设计题1----用迭代法求a的立方根 二、面向过程...
本方法还融入了敏捷过程中的"迭代细化"思想,在需求获取和分析过程中通过不断的迭代过程,使需求分析结果逐渐趋向于的用户要求,最终形成一套完整的用户需求文档。使用本方法生成的文档中不仅包括了软件原型界面,还...
云端知识库APP需求管理工具报告委托单位软件需求分析课程承办单位 G03关于工具我们采用了oBridge作为项目的需求管理工具。覆盖项目、任务、需求、缺陷、迭代