5 things you wish you knew about User and Product Requirement Specifications

1. URS VS PRS

Often referred to as User Needs, Intended Uses, User Requirement Documents or Customer Requirement Documents, eg technology prefer the term ‘User Requirement Specification’ (URS). We define it as a statement of the ‘end-user needs’, from their perspective, with respect to the product being developed. The URS describes what the product should do, from the end-user’s perspective, but does not describe how it should do it. The URS will not propose a design but must remain solution agnostic. The final design will be validated against the URS by the project owners. The URS needs to focus on two questions: “as the user, I want the product to…” and “what is the right product to make?”. It is imperative to keep these questions in mind throughout the entire process.

In contrast to the URS, the Product Requirement Specification (PRS) is a technical statement of functional and performance requirements, with respect to the product being developed. The PRS describes what the product should do, from an engineering perspective. The PRS may define how the device should do it but does not detail the embodiment of the design. The PRS portrays what everyone on the project team (including the project owners, their sub-contractors & egt) are aiming to deliver, across the whole spectrum of the project. The final design will be verified against the PRS by the responsible project team members as defined. Often referred to as Design Input Requirements, the System Requirement Document or the Engineering Requirement Specification, the PRS needs to focus on “what functional/performance target the product needs to achieve…” and “how will we make the product right?”.

There will be certain requirements in the design of your product which may sit in both your URS and PRS, for example ‘size’ of product, but the context will vary between them (i.e. user need vs functional target). Whereas others will be delineated into the relevant category. Your URS and PRS will form the backbone of your design process, so being as granular as possible is integral to ensure traceability and measurability.

2. THE THREE VS: VALIDATION, VERIFICATION AND V-MODEL

Traceability is key in the design and development of a medical device and the MDR has a presumption of compliance to the harmonised standards (including ISO 13485). There is no set clause stating that you must have a ‘URS’ & ‘PRS’, but the process itself is extremely important. What they do state is that devices shall achieve the performance expected, be safe and effective, any risks are mitigated against benefits and are compatible with a high level of protection of health and safety. At eg, we have built a bespoke design process in line with the standard, which incorporates elements applicable to us, such as ‘risk’ and ‘distinguishing responsibilities’, and uses the V-Model to map the process, ensure traceability and demonstrate Validation and Verification of the URS and PRS respectively. This evidential traceability is integral in regulatory approval for medical devices.

The V-model is an effective way (while not part of the standard, it is understood by auditors) of demonstrating your product design process. Moving through the V-Model (URS-PRS-Design-Verification-Validation) isn’t a single journey, you will travel through it numerous times as you go through your development process. Ultimately, by your final loop through the V-model you will need to prove that your ‘design output meets design input requirements’ (i.e. verification against your PRS) and that your product achieves it’s ‘specified application and intended use’ (i.e. validation against your URS).

3. WHERE THE URS AND PRS SIT IN YOUR PRODUCT DESIGN PROCESS

It is important to create a design and development programme, from concept generation through to market launch, which details compounding factors which should be considered simultaneously. As well as product design and prototyping, these will include risk management, human factors, quality assurance, qualification & validation, a clinical programme, intellectual property, and market access. To neglect any one of these at the inception of your project, may have severe implications further down the line. It is important to note, that no development programme is entirely linear and there will be continuous refinement throughout.

The development of your requirement specifications, of course, starts at the beginning of your overall development programme. However, don’t expect to add significant complexity until the prototyping stages.  The URS is the first step in your V-Model, hence we recommend starting there and because your PRS is the second step in your V-Model and will link back to the URS points you have identified, you can expect your URS development to be slightly ahead of your PRS. For each of them, start with basic notes deduced from discussions with your core team, then use workshops with said team to create a top-level draft, written in your Requirement Management System.

Utilising templates, checklists and example documents to trigger considerations. Following this, the bulk of the detail should be added through several iterations of: creative session, write-up and review. This detailing stage is often the most time consuming and it is important to involve representatives across all relevant disciplines. The subsequent refinement phase is continual, remember to remain flexible as you learn from your users, your prototyping, and so on. Just be sure to thoroughly document the development in your Requirement Management System, which you will also maintain through the next phase as well, ‘Change-Control’, to ensure traceability through your V-Model.

4. BEST PRACTICE

When writing your URS and PRS, there are some rules by which you should generally abide, in order to avoid issues further down the line. It should be written from the perspective of the intended final product design, taking in to account the whole spectrum of concerns, from concept creation to packaging and delivery. Clarity is key. PRS points should be unambiguous, measurable (to ensure they can be verified) and when writing there should be individual requirements per URS/PRS point. Terminology and notation are regular stumbling blocks. It is important to define each at the beginning of the project. Using terms such as ‘shall, should, may’ consistently, demonstrates the level of preference within the requirement, and avoiding negatives such as ‘shall not’, reduces ambiguity. Once again, traceability must be maintained through the V-Model and records must be kept of any developments throughout the design process.

The best way to keep track of refinements or iterations through the development process is via a Requirement Management System, such as Matrix or Greenlight Guru. This will automatically keep a record of file history and create links between items for traceability, establishing a full matrix of your programme. You will also be able to pull information from your risk analysis into your Requirement Management System, by adding individually identified risks and consequently linking specified requirements in your PRS. Additional functionality is the Sub-System Requirement Specification (SSRS), which acts as another hierarchical layer and can include even more of the how and some details of embodiment, if suitable for your product. This may be used to expand upon the broader PRS points or drill down into specific functions or components, such as the Consumable Requirement Specification.

5. WHAT TO WATCH OUT FOR!

Although traceability and regulatory compliance are critical factors, it is really important that creating a URS/PRS doesn’t just become a regulatory tick-box exercise. If the process is well executed, then it will result in a better design process and in turn a potentially better product. If done badly, the opposite will apply. It is also a way of unifying your team; the common process shows a statement of intent and helps to manage the expectations of everyone involved.

Hopefully having read this blog, you are now aware of the importance of creating a thorough URS/PRS and can appreciate the risks of under-defining a project at its inception. Under-defining can lead to under-budgeting, an unclear brief where the team works in silos and a lack of visibility with regards to potential risks. However, over-defining can often be as dangerous! Setting the boundaries of a design programme too firmly may stifle creativity and set expectations that cannot be delivered. A clear, well managed project outline, which is managed flexibly, collaboratively and visibly (for both traceability and efficiency) is key.