Learning how to write a URS (User Requirements Specification) is critical for any pharma digital project. Today, we continue our conversation with Kurt In Albon – an expert on pharma validation and GxP systems with over 30 years of experience – to uncover his proven strategies for writing a URS document that drives real business impact. With hands-on experience across both strategy and execution, Kurt has seen exactly where projects succeed… and where they fail.
In Part 1, Kurt laid out the strategic case – why the URS is the single most important document in the systems lifecycle. Now we get practical.
In this second part, Kurt breaks down the mechanics: what a good URS looks like on the page, who needs to be in the room (and who should not be driving), how to write requirements that are specific enough to test, and how to get business, IT, QA, and vendors aligned before misunderstandings derail your timeline.
Key takeaways
- Involve users: The content in the URS must come from the people who execute the daily process (analysts, sampling teams, logistics), not from managers or IT calone.
- Specificity is everything: Vague terms like “minimal”, “normal conditions” or “e.g.” create loopholes. Every requirement must be concrete.
- Create a shared dictionary before you start: Teams waste months arguing due to misaligned terminology. Define terms early.
- Quality is not compliance: Compliance is non-negotiable, but it’s a byproduct of quality. Build systems that bring customers back, not systems that pass audits.
What a Good URS looks like: Pharma URS best practices
Kurt, what does a good URS look like? What are the signs that “this was done right”?
Kurt: A good URS has several key characteristics:
- It’s positioned in a larger context, and it addresses a well-defined need or problem. It aims to solve that problem or group of problems.
- It contains a reasonably detailed business process flow chart, preferably a swim lane flowchart, to address responsibilities and roles involved in the process. This is crucial – you should see this on page two or page three of every URS document. Then while you write your URS, you derive every requirement from the steps of this process.
- The requirements are system-agnostic (in case of a new implementation), and structured in a simple, repeating, tabular structure. They should need no further explanations.
- The URS should also place the system in the architecture that you already have. You have a landscape of systems in your company. You bring in a new one. How is it going to fit? Maybe it’s duplication. Or maybe you see that we could then connect that system up with others and integrate for efficiency.
A more humorous sign is when you see a great lot of comments from all reviewers in the first review cycle. That means people took time to review in depth and take the effort seriously.
Writing a URS document: who should be involved?
Who should actually write the URS, and just as important, who should review and approve it to make sure it reflects business, quality, and operations properly?
Kurt: That question goes to the heart of the matter: It’s a USER Requirements Specification, not an IT or Supplier or QA Requirements Specification.
The business process owner is ultimately accountable for the content of the URS, but they may often be in a management position and not necessarily be those SMEs who work the process every day. But it is absolutely crucial that you get these people in the room – the ones at the front, the ones who execute the process.
If you write the URS for a LIMS, you want lab analysts, you want the sampling people, you want the logistics people who execute all those steps – not the lab manager, not the head of QC. Even though the head of QC may be the business process owner because they’re accountable for that process in their role, you want the people who get their hands dirty.
You have a moderator there, somebody who’s written the URS before, maybe somebody who understands the structure and the technical questions that need to be asked behind it, but that person will only provide structural input. The content comes from those people at the base.
Throw in a manager or two as well, they will give you a high level vision of what they think the process should be like or where the company is going, maybe that has an impact. And the SMEs will say, oh, yeah, if you want to do that, then you need to do this. The system needs to do this.
“The URS isn’t written for QA or IT. It’s written BY the people who actually work the process every day – the lab analysts, the sampling people, those who get their hands dirty.”
- Kurt In Albon
Review and approval
For review, we want as many roles as possible – people from involved disciplines and from “neighboring processes”. IT reviews for feasibility in the company context, QA reviews for compliance and quality topics and IT security needs to know that it will fit into the security governance. The more the merrier!
For approval, be sparse: the business process owner takes accountability, and because it’s typically a GxP validation document, the last approval would be with QA to show accountability and oversight. More signatures do not mean more accountability – on the contrary. Keep it down to two to three people.
Good requirements vs. bad requirements: real examples
Do you have an example – even anonymized – of a well-written requirement versus a weak or risky one, something that illustrates the difference clearly?
Kurt: When people ask me that, I usually tell them: remember what the document is called. It’s a user requirements specification. Requirements have to be specific.
Bad examples:
- “The system should employ minimal customization to meet requirements.”
“Minimal” is vague and subjective, and a URS shouldn’t dictate implementation details – that belongs in the Functional Specification.
- “Response times less than 2 seconds under normal conditions.”
“Normal conditions” is undefined, the 2-second threshold lacks justification, and this would be extremely difficult to verify during PQ.
- “Store documents with information (e.g., Author, Title, Date, etc.)”
Using “e.g.” and “etc.” leaves requirements open-ended. А minimal system storing only three attributes could claim to meet this despite missing critical attributes.
Good examples:
- “The system should allow the author and supervisor to cancel an approval workflow before all signatures are collected.”
Closed and specific – clearly defines who can cancel, what can be cancelled, and when.
- “The system must authenticate users against Active Directory to avoid system-specific credentials.”
Specifies the exact technical approach and explains the business rationale.
Pull regulatory requirements apart
I’ve seen user requirements specifications that said, “The system must comply with 21 CFR Part 11 and Annex 11.” Specific regulations that were written by lawyers and are not easy to read. Asking a software supplier to simply understand all that is dangerous.
If you write out the requirements from the regulations – actually pull it apart – they understand: “Ah, this is what I need to do.”
In one situation, we created a supporting document with every URS, explaining those regulations for non-experienced suppliers. Completely selfishly motivated, but extremely well received.
Always remember you will have to write PQ against your requirements – all of them!
Aligning business, IT, QA, and vendors on requirements
From an ecosystem perspective, where do you see organizations struggling the most when it comes to aligning business, IT, QA and vendors around one shared understanding of requirements?
Kurt: The biggest hurdles are typically differences in terminology and language, and a short-sighted view of objectives (department objectives vs company objectives).
An example: a URS for a document management system where the process owner, IT, and consultants all used the term “owner”, but each understood it differently. For the process owner, it was the accountable person for the document; for IT, the object in the database and its technical owner; for the consultant, the typist. Discussions extended over months before it became clear they all meant different things. Something simple like a dictionary will help.
Another hurdle is the “not my job” attitude when team members remain within department “silos”. A project should be treated like a startup where everyone has several roles. You need people with duplicate skill sets who can serve as translators, bridging the language gap between departments.
Mindset Shifts Leadership Needs to Make
If you were advising leadership directly, what mindset shift do you think they absolutely need to have to support URS success, not just approve a document?
Kurt: Leadership in many life science companies today still doesn’t distinguish between compliance and quality.
“GMP does not stand for “Generate More Paper” – but for “Good Manufacturing Practice”, and good practice is what you learn when you study at university – the best way of doing your job, with diligence, attention, professionalism, all of that.”
- Kurt In Albion
– Kurt In Albon
The mindset shift required: quality isn’t the same as compliance. Compliance is a byproduct of quality. One CEO said “compliance is very close to my heart” on quality – showing he hasn’t understood.
Compliance is non-negotiable in pharmaceutical business. But quality is when the customer comes back, not the product. Quality builds trust.
Also, never forget that “best quality” does not mean expensive. It also means the most efficient way of achieving that quality. The best way includes the most cost-effective way.
Lastly, think long-term. The more stable and better defined systems are, the longer they will provide benefit and work fit-for-purpose. But this means a strong, solid URS foundation. And long-term is not 3 years – it’s 8-10, maybe 15 years.
I realize people change jobs every two or three years. But if you’re just there briefly, you won’t think strategically – “In three years, I’m gone; not my problem anymore.” These URSs are written for strategic purposes. You want minimal OPEX later to use the system as long as possible to make up your investment.
Three essential tips from a GxP systems expert
And to close with something practical – if you had to give just three clear pieces of advice to any team before they start their URS journey, what would they be?
- First, start early.
Involve the people who actually execute the process every day – the champions of the process, the SMEs. These people provide the meat on the bone of the URS. The skeleton can be provided with the help of consultants, but never the content. Free them up from their day job for as long as it takes to write that URS and review that URS.
- Secondly, ask yourself: What is the problem I’m trying to solve?
Answer this question with brutal honesty, precisely and truthfully, or you’ll be implementing a solution looking for a problem. “We want digital transformation!” is not a good response. You want a concrete problem, a pain point, a stone in your shoe that hurts. You want that solved.
- Thirdly, don’t digitize a bad process.
Think strategically, HOW you want to work in the future. Don’t be afraid to upend a long-established process into something new, before putting it into a URS and basing your requirements on the future instead of the past. Make the best possible process and turn that into a user requirement specification.
A final word on honest reviews
When you review a URS, be brutally honest. I’ve had people give me stares when my first comment was “Has anybody else even read this?” – followed by 50 pages of comments. But I explained: if we get this right now, you’re going to be successful. If we get it wrong, you will not. It’s as simple as that.
So, when you get into that role, yeah, take the red pen and go have at it.
About Kurt In Albon:
Kurt In Albon is a recognized pharma validation expert and GxP systems expert with over 30 years of experience in GxP computerized systems validation. His expertise in writing URS documents and implementing User Requirements Specification pharma projects has helped life science companies achieve successful validation outcomes.
With a background in IT systems development and specialized training in validation and quality management, Kurt has worked across the full spectrum of pharma digital projects – from document management systems to complex LIMS implementations. He’s known for his strategic approach to validation, his emphasis on quality over mere compliance, and his insistence that good systems start with knowing how to write a URS properly.
Connect with Kurt on LinkedIn.
BGO Software is a renowned IT company specializing in healthcare technology solutions. With over 15 years of industry experience, we offer comprehensive technology consulting, software development, and IT infrastructure services. Our focus on healthcare technology enables businesses to mitigate technological risks and accelerate growth, ultimately delivering enhanced value to patients.
link to the author’s linkedin profile
