Creating a Culture that Respects Requirements

EDITOR’S NOTE: This post on requirements was originally published here, by Medium, and this article was adapted from Software Requirements, Third Edition, by Karl Wiegers and Joy Beatty. If you’re interested in software requirements management, business analysis, project management, software quality, or consulting, Process Impact provides numerous useful publications, downloads, and other resources.

Creating a Culture that Respects Requirements

The leader of a corporate requirements organization once posed a question. “I’m experiencing issues in gaining agreement from some of our developers to participate in requirements development,” she said. “Can you please direct me to any documentation available on how developers should be engaged in the requirements process so I can help them understand the value of their participation?”

In another organization, a business analyst experienced a clash between developers seeking detailed input for an accounting system and an IT manager who simply wanted to brainstorm requirements without using any specific elicitation techniques. “Do readers of your book risk cultural conflict?” this BA asked me.

These questions exemplify the challenges that can arise when trying to engage business analysts, developers, and customers in a collaborative requirements partnership. You’d think it would be obvious to a user that providing requirements input makes it more likely that she’ll get what she needs. Developers ought to recognize that participating in the process will make their lives easier than being hit on the head by whatever requirements document flies over the proverbial wall. Obviously, not everyone is as excited about requirements as the typical business analyst is.

Culture clashes frequently arise when teams are working on requirements. There are those who recognize the many risks associated with trying to develop software based on minimal or telepathically communicated requirements. Then there are those who think requirements are unnecessary.

Get Buy-In for a New Process

It can be tough to gain business-side cooperation on projects like legacy-system replacement if users see this as unrelated to their own business problems and not worth their time. Understanding why people resist participating in requirements development is the first step to being able to address it.

It’s possible the resisters haven’t been exposed to solid requirements practices. Or they might have suffered from poor implementation of requirements processes, perhaps working on a project that produced a large, incomplete, and ignored requirements specification. Those experiences would leave anyone feeling frustrated.

Perhaps the resisters don’t understand and appreciate the value of those practices when performed effectively. They might not realize the price they have paid for having worked in a casual and unstructured environment in the past. That price mostly shows up as unexpected rework that leads to late deliveries and poor software. Such rework is buried in the daily activities of the project participants, so they don’t recognize it as a serious inefficiency.

If you’re trying to get developers, managers, and customers on board, make sure everyone understands the past pain the organization and customers have experienced because of requirements problems. Find specific examples to demonstrate the impact in case individuals haven’t felt the pain themselves.

Quantify the Costs of Requirement Problems

Express the cost in units that are meaningful to the organization, be it dollars, time, customer dissatisfaction, or lost business opportunities. Development managers often aren’t aware of how badly requirements shortcomings hurt their teams’ productivity. So show them how poor requirements slow down design and lead to excessive — and expensive — course corrections.

Even if you don’t have data available to quantify the costs of requirements problems, every organization has an anecdotal legacy of project failures. People remember systems that were dead on arrival, rejected by users as unacceptable. Isn’t it strange how project teams never feel they have the time to devote to getting the requirements right, and yet they always find the time, staff, and money to fix systems that were deeply flawed because of requirements errors? Use such stories from the corporate folklore to help steer the culture to recognize that, without solid requirements, failure is highly likely.

Developers are stakeholders in the project, but sometimes their input isn’t solicited and they become the “victims” of the requirements that are thrust upon them. Therefore, they benefit from providing input that will make the requirements documentation as useful and meaningful as possible. I like to have developers review requirements as they are evolving. That way they know what’s coming and can spot areas that need more clarity.

Get Input from Developers, QA, and Testers

You also need developer input when specifying internal quality attributes that aren’t visible to users. Developers can offer suggestions no one else might have thought about: easier ways to do certain things; functionality that would be very expensive to implement; unnecessary imposed design constraints; missing requirements, such as how exceptions should be handled; and creative opportunities to take advantage of technologies.

Quality assurance staff and testers are also valuable contributors to excellent requirements. Instead of waiting until later in the project, engage these sharp-eyed people in the iterative review of requirements early on. They’re likely to find many ambiguities, conflicts, and concerns with the requirements as they are developing their test cases and scenarios from the requirements. Testers can also provide input on specifying verifiable quality attribute requirements.

Management Needs to Lead the Charge

Management plays a dominant role in shaping an organization’s culture. The leadership must understand the need for the organization to have effective business analysis and requirements engineering capabilities as strategic core competencies. Yes, project-specific and localized grassroots efforts are important. But without management commitment, the improvements and benefits likely won’t be sustained after the project ends or after a reorganization. It doesn’t help if your senior people say they “support” the improvements but then revert to the same old processes the minute there is a fire.

Behaviors — not pronouncements —are evidence of a commitment to quality. Figure 1 lists ten signs that your organization’s management is truly committed to excellent requirements processes.

Figure 1. Some behaviors that indicate management’s commitment to excellent requirements processes.

Resistance to process or culture change can indicate fear, uncertainty, or lack of knowledge. If you can discern the source of the resistance, you can confront it with facts, reassurance, clarification, and education. Show people how their constructive participation in the requirements process not only is in their personal best interest but also will lead to collectively better results. Everyone wins when they work together toward a common objective.

To learn more on the topic of requirements management, we’ve curated some of our best resources for you here.

SEE MORE RESOURCES

Author
Recent Posts

Jama Software

Subject matter experts from Jama Software provide guidance and best practices on requirements management, test management, compliance and regulation, risk management, and complex product and software development.