Requirements

veryard projects - innovation for demanding change

requirements ecology

veryard projects > requirements > ecology

we offer

on this page

other material

links

consultancy

management briefings

independent advice on tools and methods

Three Approaches to Requirements Engineering

Sources of Requirement (Triggers)

Ecological model of component supply

Three Approaches to Requirements Engineering

veryard projects > requirements > ecology > three approaches

Most traditional approaches to requirements engineering are solution-driven -- aimed at developing solutions for specific problems or generic problem domains. Our experience with complex service-based systems indicates that an alternative approach is often needed.

SOLUTION DRIVEN

ECOSYSTEM-DRIVEN

Identify Business Problem

Identify "Users"

Negotiate Requirements

Define Solution

Identify Domain

Identify Domain Experts

Define Requirements

Design Solution Kit

Identify Ecosystem

Identify Services

Procure & Release Devices

Evolve Devices following Ecosystem Response

The popular engineering approach to determining the requirements for software is in three stages. This approach has been carried forward from structured methods to Object Oriented Analysis and Design (OOAD).

First you identify a group of users who need a software solution for an identified business problem.

Then you define the requirements on the software system. In OOAD this is usually specified as a set of use cases. These requirements may be based on a model of the business process, and are negotiated with the users.

Then you design the software system as a set of interacting components.

Of course, if you are trying to build generic components for multiple use, there may not be a specific business process to analyse, or even a specific software system to design. Furthermore, there may not be any specific users to negotiate requirements with. Undaunted by this, software engineers typically adopt the same approach but at a different level of abstraction. A domain is defined, which is a generic business process or generic area of automation.

First you identify a group of domain experts, who are supposed to stand proxy for a class of potential users.

Then you define the requirements on the domain, in collaboration with the domain experts.

Then you design a generic kit of interacting components, which will be usable for any system or business process that satisfies the generic domain description.

Then you assemble systems from these components that satisfy the specific needs of particular users within the target area.

This approach implies a division of labour: some engineers specialize in the creation of small lumps of functionality (called software components, possibly delivered as web services); while other engineers specialize in assembling these components to produce large lumps of functionality (known as software applications or systems).

But this approach assumes that it is meaningful to think about software requirements in terms of a fixed lump of functionality, known as the software system or application, delivered to a fixed community of users. It assumes that one person or team (possibly known as the system architect) has design control over this lump.

The limitations of this approach emerge when we are faced with large open distributed dynamic networks of software. It is both a business imperative and a technological imperative for business organizations to connect their business processes into these networks. These networks lack central design authority or architectural control, and evolve organically. Overall functionality and structure may change unpredictably from one day to the next. Connecting to these networks raises a number of difficult management dilemmas, including control, security and stability.

These networks are "Out of Control". Traditional engineering approaches are inadequate for operating effectively in this environment. Biological and ecological metaphors seem to have more relevance than engineering metaphors. [Reference: Kevin Kelly]

The ecological approach to creating software and services is radically different to the traditional engineering approach, and is based on biological and ecological metaphors.

First we identify an ecosystem, which may contain both human users and existing artefacts.

Then we identify services that would be meaningful and viable in this ecosystem.

Then we procure devices that enable the release and delivery of these services into the ecosystem.

A good component or service is one that satisfies the ecological principles of all four ecosystems. Such a component is viable and meaningful, and is likely to survive and develop.

Business requirements FOR components (pdf)
Business requirements AS components (pdf)

Requirement Triggers

veryard projects > requirements > ecology > triggers

What triggers the creation of a new component? Based on an ecological model of component supply, the initial stimulus may come from any of the four ecosystems.

Demand-driven. An agent may identify some service that he/she/it requires. This generates an unsatisfied service demand, which may be communicated to the service supply ecosystem in hopes of a response. Alternatively, the service demand may be translated into a device demand, and communicated from the device use ecosystem to the device supply ecosystem.

Supply-driven. A supplier may identify an opportunity to extend an existing service to increase its availability. Or to package a bundle of existing services and/or devices to provide a new service. An engineer may identify an opportunity to wrap or modify an existing device to provide new services. Prototype devices may be reengineered to increase availability of services.

Regardless of the initial stimulus, a successful component needs to find sufficient acceptability on the demand-side, and sufficient economies of scale on the supply-side. The requirements process needs to connect with both imperatives, but in no particular sequence.

component requirements can originate in any ecosystem

Component requirements can originate in any of the four ecosystems.

Ecological model of component supply

veryard projects > requirements > ecology