The TL;DR for a 640-page book on software requirements
Photo by Karl Wiegers
Authors sometimes make things longer and more complicated than necessary. Some readers might feel that I’ve been guilty of this myself. The third edition of my book Software Requirements, co-authored with Joy Beatty, is about 245,000 words long, nearly 640 pages in a rather small font. Maybe that seems like overkill, but to be fair, the requirements domain is large and complex.
Books like Software Requirements, Mastering the Requirements Process by Suzanne and James Robertson, and the IIBA’s Business Analysis Body of Knowledge describe dozens of valuable techniques for requirements elicitation, analysis, specification, validation, and management. They’re all useful when thoughtfully applied in appropriate situations. But if you don’t have time to wade through these large volumes, you might like this TL;DR version of the six most important requirements practices that every project team should perform.
Practice #1: Define Business Objectives
Organizations undertake a project to solve a problem, exploit a business opportunity, or create a new market. Defining the project’s business objectives communicates to all participants and other stakeholders why they are working on the project. The organization could hope to achieve both financial and non-financial business objectives with the new product. Try to quantify the business objectives, and make them measurable, with statements like these:
- Capture a market share of X percent within Y months.
- Reach a sales volume of X units or revenue of $Y within Z months.
- Save X dollars per year currently spent on a high-maintenance legacy system.
Using business objectives aligns all of the team’s work and key decisions. Without defined business objectives, you can’t craft a clear product vision statement or establish the scope of either the entire project or any development increment. The team can’t make good decisions about scope changes or proposed functionality unless they know how those changes match up with the business objectives. Keeping the scope in focus helps the team avoid scope creep while still adapting to changing business realities. And how can you know if the project was a success unless someone defined measurable business objectives and success criteria up front?
Practice #2: Understand What Users Need to Do with the Product
I strongly advocate taking a usage-centric approach to requirements development and solution design, rather than a feature- or product-centric approach. Understanding the tasks that users need to perform and the goals they want to achieve lets the business analyst (BA) derive the functionality that developers must implement. When you focus on exploring features rather than user goals, it’s easy to overlook some necessary functionality. It’s also easy to include functionality that seems cool but doesn’t help users get their jobs done. Use cases are an effective technique for maintaining this usage-centric mindset.
Seeking to understand what users need to do with the product implies several other important BA activities, including these:
- Identifying a wide range of project stakeholders
- Characterizing distinct user classes that have largely different requirements
- Identifying individuals to serve as the voice of the customer for each user class (product champions)
- Selecting appropriate requirements elicitation techniques to engage with users
- Establishing decision-making processes to resolve conflicts and priorities across user classes
- Building and evaluating prototypes or early releases to stimulate user feedback
Practice #3: Prioritize the Requirements
I doubt that any project has ever implemented every bit of requested functionality. Even if you could implement it all, you can’t do it all at once. Your goal is to deliver the maximum business value to your customers at the lowest cost and in the shortest time. Achieving this goal demands that you prioritize requirements so the team can work on them in the most appropriate sequence.
Prioritization involves considering how much each proposed requirement contributes to achieving the project’s business objectives. Prioritizing requirements lets the team decide which of the work items remaining in the backlog to defer or omit because of time and resource constraints. There are numerous requirements prioritization techniques available, including these:
- Pairwise comparison and rank ordering
Some of these methods take more effort than others, but those methods also help the project manager or product owner make finer-grained choices. Choose any technique that lets the right stakeholders make good business decisions throughout the project to avoid a frantic “rapid descoping phase” late in the game.
Practice #4: Explore Nonfunctional Requirements
People naturally focus on a product’s functionality when discussing requirements, but those are only part of the solution. Nonfunctional requirements contribute heavily to user satisfaction and suitability for use. When speaking of nonfunctional requirements, people most commonly think of quality attributes, sometimes called the “-ilities.” These product characteristics include usability, maintainability, security, reliability, and many others. To help designers devise the most appropriate solution, BAs need to discuss nonfunctional requirements as part of requirements elicitation.
Developers don’t directly implement requirements concerning safety, reliability, portability, security, or other characteristics. Instead, these attributes serve as the origin of many functional requirements and drive design decisions. Table 1 indicates the likely categories of technical information that different types of quality attributes will generate.
Table 1. Translating quality attributes into technical specifications
(from Software Requirements, 3rd Edition, by Karl Wiegers and Joy Beatty)
Another challenge is that it’s not possible to optimize all of the desired quality factors at once. Designers must make trade-off decisions among the various attributes. Therefore, the team needs to determine which ones are most important to customer success and optimize those. Carefully specifying quality attributes lets you build a product that delights its users, beyond merely doing what it’s supposed to.
Practice #5: Review the Requirements
How do you know if your requirements are accurate? How can you tell if they’re clear enough so all the team members know what to do with them and other stakeholders know what to expect in the solution? No matter how you choose to represent requirements knowledge, it is sometimes ambiguous, incomplete, or simply incorrect.
One of the most powerful quality practices available is peer review of requirements. Convene some colleagues to review both textual requirements and diagrams. Different project participants — BAs, designers, developers, testers, users — will find different kinds of problems during these reviews. Requirements reviews pose some particular challenges. Rather than simply inviting people to look over the requirements, provide some training so reviewers know how to participate effectively and can find as many issues as possible.
A related requirements validation practice is to write conceptual tests based on requirements. Testing requirements is something you can do early in each development cycle to reveal many errors before they are cast into code. Requirements and tests are complementary views of the same knowledge. Requirements describe how the product should behave under certain conditions; tests describe how to tell if it’s exhibiting the correct behaviors.
Practice #6: Plan for Requirements Change
No matter how well you understand the problem and how carefully you prepare the requirements, they won’t be perfect, complete, or static. The world changes around us as we work. New users and new ideas appear. Business rules surface and evolve. Projects inevitably grow beyond their originally envisioned scope. Every team must anticipate requirements changes and establish mechanisms for dealing with them without derailing the team’s commitments.
When you know the project outcome is incompletely defined and likely to change a lot, an incremental, agile approach is a good way to cope with it. You plan to build the requirements — and the solution — in a series of small chunks, expecting the direction to change and accepting the uncertainty of what you’ll have at the end and when you’ll have it.
When the likely degree of change is less extreme, plan to accommodate some growth (along with risks, imprecise estimates, and unexpected events) by building contingency buffers into development schedules. Establish a requirements change process so the right people can get the right information to make good business decisions about which proposed changes to incorporate to add value with minimal disruption. Don’t use the expectation of change as a justification for skimping on requirements thinking, though. Excessive requirements churn often indicates that objectives were unclear or the elicitation approach wasn’t effective.
Neglect These Practices at Your Peril
Of course, there are many other valuable requirements activities besides these six. However, these practices greatly increase your chances of building a solution that achieves the desired business outcomes efficiently and effectively. Applying them doesn’t guarantee success for any BA, product owner, or product manager. But neglecting them likely ensures failure.
Author: Karl Wiegers, Principal Consultant at Process Impact
Karl Wiegers is the author of numerous books on software development and other topics, including Software Requirements, More About Software Requirements, Peer Reviews in Software, and The Thoughtless Design of Everyday Things. His most recent book is Software Development Pearls. Karl is the Principal Consultant at Process Impact.