For the purposes of this article the assumption is that estimations and planning are required for gathering system requirements. However it could equally be adapted for business requirements and other areas of the project development lifecycle.
A use case model describes:
- System boundaries are Systems in scope for the project
- Use cases are The things the system in scope has to do
- Actors are Systems and human interactions with the use cases
Each use case should be estimated for size and complexity.
- Complexity can either be simple, medium, complex or very complex
- Size can be either small, medium, large or very large
See use case model example and then how the table is used below to determine size and complexity.
From the use case model it is then possible to plan out how many workshops are required taking into account size and complexity in addition to who needs to be invited.
To a certain extent estimating size and complexity is quite subjective but having the functionality broken down into more manageable chunks makes the work required easier to understand. It stands to reason that a larger more complex use case will take more effort than a smaller simpler use case. An example of a small and simple use case may be where there is a system actor interaction only for uploading a file. A more larger and complex use case would be where there may be more than one actor including human interaction which then shows that a graphical user interface is required. All of this information is available by reviewing the use case model.
There are also formulas available that can be used which take into account size, complexity, availability of resource to attend meetings and confidence ratings.
Thoughts? Questions? Please share in the comments.
