dok/IS_tehniska_specifikacija_v_7_… · Web viewFurther tests are documented in external MS Word...

Appendixto the Tender Regulation of

19 May 2015No. LZRA2015/1/K

TECHNICAL SPECIFICATION (procurement identification No. LZRA2015/1/K)

1. INTRODUCTION 21.1. Context and aim of the document........................................................21.2. Procurement goals and structure.........................................................21.3. Definitions and descriptions of terms used..............................................31.4. Abbreviations.............................................................................41.5. Related documents.......................................................................4

2. GENERAL DESCRIPTION 52.1. Description of the present situation......................................................5

2.1.1. Operation of LACA...................................................................................52.1.2. Necessity of the Audit Support Information System (ASIS)..................................52.1.3. Audit or review engagement work stages.......................................................6

2.2. Description of system operations.......................................................102.2.1. The ASIS software architecture..................................................................102.2.2. System users........................................................................................102.2.3. Technical architecture of the system...........................................................11

2.3. Timeline of development and implementation of the IS...............................12

3. DESCRIPTION OF PROCUREMENT REQUIREMENTS 133.1. Service delivery requirements..........................................................13

3.1.1. Organising requirements for the project......................................................133.1.2. Requirements for development, implementation and maintenance of the system. .15

3.2. Functional requirements of the system................................................193.2.1. The ASIS system....................................................................................193.2.2. System integration requirements...............................................................27

3.3. Non-functional requirements of the system...........................................29

1. Introduction

1.1. Context and aim of the document

1.2. Procurement goals and structureThe goal of the procurement is to ensure development or adoption and implementation of the Audit Support Information System (ASIS). Within the framework of the procurement, the winner of the tender shall have to provide development or adoption and implementation of functional blocks of ASIS, carrying out development and delivery of components described in the table below.Table 1 – Procurement components

Component Description

Development or adoption of ASIS system software

The provider shall develop or adopt functional blocks of the software for registration, processing, output of the ASIS information.

Key functional blocks:• Customers’ register;• Users’ register;• Database of templates and management of engagement types;• Creation and acceptance of engagements;• Creation and processing of engagement file;• Completion and archiving of engagement;• Introduction of changes in logic of audit procedures;• Administering users and system.

Integration of ASIS with internal and external information systems.

The provider shall develop or adopt integration with internal and external systems.

When preparing a proposal, applicants have to offer a complete solution to comply with all requirements referred to in Table 1 and in the technical specification to ensure operations of all components. The Applicants shall indicate separately in the Proposal and sign the items given in the table below.

Component Notes

Functionality of software developed by the applicant in line with requirements referred to in the technical specification

To be included in the Applicant’s proposal

Components of third parties used by the applicant To be included in the Applicant’s proposal

To ensure exchange of software data between external and internal IS

To be included in the Applicant’s proposal

Software of application servers To be included in the Applicant’s proposal

Licences for database management systems The Applicant shall ensure the DBVS licences necessary to operate the solution, on the basis of infrastructure available to the Client.

Operating systems Provided by the Client. The Applicant shall sign claims against the OS on the basis of infrastructure available to the Client.

Other software Any additional software necessary to comply with requirements defined in Section 2 and 3 to be included in the Applicant’s proposal.

Component Notes

Technical support Provided by the Client. The Applicant shall sign claims against the technical support on the basis of infrastructure available to the Client.

Other technical support Any additional technical support necessary to comply with requirements defined in Section 2 and 3 to be included in the Applicant’s proposal.

1.3. Definitions and descriptions of terms usedTable 2 – Definitions and descriptions of terms used

Term Description

Business Process Execution Language

Business Process Execution Language. A language used to describe business processes and interaction of business processes in organisations and among those.

Classifier One or more database tables that include collection of specialised information necessary to systematise a certain quantity.

User interface Interface for information exchange between user and software components.

Metadata Data describing information and different parameters.

Web services .

A common way to exchange software data. Web protocols are used for transmission. Web services ensure information exchange without having knowledge of the second involved system software. It is important for the service user to receive a specific resource, service provider, however, can choose freely any time in what language and on what platform to develop and operate the necessary algorithms.

Service Oriented Architecture An aggregation of design principles providing an opportunity to use network technologies, create modular services that can be mutually integrated and used repeatedly, applying united data exchange principles (web services).

Web Network environment that can operate applications via browser.

Clients Small and medium-sized auditor companies’ clients

Engagement Specific work (audit or review) as a result of which an auditors’ report is prepared

Engagement working file An aggregation of engagement tasks and documents related to engagement and documented systematically

Work tasks Work (audit procedure) performed within the framework of an engagement and that is necessary to prepare an auditors’ report; work tasks are usually provided in specific templates.

Financial statements Financial statements prepared by client on which an auditor provides an opinion

Auditors’ report Auditors’ report on financial statements reflecting the performed work

Component of the financial statements

Part of the financial statements (for example, balance sheet item, note to the financial statements etc.)

Template(document template)

Previously defined term of reference saved in the system or document template or both

Template database An aggregation of illustrative work tasks and templates, from which work tasks or templates can be imported to the engagement file

Superuser related to audit company

Superuser / administrator of audit company that is assigned by administrator (system administrator related not to audit company but general software administration)

1.4. AbbreviationsTable 3 – Abbreviations

Abbreviation Description

ASP Active Server Pages

DBMS Database Management System

HTTP Hyper text transfer protocol

ICT Information and Communication Technologies

IS Information System

Client Latvian Association of Certified Auditors (LACA)

Provider Tender Applicant that obtained provider and implementation rights

DSD Description of Software Design

SRS Software Requirements Specification

Applicant Participants of procurement tender from which one Provider is selected

ASIS Audit Support Information System

SOA Service Oriented Architecture

SSO Single Sign-on

RCSP Reliable Certification Service Provider

XML eXtensible Markup Language

1.5. Related documentsTable 4 – Related documents

No. Abbreviated title Full title

1. Methodology Manual of International Accounting Standards application in audit of small and medium-sized companieshttp://www.fm.gov.lv/lv/sadalas/gramatvedibas_un_revizijas_politika/projekts_tehniska_palidziba_finansu_parskatu_sagatavosana/tulkojumi/

2. Law On Certified Auditors Law “On Certified Auditors”

http://www.fm.gov.lv/lv/sadalas/gramatvedibas_un_revizijas_politika/projekts_tehniska_palidziba_finansu_parskatu_sagatavosana/tulkojumi/

http://www.fm.gov.lv/lv/sadalas/gramatvedibas_un_revizijas_politika/projekts_tehniska_palidziba_finansu_parskatu_sagatavosana/tulkojumi/

2. General descriptionThis section provides a summary of the present situation, as well as sets goals and tasks of the IS and functional blocks. In addition, the section contains information on the timeline for development and implementation of the IS that the Provider has to comply with when preparing and submitting a proposal.

2.1. Description of the present situation2.1.1. Operation of LACA

The Latvian Association of Certified Auditors (LACA) is an independent professional corporation that was founded in 1994 according to the Law on Certified Auditors. The organisation was founded by 75 certified auditors, however, its roots trace back to 12 July 1938 when the Cabinet of Ministers of the Republic of Latvia adopted and the President proclaimed the “Law on Certified Auditors”. LACA is the only professional organisation in Latvia uniting all certified auditors and commercial companies of certified auditors.

The goal of the Association as a professional corporation of the Latvian certified auditors is to implement professional management of certified auditors to facilitate increase of qualification, improvement of creative skills and sharing of experience, as well as take care of reputation and legal protection of the profession. The Association’s operations are directed towards compliance with the tasks prescribed in the Law “On Certified Auditors”:

to ensure the supervision of conformity with the professional standards and ethical norms, as well as other laws and regulations applicable to the profession, and of the professional activity of members of the LACA;

to represent and defend the interests of its members, to organise qualification examinations for certified auditors, to decide on the issuance of a certificate to a certified auditor and on the issuance of a licence to a commercial company of certified auditors;

to organise the Certified Auditor Register and the Register of Commercial Companies of Certified Auditors;

to review disputes between certified auditors and clients at the request of one of the parties to the dispute;

to organise and supervise continuous education and improvement of professional qualification of certified auditors;

to develop and submit recommendations related to accounting standards and audit to legislative institutions;

to ensure quality control of certified auditors.

2.1.2. Necessity of the Audit Support Information System (ASIS)

When documenting work, the small audit companies currently are operating on the basis of their own subjective opinion and practice. Work performed is documented in separate files, however, there is no joint system that would provide a summary whether all the tasks have been completed and in what status they are at present. Moreover, separate document files require manual work that often makes the work of small audit companies inefficient.

In light of the above, the small audit companies cannot solve this problem continuously investing in development of software. The Latvian Association of Certified Auditors would like to use the available financial support provided by the Swiss – Latvian Cooperation Program to develop a specific audit software that would be adapted to the needs of the Latvian market and would therefore increase efficiency and quality of work performed in this sphere.

Implementation of the new software:

will help to reduce the amount of manual work and allow auditors to perform their work more efficiently;

will improve quality of work as working processes are structured in a system;

will simplify supervision, as well as cooperation and consultations among auditors as work would be conducted using a similar system;

will allow look for common solutions to archive documents and solve other issues, which currently are solved by each auditor individually; and

will allow audit companies to exchange with new templates and participate at their development.

The LACA is planning to carry out the ASIS implementation project and offer ASIS to small audit companies as a pay service: during the first 2 years subscription payment would include infrastructure and administration costs for operating the ASIS and after 2 years it would include also ASIS maintenance costs.

2.1.3. Audit or review engagement work stagesThis section provides work stages (auditor review engagement) and planned succession of work for support of which the ASIS is developed.

Clie

nt

acce

ptan

ce

Enga

gem

ent

plan

ning

Obt

aini

ngau

dit

evid

ence

Conc

lusio

ns,

opin

ion

Com

pleti

onof

enga

gem

ent

Image 1 – The key work stages of audit and review engagement

Work stage

Example of tasks

(The ASIS has to document a description of all tasks performed within the term of reference and the

respective results.)

Additional explanation: Work conducted within the framework of the planned system and work conducted

outside it (separate tasks)

1. Client acceptance 1.1. The Auditor researches information available on the client.

1.2. The Auditor assesses compliance with requirements of independence, resources, qualification and other requirements compliance with which is necessary to accept the work.

1.1. The main data on the client are registered with the ASIS in the client card. Information obtained during research is attached in files.

1.2. The conducted work is documented in external files.

Work stage

Example of tasks





1.3. The Auditor takes a decision on the client acceptance and signs a service agreement.

1.3. To take a decision on acceptance of work a questionnaire is filled in and a decision on client acceptance is taken in the ASIS. The ASIS fills in agreement template using data entered in the client card.

2. Engagement planning

2.1. The Auditor obtains information and fills in the following documents:

client’s business understanding, impact of external and internal factors and related risks;

understanding of key accounting processes, internal controls and related risks.

(If work within the engagement is conducted for a long time, prior year engagement file templates are used; templates are reviewed and, if necessary, updated.)

2.2. The Auditor enters the main data of the financial statements (balance sheet, profit or loss statement) in the software and links it with data of journals / ledgers imported from accounting software containing information of accounting level.

2.3. The Auditor defines the significance on the basis of indices in the financial statements.

2.4. The Auditor analyses the financial statements and identifies spheres that would potentially contain deficiencies.

2.5. The Auditor prepares a summary of risks and assesses their significance and possible impact.

2.6. The Auditor prepared the planned time line of audit procedures in line with the identified risks (majority of tasks are planned on the basis of components of the financial statements; the more components, the larger the number of tasks).

2.7. Tasks are transferred to work group members for completion.

2.1. Client business (business environment) understanding is documented in an external file. The identified risks are entered in the system and a summary of their assessment is documented in the ASIS.

2.2. Indices are entered or imported to the ASIS.

2.3. Significance is calculated in the ASIS using data (indices) referred to in the previous subsection (up to 4 or 5 indices). There has to be an option to describe (define) calculation procedure / formula and indices used in the system.

2.4. Risk spheres are entered in the system on the level of items of the financial statements. The selection defines the calculation of selection cluster with the ASIS (the higher the risk, the larger the selection cluster).

2.5. All risks are summarised with the ASIS.

2.6. Work tasks that have to be conducted to verify components of the financial statements are defined on the basis of risk assessment. Usually tasks related to verification of items of the financial statements are standard and pre-defined. As to the specific task the following information has to be included in the ASIS: item amount, risk assessment result, approach and summary. Further tests are documented in external MS Word and Excel files (templates). When downloading tasks from the database of templates, there has to be option provided to select with templates to download and which – not to (options have to be displayed in a tree structure to be able to chose either all test templates related to the respective item or only some of them (the suitable ones)). There has to be an option to download additional tasks and templates from the database of templates later.

2.7. Each work task is assigned to a person who is responsible for completion thereof.

The ASIS can include a mass of work tasks (for example,

Work stage

Example of tasks





the auditor selects name of a person and attaches several tasks and documents related to the task).

3. Obtaining audit evidence

3.1. The Auditor or Auditor’s assistants obtain evidence to gain a reasonable assurance that the financial statements in general or components of the financial statements are free from material misstatements. Such evidence can be obtained using different methods (tests or controls, substantive analytical procedures, detailed reviews). The identified deficiencies are registered in a worksheet. After completion of the work task, person responsible for it marks its status as “completed” (incomplete work task might be marked “yellow” and completed – “green”). When person responsible for completion of the work task has marked it as “completed” (green) the system has to create and attach completion date automatically.

3.2. Certified Auditor reviews all completed work tasks and attached documents (review is registered together with other information related to the work task – the reviewed work task might be market “blue”). If necessary, the Auditor attaches documents and questions to person responsible for completion of work task, who would later reply to these questions or perform additional work / improve the work already completed. When the reviewer has marked the work task as “reviewed” but person responsible for the work task has changed the entered information, the status and marking of the respective work task is changed to “incomplete” automatically (person responsible for the work task and reviewer have to mark the status as “completed” and “reviewed” again).

3.3. The Auditor summarizes all adjustments made in the financial statements and all unadjusted misstatements and errors.

3.1. The ASIS lists work tasks (work task, description and completion) and provides information whether the respective work tasks have been completed and reviewed. Practically it is conducted using MS Word and Excel files attached to work tasks.

3.2. Metadata of each document and work task include a reference whether the respective document or work task has been reviewed. If during the review questions arise (comments are expressed), a question is attached to the respective work task (status: unanswered question), person responsible for the work task has to attach an answer / comment to the question (answered question). Afterwards the reviewer marks the question as answered (question is closed). Program has to include a view that would show the so called unresolved issues (questions and comments) together with a link to the respective work task or document.

3.3. Deficiencies identified during the engagement are entered in the ASIS manually (incorrect amount, debit and credit entries, reference whether the deficiency has been eliminated or no etc.). Considering corrections of deficiencies, the program calculates the final amounts of the financial statements.

When entering items of the financial statements, it is reviewed whether the Auditor is aware of all amendments and adjustments made during the engagement.

4. Making conclusions and phrasing opinion

4.1. Assessment of effect and significance of deficiencies.

4.2. Additional analytical procedures and assessment whether the risk assessment carried out during the planning stage remains the same.

4.3. Documentation of conclusions and taking decision on the type of the auditors’ opinion to be issued.

4.1. Assessment of effect of deficiencies, in its terms, implies filling in a questionnaire that includes multiple choice questions as regards each item of the financial statements and each deficiency.

4.2. Financial indices in the ASIS are calculated on the basis of the final amounts presented in the financial statements. All important changes are analysed comparing the final amounts and previously compared amounts.

4.3. Documentation of conclusions, in its terms, implies filling in a questionnaire that includes multiple choice questions and phrasing the final opinion.

Work stage

Example of tasks





4.4. Preparation of representation letter that has to signed by the client’s management along with the financial statements.

4.5. Issuance of auditors’ report

4.4. Letter providing representation of management is an external document (there has to be an option to attach a summary of unadjusted / uncorrected deficiencies that is generated by the ASIS).

4.5. Auditors’ report is an external document.

5. Actions to complete the engagement

5.1. Completion and archiving of engagement. 5.1. Closing and archiving of engagement are the ASIS functionality. Prior to archiving, the system has to perform an automatic review whether all work tasks are marked as “completed” and “reviewed” and, if no, the system has to generate an error message and archiving cannot be commenced.

The ASIS has to register closing and archiving date. After completion of archiving all views of the program and all attached documents have to be protected against editing (available in “read only” mode).

5.2. Changes introduced after archiving have to be documented along with explanations.

5.2. Amendments in data or documents stored in the ASIS can be introduced only in exceptional cases. In these cases, the system has to reflect who has introduced the changes, what has been changed and when these changes were introduced.

2.2. Description of system operations2.2.1. The ASIS software architecture

The System’s software architecture will be based on one basic block – the ASIS Information System, as well as developed data transmission functionality with at least 6 most popular accounting programs in Latvia.

2.2.2. System usersThe ASIS will use several groups of users the necessary functionality and functions of which are provided in the table below.

Table 5 – Groups of ASIS users

Group of users Functionality

Administrators • General system administration;• Creation of superusers and assigning roles;

Superusers • Creation of new users for an audit company, defining users’ access rights (roles) to conduct certain audit or review engagements.

Users • Standard use of the system – different roles can be assigned depending on position within the respective audit or review engagement.

• administration of users, their rights and privileges (user can be involved in several engagements with different roles simultaneously, therefore the user can have different user rights). Some examples of roles (not all of them) (list in a hierarchic order) where every next (higher) level has all the rights and privileges of the previous levels.

• The engagement partner (certified auditor responsible for the engagement in general): has all the rights, as well as rights to add or delete users can be added.

• Engagement manager: entitled to add and review tasks and manage templates;

• Auditor’s assistant: entitled to supplement information within the framework of his/her work task; entitled to select works to be completed; attach evidence (files to tasks) and review work of the same or lower level auditors;

• Observer: entitled to view data.

• Users can be created for each audit company separately (if audit companies store data at one and the same server, one and the same user can be described by several audit companies).

Note: Groups of users and roles can be detailed during development of SRS / DSD.

2.2.3. Technical architecture of the systemThis section is provided to the Applicants to inform on the planned technical architecture of the ASIS that has to be considered when developing or adopting the ASIS software components.

A solution has to be developed for several technological elements to ensure maintenance of the ASIS functions. The image below provides general technical architecture of the planned system.

Ārējie lietotāji

RAIS Ārējās IS

Ugunsmūris

Ārēja IS

Testu serveri

Tīmekļa pakalpņu serveris

RAIS aplikāciju servers

RAIS DB servers

WEB service

Ieksejie lietotaji

Gramatvedibas programmu datnes

External usersAccounting

program files

Testing servers

The ASIS application server

The ASIS DB server

Internal users

External ISExternal IS

External IS

Server of web services

Firewall

Image 2 – Technical architecture of the ASIS

It is planned that to ensure the system’s operations the following technological components will be available:

► The ASIS application servers One or several servers with installed software of application server operating in cluster mode to ensure performance and continuity.

► Database server of the ASIS One or several database servers with installed DMBS software operating in cluster mode to ensure performance and continuity. If resources for development of the solution will be limited, an option should be provided to use one database server ensuring system expansion opportunity creating a cluster of database in future.

► Test servers Test servers will be used for ASIS update tests prior to transferring changes to the ASIS exploitation environment. Operations of test servers can be ensured on one physical server creating virtual servers (for database, application server, web interface and services), if necessary.

► Data transmission network components – the Client will provide the existing data transmission network active (network adapters, hubs, commutators, bridges and routers) and passive elements necessary to operate solutions. The Provider has to familiarise with the data

transmission infrastructure and speed available to the Client, and, if necessary, prepare recommendations to improve it.

The table below provides information on data exchange:

Table 6 – Data exchange to be developed within the project with the following data buses

System Data bus Brief description

Accounting programs (at least 6) • Accounting data It is necessary to import data of journals / ledgers (account No., opening balance, closing balance, debit and credit) from the accounting programme to the software (input data can be provided in xls, xlsx, txt (tab delimited), csv format).

During development of the ASIS, models necessary for importation have to be based on the most familiar accounting programs (at least 6); data import from other accounting programs will be carried out importing data from previously formatted Excel table.

2.3. Timeline of development and implementation of the IS Initially it is planned to implement the project until the end of September 2015. In line with the life cycle of software development and implementation, it is planned to carry out the project in line with the following work stages. The planned work stages of the project and the initial timeline is provided schematically in the table below.Table 7 – Timeline of development and implementation of the ASIS

Work stage of the project

Year 2015 Year 2017

5 6 7 8 9 1 1 1 1 2 3 4 5 6 7 8 9 1 1 1

Stage 1 Development of the ASIS DSD / SRS, development and demonstration of prototype

X

Stage 2 Delivery and adjustment of the ASIS X

Stage 3 Testing of the ASIS X X

Stage 4 Implementation and configuration of the ASIS (including delivery, installation and configuration of technical resources)

X

Stage 5 Trainings of main users of the ASIS X X

Completion of the project X

Maintenance and guarantee (24 months) of the ASIS free of charge X X X X X X X X X X X X X

3. Description of procurement requirementsThis section provides a detailed description of the ASIS and requirements related to its development and implementation. The Applicants have to ensure compliance with the requirements set out below and they have to provide confirmations on compliance with the respective requirements, as well as description, how compliance with the respective requirements will be ensured, that is detailed enough:

► to demonstrate the Applicant’s understanding of fulfilment of the respective requirements;

► to allow the tender commission to assess the validity and conformity of a solution with the Client’s needs.

3.1. Service delivery requirements3.1.1. Organising requirements for the project

Development, implementation of the ASIS and maintenance of the ASIS components is a joint project that has to be managed in line with approaches and methods prescribed in the international standards for IT project management and adjusting those to the Client’s specifics.Table 8 – O Organising requirements for the project

No. Requirements Description

O1. Project management

O1.1. Organisational structure of the project

During the project implementation, the Provider has to propose the organisational structure that includes at least the following structural elements:• Project monitoring commission (to be established, if necessary, upon an agreement

with the Client), that consists of the management representatives of the Client and Provider, and the Client is entitled to invite other representatives of parties involved in the project to take part in the commission. During meetings of the project monitoring commission, information provided by the project management group on the progress of the project implementation is assessed, potential risks of implementation of project measures are analysed, issued during the implementation of the project are analysed, as well as decisions taken on the necessity to make amendments to the project. In cases when disagreements occur or issues have arisen between the project management group and the Provider or other cooperation partners, the project monitoring commission provides a recommending solution for the problem to the Provider.

• Project management group consists of project managers and senior specialists of the Client and the Provider. The project management group informs the project monitoring commission on the project’s status and progress, ensures the necessary progress of the project and detailed planning of the project measures in line with the decision made by the project monitoring commission, as well as ensures management of other project aspects.

• Project work groups include specialists of the Provider and the Client necessary to deliver the respective working packages. The project management group determines what type of project work groups should be established. The project work group is responsible for completion of certain work in line with the guidelines provided by the project management group. The project work groups submit reports on status and progress of work in progress to the project management group.

The Applicant have to propose a detailed organisational model of the project.

O1.2. Project communication management

The Applicant have to describe the proposed communication approach on all levels of organisational structure.

O1.3. Project quality management The Provider has to take all necessary measures to ensure the project quality management in line with the best practice principles, including but not limited to:• the Provider approves with the Client the templates of document deliverables before


commencement of development of all document deliverables;• ensuring quality of development and implementation process;• timely submission of deliverables to the Client for approval;• timely and regular identification and escalation of the project risks.The Applicant has to sign the proposed approach to ensure the project quality management.

O1.4. Project change management The Applicant has to propose a model of project change management that prescribes review and escalation on several levels in compliance with significance and effect of these changes on time, financial and other resources, as well as to the project scope.

O1.5. Project management standards and methodologies

The project management has to be provided in line with some of the internationally recognised industry standards in the sphere of the project management (for example, PRINCE2, PMBOK).

O1.6. Use of the best practice of the program engineering

During implementation, the Provider has to consider program engineering standards and best practice:• The Latvian standards prescribing documenting of software and software

development process during different development stages, as well as measures to be taken to ensure the software quality;

• Standard for Information Technology. Software Life Cycle Processes. Software Development. Acquirer-Supplier Agreement (IEEE J-STD-016), international standard prescribing all software life cycle processes, the necessary documentation and its contents;

• Information technology – Software life cycle processes (ISO/IEC 12207:2008), international standard prescribing software life cycle processes;

• quality management system standard ISO/IEC 9001.

O1.7. Project working language The project working language is Latvian or English. The Provider has to prepare document deliverables in Latvian or English.Specialists, who do not know Latvian or English, may be involved during the project, in this case the Provider has to ensure translation for communication with the Client without additional charge.Some document deliverables within the proejct may be preared in a foreign language with a prior consent provided by the Client.

O2. Project documentation

O2.1. Minutes / summaries of interviews and meetings

The Client ensures taking minutes during the project monitoring commission and project management group meetings.The Provider has to ensure taking minutes during meetings of the work groups (making notes on the taken decisions) and coordination between parties of the meeting.

02.2. Project management plan The Provider, in line with the proposed project management model, has to ensure preparation and maintenance of the project management plan.

O2.3. Progress / status reports Progress / status reports have to be developed and submitted to the Client in line with the organisational structure of the project.

O3. Project timeline

O3.1. Project stages and deadlines for delivery

The Provider has to provide the project implementation in line with the timeline of IS development and implementation described in section of the technical specification.

O3.2. Resources necessary for implementation of the project stages

The Provider has to ensure availability of all resources necessary to implement the project for the entire project duration to secure a complete, timely and qualitative project implementation.


O3.3. Update of the project timeline The Applicant has to submit an accurate and detailed project timeline that includes the effect of the Applicant’s resources and other aspects included in the proposal on the project fulfilment.In the adjusted project timeline completion of all works has to be provided not later than in the IS development and implementation timeline provided in the technical specification.During the project implementation, changes in the project timeline have to be introduced through the project change management mechanism.

O4. Project deliverables

O4.1. System documentation During delivery, adjustment and implementation of the ASIS, the Provider has to develop at least the following documentation:• “Specification of requirements for the ASIS software”;• “Description of the ASIS software design to develop and implement system

modules”;• “Delivery, adjustment and implementation plan of the ASIS”;• “Testing plan and examples of acceptance testing of the ASIS”;• “Overview of the ASIS testing”;• “The ASIS user manual”;• “The ASIS administrator’s manual” (including installation, configuration of the ASIS

software and other components and instructions for restoration of operations);• “Plan to ensure continuous operations of the ASIS”;• “Exploitation regulations of the ASIS”;• “Security risk management plan of the ASIS”.• reports and presentation on work performed within the framework of each stage.

The set of system documentation has to be complete in terms that:• third parties could verify that development, delivery and implementation of the

system has been conducted in line with the set requirements and best practice in the industry;

• all the necessary information is provided to the system users for them to use the functionality provided by the system independently and fully;

• the system administrators have access to information necessary to ensure continuous operation of the system in line with the system specifics.

List of the system documentation can be adjusted during the project.

O4.2. The ASIS software deliverables After delivery, adjustment and implementation project of the ASIS, the Provider has to submit the developed software solution to the Client, along with licences of the developed software solutions and ready-made software, source codes of adjustments, executable codes, installation package and description of software version.

3.1.2. Requirements for development, implementation and maintenance of the systemTable 9 – (V) Requirements for development, implementation and guarantee of the system


V1. Analysis of the system requirements and development of design

V1.1. Analysis of the present situation and detailed analysis of requirements

The Provider has to familiarise with the present situation as regards development and adjustment of the ASIS in the scope necessary to develop the SRS and DSD of the ASIS (including familiarising with the regulatory enactments, descriptions of processes and other documentation, as well interview persons indicated by the Client to obtain a complete understanding of auditors’ work and related procedures).When conducting this activity, the Provider describes the Client’s business processes in an elaborative manner to ensure that descriptions can be used to develop the ASIS system.


V1.2. Development and approval of the conceptual IS design

The Provider prepares a short description of the IS conceptual design that serves as an intermediate in development of DSD and provides IS conceptual solution (specifying the proposal in line with the results of analysis) and describes components of solution, their mutual relation, functionality of the system and division in functional modules, database logical scheme, internal and external interfaces, implementation approach of the system and other elements of solution.Conceptual design has to be presented and approved by the Client.On the basis of the approved conceptual design, the Provider has to prepare the remaining IS requirements.Conceptual design that would contain specified architecture of application and technical architecture that can be included in DSD as a separate part.

V1.3. Identification and traceability of requirements

Requirements prescribed in the DSD and SRS have to be identified using unique identifiers.During adjustment, delivery and implementation of the system, it has to be possible to trace implementation of the respective requirement over entire life cycle of the ASIS project.

V1.4. Degree of detailed elaboration DSD and SRS have to be developed at least in such a degree of detailed elaboration that is sufficient for the Client to be able to maintain and administer the ASIS system.DSD has to be so elaborated to ensure a complete implementation of the ASIS functionality. Requirements have to be complete, verifiable and unambiguous.If the Provider requires more information on the Client’s needs, the Provider clarifies or specifies the information and amends documentation accordingly.

V1.5. Compliance with requirements of technical specification (business)

When developing DSD and SRS, the Provider has to ensure DSD and PPA compliance with the requirements (business) prescribed in this technical specification, as well as the Client’s needs and requirements identified during the detailed analysis of requirements.Departures from the requirements prescribed in the technical specification are possible only as a result of a formal change management process.

V1.6. Preparation of adjustment, delivery and implementation plan

The Provider prepares and the Client approves development and implementation plan of the ASIS. On the basis of the analysis of the present situation and implementation stages of the IS, the plan clarifies the development and implementation plan of the ASIS that was provided in the proposal (specifying the timeline, implementation stages of the ASIS, financial and labour resources, functionality of implementation stages and other aspects related to implementation of the ASIS).

V2. Development of the system

V2.1. Development of the system’s functionality

The Provider has to perform development of the ASIS functionality in line with the requirements of the technical specification and design (DSD and SRS).

V2.2. Development of interfaces with other systems

The Provider has to develop ASIS interfaces for information exchange with other information systems in line with the requirements prescribed in the technical specification and DSD and SRS.

V2.3. The system’s development environment

If development of separate components is necessary, the Provider has to provide its own development environment using its own resources.

V3. Data migration

V3.1. Data migration Data migration is not planned during the project, however, the Provider has to consider transferring certain data from the existing systems of the Client. In case of data migration, the Provider has to prepare a plan indicating how the data integrity (unchangeability) will be validated before and after migration and it has to be included in the test plan of the system.

V4. System testing

V4.1. Testing documentation The Provider has to provide at least the following testing documentation verifying the scope of the ASIS testing conducted by the Provider in line with standard LVS 70:1996 “Information technologies”. Program engineering. Software testing documentation”:• testing plan;


• specification of test design;• specification of test example;• specification of test procedure;• waybill of an item under testing;• testing journal;• report on a test problem;• overview of testing summary.The Provider has to ensure availability of the above documentation to the Client upon the Client’s request.

V4.2. Scope of testing The Provider has to ensure testing of the ASIS. The testing includes comprehensive tests of all components of the ASIS, as well as tests of the interaction between these components and the ASIS integration tests of data exchange with other information systems.

V4.3. Testing environment The Provider has to prepare requirements for the testing environment. The Provider ensures establishment of the testing environment until the system is approved for exploitation and operated in the exploitation environment.

V4.4 Acceptance testing The Provider has to ensure establishment of the testing environment in the Client’s environment (that complies with the expected work environment on the basis of technical parameters), as well as the support necessary to the Client for the Provider to be able to conduct acceptance testing.

V4.5. Procedure and plan of acceptance testing

The Provider prepares and the Client approves procedure and plan of acceptance testing of the ASIS, the plan includes acceptance procedure and criteria, as well as tests of acceptance testing.

V4.6. Security testing The Provider has to provide security testing in the Client’s environment.

V4.7. Performance testing The Provider has to include performance testing the testing plan and the Provider has to conduct system performance tests for complete functioning of the system. Tests have to be conducted on the Client’s equipment that complies with the exploitation environment that is planned to be used to operate the exploitation system after implementation of the system.

V5. Implementation and configuration of the system

V5.1. Installation of the system in the exploitation environment

The Provider has to ensure installation and configuration (adjustment for operation in the specific environment) in the exploitation environment of the system, providing a completely working IS to the Client.

V5.2. Involvement of the Client’s specialists

When installing the system in the exploitation environment, the LACA specialists indicated by the Client have to be involved to the extent that they would obtain a complete picture of conducted procedures when installing the system in the exploitation environment.

V6. Training of system administrators and data input administrators

V6.1. Training plan The Provider, prior to commencement of training, has to develop and the Client has to approve training plan and its contents.

V6.2. Training of system administrators

In line with the software development stages, the Provider has to conduct trainings of system administrators and provide the necessary training materials.

V6.3. User training The Provider has to provide training for the main users how to work with the system, the Provider has to prepare the training course and ensure trainings on site.The Provider has to ensure development of e-training system to the system users and to provide e-training environment and materials.

V6.4. Scope of training The Provider has to ensure training of system administrators and main users on such a level that users would be able to use the functionality provided by the system independently and completely, as well as to take administering, monitoring and updating measures of the system.


V6.5. Training environment and venue

The Provider has to provide training environment for training of system administrators and main users at the venue approved previously by the Client (number of participants <50 persons).

V6.6. Technical equipment for training

The Provider has to ensure all technical equipment and training materials necessary for a successful training course.

V6.7. Training language The Provider has to ensure that trainings are conducted in Latvian.

V7. System maintenance and support

V7.1. System warranty The system warranty includes provision of at least the following services to the Client in relation to the provided IS components:• elimination of software development and implementation errors found during the

acceptance testing free of charge;• update of software licences;• on site or remote support of administrators (level 2).Within the framework of provision of the warranty services, it is not expected to develop a new functionality, as well as the warranty does not apply to cases when the system failure is caused by the problems in IT equipment operation.The Provider has to ensure exploitation support and problem elimination during implementation and exploitation period.The Provider has to ensure support that involves registration, classification and processing of the Client’s applications in line with the defined reaction time.

V7.2. Warranty period The Provider has to ensure warranty for the developed and delivered IS components until the complete implementation of IS and all its components with the Client, as well as within 2 (two) years period after implementation of IS and all its components.

V7.3. Warranty liability The Provider is responsible for development, implementation and delivery of IS that is qualitative and complies with the best practice guidelines of the industry, the Provider has to plan and implement convenient and user-friendly mechanisms of security, data quality and for the use of IS.

V7.4. Procedure of warranty issues and change management

The Provider has to ensure listing of submitted warning messages and change requests and, upon the Client’s request, the Provider has to provide the stored data.

V7.5. Reaction time to warning messages

In the working days of the Client, the Provider has to ensure reaction within 0.5 hours.

V7.6. Prevention period for warranty issues

The maximum period to prevent issues, in line with the SLA (will be approved during the project implementation on the basis of generally accepted industry practice).

V7.7. Update of licences Within the framework of system support and maintenance, the Provider has to ensure update of all licences supplied for operation of the system.

V7.8. System improvement services (processing of request for change)

The Provider ensures the Client a secure opportunity to receive paid system improvement services within 3 years period as of the date of the Contract.System improvements will be conduced on the basis of mutually agreed requests for change (RFC).If the Client submits requests for change to the Provider as regards development of a significant new functionality during the warranty period and after the warranty period, the Provider has to ensure system improvement services (changes of functionality) in line with the new requirements of regulatory enactments and user requirements within the defined scope of work (upon a mutual agreement between the Provider and the Client).Development of a significant new functionality is not provided within the warranty.The Applicant has to indicate the approach to provision of system improvement services provided in the technical proposal, the financial proposal has to include expenses (specialists’ fees for work).

3.2. Functional requirements of the system3.2.1. The ASIS system

Table 10 – F1 General functional requirements (blocks)


F1.1. Functional blocks of the ASIS system and their supported processes

F1.1.1. The system has to provide the following functional blocks that are separately provided for each audit company:

List of engagements(different views, active, archived)

Client register(active, inactive)

Client register(active, inactive)

Database oftemplates

(different typesof

engagements)

Specific engagement fileWork tasks, documents etc.

the above blocks can be clarified during development of DSD and SRS. Direction of bullets in the diagram displays the direction of information flow.

F1.2. Requirements for the ASIS arising from the description of audit process

The Applicants have to include requirements described in the next sections of the technical specification, as well as requirements that indirectly and functionally arise from the description of audit process stages and the effective audit methodology.

Table 11 – F2 Client register


F2.1. Client data F2.1.1. When creating a client card, the following information has to be saved in the system:

• General information on the client (data entry form is used) and contact information. Additional explanation: the data entry form provided by the system is used.

• Information on the client’s owners (data entry form is used, it is possible to attach files, if necessary). Additional explanation: possible solution – a work task is created (identification of the client’s actual owners) and templates and evidence obtained during fulfilment of the work task are linked to the work task.

• Other information on the client (data entry form and possibility to attach files with additional information). Additional explanation: other information on the client is possibly attached in separate files (for example, results of Internet search); list of other information can be described as work task.

• Client acceptance questionnaire (data entry form provided by the system). It has to be possible to mark the client as inactive in the client register (after termination of relationship with the client). There has to be a possibility to delete only those clients in relation to which no engagement has been opened or archived. The status “inactive” is used to limit display of clients in the client register or


client search window when creating the respective engagement. The said list can be clarified during development of DSD and SRS.

F2.2. Functions of the client register F2.2.1. The system has to provide at least the following functions related to the client register:• creation of new client card (example: client acceptance is a work task that is linked to

document template; additional external files can be linked to this task);• automatised assigning a unique identification number (ID) to the client card;• entering of client card entry contents;• saving of client card entries;• client search on the basis of data in the card;• amending and supplementing of client card entries;• printing of client card.• Saving and printing of documents related to client registration (in defined form).

Table 12 – F3 User register


F3.1 User data and functions F3.1.1. The ASIS has to provide at least the following functionalities of the user register:

• The superuser related to the audit company has to have an option to link other users.

• There has to be an option to create groups of users (roles), to which users belong.• There has to be an option to define the superuser related to the audit company, who

can create new users.• There has to be an option to add, change and delete users and mark their status as

“inactive”.• There has to be an option to save at least the following user information:

• identification number, name and surname, e-mail address, phone, default role in the engagement, additional identification: employee of the company or third party.

Table 13 – F4 Database of templates and management of engagement types


F4.1. Database of templates and management of engagement types;

F4.1.1. The ASIS has to ensure at least the following functionality of database of templates and management of engagement types (all data mentioned below have to be stored on the server for each audit company separately.

• There has to be an option to define users of the database of templates of the ASIS and their user rights (viewing or editing rights).

• There has to be an option to describe sets of templates by types of engagements in the same database.

• There has to be an option to show list of templates by engagement types (there has to be an option to import additional templates to the engagement file both during development and implementation process of the engagement; moreover, there has to be an option to import one and several templates at the same time).

• The superuser of the database of templates has to have an option to attach new engagement types and define document templates most suitable for the respective engagement type (MS Word, MS Excel), create a copy of a new template on the basis of template available in the same or other database, where the user has access.


• There has to be an option to change and delete the existing templates. • As regards the templates, there has to be an option to define what is mandatory for

the respective engagement, namely what will be imported by default upon creation of the engagement.

• A structure of templates that would be stored in the database has to be created and each template has to have a unique reference. There might be a separate database and versions of templates on the server that would include templates of the defined work tasks along with templates of the respective documents. Defining of access rights to templates (on the level of audit companies or users).

• The database of templates will include templates of various engagements, the contents of templates depend upon the type of engagement (audit, review). However, the engagement templates will include parts that overlap and those will differ mainly by the number of work tasks and attached work documents.

Information exchange with the database of templates:

Database of templates 1

Templates, users

Database of templates 2

Templates, users

Database of templates (general)

Templates

Engagements

Users

Clients

Audit company 2

Engagements

Users

Clients

Audit company 1

F4.1.2. It has to be ensured that templates of work tasks prepared in advance and MS Word and Excel templates can be imported to the system. The system should be able to fill in certain parts of templates automatically on each engagement (for example, fill in the key engagement data and financial indices entered in the software in the respective MS Word and Excel templates etc.)

F4.1.3. There has to be an option to transfer all data entered in the system to external templates, if necessary. The document has to include at least the following information:• name of client;• person responsible for completion of work;• amount of item (opening and closing balance, reporting period or prior comparable

period); • accounts and balances related to item (opening and closing balance, reporting

period or prior comparable period);• materiality for planning purposes;• threshold of immaterial deficiencies;• risk assessment results on assurance level; • specific risks identified in relation to item during risk assessment stage.

F4.1.4. There are such document templates that have to include other type of data (for example, service agreement concluded with the client, where name and address of client, information on persons signing agreement, engagement budget and similar information has to be entered).

• Lists of work tasks, documents etc. that can be sorted and filtered (for example, by the responsible person, status etc.). Preferably users should be able to create lists in line with their company’s needs, choosing fields to be displayed in lists and filters. There has to be an option to export these lists to MS Excel.

• There has to be an option to link documents (MS Word, MS Excel, PDF) to work task


template, and change, add and delete those during the engagement. • There has to be an option to describe the link between journal / ledger data in the

accounting program and work task templates to ensure that accounting data could be automatically transferred to (or linked to) work task or related document template (-s).

Additional explanation: It is necessary to create a link between items of the financial statements and information of journal / ledge (list of accounts with corresponding amounts) in client’s accounting program, provided by the client. Compatible descriptions mean that account or set of accounts is automatically linked to item of the financial statements. Based on this, account balances are divided between work tasks and accounts related to work task are transferred to the respective document template.

F4.1.5. During development of software, it is necessary to create the linking templates for the most popular accounting programs(at least six, a precise list will be defined during the course of further analysis, developing DSD/SRS) and one MS Excel template to which information can be exported from accounting software and from which it could be imported to audit software.

Example:

The financial statements include items “Cash and cash equivalents” and “Receivables and prepayments”. Description of linking could be provided in the list of accounts when the account is linked to the respective item of the financial statements.

One option is to create a table of compliance that includes list of accounts along with references to the respective financial statements.

Account No. Account name Item of the financial statements10101 Cash on hand Cash and cash equivalents (A1)10110 Swedbank Cash and cash equivalents (A1)….12010 Trade receivables Receivables and prepayments (A2)

The other option is to describe compatibility as a range:

Cash and cash equivalents (A1) 10101…10199, Receivables and prepayments (A2) 12010…12019

The second option might be more flexible. However, when importing from MS Excel, users probably will find the first option more convenient, when links between accounts and items of the financial statements are created after import of data. When importing data, it is significant to verify whether all accounts are linked to the corresponding item. There has to be an option to change the links or delete account data and import those repeatedly.

Table 14– F5 Creation and acceptance of engagement


F5.1. Creation and acceptance of engagements

F5.1.1. When creating a new engagement, the list of engagements in the system stores and maintains the following information on the new engagement:

• general information on the engagement (type of engagement and main data) – a (using data entry form and possibility to attach files, if necessary);

• project work group members (users) and their roles;


• engagement budget (using a form or separate file), divided by operations and work group members. (Additional explanation: list of work tasks and timeline are usually standards, the level of personalities has to be added that can be done using the matrix table (users in columns) or additional rows; in practice one person often performs one task); and

• engagement acceptance form (using data entry form).

F5.1.2. List of engagements displays only projects where the user has been identified as work group member (and the list can be opened only by the respective user).

F5.1.3. When general data has been entered, templates are used to create the engagement file with all work tasks and document templates.

Table 15 – F6 Creation and processing of engagement files


F6.1. Creation of the engagement file F6.1.1. The system has to ensure creation of the engagement file and engagement acceptance (1 client = 1 company, several engagements can be related to one company, the engagement consists of work tasks to which several documents can be attached). Adding users and their roles and rights to the engagement (viewing and editing rights).

In different engagement stages, flexible description of completed work tasks and classification of these tasks in three groups: planning, obtaining of evidence and formulating conclusions.

F.6.1.2. The engagement consists of several operations (previously called “work tasks”) and the user has to be able to describe and change them freely. There has to be an option to attach documents to each operation.

When creating the engagement, there has to be an option to chose whether to open an empty engagement file, using a file available in the database of templates or other already completed engagement. In this case there has to be an option to chose which work tasks and documents to transfer to the new engagement. The system might contain support procedure that would import templates from the database of templates on the basis of information previously inserted in the software (indices, risk assessment and selected approach). For example, there should be an option to import templates on the basis of the following indices: item – stock, risk – value, approach – data review and review of control. The user has to be able to changed previously selected options before commencement of importing process.

Additional explanation: When planning the work, a provisional choice is made as regards the item of the financial statements. Similar provisional choices are available in the database of templates. Automatic choice could be made on the basis of comparison of compliance of choices. Moreover, the mandatory work tasks and templates that are not dependent upon the choice, can always be imported.

The probable choices might be the following: • name of an item of the financial statements;• statement (legal name; setting and attributing the value; completeness; existence or

occurrence; correctness; periodization; classification; presentation); • risk identified on assurance level; • audit procedures (data reviews, substantive analytical procedures, reviews of

controls);• work tasks (interview, observation, review etc.).

F6.1.3. On each work task the system will include the following information: reference to file, reference to place where the work is conducted, description of work task and conclusions, as well as external document templates related to work task. Depending upon the project completion stage, descriptions of work tasks (templates) can include other information (management representations related to work task, type of procedure / review etc.).

F6.1.4. The user has to be able to change data in the work task field or in the document template.

F6.1.5. Work task templates and templates of related documents are selected according the following criteria: • the respective templates are selected depending upon the engagement (templates

have to be grouped by the type of project: audit templates and review templates); • each engagement always have to include several mandatory work tasks and certain

templates can be used in all engagements; • work tasks and templates for the review of items of the financial statements are

selected during the planning stage (which items have to be reviewed (material) and


to what risks the respective items are exposed to); • several work tasks and document templates are selected manually on the basis of the

auditor’s judgement.

F6.1.6. The software has to include controls that would ensure that a template is not attached to the engagement file (and it is not also rewritten), if the file already contains a template with the same number. In this case the system displays a warning with the list of templates that have been already included in the engagement file and shows which template is therefore not attached to the respective engagement file.When importing document templates from the database of templates, fields of templates are filled in using information from the general engagement data.

F6.1.7. Work tasks have to be numbered (references have to be indicated) and the software has to number the attached documents automatically (number of reference is generated in line with the work task number).

F6.1.8. The user environment is divided in two parts: on the left there are operations (work tasks) and on the right – detailed information related to the respective work task (attached entry form and documents).

F6.1.9. Each operation has one data entry form and user can view the list of operations in a tree structure, where operations are arranged by numbers. There has to be an option to describe work tasks (their references) using at least four-level hierarchy.

Example of the left side of the display view:

Reference

Operation Executor Status

1 Planning

10 Risk Assessment

101 Assessment of external risks

….

A10 Review of receivables

Example of the right side of the display view (in line with the work tasks selected on the left side):

A10 – Review of receivables

Header of summary

Risk assessment results by assurance statements.

Brief description of approach and status.

Contents

Description of work tasks that includes which statements and risks have to be reviewed within this procedure.

Description of the completed work with an option to attach files (for example, file reference A10.1).

Conclusions and summary on identified deficiencies.

Initials of the person who performed the work and the date when it was completed.

Initials of the person who reviewed the work and the date when it was completed.

These example are provided to give an idea of auditors’ wishes and the examples are not


binding to the proposal of solution. Evaluation commission will analyse and assess each solution / proposal separately.

F6.1.10. There has to be an option to filter operations by status, responsible person, type of operation etc.

F6.1.11. During different project stages (planning, obtaining of evidence and drawing conclusions), different entry forms can be used. Preferably that the user can use different types of standard entry forms. According to estimates, 90-95% of work tasks can be performed using one standard work task form (standard task). Majority of practical work is performed using external files. The system has to include separate data entry forms for the following work tasks: • drawing up the engagement budget by work tasks and persons (in case of several

persons, there are several columns; limit might be up to 6 persons). (Explanation: when preparing the budget, the time necessary to complete the initial stage of the engagement is entered (provisional estimate on the basis of previous experience); budget does not have to be dynamic);

• main indices of the financial statements and their initial analysis; • linking of account balances with the corresponding items of the financial statements;• page for selection of accounting policies (what policies are suitable for different

balance sheet and profit or loss items, for example, whether investment properties are disclosed in cost or fair value);

• analysis of financial indices;• table for assessment of identified risks; • template to calculate materiality;• risk assessment on the assurance level; • worksheet to trace corrections and amendments; • summary of uncorrected deficiencies.

Some of the above templates can be copied for other tasks. The abovementioned design and layout of form fields, as well as work logics can be specified during development of the software.

Additional explanation: it is necessary to create a work task form in which the user can attach questions and provide answers (yes, no, not applicable); if the answer implies a problem, the template has to include an option of prior description of this problem. Moreover, it should be possible to answer the question providing textual comments. In the next stage it might be considered whether certain answers, depending on circumstances, could initiate certain automatic procedures. On the other hand, the part of external files might be reduced.

F6.1.12. When assigning work tasks to be completed by the users, there should be an option to assign several tasks simultaneously. The users / work performers can be defined and changed also during the engagement / work process.

F6.1.13. Each work task has to include a status (“completed”, “incomplete”) and register whether and when the work has been reviewed. Creating the above procedures, the software automatically has to generate and attach initials of the user and data.

When performing any work, the auditor can identify a deficiency that should be included in the summary of deficiencies. During the final stage of the engagement, there should be an option to prepare a summary of deficiencies identified during work task completion and to separate the corrected and uncorrected deficiencies. Moreover, the system has to be able to generate a template of uncorrected deficiencies (to export the uncorrected deficiencies, for example, to the management representation letter, if necessary).

Table 16– F7 Completion and archiving of the engagement


F7.1. Completion and archiving of the engagement

F7.1.1. When all work tasks have been completed, the software has to allow archiving the engagement, removing rights of the users to change data / documents etc. in the engagement file. Changes can be introduced only with a permission of the superuser related to the audit company. All changes made after archiving, have to be registered and the person who made the respective changes, have to add an explanation in the journal.

Additional explanation: The superuser related to the audit company has to be able to open the file to make changes. The superuser has to register any such operations along with an explanation as to what and why was changed. When the file is open, either the roles assigned in the beginning of the engagement become active again, or it is possible to add new users with new roles.

F7.1.2. Archiving and supplementing of completed engagements There has to be an option to group and filter projects so that out of all the company’s engagements, it would be easier for the users to find engagements where they have been involved.

Example: The user can view the list of work tasks and engagements (including roles within the engagements) the performance of which has been entrusted to him / her; the user can sort his / her work tasks and engagements in line with their status / entry / stage etc.

Table 17 – F8 Introduction of changes in logic of audit procedures in the software


F8.1. Introduction of changes in logic of audit procedures in the software

F8.1.1. The necessity for changes in the logic of audit process on the software level is provided exceptionally, namely, it should be possible to perform majority of operations and processes using standard templates that can be developed by the user and documents that can be attached to the templates. However, it has to be provided that the superuser related to the audit company can adjust the logics of audit steps (settings of logics can be defined). For example, to define which operations and in what succession should be performed, which templates correspond with which type of engagement etc.

F8.1.2. The user has to be able to describe the following audit logics: - Calculation of materiality using data of the financial statements imported / entered in the software.

An example of materiality calculation model:

Materiality depends upon financial indices entered in the software (up to five) and the probability to determine whether those will be or will not be used in the base calculation of materiality. As regards each index, its percentage is defined that will be used in the calculation. The materiality base is determined as follows:

Materiality is determined as the percentage of materiality base (percentage is determined by the user).

For the purposes of materiality planning, it is determined as percentage (percentage is determined by the user) of the materiality.

Proportion of immaterial deficiencies is determined as percentage (percentage is determined by the user) of the materiality.

F8.1.3. The user has to be able to describe the following audit logics - Risk assessment (risks are assessed for the company and financial statements as a whole, as well as on the level of items of the financial statements) and link of risks to certain items.

Risks are assessed by items and assurances. Both inherent and control risks are assessed. Risks can be assessed applying the following scale: low, medium, high, or using answers “yes” or “no”. The user has to be able to define options provided for risk assessment in


the software settings.

F8.1.4. The user has to be able to describe the following audit logics: – to create a link between items of the financial statements and description of account plan.

The goal is to reduce the amount of manual work transferring account data from accounting software.

The ASIS should provide the following functionality:

• List of components / parts of the financial statements (the user has to be able to change the list).

• Importing of indices of the financial statement and linking of indices with the components of the financial statements described in the system.

Additional explanation: a compliance table has to be created to link the program fields with the fields of file to be imported. It can be done by a software with a table in which the user can create the necessary links with the corresponding table. Only the data that has a corresponding field in this system are imported.

• The list of pre-defined risks divided by components of the financial statements, from which the user can change risks to assess their probability and expected consequences.

• Illustrative forms for standard work tasks and description of their fields taken from the software (financial indices, risk assessment result etc.) on the engagement level.

3.2.2. System integration requirementsTo ensure interfaces with the external systems, it is necessary to use integration environment based on the SOA standards. During development of interfaces related to use of interfaces existing in the external systems, data exchange scenario proposed by the other party has to be considered. When planning architecture of data interfaces, requirements for interfaces set by data providers have to be considered, and, if necessary, it should be possible to implement all the planned operations. Ensuring availability of the ASIS data for external requests has to be provided via web services. If other type of data exchange is necessary, it has to be possible to implement other type of data exchange in the integration environment (for example, data replication, sending of text files, sending and receiving of binary files).

Table 18 – F16 Requirements for the system integration

Precise information units to be received and transferred has to be defined when developing the ASIS design.


F9.1. Basic principles of data exchange

F9.1.1. Joint integration environment

When creating a joint integration environment, preferable the following services should be ensured (requirement can be specified during development of DSD / SRS):• identity and security services. Group of services that provides centralised

authentication, authorisation and audit services. Moreover, security services are responsible for encrypting, deciphering of message and review of integrity on the level of data transmission and messages. Integration environment has to ensure an option to implement a centralised security policy on the level of interfaces on the basis of WS-Policy / WS-Security standards. User authentication has to support the following security tokens: SAML, user ID/password, X509 certificates.


Preferable compliance with standards:

• XML/XSLT/XPath/XQuery – the system has to ensure XML, XSLT, XPath and XQuery support:

• eXtensible Markup Language or XML is a recommendation of W3C for creation of markup languages of specific significance. Its key significance is facilitating sharing of structured text and information in the Internet.

• XSLT (Extensible Stylesheet Language Transformation) is a declarative, XML-based language that is provided to describe XML document transformation.

• XPath is a language of requests provided to find entries (nodes) in XML document.

• XQuery is a language of requests and programming provided to obtain data from a set of XML documents.

• SAML and x.509 – the system has to ensure support for SAML and x.509 standards: • SAML (The Security Assertion Markup Language) is an open XML-based

standard that provides authentication and authorisation information exchange between identity and service providers.

• x.509 is a standard that provides encrypting infrastructure and privileges management infrastructure, including management of cryptography keys and certificates, management of privileges etc.

• Data exchange services Groups of services providing transmission of synchronous and asynchronous messages, replication of databases between the involved DMBS, maintenance of different data exchange protocols (SOAP, HTTP/-S, FTP, SMPT etc.) and formats (XML, binary formats) necessary to integrate the external systems.

• Compliance with the SOA – the system has to comply with the following features of the service-oriented architectures (SOA):• Service quality;• Service autonomy;• Support of open standards;• Service cooperation ability;• Possibility to cooperate with services of external systems in the development

of which different technologies have been used, for example, J2EE or .NET;• Repeated usability;• Weak linkage of components;• Extension of service links with a minimum effect;• Service abstraction;

• Management services. Ensures a centralised defining of service levels, tracing and visual display based on the measurements of service performance (reply time, message processing time etc.).

• Message processing services. Group of services ensuring transformation, validation, routing of messages and error processing.

F9.1.2. Error processing Integration services have to ensure a correct processing of errors and informing systems involved in the data exchange on the status of received and processed data sent by them.

F9.1.3. Other additional reviews It is necessary to ensure integrity of the sent documents and make sure that documents do not contain viruses and other malware.

F9.2. Data exchange with accounting systems

F9.2.1. Information to be received It is necessary to import data of journals / ledgers (account No., opening balance, closing balance, debit and credit) from the accounting programme to the software (input data can be provided in xls, xlsx, txt (tab delimited), csv format).


During development of the ASIS, models necessary for importation have to be based on the most familiar accounting programs (at least 6); data import from other accounting programs will be carried out importing data from previously formatted Excel table.

F9.2.2. Information to be sent NA

F9.2.3. Flexibility of data exchange models

Due to different accounting programs the user should be able to create new data importing schemes. The user has to define / change links between the imported data and components of the financial statements described in the software, on the basis of the used accounting program (links are maintained / saved in the compliance table that the user should be able to change or supplement, if necessary).

3.3. Non-functional requirements of the system

Table 19 – General non-functional requirements of the system


N1. General architecture

N1.1. Type of system architecture Development of the ASIS client site should be created as “Fat” or “Thick Client”, namely, not ensuring client work in an autonomous environment (without continuous Internet connectivity).

N1.2. Development of the system architecture

If the system is developed using a network application, preferably a MVC (Model View Controller) architecture principle of software development should be used in the creation of the system.Each level of architecture level has to be placed on a separate node on a physical or virtual server.On each architecture level of the server, doubling of nodes has to be ensured using cluster technologies (for example, for web-servers - NLB technology, for application servers – clusterisation on the level of applications, for database servers – clusterisation, in MS cluster services Windows environment, HCMP IBM AIX environment, Oracle Clusterware Solaris environment.The system has to be expandable, with an opportunity to add a new node (Web-server and / or application server) without a stoppage.

N2. User interface

N2.1. Compatibility with Internet browsers

If the system has been developed using a network application, compatibility with at least the following browsers:• Microsoft Internet Explorer, starting with v9. If the system has been developed using a network application, review of the user network browser and its version has to be provided and information has to be provided on possible noncompliance of its compatibility.

N2.2. Adequacy of users’ computer resources

The system has to ensure compliance with the functional and non-functional requirements (including compliance with the performance requirements), considering the following minimum computer requirements: • Processor according to www.cpubenchmark.net test with PassMark CPU results of at

least 1100 points. RAM 2 Gb.

N2.3. Use of dynamic user interface The system has to be created on the basis of technological platform that provides a possibility to create a dynamic user interface.

N2.4. Identification of the user in The user, who is authorised to work with the system, has to be clearly identified in the

http://www.cpubenchmark.net/


interface interface.Automatic authentication has to be ensured for the user interface.

N2.5. User interface and data processing language

There has to be an option to ensure change of language in software network interfaces and user interfaces. Both interfaces have to be in Latvian, English and Russian and there has to be an option to add other language in future. Program logics is in one language. At the moment of delivery, software has to be in Latvian, English and Russian. Preferably that the software would include the possibility to verify spelling of text in Latvian (is a solution is not possible free of charge, the Applicant has to indicate a fee in the proposal).

More detailed explanations of error messages. Names of errors and detailed descriptions of errors arising during processing database requests or using functionality of the operating system may be in English. However, all special reviews of data correctness, processing of incorrect action of the user and majority of system error message have to be in Latvian.

N2.6. Mandatory fields Mandatory fields have to be visually emphasised. If a mandatory field has not been filled in, the client control has to be used to warn the user on the necessity to fill in the field prior to trying to save the data.If data saving was not successful due to empty mandatory fields,• a clear message has to be displayed to the user as to what data have not been

entered;• the data entry window has to return to the first empty mandatory field.

N2.7. Ergonomic system design • The user interface has to be convenient and ergonomic (for example, non-existence of horizontal scroll bar (for computer with display resolution 1024x768), as little use of vertical scroll bars as possible, clear layout of introductory fields etc.).

• Words, phrases, concepts and graphics understandable for the system user have to be used in the user interface.

• All the necessary information on use of the system has to be included in the program it self.

• A clear terminology and joint interface elements have to be used in the user interface (for example, windows). Control elements (for example, buttons) have to operate similarly.

• The user has to be informed on the process of fulfilment.• The user interface has to provide an opportunity to use direct menus, scroll bars and

similar elements that allow to increase efficiency of an experienced user.• Information contained in the error message has to be sufficient for the user to

understand the problem and to select the next operation.• The system structure has to limit the probability of the user making a mistake, if in a

certain context, the operation if prohibited, the button is inactive.• It is not necessary to look for information on conducting of a specific task in external

information sources, the system provides a brief help necessary to complete the task. When using the menu “Help”, the user has to be able to find answers to questions how to work with the system.

• A warning has to be shown, if the user tries to perform a potentially dangerous operation or an operation that is difficult to recall.

The visual appearance of the system has to be clear and simple and compliant with the user’s tasks.The user interface has to comply with the following requirements:• the interface has to be ergonomic. For example, a clear and logical layout of data

fields, as small number of scroll bars as possible etc.• One and the same thing in different screen forms has to be called using one and the

same names, terms or abbreviations.• Messages and phrases used in the interface have to be easily understandable for the

user. Standard or error message of the system have to be clear and explaining the essence of a problem. Several options for further action have to be provided.Navigation through screen forms has to be constructed to ensure that the user does not have to remember information when switching between screens.A feedback with the user has to be ensured, trying to inform the user on actions that would be performed in the system.


N2.8. Data in table views Data in table views have to be arranged in a descending order by their registry time, if the functional requirements does not provide otherwise.

N2.9. Data arranging Data arranging in the table in an ascending order by the entry in the respective columns can be performed by clicking on the column title in the header of table. If data have already been arranged by the entry in the column, data arranging direction has to be changed.

N2.10. Selection of data The IS has to provide an option for the user to perform selection of data from drop-down lists at least in the following ways:• selection of needed data from a drop-down list;• data selection entering the first symbols of the necessary name of data.

N2.11. Searching The system has to provide simple and expanded search functionality in any of the content fields of the system. Searching function has to be adjusted depending on the content field of the system.The system has to include a built-in data searching tool that allows perform queries by all the fields and field combinations available to the user.The search tool of the system has to include an option to supplement and modify its search algorithms.

N2.12. Display of selection results Display of search and selection results has to be provided in structured lists.Display of information to which the respective user has the access rights to can be provided.When displaying search and selection result, the number of found and selected entries has to be displayed.The following information has to be included in the list of each found and selected information unit:• display of text fragment from found or selected entry characterising compliance of

the found or selected information unit with the defined search criteria;• a link to full text or file containing the necessary information.There has to be an option for the user to perform searching and selection user arrangement options:• to define the number of entries to be displayed simultaneously;• to arrange results by any parameter of the list.

N2.13. Coding support A multi-language support (for example, using UTF-8 coding) in the user interface and data entry forms has to be provided.Such a coding support has to be provided that would ensure a correct entry, processing, storing and output of at least Latvian, Russian and English, for example, UTF-8.

N2.14. Standards and guidelines to be used

The ASIS has to be developed in implemented depending upon the development platform and technologies considering at least the requirements of the following standards and guidelines:• ANSI/HFES 200 “Human Factors Engineering of Software User Interfaces”;• ELMER/ELMER2 “User Interface Guidelines for Governmental Forms on the

Internet”.

N3. Printouts

N3.1. Printout settings The system has to provide automatic adjustments of printout depending on the type of printing contents (context).Information printout adjustments will be defined when developing the ASIS design.

N3.2. Preparation of printouts The system has to provide the following printouts:• creation and printing of an interactive printout;

Two types of interactive reports can be mentioned as an example:• lists as a table that can be provided as PDF or MS Excel files. If

possible, the user has to be able to define tables and choose the value of which field will be displayed and which fields can be used to formulate a query using data filter.

• List of audit tasks that can be displayed and provided in a PDF file (along with references to documents attached to work tasks). When preparing a report, the user has to be able to select specific


task or a set of tasks that is displayed on the screen.

• creation and printing of a printout with fixed contents;

The system has to provide an option to make printouts from any functional block of the ASIS.

N4. User management

N4.1. Groups of users The system has to include an option to define groups of users and assign sets of rights to users in line with one or several groups of rights referred to in the section “System users”.Users have to have an option to be in several groups of rights.

N5. Security requirements

N5.1. General security principles The system has to provide that the following security principles are complied with:• Confidentiality – information is available only to authorised users;• Data integrity – information if protected against intentional or unintentional

unauthorised modification;• Availability – information and the related functionality is available to a certain extent,

time and place;• Authenticity – source of information can be proven, the system can trust the the

identify is real;• Responsibility – each operation with information has to be linked to its executor.

N5.2. Compliance with the IT security policy

The system has to comply with the LACA IT security policy (it is necessary to discuss its basic principles).

N5.3. Authentication Before commencement of any operations with the system, the system user has to log in the system entering user name and password. This information is used to identify the user identity and the related information.

N5.4. Authorisation In case of a positive authorisation, the system provides the user a compliant set of rights – authorising the user to perform the operations allowed to the respective user.The system has to maintain information of rights and provide access control, so that only the authorised users can access the resources. Control of rights has to comply with the following principles:• only those know who have to know;• to fulfil duties, minimum privileges have to be ensured;• everything that has not been allowed, is forbidden.

N5.5. Review of access rights For each type of access control, the executor, during analysis of requirements, has to define and the Client has to approve an algorithm according to which, during access rights control, it is determined whether the rights to access exist or no.An option to control connection access to the system, integrator and database by the third party tools (for example, SQLPlus) has to be provided. Data have to be protected by administrative accounts.

N5.6. Operations allowed to be performed by unidentified user

Unidentified users are allowed to perform only their identification in the system, as well as operations that can be performed in the public environment of the system (during analysis of requirements, the Client has to identify operations available in the public environment).

N5.7. Identification of the user The system has to ensure that the user is identified before any other operation is performed in the system. In case of unsuccessful identification, the user has to receive a message that identification was unsuccessful without providing additional information that might help to perform rereading of user names or passwords.

N5.8. Storage of passwords The system has to ensure that passwords are saved in the system only in an encrypted form. One of the secure one-way encryption methods has to be used for encryption.When changing the password, the system has to request a repeated insertion of the previous password. Neither new, nor the previous password can be displayed on the screen.


N5.9. Encrypting of information in a public transmission network

The system has to ensure encoding of information when transmitting it in the public data transmission network (except for the information that is publicly available). For encrypting of information, a SSL protocol has to be used with at least 128 bit encoding. The HTTPS data exchange protocol has to be used to web services. To ensure data confidentiality, W3C “XML Encryption” standard can be applied.

N5.10. Non-circumvention of the system security controls

Access to information stored in the system has to be prevented, circumventing application security controls by doubling the controls on the level of database.

N5.11. Additional protection against systems available to external users

The legally binding data have to be protected against modifications in cases, if an external user has obtained control over the ASIS.

N5.12. Integrity Integrity control over the digital object has to be ensure, for example, creating and controlling control amounts of files.

N5.13. Creation of audit trail The system has to perform audit of processes provided by the system to its authorised users. All web services created in the integration solution have to provide a centralised system journal and audit trail.

N5.14. Contents of audit trail The system has to include in each audit trail at least the following information on the event audited:• date and time of the event;• type of the event;• user identity related to the event;• result of the event – successful or unsuccessful operation;• other information specific to the respective event that will be identified during the

analysis of requirements.

N5.15. Storage of audit trail The system has to ensure complete and traceable creation of audit trail that is protected against external factors, including intentional or unintentional misrepresentation of data.

N5.16. Identification and warning of suspicious operations

A concept of identification of suspicious operations has to be developed (methodology, algorithm or a set of algorithms). A concept of service operations has to be verified using audit and system journal data. The service of identification of suspicious operations will perform analysis of audit events in order to discover unusual or suspicious operations. The algorithm identifying the suspicious operations has to be dynamically defined (without reprogramming of the system). The service of identification of suspicious operations needs an interface to monitor user operations and send warnings.

N5.17. Mechanism of session interruption

The system has to provide stopping mechanism of an inactive user session (user session is stopped reaching a defined idle time. The ASIS administrators have to be able to configure this idle time.)

N5.18. Standards and guidelines to be used

Protection mechanisms of the system security have to be developed and implemented considering at least the following standards and guidelines:• A Guide to Building Secure Web Applications and Web Services developed by the

OWASP;• Testing Guide developed by the OWASP;• ISO/IEC 27001 “Information security management systems — Requirements” and

ISO/IEC 27002 “Code of practice for information security management”;• W3C best practice in development of secure network applications.

N6. Requirements for performance and scalability

N6.1. Number of simultaneous users The ASIS has to ensure operation of 200 simultaneous users (the number of CPU and amount of RAM), considering the operation speed requirements mentioner in the next requirement (it has to be provided that in future the number of simultaneous users might reach 1000). It is expected that about 100 audit companies might be registered with the system, each company conducting 10 to 100 audits per year.

N6.2. The system operation speed • For all screen form that do not contain a voluminous business logics have to appear at least in 3 seconds;

• The system has to give a message to the user, if the response from the database is


expected in more than 3 minutes;• Searching when up to 100 units are found in the database, in 95% of cases have to

be performed in at least 5 seconds;• Searching when up to 100 units are found in the database, in 95% of cases have to

be performed in at least 15 seconds;Adding, updating or deletion of one entry in 95% of cases have to be performed in at least 5 seconds.Processing of synchronous request of every user interface with all the involved IS requests and processing cannot exceed 40 seconds in total.The system has to be able to process up to 10 requests per second and up to 10 million requests per month.

N6.3. Amount of data A stable system operation has to be ensured, without exceeding the defined system operation speed requirements with the total amount of data reaching 20 TB.

N6.4. Storage of data Storage of data in a database has to be provided.Digital objects (files) can be stored in the file system of operating system or other type of storage systems.Metadata of files have to be stored in data structure that ensure a quick finding and display of information.

N6.5. Indexation of information Indexation of stored information has to be ensured for those fields according to which search was performed. A precise list of fields to be indexed has to be defined in the ASIS design.

N7. Maintanability of the system

N7.1. Licence requirements All the system nodes have to be licensed in production and testing environments.

N7.2. Testing requirements The Provider has to submit a description of testing procedure, as well as instructions and list of documents (testing plan, testing scenarios, testing process and problem journals).The Provider has to perform alpha-testing of the system prior to handing it to the Client.Functional testing of the system has to be performed.Performance testing is performed in the Client’s testing environment (in real time and work equipment) and it is monitored by the Client’s representative at the Client.The system performance testing is performed:

- documenting results at each node;- changing the number of users from 1 to 200.

All testing expenses have to be included in the proposal (including lease or purchase of testing tools and equipment, purchase of licences).

N7.3. Monitoring requirements The system monitoring has to be provided with an opportunity to control fulfilment of the user transactions, displaying them on the screen and localise problem in each node.A possibility to drill down data in transaction automatically has to be provided to discover the system component that uses the most of the resources.

N7.4. Back-up copies of data The system has to provide automatic doubling of data and creation of back-up copies. The system has to provide automatic creation of back-up copies of data, their storage and archiving, as well as a possibility to use the back-up copies to return and restore the data.Creation of back-up copies has to be possible without stoppages of the system.Creation and restoring of back-up copies can be provided via database or third parties’ software tools. Requirements for the system back-up have to be included in the “Plan of restoration of the system’s operations”.The system database has to provide fault tolerance and quick disaster recovery in case of an accident using mirroring of a database.

N7.5. Transferrability of the system maintenance

The Provider or any other professional software developed company with an experience in the respective development environment and products has to be able to perform the system maintenance. To ensure the system maintenance, the Provider has to supply installation package and documentation (installation and administration manual).Training of the Client’s specialists has to be provided during installation and configuration.The system has to have production and testing environments.Works related to purchase, supply, installation and configuration of equipment have to


be included in the proposal and listed in a separate item.

N7.6. Requirements for technological support

In development of the ASIS, modern technologies and development tools have to be used, ensuring that the employed technologies would be maintained at least 5 years by their producers and the functionality of the system in this period can be supplemented in line with the Client’s needs.

N7.7. Load balancing The system has to support server applications and database load balancing , providing an opportunity to divide requests to several servers in case of increase in the load in future without changing the developed software..The system applications have to operate simultaneously in an active mode in several copies in cluster nodes (application server has to include an opportunity to work in the cluster mode active-active).

N7.8. Continuity of the system operations

The system has to be available 7 days a week, 24 hours a day. During a year, at least 95% of the system usability has to be guaranteed. Time when the system cannot be used due to incidents has to be limited to 2 hours (that corresponds with the minimum necessary recovery time).

N7.9. Testability The system has to ensure simulation of answers to requests, if a request of corresponding type has been received to be able to perform automatised control of service availability and correct operation.

dok/IS_tehniska_specifikacija_v_7_… · Web viewFurther tests are documented in external MS Word...

Documents

Transcript of dok/IS_tehniska_specifikacija_v_7_… · Web viewFurther tests are documented in external MS Word...