The TL;DR for a 640-page book on software requirements — 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…

Before you adopt the hottest new development method as a magic bullet, find out why you aren’t already getting the results you seek. — I have never met anyone who could honestly say “I am building software today as well as software could ever be built.” Individuals, teams, and organizations should all be continually looking for better ways to do our work. Frustration with disappointing results is a powerful motivation for trying a different…

A focus on understanding users and their usage is the best key to success — I first learned to program computers in college in 1970. Since then, I’ve performed many roles in software engineering: coder, designer, business analyst (BA), tester, project manager, documentation writer, team manager, process improvement leader, consultant, trainer, and author. Plus, of course, like all of us, I’m a user.

Absorb knowledge from other people’s experiences instead of slowly climbing every painful learning curve yourself — Anyone who cannot truthfully say, “I am building software today as well as software could ever be built,” would benefit from learning better ways to work. Experience is the form of learning that sticks with us the best. It’s also the slowest and most painful way to learn. …

These business analysis activities help a team lay a foundation for success, define and document the right solution, and steer the development process. — Previous articles described sixteen of the most important requirements practices that every software team should perform: the first six, the next six, and four more. These practices apply regardless of the development approach the team is taking, the application domain, or the kind of product they’re building. Here are an…

Do you know of any software team that wouldn’t benefit from these practices? It’s unlikely. — Two previous articles described the six most important requirements practices that every software team should perform, as well as six more important requirements practices. Here are four more core practices that, again, virtually every software or systems development project will find valuable. This article is adapted from Software Requirements Essentials…

Inadequate impact analysis of change requests can lead to surprises. Software surprises are rarely good news. — Two developers estimated that it would take one month to add a requested major enhancement to one of their information systems. The customer approved the estimate, and the developers set to work. After two months, the enhancement was only about half done. The customer lost patience. They said, “If I’d…

Drawing diagrams of business problems and software systems is a powerful aid to requirements development. — Software systems can be enormously complex. One way people deal with complexity is through abstraction. Abstraction allows us to represent information at varying levels of detail, depending on how much information any particular audience needs — and can handle — at some point in time. Visual analysis models provide a…

Requirements aren’t lying around waiting for the business analyst to collect them. Requirements elicitation is a more accurate term. — People often speak of gathering requirements on a software project, but this conveys an inaccurate impression. The word gathering suggests that the requirements are lying around out there somewhere, just waiting for the business analyst (BA) or product owner to collect them. When I hear someone say “gathering requirements,” I…