TARGET Functional Specifications

TARGET, (Transaction Approval & Review Gateway via Electronic Transmission) is intended to provide state of the art electronic forms processing capabilities for the University of Arkansas. It provides direct transaction data entry into an application at the point of data origin. These remotely entered transactions are held in a pending state until appropriate reviews and approvals are obtained. Once final approval has been electronically obtained the transaction is posted to the data base within the University's administrative information system.

Note: A transaction as used within the TARGET system represents a request for a specific and independent activity to be performed within an administrative system. This is normally to add, delete or update information, but may take various forms as dictated by the application implementing the activity.

The TARGET system itself only provides a framework for this processing. The administrative applications employing TARGET must be designed and written with the intent of using this framework and in accordance with specific requirements. The University is fortunate to be at the initial stage of developing new applications in the human resource, budgeting, purchasing, and financial areas which will be able to take advantage of TARGET capabilities. The TARGET components assume that applications that use these facilities will be developed using the Natural Secured Menus Architecture (NSM) and the internally developed Program Generator.

Purpose of this Document

These Functional Specifications were prepared in order to provide a clear and concise definition of the TARGET system. This document describes the features, capabilities, and internal components of TARGET. Initially it should serve as a basis for evaluating the proposed system including the integration of changes and enhancements suggested by development and user personnel. In the future it will provide the basic information necessary for an individual to develop an application using these facilities and provide insight into the operation and design of the system. Additionally, portions of this documentation should assist individuals in using applications that have been developed for TARGET. Therefore, those sections will be made available as online help.

Revision Identification

These specifications were first prepared and released in a preliminary form on November 4, 1991. They were updated and released as a "1st Draft" on January 21, 1993. They were updated to reflect the reality of functioning TARGET systems in March 1994.

Background

The need and demand for electronic forms to replace paper has existed for a number of years. Many parties moved ahead independently and developed screens, mimicing paper forms, where data could be entered. After entry, these screen images are printed and routed around campus the same as the paper forms they were to replace. In fact, nothing was replaced.

At other institutions this approach was extended to include the electronic routing of these forms and recording electronic approvals. With this approach real advantages begin to show up. However, most of these systems also fell short in that at the form's destination it was merely printed out and the data reentered into the true application. Eventually, these systems evolved to the point that the data was electronically extracted from the forms system, revalidated, and directly posted to the application data base.

The concept employed by TARGET is a complete integration of the data capture, routing, and approval process with the administrative application for which the data is being collected. The necessary conceptual design was formulated during the summer of 1991 and a prototype developed to test the technical feasibility of these concepts. This lead to the development of these Functional Specifications which were distributed internally within Computing Services in an effort to gain support and approval for the development and implementation of TARGET, specifically to be used in the BASIS projects. Following internal reviews and acceptance of the feasibility of the TARGET concept, it became obvious that it must be promoted to management and that a separate document was needed for that purpose. This lead to the development of a TARGET Proposal that was presented to the BASIS Steering Committee, Human Resource's Advisory Group, Purchasing's Advisory Group, Financial Affair's Advisory Group, and the Chancellor and Vice Chancellors. These presentations were made over the first five months of 1992 with the input provided used to revise the proposal. Progress on the TARGET concept then ceased as all resources were committed to the analysis and design of BASIS, the enhancement of the NSM architecture, and the development of a Program Generator with accompanying models. In January 1993 the need to proceed with the development of TARGET in support of BASIS development prompted the resurrection of this project and the updating of these specifications. Most TARGET facilities and support functions were developed in the summer and fall of 1993 in support of the Leave Accounting and GJIM applications.

Objectives

The objectives of the TARGET system can be summarized as follows:

Provide a core architecture to facilitate the implementation of applications which utilize a distributed data entry function combined with centralized reviews and approvals of those activities in a secure and auditable manner.
Employ this architecture in a generic manner such that it can be implemented in various administrative applications. This will result in:
- The consistent use and deployment of this technology across the University community resulting in reduced training and support requirements.
- Centralized management of control tables and all transactions.
- Cost savings in the development process due to the shared use of the design, program code and system utilities.
Meet the increasing demand for electronic forms processing with a system where:
- Data will be completely validated at the point of entry.
- Forms will not have to be printed in order to be processed.
- Transaction information will only have to be keyed once.
- The original transaction will become an integrated part of the central administrative information system and the University data base.
Implement these facilities using the Natural programming language within the applications development framework of the NSM Architecture, both of which are proven and established at the University.

Features

TARGET offers numerous special processing features. Many of these are the result of the total integration of the original transaction entry and review processing with the base application which manages the resulting data. Some of the features, facilities, and resulting benefits provided by TARGET include:

TARGET will replace the use of paper forms including the need to copy, file, mail, and process these forms. Electronic transactions will replace forms, but will contain the same information for directing actions and effecting changes within the administrative systems. This will result in cost savings in the areas of copying, internal mail distribution, personnel time, and storage.
Electronic transactions will be available for review and approval immediately online, eliminating the time lag associated with handling paper. The benefits of more timely processing of administrative transactions are intangible and difficult to quantify, but are obviously highly desirable.
The basic transaction data will be entered at the point of origin and will not be re-keyed by the administrative office responsible for the application. This will reduce the data entry work load within either the central offices or within Computing Services keypunch area. Within the originating offices, the data entry function replaces the manual entry or typing of the same information onto forms. The screens used to enter data are a part of the primary application and employ strict edits and validations, which results in more accurate, higher quality information. This improvement in the integrity of the data is one of the primary benefits of TARGET. Fewer errors will result in fewer corrections and reduce the number of times and the number of people that have to handle an item. This is expected to result in significant improvements in office efficiency and productivity.
The ability to track and review the status of transactions will be provided. Pending, completed, and rejected transactions will be maintained in a data base and be available online for review for a period of time as defined for each transaction. Transactions may be listed by requestor and transaction status, by reviewer (pending transactions only), and by data base entity affected (this is dependent on, and varies by, transaction). This simple and rapid access to, and availability of, data is expected to reduce the number of inquiries made by departments to the central offices. This will save time both within the departments and within the office previously required to research those questions.
Security definitions and the review process have been designed to operate based upon a desk concept rather than an individual's ID. These position based security and transaction routing definitions provide a significant advantage over individual based security in the administration area. When security is tied to an individual and that person is reassigned within the University, all their security (access privileges) and review (transaction routing) definitions must be reviewed and updated. Position based security is just that, all security definitions are tied to a desk associated with a job so that transfers and personnel changes do not necessitate mass changes within the system. Instead, the new person is assigned to the old desk and immediately given the appropriate access and authority. Desks are associated with departments who control the assignment of those desks to the employees of the departmnet. This scheme also allows one definition to service multiple individuals since several people may be authorized to work the same desk.
The association of a transaction with the desks that are to be assigned the review responsibility is the heart of the electronic approval system. The TARGET system uses one central routine to make this determination for all transactions based upon the type of transaction and the data being acted upon within the transaction (referred to as the review criteria). This approach provides maximum control over the process while allowing flexibility since the maintenance and enhancement of this function is localized to one routine.
An optional criteria for the establishment of the desks responsible for reviewing a transaction is the dollar value associated with the transaction. Different desks may be defined based upon this dollar value. This allows assigning review responsibility for some transactions based upon the spending authority of the desk.
Note: The dollar value is not the primary criteria which is used to determine which desk should review a transaction. Those criteria are unique and specific to each type of transaction and are described generically within TARGET as review criteria.
Another aspect of the establishment of the desks required to review a transaction is exception handling. If, using tables established for this purpose, the system cannot determine the desks of the reviewers based upon the transaction data, a default set of desks may optionally be defined to be established. This will ensure that a transaction is not prevented from being entered due to missing control information.
TARGET allows from 1 to 10 desks to be established for the review of each transaction, each assigned a review level. All approvals must be obtained at a lower level prior to the transaction being presented for review at a higher level. This will permit multiple individuals to review the same transaction at the same time while also holding a transaction back from review at higher levels until appropriate. Either or both options may be employed selectively.
Note: The term presented is used to mean that a transaction will either appear on a transaction list for review or will automatically be retrieved for review according to its time of entry, based upon the identity of the reviewer and the desk they are working.
Several features have been designed into the system to ensure that the review process is simple and effective.
- Transactions are presented in the chronological order that they were requested. Each may be approved, rejected or bypassed and the next transaction is retrieved automatically for processing.
- To aid in the identification of what is being changed by an update transaction (a transaction where new data overlays existing information), the screen will be designed with both the old and the new values present. The old field values are displayed only when they differ from the new entries. They may also be displayed using special features such as reverse video or color, if that capability is supported by the terminal or terminal emulation software. This will allow identification of a field whose old value was blank.
- A summary list function will be available to identify how many transactions of each type are pending an individual's review.
The edits and validations performed on the original transaction are invoked each time the transaction is reviewed and at the time of final posting. These consistent checks will help guarantee the integrity of the data within the University data base. Technically , these edits are performed by the same program each time, which minimizes code redundancy, the opportunity for programmer error, and the program maintenance effort when changes are required.
A complete audit trail is maintained for all transactions by recording the date, time, and individual performing any action on the transaction. This includes the original entry, all review actions performed, and the final disposition. This history of the transaction and review process will be available online via a pop-up window displayed by a centralized routine. Thus, complete document tracking and status checking information will be available to the originator, the reviewers, and all others with access rights to the transaction.
Transactions may have up to 12 comments associated with them. These short yellow stickies may be entered or viewed by anyone associated with the entry or review process. In this manner explanations and references outside the actual transaction may be communicated between the originator, the reviewers, and the central administrative office responsible for the application. A comment will be required whenever a transaction is rejected during the review process. Comments, similar to the transaction history, will be available via a pop-up window managed by a centralized routine.
Rejected transactions will require entry of a rejection code and a comment. In addition, a notice to the transaction originator is posted to a central data base file. These and other notices will be checked whenever a user signs on to Natural. The user is informed at that time of outstanding notices and each is displayed for their review and subsequent action.
The TARGET system is built on the philosophy that a desk is identified to review selected transactions as determined by the central administration. The individual or individuals associated with that desk should be the ones that normally perform that function, and it must be their responsibility to fulfill that role. TARGET will establish the appropriate transactions with that desk's ID for review expecting that review to occur. However, there will be times when all reviewers authorized to work a desk are absent and someone else must be designated to act on behalf of at least one of those reviewers. In this circumstance the TARGET system provides a proxy facility. Other individuals may be predefined, for a period of time, to act as a proxy for a desk for specific applications. The system will maintain as part of the audit trail when and who was acting as a proxy when action was taken on a transaction. The establishment of proxies will be allowed by any individual directly authorized to work a desk, but that authority must also be granted to a system administrator to be used in situations involving sickness or other unexpected absences.
Existing transactions, either completed or canceled, may be copied and used as the basis for entering a new transaction. The original transaction must first be selected for viewing and then the keys for the new transaction and the copy action specified. This option may be used to enter several transactions that are nearly identical or to retrieve a canceled transaction so that it can be modified and resubmitted. There may be situations where this feature cannot be provided due to the processing constraints of specific transactions.
All transactions cannot be maintained online indefinitly. The TARGET system provides facilities to archive, report to hardcopy or microfiche, and delete completed or cancelled transactions. Criteria for determining how long transactions are to be maintained online is based upon the transaction type and its status. In this manner varying needs of different systems can be accommodated while performing this critical function in a centralized, coordinated and timely manner.
Reports will be available to print all transactions of a selected type which occurred over a selected time period. This facility should assist in problem analysis and in meeting audit requirements.
Transaction data is stored in a generic format on the central transaction file. This means that individual fields such a salary, grade, or department are not identified as such. Instead, the applications that process the specific transactions redefine the generic data area according to their specific requirements. It can be expected that the transaction contents and generic format may change over time for a transaction. Therefore the system retains a transaction version with each transaction so that the format and processing requirements of the transaction will always be known. This will assist in the transition from new to old during periods of change.
The application functions used to view data will detect if there is a transaction pending for a data entity and will display the pending transaction information. It will also identify the originator and the date and time the transaction was entered. This means that the latest information will always be available, although the user must be aware that the transaction is still pending and has not received final approval.
The system has been designed to be as efficient as possible, attempting to minimize the data base I/O required to support the TARGET functions. For example, in normal cases only two data base calls will be required to establish the reviewers for a new transaction. This will help ensure that system response times are kept as short as possible.
The TARGET administrator may request a list of transactions that have been pending review longer than considered normal. The number of days a transaction may be pending before being reported may be customized via online definitions for each type transaction. With this facility, the system can be monitored to ensure that transactions are not lost within the system.
An e-mail interface will also be available where short messages regarding a transaction can be sent to another user. The subject of the e-mail will automatically be filled in with information identifying the transaction. This facility will be restricted to users who have a primary e-mail address identifyed within the Computing Services' directory of user IDs.

System Definition

Overview

The TARGET system assumes a complete integration of the distributed data entry function and its resulting electronic approval with the application where the data is processed. In this primary area, TARGET provides a framework and model for building application programs that incorporate electronic transaction processing features. This requires the application to be designed with the intent of using TARGET and that application programs are written according to standards and models provided by TARGET. Due to this tight integration, TARGET cannot be easily overlaid onto existing applications.

In another area, TARGET provides a set of core support functions which are used independently by all TARGET applications. The establishment of the desks that will be responsible for the review of a transaction is one example of a function performed by one of these independent routines. There are many others.

A third area is the TARGET administration system. This is an application that provides operational and management support of TARGET. Functions provided by this application include maintenance of control tables and transaction routing tables; routines to archive, print, and purge transactions; identification of transactions which have not been reviewed within a reasonable period; and the ability to establish proxies for others.

Note: Since each application and its requirements are unique, TARGET is described using generic references to application components such as data base entities, data base keys (data values which uniquely identify a data entity), and transactions. Such references will be found throughout TARGET documentation.

Processes

The primary processes for TARGET can be divided into two areas, those that are performed for a transaction within an application and those which support that operation via the TARGET administration system. Each of these is discussed briefly.

The transaction processor is the key component of a TARGET application and is responsible for performing all of the following functions:

Displaying existing application data and outstanding pending transactions when present.
Processing the original input data for a transaction complete with data edits, the enforcement of application security, and saving the transaction for later review, posting, and audit.
Presenting pending transactions for review and recording the results of the review (approval or rejection).
After all approvals have been obtained, posting the transaction to the appropriate application data base.

Several TARGET subprograms assist in this process by establishing the appropriate desks for review of the transaction, displaying and allowing entry of comments to be carried with the transaction, displaying a historical log of activities performed on the transaction, generating a notice to the requestor of the transaction if it is rejected, and verifying the proxy authority of a user.

The TARGET administration application provides facilities for managing the data required to drive TARGET systems. This includes maintenance of transaction control information, routing information (via review groups, criteria types, and review criteria), and proxies. Facilities are also provided to report transactions which have been pending too long and to archive, print, and purge transactions based upon defined parameters.

Data Requirements

The TARGET system uses 6 logical files, all critical to the operation of TARGET applications. Five of these are defined on one physical Adabas file while the TARGET transactions reside on an independent file. The name and purpose of each file follows.

TARGET-TRANSACTION

The contents of each TARGET transaction is maintained on this file along with other control and descriptive data. The transaction data itself is maintained in a generic field which each application must redefine for its own use. Associated transaction attributes include type identification, status information, a complete history of all actions taken including requestor and reviewers, and comments. This file also has several indexes to allow direct access to transaction data based upon different requirements.

TARGET-TXN-CONTROL

Several pieces of control information are maintained on this file and associated with each type of TARGET transaction. The transaction types are identified by the NSM application and command ID associated with the primary transaction processing program. A primary purpose for this control information is for the print, purge and archive process. The review criteria employed by each transaction type are also identified here for documentation purposes.

TARGET-CRITERION-TYPE

This file contains control information associated with each type of review criteria. This includes a description, a lengthy comment, and identification of the desks to be established if the criteria value is not found on the review criteria file.

TARGET-REVIEW-CRITERION

Review criteria are used to determine what desks should review a specific transaction based upon data associated within the transaction. Multiple criteria may be used for a single transaction and criteria may differ for each type transaction. Additionally, a single criterion may incorporate multiple data attributes associated with the transaction. Criteria are identified by an ID and a value range. The range is allowed to simplify the definition and maintenance of the criteria. Department, company/cost center, and/or action being performed (add versus delete) are examples of the type of data that might be used to establish the desks that will be responsible for reviewing a transaction. A dollar value is also associated with a review criterion so that different desks might be established based upon their spending authority.

TARGET-REVIEW-GROUP

The review group file permits the identification of a set of desks (from 1 to 10) by a group code. That set may then be associated with various review criteria by only entering the group code. An important part of the set is the review level assigned to each desk.

TARGET-PROXY

The proxy file contains the record of who may act as a proxy for a desk and application during a period of time. Reviewers who wish to grant authority for other individuals to act on their behalf do so by directly entering those definitions into this file using UAOPROX, which appears as command PROX in other applications. In emergency situations, the TARGET administrator is permitted to make entries to this file by using TAOPROX from within the TARGET administration application.

An entity relationship diagram depicting the relationships between these files can be found in Appendix B, "TARGET Entity Relationship Diagram". The file descriptions with complete element definitions including extensive comments are available in Appendix C, "TARGET File Definitions". An understanding of these files and elements is beneficial for working with TARGET.

Template Components

The following are Natural objects which serve as models, templates, or macros for the development of TARGET applications. These are the necessary building blocks which contain the base line logic required to implement a TARGET system. The UAF Program Generator specifications should be consulted for details regarding how to use these components.

Note: These pieces do not yet exist and are listed here for planning purposes.

Object	Description
PGZtmsf	The macro that generates a TARGET transaction processor function module. This macro generates an online Natural program which processes the screens used to display, enter, validate, review, and comment a transaction. The processing performed by these modules constitute the heart of the TARGET system.
TALtmsf	The data area containing the required data structures used by programs generated by PGZtmsf. The specific application data required for each transaction must be added in an appropriate manner to these structures.
TAMtmsf	A Natural map containing the basic screen elements and processing rules used for all transactions.
TANprint	A model print subprogram which contains the required components that allow reports to be generated of various transactions. The subprograms for each transaction are called by a main program depending on the type of transaction being processed.
PGZtltp	A macro to generate an online function which will list transactions pending review by a specified reviewer. This function will exist within each application.
PGZtlte	A macro to generate an online function which will list transactions which are targeted for a specified data base entity. An entity represents the various data objects which exist within applications: employees, accounts, timesheets, etc. This function allows viewing all completed, cancelled and pending transactions of a specific type for an entity.
PGZtltr	A macro to generate an online function which will list transactions for a requestor and status. This provides a convenient means for an individual to see which transactions s/he requested which are still pending review.

Subprograms

The following subprograms reside on the system library and are called to perform specific functions in support of TARGET processing.

Subprogram	Description
TANETRL	The centralized routine which will establish the transaction review list for all transactions. Based upon the transaction data passed to it and the criteria definitions stored in the data base it will determine the desks that are required to review the transaction and their review levels. If multiple criteria are being used for the same transaction, the routine will merge the review lists resulting from each criteria.
TANVTH	Displays a window to view transaction history. This subprogram may be invoked from any transaction processor function module and will display the date and time of the transaction request and all reviews including requestor and reviewers.
TANVATC	Allows viewing or adding transaction comments. Comments are displayed in a window where they may be browsed or additional comments added. This function is available from any transaction processor function module.
TANEOPR	Establishes the operator as a proxy for a desk, if so allowed by pre-existing data base definitions. This function will be available within each application, allowing an individual to act as a proxy in reviewing various types of transactions within the application. Note: Or will there have to be a command available within each function to do this?
TANVPAT	Verifies the proxy authority of an individual for a specific transaction. This routine will need to be invoked once by each transaction processor function if the operator has been established as a proxy. Note: I believe the need for this routine was eliminated when I decided that proxies were only needed by application, not by application and command.

Help Routines

It is expected that centralized help routines will be developed to support TARGET applications, however these have not yet been defined.

Note: Hmmm, what would be needed?

TARGET Administration

The following functions will be available within the TARGET Administration application. These functions are primarily required for maintenance of TARGET data and centralized management of the transaction file.

Function	Description
TC	Transaction control file maintenance.
RG	Review group maintenance.
RCT	Review criteria type maintenance.
RC	Review criteria maintenance.
PA	Proxy authorization maintenance.
LTPD	List transactions which have been pending longer than their maximum allowed number of days.
LTHD	List transactions which have been held longer than their maximum allowed number of days.
LTSC	List transactions of a specified status and type in chronological sequence.
PTD	Print transaction detail for transactions of a specified status, type and status date range.
PAP	Print, archive and purge transactions meeting purge criteria.
PPE	Purge proxy authorizations that have expired based upon their effective date.
RTP	Reviewer test procedure used to display the reviewers and their review levels established for a test set of review criteria. This facility is used to test out review criteria and review group definitions.

Additional Considerations

New responsibilities

In order for distributed transaction entry and approval to be successful, new responsibilities must be assumed by many offices and individuals. Some of the specific areas where this is true include:

The university administration must develop and adopt a policy endorsing the concept of electronic approval of transactions and specifically the TARGET system.
An office and individuals must be designated to maintain the required routing tables (the review criteria and review groups) and to act as the central administrator for the TARGET system.
Campus wide, all offices must receive the appropriate training to use the new systems that are deployed.
The individuals designated to review pending transactions must perform that task in a timely manner.
Computing Services must provide adequate resources for processing, storage, maintenance, support and enhancement of the system. Since these applications will become integral to almost all administrative processing, added attention may also need to be directed toward backup, recovery and disaster planning.
Due to the wider access that will be provided to online administrative systems, security issues must be emphasized. Confidentiality of IDs and passwords will need added emphasis, auditing of computer use activities must be increased, and other policing actions instigated.
When position based security is implemented, detail maintenance will be required of the association of desks to positions. In the interim, the association of desks to individuals requires an even greater level of activity due to personnel changes.

The full commitment of the university will be required to support the successful implementation of TARGET. The advantages of more timely processing, reduction of errors, higher quality data, increased productivity, and greater access to information warrants this commitment.

Standards

It is anticipated that some standards will need to be adopted regarding the development of TARGET applications. One such standard is that the application must use the NSM Architecture for menu presentation, navigation within the system, and function level security. The TARGET data must also be used according to their intended purpose. Other standards may be proposed and adopted as their need arises.

Clarifications

The following points are included to clearly state operational characteristics or issues which may have only been implied or not stated to this point.

TARGET provides no facility for priority coding a transaction so that its processing might be expedited. If a transaction needs to be "walked-through" the system, the originator will need to telephone the reviewer(s), identify the transaction, and request that immediate action be taken on the transaction. The reviewer can then directly select that transaction from a list and process it. It is expected that the need for this type of activity will be significantly reduced due to the speed in which the electronic entry and review can be accomplished.
Changes made to the review criteria will affect transactions entered after that point. Transactions entered previously are established with the reviewers and review levels that were in effect at the time of entry. No facilities have been planned or provided for altering the reviewer information (who is to review a transaction at what level) that is established for a transaction.
A reviewer will not be allowed to modify any information within a transaction. If a reviewer determines that a transaction has not been entered correctly or is unacceptable for any reason, the reviewer must reject the transaction. The originator may then reinitiate the transaction in a corrected form. This can be easily accomplished by retrieving the rejected transaction, copying that information to serve as the basis of a new transaction, making additional changes and corrections, and then submitting the new transaction for review.
Note: I always wondered if this would really fly. It appears that there will be some, if not many, cases where a transaction is at least supplemented, if not directly modified, during the review process.
Multiple review criteria may be used to establish the reviewers for a single transaction. In this situation the review list resulting from each criteria is always merged with duplicate reviewers eliminated at their lower level. If the result of the merge process is more than 10 reviewers, reviewers at the lowest levels will be eliminated.
If the requestor is also established as a reviewer, based upon the review criteria, that review status is automatically set to approved.
Transactions which require special forms, paper work or other backup materials in the central administrative office can also be processed through TARGET. In this situation, the central office or the recipient of the paper work must be defined as a reviewer of the transaction. Special procedures must be employed by that reviewer to ensure that such transactions are not approved until the necessary documentation has physically been received. A reviewer may indicate this situation with a special status code. This hold status may be placed on transactions for other reasons and will be available on transaction lists. A comment should be added to a transaction that it is being held.
The system will not permit multiple transactions of the same type to be pending for the same data base entity at the same time. For example, two address changes for the same individual pending at the same time. One change would logically overlay the other at final approval and is therefore not allowed.
Transactions are not applied to the data base until they reach final approval. Validations associated with a transaction may involve data base checks which are affected by the completion of other transactions. Therefore it is possible that a transaction will be valid at the time of original entry but may no longer be valid when it is being reviewed. Such transactions cannot be approved. They must either be rejected or held until some subsequent action would allow them to pass validation criteria (perhaps a transfer of funds).
Applications that use TARGET, due to their nature of allowing distributed transaction entry, may also need to implement security by value. This will permit restrictions to be placed on what data is allowed to be entered for a transaction based upon the originator. For example, an individual in Computing Services would only be allowed to enter vacation/leave data for Computing Services and not for any other department.
Comments are retained as they are originally entered, there are no facilities provided to delete or alter comments. Additional comments may be entered up to the maximum allowed.
The transaction file will always contain the new information being submitted for the transaction. After a transaction has been completed, this will correspond to the information stored on the data base, referred to in data processing as the after image. To determine what data existed prior to a transaction being processed, the previous transaction completed for that data base entity/transaction type must be retrieved.
The new applications being developed are expected to employ much tighter controls and more stringent online validations than previous systems. These validations will be implemented in an integrated fashion within our total information system. This should result in fewer needs for transaction approval, eliminating many of the check points currently being employed.

Security and Auditability

Security issues are of greater concern when broader access is provided to applications performing critical or financial functions. Access to TARGET applications will be controlled by the same means as currently used within our financial systems, personalized IDs and private passwords. There will only be the CICS ID/password required, unlike MSA and some other systems which require dual sign ons. This should actually be an improvement since only one ID/password will have to be remembered, resulting in less need to write it down.

Access to applications and privileges within those applications is based upon definitions maintained within the NSM Maintenance System. This administration function is performed directly by individuals within the offices with data custodian responsibility. These administrators must make the correct definitions and be conscientious in performing this task; however, this is no different than with any other system. The same situation exists with the review criteria and review groups which must be maintained by a TARGET administrator.

The audit function should be much improved with TARGET since all distributed transactions will be centrally located and contain a complete history of the review process. To assist in this area a batch program will be provided to report all transactions of a specific type over a date range.

The transaction file itself may be perceived as vulnerable since it must be updated from every transaction processing function, and thus subject to corruption. This is true. However the same is true for any data base file for which update is permitted. The production environment is a controlled environment where update to data base files is restricted to production programs and records are maintained of all updates to production programs. If added security features or new procedures are deemed necessary, they should be pursued on an independent basis.

Potential Enhancements

It is anticipated that features can be added to TARGET to allow future "effective" dating of transactions. This would permit a transaction to be entered and approved to take effect on a future date. The system would then post that transaction to the data base on that date. There are several obstacles to providing such a function:

The system would have to prevent a second transaction from being entered that would be effective prior to the date of the already approved transaction.
A second transaction effective on a later date would have to use the data from the first approved transaction versus the data base.
A means of performing the final processing and posting of the transaction to the data base would have to be implemented in batch, yet using the same online programs, which is believed to be possible but will require further experimenting.

In the meantime, applications may still employ their own mechanisms for effective dating data.

Appendix A. TARGET Data Flow Diagrams

Appendix B. TARGET Entity Relationship Diagram

Appendix C. TARGET File Definitions