Requirements Engineering: What wheelbarrows and requirements have in common…

Integrated Requirements Engineering—the value of requirements management combined with Verification/Validation

Read the Lifecycle Insights eBook, “The Product Development Dilemma: Five Strategies for Product Development Leaders to Satisfy Product Requirements and Meet Delivery Deadlines.“

I did a design engineering internship at GE while working on my undergraduate engineering degree. Like most organizations, the first day on the job included a new employee orientation.The orientation materials included GE’isms that recounted many of the classic tales we already know about GE’s founder Thomas Edison—thousands of failed trials to get to a working light bulb;‘I have not failed, I’ve found 10,000 ways that won’t work’,‘Genius is 1% percent inspiration and 99% perspiration’, and others you’ve heard.In the back of the book was local GE’isms that included a story that hailed from when the plant was being constructed…

The story goes about a workman leaving the construction site every day with a wheelbarrow full of dirt. Security guards at the exit stopped and searched through the dirt looking for what he was trying to steal.Finding nothing they let him go… and thus it went every day with the workman leaving with a wheelbarrow full of dirt until at the final day of construction they gave up and asked what he was stealing.  His answer… Wheelbarrows.

Given the amount of time we spend on text-based requirements and requirements documents it’s easy to get confused between the content of requirements vs the container for requirements. I try to measure that confusion/maturity during my visits to various companies by asking engineers what their product is…if they reach down and pick up a stack of paper or show me a large PDF requirements document I know we have an engineer focused on the wheelbarrow and not the content.

During my time in high-tech, management realized we had more work to do than people to do it, which translated into a major drive to make everyone more productive. This was especially aimed at the people at the front-end of the lifecycle that defined the requirements that everyone else downstream used (they realized the critical first step for project success was to ensure the requirements were right). To see where they were, they commissioned a time/motion study on what these front-end people did to see where it could improve.They found:

• 50% of their time was spent generating/maintaining documents

• 25% of their time reentering the same information in different location in various documents, presentations, etc.

• 30% communicating those ideas to others (often the same meeting over and over)

• 14% of their time futzing (technical term for trying to get a document to print correctly)

…which adds up to greater than 100% (because these people were working much more than 40 hours/week trying to keep up).

Those of you that remember Michael Hammer and James Champy’s book on ‘Reengineering the Corporation’ (circa 1993) will recall the value mapping process where you captured your business processes and measured the time/effort being spent on those processes, then compared it with the value to the customer. If you found something you’re spending time on that the customer doesn’t value, that’s a candidate for elimination from your development processes.Applying the reengineering value principal to requirements, requirements specs/documents must be extremely valuable to customers given the amount of effort we put into them; except our analysis found no one reads them, they are obsolete as soon as you print them, given the amount of time spent on them there’s this tendency to believe if the documents are signed off, everything on the project must be ok, and more.So why do we spend so much time on something of such dubious value?

Most of it comes down to that’s how we get paid, prove compliance, interact with customers, etc.

Using our wheelbarrow analogy, what if we could focus on the content rather than the container and start managing individual requirements which are configured and applied as needed? We could significantly improve front-end productivity (i.e. think lean concepts of the waste of waiting for batch to fill; in this case a whole document waiting for review/approval until all requirements are gathered) and we can now access the main value of requirements by connecting the requirement into the development process so products are influenced by requirements all along the way.What we call integrated requirements…

One example of integrated requirements would be to connect requirements to their downstream verification and validation processes (after all one of the definitions of a good requirement is ‘verifiable’).

So imagine the productivity boost of this type of process… a requirement is defined related to the test cases that are reused to validate compliance with the requirement (test cases are also individually managed instead of a test document), requirements and their parameters are tied to program plans which inform us which requirements need to be validated for which milestone. Test/Validation execution is monitored with evidence gathered and associated with the requirement (giving line of site from requirement to validation and evidence).Experiences/issues/escapes are fed back to the front-end of the process where we use the existing program as the starting point (with all its experience captured) for the next cycle.

You’re thinking that’s way too much to bite off all at once, but there is value along the way…

For example, there is value in just related test cases to requirements, from our experience we found it’s not uncommon that:

• 30% of test cases have no sources—no requirements to validate, i.e. test creep; 30% unnecessary testing

• 25% of requirements are unverified—no test cases tied to requirements; not testing the right thing

It’s easy to say leave the wheelbarrow behind… but culturally it’s tough; especially if you have customers that expect document deliverables. Ok, we generate documents to deliver to them, but we are focused on configuring/managing individual requirements, reusing them over and over in many different programs, we think about requirements in a lean fashion (individual requirements are approved vs anti-lean waiting for a bunch of requirements to be approved in a document) and we now have line of sight from an individual requirement, to where it goes, how/when it was verified, its history, rationale, issues, et. al. for the next round allowing us to reuse/improve with each cycle.

Read the Lifecycle Insights eBook, “The Product Development Dilemma: Five Strategies for Product Development Leaders to Satisfy Product Requirements and Meet Delivery Deadlines.“

Learn more about requirements by reading our blog posts. Learn how you can get started with Teamcenter X on the cloud to quickly and cost-effectively take control of product information and processes, including requirements.