Screencast: Getting the Most Out of Caliber RM And Your Requirements

In this post, Anothony C describes how to export your Caliber Requirements Grid into an Excel spreadsheet. In the following screencast, I demonstrate how to copy a Traceability Matrix from Caliber RM into Excel using a similar method.



You can find this video as well as many more requirements templates and tools in our resources page.

Prioritizing Your Software Requirements, Part II

In Prioritizing Requirements, Part I, we covered the reasons to prioritize requirements and the basic technique. We’ll now address what to do when there is disagreement about prioritization.

Unfortunately, requirements prioritization exercises can degrade into arguments very rapidly. This is particularly true when there are conflicting requirements that each side feels they must have. The best way to avoid this type of emotional response is to discuss the facts – what will the impact to the business be if we don’t implement this requirement?

The only way to understand this impact for each requirement is to make sure each maps back to one or more business objectives. These objectives provide a measurable, quantitative impact for each requirement. Tracing back to business objectives allows you to rephrase the question from: “Which requirement do you want – System shall allow a player to play in more than one game at once. vs. System shall allow players to create and maintain teams of other players.” to “Which requirements is better for the business with respect to the objectives of this project?”

The trickiest thing here is setting up these relationships in the first place. If it is not clear how each feature enables the business objectives, it is certainly worth the time and effort to uncover the correct links to ensure that the features and requirements being implemented actually will help solve the problem!

The important thing here is that you are reframing the conversation from “what I want” to “why this feature/requirement will help achieve our goal.”

Happy prioritizing!

Why Traceability (by itself) Is Worthless

Performing traceability of delivered functionality to requirements without tying them back to Business Objectives is in my opinion an exercise in futility. To anyone engaged in this exercise, I ask “So What?”

At first blush this might seem like an extreme position to take. The benefits of requirements traceability seem readily obvious whether or not they are tied back to Business Objectives. You can determine what requirements were implemented, when they were implemented, what still needs to be done and so on. All of these are good things in and of themselves.

Do You Need Business Objectives For Software Requirements Traceability?

By way of answer, imagine that you are writing requirements for an Experiment Management system. Consider the following scenario.

The first set deals with setting up the experiment. The other set deals with analyzing the results of the experiment.

One of them is responsible for the team that defines and sets up the experiments. The other manager leads the team that analyzes the results of the experiments.

Each set had a total of 10 requirements each. The users prioritized their requirements and each team came back with 4 “critical” and 6 “nice to have requirements”. Assume that all the “Critical” requirements are equally important and deliver approximately the same amount of functionality each to the final delivered product.

They satisfied all of the “nice to have” requirements of both sets. All 4 critical requirements of the experiment analysis requirements were satisfied, but only one of the critical requirements of the experiment set up requirements.

Business Objectives Are Your Yardstick For Success

Simple traceability that did not tie back to Business Objectives would show something along the following lines:

By any yardstick it looks like a spectacularly successful release.

But consider for a moment if the Business Objective for the release has been defined as “reduce the amount of time taken to perform experiment set up by 90% so that the company can increase the probability of successful new product creation by increasing the number of experiments that can be set up by our team of scientists.” The company came up with this objective because it is far easier for them to hire analysts than find skilled scientists who can dream up new experiments that will result in new products.

If we were to apply this knowledge to traceability and coverage of requirements, a very different picture of the success of the release emerges.

All else remaining the same, from a Business Objective stand point, we have about 25% coverage of what is really important to the company for this release. So, this was a pretty dismal release though the raw statistics that do not tie back to Business Objectives seem to indicate otherwise.

At the end of the day, companies build software that advance their prospects and help them achieve specific business goals. As requirements professionals, we need to tie back the outcomes to the Business Objectives. So, if we are not tracing requirements back to the Business Objectives, we are generating data that may or may not be useful or relevant in the grander scheme of things.

There is definitely some virtue in generating data for its own sake. This would be the case in doing all the hard work to trace requirements to specific functionality that has been delivered. But not taking the final step and tracing it back to Business Objectives misses the whole point of the exercise. We are guilty of generating data without giving it the proper context that Business Objectives provide.

So the next time, someone tells you they are tracing delivered functionality back to the requirements, ask them if they are tying them back to Business Objectives. If the answer is no, ask them “So What?” I would.

Are UI Requirements Software Requirements?

User Interface design is often assigned responsibility for look-and-feel. While I understand the importance of UI design, I am highly dissatisfied by its reliance on "heuristics" and, frankly, the uneven quality of those who profess expertise in the subject.

I submit that UI needs a haircut -- that we should limit the scope of what falls into the realm of UI. I think look-and-feel might be a better overarching category, but even that is too broad. The underlying flaw is that practical UI is rarely formally tested and less frequently permanently linked to business objectives.

The next revolution in requirements will be traceability or -- as I prefer to say -- connectivity. To me, traceability implies a one-way progression from objective, to requirement, to specification, to development, to test, with each transition as a one-way gate, during the passage through which one must abandon all hope of returning. Connectivity, on the other hand, is the continuous, two-way link between

• Business Objectives


• Marketing Objectives


• Functional Requirements


• Development


• Testing


• Usage

Such that any shift in one puts pressure on the others. It is connectivity that provides for not only rapid development, but presents the possibility of instantaneous development. Being able to modify a product this way depends wholly on being able to pick up the thread and see where it tugs. Before this was left to intuitive judgments, which were imprecise and incomplete leading the product into an inevitable "slow drift" away from the original business objectives.Imagine that you wanted to capture a certain "feel" as a marketing objective...

Why? Well, let's say that you believe "slippery" is the feel that would increase sales for a certain segment (amphibian programmers, say). If you can make that testable connection, even if it proves that there is no correlation, you have created an underlying framework to test your inference.

Even the softest requirements should be "connected" to business goals. If creating such connections seems like too much trouble for the requirement, chances are you're not dealing with a requirement in the first place.

The Trace Race

In the early days of the Internet, my then-CEO had no problems selling a complete copy of our proprietary database in lieu of the normal subscription fee. When I asked him why he was willing to do so, he smiled and said "It will be worthless in a year. There's no way they can maintain it." The core competency of the company, I realized, wasn't the information itself, but rather the way it was managed.

The same applies for requirements.

Believe it or not, gathering accurate requirements is only a small part of the requirements process, and arguably not even the most important part. Rather, I believe how we manage those requirements is the core competency of a truly revolutionary product development experience. The catalyst for revolutionary requirements management is very easy to describe but hard to do: Traceability.

Traceability is a simple enough concept: requirements have associations to business objectives, related requirements, and interdependencies. Without traceability, a single requirement change can render otherwise accurate requirements unusable, especially if there are many dependencies to that requirement.

Traceability is important because it enables:

• Project Success Metrics


• Automation of Project Change


• Change Impact Measurement


• Testability

All of which are keystones to presenting information required to make smart decisions, tools to automate requirement changes, and maintaining focus on the business objectives (aka "Now why are we doing this, again?").

Sounds easy enough, right? Unfortunately, if traceability is not part of the plan from the beginning, it can be almost impossible to implement after the fact. Indeed, many requirement documentation efforts start with excellent requirements only to fall apart in short order when the first major revisions are made (and even more so if the original business objectives fade from memory).

This is why requirement management tools can be so powerful, by enforcing traceability from the start, and providing an easier, automated method to add in the missing parts. Think about how you will modify and manage your requirements the next time you decide on getting a "head start" in lieu of establishing clear, measurable business objectives.