Agile Requirements Discovery and Validation

Many companies pursue a product development strategy that provides a product (or service) which meets customer needs sooner (rather than later), and then makes adjustments after the product has been fielded.

Pursuing this approach means accepting the associated risks.  What if a critical to quality or critical to reliability characteristic fails to meet customer needs?  A product could fail miserably by eliminating important product development work scope and accelerating time-to-market.  By the time an adjustment or “pivot” can be made it may be too late, or too costly to correct.

Risk reduction can be enabled through an agile requirements discovery and validation approach.

For example, in agile for software, validation can include the “actual product”, where a software change is made and can be shown to an internal customer (usually a product manager).  This enables developers to essentially ask the customer “is this the functionality you requested?” and then finalize the software development/release.   Essentially the developer is directly validating the design (although requirements should still be written to ensure functional outputs and inputs are well-understood).  Often the new functionality is a small development increment (part of the software development sprint).

Smaller development increments might not be practical for a new complex system, however.   A complex system may use a waterfall product development approach oriented around effectively managing and controlling larger ‘batches’ of product development information and work scope (ie. system requirements, system design, component requirements, component design, interface control documentation, etc).

We can still enable some of the benefits of agile with a batch/waterfall product development process, however.  One approach is to emphasize early product validation through simulations and emulations.

Let’s use the example of a drone that envisioned to do a specific, remote piloted task.  The validation approach might involve a simulation of the drone as it is exercised before, during and after it’s task.  What would the user see while remotely piloting the vehicle?  What controls could be included, and what functions would (or could) be remotely performed, etc?  This isn’t validation with the actual product, but a simulation for the purposes of understanding customer needs, validating the use cases and system requirements.  A physical, non-functional or (semi-functional) model may also help to understand size, space or other constraints, customer needs or user interface considerations.

In this example, we’re enabling an agile approach (via the simulation) which includes a detailed validation through understanding of customer needs, use cases and requirements.  The simulation can be improved through exercising the simulation with the customer, implementing the changes and then revalidating.  The (validated) simulation (or simulation results) is closely tied to the product design & development process through requirements management.

To pursue an agile requirements discovery and validation process while mitigating the associated risk, some questions to consider:

• Are critical-to-quality requirements identified, and are requirements that determine system architecture finalized? Conversely, are we able to implement an improved understanding of customer needs and requirements without major design changes? (These questions help determine minimum viable product.)
• Can new, validated requirements be incrementally added (or clarified) with rapid, incremental releases and tracked in a change control and requirements backlog process? (This way, changes can be documented, prioritized and held for a future design release.)
• Is there a component of the system, user-interface or physical model that can enable some form of early validation?

Rather than wait for the customer to determine adjustments after the product is fielded, an agile requirements discovery and validation framework can provide a more structured, lower risk approach while still accelerating time-to-market.