Requirement Driven Development (RDD) focuses on the attributes of a product the dev team needs to keep top-of-mind as they work. Clients and key stakeholders propose the requirements and the contractor refines them, talking with the client back and forth throughout development. In order to do this successfully, features must be constantly tested and requirements vetted through formal testing and evaluation. The purpose of a formal Test and Evaluation (T&E) program is to accomplish two goals; verification of the build components and validation of the program objectives. The easiest way to distinguish these goals is to remember the following:

• Verification tests whether you built the thing right
• Validation tests whether you built the right thing

First Comes Validation

Validation is a crucial step at every stage of a program to ensure a client can do three things. They need to understand what is being built, agree with what is being built, and benefit from what is being built. With a comprehensive and effective validation process, everyone will be happier and more satisfied with the outcomes of a development program. Engineers will be happy that they are not rebuilding products which weren’t well specified in the beginning. Clients will be happy that the delivered product is what they expected.

Requirements are the first target of validation efforts on a development program. Clients need to know what to expect from the product. The best way to accomplish this is through clearly written requirements the client understands.

One of the most fundamental guidelines for a successful T&E program is “the evaluation comes before the test”. In the simplest terms, this means know what you’re building before you start building it. Validate requirements at every step so you know what you’re building and how to test it.

Then Comes Verification

As software developers, we understand verification well. Countless articles written over the past fifty years are around the concept of verification testing. Any time you read about component testing, contract testing, unit testing, testing in isolation, or mocking and stubbing; you’re reading about verification. This is the process that a contractor takes on to ensure that they have completed their work according to the specification as they understand it.

Test Driven Development (TDD) is the process for meeting the verification needs of a software project. The goal of writing tests before writing code is the “evaluation before the test” for software.

Then Comes Validation (Again)

Verification, though, only covers half of the evaluation landscape, and unfortunately, it’s the easier half. No matter how well developers built a thing, much of that effort is wasted if they haven’t built the right thing. RDD achieves the same goals as TDD does for verification but for validation instead. A rigorous RDD process helps minimize wasted effort.

Verification is the responsibility of the contractor, whereas validation is the responsibility of the client. No one other than the client can determine if a product will meet their needs. This process, called User-Acceptance Testing, occurs at the end of the development. Like verification testing, this type of validation is well understood. Also, like verification, this only accounts for a portion of needed T&E efforts.

… and Repeat

Requirements are not written in stone. Clients will change their mind. Planned features will not work as expected. The project landscape is ever evolving, and an iterative RDD process is necessary in coping with changes. When the client changes requirements, validate again. Change your verification strategies to account for the updated requirements. When the work to meet the requirements is done, re-test, re-verify, re-validate.

Importance of Understanding the Client

The purpose of the requirements in RDD is to explain what the product is meant to do and how an end user will accomplish their use case. Use clear, unambiguous language to reduce the risk of misinterpretation when forming these requirements. Unfortunately, as is often the case, clients will have difficulty in expressing requirements in this way. Your client immerses themself in their business day after day. Often, concepts perfectly clear to them cause confusion to anyone who is not as ingrained in the business.  

As software contractors, quickly learning about our clients’ businesses and what needs the product will fulfill is an essential skill. Product architects and business analysts most often carry out this task.

Avoid rushing through this process in order to “get to the real work”. You gain valuable information working with the client to fully understand their requirements and how those requirements relate to the business.

Identifying and Gathering Requirements

The following actions will help to ensure success in the requirements gathering process:

Help write requirements.

If a client finds the process of expressing their requirements difficult, sit with them to write requirements until they capture the needs of the business.

Maintain a glossary.

Often, common words take on different meanings in different industries or even different contexts within the same business. Keep track of these definitions so that everyone in the program can refer to them.

Reduce overloaded terminology.

If a word can take on multiple meanings, ask the client if it’s possible to use different terms to reduce ambiguity. If no other terms fit, provide clear context around the word for user understanding.

Iterate.

Just like in a development process, multiple iterations of requirements gathering will be beneficial. Because it’s their everyday experience, clients will skip over steps in their process that they consider to be inconsequential. Sometimes these “inconsequential” steps will be vital to the success of the business process.

Ask Leading Questions.

Asking yes/no process-based questions and asking for quantitative measurements of each step are both very important, but, even more, questions that will lead the client into a discussion of the process will reveal details that they may have skipped over.

Stay Focused on the Business Needs.

Technologists tend to focus on a technical problem before identifying a business problem. The technical requirements for a program will come later. Ensure understanding of the business case first, before seeking a solution.

Ask For Acceptance.

Just as user-acceptance is necessary for the final version of a product, user-acceptance is necessary for written requirements.

Requirements Lead to Success

Much like a developer writing unit tests before writing functionality, the contractor’s responsibility in validation comes at the beginning of the RDD process. Gathering requirements and guiding the client through the validation of those requirements is the goal of the first phase of any program. Good requirements will lead to a more efficient and effective development effort, reducing costs and improving the satisfaction of both your clients and the developers on your team.