Guide for managing Use Case (UML) driven projects

Posted by Jackie Hewett on Mon 31st July 2006 at 03:11 AM, Filed in Project ManagementSoftware DevelopmentUML

Most project managers are aware of UML, even if they haven’t used it themselves. 

However, having worked as a Business Analyst on a number of ‘UML projects’ I believe that many Project Managers don’t really know how to use UML requirements gathering techniques to maximise the chances of a successful project.

image

I am going to try to help you understand some of the pitfalls and issues that are all too often encountered when setting up a UML based IT project.

Firstly, let’s just be clear about what a Use Case is.  Use Cases model functional requirements with an emphasis is on the ‘What’ (should be achieved) not the ‘How’.  They describe interactions between users and systems; and a single Use Case describes a high level use of the system you are trying to build. 

Writing use case descriptions (the detail) is a pretty straightforward business.  They should be meaningful to users and avoid technical jargon.  The real skill required for Use Case modelling lies in identifying the Use Cases and taking them to the ‘right level’ of abstraction in order to build a Use Case Model of the system required. 

All too often, I have joined projects part way through, and analysts have identified a huge and un-necessary number of Use Cases which complicates the model, and can give miss-guided opinions regarding the size of the project.  The problem with taking use cases to too low a level of abstraction is generally two-fold:

  • An inordinate amount of time gets spent discussing within which Use Case a particular piece of functionality should fall.  This would lead me to question whether the Use Cases should exist individually or be merged together.
  • It can impinge on the design (or how).  For example, the first step in one Use Case I reviewed was for the system to identify whether the Use Case itself needed to be called at all!  The developers (rightly) ignored this and wrote code to identify whether or not the functionality was required in the calling Use Case.  In my opinion, this occurred because the analysts were trying to keep things too modular and had developed “Use Case fever!”

Without being an expert in Use Case modelling there are some quick checks you can do to identify whether or not Use Cases are at the appropriate level:

  • Are there many Use Cases called by other Use Cases, not called directly by actors, in long ‘strings’?  Use cases are be split out (via use of includes and extends relationships) for re-use.  There is no re-use when a use case is called by only one other use case!  I would ask the analysts to justify why they have split such use cases out.  
  • Also, you do not need separate Use Cases for create, edit and delete of the same object.  One ‘maintain’ use case will describe the functionality adequately for users and developers alike.
  • It is important to try to be consistent with the level of Use Cases to aid planning.  It is not going to help you plan your project if some Use Cases represent a days worth of coding and others a week. 
  • You are likely to encounter ‘system Use Cases’. These represent functionality ‘invisible’ to the actor and are system driven so there can be none of the usual actor/system/actor flow described.  This sort of functionality does need to be identified, estimated and documented for the project, but I would suggest that it may be more appropriate to describe such functionality in a different way.  Even a good old fashioned program specification.  Furthermore, I would not present such Use Cases to business users to sign off as they are unlikely to understand them.
  • Users should be able to make sense of your Use Case Descriptions (part of their ‘raison d’etre’ is for requirement sign-off) so even as a project manager you should read a couple of the descriptions yourself.  Are they readable? Secondly, make sure the developers can work with them.  I would strongly recommend using a template (Click Here For Use Case Template Download (WORD Format)) and get that template OK’d by the developers. 
  • Show the developers the Use Case Model as soon as you have a first draft (models do change) - especially if Use Case Modelling is new to your team.  Also, show developers the first couple of Use Case descriptions (even draft) as soon as they are written rather than waiting for a hand-over date.  This will enable your analysts to get early feedback before they go too far with the project on things like - do the use case descriptions contain / reference the level of detail necessary for coding?  Does the model impinge on design?

Use Case modelling does have its limitations.  As stated before, they do not detail non-functional requirements, but they also have limitations for functional requirements. 

You will need supplementary documents / artefacts for the following:

  • Business rules - often best ‘pulled out’ and listed in separate documents referenced by the use case description as they can be quite lengthy, which spoils the flow of a use case, and they are often used by more than one use case.
  • Data entry validation - specify in the Use Case flow where it is done, but not the detail.  Reference a separate document or section of the use case description.
  • Screen design / layout - you will need some sort of visual aid that users can relate to.  Use prototypes, storyboards, wire-frames – whatever!
  • Reports – cannot be specified in use case descriptions

This may start to sound onerous and off-putting if you haven’t used UML before, but it does have its advantages.  Use Case modelling is very good for defining the scope of a project and getting business sign-off without the need for special software, case tools or technical language.  Users relate well to them!  If done properly it will also assist with estimating and planning; and can be used as the basis for testing. 

Finally, let’s briefly explore the issue of UML tools and software.  Your analysts will need something in which to draw Use Case models.  I have used Rational Rose and Select for modelling and both are fine.  However, I have found such tools too restrictive for the Use Case descriptions (usually you cannot add new template sections) so I have always resorted to Word documents.  If you are new to UML and maybe don’t have a huge budget you could start with something like Visio or even PowerPoint for your use case models and use Word for the descriptions.
 
Theoretically the specific UML tools can reduce development time by auto-generating class diagrams and code, but in practice I have yet to see this happen.  Whether this is due to limitations of the tools, experience of the team or other factors is another discussion, but the tools will give you configuration management and the team something else to shout about on their cv’s!!!

 

 

This entry has been viewed 11311 times.

READER COMMENTS:

Hi,
Excellent article.Definitely strikes a chord.

cheers

Posted by Benjy  on Thu 14th February 2008 at 04:27 PM | #

The guide is very informative. Many guide pointers have helped me create Use Case Diagram more effectively.

Posted by Sajal Gupta  on Fri 4th December 2009 at 06:46 AM | #

POST A COMMENT:

Please feel free to submit relevant comments to this entry but note: inappropriate or purely promotional comments may be removed as will be personal abuse and defamatory remarks. Reasoned debate and substantiated critique on the topic in hand is encouraged and welcomed. Email addresses are never displayed, but they are required to confirm your comments.

Name:

Email address is required but will not appear publicly:

Add your comments below:

Remember my personal information for next time

Submit the word you see below:

12 + 1 =