The previous article How to elicit high level requirements by identifying use cases explained how to identify the scope of the solution and how to define use cases. This article explains what questions to ask and how to document solution requirements in more detail using UML (Unified Modelling Language).
A great benefit of this technique is that it provides a structure for what questions should be asked to obtain the level of detail required for a developer to take forward. It enables the business analyst to have a standard list of questions they can apply for any solution requirements gathering regardless of subject area. Even if you decide not to document using this technique the structure given for asking questions is still really useful to ensure solution requirements are not missed.
The standard questions are the following for each use case identified in the previous article. These involve asking and gaining consensus on:
- The description for the use case, can be 1 or 2 sentences. Must be a clear description of the event that occurs to trigger the use case and a distinct summary
- Pre-conditions – the state of the system before the use case starts
- Post-conditions – the state of the system after the use case
- The main success scenario – documenting each step from the actors point of view. Actors are the systems and human roles which interact with the use cases.
- Alternative flows that can happen and the steps
- Business rules – specifies criteria and conditions. These can be documented in its own section and as shown in the example below by indicating the name of the business rule against a use case step to indicate when it is required.
- Special requirements – normally used for non-functional requirements specific to use case
- Entity model diagram – types of information and attributes required. A check can be done to ensure that each type of information is referred to in the use case steps.
See below for an example of how the book holiday use case introduced in the last article could be documented using this technique.
UC001 Book Holiday
Description
This use case is required to allow holiday to be booked over the company intranet.
Pre-conditions
The Actor must be a current employee registered on the company intranet
Post-conditions
The holiday will be recorded and holiday balance reduced
Use case diagram
Basic Path
| Step | Description of Activity | Links | Alternates / Exceptions |
| 1 | The use case occurs when the ACT001 Employee chooses to book a holiday | ||
| 2 | The system requests employee details | Employee | |
| 3 | The actor enters employee details | ||
| 4 | The system requests holiday details | Holiday | |
| 5 | The actor enters holiday details | BR001 holiday restriction | |
| 6 | The system verifies the holiday details | BR002 Authorised manager | 6a Holiday remaining insufficient
Returns: 4 |
| 7 | The system updates the holiday and approval details against the employee details provided and reduces the holiday remaining. | ||
| 8 | The system displays holiday confirmation | ||
| 9 | The use case ends |
This alternative flow occurs when
| Step | Description of Activity | Links | Alternates / Exceptions |
| 1 | This alternative flow occurs when the actor has insufficient holiday remaining | ||
| 2 | The system displays a message to inform of insufficient holiday remaining |
Special requirements
- Company colours
The colours used on the system must be the company colours and follow the corporate style guidelines.
Linked elements
| Type | Name | Description |
| Business Rule | BR001 holiday restriction | The actor cannot select more than 10 days. A message must be displayed “You cannot select more than 10 days, please select a lower number”. |
| Business Rule | BR002 Authorised manager | The actor cannot select a manager that is not on the approver list. A message must be displayed “The manager selected is not authorised to approve your holiday, please select someone who is authorised”. |
Entity model diagram
The example doesn’t show all of the UML diagrams available but illustrates some of the main ones that the business/system analyst would need to cover with the business stakeholders to ensure that the solution requirements are covered sufficiently and the system will deliver what they want. It is also common to include high fidelity (system based) or low fidelity (drawn out on paper) prototyping to accompany this technique
Further benefits of this technique are:
- Breaks down the requirements into manageable chunks that can be gathered and written up separately.
- Can uncover missing requirements.
- Ensures the view of each of the stakeholder roles and external systems that interact with the solution is taken into account.
- Details business rules that might not be obvious from just reviewing a prototype.
- Covers alternative flows which often get forgotten about and can make a system unusable.
- Allows an iterative development approach where completed documented use cases can be started sooner.
- Uses diagrams and a structure which should lead to less pages of documentation and easier to read.
- Removes a lot of ambiguity for the developer.
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.
