Cosmic Truths about Software Requirements, Part 1

As every consultant knows, the correct answer to nearly any question regarding software is “It depends.” I realize that’s not a very satisfying answer, but this isn’t just a consultant’s cop-out—it’s true. The best advice for how to proceed in a given situation depends on the nature of the project, its constraints, the culture of the organization and team, the business environment, and other factors.

That said, having worked with many organizations, I’ve made some observations about software requirements that really do seem to be universally applicable. In this series of three articles (adapted from my book More about Software Requirements) I present some of these “cosmic truths” and their implications for the practicing business analyst.

Cosmic Truth #1: If you don’t get the requirements right, it doesn’t matter how well you execute the rest of the project.

Requirements serve as the foundation for all the project work that follows. I don’t mean the initial software requirements specification you come up with early in the project, but rather the full set of requirements knowledge that is developed incrementally during the course of the project.

The purpose of a software development project is to build a product that provides value to a particular set of customers. Requirements development attempts to determine the mix of product capabilities and characteristics that will best deliver this customer value. This understanding evolves over time as customers provide feedback on the early work and refine their expectations and needs. If this set of expectations isn’t adequately explored and crafted into a set of product features and attributes, the chance of satisfying customer needs is slim.

Requirements validation is one of the vital subcomponents of requirements development, along with elicitation, analysis, and specification. Validation involves demonstrating that the specified requirements will meet customer needs. One useful technique for validating requirements is to work with suitable customer representatives to develop user acceptance criteria. These criteria define how customers determine whether they’re willing to pay for the product or to begin using it to do their work. User acceptance criteria typically stipulate that the product allows the users to properly perform their most significant tasks, handles the common error conditions, and offers an acceptable level of quality. User acceptance criteria aren’t a substitute for thorough system testing. They do, however, provide a necessary perspective to determine whether the requirements are indeed right.

Cosmic Truth #2: Requirements development is a discovery and invention process, not just a collection process.

People often talk about “gathering requirements.” This phrase suggests that the requirements are just lying around waiting to be picked like flowers or to be sucked out of the users’ brains by the BA. I prefer the term requirements elicitation to requirements gathering. Elicitation includes some discovery and some invention, as well as recording those bits of requirements information that customer representatives offer to the BA. Elicitation demands iteration. The participants in an elicitation discussion won’t think of everything they’ll need up front, and their thinking will change as the project continues. Requirements development is an exploratory activity.

A business analyst is not simply a scribe who records what customers say. The BA is an investigator who asks questions that stimulate the customers’ thinking, seeking to uncover hidden information and generate new ideas. It’s fine for a BA to propose requirements that might meet customer needs, provided the customers agree that those requirements add value before they go into the product. A BA might ask customers, “Would it be helpful if the system could do?” The customer might reply, “No, that wouldn’t do much for us.” Alternatively, the customer might reply, “You could do that? Wow, that would be great! We didn’t even think to ask for that feature, but it would save our users a lot of time.”

This creativity is part of the value the BA adds to the requirements conversation. Just be careful that BAs and developers don’t attempt to define a product from the bottom up through suggested product features. It’s better to base the requirements on an understanding of stakeholder goals and a broad definition of success.

Cosmic Truth #3: Change happens.

It’s inevitable that requirements will change. Business needs evolve, new users or markets are identified, business rules and government regulations are updated, and operating environments change over time. In addition, the business need becomes clearer as the key stakeholders become better educated about what their true needs are.

The objective of a change control process is not to inhibit change. Rather, the objective is to manage change to ensure that the project incorporates the right changes for the right reasons. You need to anticipate and accommodate changes to produce the minimum disruption and cost to the project and its stakeholders. However, excessive churning of the requirements after they’ve been agreed upon suggests that elicitation was incomplete or ineffective—or that agreement was premature.

To help make change happen, establish a change control process. You can download an example of such a process from the Process Impact website. When I helped to implement a change control process in an Internet development group at Kodak, the team members properly viewed it as a useful structure, not as a barrier. The group found this process invaluable for dealing with its mammoth backlog of change requests.

Every project team also needs to determine who will evaluate requested changes and decide to approve or reject them. This group is typically called the change (or configuration) control board, or CCB. A CCB should write a charter that defines its composition, scope of authority, operating procedures and decision-making process. A template for such a charter also is available at the Process Impact website.

Nearly every software project becomes larger than originally anticipated, so expect your requirements to grow over time. According to consultant Capers Jones, requirements growth typically averages one to three percent per month during design and coding. This can have a significant impact on a long-term project. To accommodate some expected growth, build contingency buffers—also known as management reserve—into your project schedules. These buffers will keep your commitments from being thrown into disarray with the first change that comes along.

I once spoke with a manager on a five-year project regarding requirements growth. I pointed out that, at an average growth rate of two percent per month, his project was likely to be more than double the originally estimated size by the end of the planned sixty-month schedule. The manager agreed that this was plausible. When I asked if his plans anticipated this growth potential, he gave the answer I expected: No. I was highly skeptical that this project will be completed without enormous cost and schedule overruns.

When you know that requirements are uncertain and likely to change, use an incremental or iterative development life cycle. Don’t attempt to get all the requirements “right” up front and freeze them. Instead, specify and baseline the first set of requirements based on what is known at the time. A baseline is a statement about the state of the requirements at a specific point in time: “We believe that these requirements will meet a defined set of customer needs and are a suitable foundation for proceeding with design and construction.” Then, implement that fraction of the product, get some customer feedback, and move on the next slice of functionality. This is the intent behind agile development methodologies, the spiral model, iterative prototyping, evolutionary delivery, and other incremental approaches to software development.

Finally, recognize that change always has a price. It is never free. Even the act of considering a proposed change and then rejecting it consumes effort. Software people need to educate their project stakeholders so they understand that, sure, we can make that change you just requested, and here’s what it’s going to cost. Then the stakeholders can make appropriate business decisions about which desired changes should be incorporated and at what time.

Speaking of which, the next article in this series will present several cosmic truths about requirements and project stakeholders.

Read the Cosmic Truths about Software Requirements, Part 2.

Read the Cosmic Truths about Software Requirements, Part 3.

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.

Author
Recent Posts

Karl Wiegers