We prepare terms of reference on a state system: 5 practical advice
How it is necessary to write technical specifications on a system that expectations matched reality that on acceptance you not just learned a system which light image was so painfully approved in the reporting, but also did not regret about its births? Practical recommendations - in article prepared for TAdviser by the expert Lyudmila Bogatyreva. They cover approval, tests, training, system implementation and a quality assurance.
Content |
Development of automated information systems is regulated by state standard specifications (first of all 19 and 34) and a set of regulatory legal acts. More strict requirements always extend to the state information systems. About them it is much written in open sources therefore in this article we will give several practical advice. We will consider stages of works when to the forefront there is an organization of joint work of the customer and contractor.
Recommendations will be useful first of all to representatives of IT departments of authorities which are engaged in preparation of the technical specifications (TS). They are applicable to all classes of the state information systems – to the websites, electronic document management, interdepartmental interaction, the systems of rendering state services, the register systems and so forth.
Unreasoned terms of reference can lead to the fact that:
- the contractor spends more resources for approvals and the reporting, than for development;
- a system is created, there correspond the terms of reference, but for some reason are not demanded by users;
- the works are completed, but after acceptance there were roughnesses which need to be eliminated.
Further we will sort that needs to be put in terms of reference not to get into similar situations. In recommendations we will consider difficult situations when owing to these or those reasons the customer and the contractor are limited in resources. Example of a standard difficult situation: the customer within half a year approved an action for development of a system with Ministry of Telecom and Mass Communications Russia, then a month more coordinated the documentation in the department, then - the publication of tender, summing up the results, the conclusion of the public contract. On execution of works there were 2-3 months, and even less. And it is the end of the year when deadlines on all projects come nearer.
Any project it is possible and it is necessary to do correctly, i.e., in advance planning an action (it is better in a year) and observing passing of all stages of lifecycle of creation of an information system.
On own experience and experience of colleagues we will tell about the risks connected with unreasoned requirements. We performed a set of different terms of reference and recommendations about specific formulations are taken from best practices of the state customers.
Approvals
The customer wants that practically the contractor approved all reporting with him, including inspection, the engineering design, the user instructions, materials of tests and so forth. It fixes it in terms of reference, underestimating the scale of work which shoulders the.
The point that the customer approves the report, means need of the visa of the responsible person on the cover page or the sheet of approval in the report of signatures of the different parties. At once there are many questions: "whom to put?", "why I should approve these documents?" and others.
There are cases when the requirement that the customer approves any documents occurs in terms of reference. It is better not to use such formulation as the approval process is a special method of introduction of the document to action and assumes the edition of the relevant administrative document: for example, protocol, order, solution, resolution.
If a customer is the IT department, and users of a system – operating structural divisions, it will entail need and for their visas on such documents. And it is difficult to bring together them if to consider all bureaucratic procedures, absence of the necessary employees because of holidays or business trips, unwillingness of employees to put the visas on unclear technical documentation. Besides, in the conditions of tough deadlines, especially in the end of the year, the customer it is simple not to provide in forces the necessary approvals in time. It can deliver all project "on a pause".
We recommend to put the requirement for approval or a statement only for the engineering design, and for other reporting to request from the contractor intermediate report versions in electronic form before the end of the reporting period that there was time to give on them notes or wishes.
Use the following formulations for inclusion in terms of reference:
In results of works we fix – "The engineering design approved with the customer". We distribute the following requirements to all reporting materials:
- The contractor in 5 working days prior to the termination of the corresponding stages directs to the e-mail address of the customer specified in the agreement, intermediate report versions.
- In case of receipt from the customer of notes and recommendations about their completion, the contractor makes the corresponding corrections and takes into account made comments and recommendations in final report versions.
Tests
Tests – one of the most important stages of works on creation or development of a system. It allows to check it for compliance of terms of reference and to receive a feedback from users before its implementation (input in commercial operation). According to state standard specification there are 3 types of tests – preliminary, trial operation and acceptance tests. Ideally on all these tests also more, depending on the scale of works is necessary of 1.5 months. We remember the standard difficult situation described above. What to do?
Each type of tests requires high organizational load: formation of the commission, holding the action, signing of test sheets with acts. It means need of visas from ten people.
In a situation with short terms we recommend to exclude preliminary tests. In the most critical situations it is possible to leave only conducting acceptance tests though it contradicts state standard specification. If on such acceptance you face a product in which a set of defects, then there is an opportunity to appoint conducting repeated acceptance tests by the time of which the contractor should eliminate the discrepancies revealed on primary acceptance. Here the most important - is competent to calculate terms which are allotted on acceptance tests in terms of reference if necessary to lay in them and repeated.
Success of tests in many respects depends on the program and a test procedure (PMI). We recommend to formulate terms of reference so that each requirement it was possible to include as separate point in PMI, to check it by demonstration. Avoid subjective or abstract formulations: for example, "A system should provide user-friendly interfaces". There is a question what to understand as convenience. Think of how the contractor will show you implementation of these requirements. It will help to avoid excess disputes inside and questions of quality and amount of completed work according to terms of reference at inspection bodies.
We recommend to use the following formulations for inclusion in terms of reference:
For acceptance of results of works in general acceptance tests are carried out. Acceptance tests are carried out in the presence of customer representatives and the contractor. Should be tested according to the document "Program and Technique of Acceptance Tests" developed by the contractor. Acceptance tests are carried out by the customer for the purpose of establishment of compliance provided by the contractor to requirements of the customer. Results of conducting acceptance tests should be reflected in the protocol of conducting acceptance tests. Based on conducting acceptance tests the act of readiness of a system for input in commercial operation is made out. At identification during acceptance tests of critical notes the contractor should resolve comments and acceptance tests should be carried out repeatedly. The revealed errors after which a system cannot continue the work are considered as critical notes. |
We NE recommend to formulate requirements as follows:
The design of the interface should contain minimum necessary quantity of graphic elements and provide as it is possible the high speed of loading |
- (how to define minimum necessary quantity of graphic elements what to compare loading speed to?)
The automated workplace of the Administrator should provide the functionality allowing to automate partially activity of the Administrator regarding accomplishment of standard tasks due to use of macroes |
- (are not specified what standard tasks should be automated)
What solution is appropriate here: for example, to add specific requirements to the text of terms of reference or to give the chance to define these requirements at a stage of engineering design:
The list of standard tasks which need to be automated due to use of macroes, is defined at a stage of engineering design. |
Training
Training is usually provided at a stage of trial operation. Often the customer and the contractor organize process of full-scale training in work in a new or modifed system later when they passed acceptance tests, and at a stage of trial operation test a system on a limited circle of users. Such organization pursues the unique aim – to lower load of responsibles, not to use them as guinea pigs and not to prevent them to work while there is a process of input of a system to action.
There are several moments which are important for considering. First, you should not order the training videos. They are less convenient for studying of a system and further work with it, than standard user instructions or the guide on a system. The main thing – is competent to formulate requirements to them. Proceeding from our experience, is most practical to do well structured user instructions with hyperlinks on sections.
It is important to do the step-by-step description of each user scenario and to insert into the instruction screenshots in the scale allowing to consider all necessary functional elements. The user will be able always to print, to put it on a table – you know how your employees like to do it.
Secondly, in the system there shall be a section where current versions of operational documentation are placed.
Thirdly, for acquaintance to the new or updated system the technology of the guide – the system of interactive hints on navigation in a system which appear after authorization of the user is effective. They tell about new functionality, about the sequence of actions, about subsystems which in it are and so on.
Following to these recommendations will help to perform painless system implementation, to minimize rejection by employees of a new format of work.
However you should not use the word "training" in the text of terms of reference. Creation and development of the state information systems takes place on the 242nd expense type. Training is other expense type (244). Instead use the concepts "consultations", you can concretize what – internal or remote.
We recommend to use the following formulations for inclusion in terms of reference:
The contractor should hold consultations of employees on work with a system. During consultations the representative of the contractor should tell informative material and answer questions of users of a system. According to the results of carrying out consultations the contractor should provide the report. |
Implementation
We understand a stage of input of a system in commercial operation, i.e. when it passed acceptance tests as implementation and is ready to work of users. At this moment the customer should refuse all different ways of work with process outside the developed system. It is the most difficult stage requiring high user discipline. That to maintain it up to standard, development of regulations on a system and regulations of work of officials in a system is required.
Provision is an organizational and administrative document which sets general options of system operation and first of all is necessary for its commissioning.
The regulations are more likely the working document which should be as "the instruction for the pilot". In it areas of responsibility are distributed, requirements to the sequence and results of activity, terms are established. For example, the processing order in the system of the statements which came to department in an electronic or paper form, an order of maintaining registers, an order of sending requests to SIEI or processings of the received requests, etc. is established. The regulations should be small (5-10 pages) and the simplest.
The requirement about project development of provision it would be strange to include in terms of reference as it is work of officials, but the help of the contractor by his preparation nevertheless is necessary. Therefore we recommend to state this work in terms of reference vaguely, for example, to call such document "The description of a system". And project development of regulations can be shifted quietly to shoulders of the contractor as a part of works on operational documentation.
Provision and the regulations will not earn if they are not approved by the order of department, having undergone all necessary approvals inside. But after that the political weight of a system will increase, especially in case it covers activity of a set of structural divisions.
Use the following formulations for inclusion in terms of reference:
The contractor should develop the description of a system which includes characteristic on the following items: the system designation (for what automation of processes it is intended) tasks and functions of a system (for what maintaining registers / registers it is used what gosuslugi / state functions are covered also by other) participants (who are an operator and what functions he performs what categories of users, what divisions covers structure of a system (architecture, program and hardware, structure of subsystems/modules) characteristics of information (storage life, technologies of storage, a data protection order, types – public, chipboard, a state secret, etc.) access order (as identification and authentication of users who and as organize access is performed). The contractor should develop the Draft of regulations of work of staff of department in a system which should reflect an operating procedure in a system on the following processes: … |
Quality assurance
Quality assurance – an important part of terms of reference both for the customer, and for the contractor which has a strategic importance. In a standard situation the quality assurance is that spare parachute which will help the customer to accept works, understanding that not everything is smoothly made because of the either party and to legalize process of elimination of roughnesses which will be beyond the main works.
The value of a quality assurance is important and in its direct appointment – to provide completion of a system if shortcomings of the future will be revealed. And what will be a quality assurance longer, that it is more profitable to the customer, but rules of business practice usually do not allow to set its term more than 1 year. It is also important to designate correctly that enters a guarantee to what cases it extends.
We recommend to use the following formulation for inclusion in terms of reference:
Guaranty period of the performed works (the rendered services) makes not less than 12 (twelve) months. The specified term is calculated from the date of signing by the Customer of the delivery and acceptance certificate of the performed works (the rendered services). If during guaranty period defects or shortcomings executed by the contractor are found (the rendered services), then the contractor is obliged to eliminate them by own efforts and at own expense, in perhaps short terms. Guaranty period in this case lasts respectively for elimination of defects, shortcomings. |
In the following article we will tell you how it is correct to build in terms of reference of the software requirement – how to register that it should be domestic how to avoid a vendorozavisimost how to organize transfer of the source code and why it is necessary to require on acceptance of system deployment from source codes.