Pillars for a Killer URS – Balancing Users, System, and Business

26 April 2023  |  Reading time: 4 minutes

This is the personal story of Karianne Martel on her experiences during the process of defining user requirements for computerized systems.

Have you ever been asked to comment on the functionality of a system or a process? I have been asked that question several times, sometimes as content expert but also as functional tester. My first question is usually: “What is the system or process supposed to do? And which aspect should I focus on?”. Most of the time followed by silence or: “We trust your expertise.”

Although I trust my own expertise, that is not the answer I like to hear as it creates a lot of opportunity for wasted time and energy. What I’m asking for are in fact the user requirements of the system and the assignment. To achieve success, you need to know the definition of success. Not because I don’t know what the system should do but because you need a common understanding of what the system needs to do.

“Keywords are ‘Users’, ‘System’ and ‘Business’.”

The user requirements in the context of a computerized system are documented in a User Requirements Specification (URS) at the beginning of the creation or implementation by the system/process owners. It can be a process with a lot of discussions, expectations, and iterations so to keep the process efficient and pleasant I prefer a structured approach. My structure starts with our definition of user requirements: Business needs for what users require from the system.

Who are the users of the system?

If you have done a stakeholder analysis, use it to identify the users for the user requirements. A user can be someone who will login to the system but the groups that facilitate the system or make use of the results of the system also have requirements. My experience is that the different user groups have different styles of thinking and communicating. The owner of the URS (User Requirements Specification) needs to balance the level of detail and the priorities of the various groups. I have seen projects where one group detailed the requirements until the position of a button while another group needed to be able to plan resources, no further details.

What are the boundaries of your system?

And in this case, I’m talking about the software system. You have carefully selected your user group that is invited to a user requirements session and people get enthusiastic. The requirements get more and more beautiful and broad and before you know the system is not capable of fulfilling the requirements. Scope creep is always just around the corner also with defining User Requirements.

“Scope creep is always just around the corner also with defining User Requirements.”

Make sure knowledge about the system is available, if necessary, remind yourself and the users of the original business case for implementing the system. Write down all the requirements but expect to drop some. Decide if it is important to have requirements combined in one solution or if it is better to split. For instance my project planning system might not need a controlled Document Management module but for my QMS it would be a real asset. Keep track of the requirements that didn’t make the cut including the decision why they are left out.

Keep the business in mind

The system at its core is created or implemented to support your business. Our customers often need to comply with regulations and standards and this has significant impact on the user requirements of the system. For example, you might need a regular back-up or two factor authentication. What is important for the business of your organisation, do you need to comply with specific regulations? What are the characteristics of your userbase? Is your business growing and is the implemented solution scalable? All these questions can help you define your user requirements from a business point of view.

“Have you ever been asked to comment on the functionality of a system or a process?” Yes, I definitely have and the level of difference in the user requirements that get drafted varies a lot. While it is a challenging process it definitely is worth all the effort in the end. Where it might seem hard sometimes, don’t forget to enjoy the process along the way! And while I was writing about User Requirements Specifications my colleague received the feedback: “I didn’t see the need to document the user requirements, but it really helped me developing the system.”

Are you getting started with drafting user requirements? By following the Business, Users, and System approach, you can identify the key factors that will guide the decision-making process of a new computerized system. If you require support with defining your User Requirements Specification, don’t hesitate to contact us.