The purpose of product / software requirements is to identify the true needs of the product and bring these requirements to life by engineering the software properly, the first time. Requirements are a best practice of quality software engineering and extremely vital to project success. Without an organized and concise format, a non-technical project champion will not be able to understand the vision and goals set forth resulting in poor moral, lack of upper management support, and possible project failure.

When project and/or software requirements are missing or written poorly, this can come at a significant cost. Poor requirements management can result in the product failing once launched to the market. Perhaps the product is launched with each requirement fulfilled; however, the product is years late to the market. Cost overruns, field and service issues, difficulty to enhance and maintain, inflexible designs, and significant redevelopment (for next generation products) are all reasons to create sound requirements from the start of the project.

Characteristics of Good Requirements

Examples of Requirements Language

Utilize consistent language, for example:

• “Shall” is mandatory
• “Should” is optional, but omission must be justified
• “May” is desired (future requirements)

Utilize consistent terminology

• Define terms – use a Glossary
• Avoid using the same name for different things
• Avoid using different names for the same things
• Always define the object first!

Anatomy of a “Good” Requirement

Putting this into Practice (Example)

You are responsible for bringing a new animal to market. Begin by creating a work breakdown structure (WBS) to define your animal:

Get more specific:

Even more specific, utilizing best practices such as good characteristics and consistent language:

What do you get? A PLATYPUS!

Want to learn more about creating product and/or software requirements?