The 6 Most Important Requirements Practices

The TL;DR for a 640-page book on software requirements

Karl Wiegers
Analyst’s corner
Published in
7 min readJun 1, 2022

--

A stack of three thick books on software requirements.
Photo by Author

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 (plus the sequels describing six more practices, four additional practices, and a final set of four practices). This article is adapted from Software Requirements Essentials: Core Practices for Successful Business Analysis by Karl Wiegers and Candase Hokanson.

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…

--

--

Karl Wiegers
Analyst’s corner

Author of 14 books, mostly on software. PhD in organic chemistry. Guitars, wine, and military history fill the voids. karlwiegers.com and processimpact.com