Can we say anything meaningful about how to structure application requirements? Years ago, Chuck Wade taught me that constraints are an engineer’s best friend. So let’s constrain our scope to “case based applications” – not transactional applications, not project management applications, not web content management.

Step 1: The Case Life-cycle

To be simple-minded about it, our application looks like this:

This doesn’t tell us much. So we explode the big circle in the center to include three types of activities:

• Manage – do work on the case information, make decisions, take actions

• Review – evaluate the work done in manage

• Communicate–interact with people in the case or outside it

Of course, the order in which these activities occur can change from case to case. Now the case life-cycle assumes a more interesting and useful form:

Step 2: The Case Foundations

We haven’t said anything about the information content of the case. We can view a case in a very simple way:

The case has a source of information and there have to be rules about what the case can do with it. The case information is typically a combination of unstructured and structured data. For clarity, we will split the control block into two pieces:

• Case Policies, which govern what the case should do under different circumstances

• Monitoring, which gives us the ability to view and analyze cases that are in progress or completed

So the picture now gets a little more interesting:

There is still one more missing piece: integration with the external environment.

Putting Step 1 and Step 2 together gives us the final picture of our application:

We have now structured our case-based application into 9 different pieces, which we’ll call the “solution requirements categories.”
In Part 2, we’ll see what all this has to do with patterns. Stay tuned!