[发明专利]一种基于目标和场景的用例驱动需求获取方法

说明书

技术领域

本发明涉及需求工程领域，具体涉及一种基于目标和场景的用例驱动需求获取方法，用以全面高效的对系统进行需求建模。

背景技术

近年来，需求工程成为了计算机软件研究的热点之一，需求工程是一个项目的开端，在软件开发过程中的重要性已不容质疑。需求获取是需求工程的主体，只有真正满足用户需求的软件产品才能被用户接受，需求获取需要通过不断交流沟通使软件开发者和用户对系统要求形成共识。如何快速地获取并准确表达用户需求，是长期困扰开发者的难题。一些调查表明，设计的软件产品存在的不完整性、不正确性等问题，其中80%以上是需求错误导致的。

随着web服务的发展，网络环境下的信息服务需求在关注对所提供服务的软件要求的同时，还有诸多信息服务之间的交互作用，大大增加了需求分类的复杂性；同时缺乏对非功能需求的分析建模技术也大大降低了现有需求技术的实用性；此外，在开发复杂软件系统时，需求的信息量庞大和复杂，无法验证所获取的需求是否满足用户的要求，或者错误理解了用户的需求描述。以上这些因素都可能导致获取的系统需求不完全或者存在某些错误。

在进行需求获取时，采用系统化的需求获取和分析方法，对于构建系统需求非常有效，一定程度上解决了上面的一些问题。现阶段，系统需求获取和分析方法很多，主要介绍以下三种方法：用例驱动的、面向目标的和基于场景的需求获取方法。其中：

1、用例驱动的需求获取方法

该方法是需求工程中大多采用的方法，用例驱动分析的基本概念是执行者和用例，通过识别并独立分析每个执行者所涉及的所有用例，可以了解系统的每一类用户的要求和愿望，而用户的要求与愿望正是系统的重要部分，所有用例的集合描述了用例的功能。非功能需求则反映的是系统的质量属性的特性和业务规则、法规制度等各种约束，如：易操作性、可靠性、可维护性等。非功能需求不能通过用例得到，但是其中一些非功能需求对用例的实现具有约束作用。通常非功能需求需要写入用例文档中，这些非功能需求需要独立获取。

该方法优点在于用例驱动技术为软件需求规格化提供了一个基本的元素，且该元素是可验证、可度量的，该方法被开发人员普遍接受；缺点在于缺少对需求获取的系统化支持，且无法得知用例的来源，而且非功能性需求通常在用例描述或文本中描述，使需求获取带来一些不便。

2、面向目标的需求获取方法

面向目标的需求获取是近年来兴起的一种需求分析方法，它与软件系统的目标功能更加紧密相关，更加关注需求分析的早期阶段。1987年初K.Yue首先引入目标概念，他除了关心“what”和“how”的需求分析以外，还在对“why”问题理解的基础上，将目标作为判断需求完整性的依据：即需求如果能够满足当前的目标，就说明需求是完整的；如果需求不能满足当前的目标，则说明需求是不完整的。

该方法的优点在于，从需求目标出发来判断需求是否完整；缺点是不能从目标过渡到规格化需求描述。

3、基于场景的需求获取方法

在需求分析中使用场景进行分析的方法源于Objectory并且应用于OBJ。作为需求工程的发展成果，基于场景的需求获取逐步得到了人们的重视。这种方法试图用领域用户熟悉的情景实例引导他们逐步提供系统信息。它首先采集一组现实系统的运行情景，领域用户根据这些情景分别说明现实系统中各种行为及其目的。场景在需求过程中，可以在预想情况下导出需求，帮助发现异常事件，获得面向对象概念模型，通过场景原型理解需求，说明设计结果，创建上下文等。

Jacobson等提出第一个用例驱动的面向对象的分析过程模型，Regnell进一步发展了该模型，并强调了从场景中综合需求模型的重要性。Potts提出了Inquiry Cycle方法，在面向目标的需求分析中，使用场景脚本识别障碍和问题。Sutcliffe提出的SCRAM方法结合了概念证明、场景和设计的基本原理。在OMT中，场景以文本形式出现，规定为一个时间序列，它们可以转化得到一个事件图，采用一种半形式化的表示。

该方法的优点在于，通过场景来引导用户，有效的导出需求；缺点在于并未给出场景的表示形式以及如何去引导用户来获得需求。

发明内容

本发明的目的在于克服上述已有技术的不足，并结合已有技术的优点，提供一种基于目标和场景的用例驱动需求获取方法，比较快速准确的获取需求，提高需求的正确性和完整性并减少需求冗余。

其具体包括，一种基于目标和场景的用例驱动需求获取方法，所述需求获取方法包括以下步骤：