Remember that a use case is always a complete procedure that starts and ends with the system in a stable state with no significant time gaps in between. Sometimes, however, it can be difficult to decide whether to group together or separate related functions. There is no one rule for this as it depends on a number of factors. Here are some guidelines:
| If the Use Case Document comes to less than a page, think about rolling it into another functionally or procedurally related use case. |
|
|
| If more than one use case relates to a single screen, think about rolling them together provided the resulting use case is no more than five pages. For example, Add, Edit and Delete use cases for major entities would normally be rolled into one use case called 'Manage EntityName'. The basic flow would start with a case statement in which the user chooses which flow to perform. | ||
| Aim for between 25 and 75 use cases in total for a medium sized system |
| Don't define each alternate flow in a use case as a use case | |
| Don't define each step in a use case as a use case | |
| It must be possible to run the use case in its own right without needing to run other use cases as part of the same sequence | |
| Don't create use cases that sit waiting for hours or days in the middle for something to happen. Finish it at the start of the wait and define the event that signals the end of the wait as the start of the next use case. |