Biometrics

>>>>... 1  2  

In the above example, you will notice that the final choice of a biometric came relatively far down the list. We should only be considering this parameter once we have fully understood the business requirement and the potential benefit that adopting a biometric system might bring.

In defining the specification required, we should concern ourselves with perceived ease of use, acceptable transaction time, contingency measures for errors, where the biometric template should be stored, enrolment procedures and logistics and general compatibility and connectivity issues.

We should also understand the distinction between verification and identification. In short, verification is a straightforward one to one check whereby we are comparing a live biometric sample with a single stored template with a simple match or no match result. Identification is a different kettle of fish entirely as we may be seeking to compare a live biometric sample with hundreds, thousands or conceivably even millions of stored templates. The probability of errors multiplies with the number of templates in the database. Currently, there is really only one commercially available product which offers the promise of practical identification from a large database of templates. For the majority of applications we are probably going to be concerned with biometric verification..

We must also consider where the biometric template (the individual reference derived from taking a biometric sample or series of samples) will be stored. It may be that the template is stored on a token such as a chip card and input into the system by the user prior to verification. This would certainly allow for a large user base as well as a degree of portability between systems and would provide for automatic updating of templates if appropriate. Alternatively, we may decide to keep the templates on a central database and call them from either a card swipe or PIN input for comparison. This decision will naturally have an impact on system hardware and configuration - if we are maintaining a central database we had better be sure about our system host and it's communication with the biometric readers, not to mention the usual database maintenance and backup requirements.

Whilst we are on the subject of hardware, it is worth stressing the importance of understanding the cabling and line termination requirements of different communication protocols. Lack of attention to detail in this area can often result in temperamental performance and perceived intermittent faults which can be difficult to trace subsequently. Whilst this may seem like stating the obvious, it is surprising how often otherwise well designed systems are tripped over by poor installation practice.

You will have noticed that we have got a long way into this paper without trundling out the usual marketing promises about biometrics or contemplating the old chestnuts of false accepts / false rejects etc. This is deliberate - one can concentrate too much on the theoretical individual device performance issues. The performance we should concern ourselves with is that of the entire system, not individual components. In the real world, theoretical performance may be influenced greatly by other less quantitative parameters. For example, a badly sited reader which is difficult for individuals to use comfortably will almost certainly result in increased false rejects, even though the system may be functioning properly. Similarly, a lack of training or understanding among both system administrators and regular users will play havoc with your anticipated performance. The operational processes coupled to the perception and attitude of the user are as much of a performance criterion as biometric hardware specifications. These elements, coupled with overall system design and component performance combine to produce the Total System Performance (TSP). It is the TSP that we should have uppermost in our minds throughout the development and implementation of the entire project.

>>>>... 1  2