Difference between revisions of "User:Shawndouglas/sandbox/sublevel1"
Shawndouglas (talk | contribs) (Replaced content with "* {{cite journal |title=The impact of health information technology on patient safety |journal=Saudi Medical Journal |author=Alotaibi, Y.K.; Federico, F. |volume=38 |issue...") Tag: Replaced |
Shawndouglas (talk | contribs) |
||
| Line 1: | Line 1: | ||
[[File:LIMSpec.png|right]][[Book:LIMSpec 2019 R1|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.<ref name="AasemAnalysis10">{{cite journal |title=Analysis and optimization of software requirements prioritization techniques |author=Aasem, M.; Ramzan, M.; Jaffar, A. |journal=Proceedings from the 2010 International Conference on Information and Emerging Technologies |pages=1–6 |year=2010 |doi=10.1109/ICIET.2010.5625687}}</ref><ref name="Hirsch10Steps13">{{cite web |url=https://www.phase2technology.com/blog/successful-requirements-gathering |title=10 Steps To Successful Requirements Gathering |author=Hirsch, J. |publisher=Phase2 Technology, LLC |date=22 November 2013 |accessdate=23 November 2021}}</ref><ref name="BurrissSoftware07">{{cite web |url=http://sce2.umkc.edu/BIT/burrise/pl/requirements/ |archiveurl=https://web.archive.org/web/20190724173601/http://sce2.umkc.edu/BIT/burrise/pl/requirements/ |title=Requirements Specification |work=CS451R, University of Missouri–Kansas City |author=Burris, E. |publisher=University of Missouri–Kansas City |date=2007 |archivedate=24 July 2019 |accessdate=23 November 2021}}</ref> 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|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."<ref name="MWSpec">{{cite web |url=https://www.merriam-webster.com/dictionary/specification |title=specification |work=Merriam-Webster |publisher=Merriam-Webster, Inc |accessdate=23 November 2021}}</ref> 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.<ref name="MemonSoftware10">{{cite web |url=https://www.cs.umd.edu/~atif/Teaching/Spring2010/Slides/3.pdf |format=PDF |title=Software Requirements: Descriptions and specifications of a system |author=Memon, A. |publisher=University of Maryland |date=Spring 2010 |accessdate=23 November 2021}}</ref> | |||
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. | |||
==References== | |||
{{Reflist|colwidth=30em}} | |||
==Citation information for this chapter== | |||
'''Chapter''': 5. Resources for selecting and implementing informatics solutions: Part 3: Industry and community resources | |||
'''Title''': ''Laboratory Informatics Buyer's Guide for Medical Diagnostics and Research'' | |||
'''Edition''': 2022 Edition | |||
'''Author for citation''': Shawn E. Douglas | |||
'''License for content''': [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike 4.0 International] | |||
'''Publication date''': January 2022 | |||
<!--Place all category tags here--> | |||
Revision as of 19:07, 22 January 2022
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.
References
- ↑ Aasem, M.; Ramzan, M.; Jaffar, A. (2010). "Analysis and optimization of software requirements prioritization techniques". Proceedings from the 2010 International Conference on Information and Emerging Technologies: 1–6. doi:10.1109/ICIET.2010.5625687.
- ↑ Hirsch, J. (22 November 2013). "10 Steps To Successful Requirements Gathering". Phase2 Technology, LLC. https://www.phase2technology.com/blog/successful-requirements-gathering. Retrieved 23 November 2021.
- ↑ Burris, E. (2007). "Requirements Specification". CS451R, University of Missouri–Kansas City. University of Missouri–Kansas City. Archived from the original on 24 July 2019. https://web.archive.org/web/20190724173601/http://sce2.umkc.edu/BIT/burrise/pl/requirements/. Retrieved 23 November 2021.
- ↑ "specification". Merriam-Webster. Merriam-Webster, Inc. https://www.merriam-webster.com/dictionary/specification. Retrieved 23 November 2021.
- ↑ Memon, A. (Spring 2010). "Software Requirements: Descriptions and specifications of a system" (PDF). University of Maryland. https://www.cs.umd.edu/~atif/Teaching/Spring2010/Slides/3.pdf. Retrieved 23 November 2021.
Citation information for this chapter
Chapter: 5. Resources for selecting and implementing informatics solutions: Part 3: Industry and community resources
Title: Laboratory Informatics Buyer's Guide for Medical Diagnostics and Research
Edition: 2022 Edition
Author for citation: Shawn E. Douglas
License for content: Creative Commons Attribution-ShareAlike 4.0 International
Publication date: January 2022
