This page contains a Flash digital edition of a book.
Technical issues / Functional/user requirements Building a Smart Laboratory 2012


become increasingly rare in the lab landscape. However, the progressive introduction


of information technology into laboratories has been conducted in a piecemeal fashion, generally leading to the adoption of best-of- breed solutions for specific lab requirements. Te consequence is that laboratories have a plethora of systems that were not necessarily designed to work together, that are based on proprietary platforms and that adopt proprietary data formats. Te deployment of an electronic laboratory


notebook has been the catalyst for an increasing demand for systems integration. Up to now, integration has largely been achieved by bolting together various disparate systems that meet specific functional requirements and which oſten end up as a group of interconnected silos. Although this has been an important stepping-stone that has oſten delivered significant productivity benefits, it comes at the cost of significant effort and with the worrying legacy of the on-going management of a custom solution. Tis extensive adoption of technology


presents a difficult ROI calculation due to the growing need to transfer and share data seamlessly between systems. Despite all of the outstanding advances, it would be quite revealing to add up the total cost to industry to create and maintain custom solutions and middleware to solve integration problems, in addition to how much time has been wasted in not having direct and immediate access to data that is locked in inaccessible systems and how many risks have been taken in using all kinds of crude and insecure methods of transferring data. To some extent this is a legacy issue as most of our current systems were not necessarily designed to work together. In addition, systems oſten do a poor job of separating the content from the functionality, thus making the integration challenge even more difficult. Te demand for integration has been a


technology driver behind a number of merger and acquisition activities in the informatics market during the past couple of years. Tis may well lead to progress, although it will be tempered by the fact that scientists usually opt


for best-of-breed products, rather than single vendor solutions. Te lack of integration standards is a


well-established problem in the laboratory world, and there’s very little evidence of a universal solution emerging. Ongoing efforts with AnIML[12]


and the Pistoia Alliance[13]


yet to gain enough inertia to make a realistic difference. SiLA (Standardization in Lab Automation)[14]


have is attempting to introduce new


interfaces and data management standards to facilitate the integration of lab automation systems. Te IQ Consortium (International Consortium for Innovation and Quality in Pharmaceutical Development) is an international association of pharmaceutical and biotechnology companies aiming to advance innovation and quality in the development of pharmaceutical products through scientifically-driven best practices and standards.[15]


for Laboratory Automation[16]


Furthermore, the Institute is proposing


a collaborative programme of activity to drive the development and adoption of data interchange standards.


Functional/user requirements


Gathering user or functional requirements is one of the key tasks, usually assigned to the project team, for providing 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. In principle, the requirements


specification should define what the solution must do both in


30


terms of its functionality and how it should perform in the customer’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; • 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;


• 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 and diagrams showing relevant workflows. It 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 telling 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 can envision the potential. Unfortunately, the committee process can create complex systems, reflect compromises


“Gathering user or functional requirements is one of the key tasks for providing a specification against which potential solutions can be evaluated”


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