User Requirements Specification: Why It’s not a ‘User Wants Specification’

user requirements specificationThe purpose of a User Requirements Specification is to clearly and specifically document the requirements for the machine, system, or upgrade that you plan to buy or implement (for our purposes, let’s call it a machine).  The User Requirements Specification provides the project manager or engineer with her marching orders. ‘Go get us the machine to do what it says in this document.’ In the FDA-regulated life sciences industry, the User Requirements Specification (URS) is the foundation.  It forms the basis for the volumes of documented evidence known as ‘Validation’ and is the cornerstone of the GAMP model. Done correctly, the URS specifies a machine that will repeatedly and reliably perform its role in the manufacturing process; no less, for sure.  But, equally if not more importantly, no more. And that’s the point:  Done wrong, you’re instructing your engineer to obtain a machine that is too much, too complex, too expensive, too big, or all of the above. It can be like buying a big rig to deliver pizzas.

Everything costs something.  Be aware that every feature your team of users adds to the list as a ‘requirement’ is going to cost more money or more time to obtain. And, it will need to be tested to make sure it works as requested. Is it really necessary to have frames made from 316L stainless steel or would powder-coated mild steel meet the need? Are servo-controlled positioners a ‘must have’ or would a couple of hand cranks work just as well? Do you need to collect and store thirty pieces of data on every pouch the machine produces or can you narrow it down to three to five critical parameters that should be monitored?

Going back to the life sciences world, every feature you add also has to be validated. One group of people has to write, approve, and execute the qualification protocols.  Someone else has to invest time to write, review, approve, and file the resulting report. If that feature is not something you really need and adds value, what’s the point in adding it to the user requirements specification?

Learning to ask ‘why?’ can be a valuable tool. As your team develops its list of requirements, it doesn’t hurt to politely and respectfully ask Why do we need that? What makes this necessary? Is it something that the process requires or is it something that somebody on the team wants because he thinks it would be cool to have? Does it fulfill a regulatory requirement? Does it make the machine more reliable or easier to maintain? Is the machine still safe to operate without it? Is it a ‘requirement’ or a nice-to-have ‘want’.

The Importance of Buy-In at the User Requirements Specification stage cannot be underestimated. There’s a reason more than one person signs off on a URS. Before a team member or user places a signature on the signature page, he has to be comfortable that what is written inside truly represents the requirements for the project, including his own. One of the benefits of having a cross-departmental team involved in authoring the User Requirements Specification is the ability to synthesize thoughts and challenge the requirements on a cross-functional basis. A good project manager will not ask for those signatures until she is confident that it contains only requirements, without the wants.

Speak Your Mind