If you have not read the first two articles, you can find them here:
Rather than expecting use cases to contain all of a system’s functionality, I prefer to employ use cases to help the business analyst discover the functional requirements. That is, the use cases become a tool to reveal functionality rather than being an end requirements deliverable themselves. Users can review the use cases to validate whether a system that implemented the use cases would meet their needs. The BA can study each use case and derive the functional requirements the developer must implement to realize the use case in software. I like to store those functional requirements in a software requirements specification, although you could add them to the use case description if you prefer.
I’m often asked, “Which comes first: use cases or functional requirements?” The answer is use cases. Use cases represent requirements at a higher level of abstraction than do functional requirements. I like to focus initially on understanding the user’s goals so that we can see how they might use the product to achieve those goals. From that information, the BA can derive the necessary functionality that must be implemented. Conversely, if users present fragments of functionality during a requirements elicitation discussion, the BA should try to figure out which use case that functionality might go with, if any.
Functional requirements—or hints about them—lurk in various parts of the use case. The remainder of this article describes a thought process a BA can go through to identify the less obvious functional requirements from the elements of a use case specification.
Preconditions state conditions that must be true before the actor can perform the use case. The system must test whether each precondition is true. However, use case descriptions rarely state what the system should do if a precondition is not
satisfied. The analyst needs to determine how best to handle these situations.
Suppose a precondition for one use case states, “The patron’s account must be set up for payroll deduction.” How does the system behave if the patron attempts to perform this use case but his account is not yet set up for payroll deduction? Should the system just notify the patron that he can’t proceed? Or should it give the patron the opportunity to register for payroll deduction and then proceed with the use case? Someone has to answer these questions, and the SRS is the place to provide the answers.
Post-conditions describe outcomes that are true at the successful conclusion of the use case. The steps in the normal flow naturally lead to certain post-conditions that indicate the user’s goal has been achieved. Other conditions, however, might not be visible to the user and therefore might not become a part of a user-centric use case description.
Consider an automated teller machine. After a cash withdrawal, the ATM software needs to update its record of the amount of cash remaining in the machine by subtracting the amount withdrawn. Perhaps if the cash remaining drops below a predetermined threshold the system notifies someone in the bank to reload the machine with additional money. I doubt any user will ever convey this information during an elicitation discussion, yet the developer needs to know about it. Such behind-the-scenes information is not part of a user’s view of the system as a black box. Instead, think of that information as being white-box details about the internal workings of the use case that the analyst must deduce and convey to the developer.
Normal and Alternative Flows
The functionality needed to carry out the dialog between the actor and the system is usually straightforward. Simply reiterating these steps in the form of functional requirements doesn’t add value. The BA needs to look carefully at the normal flow and alternative flows to see if there’s any additional functionality that isn’t explicitly stated in the use case description. For example, under what conditions should the system offer the user the option to branch down an alternative flow path? Also, does the system need to do anything to reset itself so that it’s ready for the next transaction after the normal flow or an alternative flow is fully executed?
The BA needs to determine how the system could detect each exception and what it should do in each case. A recovery option might exist, such as asking the user to correct an erroneous data entry. If recovery isn’t possible, the system might need to restore itself to the state that existed prior to beginning the use case. The BA needs to identify the functionality associated with such recovery and restore activities and communicate that information to the developer.
Many use cases are influenced by business rules. The use case description should indicate which business rules pertain. It’s up to the BA to determine exactly what functionality the developer must implement to comply with each rule or to enforce it. These derived functional requirements should be recorded somewhere (I recommend documenting them in the SRS), rather than just expecting every developer to figure out the right way to comply with the pertinent business rules.
Other Requirements and Assumptions
The use case might assume that, for instance, the product’s connection to the Internet is working. But what if it’s not? The developer must implement some functionality to test for this error condition and handle it in an appropriate way.
In my experience, the process of having the BA examine a use case to derive pertinent functional requirements adds considerable value to the requirements development process. There’s always more functionality hinted at in the use case than is obvious from simply reading it. I prefer to have an experienced BA discern this latent functionality rather than a developer.
Use Cases: A Pragmatic Approach
Developers don’t implement use cases: they implement specific fragments of functional behavior that allow users to accomplish valuable tasks with the software. My philosophy of employing use cases as a tool to help me discover functional requirements means that I don’t feel a need to force every bit of functionality into a use case. It also gives me the option of writing use cases at whatever level of detail is appropriate. I might write some use cases in considerable detail to elaborate all their alternative flows, exceptions, and other requirements. I could leave other use cases at a high level, containing just enough information for me to deduce the pertinent functional requirements on my own. The functional requirements are the end result of requirements analysis, regardless of where you choose to store them or whether you even write them down at all.
Deriving functional requirements from the use case always takes place on the journey from ideas to executable software. The question is simply a matter of who you want to have doing that derivation and when. If you deliver only use cases without all the functional detail to developers, each developer must derive the additional functionality on his own. If they don’t record these functional requirements, it’s hard for testers to know exactly what they need to test. It also increases the chance that someone will inadvertently fail to implement certain necessary functionality.
You will almost always have additional functional requirements that do not fit nicely into a particular use case. In the second article in this series, I mentioned the example of logging into a system. Clearly, that functionality must be implemented, but it’s not a use case. You might also have functional requirements that span multiple use cases. Consider the behavior the system should exhibit if a required Internet connection goes down. The Internet connection could fail while the user is executing any use case. Therefore, this error condition doesn’t constitute an exception flow associated with a specific use case. It needs to be detected and handled in multiple operations. The BA can place all the functional requirements that are not associated with or derived from a particular use case into the logically appropriate section of the SRS.
I have found use cases to be a highly valuable technique for exploring requirements on many types of projects. But I also value the structured SRS as an effective place to adequately document the functional requirements. Keep in mind that these documents are simply containers for different types of requirements information. You can just as readily store use cases, functional requirements, and other types of requirements information in a requirements management tool or in other forms. Just don’t expect use cases to replace all your other strategies for discovering and documenting software requirements.
Author: Karl Wiegers is Principal Consultant at Process Impact, www.processimpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is Software Requirements, 3rd Edition (Microsoft Press, 2013), co-authored with Joy Beatty.