需求分析原则和注意事项

转美女同事:http://blog.sina.com.cn/s/blog_4e296f0a0100jrt9.html

 

近几年，UML 在可视化软件开发方面获得了一定程度成功。随着UML 2.0 的到来，对大型及复杂的系统与软件进行建模已经变成现实。为了做到这一点，我们需要理解模型与其它系统工程领域，特别是需求管理的关系。

需求管理与系统模型的关系是什么呢？它们怎样才能工作到一起？本文的目的就是从流程的角度来回答这些问题。

需求管理与系统建模

图1 通过三明治的类比总结了需求管理与系统建模之间关系的关键概念。

在这个比喻中，需求管理是开发周期中的“面包和奶油”。三明治没有面包会成为什么？但是，只有需求管理会有点干；通过系统模型的填充可以把面包连在一起，并使得整体变得更有意义。正是面包及填充物才构成了三明治。系统模型不是需求，许多工程师错误地认为系统模型自身就是对需求的详细描述。事实上并非如此。即使UML模型已经详细到能够生成代码，但是也有些系统方面——特别是非功能需求，如性能，安全等无法从系统模型中获得。这些额外的需求也必须被跟踪并需要有测试用例与之对应。这需要有需求管理活动对建模进行辅助。

仅使用模型作为合同的描述也是很困难的；在大多数情况下，客户/供应商的合同依然需要使用文本文档来表达。模型也许会在文档中以图形的形式出现，但是仅有图形对合同来说还是不够，因此，需求与系统建模是相辅相成的。

层次控制复杂性

图2 显示了系统工程的一种典型的层次化方法。这种层次很重要，不仅作为对当今复杂系统的分解方法，也是因为工程流程几乎总是涉及多个组织。不同的组织也许要执行不同的工程层次。

层次代表抽象的水平。这些抽象层次的一个重要特点是每层可以使用不同的语言，但是术语必须被映射到模型术语上。例如，问题领域的工程师可能很自然地谈到涉众而不是执行者、实体、类、关系、能力与用例。建模的障碍主要是必须学习一种新词汇及由此带来的困惑。

建模应该发生在所有层次，但是具有不同的抽象程度。这意味着同一实体可能在每个层次的模型中扮演不同的角色。图3说明了下面的例子：例如，当对行李登记系统的涉众层进行建模时，叫做“飞机”的类也许会代表实际的物理实体。在系统层，“飞机”类也许代表系统的飞机的逻辑表示（如果你喜欢，可以叫做关于飞机的系统知识）并包含属性细节。最后，在软件设计层次，“飞机”类将代表飞机对象的软件实现。

试图在一个模型中管理不同层次的抽象会增加复杂性。因此不是力图在一个UML模型中同时对同一个实体进行所有三种形式的表示，而是采用在每个层次建立分离的模型方法。上层模型的一些细节将被下层模型引用，但是，各种实体角色将随着模型层次而逐步细化。跟踪技术可以通过层次对模型之间进行映射。

系统的系统

了解被开发的系统，最重要的是了解其上下文内容。在开发前期使用的一种著名的建模方法就是绘出“上下文图表”，来描绘系统与环境的外部关联。

这种核心观念来源于“系统的系统”思想，如图4。对问题领域进行建模时，不仅对系统本身进行建模，而且要考虑封闭的系统。所创建的模型是域模型，它描述系统的外在部分及其接口。系统作为一个实体存在于域模型中，并可能参与到一些图符中，但是，在这一层它是“黑盒”，是对系统本身进行建模的开始。

意识到一些设计发生在所有层次是很重要的。即使是在对问题进行建模时，部分模型将描述系统已存在的部分，部分描述将要实现的系统。新的封闭系统设计过程中这一点很明显，此处的封闭系统指所要开发系统的外部支撑系统。

建模为设计提供依据

建模支持设计活动。它可以帮助工程师充分理解系统怎样从一个特定层次的需求分解到下一个层次的需求。需求本身也是不断细化的要求的一个缩影。建模也是创造性工作发生最多的地方，形成了包含模型图符的设计文档与文本解释、依据及上下文内容。

图5描述了模型可以用来从上一层需求推导出下一层需求的方式。左侧的方框代表需求文档，右侧的代表设计文档。虽然许多模型非常专业，但每个系统都有一些方面可以用UML 2.0这样的方式来建立通用模型。大多数系统具有实体、事件、状态、接口与执行者，它们以各种方式相互关联，可以用不同的UML 图符进行建模。

设计文档也能够表达模型中所没有包含的与非功能分解相关的需求。通过这种方式，对于系统的特定层次来说，设计文档就可以成为单一的参考点。

把设计从需求文档（及其可跟踪性的维护）中分离出来也使得重用设计与建立产品设计库成为可能。

建模的例子

涉众层（问题域）

这一层把初始需要的陈述作为输入需求，并推导出涉众需求。这一层根植于问题域。

这一层的建模重点是封闭系统，即“行李登记系统”所嵌入在的“行李处理系统”。一个关键的目标是为系统域建立词汇表。这些词汇随图形单元如类、执行者、用例与状态的增加被收集在模型中。

首先用类图建立封闭的系统，其中的行李登记系统以类的形式也存在于系统中。这一系统如图6所示。行李登记系统与其它类之间的关系是用来定义系统的周围环境的。

这一阶段，模型另一部分是用例图。一个用于封闭的行李处理系统（图7）， 另一个用于行李登记系统（图8）。

图7采用“系统的系统”视图，在其它交互系统的背景下描述行李登记系统。

第二个图的目的如下:

• 帮助定义系统边界，用矩形标示，用UML 的术语来说叫做“主题”，是行李登记系统类的一个实例。
• 把涉众与外部系统表示为执行者。它们在系统边界的外部。
• 把用例的名称作为涉众的最高目标。注意在用例之间的“包含”关系，这允许根据能力对系统进行分解。

图9显示了这一阶段的另一种图，一种构架图。在这里封闭系统被它的内部部件所描述，其中之一是行李登记系统。也显示了与周围部件的接口。

注意在这一层中我们只允许在顶层用例中描述行李登记系统的细节。在其它图中，行李登记系统作为“黑箱”存在，并对其外部关系进行建模。

从这一层的模型中，可以推导出下列的需求管理工件：

• 从模型中发现基于领域的术语词汇表；
  例如，每个类、执行者与用例形成词汇条目，同时也提供相关的文本解释。
• 基于模型中执行者的，行李登记系统的涉众列表。
• 基于类的关联与部件接口的外部接口与外部系统的记录。
• 行李登记系统场景列表。
• 基于如主要用例图中使用“包含”关系的来形成层次结构，也可以用于涉众需求文档的层次结构
• 对于每个用例，涉众所要求的关键能力。
• 涉众提出的关键约束能力列表。这可以从评审每个图并询问用于提取约束问题，如“多快？”，“使用频率？”等获得。约束有时可以在适当用例的注释中表示。例如，在行李登记系统中，或许有个用例叫做“秤量行李”，在注释中说明“两分钟内被放在传送带上”。

能力需求很可能会被工程师重新用文本方式表达，利用术语表中的词汇画图。能力经常被具有数量的质量需求详细描述，如性能，它们没有被模型所表达。除此之外，在模型中没有表达的分离的约束必须用文本捕获。

系统开发层

这一层把涉众需求作为输入需求，并推导出系统需求。这一层从抽象的角度看根植于解决方案域。

在抽象解决方案层，我们开始考虑功能与行为而不是能力。问题层模型现在被细化来显示用于提供能力的功能步骤。前面的类图用属性来细化，如图10。

系统行为通过顺序图与状态图结合描述。图11 显示了一个顺序图的例子。

一个构架图也可以被用于把行李登记系统首先分解成子系统与部件。如图12 所示的例子。外部的矩形框现在是行李登记系统，而在图9中是以内部框的形式出现的。这里形式化建模的一个最大的好处就可以显示出来了，被分解的层次接口的一致性可以被工具自动检查。

系统建模最后，可以推出下面三条：

• 系统需求与每个被识别的系统功能相关。
• 一个顶层的构架显示子系统与内部接口。
• 一组子系统需要被开发。

对于每个被识别的子系统现在产生了一个新的需求层。

子系统开发层

这些层以系统需求作为输入需求，完成顶层构架并推导子系统需求。这些层的特性与系统开发层很相似，只是现在的重点是一个单一的子系统。在系统层的建模与设计依据的重点是决定哪些系统需求要流向这个子系统。

系统模型与需求管理的集成原理现在已经被建立起来了，因此我们不必在像先前那样详细地定义下层的细节。

部件开发层

在系统分解的某一水平，子系统成为部件，它们中的一些已经是存在的，其它的一些需要被开发；一些是软件，其它的是硬件。对于软件来说，UML 模型可以处理部件层直到详细设计与代码生成， 并且在这一阶段，可以完全转换到UML 开发工具中来完成整个开发周期。

结论

通过将需求管理与系统建模相结合，我们获得了一种更加准确、易懂的描述复杂问题和解决方案的方法。

系统建模给需求工程带来的好处：

• 系统模型为在需求层之间的设计流程中加入了形式化内容。
• 系统模型支持需求以文本方式表述所用词汇的一致性。（事实上，可以有工具直接从模型字典中提取术语词汇表）
• 来源于系统模型的设计依据成为需求层之间跟踪性的依据。
• 系统模型的结构可以为需求文档提供结构。（通常可以利用工具从模型中建立需求文件的大纲。）
• 系统模型可以被嵌入到系统设计文档中。这些可以为系统模型提供文本的上下文关系，为设计选择、图形解释等提供依据。
• 影响分析可从需求直接过渡到模型。
• 模型所不能捕获的非功能与性能需求可以作为文本陈述来管理。