All About Requirements

How to get Use Case success - get the level right!

Use cases are widely known for being an excellent tool for specifying requirements for IT systems. The strength of use cases is, in my opinion that they provide a structure for the requirements and a way to graphically outline how the user should interact with the system.

Use cases are originated from the UML framework. The fact that UML is a framework has the advantage that it can be used for many purposes and can be tailored to fit your project and your organisation. The disadvantage is that UML does not prvide any firm guidelines about how to structure and design your use cases or, even more painful, UML does not give you any guideline on how detailed you should write your use case.

In many of the projects I participate in or give advise to a discussion issue when initiating the use case analysis phase is often about how to write the use case content and especially how detailed it should be. It can be hard discussions because each of the business analysts participating have different views on what a good use case is. The truth is that all the views on what detail level makes a good use case can be right. The right detail level depends on the following factors:

• What type of system are you specifying requirements for?

The requirements for a standard system should be more high-level than the requirements for a custom-developed system

 

• How complex is the business domain

Very complex systems requires more detailed requirements than simple systems
What is the risk taken if the requirements specified are too high-level. If for example, a requirements specification with requirements being too high-level is that the system would be useless, the system could generate wrong numbers harming our business and make you loose customers, the competitive advantages you're trying to achieve could not be reached - these indicators would require specifications with many details.

As a rule of thumb, your use case should be as detailed as necessary to make you feel comfortable when asking yourself the question:

• Is the use case detailed enough to make it clear for the vendor what should be build?
  Ask yourself is the use case specification could be misunderstood. If so, you might be too high-level.

 

• If the use case if misunderstood is the damage acceptable and controllable?
  This is a key issue. If you think there might be a risk that your use cases are not totally clear or if they can be interpreted in different ways, ask yourself:

What happens if the use cases are misunderstood? If the consequence is that you get functionality build different than you require and it does not make any difference (if the system is low-focus, not bringing competitive advantages, and other ways of working probably would be just as fine) it could be acceptable to face the risk. However, if the consequence of not being specific enough could mean competitive advantages, could not be reached, the system would be useless, destroy your business case etc.
you might want to go as low in details as whenever possible.

I usually operate with three general levels when designing use cases:

 

1. High-level use cases
2. Medium-level use cases
3. Detailed use cases

First of all, determine what kind of use case you think fit to your project (and organisation) - the high-level, the medium-level, or the low-level use case. Then, determine what the use case level chosen should look like - here it helps, in advance, to operate with objective criteria on what determines each use case level.

Here are some suggestions:

The high-level use case should contain the following elements:

• Name
• Unique ID
• Pre-condition
• Post-condition
• Trigger
• Verbal description of the use case (use case purpose)

 

The medium-level use case should contain the following elements:

• Name
• Unique ID
• Pre-condition
• Post-condition
• Trigger
• Actors involved
• Verbal description of the use case (use case purpose)
• Description of the main flow
• Description of alternative flows

 

The detailed use case should contain the following elements:

• Name
• Unique ID
• Pre-condition
• Post-condition
• Trigger
• Actors involved
• Verbal description of the use case (use case purpose)
• Description of the main flow
• Graphical description of the main flow
• Description of all alternative flows
• Graphical description of all alternative flows
• Detailed description of all business rules involved
• Detailed description of all functional requirements involved
• Detailed description of any design requirements
• Links from use case steps to requirements (business rules, functional requirements, and design requirements)

 

 

Process Governance

In the world of business process management several frameworks exist for ensuring a standard notation and a structure of models to use.

However, very few methods (outlining how to use the framework, when to use which parts of the framework etc.) exist. This leaves many of the projects without a clear and committed governance structure for the processes being specified. Unlike many project management methods, for example in PrinceII where project governance is a central part, the governance is most often missing in regards of the business processes. That is a huge disadvantage because it leads to unmanaged process documentation and business processes that are no longer being paied attention to.

Business processes do change - even after they have been reengineered and optimised. So, how do we keep track on those updates, document them and make sure they and being addressed in terms og process optimisation. The easy answer is: Point out a business process owner for each process and make her responsible for monitoring business process changes and for business process optimisation.

This works fine for simple business process landscapes. But, often the person being responsible for a process is the department manager responsible for the process in the first place and that
will lead to sub-optimisation of the business process.

Following this guideline can ensure a minimum degree of governance:

Establish a governance structure for your business processes and write the decision into the project plan where the business processes are part of the deliverables.It is fine if the governance structure is very simple, but it should answer:

a) Who reviews business process designs (not department managers but e.g. a process board)
b) Who can sign-off on a business process design (not department manager but e.g. a process board) and how is sign-off documented
c) Where are the business process designs documentation stored and how is it versioned (Configuration management). Consider a business process repository
d) Who can suggest business process changes
e) Who is responsible for maintaining the business process design documentation

 

Why is all this important? well, in todays IT environment the business process design generates competitive advantages and therefore the business processes are an assett and should be treated as an assett.