升级到 SOA 中的系统需求工程框架

“使用多重 SOA 来消除企业系统之间的差异”探索了如何从一个或多个 SOA 中重用 Web 服务——以数据为中心和业务逻辑——并将它们合并到组合应用程序中。“SOA 中的紧密耦合 Web Services”研究了紧密耦合和松散耦合 Web 服务的优点和缺点，以及紧密耦合所带来的规模上的最终变化。

这些文章讨论了 SOA 开发的不同方面。本文介绍应该如何调整系统 REF 以适应构成 SOA 应用程序的各个 Web 服务，以此作为使用多个 SOA 来缩小系统差距的方式。了解业务和系统需求工程如何改进由 SLA Web 服务组成的 SOA 应用程序的性能和系统安全性，这些 Web 服务大部分是松散耦合的，只有一小部分是紧密耦合的。

回页首

传统需求工程

作为软件开发流程中的第一步，传统需求工程确定新产品或系统所必须满足的功能性和非功能性需求或条件。

• 功能性需求指定系统或产品必须具有的行为或功能。
• 非功能性需求指定用于确定系统如何运行或工作的质量标准。

定义需求工程并没有解释软件开发流程的为什么问题；它只是告诉您需要做什么，以及应该如何在需求工程的引出、分析、验证和文档说明方面继续下去。

转换到系统需求工程框架

要解释流程，可以转换到系统 REF。此框架从作为需求的输入的系统上下文和目标开始，并使用需求的约束和风险完成其运行。该框架响应系统上下文、目标、约束和风险方面的重大更改而重复执行流程。

不要在该框架中忽略的是参与到设计一个或多个目标的涉众（stakeholder）。涉众的参与允许分析人员权衡不同涉众对制定需求（以响应 SOA 约束和风险方面的变化）的不同目标意见。

系统上下文考虑有关构建 SLA Web 服务的需求引出、协商和文档说明所必需的需求源。系统上下文的更改可能使目标更改变得必要。一些系统上下文更改示例包括：

 

 

本文转自IBM Developerworks中国

        请点击此处查看全文