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.
