# How to Create a LIMS Requirements Checklist By the end of this article you will be able to build a complete LIMS requirements checklist for your laboratory, score candidate systems against it, and hand the result to vendors or your IT department as a defensible specification. You do not need any software installed to start. You need a spreadsheet application, one or two hours of interviews with the people who actually run your workflows, and a written description of your current sample handling process on paper or in a notebook. A [laboratory information management system](/knowledge/bioinformatics/lims-explained-lab-information-management-systems) (LIMS) is software that tracks samples, associates them with metadata and results, automates workflows, and reports outcomes. Published studies across [clinical microbiology](/knowledge/diagnostics/microbiology/clinical-microbiology-from-specimen-collection-to-pathogen-identification), transfusion medicine, biobanking, forensics, and structural biology show that the difference between a LIMS that helps and one that frustrates comes down almost entirely to how well the laboratory defined its requirements before selecting or configuring the system [1][2][3][4][5]. Up to 70 percent of clinical decisions in high-resource settings rest on laboratory results, which is one reason laboratories that implemented a LIMS saw improved throughput, fewer transcription errors, and standardized reporting [1]. This article walks through the full process, gives you a reusable template, and shows a filled-in example you can adapt. ## What a Requirements Checklist Is and Why It Fails When Skipped ![Seven ordered steps for building a LIMS requirements checklist, from mapping workflows through versioning and reuse.](/article-images/illustrations/lims-requirements-checklist-seven-step-checklist.webp) A requirement is a single, testable statement about what the system must do, must not do, or must satisfy as a constraint. A LIMS requirements checklist is the organized collection of those statements, grouped by category, prioritized, and written so that each one can be marked met, partially met, or not met for any candidate system. The software engineering literature is blunt about what happens when this step is done poorly. Deficient requirements often produce defects in the delivered software, and those defects are difficult and expensive to fix after deployment. Requirements engineering research consistently identifies clear, well-written specifications as the foundation of a successful system [6]. In a laboratory context, the cost of a vague specification is concrete. A review of transfusion laboratories in the United Kingdom found that laboratories were running many different LIMS products and versions, that systems were not always updated because of resource constraints, and that respondents named interoperability and improved functionality as their main unmet requirements for transfusion safety [2]. Those are exactly the gaps a written checklist forces you to confront before purchase rather than after. There is also a research integrity argument. A review of information systems for research management in biology concluded that before adopting any tool, a team should understand the purpose of implementation, define the set of tasks the tool must solve, and formulate requirements from that definition [7]. Work in chemistry research [data management](/blog/guides/data-management-basics-principles-processes-and-best-practices) makes a parallel point: electronic lab notebooks and LIMS improve data handling, but only when teams agree on minimum information standards for what must be recorded [8]. Your checklist is where that agreement gets written down. ## Step 1: Map Your Workflows Before You Write a Single Requirement A checklist built from a vendor brochure describes the vendor's imagination. A checklist built from your workflows describes your laboratory. Spend one to two hours walking through each of your core processes end to end. For a clinical microbiology laboratory, that might be specimen receipt, accessioning, culture, identification, antimicrobial susceptibility testing (AST), result validation, and reporting. For a crystallography facility, it is crystallization, crystal treatment, shipping to a synchrotron, data collection, structure refinement, and deposition to the [Protein Data Bank](/blog/guides/protein-data-bank) (PDB) [4]. For a biobank, it is consent, collection, processing, storage, aliquoting, and release of samples to researchers [5]. For each workflow step, write down four things: 1. What information enters the step (a sample ID, a plate position, an instrument output file) 2. What information leaves the step 3. Who performs the step and on what instrument or workstation 4. What currently goes wrong at this step (lost aliquots, manual transcription, missing metadata) The failures you list in item 4 become your highest-priority requirements. When the National Health Laboratory in Timor-Leste implemented a microbiology LIMS, the documented gains were reduced transcription errors, standardized AST reporting, improved sample throughput, and better data management [1]. Each of those maps to a workflow step where paper-based handling had failed. When Cameroon deployed the PlaCARD platform for COVID-19 testing, the system covered preanalytical, analytical, and postanalytical phases, and turnaround time fell from a median of 2 days to 1 day after scale-up [9]. The lesson for your checklist is to make sure every phase of testing, not just the analytical step, appears in your workflow map. ## Step 2: Organize Requirements Into Standard Categories Use a fixed set of categories so nothing gets forgotten and so different evaluators can work in parallel. A category set that matches the published laboratory literature looks like this: 1. Sample and inventory management 2. Workflow and protocol execution 3. Data capture, metadata, and standards 4. Integrations and interoperability 5. Compliance, security, and audit 6. Users, roles, and training 7. Infrastructure and hosting 8. Reporting and data export 9. Vendor support, maintenance, and cost Each category earns its place from the literature. Sample tracking and traceability are the core of biobank information management, where donor information, processing history, and sample use must all be linked [5]. Metadata quality is the central recommendation of the MaRDA working groups for materials microscopy, which advise that instruments should capture comprehensive metadata about operators, specimens, instrument conditions, and data formation, using standardized vocabularies and community identifiers [10]. Interoperability is the top unmet requirement reported by transfusion laboratories [2]. Integration with electronic medical records requires attention to data standards, medical terminology, privacy, data entry design, and communication protocols [11]. Compliance requirements appear throughout regulated laboratory work, including Good Laboratory Practice (GLP) and Good Manufacturing Practice (GMP) settings mapped to U.S. Food and Drug Administration (FDA) 21 CFR Part 11 and ISO/IEC 17025 [12], and laboratories under the College of American Pathologists (CAP) inspection cycle face substantial ongoing compliance workloads that software can ease [13]. ## Step 3: Write Each Requirement in a Testable Format Use a consistent record structure for every line in your checklist. A LIMS requirements checklist format that works in any spreadsheet has these columns: - **ID**: a stable identifier such as SAM-01 or INT-03 - **Category**: which of the nine categories the item belongs to - **Statement**: one sentence, written as "The system shall..." - **Priority**: Must, Should, or Could - **Acceptance criterion**: how you will verify the requirement in a demo or a test - **Source**: who asked for it and in which workflow step - **Status**: met, partially met, not met, or not evaluated Here is a LIMS requirements checklist template entry in YAML, which is a plain-text format that pastes cleanly into configuration tools, issue trackers, and version control: ```yaml id: SAM-01 category: sample_and_inventory statement: >- The system shall assign a unique barcode identifier to every sample at accessioning and print the label on demand. priority: Must acceptance_criterion: >- During the vendor demo, register a mock sample, print a barcode, scan it, and confirm the correct record opens within 3 clicks. source: Workflow map step 1, accessioning bench lead status: not_evaluated ``` When you load a set of these into a checklist and evaluate a vendor, the output should look like this: ```text ID Priority Requirement (abridged) Status SAM-01 Must Barcode at accessioning met SAM-02 Must Parent-child aliquot linkage partially met WF-01 Must Configurable workflow per protocol met INT-02 Must HL7 interface to hospital EMR not met SEC-01 Must Role-based access control met SCORE Must requirements met: 3 of 4 (75%) ``` Three writing rules keep requirements testable. First, one requirement per line. "The system shall manage samples and integrate with instruments" is two requirements wearing one coat. Second, avoid the word "and" inside a statement where it joins two verifiable behaviors. Third, phrase the acceptance criterion as an action someone can perform in a demonstration or a trial instance, not as a feeling. "The interface should be user-friendly" is not a requirement. "A bench technician with no prior exposure shall register a sample in under 60 seconds using only the vendor's standard training materials" is. ## Step 4: Prioritize With MoSCoW The MoSCoW method sorts requirements into four buckets: Must have, Should have, Could have, and Won't have (this time). Apply it ruthlessly. A useful discipline is to cap Must items at roughly 40 percent of the total, because a checklist where everything is Must cannot discriminate between candidates, which defeats the purpose of a research software comparison. Use these defaults when you are unsure: | Priority | Use it when | Example | |--|--|--| | Must | The laboratory cannot operate legally or safely without it | Audit trail, sample traceability, access control | | Should | Major efficiency or quality gain, workaround exists | Instrument integration, automated AST rule checking | | Could | Nice to have, no current pain | Custom dashboards, mobile app | | Won't | Out of scope for this procurement | Genomics pipeline execution, billing | Two requirements deserve automatic Must status in nearly every laboratory. Traceability of samples from receipt to final disposition is the defining function of a LIMS in biobanking and clinical work [5]. Interoperability with the other systems your organization already runs, whether hospital information systems, electronic medical records, or instrument software, is the requirement most often named as unmet in real deployments [2][11]. ## Step 5: Validate the Checklist Against Stakeholders Hand the draft to every role that touched your workflow map and ask one question per category: "Is anything you do every day missing from this list?" This step catches the silent requirements, the ones nobody thinks to mention because they seem obvious. A crystallography facility that ships crystals to a synchrotron must capture the exchange of metadata between the home laboratory and the beamline, a requirement that never surfaces unless someone walks the shipping step with you [4]. A microbiology laboratory in a setting with unreliable internet connectivity must specify offline tolerance, a requirement that surfaced as a real challenge during LIMS implementation in Timor-Leste [1]. Requirements engineering research calls the practice of linking each requirement back to its origin traceability. Pre-requirements traceability connects a requirement to the interview, meeting note, or legacy system that produced it, and a systematic review of 77 published articles identifies stakeholder origin as a core use case that improves later validation and change management [14]. The Source column in the template above does this job cheaply. When a vendor asks why you need parent-child aliquot linkage, you can answer with a named workflow step and a named person, and when someone proposes a new requirement in month six, you can trace whether it came from evidence or from a demo that impressed one person. Automated and AI-assisted tools for checking requirement quality are an active research area, including machine learning approaches that identify privacy and security requirements in specification documents [15][6]. These are emerging aids, not substitutes for the stakeholder interviews in this step. ## Step 6: Score Candidates With the Checklist ![Worked weighted score calculation showing Candidate B winning at 85.5 percent because it meets every Must item.](/article-images/illustrations/lims-requirements-checklist-weighted-score.webp) Once the checklist exists, it becomes your scoring instrument for a research software comparison. For each candidate system, work through the checklist in a scripted demonstration where you drive, not the vendor. Mark every Must, Should, and Could item. Then compute a weighted score: ```text Weighted score = (2 × Must met) + (1 × Should met) + (0.5 × Could met) Candidate A: Must 18/20, Should 7/10, Could 3/6 = (2 × 18) + (1 × 7) + (0.5 × 3) = 45.5 of 55.0 → 82.7% Candidate B: Must 20/20, Should 5/10, Could 4/6 = (2 × 20) + (1 × 5) + (0.5 × 4) = 47.0 of 55.0 → 85.5% ``` Candidate B wins despite fewer Should items because it clears every Must. That is the intended behavior of the weighting. Any candidate that fails a Must item is disqualified regardless of its total, because Must items encode safety, compliance, and legal constraints. In transfusion laboratories, the whole point of demanding better LIMS functionality is error prevention, and haemovigilance reports have identified cases where the LIMS could have prevented an error but did not [2]. The same scoring approach applies when the "vendor" is an open-source tool or a general-purpose research platform. Reviews of research management systems describe options ranging from project trackers like Trello and Redmine to discipline-specific systems like OpenBIS, SEEK, and Galaxy, and note that the right choice depends on the tasks you defined in Step 1 [7]. A [molecular biology](/blog/careers/molecular-biology) group whose main pain is data versioning across collaborators has a different Must set than a clinical laboratory whose main pain is result reporting, which is why the checklist, not a generic "best software for researchers" list, should drive the decision. ## Step 7: Version the Checklist and Reuse It Store the checklist in a plain-text or spreadsheet format under version control, and record the date and the candidate version against every evaluation. Requirements evolve. When a laboratory digitizes further, new requirements appear. The roadmap for a digital nonclinical pathology laboratory describes a stack where a GLP-validated LIMS connects to whole slide scanners, image management systems, and AI-based decision support, a level of integration that only becomes specifiable after the core LIMS requirements are stable [16]. Emerging work on cloud platforms that merge LIMS and quality management system (QMS) functions, with modules for computer software assurance and automated SOP generation, likewise extends rather than replaces a structured requirement set [12]. ## A Worked LIMS Requirements Checklist Example Here is a compressed example for a small research biobank, showing the level of detail that survives contact with a vendor demo. It uses the same format as the template above. ```yaml - id: SAM-03 category: sample_and_inventory statement: >- The system shall record every storage position change (freezer, rack, box, position) with a timestamp and user ID. priority: Must acceptance_criterion: >- Move a mock aliquot in the demo, then generate a history report showing the old and new positions with timestamps. source: Workflow step 4, biobank manager status: not_evaluated - id: DAT-02 category: data_metadata_standards statement: >- The system shall store user-defined metadata fields per sample type and export them in CSV and JSON. priority: Must acceptance_criterion: >- Add two custom fields to a sample type, register a sample, export to CSV and JSON, and verify both fields appear. source: Workflow step 2, data manager, FAIR requirement status: not_evaluated - id: INT-01 category: integrations statement: >- The system shall export an annotated sample manifest consumable by the sequencing facility's submission portal. priority: Should acceptance_criterion: >- Vendor shows a real export or a documented sample file matching the facility's published manifest template. source: Workflow step 6, [genomics core](/blog/guides/genomics-core) liaison status: not_evaluated ``` Notice what the acceptance criteria have in common: every one can be executed inside a 60-minute vendor demonstration using mock data. If a requirement cannot be demonstrated this way, either reword it or move its verification into a paid pilot phase, which you should list as its own requirement under vendor support. ## Common Mistakes and Limitations **Copying another laboratory's checklist wholesale.** Requirements encode your workflows, your instruments, and your regulatory context. A clinical microbiology laboratory in a hospital with an electronic medical record needs integration requirements that a university research lab does not [11]. Borrow structure, not content. **Writing requirements about features instead of outcomes.** "The system shall have a dashboard" says nothing testable. State what a person must be able to see or do. **Treating the checklist as a procurement document only.** The same checklist drives configuration, user acceptance testing, and training. Laboratories that skip it often rediscover their requirements as complaints after go-live, and the deployment literature records implementation challenges, including infrastructure limitations and the need for ongoing technical support, that a requirements process would have surfaced in advance [1][9]. **Ignoring hosting and infrastructure constraints.** Unreliable internet connectivity was a documented challenge in at least one national laboratory LIMS deployment [1]. If your building has the same problem, offline tolerance and local data storage are Must items, not footnotes. **Assuming compliance is the vendor's problem.** No commercially available LIMS fully automates regulatory compliance and inspection readiness, and laboratories still devote substantial personnel time to preparing for inspections [13]. Write explicit requirements for audit trails, electronic signatures where applicable, and document control, and verify them yourself [12]. **Skipping the Won't-have list.** Saying explicitly what the system will not do this time, such as running analysis pipelines or handling billing, prevents scope arguments during implementation. **One limitation to keep in mind.** Published implementation studies report outcomes from specific laboratories under specific conditions, so their turnaround times, error reductions, and deployment dates describe what happened there, not guarantees for your laboratory. Your own baseline measurements, taken from the workflow map in Step 1, are the numbers that matter for judging your own project. ## Frequently Asked Questions ### What is a LIMS requirements checklist? It is a structured document listing every capability and constraint your laboratory needs in a laboratory information management system, with each item written as a single testable statement, assigned a priority, and paired with an acceptance criterion. You use it to compare candidate systems and to verify a deployment. ### How long should a LIMS requirements checklist be? Most laboratories need between 60 and 150 requirement lines across the nine standard categories, with no more than about 40 percent marked Must. Length varies with workflow complexity, but any item you cannot write an acceptance criterion for should be cut or rewritten. ### What is the difference between a LIMS and an electronic lab notebook? A LIMS manages samples, workflows, and structured records across a laboratory, while an electronic [lab notebook](/knowledge/molecular-biology/lab-notebook) (ELN) captures free-form experimental context and protocols at the bench. Many laboratories need both, and published guidance treats them as complementary tools for research data management [8]. ### Is there a single best software for researchers looking for a LIMS? No. Published reviews compare systems as different as Trello, Git, Redmine, SEEK, OpenBIS, and Galaxy, and conclude that the right choice follows from the tasks you define and the requirements you write, not from a universal ranking [7]. Use your checklist as the ranking instrument. ### Do I need a requirements checklist if I choose an open-source LIMS? Yes. Open-source removes license cost, not implementation cost, and you still must specify workflows, metadata, hosting, and support. Community recommendations for LIMS implementation include cost and benefit comparison and stakeholder role definitions precisely because these decisions do not disappear with a free license [10]. ### What compliance items belong in the checklist? At minimum, audit trails, user authentication, role-based access control, data backup and recovery, and document control. Laboratories operating under GLP or GMP should map requirements to FDA 21 CFR Part 11 and ISO/IEC 17025 explicitly [12], and clinical laboratories should address inspection readiness requirements directly [13]. ### How do I write an acceptance criterion if we have not bought the system yet? Write the criterion as an action performable in a vendor demonstration or trial instance using mock data, for example registering a sample, moving an aliquot, and generating a history report. If the capability cannot be shown in a demo, specify a pilot-phase verification instead. ### How often should I update the checklist? Review it at three fixed moments: before vendor selection, before user acceptance testing, and at each major version upgrade. Add new requirements when workflows, instruments, or regulations change, and keep the version history so every change traces back to a named source. ## Sources 1. [Implementation of a Laboratory Information Management System (LIMS) for microbiology in Timor-Leste: challenges, mitigation strategies, and end-user experiences.](https://pubmed.ncbi.nlm.nih.gov/39825312/) 2. [SHOT UK Collaborative Reviewing and Reforming IT Processes in Transfusion (SCRIPT) survey: Laboratory information management systems: Are we ready for digital transformation?](https://pubmed.ncbi.nlm.nih.gov/37776051/) 3. [Laboratory Information Management Systems for Forensic Laboratories: A White Paper for Directors and Decision Makers](https://doi.org/10.2172/892806) 4. [Managing macromolecular crystallographic data with a laboratory information management system.](https://pubmed.ncbi.nlm.nih.gov/38984903/) 5. [Information Management.](https://pubmed.ncbi.nlm.nih.gov/28353261/) 6. [Advances in automated support for requirements engineering: a systematic literature review](https://doi.org/10.1007/s00766-023-00411-0) 7. [Laboratory information systems for research management in biology.](https://pubmed.ncbi.nlm.nih.gov/38213703/) 8. [Minimum Information Standards in Chemistry: A Call for Better Research Data Management Practices.](https://pubmed.ncbi.nlm.nih.gov/36347644/) 9. [Improving the management and security of COVID 19 diagnostic test data with a digital platform in resource-limited settings: The case of PlaCARD in Cameroon.](https://pubmed.ncbi.nlm.nih.gov/36812594/) 10. [MaRDA FAIR materials microscopy and LIMS data working groups’ community recommendations](https://doi.org/10.1557/s43577-025-00882-2) 11. [INTEGRASI ELECTRONIC MEDICAL RECORD (EMR) DENGAN LABORATORY INFORMATION SYSTEMS (LIS) DAN PICTURE ARCHIVING AND COMMUNICATIONS SYSTEM (PACS)](https://doi.org/10.33560/.V6I2.191) 12. [A cloud-enabled LIMS-QMS platform with large language model-assisted standard operating procedure generation for GLP/GMP-aligned theranostics laboratory operations.](https://pubmed.ncbi.nlm.nih.gov/42901382/) 13. [A-296 Automating Laboratory Compliance: AI-Driven LIMS Enhances CAP Inspection Readiness and Quality Assurance](https://doi.org/10.1093/clinchem/hvag086.241) 14. [A systematic literature review of pre-requirements specification traceability](https://doi.org/10.1007/s00766-023-00412-z) 15. [Automatic identification of privacy and security requirements: a systematic literature review](https://doi.org/10.1007/s00766-025-00455-4) 16. [Building a nonclinical pathology laboratory of the future for pharmaceutical research excellence.](https://pubmed.ncbi.nlm.nih.gov/37598916/)