This article inadvertently ended up focusing on Use Cases rather than UML as a whole, but is still important. There is alot more to come, though…

Every now and then the subject of UML with agile projects comes up.  My view on this is the same as it has always been: UML has a big part to play, because (a) UML is a communication language and is well suited to help you get you message across in a meaningful way, and (b) the finely-grained nature of user stories, backlog items and acceptance tests often doesn’t give people the context or overview they need to understand the bigger picture.  As systems grow ever more complex and connected, this bigger picture is important. 

Some people insist in misinterpreting a statement like this as if it is almost some act of heresy:  An attempt at imposing a draconian iron-fist of bureaucracy over things; a pollution of the agile principles; a return to waterfall.  Crazy.

Where the difficulty – and the argument sometimes – comes in is that whilst there is a bigger picture that some people might need to be aware of, not everyone necessarily needs to know it. Most members of a team don’t work on everything, and whilst the agile principles include the spreading of knowledge, rotation of team members etc., people will still need to get up to speed in the first place.  If your project has allot of legacy baggage, systems integration, complex data, data quality issues and so on, this isn’t going to be easy to understand or to explain.  Also, spare a thought for those new to the team or department or perhaps new to the company entirely.    Obviously if people want to understand the bigger picture and take an interest in why they are building what they building in that particular way, that’s great, but you can’t necessarily force people do that, though. Just as you can’t force people to go to the department away day, or to attend corporate presentation events.  It’s better if they do, but it’s just not up everyone’s alley.

I don’t think there is a major issue with the techniques: nor is there, really, a major intellectual debate to be had about how UML slots in.  You can slot UML relatively easily into any project: It’s simply a communication tool. Moreover most of the key techniques in it have been around for decades, and certainly were around before the UML itself.

Let us consider something which is becoming more of a hot topic – accessibility. Traditionally, many people have viewed this as something of a side-issue; a bolt-on task performed by a ’specialist’ in combat-trousers and a strange t-shirt.  I would argue, though, that accessibility is actually just a facet of good design and that considering accessibility actually forces you into thinking about your system in a clearer way. 

Consider a simple web page where you have to choose a product, choose a quantity and add it to a basket.  I did this just now.  The site I was ordering from sells relatively few products – in the region of about 20.  The ordering page was relatively straightforward and on the face or it, the initial thought going through one’s head is this story would read something like ‘As a public user I want to select one of the products and provide a quantity so that I can add it to the basket and continue’ (or whatever else). The story is very straightforward.  It’s a drop-down list, a text box and a submit button. Nothing unusual there. Or is there?

Apart from the fact that it assumes we only add one product at a time to the basket; we have assumed that our page will allow one of only 20 or so products.  It all makes a kind of sense. But what happens if we are later told the product range will now contain things not previously available. We will be looking at in the region of 2000 products.  Where does that leave us?  It’s not outrageous to expect the company to start selling more products.

Well, our page won’t blow up with 2000 products, but wouldn’t meet the accessibility guidelines. We need a way of reducing the list of products into smaller more manageable lists or sets somehow.  There are a range of ways of doing this: perhaps an intermediate search screen, or some kind of browse facility.  This in turn might show up data quality issues, the need to consider search performance and perhaps ways of categorising and grouping the products using data items that don’t currently exist, and so on.  Allot of this stuff is almost a science in itself.

This is a simplistic example, but the point is that our simple ’select a product and add it to the basket’ story conceals allot of detail that isn’t necessarily obvious and that the users themselves might not even have considered.  In my view, this is where Use Cases add significant value: If written well they enable us to join up several smaller stories, provide us some context, and help accessibility designers and others to plug in to the project relatively easily. 

The following diagram attempts to represent this:

Note the following:

  • In Sprint 1 we have 4 features that have been scheduled, and these are mostly covered off by 2 Use Cases. These in turn have some supplmentary information but the information is quite different:  A List of agreed User Roles has been produced against Use Case UC-1, and a Wiki entry for Use Case UC-8.  
  • Use Cases UC-1 and UC-8 have been written in such a way that they reference the interface design wireframes:  In the case of UC-1, this details a screen or page containing 3 groups of screen elements which have been labeled A, B and C. These elements might pose their own problems, of course:  As we noted above, if elements A and B represent the enhanced Product Search we have be asked to build, there is likely to be alot behind this:  We obviously don’t go any further down than this though:  Certainly not to the field level – we can detail that elsewhere.
  • Requirements Group 2 has another set of Use Cases and these have been supplemented in a different way again.  In thise case Sequence Diagrams are appropriate: Perhaps there is a call to another system.
  • We have some features that don’t require Use Cases:  The functionality is understood well enough in itself.  Fine.

It seems logical to start with user stories as a “needs” capture, and then evolve the stories into use cases. The story is the placeholder for a later discussion, and the results of this will define actual goals for the system. To produce an agile Use Case, you simply need to provide a skeleton that can built on later – but not too late that you end up with more analysis than you have time to do.  Other interested parties, the accessibility designers, the corporate identity/brand people etc. have something of substance to work against. 

Alistair Cockburn quite rightly points out the danger of overlooking completeness There is obviously a need to unearth new and otherwise overlooked functionality that isn’t glamorous enough for the users to come forward with. This is life.  We’re not here to expect the users or customers to spoon feed us everything we need to know – we have to go looking. We have to influence their thinking.  So the completeness question is key: and NO, that doesn’t mean ‘Big upfront design’, ‘analysis paralysis’ or anything of the sort.  There is of course alot of opportunity to produce very bad Use Cases, especially since the Use Case descriptions aren’t actually defined in the UML. I’ve certainly seen many horrendous examples, and met people with an almost religious adversion to them as a result.  This is unfortunate – but in a way you can’t blame them.  The answer, though, is simple:  Produce good ones – human nature is such that that much lies in the presentation, with people quick to pass judgement. But the technique itself is not flawed at all: Try working at things before you write them off.

Obviously Use Cases are predominately based on User Interaction (though they can cover interactions between systems too).  For system-system interactions and the order in which data is exchanged or processed, Sequence Diagrams and State Machines are ideal. 

Clearly, not every set of needs or requirements in the system will afford the same amount of analysis and attention.  If you are working on an externally-facing web site aimed at marketing brands of breakfast cereal you will be in a very different position to those people implementing a content management system, constructing an interface to SAP, or engaged in a complex data migration as well as building more convential user interfaces.   

Of course, you may think that you can get the necessary detail illustrated above just by reading a set of User Stories.  All I can say is: Good luck.

« »