需求捕获和需求分析方法探析

2010-01-09李军伟

河北民族师范学院学报 2010年2期

关键词：用例原型界面

李军伟

（承德民族师专信息中心，河北承德 067000）

需求捕获和需求分析方法探析

李军伟

（承德民族师专信息中心，河北承德 067000）

需求捕获和需求分析的目标是发现真正的需求并以适合用户、客户和开发人员的方式加以表示，需求的成败决定着待开发系统的成败。本文详细阐述了“界面原型法”中界面需求及用户角色的需求方法，“用例模型法”中确定边界、建模步骤、用例文档及用例粒度的需求方法，并讨论了两种方法综合应用中功能比对和细化迭代的相关问题。

需求捕获；需求分析；界面原型法；用例模型法

需求捕获和分析是软件开发的第一个阶段，需求工作的成功与否决定着待开发系统的成败。据权威部门统计，目前软件的成功率约为25%，75%的软件是失败的。在这75%的失败中，约有50%以上的软件是由于需求的原因造成的。由于任何一个系统都会有很多的用户，同时每个用户只知道自己如何使用系统，一般没有人知道系统的整个情况，因而不能对待构造的系统有一个准确、细致、全面的了解和阐述。同时需求人员在倾听用户的描述时不可避免会有理解上的不同，所以需求人员掌握的需求与实际需求经常会有差距，如果这个差距在开发阶段或后期才被发现，必然会影响系统的成败。所以合适的需求捕获和分析方法对系统的成败所起的作用不可小视。本文将对“界面原型法”和“用例模型法”的需求方法进行讨论和分析。

1 界面原型法

软件界面是人与计算机之间的媒介。由于在软件开发前期，用户对待开发的系统很模糊，甚至没有自己的理想模型，用户提出的要求就很难量化，结果很容易被需求分析人员忽略。界面原型法使用户在最短的时间内看到待开发系统的雏形，可以帮助用户尽快完善自己的理想模型。根据软件系统的需求产生出的软件系统界面原型，用户可以感性地认识到未来系统的功能、界面风格以及操作方式，从而迅速做出判断：系统是否符合自己的期望，是否能够满足自己工作的需要。需求分析人员可以利用界面原型，通过对操作界面所完成的功能得到进一步的功能需求，并诱导用户修正自己的理想系统，提出新的需求，从而尽早获得更完整、更正确的需求。以收银系统为例，通过登陆、处理、出单、统计等界面操作，用户可以对待开发的系统有一个明确的认识，界面的流转也就是功能或处理的流转，从而将需求进一步的挖掘，得到更加量化、具体、全面的需求。建立界面原型一般需要以下两个步骤。

1.1 界面需求分析

通常一个软件界面的元素包括界面主颜色、字体颜色、字体大小、界面布局、界面交互方式、界面功能分布、界面输入输出模式等。软件界面作为一个整体，其中任何一个元素不符合用户习惯、不满足用户要求都将降低用户对软件系统的认可度，甚至影响用户的工作效率，有可能使用户最终放弃使用系统。围绕界面元素所要达到的设计目的,让最终用户能够获得美感、提高工作效率、易于操作使用系统。如收银系统，用户需要进行大量的数据处理，所以用键盘较多，所以尽可能减少键盘与鼠标的交叉应用。

1.2 用户角色

用户角色是指按照一定参考体系划分的用户类型，是能够代表某种用户特征、便于统一描述的众多用户个体的集合。将用户集合定义为角色模型，同时赋予不同的优先级别，了解记录其界面需求。在一个软件系统中，用户角色定义时所依据体系可以多种多样，一个单一用户可以属于不同参考体系下的不同用户角色，但是一个用户角色要求能够代表一种界面需求类型。如收银员就是按照用户工作职位划分出来一个用户角色，如果按照操作计算机的熟练程度，属于收银员角色中的系统用户又可以分为：熟练用户、生疏用户。

之所以要定义用户角色，是因为不同的用户角色在需求分析过程中的需求目标不同，侧重点也不同，甚至互相矛盾。在一个大型系统中,需求分析人员面对的用户只能是众多单一的用户个体，他们的需求也因人而异。只有明确了用户角色，需求分析人员才能在纷乱复杂而又不甚明了的用户要求中理出脉络，依据用户角色不同的优先级别，平衡众多用户需求中的矛盾，抽象出完整的界面模型。例如，GSP认证的医药经营企业管理信息系统中，对于经营商品的统计，管理部、质检部、计划部、销售部、财务部、仓储部都要做相应的统计，但侧重点不同，需要统计的内容也不同，管理部和计划部侧重于库存合理、质检部和仓储部侧重于数据全面、销售部和财务部侧重于利润，在做界面原型时，分别为各个部门做一组界面，每个部门针对自己的界面组提出具体的要求，分析时就可以将其中的共同点提取出来，而将不同点分别处理，从而可以得到整个系统关于统计方面的界面模型，并挖掘出相应的业务功能，为系统功能的需求分析打下基础。

2 用例模型法

用例(Use Case)已普遍用于捕获软件系统的需求，并得到越来越广泛的应用，它与其它需求捕获技术相比，它成功的原因在于：

>用例把系统当作一个黑盒

>用例提供了一种捕获功能需求的系统而直观的方法

>用例可以驱动整个开发过程，因为大部分活动如分析、设计和测试都是从用例开始执行的[1]。

用例用来捕获系统的功能性需求，从用户的视角描述了在逻辑上相对完整的一个功能流程。用例很直观，用例模型是用来与用户和客户在“系统应该为用户做什么”方面达成共识，可以认为用例模型是所有可能使用系统的方式的完整的规格说明。用例最主要的价值在于：它强调了用户的目标和观点。用例模型法需遵循的原则：

2.1 明确系统边界。需求管理的目标是为了确定正确范围，明确系统边界，即对在里面的对象和在外面的对象进行区分。明确系统边界的关键在于描述交互，而不是内在的系统活动。参与者代表在系统边界之外的真实事物，并不是系统的成份，参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定。如图书馆系统的用例图中,读者、工作人员、管理员是使用系统，所以在边界之外；而相应的借书、图书管理、系统维护是系统所要完成的工作，属于系统成份，在边界之内。

2.2 遵循建模步骤。建模时首先要进行领域分析，建立领域模型；其次整理用户的业务流程，建立业务模型；第三对业务模型的输入输出进行分析，建立用例模型，此时不考虑怎么实现，只是初步的划分，考虑的重点是结构和交互行为，包括用例图；第四是分析阶段的分析模型，分析阶段是进行抽象的过程，不解决具体的实现，包括类图、序列图、协作图、活动图和状态图；第五是设计阶段的设计模型，包括组件图；第六是部暑阶段的实施模型，包括部署图；最后是测试模型。

2.3 使用有效用例文档。用例可以驱动整个开发过程，用例文档是对用例的详细内容进行说明的文档，包括用例名称、标识符、参与者、状态、频率、前置条件、后置条件、基本操作流程、可选操作流程等内容，在用例文档中对于相关内容必须明确和正确的说明，不能含糊，不能有二义性。

2.4 确定用例粒度。确定用例粒度遵循以下基本原则：

（1）控制用例的总体数量：一般来说，一个比较复杂的系统的用例数量可能在30-50个之间。

（2）避免功能分解：功能分解是正确使用用例技术的最大敌人，很多用例粒度的讨论其实都是功能分解的思想在作怪。如医院的管理系统要将收费和取药两个流程改为一个，两个流程要衔接好是主要目标，所以要用一个用例；而如果是把收费和取药一个流程改为两个，因为解决的问题不同，所以要用两个用例；对于领导要查看的门诊量和收费情况统计，因为查询统计只是整个工作流程中的一个环节，所以不能作为一个单独的用例。

（3）不断调整。很多时候在初步规划用例模型的阶段，有时很难判断一个用例的粒度是否合适，不要执迷于一次获得一个完美的用例模型和用例粒度。不妨先得出一个初稿，然后在实际写用例的过程中，根据需要进行调整。

3 界面原型法和用例模型法的综合

“界面原型法”具有直观、清晰、容易量化的特点，用户参照界面原型可以将需求提的更具体、更准确，但缺乏功能捕获的优势；而“用例模型法”是一种捕获功能需求的系统而直觉的方法，可以驱动整个开发过程。

3.1 功能比对

最初的需求分析采用界面原型法，由于界面原型法直观、容易量化，所以在与客户交流时更容易获得相对准确的需求，在大体确定界面应有功能后，根据该界面的功能描述，可以确定哪些功能由哪些用户实现，从而与用例模型中相应参与者的功能进行比对。“界面原型法”中“用户角色”定义与“用例模型法”中“参与者”的确定有大致相同的功效，所以针对这个交叉点，除去“用例模型法”中参与者的非“使用者”因素，将二者进行叠加，互相补充、互相比对，将不相交和不相容部分进行进一步挖掘，补正纠误，因为从不同的角度考虑问题，所以在获得的需求上能够更全面、更准确，为项目的顺利进行打下良好的基础。

以“GSP认证的医药经营企业管理信息系统”为例，在进行销售部的界面设计时，需要的信息是销售单位、库存数量、单价，在销售单位中又要明确应收款额度、信用度信息，但缺少对GSP认证时需要的单位资质信息。在GSP认证的用例设计中，单位的资质信息是必须的，而这个资质信息又是销售部门在为销售单位建立原始档案时提供的，所以在进行销售单位的数据处理时，就需要增添必要的资质信息。销售单位的应收款额度、信用度又是财务部提供的信息。所以在进行销售单位的数据处理时，还要为财务部预留相应的字段空间。通过“界面原型法”和“用例模型法”综合应用，为系统的需求捕获和分析提供了一种行之有效的解决办法。

3.2 细化迭代

在确定了界面元素后，就要为控件的行为及状态变化制定相应的状态迁移图，状态图和时序图把重要的控件状态变化及相应顺序进行了描述，基本上完成了界面设计。针对功能性需求，建立问题跟踪图表，对每一个提出的问题，均需要记录上去，把问题结果记录下来，根据这些表，可以很好地了解自己工作中的核心问题，并有了解决它的方向，提高了工作效率。每进行一层的细化，都把结果交付客户审核，由他们进行提出何时能终止细化，当对方认为已达到了效果，确认可以结束。选用迭代法，把一些错误的影响在功能分析和界面分析的不断迭代过程中加以改正。