Requirements Modelling and Specification for Service Oriented Architecture

3.5. Establishing and Prioritizing the Business Objectives

We intend to use UML as our primary modelling notation for requirements analysis and specification. However, there are some things that just cannot be modelled with UML, so we need other representations. This is most true at the outset of a requirements engineering exercise.

Let us suppose that we are looking to improve a particular business area. It is enormously beneficial to be able to state what the business area does. This can be captured in a mission statement - sometimes called a project charter. If we think of the business area as providing a service then the mission statement should capture, as succinctly as possible, what this service is.

A manufacturing process might state, for example, that it should 'make a high quality product at a reasonable price, while maintaining an adequate profit margin'. If we are developing a word processing service, our mission could be to create the easiest to use and most comprehensive word processor available. Clearly, UML has no diagram type that can represent these ambitions; natural language seems to fit the bill perfectly though.

Mission statements, such as the above, can be quite vague. To pin down the requirements we must ask for much more precise objectives within each service or process area. These objectives may refer to several services that the business area provides to its customers or internally.

For any given process-oriented business area, once we have defined its ...