The leader of a corporate requirements organization once posed a problem. “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.
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 he’ll get what he 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 you are; if they were, they’d probably all become business analysts!
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. 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 that 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. That 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. 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 that 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 a recognition 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. 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 plays a powerful role— often the dominant role—in shaping the culture of an organization. The organization’s leadership must understand the need for the organization to have effective business analysis and requirements engineering capabilities as strategic core competencies. Though project-specific and localized grassroots efforts are important, 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—constitute evidence of 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.
Author: Karl Wiegers & Joy Beatty
Karl Wiegers is Principal Consultant at Process Impact, www.processimpact.com. Joy Beatty is a Vice President at Seilevel, www.seilevel.com. Karl and Joy Beatty are co-authors of the award-winning book Software Requirements, 3rd Edition, from which this article is adapted. Karl’s most recent book is Successful Business Analysis Consulting: Strategies and Tips for Going It Alone.