How to Create Solid User Requirements for a System Application

Blog: User Requirements Specifications

A laboratory informatics solution (e.g., LIMS, ELN, CDS) is only as strong as its foundation. The strongest foundation for a laboratory informatics solution implementation is a thorough user requirements document, generated to identify exactly what the system is intended to do. This requirements document, also known as a User Requirements Specification (URS), is used extensively throughout the selection, development, and implementation of the solution and in the end, is the yardstick used to measure its success.

Unfortunately, many times this document is not created with the attention to detail that its importance deserves. On numerous occasions CSols has been brought on to help get a project back on track after the client spent painstaking hours developing an incomplete URS, or worse, evaluated vendors without a URS, only to wind up unsatisfied with the outcome. Too often, requirements generation is looked at as a checkbox exercise where many in the business assume they will have plenty of time to correct any inconsistencies as the project evolves.

Compounding the problem of incomplete requirements documentation is that many project decisions are made based on the incomplete document before the realization dawns that the requirements were not detailed enough or suited to actual business needs. The result of such neglect can be time and cost overruns, a system that is inefficient, users who are unhappy, and the possibility of total project failure.

So, what can be done to position an organization for success with respect to creating solid user requirements for a LIMS, ELN, or CDS project? The following tips outline some sensible approaches to generating a solid user requirements document while also providing some additional benefits to your company’s culture.

Strategies and Methods for Gathering Your Requirements During System Development

Generate a Buzz

We all love recognition, right?  Great contributions to a project are no exception. Make sure the importance of the project is communicated across the organization when the process of requirements gathering begins. Having this message come from management (the higher up the better) will go a long way in conveying its importance to the company. It is crucial that the project’s importance is communicated, with an emphasis on why it’s important. Explain how the solution will make people’s jobs easier, increase efficiency, and impact the bottom line. 

The resulting buzz will help to attract high achievers in the organization who want to be involved. People will feel the project buzz and realize that contributing to the project’s success will not only help the company but also allow them to have input into the solution and possibly gain more visibility and recognition for themselves. This buy-in will help to ensure that requirements are drawn from a robust pool of end-users and stakeholders.

Create a Solid URS Team

Blog: LIMS and ELN Planning Team Members

OK, now that you have attracted some of the best and brightest, make sure the user requirements team is well structured. If your initial efforts have not attracted users from all impacted business units, ensure that you will get their input by adding team members from IT, the labs, quality control, the business, and any other affected areas. One common cause of incomplete requirements gathering is that certain affected areas were never given the opportunity to provide input. Whether due to oversight or the assumption that their needs have been understood, this can be a huge mistake. Without input from all impacted business units, your user requirements will not be complete.

When selecting representatives of each area for their input, make sure that they are subject matter experts (SMEs) in their areas who are empowered to either make or influence decisions for their department. Note that the most appropriate SME to fulfill the team’s needs is not usually a member of management, but a person who is close to the processes themselves. The best SMEs will be vocal advocates for their own needs as well as willing to listen and understand the needs of other areas and how all those needs fit together. The assignment of these strong SMEs to the team can require a short-term sacrifice of resources available for day-to-day operations but will pay off at the end of the process. 

An added benefit across the organization is that through the work of this team, great communication channels and relationships are formed that can be used in the future. The team will provide much better insights into overall processes and cross-department impacts may be achieved through the discussions. 

Additional Reading Resourcing Your Project Team for Success

Clarify the Intent for your URS

We can all be too clever for our own good, and generating user requirements is no exception. Avoid creating requirements that are too difficult to understand or at an inappropriate level of detail (either too much or too little).

In a recent validation project for an electronic master batch record system completed for a life sciences company, the URS document was not specific enough because the client was unfamiliar with the validation process. Extra work was needed to identify what functionality to test. A good way to avoid this pitfall is to make sure everyone on the team clearly understands what the requirement document is, what purpose it serves, and the appropriate level of detail it should contain.

Conducting a quick training session on these topics will ensure that the team is on the same page and will go a long way toward easing any discomfort in team members who have never experienced a requirements generation exercise. 

The Payoff for Generating a URS

Though it can be thought of as another boring document generation exercise, the generation of user requirements for a LIMS, ELN, or CDS can be so much more. Take advantage of the added benefits you can receive through this exercise, such as:

  • Organizational team building and relationship generation
  • Improved communication across the organization
  • Improved understanding of overall processes and impact
  • Empowerment and development of colleagues

Another benefit for creating solid user requirements is it’s use during the vendor selection process. It can be used as your guide, allowing a level playing field on which stakeholders can evaluate vendors, which is a key part of ensuring you have chosen the best LIMS for your laboratory. Postimplementation, it provides an objective measure of how successful the LIMS implementation has been. If the user requirements were met, user adoption should be high.

The development of user requirements may be the most important task in determining the success of an informatics project. If you provide the proper resource, time, excitement, and priority to generate these requirements, the payoff will be well worth it.

Webinar: "Where to Start When Planning for a LIMS or ELN"

What do you see as the main obstacles in an organization to generating solid user requirements for an informatics system? 

Share Now:
Comments

6 responses to “How to Create Solid User Requirements for a System Application”

  1. Corne Nous says:

    To my opinion the fundament of the URS should be ai thorough analysis of the business processes. In each process the decission points and stake holders should be identified, together with any inconveniences. Discussions should be initiated on where the processes can be optimized.

    Still too often the organization tends to stick to their legacy processes and are adapting the applications instead of adapting their processes.

    • Tom says:

      It has been my experience that URS can often delay the start of the project by 6-12 months and are also inaccurate by the time they get to the software vendor. If any lab is worth its salt it is evolving their processes (workflows) on a continuous basis. So at what point in time to you cut off the development of the URS? if a requirement was written in the beginning of the URS development process it is likely that it is obsolete by the time the document is published.

      I think it is favorable to give a customer a system to work with and then develop the system to their specification on an iterative basis. This presumes that you can turn around their requests rapidly; same day or same week. Customers are much happier with this approach and implementation time is cut down by the 6-12 months you would have taken to write a URS document.

      • siteadmin says:

        It is clear that taking 6-12 months to develop the URS is excessive and it would not be unusual to have laboratory and business processes evolve somewhat in that time frame. However, it has been our experience that attempting to implement a LIMS without any URS is not a best practice. That being said, we would agree that utilizing a prototypical implementation methodology with a quick reiterative process will help the key stakeholders gain a true understanding and feel for what is being implemented. During this process, it is common to adjust the URS as the users give feedback.

        Besides, without any URS it may be difficult to select the best LIMS or ELN for a particular’s laboratory organization’s needs.

    • Rebekah says:

      I agree SMEs attempting to replicate legacy processes in the new system is an issue, and that’s why you need a strong PM/BA/SCRUM master who has ownership of gathering the requirements, to guide the SMEs to recognise this, push back when needed, capture the Start-Stop-Continues for their Future State vs Current State processes etc.

      I think to be fair, the author covered that to an extent when they said “the best SME’s to fulfill the team needs is not usually a member of management, but a person who is close to the processes themselves”. I makes sense that you can’t gather accurate User Requirements from someone who isn’t a SME, but they also need to have enough authority to author SOPs and implement these process changes. Lab managers are ideal.

      • siteadmin says:

        Rebekah, you have definitely identified a couple of very important traits that the URS team must possess to be successful! The main one being that they must be empowered to either make decisions for their group or organization or at minimum have direct, timely access to management who can provide those decisions.

        In addition, having a facilitator or team member who has experience in these discussions is huge. It is important that the team understands that part of the URS process is to challenge why things are currently done a certain way, which often leads to discovering efficiency to be gained with changes.

    • siteadmin says:

      Great points Corne. We have found that a balance has to be struck between adapting the application and adapting the processes. It is important to analyze the degree of disruption that changing the process will have on the business. Also, in the informatics area, most of the products have very good development tool sets and application programming interfaces (APIs) that allow for the customization of the system in a supportable manner.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.