Requirements Modelling and Specification for Service Oriented Architecture

7.10. Summary

Understanding and modelling requirements requires a richer language than that needed to specify a computer system.

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 and conversations.

• Descriptions of the boundary conversations that are the starting point for specification.

There are problems with the conventional approach to use cases including the following.

• Overemphasis on functional decomposition.

• Lack of a clear definition and agreed interpretation.

• The inappropriate use of controller objects.

• Confusion over the relationship of use cases with scenarios.

• Lack of a notion of genericity.

• Lack of a notion of atomicity.

• Too much detail and too many use cases as a result of poor abstraction.

• Poor exception handling.

We can use the standard UML class diagram concepts to model conversations and use cases; the <<extends>> dependency violates object-oriented principles and should never be used.

Boundary conversations describe the features that the user of the system will be able to use. In other words, they describe the services that the system offers its direct users. Describe such services by their ...