Using Use Cases for Requirements Definition and Management

Several years ago I found a book titled “Use Cases: Requirements in Context”. I had to think about that for just a second before realizing that precisely describes what a use case does. Use cases describe requirements in the context of a process flow or process narrative, thus stating a requirement in the context of that narrative.

Use cases are an effective tool in documenting how the user does their job. Often called “as is” and “to be”, these narratives help ensure that we understand how the user does their job today (as is) as well as how they may envision doing their job tomorrow (to be). Use cases are becoming more and more popular as analysts continue to struggle with the issues around the relationship of requirements.

However, sometimes use cases are used effectively during requirements elicitation and definition, but get lost when the transition is made to requirements management. If you think about the steps in a use case, each step describes an action by either the user or the system. Depending on the granularity you want in your requirements and traceability, consider making each step in the use case a requirements statement. Take the following simple use case as an example.

The System displays the account information to the Customer.

The Customer reviews the account information.

The Customer selects the Pay Option.

The System displays the payment options to the Customer.

It is pretty clear from this use case that there are two System steps and two Customer (i.e. User) steps. If we extract the two System statements and, if required, add “shall” to them we get the following two system requirements:

The System shall display the account information to the Customer.

The System shall display the payment options to the Customer.

These two requirements begin to form the basis for the system requirements. These system requirements will likely be decomposed into many system requirements, but we can trace them directly back to the system steps in the use case.

Remember that use cases contain very valuable information for systems analysis and development. Use cases are never really finished since they must be continually reviewed throughout development to make sure they accurately reflect how the product behaves when it is delivered. Make sure that use cases are not put on a shelf, but are traced to both tests and system requirements.

By: Marcia Stinson