Join Terri Wagner for an in-depth discussion in this video Writing requirements with use cases, part of Project Management Foundations: Requirements.
- Use cases for requirements, define real requirements for what the system must do. The system is simply a collection of interrelated elements that interact to achieve an objective. So while that could be An IT system, an automated teller machine or ATM system, it could also be People or interrelated elements that create a Wind farm And so on. Use cases describe a full set of behavioral requirements for the system outcome. A Use Case is A list of steps typically defining interactions between a role or "actor" and a system to achieve a goal.
For example, a restaurant wanting to Improve kitchen efficiencies, or their system may Build a use case around the customer as the "actor". Then, Provide a brief description and main flow of all the steps from the moment the actor enters the restaurant, places their order and get's their piping hot delicious food. Use cases are not the full set of requirements. Details might still be needed around things like External interfaces, Business rules and Performance targets. Use cases provide an easy way to describe user needs and system capabilities.
They're readable by both customers and users and help fill the gap between user needs and system functionality. They Help manage the system complexity by focusing on a single aspect at a time and helping to establish a framework to create user acceptance criteria that can be easily translated into test cases. Use cases Allow easy transition to the development and design team due to the structure and detail. Let's look at an example. To write a use case about withdrawing funds from an automatic teller machine or ATM, we described the customer sequence of interactions with the system.
The Customer inserts their ATM card and the System asks the customer to select the language. The Customer selects their preferred language and the System requests a personal identification number or PIN. The Customer enters their PIN number and the System asks the customer to select a transaction. The customer select's "Withdraw money". The System asks the customer to pick an amount. The Customer picks an amount and the System dispenses the money. The System asks if the customer wants another transaction and the Customer selects "No".
The System dispenses the ATM card, prints the receipt, records the transaction and closes the door. So you captured the sequence of interactions or behavior from the users point of view. It's important at this point, you Describe what the system will do, not how it will be done. The typical approach to this is through Progressive Elaboration. Each iteration results in a New, incremental version of the use case containing More details and Greater functionality than the previous iteration.
You Build on what was learned from previous versions and interactions with the clients and stakeholders. Iteration Allows successive refinements addressing high risk elements. So instead of trying to solve the whole problem at once, through iteration, you're solving a problem by repeatedly working on successive parts. So the First Round is very simple. First you Identify the actors. Next, for each actor, Identify it's use-case goals.
Then, for each use case, Write a brief description of the main flow. Just to be clear, let's define those elements. The "Actor" is a role played by a user or external entity interacting with the system to obtain value from the interaction. The Goal is an objective stating what has to be achieved. This is usually the name of the use case such as, withdraw funds from ATM. The Main Flow describes the entire interaction between the "actor" and the system to accomplish the goal.
Then, each time you iterate, You may capture more elements. So on the Second Iteration, You may add additional flows. And after Several Iterations, you wind up with a fully dressed Use Case that Captures all the elements we've discussed so far as well as Pre-conditions, Post-conditions, Success criteria and any other Additional information. Let's look at an example from our Wind Farm. Let's say under the section of Control Monitoring you want to Build a use case for turbine operating limits.
Hold on here because I'm just going to read what the original requirements are, so here we go. The original requirement says, "Operators shall be notified by the system "if individual turbines fail to operate within this, "the defined and agreed-upon range "of cut-in and cut-out speeds. "Corrective action is required when an individual turbine "does not meet the range values." "The control monitoring system "shall keep the available energy above "the minimum threshold, to maintain "the turbine's structural health.
"Operators shall be notified when turbines "are within 20% of the upper "or lower ends of those limits." "Corrective action is required when an individual turbine "is trending towards the upper and lower range values. "The control system shall automatically shut down turbines "exceeding the limits, pending analysis of the results." So now let's take that information and create a use case. A brief use case on the First Iteration would List the name, something like, "Control Monitoring-Turbine Operating Limits".
Then you'd identify the "Actors", Control System Operator, Control System, Individual Turbines. Next you would State the Goal: Monitor and control turbine-operating limits to maintain structural health of the turbines and optimize turbine performance. And finally, you would describe the main flow. Operators use the control system and its reporting data to monitor wind turbines relative to the defined and agreed-upon operating limits of cut-in and cut-out speeds.
Operators are notified when individual turbines are trending within 20% of the defined operating limits. Based upon the data, operators will decide if action is required, and which action to take. Turbines exceeding the limits shall be automatically shut down by the control system. Operators will be notified of the action and asked to perform analysis of the situation and determine next steps. Whew, okay, so there we just took the stated requirments and converted them into a use case.
If you need to develop a fully dressed use case, just Go through the process again and Apply your progressive elaboration techniques. In some, that's how you take stated requirements and turn them into a use case. Do you write use cases when documenting your requirements? Do you just create a brief use case or do you iterate several times until you have a fully dressed use case?
Lynda.com is a PMI Registered Education Provider. This course qualifies for professional development units (PDUs). To view the activity and PDU details for this course, click here.
The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.
- Classifying requirements
- Developing requirements
- Investigating requirements
- Documenting requirements
- Validating requirements
- Managing changing requirements