How to Get the LIMS You Need - Part 3

Part 1 of this blog series reviewed the importance of identifying your LIMS requirements to ensure the success of your project. We also reviewed some key considerations for identifying those needs. In Part 2 we looked at how understanding your requirements helps you choose the correct LIMS solution and supplier. In Part 3 we discuss the importance of documenting your requirements accurately, concisely, and most importantly with clarity.

The importance of clarity

In Parts 1 and 2 on this blog series the problem of ill-defined, imprecise, and incomplete requirements were identified, and some techniques touched on to help avoid these issues. However, an equally important, but possibly rather dry sounding subject, is how those requirements are formally documented.

Robin Sharma the Canadian writer on leadership has said “clarity precedes success" while Julian Barnes in his novel Flaubert’s parrot says, "Mystification is simple; clarity is the hardest thing of all”.

When it comes to documenting LIMS requirements clarity is key to ensuring that the requirements are:

• Complete and comprehensive
• Understandable to suppliers and those responsible for implementing the solution
• Easily manageable

Creating a Requirements Document

Requirements should be recorded using some form of requirements document. Many software products exist to help create and manage requirements and may be useful for large projects, but often it is possible to use standard tools such as Word or Excel. Generally, it is a good idea to have separate requirements documented for different parts of the system. For example, it will probably make sense to have different requirements documents for sample registration, result entry and sample approval and reporting, in addition there may well be separate sections within each requirements document.

When creating the document, it can often be a good idea to put the requirements into context by, for example, writing an overview of the functionality and its purpose and defining any assumptions or dependencies that have been used when defining the requirements. It is also important to define specific terms, especially if they are particular to your organization or way of working.

As a minimum each requirement should have a unique identifier, a priority, and a description.

Unique identifier

Assigning a unique identifier to each requirement makes traceability much simpler. When formal testing takes place, each requirement can be associated with a specific test or test script to show that all requirements have been completed and tested. The identifier can be used to associate user requirements with functional requirements produced by the supplier ensuring that all agreed requirements have been included. Linking requirements to the business can also help ensure that each requirement is aligned with the business case (if they aren’t why is time and money being spent on implementing them?).

Priority

When requirements are identified some will be more important than others and it is vital that these are prioritized for inclusion in the system, as budget and time constraints usually mean that not all identified requirements can be implemented. Any prioritization system must be simple and easy to understand. Scoring systems that, for example, use a scale of 1 – 10 should be avoided as it is almost impossible to describe what the difference between a score of 6 and 7, and somehow there is always something that ends up as a 6.5!

MoSCoW prioritization can be used instead to identify Must Have, Should Have, Could Have and Won’t Have requirements.

• Must Have – The system will not work or be accepted without it. Must Have requirements can be seen as defining the minimum viable product (MVP)
• Should Have – These will add value to the system, but it will work without them. If they cannot be included, they may be included in a later phase
• Could have – Nice to have features which may be included; they are the first to be dropped if changing constraints impact the project once it has started
• Won’t have – These are requirements which have been identified but rejected for inclusion in the system

A question is sometimes asked along the lines of “if a requirement has a priority of won’t have why bother including it in a requirements document?” The importance of including won’t have requirements is this; if someone subsequently demands to know why the system doesn’t do something, the requirements document can be used to show if the items had been identified, discussed and rejected, or if it had actually been overlooked.

Description

The most important part of any requirement definition is the description; however, it is also the most difficult and the area where clarity is key. Fundamentally any requirement should be understandable by someone who is not necessarily familiar with your organization, laboratory, or function.

There are a few obvious considerations to bear in mind when describing a requirement

Avoid the use of jargon.

Definitions of jargon include “obscure and often pretentious language marked by circumlocutions and long words” and “confused, unintelligible language”. The use of language like this will not help clarity and understanding.

Define technical terms.

When using technical terms that have a definite meaning, but which may not be generally understood make sure their meaning is clear

Describe all the requirements (There is no such thing as an implied requirement).

All requirements should be identified and documented. It is not acceptable, on finding that a feature or function has not been included in a system, to say that its necessity was implied by another requirement.

Avoid the use of etc.

Using etc. at the end of a definition indicates that there are further requirements that have not been identified or that whoever identified the requirement does not fully understand it.

Each requirement should be discrete.

The scope of each requirement should cover just a single item or point. If we look at the simple example of sample approval it may seem that this is a single function that could be covered by a single requirement. However, it can be broken down into a number of different items such as:

On Sample approval

• The status of the sample will be set to approved
• The date and time of approval must be recorded
• The ID of the person who carried out the approval must be recorded

Each of these should be recorded as a separate requirement. Doing so clarifies the needs but also makes subsequent changes or modification to the requirements simpler.

Adhering to the above guidelines will help to define a set of complete, understandable and manageable requirements. It is true that they may end up being a long and, quite frankly, rather dull read - no one is ever going to win a Nobel prize for literature for a set of LIMS requirements. However, that’s not the point, what clear, concise and complete requirements will do is help set your project up for success.

Summary

This three part series has guided you through the importance of identifying your LIMS requirements to ensure the success of your project in Part 1. The significance of understanding those requirements in helping you to choose the right LIMS solution for your needs was discussed in Part 2. In this final part (Part 3) we discussed the importance of documenting your requirements accurately and providing a common method of prioritizing those requirements to ensure success. Together they form a solid methodology to get the LIMS you need for your laboratory and avoid many of the pitfalls that can affect LIMS implementations.