People often ask me what makes a good user requirement specification (URS). Maybe it’s my age or experience, or maybe they’re just trying to make me feel good, but I always consider it a compliment when someone asks me. After working on automation projects for more years than I would like to believe, I think I can nudge people in the right direction.

To me, the answer always returns to one word: simplicity. But, boiling down immensely complicated processes to the most straightforward explanations is often challenging.

In truth, it’s not as hard as people imagine. It’s about the right people, giving the right input at the right time. But, with so many stakeholders involved in drafting a URS, it’s far too easy for the process to go sideways. And when it does, it can lead to costly redesigns, delays, and, sometimes, disastrous results.

Lessons Learned the Hard Way

Previously, I worked for a company whose first attempts at automation had been less than successful. The machine they ordered was late, over budget and did not meet throughput requirements. Worst of all, it needed a highly paid babysitter to keep it running.

We learned much from our first attempt at automation. Senior management was skeptical of the need for automation from the beginning. Lacking experience with automation, they were comfortable with manual production. Should the need arise for increased output, they simply added more manpower. Inevitably, increased demand and external pressures forced management to look into automation.

After assembling a team of engineers, we started defining what was needed from the automated equipment and began to compile a list of user requirements.

As an OEM, we passionately believed that everything should be defined. At the same time, we also felt it would be advantageous to keep our options open as the project developed. This led us to define everything: screw sizes, tolerances, a particular brand of sensors, the gap between safety doors. We specified everything that we considered remotely necessary.

Looking back, most of the requirements we listed were trivial. At the same time, we overlooked many critical aspects. For example, we failed to specify how material should be off-loaded from the machine. We were so busy tied up in minor details, we neglected the bigger essentials.

The project became a nightmare. The machine builder became so bogged down with our precise demands that the requirements themselves became a significant hindrance to the project and resulted in runaway costs. The machine builder ran into more problems with the components our engineers had explicitly requested. For example, a sensor we demanded did not have the resolution needed to fulfill its primary objective, and this oversight was only discovered months into development.

Costs spiraled as the builder found it increasingly difficult to accurately quote the ever-expanding list of requirements and redesigns. Ultimately, the machine we received never ran as hoped. It was slow and produced far lower output than planned. It was a disaster. The entire project became a defining moment for the company. Management avoided further automation and continued to rely on manual labor. Automation became a dirty word.

Thankfully, things changed, and the engineering team was given an opportunity for redemption. A new, cutting-edge product had become a great success. Skyrocketing demand forced the company to redirect an ever-increasing labor force to manual production. In the end, management had little choice, and they agreed to give automation another try.

Determined to make this work, we agreed that the most effective way to move forward was to step back and scrutinize the previously failed project.

It soon became apparent that we had not worked well with our machine builder, particularly in terms of communicating what we wanted. As we talked with automation companies, we realized they wanted far more than just our requirements. They were looking for context, background and any other information to help them understand our needs. They didn’t need our in-the-weeds definitions; they simply needed help getting on the same page.

As we wrote a new URS, we discarded the prevailing ideas that had dominated our company’s previous automation project. We reconfigured the URS as a document to explain our process, give background, context, and obviously, the requirements themselves.

Our new URS was different from any other requirements document the company had written. In fact, during the final approval meeting for the URS, the executive in charge of the project pulled out a copy of the old URS from the previous project and compared it with the new one. The difference was stark. The old URS was as thick as a book; the new one was much thinner.

Ultimately, the automation project went forward, and we were recognized for our success. At last, we had hit a home run.

There are two key takeaways from this experience. First, you must reduce and simplify your requirements, so all that remains is essential. The most basic question is: What do you want to come out of the machine? Second, the machine builder is the expert at making machines, not the company commissioning the product. By setting too many requirements, you tie the hands of the builder and restrict the company’s engineers from doing their job to the best of their ability.

Simplifying Requirements

How do you decide which requirements are crucial and which requirements are superficial?

Previously in my career, I worked at Idaho National Laboratory in Idaho Falls. I had the pleasure of working with an engineer, Michael, who was a master of this. Michael worked on some large projects and was a pivotal contributor to the Yucca Mountain Nuclear Waste Repository in Tonopah, NV. He practiced the adage that if you wanted to add a requirement, the first answer was always “no.” Only after it was entirely justified could the requirement be included. Michael would go over every aspect and challenge you to defend it. If you couldn’t explain it to his liking, it was quickly deleted.

Even when a requirement was warranted, Michael would expect to see the rationale for why the item was set as it was. If you couldn’t justify the value, you’d have to go back and rework it—possibly more than once.

This process made getting his buy-off arduous, but it also helped people focus and understand what was needed. Too often, things that people think are essential are really not.

Years later, I applied that philosophy to the new automation project, and it proved invaluable. Over time, as we implemented more automation projects, the number of initial requirements became less and less as engineers learned to refine their methods.

I used to wonder what Michael’s “secret sauce” was. And then I realized: Michael simply understood how things worked. He knew what was required from each stakeholder. He had a good understanding of human nature and how a project could be hindered by people getting hung up on specific features that were not critical to the functionality of the final machine.

That’s the key to a successful URS. To comprehend the procedure, know the people involved and when they add value. All the stakeholders throughout the chain have differing angles, priorities and motives. We all have our perspectives and, at times, different interpretations of what the ultimate goal is.

When managing a URS, you need to be aware of each stakeholder’s role, experience and limitations. For example, you need to understand an engineer’s viewpoint and consider the daily pressures they can work under and how they can get lost in detail. Remember that purchasing agents are rarely trained engineers They can over-rely on the URS and find it difficult to answer specific engineering questions. Consider how approval committee members have different agendas and responsibilities within a business. Understand how these roles naturally influence which requirements they prioritize, such as costs, profitability or sustainability.

Think of the URS process as a giant beach ball. Each stakeholder has a different view of what they see, depending on how close they are to the project and where they sit. When asked to describe the beach ball, some see the ball as red and blue. At the same time, another sitting further away sees it as green, red and white. Someone sitting too close may only see a single color.

To craft a perfect URS, you must see the whole picture. From here, you can see all the colors of the ball and where each stakeholder sits in relation to it. Only then do you see the complete picture and understand why others see things differently depending on their situation. The finished URS can’t be all things to all people, but a good URS can clearly define and prioritize definitions while helping control expectations for all stakeholders.

Since that first project, I have become keenly aware of how crucial a clear and structured URS is to the manufacturing process. Here, then, are eight essential steps for crafting a perfect URS.

Everybody on the Same Page

A URS is much more than a document containing specifications. In a way, it’s a constitution, a single document that binds all stakeholders to achieve the objective. It sets out expectations, together with short- and long-term goals. A good URS lays down context and background and works as a roadmap to connect the dots from preconception to postproduction.

Clarity is everything. Background information prevents the machine builder from making incorrect assumptions and helps engineers know what priorities are and where they need to focus.

Make sure that you clearly define everything that has made it into the URS. Define how quality and effectiveness will be measured; this is crucial for the machine builder and will determine the quality of materials and components used to get desired results.

When compiling background information, don’t forget to include any supporting reference material. Be sure to define how and what you will be measuring. This is not always as obvious as it seems and is a common area where presumptions can lead to mistakes. Think about where the machine is to be installed and whether the installer should be aware of regulatory or geographical conditions.

Every machine, product and circumstances are different. So, too, is every URS. In the initial stages, if you are compiling the URS or coordinating the project, it’s critical to imagine each step and attempt to pre-empt questions, objections, or red tape.

Focus on Your Black Box

When compiling the URS, it helps to consider the machine as a plain black box. You don’t need to know how the solution will look. Don’t be concerned with what is going on inside the box. You only need to define what goes in and what comes out.

A machine builder needs to know how much and which materials will go into the machine and what you expect to be coming out. What crosses the system boundary of the black box is your responsibility during the URS creation. What happens within that boundary is the concern of the machine builder.

This doesn’t mean losing control of that development area. The machine builder will detail its solution in a proposal. If your team isn’t comfortable with proposal, the machine builder will have to return to the drawing board. This way, you only need to start influencing what happens in the black box after the project moves into the design phase.

Likewise, keep in mind that the more the URS specifies what must happen within the machine, the more it restricts the machine builder.

Standards Will Make Your Life Easier

The first rule of URS club: Always use standards when possible. Standards ensure everyone is on the same page since they are already known, understood and proven. They free us from being concerned over important yet tedious and time-consuming details. In short, they save time, increase compatibility, and significantly improve convenience.

For example, during our successful automation project, we struggled to define quality and overall equipment efficiency (OEE). The salesperson from the automation company simply advised that we follow a DIN standard used in the packaging industry where OEE, quality and throughput were already defined. Easy.

Not All Requirements Are Equal

Often, requirements are actually just things we would like to have. Or, in other words, desires. Generally, we would still accept a machine that made an acceptable product, even if it didn’t meet our precise requirements. Accordingly, an effective URS requires a method to add our desires into the requirements without formally making them a “must-have” requirement.

An excellent solution to this is to specify desires in the requirements section of the URS—but not assign it a requirement number or specify any test methods. This way, it’s out there, in a location where it will get noticed, but lacking traceability and testability. However, be sure to highlight this methodology to avoid any stakeholder presuming that the lack of a number or test method is merely an oversight.

If you doubt the necessity of a requirement, ask yourself the following question: What is the worst thing that could happen if the requirement were not included? If there is no significant consequence, you probably don’t need to have the requirement.

Additionally, if a secondary item must be delivered with the machine, state that implicitly. People often presume that secondary items, such as peripheral equipment, 2D drawings, 3D CAD models, schematics and vendor data sheets, will come with the machine. However, unless you specify these items as requirements, you can’t assume the machine will include them.

Short, Verifiable and Attainable

Two rules should govern each requirement. First, a requirement should express a single clear thought. Second, make sure that you can verify that the output was done correctly.

This is common sense. Each requirement must be understood. Rambling, ambiguous text is open to interpretation. A requirement needs language that defines, not a sentiment of prose. Subjective statements containing weasel words, such as “quick” and “easy” are not verifiable. Avoid using them. Symbols, such as <, ≤ and ± are your best friends for clarity. Cpk, Pp, Ppk and all statistical process control (SPC) methods are essential for compiling precise requirements.

A well-written requirement should define not only one-time targets but process capabilities. They help us answer the question: Will the machine work for thousands or millions of units? It’s impossible to answer that question unless you use SPC tools.

Any requirement must state a value that can be verified by examination, analysis, test or demonstration. As you write the URS, figure out how each requirement can be verified.

Requirements must be technically feasible and fit within budget, schedule and other constraints to be attainable. If you are uncertain whether a requirement is technically possible, do some research or simply asking the machine builder.

Change Happens

Aside from death and taxes, one thing is certain: Change will happen in a project. What is essential today may be irrelevant tomorrow.

When things change, it’s necessary to keep everyone on the same page. The URS is an evolving document. As such, it is imperative to maintain a strict order.

Be sure to incorporate revision approval and tracking on the URS document. Here, you can define any changes and explain the rationale for making them.

Ensure you maintain the same item numbering throughout the lifespan of the URS. Be especially aware that the requirement number stays the same between revisions, and lock this down as best you can.

Requirements are often added or dropped. When they are dropped, it’s crucial to stop using their allocated number. Accordingly, assign a new and previously unused requirement number when adding a new requirement.

Lastly, make sure everyone involved is working from the latest revision. I have lost count of the number of times when confusion over a requirement arose because from people were working from different versions.

Add Traceability

Be sure to include the source of each requirement in the URS. If the source comes from a requirement in a separate document, reference both the document and the requirement. This rule helps to trace the location of the requirement and assists in understanding why it was needed or not.

Traceability also helps should someone take over the project in the future, especially when retrospectively trying to ascertain the initial source of particular values or statistics. Traceability helps people understand the process’s history, and it explains why some requirements were retained and while others were rejected.

Traceability also helps eliminate the he-said, she-said game. It allows you to trace back step by step, should you or the machine builder have issues meeting a requirement, because it points to the original justification.

Allow Outside Experts to Provide Input

Working with outside experts, such as manufacturing consultants and machine builders, is an excellent way of gathering differing perspectives and thoughts early in the URS writing. Benefiting from their experience and knowledge can bring fresh ideas and methodology to your process.

Remember, not all the requirements will be achievable. They won’t all make sense in terms of finances or scheduling. Outside experts will have experience and know-how to save you significant amounts of time and money, especially in early planning.

This type of contribution can usually be conducted informally. If you look to gain input from a machine builder, it’s essential to your ongoing relationship that they are aware you are at the draft stage and understand that the project may not lead anywhere. As the project moves from the draft phase to the actual build, you can introduce a more formal input process.

It’s good to go with independent voices because there are often situations where your preferred machine builder can’t sit so close to you in the early planning stages. This could be because of company guidelines, tender conditions, regulations or simply not knowing which machine builder you will use. Whatever the reason, there will be situations when you will need input via a more formalized method.

Beware of machine builders trying to position themselves to get an advantage. This can be problematic if they push the solution based on something they can provide rather than what is best for your project. That is why I prefer to go with independent voices that aren’t selling you the end product. These experts are neutral and will always give the best help.

Lastly, I always like to include an opportunity in the URS for machine builders to comment formally on requirements. Allowing a location for secondary, but potentially vital, documents helps to keep everything in a single place and mitigates any potential oversights.

Accepting a response to your URS as a separate, stand-alone document is sometimes unavoidable, but be careful as this can lead to problems.

At the beginning of my career, I worked on a multi-million-dollar project with an overseas machine builder. We sent the company our URS, and it sent us a response. Since these two documents were separate, we forgot the builder’s comments on our original URS as the project moved forward. When it came time to do final acceptance testing, we were surprised when the builder refused to move forward. The builder had previously not accepted some of our definitions in the URS. We found those objections, of course, hidden deep in a separate response document. This resulted in headaches and heartaches on both sides.

It was our fault for forgetting the submitted document. However, our fundamental mistake was not controlling the response mechanism to keep it within the focus of our URS.

These eight steps will enable you to draft your URS faster, more smoothly and more effectively. They will help you commission your equipment, get it into production quicker, and realize the benefits of automation.

Remember, a URS is never just a document; it’s an evolving set of definitions designed to hone down on the details, always getting tighter and tighter, squeezing out the unnecessary, and leaving no room for ambiguity.

For me, drafting a URS is always exciting and gratifying. I hope these eight steps will assist you with your own URS.

To download a URS template, click here.

Editor's Note:
Tschaggeny Design provides engineering, design and support services to help transform ideas into products and get these products into customers’ hands. The company can help with the ideation, design, and manufacture of a product regardless of its size or complexity. The firm practices a variety of “design for X” approaches, including design for manufacturing and design for assembly. For more information, email info@tschaggenydesign.com or visit www.tschaggenydesign.com.