The Impact of Change and Use Cases

Market requirements change. These changes impact the use cases that support the changing requirements. Functional requirements change. These changes impact the use cases that they support. How can we leverage use cases to manage these changes? And how can we manage changes to use cases?

Background

We started a series of posts exploring why we apply use cases as part of product management, identifying 8 goals for which use cases are relevant. That series post contains links to detailed articles on each goal as we write them over the next weeks. Bookmark it and come back to it to see the puzzle come together.

Structured Requirements

When we use a structured requirements process, use cases support market requirements or goals. The use cases themselves are then enabled by functional requirements, and sometimes non-functional requirements.

Collectively, the functional requirements and non-functional requirements make up the software requirements specification, or SRS.

Different people view requirements from different perspectives. Something as simple as intent can mean completely different things to stakeholders and implementers. Depending on your role on the team, why, what, and how can mean very different things. The following diagram shows the perspectives of team members (stakeholders and product managers share a similar perspective).

Requirements Documents – One Man’s Trash

Changing the Software

Change happens. And changes flow downhill. As the first diagram shows, when we make a change anywhere in the process, it will cause changes in each of the “lower” areas. Each change also has to be validated back up the chain, to make sure that the implicit contracts between areas of the diagram are maintained.

Note: we’re using language that presumes changes have been approved, to make this article easier to read. Keep in the back of your mind that there may be outstanding approval processes that are not covered in this article. We did this instead of saying “approved changes” or “proposed changes” every time we could just say “changes.”

Changing Market Requirements

The goals of a software project can and should change over time. One of the benefits of incremental delivery is that we can identify changes to the needs of the business before we deliver the software. This allows us to adapt, which gives us a greater likelihood of achieving software product success.

Before a goal has changed, we will have defined the use cases that enable the goal. And we will have confirmed that the use cases are both correct and complete for achieving that goal.

After a market requirement has been changed, we need to revalidate that it is both correct and complete. We do this by reviewing the supporting use cases. When we identify which use cases support each market requirement, we can narrow the scope of our review to only those use cases that support the changing requirement.

Those use cases might need to change, or they might be obsoleted by the change. We may need to add one or more use cases to meet the new requirement. But with a form of traceability from the market requirement to its supporting use cases, we can focus our efforts on only the relevant changes.

Changing Use Cases

A use case can change because one or more of the market requirements it supports has changed. A use case may also be independently changed, because someone has proposed a better business process for achieving the same goal. A business analyst or interaction designer may be responsible for these changes.
When a use case has been changed, we must first verify the completeness of the market requirements it supports. Does the change in the use case cause us to no longer achieve our objectives?

We then have to validate the correctness of the use case. Is this changed use case correct?

Once a use case has been changed, the non-functional and functional requirements that are derived from the use case must also be evaluated. The notion of traceability from use cases to their supporting requirements allows us to narrow the scope of our analysis. The same logic described in the previous section applies here too.

Changing (Non)Functional Requirements

Functional and non-functional requirements can change because the use cases they enable have been changed. Functional requirements may also be changed because a software designer has proposed an alternative approach. This software designer could be an interaction designer or a senior member of the implementation team. The point to remember is that there is ideation involved in writing the requirements that support a use case.

If design wasn’t required, then writing an SRS would be both self-evident and programmatic, given a particular use case. And if that were true, then CASE tools would have found a very large market and flourished. Simply put, they haven’t.

As in the previous sections, when requirements in an SRS are changed, the upstream relationship must be reconfirmed – do they continue to support their respective use cases?

Downstream impacts of a change to the requirements spec are addressed in the scoping of the implementation team. Each change in requirements can result in changes to the design or implementation. Those changes must be evaluated for their impact on project costs and schedules.

Traceability helps us to narrow the scope of our analysis here too. Only those directly supporting requirements need to be evaluated.

Summary

Change happens. When it does, it propogates “down” the structured requirements diagram. We use traces between the artifacts to minimize the effort of evaluating those changes. We also use traceability to confirm that the previous characteristics of completeness and correctness still hold true.