Difference between revisions of "User:Shawndouglas/sandbox/sublevel1"
From LIMSWiki
< User:Shawndouglas | sandbox
Jump to navigationJump to searchShawndouglas (talk | contribs) |
Shawndouglas (talk | contribs) |
||
| Line 1: | Line 1: | ||
In section 2.4 of this guide, we briefly discussed how a user requirements specification (URS) fits into the process of purchasing laboratory informatics solutions for your clinical or research laboratory. The URS has been viewed as a means for the purchaser to ensure their needs are satisfied by the functionality of the software. Traditionally, this has turned into a "wish list" for the purchaser, which while somewhat practical still lacks in its finesse. One common problem in this wishlist approach is the risk of "requirements creep," where more functionality than is truly necessary is desired, inevitably leading to a state where no vendor can meet all the wishlisted requirements. This makes selecting a solution even more difficult, particularly without significant prioritization skills.<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=18 November 2021}}</ref><ref name="BurrissSoftware07">{{cite web |url=http://sce2.umkc.edu/BIT/burrise/pl/requirements/ |archiveurl=https://web.archive.org/web/20190925003040/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=25 September 2019 |accessdate=18 November 2021}}</ref> | |||
Noting the potential problems with this wishlist approach, LIMSpec—a specification document for laboratory informatics solutions—took a new approach and turned to standards and regulations that drive laboratories of all types, as well as the data they manage. LIMSpec was rebuilt based on [[ASTM E1578|ASTM E1578-18]] ''Standard Guide for Laboratory Informatics'', as well as dozens of other standards and regulations, while still leaving room for a software buyer to add their own custom requirements for their industry or lab. | |||
The rest of this chapter examines the research, documentation, and acquisition process that clinical and research labs needing laboratory informatics solutions will want to go through, with an emphasis on the utility of a sound requirements specification. While LIMSpec is offered as a solid starting point, you don't strictly need to use LIMSpec to conduct this process; the information in this chapter can largely be applied with or without LIMSpec itself. | |||
==References== | ==References== | ||
{{Reflist|colwidth=30em}} | {{Reflist|colwidth=30em}} | ||
Revision as of 19:09, 22 January 2022
In section 2.4 of this guide, we briefly discussed how a user requirements specification (URS) fits into the process of purchasing laboratory informatics solutions for your clinical or research laboratory. The URS has been viewed as a means for the purchaser to ensure their needs are satisfied by the functionality of the software. Traditionally, this has turned into a "wish list" for the purchaser, which while somewhat practical still lacks in its finesse. One common problem in this wishlist approach is the risk of "requirements creep," where more functionality than is truly necessary is desired, inevitably leading to a state where no vendor can meet all the wishlisted requirements. This makes selecting a solution even more difficult, particularly without significant prioritization skills.[1][2][3]
Noting the potential problems with this wishlist approach, LIMSpec—a specification document for laboratory informatics solutions—took a new approach and turned to standards and regulations that drive laboratories of all types, as well as the data they manage. LIMSpec was rebuilt based on ASTM E1578-18 Standard Guide for Laboratory Informatics, as well as dozens of other standards and regulations, while still leaving room for a software buyer to add their own custom requirements for their industry or lab.
The rest of this chapter examines the research, documentation, and acquisition process that clinical and research labs needing laboratory informatics solutions will want to go through, with an emphasis on the utility of a sound requirements specification. While LIMSpec is offered as a solid starting point, you don't strictly need to use LIMSpec to conduct this process; the information in this chapter can largely be applied with or without LIMSpec itself.
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 18 November 2021.
- ↑ Burris, E. (2007). "Requirements Specification". CS451R, University of Missouri–Kansas City. University of Missouri–Kansas City. Archived from the original on 25 September 2019. https://web.archive.org/web/20190925003040/http://sce2.umkc.edu/BIT/burrise/pl/requirements/. Retrieved 18 November 2021.
