Cosmic Truths about Software Requirements, Part 3

In the previous two articles in this series I have shared some “cosmic truths” about requirements concepts in general and about how requirements affect the project stakeholders. This closing article in the series, adapted from my book More about Software Requirements, presents four more universal truths regarding requirements specifications.

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

Anyone who’s been in IT for long has worked on a project that has suffered from scope creep. It is normal and often beneficial for requirements to grow over the course of a project. Scope creep, though, refers to the uncontrolled and continuous increase in requirements that makes it impossible to deliver a product on schedule.

To control 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 a new functional requirement, feature, or use case, the BA can ask, “Is this in scope?” To help answer this question, some project teams write their scope definition on a large piece of cardstock, laminate it, and bring it to their requirements elicitation discussions.

If a specific requirement is deemed out of scope one week, in scope the next, then out of scope again later, the project’s scope boundary is not clearly defined. And that’s an open invitation to scope creep.

Cosmic Truth #8: Even the best requirements document cannot—and should not—replace human dialog.

Even an excellent requirements specification won’t contain every bit of information that developers and testers need to do their jobs. There will always be tacit knowledge that the stakeholders assume—rightly or wrongly—that other participants already know, along with the explicit knowledge that must be documented in the requirements specification. BAs and developers will always need to talk with knowledgeable users and subject matter experts to refine details, clarify ambiguities, and fill in the blanks. This is the rationale behind having some key customers, such as product champions, work intimately with the BA and developers throughout the project. The person performing the role of BA (even if this is one of the developers) should coordinate these discussions to make sure that all the participants reach the same understanding so the pieces all fit together properly. A set of written requirements—whether stored in a document, a requirements management tool, or some other form—is still valuable and necessary, though. A documented record of what stakeholders agreed to at a point in time—a “group memory”—is more reliable than human memories.

You need to include more detail in the requirements specifications if you aren’t going to have opportunities for frequent conversations with user representatives and other decision makers. A good example of this is when you’re outsourcing the implementation of a requirements specification your team created. Expect to spend considerable time on review cycles to clarify and agree on what the requirements mean. Also expect delays in getting questions answered and decisions made, which can slow down the entire project.

This very issue was a major contributing factor in a lawsuit I know of between a software package vendor and a customer. The vendor allowed no time in the schedule for review following some requirements elicitation workshops, planning to begin construction immediately. Months later, numerous key requirements issues had not yet been resolved and the project status didn’t remotely resemble the project plan.

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

Specifying requirements precisely is hard! You’re inventing something new, and no one is exactly sure what the product should be and do. 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 the developers to build whatever they want to build. This is all great fun, but it doesn’t lead to high-quality software.

Ultimately, you are building only one product, and someone needs to decide just what that product will be. If customers and BAs don’t make the decisions, the developers will be forced to. This is a sign that the key stakeholders are abdicating their responsibility to make requirements-level decisions, leaving those decisions to people who might know far less about the problem or the business.

Don’t use uncertainty as an excuse for lack of precision. Acknowledge the uncertainty and find ways to address it, such as through prototyping. A valuable adjunct to simply specifying each requirement is to define fit criteria that a user or tester could employ to judge whether the requirement was implemented correctly and as intended. Attempting to write such fit criteria will quickly reveal whether a requirement is stated precisely enough to be verifiable. See Suzanne Robertson and James Robertson, Mastering the Requirements Process, Third Edition (Addison-Wesley, 2013) for more information about fit criteria.

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

Requirements are rarely finished or complete. There is no way to know for certain that you haven’t overlooked some requirement, and there will always be some requirements that the BA won’t feel are necessary to record. Rather than declaring the requirements “done” at some point, define a baseline, a snapshot in time that defines an agreed-upon foundation for subsequent work and modifications. Once you’ve established a baseline, follow your change control process to modify the requirements, recognizing the implications of making changes. It’s folly to think you can freeze the requirements and allow no changes after some initial elicitation activities.

Striving for perfection can lead to analysis paralysis. Analysis paralysis, in turn, 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 quicker path to failure.

You don’t succeed in business by writing a perfect specification. From a pragmatic perspective, strive to develop a set of 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. Have team members who will need to base their own work on the requirements review them to judge whether they provide a suitably solid foundation for that subsequent work. Keep this practical goal of “good enough” in mind as you pursue your quest for quality requirements.

Don’t forget to leave your comments below.