Upgrade to the system requirements engineering framework in SOA


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Upgrade to the system requirements engineering framework in SOA

  1. 1. Upgrade to the system requirements engineering framework in SOA Skill Level: Intermediate Judith M. 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. My article "Guarantee your Web service with a SLA" (developerWorks, Apr 2002) covers the exceptions that should be included in a service level agreement (SLA). In "Mitigate risk for vulnerability with a SLA guarantee" (developerWorks, Jan 2005), I address the issues of determining interruption thresholds for Web services. This article explores how you should adapt the REF to individual Web services that comprise an SOA application as a way of closing system gaps with multiple SOAs. Find out how business and system requirements engineering can improve performance and system security of an SOA application comprised of service-level agreement (SLA) Web services loosely coupled to the greater extent and tightly Upgrade to the system requirements engineering framework in SOA © Copyright IBM Corporation 1994, 2007. All rights reserved. Page 1 of 8
  2. 2. developerWorks® ibm.com/developerWorks 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. Upgrade to the system requirements engineering framework in SOA Page 2 of 8 © Copyright IBM Corporation 1994, 2007. All rights reserved.
  3. 3. ibm.com/developerWorks developerWorks® 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. Upgrade to the system requirements engineering framework in SOA © Copyright IBM Corporation 1994, 2007. All rights reserved. Page 3 of 8
  4. 4. developerWorks® ibm.com/developerWorks 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 Upgrade to the system requirements engineering framework in SOA Page 4 of 8 © Copyright IBM Corporation 1994, 2007. All rights reserved.
  5. 5. ibm.com/developerWorks developerWorks® 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. Upgrade to the system requirements engineering framework in SOA © Copyright IBM Corporation 1994, 2007. All rights reserved. Page 5 of 8
  6. 6. developerWorks® ibm.com/developerWorks Upgrade to the system requirements engineering framework in SOA Page 6 of 8 © Copyright IBM Corporation 1994, 2007. All rights reserved.
  7. 7. ibm.com/developerWorks developerWorks® 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 Upgrade to the system requirements engineering framework in SOA © Copyright IBM Corporation 1994, 2007. All rights reserved. Page 7 of 8
  8. 8. developerWorks® ibm.com/developerWorks • Participate in the discussion forum for this content. • Get involved in the developerWorks community by participating in developerWorks blogs. About the author Judith M. Myerson Judith M. Myerson is a systems architect and engineer. Her areas of interest include open source tools, middleware technologies, enterprise-wide systems, database technologies, application development, network management, security, performance management, RFID technologies, and project management. Trademarks IBM, the IBM logo, ClearQuest, Rational, Redbooks, RequisitePro, and WebSphere are registered trademarks of IBM in the United States, other countries or both. Adobe, the Adobe logo, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Upgrade to the system requirements engineering framework in SOA Page 8 of 8 © Copyright IBM Corporation 1994, 2007. All rights reserved.