面向构件的软件过程：需求阶段

面向构件的软件过程：需求阶段
黄柳青温昱
业务构件在从需求到部署整个开发生命周期都是可复用的基本单位。
--Peter Herzum，《业务构件工厂》
概述
一般而言，需求阶段的目标如下：
* 对有待解决的问题达成一致
* 确定涉众
* 定义系统边界
* 确定用户需求集
* 确定对系统强加的约束
而作为面向构件的软件过程，需求阶段还有一些非常重要的目标：
*识别业务构件
*找出已有资产中的可复用业务构件
*归纳业务构件需求
需求阶段的进入条件、主要角色和步骤、核心工件、退出条件等如图1所示。

图1 面向构件软件过程的需求阶段总览
需求层次及其对策
在面向构件的方法中，“业务构件需求”和“服务构件需求”是何含义呢？这需要先说明需求层次的划分问题。
正如所有复杂的事物一样，需求是分层次的（如图2所示）：
*最顶层的需求称为“组织愿景”。组织愿景是一个组织对将使用的软件系统所要达成的目标的预期期望。比如“希望公文管理系统的实施为我们公司节约30%以上的开支”就是一条组织愿景。不难理解，作为最高级别的需求，组织愿景的目标是宏大的，数量是很少的，一般不应超过2到5条--这也正是它位于“需求金字塔”塔尖的原因所在。
*中层的需求称为“用户需求”。用户需求必须能够体现软件系统将给用户带来的业务价值。
*下层的需求称为“服务级需求”。服务级需求是软件为达到用户需求所必须提供的功能，其数量往往比用户需求高一个数量级。
棱锥图

图2 需求的层次
在实际的软件实践中，我们发现最为重要的“用户需求”往往和数量巨大的服务级需求混淆在一起，这是很有害的，没有突出重点。正如Stephen这位著名的开发经理所说的，让太多“没有直接提供业务特性的需求”充斥在需求阶段是代价巨大的。
我们所提出的面向构件方法，不仅将业务构件与服务构件分离，还将“对客户或用户有业务价值的需求”和“为达成目标软件模块必须提供的服务”分离--这正是前沿开发团队所需要的方式。
这里，所谓“业务构件需求”就是指“对客户或用户有业务价值的需求”。与之相对，“服务构件需求”指“为达成目标软件模块必须提供的服务”。
为了突出重点，需求的确定也分成了两步：
*确定业务构件需求 活动的目的是：将“用户需求”分配给业务构件。该活动由需求分析师在构件库管理员的协助下进行。
*确定服务构件需求 活动的目的是：根据上游分析和设计活动的结果，确定每个服务构件的服务级需求。该活动由架构设计师在构件库管理员的辅助下进行。
捕捉领域词汇
该活动的目的是：定义在系统开发过程中使用的领域词汇表或领域模型，统一所有涉众对问题所处领域的认识。该活动由需求分析师辅助领域专家进行。
任何一个项目都应当一致地使用同一套领域术语，这些术语的定义应该采用用户语言，并与相关问题领域所使用的术语相一致，从而避免在项目团队成员之间造成误解。
捕捉领域词汇的具体方式有两种，采用何种方式可以视具体项目和团队所熟悉的技能而定：
*词汇表（采用自然语言）
*领域模型（采用UML）
一方面，建模较之使用自然语言的词汇表，具有“大局观更好”的优点。另一方面，文字方式自有它的适用场合，而这些场合下建模方式反倒是笨拙的。如表1所示，为银行卡的卡号业务规则说明。

o     位数：16位
o     格式：xxxxx yyyy zzzzzz n
o     说明：
n      xxxxx为银行卡组织为各总行卡机构分配的标识号
n      yyyy为各银行发卡子机构分配的联行号
n      zzzzzz 为发卡序号
n      n为检验位

表1 银行卡卡号的规则说明
需求捕获
该活动的目的是：捕获系统的功能需求和非功能需求。该活动由需求分析师在领域专家及客户等相关涉众的帮助下进行。
值得说明的是，你的需求并不仅仅来自客户，而是来自处于不同层次的多方涉众，如图3所示。

图3 需求来自多方涉众（图片来源：《软件需求（第二版）》）
确定参与者和用例
该活动的目的是：通过确定与本系统交互的人或外部系统、描述系统必须处理的内容的方式，来定义系统的范围。该活动由需求分析师完成。
参与者是在系统外部与系统进行交互的人或系统。找出参与者有助于确定系统的边界，还有助于理解系统的目的。
找到了参与者之后就要寻找系统的用例。找出用例的最好方法就是研究下列问题：
*  针对每一个参与者，系统将参与完成哪些任务？
*  参与者需要获知系统何种情况？
*  参与者是否需要将外部的变化通知系统
*  用例是否覆盖了前景文档中的全部特性？
*  系统要修改和建立哪些信息，参与者需要如何参与其中？
*  用例需要支持系统的管理和维护吗？
在面向构件软件过程的需求阶段，仅要求给出用例名称和简短描述，这是必须的。至于用例场景的细化描述，是后面“分析与高层设计阶段”的“业务构件分析”活动的职责；而且，非常重要的是，在“分析与高层设计阶段”中，某个用例是否要有完整的事件流描述也应该视具体情况而定--对所有用例进行一刀切式的大规模细化是很浪费的。
识别业务构件
该活动的目的是：识别业务构件，并将捕获的功能需求和非功能需求分配给每个业务构件。该活动由需求分析师在领域专家的帮助下进行。
Peter Herzum等人在《业务构件工厂》中指出：“业务构件不仅是一个构件，它也是在解决方案空间内对问题空间内的业务概念的一种直接表达和实现。……业务构件的合适候选者是相对于业务域而言真实并独立的那些业务概念。”
为达到识别业务构件的目标，我们需要深入考察“捕获领域词汇”活动所获得的《领域词汇表》或《业务模型》，理清各个业务概念之间的关系；然后，需要将需求结构化，从而使每个用例总是从属于或分配给一个业务构件。
业务构件是完成特定业务功能的整体，通常其内部封装了展现逻辑、业务行为和数据管理。典型地，一个业务构件对应需求中的多个用例。因此，通过将用例分组，可以帮助确定所需的业务构件。
需求结构化的要点在于：在充分理解需求的基础上，为“把系统分解为无重叠的业务构件”提供有力支持，从而支持作为上游活动的需求分析工作。其工作成果中就应当包含某种级别单位，这种单位可以和业务构件有一一对应关系。
可复用资产分析
该活动的目的是：在项目周期的第一时间识别可复用资产。该活动由需求分析师辅助构件库管理员进行。
此活动的上游活动是“识别业务构件”，构件库管理员和系统分析师一起，将新近识别出的业务构件和构件库中已有的业务构件进行对比、分析，提交《可复用业务构件列表》文档。
值得说明的是，经过可复用资产分析活动之后，上游的“识别业务构件”活动的工作成果可能会有一定的调整。这是因为，构件库中所积累的业务构件往往是经过了多次复用并锤炼的结果，其设计往往是经过优化调整的；此次项目中识别的业务构件，应充分重视已有的成熟业务构件所提供的参考意义。
确定业务构件需求
正如所有复杂的事物一样，需求是分层次的。如前所述，“用户需求”必须能够体现软件系统将给用户带来的业务价值，而“服务级需求”是软件为达到用户需求所必须提供的功能，其数量往往比用户需求高一个数量级。若将最为重要的“用户需求”和数量巨大的服务级需求混淆在一起，往往会忽视重要的业务特性。
我们所提出的面向构件方法，不仅将业务构件与服务构件分离，还将“对客户或用户有业务价值的需求”和“为达成目标软件模块必须提供的服务”分离--这正是前沿开发团队所需要的方式。
“确定业务构件需求”活动的目的是：将“用户需求”分配给业务构件。该活动由需求分析师在构件库管理员的协助下进行。
小结
从宏观上看，整个软件过程是一个从用户头脑中隐藏的需求到切实可行的软件系统的转换过程。需求阶段非常重要，要得到研需双方共同认可的系统目标，成为后续工作的基础。
这里，尤其应当重视的是需求的分层方法与构件种类直接的对应关系，如图4所示。

图4 需求的分层方法与构件种类直接的对应关系

面向构件的软件过程：需求阶段

相关阅读:

关于普元

次访问

个访问者