Accendo Reliability

Your Reliability Engineering Professional Development Site

Accendo Reliability

Reliability Engineering Professional Development
  • About
    • Adam Bahret
    • Andre Kleyner
    • Anne Meixner
    • Ash Norton
    • Carl Carlson
    • Chris Jackson
    • Chris Stapelmann
    • Dennis Craggs
    • Doug Plucknette
    • Fred Schenkelberg
    • Greg Hutchins
    • James Kovacevic
    • James Reyes-Picknell
    • John Paschkewitz
    • Katie Switzer
    • Kevin Stewart
    • Kirk Gray
    • Les Warrington
    • Mike Konrad
    • Mike Sondalini
    • Perry Parendo
    • Rob Allen
    • Robert Kalwarowsky
    • Steven Wachs
    • Tim Rodgers
  • Reliability.fm
    • Dare to Know
    • Speaking Of Reliability
    • Rooted in Reliability: The Plant Performance Podcast
    • Rob’s Reliability Project
    • Practical Reliability Podcast
    • Reliability Matters
    • Accendo Reliability Webinar Series
    • Asset Reliability @ Work
  • Articles
    • CRE Preparation Notes
    • on Leadership & Career
      • Advanced Engineering Culture
      • Engineering Leadership
      • Managing in the 2000s
      • Product Development and Process Improvement
    • on Maintenance Reliability
      • Conscious Asset
      • Maintenance and Reliability
      • Plant Maintenance
      • RCM Blitz®
    • on Product Reliability
      • Accelerated Reliability
      • Achieving the Benefits of Reliability
      • Apex Ridge
      • Musings on Reliability and Maintenance Topics
      • Reliability in Emerging Technology
    • on Risk & Safety
      • CERM® Risk Insights
    • on Tools & Techniques
      • Big Data & Analytics
      • Experimental Design for NPD
      • Inside FMEA
      • Testing 1 2 3
      • Reliability Reflections
  • eBooks
    • Reliability Engineering Management DRAFT
  • Resources
    • Accendo Authors
    • FMEA Resources
    • Feed Forward Publications
    • Books
    • Webinars
    • Journals
    • Higher Education
    • Podcasts
  • Groups
    • Reliability Integration
    • Mastermind
    • Study Groups
  • Courses
    • 14 Ways to Acquire Reliability Engineering Knowledge
    • SPC-Process Capability Course
    • 5-day Reliability Green Belt ® Course
    • 5-day Reliability Black Belt ® Course
    • CRE Preparation Course
    • RAMwright Courses
  • Webinars
    • Upcoming Live Events
  • Calendar
    • Call for Papers Listing
    • Upcoming Webinars
    • Webinar Calendar
  • Login
    • Member Home

by Robert Allen Leave a Comment

Agile Requirements Discovery and Validation

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.

Filed Under: Articles, on Leadership & Career, Product Development and Process Improvement Tagged With: agile product development, agile product validation, customer value, Human Resource Management, lean product development, Lean Project Management, New Product Development, portfolio analysis, project approval committee, project governance, Project Management, requirements management

« The Actions To Accelerate Your Culture Change
Anchoring Methodology Presentation at Applied Reliability and Durability Conference ARDC 2018 »

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Articles by Rob Allen
in the Product Development and Process Improvement series

Join Accendo

Receive information and updates about articles and many other resources offered by Accendo Reliability by becoming a member. It’s free and only takes a minute.

Join Today

Stay in touch with Rob and improve your product and processes.

You will receive occasional emails with announcements, recent articles, and maybe a question or two.

Recent Posts

  • Benefits of Comparing DMAIC with Project Management
  • The Rover Says Good Bye! :(
  • 100% Inspection
  • Don’t Need a Science Project
  • Don’t Forget to Subscribe to our Weekly Email Updates!

© 2019 FMS Reliability · Privacy Policy · Terms of Service