One analyst on my project team thinks we should put every bit of system functionality into a use case. Is that a good idea?
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
Not in most cases. I've seen many organizations get in trouble when they relied solely on use cases as being "The Requirements." Many analysts have told me that they handed their use cases to their developers, who got the general idea about the system, but the use cases were missing a lot of necessary functionality details the developers had to track down.
I regard use cases primarily as a tool for structuring conversations with users to understand the goals (or tasks) users are trying to achieve with the help of the software system. Use cases also help users envision how they might interact with the system to achieve those goals. From this information, the analyst can derive the necessary functionality that developers must implement to let the users achieve those goals or perform those tasks.
Even a well-written use case does not contain all the functionality developers need to know about, such as how to handle unsatisfied use case preconditions or how to enforce pertinent business rules. Often the analyst already knows about some functionality the system must contain, such as the need to provide login access or other security mechanisms. I see no value in packaging such requirements into a use case.
The ultimate deliverable from requirements development is a software requirement specification that contains the detailed functional requirements, nonfunctional requirements, and other supporting information. Use cases are a valuable way for the analyst to discover functional requirements. But I've never met anyone who found that use cases provided enough details about system functionality for developers to build the software.
I regard use cases primarily as a tool for structuring conversations with users to understand the goals (or tasks) users are trying to achieve with the help of the software system. Use cases also help users envision how they might interact with the system to achieve those goals. From this information, the analyst can derive the necessary functionality that developers must implement to let the users achieve those goals or perform those tasks.
Even a well-written use case does not contain all the functionality developers need to know about, such as how to handle unsatisfied use case preconditions or how to enforce pertinent business rules. Often the analyst already knows about some functionality the system must contain, such as the need to provide login access or other security mechanisms. I see no value in packaging such requirements into a use case.
The ultimate deliverable from requirements development is a software requirement specification that contains the detailed functional requirements, nonfunctional requirements, and other supporting information. Use cases are a valuable way for the analyst to discover functional requirements. But I've never met anyone who found that use cases provided enough details about system functionality for developers to build the software.
This was first published in February 2007