How to succeed with business oriented IT projects using business process analysis, use cases and requirements management in general.

Use Cases

17/12/2012

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:

Expert Judgment

Lines of
Code (LOC)

Function
Point Estimate

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.

“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.

15/10/2011

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:

It must be verified that a new user is created in the system with the attributes typed-in

It must be verified that the user created has been granted exactly the privileges as specified

It must be verified that the user created is assigned a 4 digit employee ID

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 = jan@com.com

Department = “Sales”

Permission = “Read/Write”

30

Save

70

Screen3: Confirmation

Post-conditions:

It must be verified that a new user is created in the system with the attributes typed-in in step 20

It must be verified that the user created has been granted exactly the privileges as specified in step 20

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”

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 = jan@com.com

Department = “Sales”

Permission = “Read/Write”

30

Save

70

Screen3: Confirmation

Post-conditions:

It must be verified that a new user is created in the system with the attributes typed-in in step 20

It must be verified that the user created has been granted exactly the privileges as specified in step 20

It must be verified that the user created is assigned a 4 digit employee ID

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.

23/09/2011

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:

Create a use case model showing the use cases and actors

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

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):

16/06/2011

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.

04/06/2011

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.

Both concepts involve the users in order to capture the user requirements to be developed.

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.

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:

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.

User stories are usually shorter – that is by design, refer to difference#1 – than use cases.

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).

Use cases contain a sequence of actions while user stories are plain unstructured text.

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.

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.

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.

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.

20/04/2011

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.

04/04/2011

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

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

27/03/2011

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 systemsWhat 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:

High-level use cases

Medium-level use cases

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.

Welcome to All About Requirements. I hope you are visiting because you, just like me, are absolutely passionate about business process analysis, use cases, and requirements in general. Thank you for visiting.
- John