User:Shawndouglas/sandbox/sublevel1

LIMSpec is an ever-evolving set of software user requirements specifications for laboratory informatics systems. The specification has grown significantly from its humble origins over a decade ago. Earlier versions of LIMSpec focused on a mix of both regulatory requirements and clients' "wishlist" features for a given system. The wishlist items haven't necessarily been ignored by developers, but they do in fact have to be prioritized by the potential buyer as "nice to have" or "essential to system operation," or something in between.^[1]^[2]^[3] This latest version is different, focusing strictly on a regulatory-, standards-, and guidance-based approach to building a specification document for laboratory informatics systems.

At its core, LIMSpec is rooted in ASTM E1578-18 Standard Guide for Laboratory Informatics. With the latest version released in 2018, the standard includes an updated Laboratory Informatics Functional Requirements checklist, which "covers functionality common to the various laboratory informatics systems discussed throughout [the] guide as well as requirements recommended as part of [the] guide." It goes on to state that the checklist "is an example of typical requirements that can be used to guide the purchase, upgrade, or development of a laboratory informatics system," though it is certainly "not meant to be exhaustive."

LIMSpec borrows from that requirements checklist and then adds more to it from a wide variety of sources. An attempt has been made to find the most relevant regulations, standards, and guidance that shape how a compliant laboratory informatics system is developed and maintained. However, the LIMSpec should also definitely be considered a continual work in progress, with more to be added as new pertinent regulations, standards, and guidance are discovered.

If you've never worked with a user requirements specification document, the concept remains relatively simple to grasp. Merriam-Webster defines a "specification" as "a detailed precise presentation of something or of a plan or proposal for something."^[4] Within this organized "plan or proposal" are requirements. 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 it may be 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]

The next chapter discusses the user requirements specification, using LIMSpec as an example. You'll learn how to shape such a specification to your laboratory's needs, how to issue the specification as a request for information (RFI), and how to get the most out of it when getting decision-related information from vendors. Additionally, in Appendix 1, you'll find a blank version of LIMSpec for practical use.