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

Shortening the Requirements Definition Phase on Your Project

Have you ever asked yourself why your requirements definition phase seems to take so long? On even short projects the definition phase can take as long as the implementation phase. Here are some suggested reasons why this may be the case.

1. Your elicitation sessions are unplanned and ad hoc. Planning your elicitation session and identifying key stakeholders is a key activity during requirements definition. Planning your sessions and setting them up ahead of time give stakeholders an opportunity to set aside the required time to both prepare and attend the sessions. Without this planning you may miss key stakeholders, requiring additional sessions to get their inputs.

2. There are too many attendees in the session. Have you ever attended a requirements gathering session with 15-20 people in the room? Have you asked why some of these people were providing requirements for a system they would never use? When you are planning your sessions identify key people who are required to attend. Keep the list to approximately 5-7 people. If additional people “show up” for the elicitation sessions, make it clear they are welcome to listen but that you are looking for input from the key stakeholders you identified. This is a great topic to discuss during the project kick-off as well.

3. The elicitation discussions quickly become revolved around technical and implementation issues. One of the key factors during elicitation sessions that can get you bogged down is focusing on how you are going to solve the problem versus just understanding the problem. Keep the discussion away from technical details and implementation solutions. Users will tend to lose interest in these discussions and you will lose valuable time.

4. The elicitation discussions wander off topic. Again, a key to preventing this is planning. Identify topics to be covered during an elicitation session and review them at the beginning of the session. Be a strong facilitator and keep the discussion on track. Identify a parking lot of items for later discussion versus sorting them out during the elicitation session.

Hopefully these suggestions will help guide your definition phase to a clear and timely conclusion.

By: Marcia Stinson