For more than 35 years I’ve been learning, applying, and teaching about ways that software teams can improve how they develop and manage their product requirements. I’ve observed six requirements-related themes that pertain to every project, regardless of what you’re building or how you’re executing the project. Keep the following…

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. …

Open-ended questions can stimulate creative thinking during requirements elicitation or in any other discussion. — “What do you want?” is hardly the most useful question a business analyst (BA) can ask during a requirements elicitation discussion. Sure, you’ll get some answers, but they’ll likely just skim the surface. …

A business analyst is not simply a scribe, dutifully recording whatever stakeholders say they need. The shrewd BA asks “why” a lot. — During a software reengineering project, a business analyst (BA) named Dawn asked one of the developers why a utility company fee calculation was being performed a certain way in the existing system. “A government statute dictates how we have to calculate those fees,” was the reply. Upon investigation, Dawn discovered…

You’re going to die eventually. Make things easier for your family by organizing essential information before they need it. — I’m going to die. So is my wife, Chris. Probably not real soon; maybe not for 20 or more years (we are in our early 70s). But we’re both going to die. Perhaps at the same time, more likely not. And when either or both of us are gone, someone…

These 20 practices can help make any project more successful and less painful. — Managing software projects is challenging under the best circumstances. The team must balance competing stakeholder interests against the constraints of limited resources and time, ever-changing technologies, and unachievable demands from unreasonable people. Project management involves managing people, technologies, risks, requirements, expectations, suppliers, and more. …

A group estimation method can yield more meaningful predictions than any one individual can produce — Most software professionals must provide estimates for their work, but few of us are skillful estimators. Many of us haven’t been trained in estimation techniques. We’re too optimistic, with short memories that mask the painful overruns from previous projects. We don’t incorporate contingency buffers to accommodate unexpected events or risks…

These tips might keep your outsourced or packaged solution projects from winding up in litigation. — Many companies outsource their software development projects, often to offshore suppliers. Others are replacing custom green-field development with commercial package solutions, which they — or the vendor— must customize, extend, and integrate into their application environment. Failed outsourced or contracted package projects sometimes result in lose-lose litigation. …

Why do we persist in maintaining that the customer is always right, when we all know that isn’t true? — Perhaps you’ve patronized a business that had a sign on the wall saying something like: “We have only two rules. Rule #1: The customer is always right. Rule #2: If the customer is wrong, see Rule #1.” It’s fashionable to say that the customer is always right. But I’ve seen…