Requirements Modelling and Specification for Service Oriented Architecture

7.1. From Requirements to Specification

As argued already, understanding and modelling requirements requires a richer language than that needed to specify a computer system that will satisfy all or some part of the requirement. In requirements engineering we model a world of which this system may be only a small part. So the style of requirements engineering that says that requirements statement are all of the form: 'The system shall...' misses the point; such statements do not and cannot describe the entire business problem that we are trying to solve or the process that we are trying to support. For example, a system with services that show current cash balances and display stock levels does not, in and of itself, get the goods into the hands of the purchaser, which is the key goal of the process.

Having understood this, once a clear understanding of the business requirements is achieved, it is quite proper to focus on the detailed specification of a system; that is the definition of a set of services that the system will offer. How do we do this?

The requirements model should contain all of the following items.

• Prioritized measurable business objectives.

• Before and after versions of business process descriptions. These may include network models (e.g. models written in BPMN), mission grids or rich pictures based on conversations - or both. They may also include collaborations that show how conversations interact.

• Cross reference tables linking the objectives to the processes ...