The Requirements: A Love Story

“I know that you believe that you understand what you think I said but I am not sure you realize that what you heard is not what I meant.” -Robert McCloskey, former U.S. State Department spokesman

Regardless of how your software project is organized, how it is being run, or what you are building, sooner or later everyone involved is going to come to terms with The Requirements: that collection of all the requests, specifications, expectations, hopes, dreams, and desires of what the product is supposed to do.  The Requirements provide everyone on the team something they need. They tell the architects, designers, and developers what to construct; provide the testers the basis for verifying what was constructed; and help the end users and business stakeholders validate what they really wanted in the first place. And everyone wants The Requirements in a hurry, with the least amount of effort and overhead.

Choosing a Global Software Development Partner to Accelerate Your Digital Strategy

To be successful and outpace the competition, you need a software development partner that excels in exactly the type of digital projects you are now faced with accelerating, and in the most cost effective and optimized way possible.

Get the Guide

The Requirements represent the “single truth,” regardless of whether they are written, stated, demonstrated, or wished upon a star. The format is simply the means to an end:  use cases, user stories, IDEF0, UML, SRS, an email, 100 emails, a hallway conversation, a wiki page, or the back of the napkin. The means and method vary, but knowing when you have The Requirements has been a classic engineering issue for decades.   In fact, this is such a timeless concern that the IEEE went so far as to write a standard on the subject: IEEE 830-1998 – IEEE Recommended Practice for Software Requirements Specifications.

Now, before you write this off as overly bureaucratic and stuffy, let me help you skip ahead to the good part (the part you can use when you’re done reading this blog post).

Section 4.3, entitled Characteristics of a Good SRS, is a fantastic yardstick for evaluating The Requirements on your project.  It’s also a great tool for getting your team to agree on what comprises good requirements in the first place. Good requirements are:

• Correct
• Unambiguous
• Complete
• Consistent
• Ranked
• Verifiable
• Modifiable
• Traceable

Over the next few posts, I will elaborate on how these characteristics can improve The Requirements on your project.   Like anything, be reasonable and use common sense. But what is reasonable? Sorry, there isn’t an IEEE standard for that.