The 3-Step Guide to Documenting Requirements with Use Cases
/I was once part of a project team that employed use cases to identify which developer was working on the different software modules. We had different colour codes for each developer, so we could easily see at a glance who was working on what functionality and what level they had reached. Most analysts see the use case as a communication tool in holding discussions with stakeholders and for validating requirements. Whatever the purpose of employing use cases is, they should be continually refined to ensure that they capture additions, revisions or refinements as more facts emerge during the life of the project.
Use cases are a popular technique for documenting and understanding system requirements. Use case diagrams graphically depict who will use the system and in what ways the user expects to interact with the system. Use cases are triggered when an actor initiates a use case to complete a business task. An actor is someone or something that fulfils the role of interacting with the system in a specific way.
In a huge project, it’s not advisable or even feasible to document all the use cases due to schedule limitations and resource constraints. Only the important ones (based on project priorities) are documented.
Here are the 3 major steps to applying the use case technique to your project:
1. Identify Actors and Use Cases
Though there are different techniques for identifying use cases, a simple and effective way is to hold a discussion with stakeholders to identify inputs and outputs for specific processes. Using the demand planning process as an example, an input to the process is “Field Sales forecasts”. An associated use case here could be “Aggregate Sales Forecasts”, which adds up all the sales forecasts received from field staff. This same goes for outputs. A report may be required at a certain time of the month on the accuracy of sales forecasts. Such an event (the generation of the report) is referred to as a temporal event since it is triggered by time. A use case in this instance would be “Generate Accuracy Report”.
Another way to identify use cases is by analyzing the context diagram of the system, which shows the external parties that interact with it to provide inputs and receive outputs. If an external party initiates an input into the system, it’s called an actor. it’s always important to double-check findings with business users after drawing up the use cases.
2. Document High-level Use Cases
The next step is to document the purpose of each use case to gain an understanding of system functionality. An illustration is as follows:
Use case name: Approve Sales Forecasts
Actor: Commercial Director
Description: This use case describes the process of approving sales forecast values by the Sales Director. On completion, the demand planner gets a notification
3. Document the Use Case Course of Events
This is a more elaborate description as illustrated in the example below. It documents all the steps from when the actor initiates the use case till the event is complete.
Approve Sales Forecast
How do you apply use cases on the job?
Related Articles
