LII:LIMSpec/Introduction and methodology - Revision history

Shawndouglas at 19:33, 22 January 2022

2022-01-22T19:33:01Z

← Older revision		Revision as of 19:33, 22 January 2022
Line 1:		Line 1:
			==Introduction and methodology==
	{{LIMSpec/Introduction and methodology}}		{{LIMSpec/Introduction and methodology}}

	==References==		==References==
	{{Reflist\|colwidth=30em}}		{{Reflist\|colwidth=30em}}

Shawndouglas at 00:39, 20 January 2022

2022-01-20T00:39:59Z

← Older revision		Revision as of 00:39, 20 January 2022
Line 1:		Line 1:
	{{LIMSpec/Introduction and methodology}}		{{LIMSpec/Introduction and methodology}}

			==References==
			{{Reflist\|colwidth=30em}}

Shawndouglas: Changing to template

2022-01-20T00:38:15Z

Changing to template

Show changes

Shawndouglas at 20:16, 4 December 2021

2021-12-04T20:16:27Z

← Older revision		Revision as of 20:16, 4 December 2021
Line 15:		Line 15:

	What follows is 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. What does the United States' [[21 CFR Part 11]] have to say about how your [[laboratory information management system]] (LIMS), [[laboratory information system]] (LIS), [[electronic laboratory notebook]] (ELN), and other systems operate? What does the European Union's Annex 11 dictate in those same regards? The following five chapters list those requirements, supported by one or more regulations, standards, and guidelines. The final chapter discusses how to best put this requirements specification to use.		What follows is 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. What does the United States' [[21 CFR Part 11]] have to say about how your [[laboratory information management system]] (LIMS), [[laboratory information system]] (LIS), [[electronic laboratory notebook]] (ELN), and other systems operate? What does the European Union's Annex 11 dictate in those same regards? The following five chapters list those requirements, supported by one or more regulations, standards, and guidelines. The final chapter discusses how to best put this requirements specification to use.


	==Methodology==		==Methodology==

Shawndouglas: /* Methodology */ Added ELAP

2020-12-23T21:18:50Z

Methodology: Added ELAP

← Older revision		Revision as of 21:18, 23 December 2020
Line 85:		Line 85:
	* [https://www.aphis.usda.gov/animal_health/nahln/downloads/MessagingQuickGuide.pdf NAHLN HL7 Messaging Quick User Guide]		* [https://www.aphis.usda.gov/animal_health/nahln/downloads/MessagingQuickGuide.pdf NAHLN HL7 Messaging Quick User Guide]
	* [https://www.aphis.usda.gov/aphis/ourfocus/animalhealth/lab-info-services/nahln/ct_nahln_it NAHLN Information Technology System]		* [https://www.aphis.usda.gov/aphis/ourfocus/animalhealth/lab-info-services/nahln/ct_nahln_it NAHLN Information Technology System]
			* [https://www.wadsworth.org/sites/default/files/WebDoc/MM%20guidance%20procedure%20for%20Micro%20iDOC-120320.pdf New York Department of Health ELAP Microbiology Protocol]<br />
	* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf NIST 800-53, Rev. 4]		* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf NIST 800-53, Rev. 4]
	* [http://www.oecd.org/chemicalsafety/testing/oecdseriesonprinciplesofgoodlaboratorypracticeglpandcompliancemonitoring.htm OECD GLP Principles]		* [http://www.oecd.org/chemicalsafety/testing/oecdseriesonprinciplesofgoodlaboratorypracticeglpandcompliancemonitoring.htm OECD GLP Principles]

Shawndouglas: /* Introduction */ Cite fix

2020-02-01T20:09:09Z

Introduction: Cite fix

← Older revision		Revision as of 20:09, 1 February 2020
Line 12:		Line 12:
	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.<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=20 September 2019}}</ref>		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.<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=20 September 2019}}</ref>

	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.<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=20 September 2019}}</ref><ref name="BurrissSoftware07">{{cite web \|url=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 \|accessdate=~~20 September 2019~~}}</ref> While this reasonable mix of requirements has served informatics software developers well<ref name="HofmannRequire01">{{cite journal \|title=Requirements engineering as a success factor in software projects \|author=Hofmann, H.F.; Lehner, F. \|journal=IEEE Software \|volume=18 \|issue=4 \|pages=58–66 \|year=2001 \|doi=10.1109/MS.2001.936219}}</ref>, sometimes a fresh approach is required.		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.<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=20 September 2019}}</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=02 February 2020}}</ref> While this reasonable mix of requirements has served informatics software developers well<ref name="HofmannRequire01">{{cite journal \|title=Requirements engineering as a success factor in software projects \|author=Hofmann, H.F.; Lehner, F. \|journal=IEEE Software \|volume=18 \|issue=4 \|pages=58–66 \|year=2001 \|doi=10.1109/MS.2001.936219}}</ref>, sometimes a fresh approach is required.

	What follows is 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. What does the United States' [[21 CFR Part 11]] have to say about how your [[laboratory information management system]] (LIMS), [[laboratory information system]] (LIS), [[electronic laboratory notebook]] (ELN), and other systems operate? What does the European Union's Annex 11 dictate in those same regards? The following five chapters list those requirements, supported by one or more regulations, standards, and guidelines. The final chapter discusses how to best put this requirements specification to use.		What follows is 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. What does the United States' [[21 CFR Part 11]] have to say about how your [[laboratory information management system]] (LIMS), [[laboratory information system]] (LIS), [[electronic laboratory notebook]] (ELN), and other systems operate? What does the European Union's Annex 11 dictate in those same regards? The following five chapters list those requirements, supported by one or more regulations, standards, and guidelines. The final chapter discusses how to best put this requirements specification to use.

Shawndouglas: /* Methodology */ Added two new items

2019-12-10T20:43:58Z

Methodology: Added two new items

← Older revision		Revision as of 20:43, 10 December 2019
Line 21:		Line 21:
	This 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, this should definitely be considered a work in progress, with more to be added with additional public and private comment on missing sources.		This 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, this should definitely be considered a work in progress, with more to be added with additional public and private comment on missing sources.

	That said, this ~~first~~ revision taps into the following sources:		That said, this second revision taps into the following sources:

			* [https://www.law.cornell.edu/cfr/text/5/930.301 5 CFR Part 930.301]
	* [https://www.law.cornell.edu/cfr/text/7/part-331 7 CFR Part 331]		* [https://www.law.cornell.edu/cfr/text/7/part-331 7 CFR Part 331]
	* [https://www.law.cornell.edu/cfr/text/9/part-121 9 CFR Part 121]		* [https://www.law.cornell.edu/cfr/text/9/part-121 9 CFR Part 121]
Line 84:		Line 85:
	* [https://www.aphis.usda.gov/animal_health/nahln/downloads/MessagingQuickGuide.pdf NAHLN HL7 Messaging Quick User Guide]		* [https://www.aphis.usda.gov/animal_health/nahln/downloads/MessagingQuickGuide.pdf NAHLN HL7 Messaging Quick User Guide]
	* [https://www.aphis.usda.gov/aphis/ourfocus/animalhealth/lab-info-services/nahln/ct_nahln_it NAHLN Information Technology System]		* [https://www.aphis.usda.gov/aphis/ourfocus/animalhealth/lab-info-services/nahln/ct_nahln_it NAHLN Information Technology System]
			* [https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf NIST 800-53, Rev. 4]
	* [http://www.oecd.org/chemicalsafety/testing/oecdseriesonprinciplesofgoodlaboratorypracticeglpandcompliancemonitoring.htm OECD GLP Principles]		* [http://www.oecd.org/chemicalsafety/testing/oecdseriesonprinciplesofgoodlaboratorypracticeglpandcompliancemonitoring.htm OECD GLP Principles]
	* [https://www.ams.usda.gov/datasets/pdp/pdp-standard-operating-procedures USDA Administrative Procedures for the Pesticide Data Program (PDP)]		* [https://www.ams.usda.gov/datasets/pdp/pdp-standard-operating-procedures USDA Administrative Procedures for the Pesticide Data Program (PDP)]

Shawndouglas at 17:45, 20 September 2019

2019-09-20T17:45:53Z

← Older revision		Revision as of 17:45, 20 September 2019
Line 1:		Line 1:
	==Introduction==		==Introduction==
	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=20 September 2019}}</ref> 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.<ref name="BiegRequire14">{{cite web \|url=https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/requirements-management.pdf \|format=PDF \|title=Introduction \|work=Requirements Management: A Core Competency for Project and Program Success \|author=Bieg, D.P. \|publisher=Project Management Institute \|page=3 \|date=August 2014 \|accessdate=20 September 2019}}</ref>		[[File:Systems Requirement Analysis.jpg\|700px\|right]]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=20 September 2019}}</ref> 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.<ref name="BiegRequire14">{{cite web \|url=https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/requirements-management.pdf \|format=PDF \|title=Introduction \|work=Requirements Management: A Core Competency for Project and Program Success \|author=Bieg, D.P. \|publisher=Project Management Institute \|page=3 \|date=August 2014 \|accessdate=20 September 2019}}</ref>

	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.<ref name="ISO29148">{{cite web \|url=https://www.iso.org/standard/72089.html \|title=ISO/IEC/IEEE 29148:2018 \|publisher=International Organization for Standardization \|date=November 2018 \|accessdate=20 September 2019}}</ref> The standard describes the characteristics that make up quality software requirement development, including aspects such as<ref name="SeibertHowDoYou11">{{cite web \|url=https://hubtechinsider.wordpress.com/2011/07/28/how-do-you-write-software-requirements-what-are-software-requirements-what-is-a-software-requirement/ \|title=How do you write software requirements? What are software requirements? What is a software requirement? \|work=HubTechInsider \|author=Seibert, P. \|date=28 July 2011 \|accessdate=20 September 2019}}</ref>:		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.<ref name="ISO29148">{{cite web \|url=https://www.iso.org/standard/72089.html \|title=ISO/IEC/IEEE 29148:2018 \|publisher=International Organization for Standardization \|date=November 2018 \|accessdate=20 September 2019}}</ref> The standard describes the characteristics that make up quality software requirement development, including aspects such as<ref name="SeibertHowDoYou11">{{cite web \|url=https://hubtechinsider.wordpress.com/2011/07/28/how-do-you-write-software-requirements-what-are-software-requirements-what-is-a-software-requirement/ \|title=How do you write software requirements? What are software requirements? What is a software requirement? \|work=HubTechInsider \|author=Seibert, P. \|date=28 July 2011 \|accessdate=20 September 2019}}</ref>:

Shawndouglas at 17:18, 20 September 2019

2019-09-20T17:18:12Z

← Older revision		Revision as of 17:18, 20 September 2019
Line 10:		Line 10:
	* unequivocally ensuring the requirements are testable, modifiable, and traceable.		* 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 ~~can~~ 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=20 September 2019}}</ref>		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.<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=20 September 2019}}</ref>

	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.<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=20 September 2019}}</ref><ref name="BurrissSoftware07">{{cite web \|url=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 \|accessdate=20 September 2019}}</ref> While this reasonable mix of requirements has served informatics software developers well<ref name="HofmannRequire01">{{cite journal \|title=Requirements engineering as a success factor in software projects \|author=Hofmann, H.F.; Lehner, F. \|journal=IEEE Software \|volume=18 \|issue=4 \|pages=58–66 \|year=2001 \|doi=10.1109/MS.2001.936219}}</ref>, sometimes a fresh approach is required.		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.<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=20 September 2019}}</ref><ref name="BurrissSoftware07">{{cite web \|url=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 \|accessdate=20 September 2019}}</ref> While this reasonable mix of requirements has served informatics software developers well<ref name="HofmannRequire01">{{cite journal \|title=Requirements engineering as a success factor in software projects \|author=Hofmann, H.F.; Lehner, F. \|journal=IEEE Software \|volume=18 \|issue=4 \|pages=58–66 \|year=2001 \|doi=10.1109/MS.2001.936219}}</ref>, sometimes a fresh approach is required.

	What follows is 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. What does the United States' [[21 CFR Part 11]] have to say about how your [[laboratory information management system]] (LIMS), [[laboratory information system]] (LIS), [[electronic laboratory notebook]] (ELN), and other systems operate? What does the European Union's Annex 11 dictate in those same regards? The following five chapters list those requirements, supported by one or more regulations, standards, and guidelines.		What follows is 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. What does the United States' [[21 CFR Part 11]] have to say about how your [[laboratory information management system]] (LIMS), [[laboratory information system]] (LIS), [[electronic laboratory notebook]] (ELN), and other systems operate? What does the European Union's Annex 11 dictate in those same regards? The following five chapters list those requirements, supported by one or more regulations, standards, and guidelines. The final chapter discusses how to best put this requirements specification to use.



	==Methodology==		==Methodology==
Line 95:		Line 93:
	* [https://vichsec.org/en/guidelines/general VICH GL53]		* [https://vichsec.org/en/guidelines/general VICH GL53]
	* [https://extranet.who.int/prequal/content/who-technical-report-series WHO Technical Report Series, #986, Annex 2 ]		* [https://extranet.who.int/prequal/content/who-technical-report-series WHO Technical Report Series, #986, Annex 2 ]

			Each requirement statement has at least one linked regulation, standard, or guidance item. In some cases, the standards covered are proprietary. 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 sources have been intentionally omitted. 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 and Laboratory Response Network, they simply don't make their standardized procedures open to the public.

	==References==		==References==
	{{Reflist\|colwidth=30em}}		{{Reflist\|colwidth=30em}}

Shawndouglas at 17:08, 20 September 2019

2019-09-20T17:08:05Z

← Older revision		Revision as of 17:08, 20 September 2019
Line 9:		Line 9:
	* accurately prioritizing and ranking the requirements; and		* accurately prioritizing and ranking the requirements; and
	* unequivocally ensuring the requirements are testable, modifiable, and traceable.		* 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 can 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=20 September 2019}}</ref>

	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.<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=20 September 2019}}</ref><ref name="BurrissSoftware07">{{cite web \|url=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 \|accessdate=20 September 2019}}</ref> While this reasonable mix of requirements has served informatics software developers well<ref name="HofmannRequire01">{{cite journal \|title=Requirements engineering as a success factor in software projects \|author=Hofmann, H.F.; Lehner, F. \|journal=IEEE Software \|volume=18 \|issue=4 \|pages=58–66 \|year=2001 \|doi=10.1109/MS.2001.936219}}</ref>, sometimes a fresh approach is required.		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.<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=20 September 2019}}</ref><ref name="BurrissSoftware07">{{cite web \|url=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 \|accessdate=20 September 2019}}</ref> While this reasonable mix of requirements has served informatics software developers well<ref name="HofmannRequire01">{{cite journal \|title=Requirements engineering as a success factor in software projects \|author=Hofmann, H.F.; Lehner, F. \|journal=IEEE Software \|volume=18 \|issue=4 \|pages=58–66 \|year=2001 \|doi=10.1109/MS.2001.936219}}</ref>, sometimes a fresh approach is required.