The Case of the Missing Requirement

By: Larry Randall

The NRE? Group

A rancher lamented that one of his prize bulls was stranded on an island in a river that had risen rapidly. He said the water had stopped rising, but that it was impossible to bring the bull across the rope bridge that he had managed to build to take food to the bull.

The rancher was somewhat surprised when a shop owner said that it was possible to bring the bull over the bridge. “How?”, asked the rancher. “You can make him into steaks, and bring those back.”, replied the shop owner “I need him alive”, responded the rancher. “Now, you are adding constraints”, laughed the shop owner.

The point of the story is that the rancher had a Requirement – Get the bull off the island. The shop owner produced a valid solution – convert the bull into manageable chunks. Only after the solution was presented did the rancher add a Constraint – the bull had to remain alive. That Constraint was a KEY requirement – but it was not stated. Because it was not stated, it was not considered.

We can be reasonably certain that the shop owner knew of the constraint, and simply wanted to have a laugh at the rancher’s expense – however, too often business and product development projects have gone awry for the simple reason that Constraints and/or key Requirements were not captured. Because they were not captured, they were not considered. Because they were not considered, the projects went “off the rails”.

Whether “Process Development or Improvement” or “Product Development” is our goal, the Capture, Vetting, and effective Management of Requirements are critical to success. The key parts of Requirements Management are:

• Capture of User Requirements (including interface(s) – whether physical, software, or operational)
• Capture of Functional Requirements (including all Constraints)
• Recording of the Origin of each requirement (preferably the person, otherwise the entity)
• Ranking of each requirement (e.g., 1 = “Nice to have”, 10 = “Fail if not done” )
• Conversion of each of the above to specific and testable Engineering Requirements (Product – including internal tools) or measurable KPI (Process Development/Improvement)
• Vetting of all Engineering Requirements and/or KPI for practicality, testability, and measurability
• Tracability for each Engineering Requirement or KPI to one or more User or Functional Requirements
• Traceability of each Test to its “parent” Requirement set(s)

Requirements Management forces us to define and to understand the boundaries within which we must operate, and to set our goals based upon priorities and realities.

The Requirements Log

Each and every request, comment, and “hard requirement” that has bearing upon the intended project must be captured in the project Requirements Log. The log must contain:

• Date
• Short description
• Originator (whose idea was it)
• Contact (if not same as originator -- who must be contacted for more details)
• Comments/notes that explain the requirement
• Class (User, Functional, Regulatory, Constraint, Power, ….)
• Action taken (Accept, Clarify, Modify, Reject)
• Basis for action (if held for clarification, modified, or rejected)
• Engineering requirement(s) or KPI that trace to this requirement

Determine the Rank

The importance of a requirement must be determined early in the project, so that critical requirements do not get pushed to a point late in the project. The project team must have inputs to this ranking, as the leveling of resources (and the possible need for additional resources) are key components in this “chess game”.

Testing and Measurement

If we cannot measure it, we cannot test it or determine if we are moving in the direction of improvement. If we cannot define it, we can neither test it nor compare its current state versus past state(s).

The Test Plan (Implementation plan, for Process Improvement) must be created early, and updated as appropriate. Key stakeholders must have continuing visibility to the test results and/or measures of the KPI (for Process Improvement).

Why Vetting?

Let’s assume that “Joe” wants to add staff to his department, because he wants a raise in title and money. Joe generates a requirement that a task be added, and/or done in a specific order. If we accept that “requirement” we may actually reduce both efficiency and profits. If we vet the requirement, we have a chance to get a business case. Joe most likely cannot produce any business case to support the “requirement”, and we will not waste resources to support his desire for a new title.

Similarly, a customer may desire a phone that runs at 3 GHz for 3 days with 16 hours of use per day on a single 700 mAh battery. Their “requirement” is not possible with current technology, so it must be rejected. If we fail to reject it, we will: a) have an unhappy customer who expected the impossible, b) have a huge financial sink hole into which we have poured expensive resources, and c) have missed doing projects that could have brought in more customers and more revenue.

Traceability Ensures Success

By tracing each Engineering or Process Requirement to its “root”, the person who is attempting to satisfy that requirement can reach out to the source at any point in the process. This ensures that a requirement for “two wheels” looks more like the desired bicycle than a 2 wheel dolly. While the example may sound silly, many millions of dollars have been spent because of misinterpretation of requirements.

Summary

Requirements management is simply the means of getting everyone moving toward the same goals, and of ensuring that each person has full understanding of his/her part(s) of the project. If requirements are properly documented, any team member can reference the “root” requirement and contact the source of that “root” to ensure that their understanding matches that of the source. Misdirection can be avoided before it happens – or, at least, sufficiently early that recovery is relatively inexpensive.

The ultimate danger of requirements that are nebulous is that our “new and improved mouse” may look more like an elephant -- but with really tiny feet. The costs to fix the “disconnects’ may be enormous.

Bio

Mr. Randall has worldwide experience in program management, project management, technical marketing, Root Cause Analysis, Gap Analysis, business and technical process improvement, documentation management, training management, training needs analysis, curriculum design, development and delivery of training, and evaluation of effectiveness of training. He has created and delivered training and marketing presentations in at least 40 countries on 5 continents, with audiences ranging from the chief executive of the country to new soldiers. International field experience includes resolving issues for military organizations and commercial users, and project management in such places as Egypt, Ecuador, India, Nigeria, and Peru.

Mr. Randall received an invitation to join MENSA, a commercial FCC radio license, and an FCC Amateur Radio license while still in high school. He is a member of IEEE. Rounding out his “main” varied interests are photography, video production (he was elected to Active Grade in the Society of Motion Picture and Television Engineers for pioneering work in Electronic News Gathering), woodworking, and singing. He and his wife make their home in Richardson, Texas.