All About Requirements

Use Case Point Estimation – Estimate Your Project By Looking At Your Use Cases

Estimating what effort is needed to develop an IT solution is not an easy act. The pitfalls are multiple and chances are that you end up guessing.

 

In this post I will outline how to estimate projects based on the use cases. In addition I will show you how you can use Use Case estimation to negotiate with suppliers.

 

Estimation can be hard. Luckily a number of techniques exist that can give you a qualified (gu)estimate.

 

Among others, the following popular estimation techniques for estimation IT development exist:

 

1. Expert Judgment
2. Lines of Code (LOC)
3. Function Point Estimate
4. Use Case Point Estimate

 

 

Expert Judgment is when you rely on an estimate based on talking to experts. Especially valid when talking to experts experienced in the domain and with experience from developing similar solutions. Investigations shows that expert judgments can be fairly valid and almost as valid as more proven methodologies. Challenges are for example how to find the right experts and to evaluate their expert level. Furthermore, it can be hard to convince others (for example your supplier) that your estimate is valid, because it is a subjective evaluation.

 

 

Lines of Code (LOC) are a technique that is fairly reliable in the hands of an experienced team. The technique says, as a rule of thumb, that it takes X number of hours to develop Y lines of code. For example 100 hours per 1000 lines of code. An disadvantage of this technique is that you need to know how many lines of code you are going to produce – this can be estimated for example for a 1:1 conversion of an existing system, but can be hard to determine in other situations. Another disadvantage is that you need an experienced team to do the estimation, and you need to compare with similar systems – the amount of lines of code in a from-scratch-developed-system might differ from a similar system developed using a industry-standard-solution or framework.

 

 

Function Point Estimate, is an estimation technique developed by IBM. It counts the elements of the functional requirements and based on that calculates an estimate.  The technique is very usable and accurate. The advantage of this technique is that it is fact based and can be used by teams not experienced in the domain of the solution. Another advantage is that the cost of the project can be based on previous/other projects, and that other estimates using Function Point Estimation within your organization can be used as baselines. A description on how to use Function Point Estimation can be found here: http://en.wikipedia.org/wiki/Function_point

 

Use Case Point Estimation is a technique developed by the Swede Gustav Karner in 1993. The Use Case Point estimation technique is based on the same principles of Function Point estimation and has the same advantages. It has turned out that Use Case Point (UCP) estimation is as reliable as Function Point estimation. 

 

An explanation of the content of Use Case Point Estimation can be found here: http://en.wikipedia.org/wiki/Use_Case_Points

 

“What makes this technique particular interesting is that by using UCP estimation you are able to produce a reliable estimate very early in the development cycle.”

 

 “Actually even after sketching the use case model you are able to produce an estimate, apply it to the business case and consider stopping the project at this early stage, if the business case is not positive. That is a strong asset”

 

 

The figure below outlines where in the development cycle the various estimation techniques apply.

 

 

 

 

Lets have a look on a practical example on how to use the UCP estimation technique:

 

Lets say you’ve created the following simple use case model:

 

 

 

In this use case model there are seven use cases and two actors. The UCP technique involves ten calculation steps. Once learned they are easy to follow and your UCP estimate can be calculated within minutes.

 

The very first step is to calculate the Unadjusted Use Case Weight (UUCW). For calculating the UUCW you look at the number of use cases in your use case model, categorise them and calculate a UUCW score. The UUCW score will be used in other calculations as we move forward. So, we already know we have seven use cases. Those seven use cases needs to be categorised into Simple Use Cases, Average Use Cases, and Complex Use Cases.

 

In the table below you can see how each Use Case Category is described. Simple Use Cases are those having 1-3 transactions, and so on.

 

 

 

 

You just need to determine for each use case how many transactions they have in order to categorise them. To do so, you could have a look at the activity diagram and count the number of times the flow control switches from actor side to system side and vice versa.

 

For example in use case #1 the activity diagram could look like the one shown below (Notice: The activity diagram could as well be represented by a table showing the steps):

 

 

 

 

 

When looking at the activity diagram you can see that the control flow starts in the User side where the user is on a screen typing in some details. At some point in time the User chooses to save the input and clicks “Save”. By doing that, the control flow switches to the System side where the system validates the input.

 

When counting the transactions you should count the number of times the control flow switches lane (crosses the lane line) – except for error handling – those should not be counted.

 

 

So, in the activity diagram above I count three lane crossing – when I subtract the one involved in error handling, I calculate a total of two transactions for that use case.

 

 

Imagine doing this for all seven use cases in the use case model, we might end up with following categorising and a total UUCW score of 45:

 

 

 

 

“As you might have noticed you are now taken advantage of having documented your use cases properly by using activity diagrams with clear division of actor lanes!”

 

 

So far, so good.

 

 

The next step is to calculate the unadjusted Actor Weight (UAW) score. The UAW score tells something about the complexity of the solution. The Actor categories shown in the figure below doesn’t need much explanation.

 

 

 

 

When looking at the use case model shown in top (above) of this post, let’s assume that the two actors are human beings. The UAW score is then ‘6’ as stated in the figure above.

 

 

The next step in calculating the UCP score is to calculate the Technical Complexity Factor (TCF). The Technical Complexity Factor is often the most confusing part. In short, the TCF score adds an overhead of complexity to your score – the more complex the technical part of your solution is the higher score. Lets have a look at the TCF below:

 

 

 

 

By filling in the 13 factors above you’ll reach a score of 0,8 (TCF). Notice that the Complexity Factor (not to be confused with TCF) is 0.6. The formula to get to the TCF is just to multiply the Complexity Factor by 0.01 – don’t ask! it just happens to be the formula.

 

 

The final calculation to do is calculating the Environmental Complexity Factor. This factor is even more confusing than the TCF score. As you can see from the figure below the impact of various factors are rated. This gives you a sum (ETF) that goes into the ECF formula:

 

 

 

 

So far the following calculations has been performed:

 

Unadjusted Use Case Weight : UUCW

Unadjusted Actor Weight: UAC

Complexity Factor: CF

Technical Complexity Factor: TCF

Environmental Technical Factor: ETF

Environmental Complexity Factor: ECF

 

 

By having those six formula results you are now able to calculate the Use Case Point result. The Use Case Point for your solution is based on the following formula:

 

 

UCP = (UUCW + UAW) x TCF x ECF

 

Here is what the calculation from the example in this post looks like:

 

UUCW = 45

UAW = 6

TCF = 0,8

ECF = 1,085

 

UCP = (45 x 6) x 0,8 x 1,085

 

UCP = 44,268

 

 

Now, what use do you get from that?

 

Knowing that this project or this solution equals 44,268 worth of Use Case Points tells you a lot about the size of your project/solution. For example if you previously developed a solution worth 88 Use Case Point you now know that (with all other things being equal) this project is about half as big. This is valuable information in estimating the effort.

 

If you know that the previous solution you developed (the one worth 88 UCP)  demanded you 1000 hours of development, then it is likely that this new solution will take you about 500 hours to develop. That is, what the final calculation is all about: The Productivity Factor (PF).

 

The Productivity Factor (PF) is the hours of development per use Case Point. If the PF equals 10 then; (from the example above) the project estimate is (10 x 44,268) 442,68 hours.

 

Using the UCP method for creating estimates and discussing those estimates with suppliers can involve a lot of arguing about what the right PF factor should be. The supplier of course, will argue that the PF factor should be fairly high – e.g. 20 or 25. You, on the other hand, might argue that the productivity factor should be way lower – e.g. 9 or 8. So, what is right then? Reading materials explaining UCP estimation often suggests that a productivity factor of 20 is correct. The thing is though, that it depends.

 

 

Building your own baseline of PF Factor documentation

 

 

What you should do is to start collecting knowledge about your projects and the realised PF calculated. Let’s say you have completed a project and that the UCP point calculated for that project was 120. Now, if you spend 1800 hours developing the solution then your realised PF is: 1800/120 = 15

 

Imagine doing this for all your projects the result could look like illustrated below.

 

 

 

 

Now, by tracking your realised PF you can calculate a baseline by calculating an average PF of 12,6.

 

What the average PF of 12,6 tells you is that in average, when developing solutions in your organisation, using your IT environment, dealing with your business complexity, you spend in average 12,6 hours per use case point.

 

You could take the UCP baseline calculation a step further. For example if Project1 and Project2 are infrastructure projects and Project4 and Project7 are ERP projects you can create various Realised PF baselines depending on the project type ….. or depending on the suppliers, or in-house / external development, or, or….. The possibilities go on. It only requires a solid base of project tracking.

 

 

Using this information to control your suppliers

 

By having an average PF calculation you are able to create a documented fact based estimate. With a fact based estimate you have a better position when negotiating with suppliers.

 

-       Why can’t you deliver on a PF of 12,6, when all our other current suppliers in average delivers on 12,6 PF?

 

-       If your offer is based on a PF of 30 we believe you are charging too much based on the performance of our other suppliers/projects

 

-       If your offer is based on a PF of 4 we fear that you have not understood the complexity of our project, or that you under-charge just to get your foot in.

 

-       All right, we’ll accept your offer based on a PF of 20 once again, but you must document a strategy on how to optimise your performance to match our other suppliers.

 

 

Warning

 

Remember that UCP estimation and PF calculation are not absolute truths. What you get is an estimate based on facts and an estimate that gives you a feeling of what end the “real” estimate should be in.

 

 

Test Cases Based on Use Cases

 Use Cases represents functional requirements and functional requirements need to be tested.

 

The purpose of the functional test is:

 

A)   Determine that the delivered solution works as required

B)   Determine that the delivered solution works as specified

 

The difference between A) and B) is that in A) you test that the requirements you have written in the use case (being the flow, the pre-conditions, the post-conditions, and the business rules) are actually delivered and works as required. In B) however, you test that the delivered solution works as specified in the design document.

 

For example if you have required that it must be possible to create users in the system (specified in the use case “Create User”). That use case specifies the functionality and the conditions under which “create user” must work.

 

What the use case (usually) does not say is how the requirement is designed in the system – for example that the create user functionality is designed as a wizard functionality with three tabs and with all fields popping up when required. That part, the design needs testing as well, so that you determine that not only is the functional requirement delivered but it also behaves as specified in the design specification.

 

In this post I will outline how to create a full functional test case foundation on basis of your use cases. Normally you would need to also update the functional test cases to address the design specification. In addition, besides functional testing various other test types exist. However, in this post I will focus only on the functional testing based on use cases. All the examples will be based on the use case example "Create User"  Download Use Case Example - Create User

 

The nature of the use case is that it describes the steps of activities inside the use case and for each step a number of business rules are related. So, in theory the use case could be considered a test case because you just need to test that you can execute the use case as specified and get the results as expected. In other words you test that:

 

A)   The use case can not be initiated if any of the pre-conditions are broken

B)   The use case can be executed following the steps outlined in the use case

C)   The use case address all business rules outlined related to the right steps

D)   The use case produce the conditions and / or output as specified in the post-conditions

 

In B) it says, “The use case can be executed following the steps outlined in the use case”. If we take a look on the steps in the use case (illustrated graphically in the activity diagram):

 

 

 

As you can see the steps through the use case is:

 

 

Step	User (System Administrator)	System
10	Screen1: Create User
20	Type-in user details
30	Save
40		Validate user details
50		Create user
60		Grant privileges
70	Screen3: Confirmation

 

 

 

But the use case could also be executed through these steps:

 

Step	User (System Administrator)	System
10	Screen1: Create User
20	Type-in user details
30	Save
40		Validate user details fail
50	Screen2 Error message

 

 

 

This lead to rule of thumb #1:

 

For each “way” through a use case you need a test case

 

 

In this example we need two test cases to represent the use case test. This can also be illustrated as the picture below. Here you can see a coloured line for each “way” through the use case, each representing a test case.

 

 

All right, so far we have identified two test cases for the use case test. Each test case has its own flow (the steps). Lets take a look at one of the test cases (for simplicity each time the test case is outlined it is written in green):

 

 

Step	User (System Administrator)	System
10	Screen1: Create User
20	Type-in user details
30	Save
70	Screen3: Confirmation

 

 

Actually, when executing a test case what the tester needs to do is to perform the user steps. Therefore I have deleted the system-side steps because the tester does not execute these steps – the system-side steps are not tested, but the outcome is. In other words the tester performs her steps and verifies that the system has responded correctly.

 

In order to verify that the system has responded correctly you need post-conditions in your test case. The post-conditions can be copied from the use case.

 

 In the use case the following post-conditions were specified (for the positive flow, which we are handling here):

 

If success:

• A new user is created in the system
• The user created is granted the privileges as specified
• The user created is created with a unique 4 digit employee number and a default password

 

Each of the bullets above represents a post-condition that needs to be verified. Your test case now looks as specified below:

 

 

Step	User (System Administrator)	System
10	Screen1: Create User
20	Type-in user details
30	Save
70	Screen3: Confirmation

 

Post-conditions:

 

1. It must be verified that a new user is created in the system with the attributes typed-in
2. It must be verified that the user created has been granted exactly the privileges as specified
3. It must be verified that the user created is assigned a 4 digit employee ID
4. It must be verified that the user created is assigned to a password

 

 

As you can see the post-conditions outlined is following the structure “verify that…”. Depending on the systems nature and the testers skills you could outline how to verify the statements outlined in the post-conditions. However, in this example we’ll assume that the testers are capable of verifying the statements.

 

Now we have the steps the tester must perform and the post-conditions the tester needs to check-for or verify. If we take a look at the steps you can see that the steps are not very clear. For example in step 20 it says “Type-in user details”. But what user details?

 

 According to the use case, when typing-in user details the following business rules apply:

 

FR1	User details	It must be possible to specify the following details when creating a new user:  First name  Surname  Birth date Address City Zip code Telephone Gender email
FR2	Specify related department	It must be possible to specify that the user to be created belongs to one of the following departments: Marketing Sales R&D IT Administration
FR3	Permissions	It must be possible to specify the following permissions to the system: Read only Read/write

 

 

A good test case specifies in details what data to type-in in the various steps. The reason is that you need to be able to reproduce an error by using the exact same data and you need to be able to re-test and confirm error correction by executing the test case with the exact same data again. This lead to:

 

Rule of thumb #2:

 

Test cases must be able to be re-produced by using a specified set of (test) data.

 

You could choose to refer to an excel sheet with the test data outlined – especially if you plan on reusing the test data for other test cases. For simplicity I will specify the test data directly in the test case.

 

Your test case now looks as specified below:

 

 

Step	User (System Administrator)
10	Screen1: Create User
20	Type-in user details: First name = “Jan” Surname = “Thomson” Birth date = “12-12-1970” Address = “122, Main Road” City = “Manchester” Zip code =XX 555” Telephone = “999 999” Gender = “Male” Email = [email protected]   Department = “Sales” Permission = “Read/Write”
30	Save
70	Screen3: Confirmation

 

Post-conditions:

 

1. It must be verified that a new user is created in the system with the attributes typed-in in step 20
2. It must be verified that the user created has been granted exactly the privileges as specified in step 20
3. It must be verified that the user created is assigned a 4 digit employee ID
4. 4.    It must be verified that the user created is assigned to a password being 8 character long as specified in business rule “FR 7”

 

 

The test case could be complete by adding the pre-condition, a unique test case ID and a test case name.

 

 

Your test case now looks as specified below:

 

 

Test case ID: TC #1

 

Test Case Name: Create User_Main flow

 

Pre-condition:

 

• The user must be logged-in as “System Administrator”

 

Flow:

 

Step	User (System Administrator)
10	Screen1: Create User
20	Type-in user details: First name = “Jan” Surname = “Thomson” Birth date = “12-12-1970” Address = “122, Main Road” City = “Manchester” Zip code =XX 555” Telephone = “999 999” Gender = “Male” Email = [email protected]   Department = “Sales” Permission = “Read/Write”
30	Save
70	Screen3: Confirmation

 

Post-conditions:

 

1. It must be verified that a new user is created in the system with the attributes typed-in in step 20
2. It must be verified that the user created has been granted exactly the privileges as specified in step 20
3. It must be verified that the user created is assigned a 4 digit employee ID
4. It must be verified that the user created is assigned to a password being 8 character long as specified in business rule “FR 7”

 

 

So, now you have created the first of two test cases related to the use case “Create User”.  By executing the test case just created are you absolutely confident that “Create User” works? Well, definitely for the test data typed-in we are – but what if the user to be created should be related to the “Marketing” department instead, will it still work? The case is that you can’t de 100% sure unless you test that too. What we are talking about is test variations.

 

 

This lead to rule of thumb #3:

 

Only by testing all variations of the test case you can be sure that the functionality works error free.

 

Test variations are the combinations of choices you can type-in. The choices are hidden in the business rules. For example, by looking at the use case and business rule “FR 2” you could execute the test case just created with the related department being Marketing – or Sales or R&D or IT or Administration….and then again, you could try granting the permission “Read only” (FR 3). Notice that the variations of the business rules “FR 4” and “FR 5 “ belongs to the other test case not outlined in this example (testing for the error situation).

 

Despite the variations of choices you could also create different test data and try those with different test variations. For example in the test case example just created we type in the date 12-12-2011 – maybe it could be interesting typing-in other dates too. Or try creating a female user etc.

 

The number of test variations can be huge and you need to determine what level is right for you depending on the system nature and how business critical it is – I will address this in another post.

 

 

 

Use Case Specification Example

In this post I will show an example of a use case and how to create it. Remember that use cases comes in many detail levels (See overview of Use Case Levels), in this example I will show you a Level2 use case which for example does not specify GUI requirements, error messages and confirmation messages.

 

Creating a use case specification has three steps:

1. Create a use case model showing the use cases and actors
2. Create an overview of the steps (content) of the use case -> here I strongly recommend you to use a model based approach – I prefer creating activity diagrams
3. Write the use case specification

 

Ad 1)

In order to give you a fairly simple example I have created a very simple use case model containing only one use case:

 

 

 

From the use case model you can see that the system has one use case only (for simplicity) and that the use case interacts with the actor System Administrator.

 

Ad 2)

The next thing to do is to create an overview of what goes on inside the use case. That is, what activity steps it contains. The best way to do this is to create an activity diagram (UML notation). The activity diagram is shown below. The advantage of creating an activity diagram is that you will get an overview and be forced to consider validations and error situations.

 

 
 

 

Ad 3)

 

Now that you have a use case model and an overview of the steps inside the use case you are dealing with – next thing to do is to write the use case specification. The use case specification will be based on the activity diagram. The main purpose of the use case specification is to specify any pre-conditions that must be met in order to start the use case, specify any business rules related to the use case steps, and specify any post-conditions that will be present after executing the use case.

 

Especially the business rules are important, since the business rules specify your business requirements. For each step in the use case you need to relate the step to a number of unique business rules – the approach is shown below (as you can see step 20 relates to three business rules (FR1, FR2, FR3):

 
 

 

Below you can see the final use case specification (the specification is a simplified example). You can also Download Use Case Example - Create User and/or Download Activity diagram - create user (Visio drawing).

 

Use Case Specification

 

 

Use Case ID:                                 UC-01

Use Case Name:                         Create User

Company:                                     AllAboutRequirements.com

Project:                                          AllAboutRequirements.com

 

 

 

Revision history:

Date	Version	Author	Description
23-09-2011	Draft	John Hansen	Draft example use case.

 

 

 

 

Table of Contents

High-level Description. 3

Use Case Characteristic. 3

Activity Diagram.. 4

Outlined main scenario. 5

Outlined Alternative Scenario 1. 5

Business Rules. 6

 

 

 

 

 

High-level Description

The purpose of this use case is to create a new user in the system.

 

Use Case Characteristic

Primary Actor	System Administrator
Trigger	System administrator chooses “Create User”
Pre-conditions	The user must be logged-in as “System Administrator”
Post-conditions	If success: A new user is created in the system The user created is granted the privileges as specified The user created is created with a unique 4 digit employee number and a default password   If failure: The system administrator is presented with an error message

 

Activity Diagram

 

 

 

Outlined main scenario

 

Step	User (System Administrator)	System	Business Rules
10	Screen1: Create User
20	Type-in user details		FR1, FR2, FR3
30	Save
40		Validate user details	FR4, FR5
50		Create user	FR6, FR7
60		Grant privileges	FR8
70	Screen3: Confirmation

 

Outlined Alternative Scenario 1

 

	Exit criteria from main flow: 40	User details validation fails
Step	User (System Administrator)	System	Business Rules
10	Screen2 Error message
20

 

 

 

Business Rules

 

ID	Business Rule name	Business Rule Description
FR1	User details	It must be possible to specify the following details when creating a new user: First name Surname Birth date Address City Zip code Telephone Gender email
FR2	Specify related department	It must be possible to specify that the user to be created belongs to one of the following departments: Marketing Sales R&D IT Administration
FR3	Permissions	It must be possible to specify the following permissions to the system: Read only Read/write
FR4	Mandatory details	The following fields are mandatory and must be filled-in: First name Surname Address City Zip code Gender Department relation Permission type
FR5	No duplicates	It must be validated that the user with duplicate information (as specified in mandatory fields) does not exist.
FR6	Apply employee number	The user to be created must be created with a unique four digit employee number
FR7	Apply default password	The user to be created must be created with a default 8 character password
FR8	Grant permissions	The user to be created is granted the privileges as specified in FR3

 

 

 

Free Use Case Specification Template

Download Use Case Specification Template

The template is desgned for level3 "fully dressed" use case specificatons but it can easily be tailored to your needs. Feel free to use the use case specification template free of charge with no limitations.

What To Use For Agile Projects - Use Cases or User Stories?

User Stories are a key element in Scrum projects and used to capture the high-level requirements for the Product Backlog of requirements.

 

One common misunderstanding is that user stories per definition replace use cases as a concept when developing agile solutions. Another misunderstanding is that if you are using use cases you can’t use agile methodologies for development. Both statements are wrong.

 

Let's first look at the two concepts. User Stories are an element in the agile methodology Scrum, while Use Cases origin from the UML framework for specifying requirements.

 

Similarities

There are some similarities between use cases and user stories.

1. Both concepts involve the users in order to capture the user requirements to be developed.
2. Both concepts are using plain language as the main content in order to enable the users to write or at least understand the produced output.
3. Both concepts are input to the design- and development process

 

Differences

Even though use cases and user stories are comparable there are some distinct differences:

1. Use cases capture more information than user stories. User stories are written stories in native language and often follow this structure: As a [user role], I want to [goal], so I can [reason]. Use cases capture a lot more information for example: Pre-condition, Post-condition, Trigger, Actors involved, Verbal description, sequence of actions etc.
2. User stories are usually shorter – that is by design, refer to difference#1 – than use cases.
3. User stories are slightly easier to create. The fact that user stories are shorter and includes less information justifies the statement that user stories are easier for the users to create. However, judging how much easier it is depends on how complex use cases you intend creating. Use cases can be created with various levels of complexities (See post: How to get use case success).
4. Use cases contain a sequence of actions while user stories are plain unstructured text.
5. Use cases model the behaviour of the system by defining how (usually) a user interacts with the system. User stories don’t model how this interaction should be. 
6. Use cases can be heavily detailed and used for “over-the-fence” projects, while user stories in their short form requires verbal interaction when development starts. Heavy detailed requirements can be useful when capturing very complex requirements or when creating a request for proposal.
7. Use cases are derived from a use case model. User stories are usually not derived from a model. Being derived from a model establishes an overview of the requirements structure.
8. Use cases are primarily used for capturing and documenting requirements, while user stories are primarily used for capturing high-level features and to prioritise work

 

Use cases have been along for many years. It is true, that in the past use cases were usually heavyweight specifications. I have seen 50 pages use case specifications being developed (in some cases that amount of details were needed). Today this is no longer usual. Today use cases are normally found in various levels of detail – from extremely lightweight being just a use case shape with a few sentences of description to heavyweight use cases with exact details of the business rules and requirements. I think the agile methods have influenced the way we use use cases today into a much more agile approach. That is why you can easily use cases for specifying your product backlog. In general think of a use case as containing a user story for each flow in the use case.

  

What is best – use cases or user stories?

In my opinion the best approach is what the development team is most familiar with. If the team favour one of the concepts and you can see it’s working you should not change it.

Saying that use cases or user stories in general are always a better choice is, in my opinion, nonsense.

 

Personally I find it easier to identify use cases from a use case model than to identify user stories. In addition I find it difficult to understand how the selected user stories adds up to be the complete system - looking at a use case model is easier that looking at hundreds of user stories.

 

After all what requirements specification is all about is lowering risk. Lowering the risk that something wrong or incomplete is being developed. How much effort you should put into lowering that risk depends on the impact and the probability that it will happen. What is enough? It depends on the risk assessment – but I think for agile projects a good rule of thumb is that you need enough details to be able to sign-off on a sprint.

 

New to UML - Check These Links to Get Started

Are you new to UML? if yes, then you might find these links usefull to get an idea what is inside the UML framework:

UML - the official OMG webpage about UML

IBM Ratonal - UML page

UML Tutorial from SparxSystems

 

 

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

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

 

 

 

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)