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.
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.
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.
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.
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.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: