Requirements Modelling and Specification for Service Oriented Architecture

5.7. Checking Model Consistency

Having analysed the business process in terms of conversations and collaborations, there is one more critical task for the requirements engineer. Recall from Chapter 3 how we went to a good deal of trouble to establish a set of measurable, prioritized business objectives for each process. Now there is a model of a network of conversations. What is the relationship between the two models? We must now answer two critically important questions:

• Does every conversation support the achievement of at least one objective?

• Is every objective supported by at least one message?

If the answer to either question is, then the models must be amended. Either we have missed some conversations or we are modelling conversations that do not contribute to the achievement of any stated business objective. Of course, it is possible that we have missed an important objective and, in that case, the users should be consulted to see if the statement of objectives needs to be modified. If not, we have a clear re-engineering opportunity: just stop doing the work that supports no objective.

The simplest way to record the results of the analysis is to construct a simple spreadsheet with the rows representing conversations and the columns objectives. A 'Y' entered in the grid then signifies that 'this conversation has a goal that will contribute to the achievement of this objective'. It takes just a few minutes to create a macro that will highlight any conversations that contribute ...