Requirements Modelling and Specification for Service Oriented Architecture

7.7. Ontology, Type Models and Business Rules

The process of specification is best approached iteratively. Figure 7-12 suggests an approach. We can either start with a process description using BPMN or conversation analysis, or we may begin - especially when migrating from important legacy systems - with the types evident in the data model. Let us look at the process-led case, because there is no difference in procedure, wherever one starts. The procedure is this.

Figure 7.12. The specification process.

• Identify the processes or conversations at the system boundary.

• Write pre- and post-conditions and business rules for each of these.

• Extract types using textual analysis and other techniques.

• Refine the model and find new processes and actions using, perhaps, state models.

• Write pre- and post-conditions and rules for any new processes.

• Iterate until the model is stable (or time runs out!).

Of course, we could start the iteration by eliciting the rules but implicitly the rules are always about either a process or a type, so the diagram is right conceptually.

Rules only make sense in the presence of the type model, which provides their vocabulary or ontology.

7.7.1. Rules and Rule Chaining

Graham (2006), based largely on an analysis of other people's earlier work, defines a business rule as a compact, atomic, well-formed, declarative statement about an aspect of a business that can ...