软件工程需求分析之七种武器（上）

   背景介绍 

    人物：“我” 

    角色：IT部门系统分析师 

    公司介绍：勤缘电子贸易公司(化名), 年营业额达2亿,主要由销售部门、资材部和IT部门等组成。其中，销售部门负责业务, 资材部负责供应商的开发和采购电子元器件产品,IT部门则负责公司的订单管理系统的开发与实施。 

    系统目的: 该公司本年度把商机管理纳入日程。所谓“商机”是指能为公司带来业绩和利润的客户需求信息。商机一旦提交,公司的销售部、资材部等会就需求完成一些针对该商机而 进行业务的任务。本系统的目的是管理追综该商机及其任务。 

    现状描述: 前段时间经过业务访谈，已经完成了系统的需求捕获工作，确定了商机管理的范围和目标。 

    任务描述：商机追踪系统需求分析。 



    第一种武器： 长生剑——建模法 

    需求分析常常从建立模型开始,建模的原因主要在于:通过抽象降低复杂度,有助于回忆所有细节,有帮助于与开发者以及系统相关者交流，正所谓一图胜千言。同时，模型本身还可作为系统维护文档。 

    图形模型是图表和系统某些方面的示意性表示,多用一些符号表示较抽象的东西,诸如实体、处理过程、数据、对象、信息和连接等。需求分析阶段的重点是集中在系统需求高度抽象的问题上。 

    在建立模型之前,我们必须搞清楚两个关键概念,即事件和事物。“事件”指可以描述的、值得记录的，在某一特定时间和地点发生的事情。“事物”类似与系统交互的外部实体或参与者,同时,事物构成了系统存储信息的相关数据。 

    参照前面所描述的任务，在分析阶段我们为商机管理建立了事件列表、实体—联系图以及类图等模型数据流图等。而在设计阶段,我们创建的模型有界面设计、流程图、数据库设计、结构图等。 

    商机追踪系统的事件如下:

• 收到商机信息时
•  发布商机时
•  收到任务信息时
•  任务跟进时
•  任务处理完毕时
•  商机结案时
•  商机达成时

    我们对现实世界中事件的认识有助于理解现代编程语言中的事件概念,更让我们认识到编程语言在发展过程中产生了诸多思想和种类,其目的都是为了更好地解决现实问题。 

    让我们列出商机追踪系统基于名词的事物的部分清单，其中包括：商机任务、BOM表、责任人、主题、内容、执行人、任务询价、议价、特价申请、评估、索样，等等。还有吗？也许还有,如果没有了,那么恭喜,你的需求已经提炼完毕。 

    我们把事物列出来本身已经构成需求分析的符号系统。我们可以看到事物之间自然发生的的关系是很清楚的。商机和任务是一对多关系, 即一个商机至少引发一个任务,也可以引发多个任务。 

    我们看到,准确地定义系统的概念、事件、事物、流程是建立模型的基石。甚至可以说是一切需求分析方法的基础。 

    我们需要重点关注的模型图有实体类图和实体关系图(Entity Relation Diagram，ERD)。实体类图描述了实体和实体之间关系的一种图解方式。它可以通过多种Case工具制作,如Visio或Rose。它本身也是UML适用于需求分析的抽象层中的一种模型。实体关系图是一种数据模型,可以帮助我们分析和理解业务或系统的数据组件。 

    实体用单名称来命名,在ERD中用矩形框来表示。实体关系图用菱形框代表关系,它确定了一对实体之间在逻辑上和数量上的连系。关系的命名则要能描述关系的本质。例如“BOM商机”和“任务”之间是“被执行”关系,用语言表达为“ BOM商机被任务执行”或“任务执行BOM商机” 。 

    请客户评审ERD时,要让他们检查图中所显示的关系是否全部正确、合适和全面。 

    下图给出商机追踪的ER图。

图1: 商机追踪E-R图

 

   第二种武器： 孔雀翎——用例法 

   用例的重要功能是用画用例图的功能来鉴别和划分系统功能。它把系统分成角色（Actor）和用例（Use Cases）。角色表示与系统交互以实现某种目的的人、硬件或软件系统。 

   判断角色唯一的标准是它们必须要在被划分进用例的系统部分以外。它们必须能刺激系统部分并接收返回。用例描述了当角色给系统特定的刺激时系统的活动。这些活动被文本描述，它描述了触发用例时受到刺激下反映的本质，输入和输出到其他活动者和转换输入到输出的活动。用例文本通常也描述每一个活动在特殊的活动线时可能的错误和系统应采取的补救措施。 用例也可以用活动图来表示。 

   这样说可能会非常复杂，其实一个用例描述了系统和一个角色的交互顺序。用例被定义成系统执行的一系列动作，动作执行的结果能被指定角色察觉到。 

   用例可以完成的目标如下:

• 用例捕获某些用户可见的需求，实现一个具体的用户目标。
• 用例由角色激活，并提供确切的值给角色。
• 用例可大可小，但它必须是对一个具体的用户目标实现的完整描述。在UML中，用例表示为一个椭圆。

   用例转变了需求开发的角度，传统的需求分析方式是研究用户需要用系统做什么，而现在则是讨论用户需要实现什么。用例法的目的是描述。 

   通常我们是用如下方法确定用例：

• 首先明确执行者和他们的角色，然后确定他们各自参与了哪些业务过程。
• 系统所能反映的外部事件，然后把这些事件与参与的执行者和特定的用例联系起来。
• 用特定场景来描述业务过程，将这些场景归纳为用例，并确定每项用例涉及哪些角色。

   商机追踪系统就采用了第一种方法，我召开了一系列用例获取和分析讨论会，每周一到两次，每次会前都要请用户思考他们需要使用新系统执行什么任务。我发现，用例的名称应该表明用户需要达到的目标，而描述用例则需要在名词中使用动词。如此一来，才能真正描述用户的执行任务，即分析员需要描述的用例。 

   经过需求分析, 该电子公司商机管理的角色如下:

•  商机成员：其职责是发布商机。
•  商机管理：其职责是处理和分配商机任务, 常有如下动作:商机分配、验证、询价、议价、索样、确定。

   关于商机追踪系统“商机发布”用例的完全展开描述如下:

 

    第三种武器： 碧玉刀——原型法 

    原型是模型、样品的意思，显然它借鉴了制造业承接批量订单前先索要样品的经验，在系统初始阶段以可以运动的原型来说明需求和分析需求，给人以豁然开朗之感。 这里的思想实际上是以设计来获取需求,以设计原型的“砖”引出了真正需求的“玉”。我们也应该看到现在软件工具的可视化也是促成原型法得以快速生成的原因所在。原型实际上也分为几种：界面原型、概念模型、数据模型。心理学亦表明人们对活动着的界面原型的理解力远远大于对静态事务的理解，这就好像影像对视觉的冲击力远远大于文本一样。 

    一个快速实现的原型在整个需求开发过程中具有如下作用：

• 明确并完善需求
• 研究和设计选择方案
• 可发展为最终产品

    原型的好处有很多, 掌握如下的原则去构建原型相信能获得更佳的效果：

• 安排在项目计划中的创建原型的任务和安排资源。
• 创建之前要陈述用途。
• 创建废弃型原型要尽量快速和经济,最少投资开发那些用于回答问题和解决需求不确定性的原型。
• 对于已经理解的需求不要建立原型,除非是研究设计选择方案。
• 在屏幕显示和报告中使用看似真实的数据。
• 不能期望用原型去代替软件需求规格说明（Software Requirements Specification，SRS）。
• 设计原型可以参考同类型软件的界面, 但设计不要脱离现实需求和目标。

    好，现在就让我们来一窥商机追踪系统原型界面的庐山真面目吧。

图2 新增商机

图3任务追踪

    从上面的原型界面看来，它是HTML的网页格式, 看上去很真实。但我们也会发现，原型法和敏捷开发(XP)的区别在于功能：原型法侧重在于界面和概念的定义，而敏捷开发则重在功能的迭代实现。

 

来源：http://tech.it168.com/m/p/2007-03-22/200703221308636.shtml