Difference between revisions of "User:Shawndouglas/sandbox/sublevel3"
Shawndouglas (talk | contribs) (Blanked the page) |
Shawndouglas (talk | contribs) |
||
| Line 1: | Line 1: | ||
Choosing laboratory informatics software for your lab ... | |||
Opening text goes here. | |||
==2.1 Evaluation and selection== | |||
===2.1.1 Technology considerations=== | |||
===2.1.2 Cybersecurity considerations=== | |||
===2.1.3 Regulatory compliance considerations=== | |||
===2.1.4 Features and functions=== | |||
===2.1.5 Contract considerations (maintenance, support, warranty, and enhancements)=== | |||
===2.1.6 Cost considerations=== | |||
==2.2 Implementation== | |||
===2.2.1 Internal and external integrations=== | |||
==2.3 Maintenance and updates== | |||
==2.4 How a user requirements specification fits into the entire process== | |||
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>: | |||
* 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. | |||
This is where a requirements specification shines, not only for the software developer but also for those acquiring the software. A set of development requirements, compiled in the form of a software requirements specification, can serve to strengthen the software development process. For those acquiring the software, a set of user requirements, compiled in the form of a user requirements specification (URS), can be used for the selection and acquisition of software or a service.<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><ref name="SchmittUser18">{{cite journal |title=User Requirements Specifications–How Difficult Can It Be? |journal=Pharmaceutical Technology |author=Schmitt, S. |volume=42 |issue=11 |page=58 |year=2018 |url=http://www.pharmtech.com/user-requirements-specifications-how-difficult-can-it-be-0 |accessdate=09 January 2020}}</ref> In the case of the URS, the acquiring business can approach this several ways. The simple way would be to essentially take the vendor at the word in regards to what they say their system can and can't do, agreeing formally to their description and taking responsibility that it will cover all the applicable regulations required by your business. However, this method isn't comprehensive and leaves the business open to not being able to fully meet its goals.<ref name="SchmittUser18" /> | |||
The other method has the URS be specific to your business' needs. The process is more work but leaves less to chance. <ref name="SchmittUser18"> | |||
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> | |||
==References== | |||
{{Reflist|colwidth=30em}} | |||
Revision as of 18:51, 9 January 2020
Choosing laboratory informatics software for your lab ... Opening text goes here.
2.1 Evaluation and selection
2.1.1 Technology considerations
2.1.2 Cybersecurity considerations
2.1.3 Regulatory compliance considerations
2.1.4 Features and functions
2.1.5 Contract considerations (maintenance, support, warranty, and enhancements)
2.1.6 Cost considerations
2.2 Implementation
2.2.1 Internal and external integrations
2.3 Maintenance and updates
2.4 How a user requirements specification fits into the entire process
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.
This is where a requirements specification shines, not only for the software developer but also for those acquiring the software. A set of development requirements, compiled in the form of a software requirements specification, can serve to strengthen the software development process. For those acquiring the software, a set of user requirements, compiled in the form of a user requirements specification (URS), can be used for the selection and acquisition of software or a service.[5][6] In the case of the URS, the acquiring business can approach this several ways. The simple way would be to essentially take the vendor at the word in regards to what they say their system can and can't do, agreeing formally to their description and taking responsibility that it will cover all the applicable regulations required by your business. However, this method isn't comprehensive and leaves the business open to not being able to fully meet its goals.[6]
The other method has the URS be specific to your business' needs. The process is more work but leaves less to chance. Cite error: Closing </ref> missing for <ref> tag[7][8]
References
- ↑ "specification". Merriam-Webster. Merriam-Webster, Inc. https://www.merriam-webster.com/dictionary/specification. Retrieved 20 September 2019.
- ↑ Bieg, D.P. (August 2014). "Introduction" (PDF). Requirements Management: A Core Competency for Project and Program Success. Project Management Institute. p. 3. https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/requirements-management.pdf. Retrieved 20 September 2019.
- ↑ "ISO/IEC/IEEE 29148:2018". International Organization for Standardization. November 2018. https://www.iso.org/standard/72089.html. Retrieved 20 September 2019.
- ↑ Seibert, P. (28 July 2011). "How do you write software requirements? What are software requirements? What is a software requirement?". HubTechInsider. https://hubtechinsider.wordpress.com/2011/07/28/how-do-you-write-software-requirements-what-are-software-requirements-what-is-a-software-requirement/. Retrieved 20 September 2019.
- ↑ 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 20 September 2019.
- ↑ 6.0 6.1 Schmitt, S. (2018). "User Requirements Specifications–How Difficult Can It Be?". Pharmaceutical Technology 42 (11): 58. http://www.pharmtech.com/user-requirements-specifications-how-difficult-can-it-be-0. Retrieved 09 January 2020.
- ↑ Hirsch, J. (22 November 2013). "10 Steps To Successful Requirements Gathering". Phase2 Technology, LLC. https://www.phase2technology.com/blog/successful-requirements-gathering. Retrieved 20 September 2019.
- ↑ Burris, E. (2007). "Requirements Specification". CS451R, University of Missouri–Kansas City. University of Missouri–Kansas City. http://sce2.umkc.edu/BIT/burrise/pl/requirements/. Retrieved 20 September 2019.
