 | Level: Intermediate Judith Myerson (jmyerson@bellatlantic.net), Systems Engineer and Architect
15 May 2008 Want to know how to move up to the system requirements engineering framework
(REF) in Service-Oriented Architecture (SOA)? Learn about issues related to shifting
to the framework, soft-goal operationalization, and completing the framework with
constraints, risks, and changes. Regular developerWorks author Judith Myerson gives
you examples of developing soft goals and suggests ways to operationalize one goal.
Introduction
"Close
enterprise system gaps with multiple SOAs"
(developerWorks, Feb 2005) explores how you can reuse Web
services—data-centric and business logic—from one or more SOAs and
combine them into a composite application.
"Tight
coupling Web services in the SOA "
(developerWorks, Jan 2008) looks at the pros and cons of both tight and loose
coupling Web services, and the resulting change in scale that comes from tight
coupling.
These
articles address various aspects of SOA development. This article covers how
you should adapt the system REF to individual Web services that comprise an SOA
application as a way of closing system gaps with multiple SOAs. Learn about how business and system requirements engineering can improve performance and system security of an SOA application comprised of SLA Web services loosely coupled to the greater extent and tightly coupled to the lesser extent.
Traditional requirements
engineering
Traditional requirements engineering, the first step in the software development
process, determines the functional and nonfunctional needs or conditions that must
be met for a new product or system:
-
Functional requirements specify the behavior or functions that a system
or product must have.
-
Nonfunctional requirements specify quality criteria you use to
determine how the system should behave or function.
Defining requirements engineering doesn't explain the whys of its process;
it only tells you what you need to do and how you should proceed in the
elicitation, analysis, validation, and documentation of requirements engineering.
Shifting to system
requirements engineering framework
To explain the processes, shift to the system REF. This framework starts with
system context and goals as inputs to requirements, and completes its run with
constraints and risks to requirements. It repeats the processes in response to
major changes in system context, goals, constraints, and risks.
Not to be overlooked in the framework is the stakeholder participation in
designing one or more goals. Stakeholder participation lets analysts weigh
different goal opinions from different stakeholders on formulating requirements in
response to changes in SOA constraints and risks.
System context considers requirements sources that are necessary for the
elicitation, negotiation, and documentation of requirements on building SLA Web
services. Changes in system context might necessitate changes in goals. Some
examples of system context changes include:
- High-speed bandwidth upgrade for faster response.
- Enterprise network expansion as a result of mergers and acquisitions.
- Adding an SOA to close enterprise-system gaps.
- Tight-coupled SLA Web service components.
- Grid computing to harness unused resources.
All changes must be versioned, validated, documented, and monitored.
Operationalizing soft
goals
Goals aren't always hard and measurable; some are soft as well. The analysts need
to operationalize soft goals into implementable requirements. In the framework,
you can incorporate new changes before you turn soft goals into implementable
requirements after you've implemented, validated, and versioned the requirements
or after new constraints are imposed on system context. Traditional requirements
engineering doesn't let you incorporate new changes after you implement the
requirements.
For instance, you specify a hard goal that a Web service must make service
available; it acts as an automatic SLA Web service. At the same time, the goal
originator or an agreement between the agents focuses on, say, three soft goal
variables that the analysts can turn into implementable requirements. They include
uptime availability, exceptions, and availability variables. You can make changes
later on.
First soft goal: uptime
availability
The first soft goal specifies uptime availability that must be guaranteed to
achieve, say, 99% or more of the time. The goal originator or analyst decides what
penalties to impose when the availability time falls below the guaranteed time,
and what incentives to offer when the availability time remains at least
guaranteed time within a given period of time.
Second soft goal:
exceptions
The second soft goal specifies exceptions, such as planned failures, denial of
service, scheduled maintenance, network outages, and network issues within the
control of a service provider. The goal originator or analyst includes these
exceptions after determining which penalties for service downtime by the provider
are unfair and unreasonable. When conditions for the first soft goal significantly
change, the analyst can add new exceptions or subtract existing exceptions from
the second goal.
For some exceptions, the goal originator may specify the client companies get
reasonable recompensation. Too many exceptions can cause a client to choose a
competitor's SLA Web services that offer fewer exceptions, more uptime in business
operations, and better service guarantees. The soft goal should give the client
the opportunity to choose exceptions as permitted by the service provider.
Third soft goal:
availability variables
The third soft goal specifies service availability variables. Table 1 shows a
list of the variables with an explanation for each.
Table 1. Service availability variables
| Availability variable | Explanation |
|---|
| Statefulness | Server must respond correctly in the subsequent states. |
|---|
| Access | Unauthorized user successfully accesses a control that only the
administrators are authorized to use. |
|---|
| Response time | Web service is available and responds reliably and quickly, otherwise
impatient users will go to competing service. Exceeding maximum number of
response interruption thresholds will adversely impact response time. |
|---|
| Versioning | A new build won't break an existing Web service's functions. If the
functions are broken, they're restored with versioning procedures. |
|---|
| Time out | The steps the Web service needs to take if it times out. It can go to
another Web service with the same or different sets of tasks or
functionalities. Alternatively, it can send an alert to the user that the SLA
Web service has timed out. |
|---|
When the first and second soft goals change, the types of availability variables
change.
Operationalization example
Let's take a look at an example of how you can operationalize a soft goal on an
access availability variable. To turn this soft goal into an implementable
requirement, you need to build a quality model and then populate the model.
For example in building the model, the analyst should let the stakeholder judge
how promptly a service is available. The stakeholder can recognize the time
required for a service to make a service available to the organization and the
time to download the document as long as the service isn't interrupted.
Then the analyst populates the quality model with the data about the system
behavior the stakeholders desire. The stakeholders who have the proper access
authorizations can require that the service be available 99% of the time and that
the download time per page of the document be no more than four seconds.
Similarly, for a document to be accessible, stakeholders might require that they
be able to access the document for no more than 20 seconds.
The stakeholders and the goal analyst must agree on what data on exceptions to
include in the quality model if the stakeholders find service availability
penalties to be unfair and unreasonable, such as scheduled maintenance, denial of
service, and network outages not within the control of a provider. In addition,
quality model data should include data on statefulness, access, response time,
versioning, time out, and other SLA Web service availability variables.
Constraints, risks, and changes
To complete the framework in the first round, you need to perform a few more
steps. First, you validate requirements to ensure they work properly as originally
intended, assuming that constraints on system context haven't changed. As part of
the validation process, you need to assess risks of service availability if you
intend to offer SOA applications consisting of tightly coupled and loosely coupled
SLA Web services over the Internet. If the results show high probability of risks,
you might want to change goals and requirements to mitigate the risks to more
acceptable levels.
However, if monitoring shows new environmental constraints emerged after the
validation process is completed and risks have been mitigated, the constraints may
adversely impact or limit the requirements. This means you need to re-evaluate
what new constraints on system context are, what current constraints are no longer
applicable, and what part of goals and requirements can be reused.
Then you add, delete, and change goals as new inputs into implementable
requirements, and repeat the validation and risk mitigation processes in the
framework. Just make sure all processes of change are documented in each stage of
the framework to let the analyst and those in other roles do impact analysis if
needed.
Conclusion
You need a project team of developers, system administrators, and requirement
developers to collaborate on moving up to system REF in the SOA. Plan ahead for
shifting to the REF and turning soft goals into implementable requirements.
Resolving the issues around completing the framework with constraints, risk
mitigation, and change management makes shifting to the framework much easier.
Your team can use
IBM® Rational® RequisitePro®
to manage their requirements, improve traceability, strengthen collaboration,
reduce project risk, and increase quality. You can integrate this software with
IBM Rational Portfolio Manager
to provide business case management and the periodic management and strategic
reviews of initiatives. You can also use
IBM Rational Method Composer
to amend the processes when changes are identified and
IBM
Rational ClearQuest®
to increase productivity by reducing testing time.
Resources Learn
- Read
other developerWorks articles by Judith M. Myerson
for information on how to work with Web services in enterprise-wide SOAs.
- Check out Judith's series
Use
SLAs in a Web services context
for details on SLAs.
- Get more information about requirements
engineering in
"Integrating IBM Rational RequisitePro with IBM
Rational Portfolio Manager"
(developerWorks, Aug 2007).
- Judith M. Myerson's book,
The Complete Book of Middleware
,
focuses on the essential principles and priorities of system design and emphasizes
the new requirements brought forward by the rise of e-commerce and distributed
integrated systems.
- Get the business insight and the technical
know-how to ensure successful systems integration by reading
Enterprise Systems Integration, Second Edition
.
- Bring your organization into the future with
RFID in the Supply
Chain
, which explains business processes, operational and implementation problems,
risks, vulnerabilities, and security and privacy.
- IBM Redbooks®: Get into the nuts and bolts
of developing an SLA in
Tivoli Manager for Domino V2.1: Fulfilling Service Level Agreements Using Tivoli Technology.
- The
SOA and Web services zone
on IBM developerWorks hosts hundreds of informative articles and introductory,
intermediate, and advanced tutorials on how to develop Web services applications.
- Play in the
IBM SOA Sandbox!
Increase your SOA skills through practical, hands-on experience with the IBM SOA
entry points.
- The
IBM SOA Web site
offers an overview of SOA and how IBM can help you get there.
- Stay current with
developerWorks technical events and webcasts.
- Browse for books on these and other technical
topics at the
Safari bookstore.
- Check out a quick
Web services on demand demo.
Get products and technologies
- Innovate your next
development project with
IBM trial software,
available for download or on DVD.
Discuss
About the author | | | Judith M. Myerson is a systems architect and engineer. Her areas of interest
include middleware technologies, enterprise-wide systems, database technologies,
application development, network management, security, RFID technologies, and
project management. |
Rate this page
| |
