password
username
Sponsored by CakeMail, an email marketing software.
Newsletter preview


IBM developerWorks Web services/XML tip newsletter
----------------------------------------

IBM's resource for developers
http://www.ibm.com/vrm/newsletter_10802_3426_75364_email_DYN_1IN/mcauq136238161

----------------------------------------
3 June 2008, Vol. 8, Issue 5
----------------------------------------

"UPGRADE TO THE SYSTEM REQUIREMENTS ENGINEERING FRAMEWORK IN SOA"
http://www.ibm.com/vrm/newsletter_10802_3426_75365_email_DYN_1IN/mcauq136238161

Level: Intermediate

Judith Myerson (jmyerson@bellatlantic.net)
Systems engineer and architect


Hello, tip readers.

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.

For the full tip, read on below.

Until next time,
The Web services/XML tip team at developerWorks

Correspondence:
mailto:dwnews@us.ibm.com


_________________________________________________________________
INTRODUCTION

This article covers how you should adapt the system requirements
engineering framework 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. Here is
a list of the variables with an explanation for each:

* 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.


_________________________________________________________________
OPERATIONALIZING 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.


=================================================================
LINKS TO OTHER GOOD STUFF

::: Resources related to this tip :::
http://www.ibm.com/vrm/newsletter_10802_3426_75365_email_DYN_2IN/mcauq136238161

::: Full text of this tip on the Web :::
http://www.ibm.com/vrm/newsletter_10802_3426_75365_email_DYN_1IN/mcauq136238161

::: Read Judith Myerson's article "Close enterprise system gaps with multiple SOAs" :::
http://www.ibm.com/vrm/newsletter_10802_3426_75365_email_DYN_3IN/mcauq136238161

::: Read Judith Myerson's article "Tight-coupling Web services in the SOA" :::
http://www.ibm.com/vrm/newsletter_10802_3426_75365_email_DYN_4IN/mcauq136238161

::: IBM developerWorks SOA and Web services zone :::
http://www.ibm.com/vrm/newsletter_10802_3426_75365_email_DYN_5IN/mcauq136238161

::: IBM developerWorks XML zone :::
http://www.ibm.com/vrm/newsletter_10802_3426_75365_email_DYN_6IN/mcauq136238161

::: Subscribe to the developerWorks weekly newsletter :::
http://www.ibm.com/vrm/newsletter_10802_3426_75365_email_DYN_7IN/mcauq136238161

::: IBM's privacy policy :::
http://www.ibm.com/vrm/newsletter_10802_3426_75365_email_DYN_8IN/mcauq136238161

::: IBM's copyright and trademark information :::
http://www.ibm.com/vrm/newsletter_10802_3426_75365_email_DYN_9IN/mcauq136238161


=================================================================

THIS NEWSLETTER IS FOR INFORMATION ONLY. This newsletter should not be
interpreted to be a commitment on the part of IBM, and, after the
publication date, IBM cannot guarantee the accuracy of any information
presented. You may copy and distribute this newsletter, as long as:

1. All text is copied without modification and all pages are included.
2. All copies contain IBM's copyright notice and any other notices
provided therein.
3. This document is not distributed for profit.

IBM developerWorks
http://www.ibm.com/vrm/newsletter_10802_3426_75365_email_DYN_10IN/mcauq136238161

----------------------------------------
About this newsletter

Manage your subscriptions:
http://www.ibm.com/vrm/newsletter_10802_3426_43352_email_DYN_1IN/mcauq136238161

Subscribe:
http://www.ibm.com/vrm/newsletter_10802_3426_43352_email_DYN_4IN/mcauq136238161

***:
http://www.ibm.com/vrm/newsletter_10802_3426_43352_email_DYN_3IN/mcauq136238161

Contact editor:
mailto:dwnews@us.ibm.com

To ensure proper delivery please add enewsletter@us.ibm.com to your address book.

You received this e-mail because you are subscribed to IBM's developerWorks Web services/XML newsletter as: TAYLLORCRISS@GMAIL.COM

© International Business Machines Corporation 2007. All rights reserved.

IBM Corporation
Attn: Developer Communications, M/D 241
150 Kettletown Road
Southbury, CT USA 06488

Contact IBM:
http://www.ibm.com/vrm/newsletter_10802_3426_43352_email_DYN_2IN/mcauq136238161