This article is to provide you with techniques for eliciting requirements by providing step by step instructions to produce a use case model for an IT system. A company intranet will be used throughout to provide examples.
Use cases were first used by Ivar Jacobson to describe an amount of work to be done. Use cases break down the complexity and largeness of modern systems into convenient chunks. These chunks are based upon the users view of the product / system. The use cases help ensure the scope is defined before delving into more detailed requirements.
The benefit of identifying use cases and putting together a use case model is to:
- Ensure the breadth of the work is understood and agreed,
- To plan, prioritise, estimate and schedule the work
- Agree the system boundaries for the system architecture
- Foundation for more detailed requirements and the design
Once use cases are identified for the use case model they can either then be broken down into more detail using UML (Unified Modelling Language) or be used as a basis for creating user stories if using an agile methodology.
The article Using a use case model for estimating and planning provides more detail for planning the work based on a use case model.
There will be 4 further articles from this one to demonstrate how to provide more detailed requirements from the use cases so a developer can develop from them. Four different techniques will be covered to show how to gather and document the requirements into more detail:
- Writing a use case
- Data class diagrams
- Sequence diagrams
- User stories
Step 1 – Identify Actors
- List potential actors (people, products, systems)
- Only actors that are external to the system and interact with the product / system
- Could be human, i.e. a user or;
- Non human e.g. another system
- Draw a diagram with a large box in the centre to represent the product / system boundary and stick men around the outside to represent the actors. Draw lines to the centre box from each actor. Provide a name in the central box that represents the product / system boundary.
- Questions you could ask to identify actors
- Who uses the product / system?
- Who gets information from the product / system?
- Who provides information into the product / system?
- Where in the organisation is the product / system used?
- Who supports and maintains the product / system?
- What other systems use this product / system?
- Each time you interview a stakeholder show them this diagram as it could then prompt them to spot an actor missing.
- Communications involving external actors are only included where they interact directly with the solution.
Using below as an example shows that in addition to employees interacting with the intranet, the intranet must also communicate with external systems such as the companies timekeeping system, finance system, content management system and LDAP directory system.
Step 2 – Inputs / Outputs
- Identify all of the inputs and outputs including what business areas and systems need to input or receive output into the solution.
- Questions for identifying inputs and outputs
- What forms do you use?
- What types of information are going into the system?
- What outputs?
- What reports?
- This provides an opportunity for you to get copies of any forms or reports that are fed into or should come out of the system. Remember to always ask how up to date and complete these are.
Using the intranet example the inputs and outputs for each actor could be the following:
| Actor | Input and output |
| Timekeeping system | Employee schedule (input)
Leave requests (output) |
| Finance system | Expenses (output) |
| Employee | Personalised intranet content (output) |
| Employee | Self service information (Input) |
| Content management system | Published news and events (Input) |
| LDAP directory | Employees name
Telephone numbers |
Step 3 – Identify reasons for using the system (goals) from Inputs / Outputs.
- Identify the goals and things that the Actors (people, products, systems) want to achieve.
- The inputs and outputs identified in step 2 can be used to determine the goals.
- Make sure you cover all of the main goals of each of the actors.
- Questions to identify goals are:
- What are the goals of each actor?
- What will the actor use the system/solution for?
- Will the actor create, store, change, remove or read data into the system?
- Will the actor need to inform the system about external events or changes?
- Will the actor need to be informed about certain occurrences in the system?
- Does the system supply the business with all of the correct behaviour?
- What are the problems that need to be solved?
Following on from the example of an intranet from the previous examples the goals identified for each input and output could be the following:
| Input and output | Goal name |
| Employee schedule (input)
Leave requests (output) |
Book holiday |
| Expenses (input, output) | Submit expenses |
| Personalised intranet content (output) | View personalised content |
| Self service information (input, output) | Identify employee details |
| Published news and events (input) | Publish company news and events |
| Employees name
Telephone numbers |
Find employee telephone details |
Step 4 – Identify goals from business process modelling
- It may be the case that the goals identified from the previous steps are at the right level for a use case.
- A use case can normally be broken down into 7-12 steps to achieve the goal. If the steps are more than this or the goals identified contain a mixture of business specific or manual activities outside the scope of a system then a business process model setting out the business processes may be required.
- This may also be useful if the goals still remain unclear. If the stakeholders aren’t clear on what they want then they may be more comfortable describing their business processes. It can be useful to map out the as is processes to understand what needs to be improved and the to be processes to understand what the new improved process should be. Once the to be process is mapped the processes identified as being part of the system can be picked out as goals.
The article A guide to Business Process Modelling provides guidance on how to use this technique.
Step 5 – Selecting the goals for use cases
- Must be named using a verb noun phrase
- Always described from the actors point of view
- Supports activities in business processes
- Describes only interactions with the system and not events outside
- Should not be confused with business processes, the business processes are an end to end set of business activities, some of which may be supported by use cases. Step 4 covers identifying which use cases should apply to which activities in a business process.
- In a use case model unique references should be given to each actor and use case.
Using the previous steps the use cases and use case model would look like the following:
Step 6 – Identifying if there are any includes or extends use cases
- Think about the type of steps involved in the main flow of each use case. The main flow is also known as the happy path as it is the most common set of steps required to achieve the use case goal. If two or more of the use cases contain the same steps then consideration must be given to either merging them or creating what is known as an included use case. For example if an employee has to log on to be able to book holiday, submit expenses or view personalised content then you may wish to create a dedicated log on use case. It is called an include use case because it has to happen.
The syntax for an include use case would be the following update to the previous use case model diagram.
- Think about the alternative flows that could happen in each of the use cases. Alternative flows are alternative steps that can happen outside the main path. If there are any complex alternative flows then you may want to create an extend use case. This will make it optional to a use case so may not always happen. For example if an alternative flow is to approve expenses if they are over a certain amount then you may wish to create an approve expenses use case.
The syntax for an exclude use case would be the following update to the previous use case model diagram.
There will be further articles for how to elicit requirements in more detail.
This will also provide you with:
- How to structure meetings
- What questions to ask
- How to document the findings
- How to ensure all scenarios are identified to avoid missing requirements
Thoughts? Questions? Please share in the comments.
If you have found this article useful then you might like my book – The Business Analysis Handbook – Techniques and Questions for better Business Outcomes. The book is available from www.koganpage.com and all major print and e-book retailers.
Great article, Helen!!! Thanks! Very helpful!