XSEC-2.1 (client/server) suite Requirement specification

Security System Based On Face And Voice Recognition.

Table of Contents

• 1. Introduction
• 2. Environment
  • 2.1 Users
  • 2.1.1 End User
  • 2.1.2 Administrator
  • 2.2. Technology – Devices and Software
  • 2.3. Technology -  Support for Java
• 3. Functionality
  • 3.1 Core
  • 3.2 Base
  • 3.3 Optional
• 4. Software architecture
• 5. Usability
• 6. Quality: goals and verification
• 7. Legal issues

1. Introduction

This document is the Requirement specification for a security authentication system based on faces and voice recognition, to be implemented by the XPEG project group. The intended usage of the security system is a tool for authenticating users for any valuable resource over any network of computers. "Real-life" factors like user face variations and voice variations of a user are considered important in the design. It is very important to state the fact that real life implementations of such security systems are highly application specific. Hence the main aim of the project should be to design software that shows how robust human face and voice are in recognition. A successful implementation of XSEC will be used to target the enterprise and thereby implement it in some real life security system. The aspects related to network efficiency like network load and network security are the main factors that need to be handled.

The main goals of the project are to:

• To design a template that authenticates the user based on his face and voice. This template could then be used to implement a functional security system on a real-life resource.

• To make the training of the system for user face and voice as simple as possible.

• To make a platform (operating system) independent network based authentication system.

• To implement an easily extensible, portable and configurable system.

The aim of this document is to state the requirements which will characterize a product that fulfills these goals. Requirements are set on the design, documentation and architecture.

The project entails a great deal of prototyping and research as it is very much charting the territory of artificial intelligence. The volatility of the project has strong implications on the requirements. As a basic risk managing strategy the requirements have been divided into three levels:

Core requirements: These requirements are considered to be primary and should be met upon completion of the project. Core requirements are tagged with Core or the word "shall*" (notice the asterisk!) in the documentation.

Base requirements: Secondary requirements, of which as many as possible, within reasonable effort, should be met upon project completion. Base requirements are tagged with Base or the word "should*" in the documentation.

Optional features: Things that may be implemented if there is time and/or they require little effort compared to their usefulness. This list includes "wild ideas", some of which will be totally beyond the scope of the project, thought up during customer meetings. Optional features are tagged with optional or the word "may*" in the documentation.

The rest of this document is structured as follows: Section 2 deals with the environment of the users, use cases and technical environment. Following this in section 3 are the functional requirements set on the network based security system. Requirements for documentation and research can be found in section 4.  The software architecture, including performance requirements, is described in section 5. Section 6 presents the usability considerations of the project. In section 7 the quality goals and methods of their verification are presented. Section 8 briefly discusses legal rights to use the project outcome. 

2. Environment

2.1 Users

The system shall* support users who can speak English and who have a normal human face feature. The system may* be extended to support any user who can just speak out in any language.

2.1.1 Core: End User.

The security system is used by a person, who is familiar with basic computer usage. The person trains the system for recognizing his face as well as voice by performing simple mouse clicks. Training shall* involve taking a few face snap shots (not more than 10) as will be specified in the final user manual followed by a speaking session where the user is meant to speak out some English words (not more than 20). Recognition shall involve taking a snapshot of the face and spelling a few words (not more than 3).

2.1.2 Core: Administrator.

The administrator should be a technically sound computer professional who shall maintain the user database that holds valuable information related to voice and face features of the users. The administrator should have a sound knowledge of the network installation and network security aspects related to XSEC-2.0.

2.1.3 Base: Corporation using the security system.

The corporate user wants the software to be easy to install and maintain, preferably on a common platform such as Windows XP or generic UNIX. The whole process of authentication shall* be performed trough a GUI, which would provide an easy to use training and recognition process.

2.2 Technology – Devices and Software.

The computer on which the software runs should be connected to a digital camera such as a web camera (XSEC shall be designed to make the best out of cheaply available, low quality cameras) and a good quality microphone. The software shall* run on Windows NT, Windows XP and shall* be easily portable to Linux.

2.3 Technology – Support for Java.

As java is the preferred language for the development of a platform independent implementation hence the software should* be built completely in Java. Sun’s Java runtime environment should* be the target runtime environment. The choice of java is also driven by the fact that the software can be easily ported to an array of hand held electronic devices like mobile phones. Media framework support for java shall* be the additional requirement. 

3. Functionality

This section lists the functional requirements. The requirements are divided into core, base and optional sections.

3.1 Core

A voice and face Trainer: The software shall* include an easy to use trainer GUI. Training should be as simple as possible.

A Recognizer: The software shall* include a recognizer GUI. The recognition process should involve a minimum user effort and a very high recognition rate.

An Admin Tool: There shall* be an administrator to XSEC-2.0 who shall* be provided a network based GUI tool that should* handle a minimum basic administrating facilities like assigning new users, making modifications on present users, deleting users, blocking users: other additional facilities may* be added in order to make the task of the administrator more lucid.

3.2 Base

A database manager. The database manager shall* be a GUI that makes essential features of a database available in easy to use formats.

3.3 Optional

Camera settings GUI. The user should be provided an easy to use interface that helps configure the camera.
Microphone settings GUI. The user should be provided an easy to use interface that helps configure the microphone.
Help.  There shall* be ample, full and easy to understand help guides that should give usage related information to any user of XSEC.

4. Software architecture

The main requirements on the software architecture is that it should be simple and clear, yet easily extensible and sufficiently versatile. The architecture should be highly modular with separate modules for voice and face training and recognition. The modularity should help provide a final system that could use either the voice or face or a combination of both as a security system. The software shall* run in Microsoft windows and should* be portable to various other operating systems. A port to UNIX may* also be made.

5. Usability

A high level of usability is important on the end user side. Thus, the recognizer shall* be designed with high usability and transparency in mind. On the training side the software shall* be easy to use for the end user guided by a technician. One shall* remember that although trainer module requires a supervision of a technician, there is no excuse for an overly complex or badly designed UI.

Another aspect is "usability of the code and documentation", i.e. the code and the documentation shall* be, among other things, clear to follow, lucid and well structured.

6. Quality: goals and verification

This section lists the 10 most important quality goals of the project and methods of verifying their success upon project completion.
   

7. Legal issues

The XPEG team will hold license to the outcome (documents, source code, binaries etc...) of the project.