Practical considerations
Building a Smart Laboratory 2018
PRACTICAL CONSIDERATIONS
Specifying and building the smart laboratory
This 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. The 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 G
athering 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 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.
Te requirements may include, but are not limited to: n General business requirements; n User/functional requirements; n IT requirements; n Interface requirements; n Regulatory issues; n Data management requirements; n Error handling;
36
n Reporting requirements; and n Performance requirements.
Te criteria that define required performance may include: n Access control and security; n Look and feel; n Robustness; n Scalability; n Ease of use; n Technical performance/response times; and n 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
www.scientific-computing.com/BASL2018
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
