Conventional Requirement Management Tools and Methods do not Work in Today’s Environment (Part 1 – SOA)

Conventional Requirement Management Tools and Methods do not Work in Today’s Environment (Part 1 – SOA)

iStock_000012938112XSmallConventional approaches for requirements development and management are limited in their value as organizations attempt to address demands for increased innovation, rapid product and service rollout, outsourcing, cloud computing and new technology enablers such as BPMS, business rules engines and Service Oriented Architecture (SOA).

Additionally, agile development and IT-centric methods for analyzing and designing software solutions don’t accurately represent how business processes, rules, events, knowledge and human to system interaction fit together. This prevents creation of a cohesive business solution design that can be understood by both business analysts and their stakeholders. The inability to preserve business concepts throughout the business/IT change lifecycle leaves the business community dependent on IT to understand the details of how their business operates, resulting in a cycle of rework that is incompatible with agile.

For example, consider SOA. Many organizations are embracing SOA as a means to quickly respond to business demands while leveraging their existing investments in applications.  SOA is an architectural style for building software applications that use network services, such as the web. SOA, with its loosely coupled nature, allows enterprises to plug in new services or upgrade existing services in a granular fashion. Most major application vendors have an application or platform suite that enables SOA.

Compared to traditional information technology (IT) projects, Service Oriented Architecture projects face severe challenges when it comes to requirements gathering and requirements processes.  Let’s examine why. Applications in SOA are built based on services. A service is the implementation of a well-defined business functionality which may be used in many different applications and business processes. Any time a service is changed, it is critical to know what business processes and applications will be affected. In many cases, requirements will need to be defined in a manner that addresses changes in the service and the applications and business processes that will be impacted.

SOA provides many benefits to the organization.  However, for SOA to deliver value to the business, it requires a number of IT support processes as well as organizational processes that involve business leaders.  SOA needs a solid foundation based on standards and includes policies, contracts, and service level agreements. Successful SOA implementations have a well defined governance structure that assigns decision-making authorities, roles, and responsibilities and bring focus to the organizational capabilities needed to be successful.

Traditional requirement management tools and methods do not even begin to address the complexities of SOA and SOA governance principles. Imagine trying to use Word or Excel to document requirements for a SOA environment. Current automated requirement management tools available in the market are not much better. They are primarily focused on defining requirements for a single product with minimal integration to other systems.

The Enfocus Requirement Suite™ from Enfocus Solutions was designed to address these problems.  We are able to do this in several ways.  First, we have four knowledge bases used by enterprise subscribers that maintain permanent information about business processes, business rules, products and services, and stakeholders. These knowledge bases are used across projects.  Stakeholders and developers have access to this data via our Stakeholder Portal™ product.

SOA applications and services are defined in the product and service knowledge base. When a project is defined, project scope statements are created that reference which products and services are impacted as well as the business processes that are impacted. These project scope statements are used to elicit needs from stakeholders and to specify functional and supplemental requirements.

Requirements are later organized into bundles to address how functionality will be designed, built, and deployed. These bundles fully support agile and other iterative development methods.  Requirements within a bundle are traced through lifecycle events including design, build, test, and deployment.  Maintaining requirements in this fashion provides a permanent record of all requirements organized by business process, application, service, and stakeholder.  This information is critical for stakeholders to understand their business process and for developers to be able to maintain and support systems.

To learn more about the Enfocus Requirement Suite™ from Enfoucs Solutions, please download our product fact sheet below.

[cta id=”7421″]

Submit a Comment

Your email address will not be published. Required fields are marked *