Template:LIMSpec for Cannabis Testing/Introduction/Introduction and methodology

1. Introduction

Introduction and methodology

Introduction

Merriam-Webster defines a "specification" as "a detailed precise presentation of something or of a plan or proposal for something."^[1] In other words, an existing or theoretical product, concept, or idea is presented in detail for a particular audience. In a broad sense, detailing the specifics about a project, concept, or idea to others is just common sense. This applies just as well to the world of software development, where a software requirements specification is essential for preventing the second most commonly cited reason for project failure: poor requirements management.^[2]

In fact, the ISO/IEC/IEEE 29148:2018 standard (a conglomeration of what was formerly IEEE 830 and other standards) is in place to help specify "the required processes implemented in the engineering activities that result in requirements for systems and software products" and provide guidelines for how to apply those requirements.^[3] The standard describes the characteristics that make up quality software requirement development, including aspects such as^[4]:

correctly describing system behavior;
effectively removing ambiguity from the language used;
completely covering the system behavior and features;
accurately prioritizing and ranking the requirements; and
unequivocally ensuring the requirements are testable, modifiable, and traceable.

A requirement typically comes in the form of a statement that begins with "the system/user/vendor shall/should ..." and focuses on a provided service, reaction to input, or expected behavior in a given situation. The statement may be abstract (high-level) or specific and detailed to a precise function. The statement may also be of a functional nature, describing functionality or services in detail, or of a non-functional nature, describing the constraints of a given functionality or service and how it's rendered. An example of a functional software requirement could be "the user shall be able to query either all of the initial set of databases or select a subset from it." This statement describes specific functionality the system should have. On the other hand, a non-functional requirement, for example, may state "the system's query tool shall conform to the ABC 123-2014 standard." The statement describes a constraint placed upon the system's query functionality. Once compiled, a set of requirements can serve not only to strengthen the software requirements specification, but the requirements set can also be used for bidding on a contract or serve as the basis for a specific contract that is being finalized.^[5]

Over the years, a wide variety of companies, consultants, and researchers have compiled public and private software requirements specifications for laboratory informatics systems. These compiled lists of requirements for how a given laboratory informatics solution should be developed, delivered, and maintained have changed as technology and user demand evolved. Often times, these requirements documents turn into a mix of "wishlist" requirements from potential and active clients, as well as regulation-mandated requirements. The wishlist items aren't necessarily ignored by developers, but they do in fact have to be prioritized as "nice to have" or "essential to system operation," or something in between.^[6]^[7]^[8] While this reasonable mix of requirements has served informatics software developers well^[9], sometimes a fresh approach is required.

Methodology

Many years ago, a list of software specifications for the development of a laboratory information management system (LIMS), referred to as LIMSpec, was developed. It has seen many iterations over the years, including a complete overhaul in 2019. That overhaul was an attempt to look less at the wishlists of laboratories and more directly at what requirements current regulatory schemes, industry standards, and organizational guidelines place on the ever-evolving array of laboratory informatics systems being developed today. At its core is the ASTM E1578-18 Standard Guide for Laboratory Informatics, along with numerous other relevant regulations, standards, and guidance that shape how a compliant laboratory informatics system is developed and maintained.

This LIMSpec for cannabis testing takes the base LIMSpec 2022 R2 document and tweaks it to address the informatics needs of a cannabis testing laboratory. This includes laboratories testing not only leaf and flower material but also their constituents, and the products made from them, regardless of whether derived from low-THC hemp, medical cannabinoids or a more psychoactive recreational cannabis plant. To be fair, this LIMSpec for cannabis testing doesn't differ much from the base LIMSpec 2022 document; there's a surprising amount of feature crossover. How those features are implemented to address the needs of a cannabis testing laboratory, however, can truly separate a generic all-purpose LIMS from one that is developed to fully address those needs. (In the next section you'll see what LIMS requirements best support a cannabis testing lab and how LIMSpec addresses those requirements.)

When reviewing LIMSpec, you'll notice that in almost every case a requirement statement has at least one linked regulation, standard, or guidance item. A rare few requirements (e.g., a secure portal for third-party access) will not have such an item, meaning no regulatory- or standards-based mandate could be found to support the system requirement. In a few cases, the standard backing a requirement is a proprietary standard. In those cases, the standard was either purchased for review or heavily researched using supporting documentation, and the link goes to the acquisition page for the standard. In other cases, some standards-based sources have been intentionally omitted from the LIMSpec. For example, the AOAC International Official Methods of Analysis are both proprietary and more or less prohibitively expensive. In other cases such as the U.S. Food Emergency Response Network, the Laboratory Response Network, and the American Association for Laboratory Accreditation (A2LA), they unfortunately don't make their standardized procedures open to the public.

Finally, note that a Microsoft Word version of this specification is available to you, the reader. For more about this downloadable version, see the final chapter of this guide.