SPA 2006 – Use case workshop

This session, delivered by myself & Mark Fish, was based on training courses we have both delivered for a variety of clients. We have both seen use cases applied inappropriately or poorly. Also we have identified areas that cause difficulties in many situations. We hoped to highlight these areas and encourage a pragmatic approach to use-case development.

In my introduction I invited attendees to share there reasons for being there. Amongst the 16 or so people we had a majority who had either had some difficulties in applying the techniques effectively or felt that the use case approach had inherent weaknesses. The remainder were looking for a refresher on benefits and limitations of use cases.

In making an initial stab a managing peoples expectations if highlighted a few points

• Use cases are not a golden hammer
• Use cases provide a useful mechanism for elicitation of behavioural requirements.
• The use case diagram that many people present is a HOAX.
• In the vast majority of cases the only necessary relationship between use cases is <<includes>>

I was also asked to present a mapping from use cases to “service oriented architecture”. I ducked this question as I have found SOA to have a negative effect on OO design.

At this stage Mark took the floor to introduce use-cases and a process for their development.

As a means of communication, use-cases are dependent on the adoption of a common vocabulary. Other parties have referred to this as “ubiquitous language”. The approach that we advocate to developing this vocabulary is domain modelling. We use a noun search technique to help identify key concepts, relationships between these can be shown on a UML class diagram. The result is a glossary for the project.

Having developed and agreed the terms to be used in describing the problem we will begin to elicit the behavioural requirements. The term behaviour did cause us some difficulties in this forum. Use cases are a highly effective tool for describing the required interactions between the system under design and external stimuli (people or systems). We at this stage took the opportunity to take stock and discuss the make up of a requirements document. I see it as consisting of a number of chapters, these may include:

• Business rules (formulae and calculations. not workflow)

• GUI wire frames (or similar)

• Non functional constraints

• Quality of service (availability, performance etc.)

This discussion highlighted some significant concerns regarding the use of terms such as non-functional requirement, business rule and of course behaviour. It was generally accepted that while we held a common understanding of these terms they were perhaps not ideal. For instance business rules is a term I use to separate out calculations from use-cases. However, the term can be used to describe workflow.

Having got past a significant diversion to cover terminology Mark continued the elicitation process. We need to obtain a list of prime capabilities of the system under design.  Mark emphasised that the “system under design” (SUD) could be a system or a business.

Rather than dive in and try to discover capabilities we start by brain storming actors.  This list will include all parties who interact with the SUD. This list of actors leads us to the next question; why do these parties use the system. With this question we are trying to ascertain actor goals. Alternatively if a system is used by our system we describe it as having a responsibility.

Following this we begin to identify certain goals as primary capabilities of the system. These are the beginnings of our use cases. Finally, for Mark, the possible structure of use cases was covered.

Mark emphasised that this approach will only cover the behavioural requirements. On average this will be in the region of 30% of the requirements for a system.

I re-took the floor here to present a technique called robustness analysis. This I borrow from Doug Rosenberg’s ICONIX process. This technique can be used at two stages; first to improve the standard of a use case, second, to kick start the design of a system based on the use case.

The final point for discussion was the applicability of use cases in an agile process. My particular area of interest is SCRUM. I am happy to acknowledge the benefits of an on site customer. However, many of my clients cannot donate an appropriate individual to the development team for the required time. In this case we leverage use cases to capture a conversation with the customer. This must be use in combination with the usual agile principles of minimising up front investment and achieving feedback ASAP.

Over the next couple of days I spoke to a number of the use case sceptics who felt that our pragmatic approach had effectively eased there concerns. I thank all attendees for taking part in a session that I enjoyed and I feel all parties took some benefit away from.