Entity / Event Analysis

Entity Life Histories are a very specific technique but where a supplier is involved, it is probably best to record the business rules in prose with each requirement specification. Each supplier will have its own technique for translating business rules and the sequence of allowed processing into logical system specifications.

If there are very specific rules as to how events should be sequenced and allowed to interact with entities, this can be documented as part of the CRUD matrix (below).

CRUD Matrix - Create, Read, Update, Delete

• Identify business events, e.g. Customer Order Received and Customer Order Received With Payment
• Look at each function defined in Function Definition. Track back to its triggering dataflow(s) - these will be Events. It could, for example, be receipt of an order, receipt of a payment against an invoice, decision to add a new product to offer for sale, despatch of an order or receipt of a delivery from a supplier. Follow the processing of that event through the various elementary processes (or parts of a process) that make up the function. Identify the entities affected and the way they are affected - they will be on dataflows, either carried with the event's triggering dataflow or picked up from or created / updated into datastores via dataflows. Every time a user has to make a decision before deciding how to process an item then that is a separate event.

For example, whether there is a payment with the order, or where, say an authoriser has to decide whether to authorise an order that would place a customer over their credit limit. In this latter case, the order would be put into the system, the system would prevent the actual processing of the order and instead would put in suspense, awaiting authorisation from a manager. Here, the processing of the first event, Customer Order Received, can automatically be directed down one of two routes - normal and into suspense (if this order would take them over their credit limit). Another two events would then be the manager picking off orders in suspense and either deciding to authorise them for fulfilling, or to reject the order with a letter to the customer explaining the situation (Suspended Order Authorised and Suspended Order Rejected).

• For each event you identified, create a new row on the CRUD matrix and put in the Event Name. Next decide which entities are Created, Read, Updated or Deleted.
• For each such event, also describe the detailed effects of the event and any business rules that can be applied automatically An example would be that the accounts of customers who have unpaid invoices over 30 days past their due date must be put into suspension.

A more straightforward example would be where a customer order turns out not to violate any business rules. You'd describe the effects something like this. The customer entity is read to match against the name on the order. A new Customer Order entity is created. For every item ordered, an Order Line entity is created with product and order quantity details. To get the product details, the Product entity would be read. The order total is used to check against the Customer Account to see if the credit limit would be exceeded. If so the Customer Account entity is updated to put it into suspense.

What about the business rule that a customer can only purchase things on credit if they have an account?

What's likely to happen is that the order entry screen will have somewhere that allows you to put in the customer name to see if they have an account. If not and the order wasn't accompanied by payment, the user wouldn't process the order but would instead write back to the customer. An alternative would be to put in the order details but put it into suspense until payment is received. Next, write to the customer explaining that the order is on hold until payment is received. Users will decide these sorts of details.

Something akin to the above prose description would go into the appropriate requirements catalogue entry and something more precise in the CRUD Matrix.