Ten Cosmic Truths About Software Requirements

Karl Wiegers
Aug 12, 2019 · 10 min read
Image for post
Image for post

I have been working in the field of software requirements and business analysis for about thirty years, as a practitioner, manager, consultant, trainer, and speaker. Having worked with more than 100 organizations of all sizes and types, I’ve observed some facts about requirements that appear to be universally applicable. This article (adapted from my book More About Software Requirements) presents 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.

The purpose of a software development project is to build a product that provides value to a particular set of customers. Requirements development seeks to determine the mix of capabilities and characteristics in a solution 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 a business analyst doesn’t adequately explore these expectations and craft them into a set of product features and attributes, the chance of satisfying customer needs is slim.

One technique for validating requirements is to work with suitable customer representatives to develop user acceptance criteria or acceptance tests. These criteria define how customers determine whether they’re willing to pay for the product or to begin using it to do their work. Acceptance tests aren’t a substitute for thorough system testing, but they do provide a valuable 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.

Elicitation is an exploratory activity. It includes some discovery and some invention, along with recording the requirements information customer representatives present. 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.

A business analyst is an investigator, not simply a scribe who records what customers say. An adroit BA asks questions that stimulate the customers’ thinking, 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. A BA might ask, “Would it be helpful if the system could do <whatever idea he has>?” The customer might reply, “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.

Cosmic Truth #3: Change happens.

Some people fear a “change control process.” The objective of such a process is not to inhibit change, but rather to ensure that the project incorporates the right changes for the right reasons. You need to anticipate and accommodate changes so as to produce the minimum disruption and cost to the project and its stakeholders. 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 manage change effectively, establish a rational and appropriate change control process. When I implemented such a process in a web development group once, 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.

Nearly every software project becomes larger than originally anticipated, so expect your requirements to grow over time. A growth rate of several percent per month can significantly impact 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 trashed with the first change that comes along.

Instead of attempting to get all the requirements “right” up front and freeze them in a classic waterfall approach, baseline the first set of requirements based on what is known at the time. A baseline is a statement about the requirements set at a specific point in time: “We believe these requirements will meet a defined set of customer needs and are a suitable foundation for proceeding with the next stage of design and construction.” Then implement the initial, top-priority set of requirements, get some customer feedback, and move on the next slice of functionality. This is the intent behind agile and other incremental approaches to software development.

Change 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 changes should be incorporated and when.

Cosmic Truth #4: The interests of all the project stakeholders intersect in the requirements process.

Image for post
Image for post
Figure 1. Some possible software project stakeholders.

The BA plays a vital communication role, interacting with all these stakeholders to specify a solution that will best satisfy all their needs, constraints, and interests. Identify your key stakeholder groups at the beginning of the project. Then determine which individuals can best represent the interests of each group. You can count on stakeholders having conflicting interests that must be reconciled. Therefore, identify the decision makers who will resolve these conflicts and have them agree on their decision-making process — before they confront their first significant decision.

Cosmic Truth #5: Customer involvement is the most critical contributor to software quality.

Customer involvement requires more than holding a workshop or two early in the project. Ongoing engagement by empowered and enthusiastic customer representatives is a critical success factor for software development. Following are some good practices for engaging customers in requirements development (see Software Requirements, Third Edition for more information about these practices):

Identify user classes. Customers are a subset of stakeholders, and users are a subset of customers. You can further subdivide your user community into multiple user classes that have largely distinct needs. Some might be favored user classes, whose needs are more strongly aligned with the project’s business objectives. Unrepresented user classes are likely to be disappointed with the project outcome.

Select product champions. You need to determine who will serve as the literal voice of the customer for each user class. I call these people product champions. Ideally, product champions are actual members of the user class they represent. Sometimes, though, you might need surrogates to speak for certain user classes to the best of their ability. When developers are forced to define user requirements, they often don’t do a great job.

Agree on customer rights and responsibilities. People who must work together rarely discuss just how they’ll collaborate. The BA should negotiate with the customer representatives early in the project to agree on the responsibilities each party has to the requirements process.

Build prototypes. Prototypes let user representatives interact with a simulation or a portion of the ultimate system. Prototypes are far more tangible than written requirements specifications and easier for users to relate to. However, prototypes aren’t a substitute for documenting the requirements details so everyone is working toward the same objective.

Cosmic Truth #6: The customer is not always right, but the customer always has a point.

  • Presenting solutions in the guise of requirements.
  • Failing to prioritize requirements or expecting the loudest voice to get top priority.
  • Not communicating business rules and other constraints, or trying to get around them.
  • Expecting a new software system to drive business process changes.
  • Not supplying appropriate representative users to participate in requirements elicitation.
  • Failing to make timely decisions when a BA or developer needs an issue resolved.
  • Not accepting the need for trade-offs in both functional and nonfunctional requirements.
  • Demanding impossible commitments.
  • Not accepting the cost of change.

The customer might not always be right, but the BA needs to understand and respect whatever point each customer is trying to make through his request for certain product features or attributes. Rather than simply promising anything a customer requests, strive to understand the rationale behind the customer’s thinking and conceive an acceptable solution.

Cosmic Truth #7: The first question to ask about a proposed new requirement is “Is this in scope?”

To minimize scope creep, the project stakeholders must first agree on a scope definition, a boundary between the desired capabilities that lie within the scope for a given product release and those that do not. Then, whenever some stakeholder proposes some new functionality the BA can ask, “Is this requirement in scope?” If the answer is “no,” then either defer (or reject) the requirement or expand the project scope, with the associated implications of cost and schedule increase. A poorly defined scope boundary is an open invitation to scope creep.

Cosmic Truth #8: Even the best requirements document cannot replace human dialog.

A set of written requirements is still valuable and necessary, though, whether stored in a document, a spreadsheet, a requirements management tool, or some other form. A documented record of what stakeholders agreed to at a point in time — a group memory — is more reliable than human memories, and it can be shared with people who weren’t privy to the original discussions.

The requirements specifications need more detail if you won’t have opportunities for frequent conversations with users and other decision makers. This happens when you’re outsourcing the implementation of a requirements set your team created. Expect to spend considerable time on review cycles to clarify and agree on what the requirements mean in those situations.

Cosmic Truth #9: The requirements might be vague, but the product will be specific.

People sometimes are comfortable with vague requirements. Customers might like them because it means they can redefine those requirements later on to mean whatever they want them to mean. Developers sometimes favor vague requirements because they allow them to build whatever they want to build. This is all great fun, but it doesn’t help you create high-quality solutions.

Ultimately, you are building only one product, and someone needs to decide just what that product will be. Customers and BAs who don’t make the decisions force developers to do so, though they likely know far less about the problem or the business. Precise requirements, however represented and communicated, lead to a better shared expectation of what you’ll have at the end of the project.

Cosmic Truth #10: You’re never going to have perfect requirements.

Striving for perfection can lead to analysis paralysis, which can have a backlash effect. Stakeholders who have been burned once by a project that got mired in requirements issues sometimes are reluctant to invest in requirements development at all on their next project. This is an even more certain path to failure.

You don’t succeed in business by writing a perfect set of requirements. Practically speaking, strive to develop requirements that are good enough to allow the team to proceed with design, construction, and testing at an acceptable level of risk. The risk is the threat of having to do expensive and unnecessary rework. Keep this practical goal of “good enough” in mind as you pursue your quest for quality requirements.

===========

If you’re interested in requirements and business analysis, Process Impact provides numerous useful publications and other resources.

Analyst’s corner

We are passionate about helping businesses do their job better!

Sign up for Top business analysis stories

By Analyst’s corner

A curated collection of recent stories from the Analyst's corner. Never miss an insightful article worth reading! Take a look

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Karl Wiegers

Written by

I’ve written on software development and management, consulting, self-help, chemistry, military history, and a mystery novel. More info at karlwiegers.com.

Analyst’s corner

All aspects of organisational analysis: business analysis | enterprise architecture | quality

Karl Wiegers

Written by

I’ve written on software development and management, consulting, self-help, chemistry, military history, and a mystery novel. More info at karlwiegers.com.

Analyst’s corner

All aspects of organisational analysis: business analysis | enterprise architecture | quality

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store