All About Requirements

Use Case Completeness Tool - a Checklist

Whenever creating use cases it is a good idea to agree on what quality the use cases should have. Furthermore when creating use cases in a team with regularly review sessions it is desirable to establish an objective list of factors to check for when reviewing.

To do this you should establish a Use Case Completeness Checklist with factors that should all be true in order t label the use case "Complete". This way only "Complete" use cases are passed to review sessions and all team members know what, in this project, makes a "Complete" Use Case.

Feel free to use the embedded Use Case Completeness Tool and alter it to fit your project.

Download Use Case Completeness Tool

Feature driven development failures

When developing software a popular agile approach is the feature driven development methodology. In short: create a prioritised feature list and plan development from that baselne. The approach is fine for many situations, especially for handling development cycles for a bunch of change requests or errors. However, the approach and especially the use of featurelists does have some disadvantages. First, I find it is a shame that the value of the product being developed is equal to the value of the users required features. Often users are keen on features that makes their life easier, makes the product nicer, or just pops up when asked. The outcome is that the feature lists often contain a lot of nice-to-have features such as 'the list must be divided into two horisontal panels', 'the colours must be customisable', etc. Second, nothing ensures that the features listed are supporting the desired business benefits. To address these risks for failure the desired business benefits should be outlined and the desired business process should be outlined. Finally, the featurelist must contain features ensuring the desired business benefits and these should be prioritised.

Use Cases for beginners

 I was just about to call this article for "Use Cases for Dummies" but then it struck me that the title could be a little bit offending. The truth is that people unfamiliar with use cases should not feel intimidated by use cases or their lacking expertise in use cases in general.

 

Use cases are just a tool for structuring your requirements using a widely accepted notation. Nothing more - that is what it is all about.

 

Of course it is true, like in all other aspects of life, that some are more fluent in use cases that others. Experience is the key of course. However, even if you are completely new to use cases you can easily dive into it and get started very fast. 

 

First you need to learn a few tricks:

 

• Users are called actors in UML because according to the UML notation, actors can be persons or hardware (e.g. Computer systems, items, machines etc.). Don't let this confuse you, just call your persons Users

 

• Users are illustrated as a stickman

 

• Use cases are producing something and 90% of all use cases consist of a verb+a noun. Think: "create invoice", "search data", "print report", "create order", "modify order", "delete order", "send invoice", "search stock", "buy item", "submit payment", etc.

 

• Use cases referring to your key objects are often divided into several use cases targeting the object. For example the Object "Order" which could be targeted by the use cases: "create order", "modify order", "delete order".

 

It that all? Isn't there more to use cases? Oh yes, you can take your use cases from this point and add details and complexity with extended use cases, generalisations, use case flows and alternative flows. However, you can easily dig in and create the basics after this short introduction.

 

To create your first use case model, follow the outlined activities below:

 

• write down your requirements in plain language. Imagine you are telling a friend a 30 seconds description of what your requirements are

 

• Identity the use cases by highlighting the verbs+nouns that generate something that you require

 

• Identify the Users to the use cases. The users are those persons starting the use cases (technically this is just the quick-not-all-correct way of saying it)

 

• Draw your use case diagram. Users are stickmen. Use cases are circles. Users who can start a use case must have a straight line from the user (stickman) to the use case (circle). Voila, you have just created a use case diagram.

 

To get started and quickly produce a useful use case model follow these advices:

 

• Go ahead. An 80% correct use case model is much better than just a verbal text with your requirements

 

• Forget about tools to assist you in drawing your use case model. People new to UML often spend too much (unproductive) time learning how to use a drawing tool. Instead just draw your use case model on paper, it will save you a lot of time and be just as useful.

 

 

Here is an example of what you could produce as your first use case model:

 

• Short description of your requirements in plain language:

 

"I would like a system from which a user could search our data base"

 

By analysing the plain-text-requirements you can identify a User. The User is someone performing a task (search) which produces a result (search result).

You can illustrate the User as a stickman:

 

 
 

You can identify the use case Search Data which is a verb + a noun. Now your use case model looks like this:

 

 

 

By using just the stickman, circles and straight lines you are now able to:

 

• Define the scope of your requirements

 

• Define your high-level requirements in a structured manner

 

• Specify which users should have access to which high-level requirements