Beyond the laboratory Building a Smart Laboratory 2015


Practical considerations when specifying and building the smart laboratory


Tis chapter looks at how to build a smart laboratory; what approaches to take; and how to deal with potential problems. Inevitably, becoming ‘smart’ takes time, not only due to the level of investment required, but also because of the impact of change and the need to consider legacy requirements. Te rate of change in computer


technologies is far greater than in the laboratory and in business, and this unavoidably means that the computing experience in the laboratory will lag behind the consumer experience. Additionally, the constraints of IP, regulatory and legal compliance do not lend themselves to risk- taking when deploying new technologies. New laboratory informatics projects demand a carefully managed and risk-averse approach.


Functional/user requirements


Gathering user or functional requirements is one of the key tasks, usually assigned to the project team, to provide a specification against which potential solutions can be evaluated. Te task involves uncovering and understanding user-needs, distinguishing them from ‘wants’ and ‘nice to haves’, and aggregating the needs into a requirements specification. In this context, reference to ‘users’ includes not just end-users of the proposed system, but anyone who will interact with the system, or be


34


involved with inputs or outputs to the system. In order to do this, various methods may be used to gather needs and to prioritise them. In principle, the requirements specification


should define what the solution must do, both in terms of its functionality and how it should perform in the user’s environment. Te requirements may include, but are not


limited to: • General business requirements; • User/functional requirements; • IT requirements; • Interface requirements; • Regulatory issues; • Data management requirements; • Error handling; • Reporting requirements; and • Performance requirements. Te criteria that define required performance may include: • Access control and security; • Look and feel; • Robustness; • Scalability; • Ease of use; • Technical performance/response times; and • Technical support. All of these requirements are normally collated into a request for proposal (RFP) that will be submitted to potential vendors. Te RFP should also provide more general information, including an introductory description of the organisation and the major objectives of the project, as well as diagrams showing


relevant workflows. Te RFP may be preceded by a request for information (RFI) – a means of gathering information about a potential vendor’s products and services, which may be used to fine-tune a final list of vendors to whom the RFP may be submitted. Unfortunately, users are notoriously bad


at stating what they need. Most systems are specified or designed by a team or committee and the team/committee members tend to be volunteers who are committed to the concept of the system, enthused about the improvements it can bring, and are able to envision the potential. Unfortunately, the committee process can create complex systems and reflect compromises, and it is oſten the case that most problems come from people who don’t volunteer for the committee! By definition, the members of the team are more committed to the success of the project than those who are not directly involved. In their deliberations, project teams oſten develop a concept of a solution that is much more sophisticated than might be needed or, indeed, is economically justifiable. Typically the requirement-gathering phase


involves harvesting needs, wants and ideas from the potential user community, and then engaging in a prioritisation exercise to reduce the list to a specific set of requirements that form the basis of a request for proposal (RPF) to be presented to vendors. It is important that the business


requirements are fully clarified first of all; this ensures that the scope of the project is defined


www.scientific-computing.com/BASL2015


wavebreakmedia/Shutterstock.com


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44