How to Create Solid User Requirements for a System Application

How to Create Solid User Requirements for a System Application - CSols, Inc.

A laboratory informatics solution (e.g. LIMS, ELN, CDS) is only as strong as the weakest part of its foundation. The foundation for an implementation of a laboratory informatics solution is the user requirements document, generated to identify exactly what the system is intended to do. The 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 thoroughness and attention to detail that its importance deserves. 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, it is often the case that many project decisions are made based on the document contents before the realization occurs that the requirements were not detailed enough or suited to actual business needs. The result of such neglect can be time and cost overrun, 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 system application project?  The following tips outline some sensible approaches to generating a solid requirements document while also obtaining some additional benefits to your company’s culture.

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.  Having this message come from management (the higher the better) will go a long way in conveying its importance to the company.  It is crucial that the project’s importance is communicated, but emphasis should be placed upon why it’s important.   Explain how the solution can make people’s lives easier, increase efficiency, and impact the bottom line.

strategies and methodologies for gathering URS

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!

Create a Solid Team

OK, now that you have attracted some of the best and brightest, make sure the user requirements team is well structured.  It is essential that the user requirements include input from all areas that will be impacted by the informatics solution.  Often, certain areas that are impacted were never given the opportunity to provide input to a solution.  Whether due to oversite or the assumption that others already understood their needs, this can be a huge mistake!  It is essential that all areas have input into the generation of the user requirements.

When selecting representatives of each area for their input, it is imperative that they are subject matter experts (SME’s) for their areas and are empowered to either make or obtain decisions for their department.  Note that 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.  The best SME’s are willing to be vocal as well as listen and understand other area needs and how it all fits together.  The assignment of these strong SME’s to the team can be a short term sacrifice to resources available for day to day operations, but will pay off handsomely in the end.

An added benefit across the organization is that through this team, great communication channels and relationships are formed that can be utilized for the future!  In addition, a much better insight into overall processes (as well cross-department impact) may be realized through these team discussions.

Webinar: Managing Multi-Sourced Lab Informatics Teams - CSols, Inc.

Clarify the Intent

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).  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 at the same understanding and will go a long way in easing any discomfort in members who have never experienced a requirements generation exercise.


Though it can be thought of as another “boring” document generation exercise, the generation of user requirements for an informatics solution 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

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 generating these requirements, the payoff will be well worth it.  The alternative could be devastating!

presentation: creating solid user requirements

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

Share Now:

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.