Instant Objects Ltd

Maxim - Requirements Analysis

The analysis information is captured in an excellent UML tool called Enterprise Architect from Sparx Systems.

1. Roles and Goals

There are two things that should be noted. Firstly, the goals are stated in the form verb...noun to help us produce a consistent platform for further analysis.

At this stage, we are targetting business goals and not business processes so we have to make like a 3-year-old and keep asking the question 'Why?'. So in the above example, we can push 'Chase oustanding purchase orders' down to the business processes as it is done in support of the goal 'Ensure at least minimum levels of stock'.

Just to add a little colour to the mix, we also introduce related software systems as 'roles' and ask why we need to communicate with them. An inventory management system may talk to a sales order system, and produce general ledger journals.

This first step is focussed on scope definition and what value a proposed new development can bring to the situation.

2. Business Object Model

At this stage, we produce a 'wiring-diagram' of the business domain. Unfortunately, in our jargon filled industry this goes by many names such as Domain Object Model, Business Class Diagram, Data Model. We use UML and Enterprise Architect to capture this and it provides the skeleton of the system. An example of a partial business object model in a purchasing domain is shown below.

In practice, this model becomes our glossary for the rest of the project.

3. Business Object Life Cycles

In this phase, we look through all our business classes, and decide whether the concept of a life cycle is relevant to them. It so, we again use UML to produce a statechart as show below.

In contrast to virtually all other drawing diagram, the activities are on the lines while the boxes are reserved for valid order states.

Note that this process has identified many of the key functions that we will need for supporting purchase ordering. Typically, this would get refined during the course of a project to include more of the exceptions.

4. Performance Indicators

We review the top level goals for conditions, observable criteria and consequences. This will typically lead us to identification and definitions of performance indicators such as profit, stock value, capital efficiency, and supplier dependability. These definitions are then used to enrich the basic skeleton. We feel that in this way, not only does a new development support the normal transaction handling but it can also help people assess their progress in reaching business goals.

5. Functional Decomposition

By the time, we have got to this stage, we normally have a collection of different business processes at different levels of detail. These are organised into a hierarchy and will be used for planning and progress tracking. We tend to present them around the role that will be interacting with the developed system.

Purchaser
- Enter new supplier
- Suspend supplier
- Allocate supplier to product group as preferred supplier
- Place purchase order
- Reconcile supplier invoice

Accountant
- Produce Stock Valuation report
- Produce Stock Write-off risk analysis
- Receive email alert of stock value exceeding threshhold.

6. Attribute Enrichment

Having identified the vast majority of analysis items, we then go through and enrich the models with added detail. Specifically, we will allocate attributes to given business events or performance indicators, add masks, display formats and business rules.

We feel that our attribute enrichment process gives us a very strong competitive advantage over other software developers as it is designed to automate much of the design phase of the project.

If you haven't had enough yet and wish to read about our design methodology, click here.