How to Write a URS: Expert Guidance from Kurt In Albon – Part 1

Learning how to write a URS (User Requirements Specification) is critical for any pharma digital project. Today, we’re speaking 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 this first part of our conversation, Kurt shares strategic URS principles that separate successful projects from costly failures: why the URS matters more than any other validation document, the results of a poor URS, and the leadership mindset required to get it right.

Key takeaways

• The URS is your foundation: It’s the single most important document in the system development lifecycle – everything else is built on it
• Start early, really early: Write the URS before system selection, not after, and invest the time upfront
• Think strategic, not compliance: A good URS serves your business for 5-15 years, not just QA sign-off
• Keep it system-agnostic: Define what you need and why, not how a specific system works

Why user requirements specification matters in pharma and GxP computerized systems validation

Before we get technical, why should senior leaders even care about how well a URS is written? What happens when leadership treats it as just a formality?

Kurt: When learning how to write a URS, senior management must understand they’re paying for a multi-million dollar investment. A well-written User Requirements Specification allows for better timing estimates and sets realistic expectations from the start.

The URS is the single most important document in the entire lifecycle. It builds the foundation, that bedrock on which the system is later built. Senior management has an interest in this foundation being solid in a strategic manner, because that system is going to be in place for five, 10, maybe 15 years, with upgrades and everything.

If it’s treated like a formality, it becomes a source of delays (because all other validation documents rely on the URS) and a waste of time. I’ve seen this firsthand: projects that dragged on for two, three years because the URS was weak. The system went live but wasn’t used very frequently. And then it died. 

That was a couple of million dollars wasted, plus all the people’s time. Then you end up with years’ worth of data that you’ve gathered, you have to replace the system with something better, and now some of that data is still operational – it’s not ready to be archived yet. So you have a migration project on your hands as well. It’s a mess.

“The URS is the single most important document in the entire lifecycle. It builds that bedrock on which the system is later built – and that system will be in place for 5-15 years.”

• Kurt In Albon 

How to write a URS: understanding the basics

For those who are less hands-on, would you describe what a URS actually is, in the simplest and most practical terms?

Kurt: A URS specifies WHAT we want a system to do, and – perhaps most importantly – WHY we want the system to do this. It’s a list of statements, a tabular form with a simple structure that says what a system should do and why.

It’s not an overly technical document. Sometimes it will contain content from different sources – not just the business process, but also quality or compliance requirements, IT security requirements, and so on. But most importantly, the URS says why.

It’s typically a listing of well-formed statements – a table of sentences that start with “The system should” or “The system must”. It’s the first document that gets created when we want to bring in a new system. It’s boring to read, I’ll admit that. But it’s difficult to write.

User requirement specification in pharma: avoiding common mistakes

You’ve seen many teams struggle. What are the most common misconceptions or wrong assumptions companies have when starting with a URS? 

Kurt: Teams often struggle to remain system-agnostic. The URS should not be written off the slides of a supplier. I’ve seen teams struggle with this because very often they already have a system in the back of their head – they’ve seen a demo, they’ve seen it at a trade show.

One of the most extreme cases was a document management system being brought in. The team ended up writing the URS after the system evaluation phase, after it was already decided which one to bring in. We wrote the URS based on the supplier’s user guide.

And yes, that certainly takes less time because you can just copy-paste a lot. But it becomes a formality. The document matches perfectly, but you’ve done it backwards.

Why this happens

I think this happens a lot because software suppliers build one-size-fits-all solutions. They go to all the pharma companies and sell the same system. The pharma company looks at it and says, “Yeah, that kind of looks okay, they’re making a good price, let’s go with that one.” Then halfway through: “Oh, by the way, validation – what do we need?” And then the URS comes into play.

A URS is not a document written after a system is selected – it’s written before that. A URS does not describe HOW a system meets a requirement (that’s the Functional Specification). If the URS is written by the wrong people, there’s a real danger of it becoming system-dependent and highly technical.

In Part 2 of our conversation, Kurt shifts from “why it matters” to “how to actually do it”: the structure of a good URS, who should be in the room, what separates strong requirements from weak ones, and practical advice for aligning IT and QA around a shared understanding. Stay tuned!

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

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