A. Customers (users) set the rules

1. Vendors/suppliers must provide systems to meet user needs
   
2. Users must assist in defining system requirements
   
3. Development office must work with users to determine trade-offs between desired technical functionality, cost of system, and schedule for implementation
   
4. Users must participate in the development of standards
   
5. Continual development updates should be provided to the users
   1. Users thereby understand system capabilities and limitations and their expectations are properly managed

B. Define system with minimum requirements

1. Enhancements should be provided once system is stable, NOT before
   
   1. Completely assess cost and schedule impacts of any requirements changes
      
   2. Requirements changes to one function may adversely affect other functions under development
      
2. Early attention to system architecture and engineering detail is essential
   
3. Define and fix requirements before going into design development

C. Contract to build an integrated system

1. Mandating a national AFIS system for all users from the top down is easier and cheaper than building a system to accommodate AFISs already in operation
2. Understand that integration of complex systems is NOT a trivial exercise
   
3. When contracting with separate suppliers/vendors with separate functionality, ensure all segments are integrated
   1. Require integrated architecture
      
   2. Give priority to system requirements and engineering
      
   3. Understand and communicate to users the complexity of assembling segments into a system
   4. Build system incrementally
      1. Demonstrate and test proof of concept and functionality a step at a time
      2. Build on successes
      3. Make new capabilities visible to users
      4. Allows for realistic performance measures
4. The more Commercial Off The Shelf (COTS) software used, the greater the integration risk

D. Collect dependable and realistic data (metrics)

1. Information collected from:
   1. Earned Value Reports
   2. Actual cost data
   3. Program Management Reviews
   4. Master schedule data
   5. Risk lists
   6. Vendor/supplier reports

E. Enforce strong Program Control

1. Configuration Management practices
   
1. Manage and control of system baselines, configuration, and required changes during development
   
2. Limit configuration changes during development to those required to meet functionality goals
   
2. Quality Assurance practices
   
   1. Audit system physical and functional configuration during specific milestones during development
      
   2. Ensure development system passes QA criteria before proceeding to next milestone
      
3. Manage contractors to the contract
   
   1. Require specific plans for program completion
      
   2. Do not allow unspecified, undirected or unfunded changes to the system under development
      
   3. Use contract incentives to get system that meets system requirements, within projected cost and schedule

A. Obtain necessary data from regional/provincial users

1. Process is challenging
   
2. Surveys often provide inaccurate and misleading data
   
3. Direct assist visits provide most accurate assessments of current status
   
4. Even if region/province has same vendor/supplier AFIS, every solution is unique

B. Develop comprehensive understanding of regional/provincial systems

1. Must be developed BEFORE embarking on development of a connectivity solution
   
2. Conduct detailed analysis of each region’s/province’s configuration
   
3. Conduct detailed assessment of requirements
   
4. Design and develop solution for each application

C. Develop national communications network

D. Security plans and procedures should be established early in the program

1. Conduct comprehensive surveys of state-of-the-market to determine attainable security policy and encryption methods
   1. Completely understand requirements and capabilities before selecting solution
   2. Encryption slows transmission times
   3. Some encryption packages require third parties to hold public and private keys; management overhead could be significant

E. International connectivity takes time

1. Different AFIS vendors = proprietary encoding/matching algorithms = lack of commonality/interoperability
2. For encryption, establish if products (software and hardware) are importable/exportable by countries involved
   1. Determine key management policy and responsibilities
3. Different AFIS vendors = proprietary encoding/matching algorithms= lack of commonality/interoperability
   1. Requires commonly accepted international standard
      1. ANSI/NIST standard is inherently flexible and is currently accepted worldwide, but has several different implementations
         1. Language differences
         2. Fingerprint card size, orientation, and layout
         3. Requires adaptation for scanning and subsequent transmission
         4. Type 2 record differences, such as international versus NCIC country codes and manadatory and optional data fields (e.g., imperial versus metric height/weight)
      2. INT-I being supported as international standard by INTERPOL AFIS Expert Group
      3. Translation software would translate outgoing messages from a national AFIS standard to INT-1 and incoming messages from INT-1 to the national AFIS standard
      4. Different image capture procedures
         1. Affects number of minutiae points extracted; matcher performance; database size; overall storage required; and back-up time
            1. Image resolutions (250/500/1000 dpi)
            2. Image capture techniques (nail-to-nail versus flats)