Challenging Requirements

The hardest long term challenge in eliciting requirements is improving our ability to do it. The hardest short term challenge in gathering requirements is getting all of them. We have a lot of techniques for gathering requirements, from interviewing to brainstorming to researching. How do we know we defined all of the requirements? Everyone who manages requirements knows the value of validating requirements. But validation leaves a blind spot as it looks backwards instead of forwards. We propose to do exactly the opposite.

Challenging Requirements

When we validate our requirements, we start with an assumption – that we already have the requirements defined. We just need to validate that we got it right. This is exactly the mindset that can get us in trouble.

I think that these requirements are correct. Will you validate them for me?

This is the analyst equivalent of “Do these jeans make me look fat?” Even when our interviewee intends to give us the best possible answer, we have established a subliminal desire to tell us what we want to hear.

We’re trying to find the unknown unknowns – those things we missed, but don’t know we missed. Validating the things we didn’t miss is like trying to drive forward by looking in the mirrors. What we need to do is challenge what we think is true, not validate it. By challenging it, we will force ourselves to consider alternatives, think outside the box, and possibly uncover some more requirements. We will likely improve the ones we have as well.

Follow the Money

Every detective show on television has at least one episode where the way to solve the problem is to follow the money. Whoever stands to gain from the crime is a likely suspect. We should do the same thing with our requirements. Starting at the top, and working our way down, we will challenge everything.

We’ve used the following diagram in several articles on structured requirements. It shows

• Goals (benefits to the business) that are achieved by enabling
• Use Cases that are enabled by implementing
• Functional requirements with certain characteristics and restrictions.

Structured requirements diagram

The goals are closest to the money. One trick we can take from sales people is to start with the annual report. What does the CEO or chairman talk about to the shareholders – this is the most important issue to the company. And usually a strategy has been identified – organic growth, acquisition, aggressive cost-cutting (re-engineering). Does our goal directly contribute to these objectives? When working on enterprise software, or any project where the budget is more than 1% of the profits for the company, we better be clearly aligned with those objectives.

Smaller projects may be supporting a division objective (expand dealer network in Europe) or department objectives (reduce call-center operations costs by 10%). We won’t be able to create a clear link between a $100,000 project and the annual report of a $10 billion company. Look one level above the project for the driving objective.

We might think that the goal is to reduce operations costs for the call center. What if the goal is really to increase call-center throughput with the current staff? How would we know? What are other goals that might be the true drivers of our project? Ask our stakeholder what his goals (not the project’s) are. Ask how they support his boss’s goals. Ask hypothetical questions to see what the real drivers are. Ask if replacing the call-center staff with cheaper people would be a success? If cost reduction is the true goal, then it would.

Challenging Use Case Completeness

This activity is no different than validating completeness, except for our state of mind. We start with the assumption that we’re missing something, and its something important. Since each goal is supported by a series of use cases, what are the missing use cases? We probably diagrammed business processes to create our current set of use cases. We aren’t looking for overlooked steps in the process, we want to know how these processes can be different.

• If we implement every defined use case to perfection, what doesn’t happen?
• Are the post-conditions of our formal use cases accurate (or do they imply a missing activity)? If we achieved only the post-conditions, would we achieve the ROI targeted in the supported goals? The missing steps will be glaring – what are the use cases that fill the gaps?
• Is there a shortcut that people use when there’s a huge rush to process something? Does this shortcut identify any alternate courses or new use cases?

These edge cases are probably not the best thing to study when initially defining use cases, but they can help us uncover processes we overlooked when initially defining the use cases.

Unsupported Use Cases

We’ve written functional requirements to support our use cases. Again, we’re assuming that we missed something. What are the unsupported use case steps?

• Walk through the steps in each use case, and make sure that each step in each use case is supported with functional requirements.

Incomplete Functional Requirements

There is a lot of good content out there about validating (challenging!) the completeness of functional requirements. It is a big enough topic that we’ll save it for another post. Techniques like using data-flow diagrams and state-transition diagrams are fantastic for identifying low-level oversights when writing an SRS or PRD.

Challenge

The challenge for us is to change our perspective. We shouldn’t be validating that what we found is correct. We should be challenging the assumption that we found everything.