17.11.2014

Any work begins with a task, and the work of a technical writer must begin with a technical task. It remains only to figure out what it is and why we need it. Read Kimberly Chan's article so you don't end up in the same situation as the developer from our already beloved comic book series.

What is the terms of reference for software development?

Most developers prefer to work with a software development specification, as this document usually contains the following:

• A complete description of the purpose and functionality of the software;
• Details of how the program will work in terms of speed, response time, availability, portability, reliability, recovery speed, etc.;
• Options for how users will use the software;
• Determining how the application will interact with hardware or other programs;
• Non-functional requirements (for example: performance requirements, quality standards, or design constraints)

Why is it important?

TOR allows developers to clearly understand the goals of the software and what to focus on. In addition, it:

How to write a TOR for software development?

There is no standard method for writing TOR, but we can give some advice:

Create a schema

If you don't have a template yet, they can be found online. Use a template to create a document outline. Modify it to suit your organization's needs.

Terms of reference plans differ depending on the organization and its processes. Some of them may be simple, others are more detailed and complex.

Here is an example of a simple TOR plan for software:

1. Scope of application
2. System overview
3. Links
4. Definitions
5. Examples of using
6. Functional requirements
7. Non-functional requirements

After creating the plan, you can write the specification. Here are some tips:

Choose to write better

The writer must have excellent communication skills. The purpose of the specification is that everyone can understand it. Anything that remains unclear or misunderstood can lead to not very pleasant consequences. Many assume that the involvement of a technical writer in the process helps prevent misunderstandings. There are writers more experienced than developers, with a talent for precision and clarity. Technical writers know how to collect and process the right information; they also know how to communicate customer requirements.

Make information visual

An image can save 1000 words. Turn on visual information, such as tables and graphs, to better convey ideas.

Don't Document Too Much

Try not to include items in the document that do not need to be documented. The TOR can become too long, so avoid redundant information.

Create an online version of the TOR and keep it up to date

As tasks are completed or if there are changes in staff or processes, the TOR will need to be updated. For this reason, keep a virtual version - this will help ensure that the entire team receives an updated document for any change.

1. Introduction
1.1. Program name
1.2. Purpose and scope of the program
2. Requirements for the program
2.1. Requirements for the functional characteristics of the program
2.2. Program Reliability Requirements
2.2.1. Requirements for ensuring the reliable operation of the program
2.2.2. Program recovery time after a failure
2.2.3. Program failures due to incorrect operator actions
3. Terms of use of the program 3.1. Climatic conditions of program operation
3.2. Requirements for qualifications and number of personnel
3.3. Requirements for the composition and parameters of technical means
3.4. Information compatibility requirements
3.4.1. Requirements for information structures and solution methods
3.4.2. Requirements for source codes and programming languages
3.4.3. Requirements for the software used by the program
3.4.4. Requirements for the protection of information and programs
3.5. Special requirements
4. Requirements for software documentation
4.1. Preliminary composition of program documentation
5. Technical and economic indicators
5.1. Economic Benefits of Program Development
6. Stages and stages of program development
6.1. Program Development Stages
6.2. Stages of program development
6.3. The content of the work by stages
7. Procedure for control and acceptance
7.1. Test types
7.2. General requirements for acceptance of work

1. Introduction

1.1. Program name

Name of the program: "Test program"

1.2. Purpose and scope

The program is designed for...

2. Requirements for the program

2.1. performance requirements

The program must provide the ability to perform the following functions:

2.2. Reliability Requirements

2.2.1 Requirements for ensuring the reliable operation of the program

Reliable (sustainable) operation of the program must be ensured by the implementation by the Customer of a set of organizational and technical measures, the list of which is given below:
a) organization of uninterrupted power supply of technical means;
b) use of licensed software;
c) regular implementation of the recommendations of the Ministry of Labor and Social Development of the Russian Federation, set out in the Decree of July 23, 1998 No.
On approval of intersectoral standard norms of time for maintenance of PCs and office equipment and maintenance of software”;
d) regular compliance with the requirements of GOST 51188-98. Data protection. Software testing for computer viruses

2.2.2. Recovery time after failure

Recovery time after a failure caused by a power failure of technical means (other external factors), a non-fatal failure (not a crash) of the operating system,
should not exceed 30 minutes, subject to the operating conditions of hardware and software.
Recovery time after a failure caused by a malfunction of hardware, a fatal failure (crash) of the operating system, should not exceed the time required to troubleshoot hardware and reinstall software.

2.2.3. Failures due to incorrect actions of the operator

Program failures are possible due to incorrect actions of the operator (user) when interacting with the operating system.
To avoid program failures due to the above reason, you should ensure that the end user works without granting administrative privileges to him

3. Operating conditions

3.1. Climatic operating conditions

The climatic conditions of operation, under which the specified characteristics must be ensured, must meet the requirements
presented to technical means in terms of their operating conditions

3.2. Requirements for qualifications and number of personnel

The minimum number of personnel required for the operation of the program must be at least 2 staff positions - a system administrator and the end user of the program - an operator.
A system administrator must have a higher profile education and certificates from the operating system manufacturer. The list of tasks performed by a system administrator should include:
a) the task of maintaining the operability of technical means;
b) the tasks of installing (installing) and maintaining the operability of system software tools - the operating system;
c) the task of installing (installing) the program.
d) the task of creating database backups.

3.3. Requirements for the composition and parameters of technical means

3.3.1. The hardware should include an IBM-compatible personal computer (PC) that acts as a server, including:
3.3.1.1. processor Pentium-2.0Hz, not less;
3.3.1.2. RAM, 1 GB, not less;
3.3.1.3. RAM, 1 GB, not less;
3.3.1.4. operating system Windows 2000 Server or Windows 2003;
3.3.1.5. operating system Windows 2000 Server or Windows 2003;
3.3.1.6. Microsoft SQL Server 2000

3.4. Requirements for information and software compatibility

3.4.1. Requirements for information structures and solution methods

The database runs under Microsoft SQL Server. Multithreaded access to the database is used. It is necessary to ensure simultaneous work with the program with the same database of external data export modules.

3.4.2. Requirements for source codes and programming languages

No additional requirements

3.4.3. Requirements for the software used by the program

The system software used by the program must be a licensed localized version of the operating system Windows 2000 Server or Windows 2003 and Microsoft SQL Server 2000

3.4.4. Requirements for the protection of information and programs

There are no requirements for the protection of information and programs

3.5. Special requirements

There are no special requirements for this program.

4. Requirements for software documentation

4.1. Preliminary composition of program documentation

The composition of the program documentation should include:
4.1.1. technical task;
4.1.2. program and test methods;
4.1.3. operator's manual;

5. Technical and economic indicators

5.1. Economic benefits of development

Estimated economic efficiency is not calculated. The analogy is not carried out due to the uniqueness of the requirements for development.

6. Stages and stages of development

6.1. Development stages

Development should be carried out in three stages:
1. development of technical specifications;
2. working design;
3. implementation.

6.2. Development stages

At the stage of development of the terms of reference, the stage of development, coordination and approval of this terms of reference must be completed.
At the stage of detailed design, the following stages of work should be performed:
1. development of the program;
2. development of program documentation;
3. test program.
At the implementation stage, the development stage, the preparation and transfer of the program, must be completed

At the stage of development of the terms of reference, the following works should be performed:
1. problem statement;
2. definition and specification of requirements for technical means;
3. definition of requirements for the program;
4. definition of stages, stages and terms of development of the program and documentation for it;
5. coordination and approval of terms of reference.
At the stage of program development, work on programming (coding) and debugging of the program should be performed.
At the stage of development of program documentation, the development of program documents should be carried out in accordance with the requirements for the composition of the documentation.
At the testing stage of the program, the following types of work must be performed:
1. development, coordination and approval of test methods;
2. carrying out acceptance tests;
3. Correction of the program and program documentation based on test results.
At the stage of preparing and transferring the program, work must be done to prepare and transfer the program and program documentation to operation at the Customer's facilities.

7. Procedure for control and acceptance

7.1. Test types

Acceptance tests must be carried out at the Customer's site within the agreed time frame.
Acceptance tests of the program must be carried out in accordance with the Program and test methods developed by the Contractor and agreed by the Customer.
The progress of the acceptance tests is documented by the Customer and the Contractor in the Test Protocol

7.2. General requirements for acceptance of work

Based on the Test Protocol, the Contractor, together with the Customer, signs the Program Acceptance and Commissioning Certificate.

We constantly hear about technical tasks, about their importance and about the correct compilation. Technical task for the creation of websites, terms of reference for design projects, terms of reference for software development, terms of reference for this, terms of reference for this ... Is it really that important, the terms of reference, familiarly referred to as TK? And let's find out!

For example, let's highlight one of the most common areas - the preparation of terms of reference for the development of programs. And, perhaps, we will begin to gradually answer the questions that arise.

Why technical task?

Answering the question "why?" It is important to understand what is really being said. As already indicated above, as an example of the preparation of terms of reference, the development of programs was chosen. And this means that the enterprise, firm, organization has real existing, current tasks that can and should be solved more efficiently than it is being done at the moment. In other words, it is necessary to replace human labor, which is expensive and of varying quality, with efficient, and much less expensive, software work.

Indeed, employees need a vacation, they all want to receive their wages on time, periodically “go on sick leave”, and, as a rule, do not express a desire to work on weekends. The development of programs, on the contrary, not only does not bring the indicated problems, replacing one another with enviable regularity, but, on the contrary, solves them!

Let's take a closer look at the solutions. Since the list of current problems that need to be resolved through software has already been formed, it is time to think about the process of solving itself. We gather, sit, argue, find out, and in the end, here it is, more or less the general opinion of responsible persons about what the future program will do. This is how the prerequisite for the preparation of terms of reference for the development of programs is born, slowly but surely.

Of course, things can be quite different. We entrust the preparation of the terms of reference to the specialists of the company offering the development of programs. A couple of meetings in a businesslike, but friendly atmosphere, ready-made briefs, forms, contracts, forms. Everything is completed and everyone is happy. At least for now.

The owner, as they say, is a gentleman, and is always free to choose the best option, both in terms of price and quality. Ideally, of course, that both are commensurate, but you always have to make compromises. If the price is too low, the software development trade-off naturally shifts towards a sharp deterioration in the quality of the software. However, paradoxically, the same thing happens with the illiterate drafting of technical specifications for the development of programs. The money is paid, the product is received, it works, but not like that.

Here, in fact, the answer to the question of why it is necessary to draw up a competent technical task for developing programs is obvious. Move on.

Who is the specification for?

The terms of reference for the development of programs are drawn up, first of all, for those people who will carry out this very development. Accordingly, it should be clear to that person who knows nothing about the client, and even more so, about his tasks and problems. At least he doesn't know yet.

Consequently, the terms of reference for the development of programs should tell the contractor about the company, and about the goals, and about the tasks. At the same time, the more specific the story is, the better - both for the narrator, that is, the Customer for developing programs, and for the listener, that is, for the project executor.

In general, the terms of reference have several goals, and although this may have been said at the very beginning, it is never too late to correct the omissions. And so, the goals:

• Organization
• Information
• Communication
• Jurisdiction.

The organization should be directed to the process itself, in other words, to streamline the creativity and creation of the program, or software package. Strictly, the structure of the terms of reference for the development of programs should be clear and concise at the same time. Since reading 120-150, or even more, pages of an indigestible technical text, the programmer's creative personality simply cannot. So, brevity is the sister of talent.

The information component of the TOR should be complete, but concise.

And again, a simple rule, "necessary and sufficient." It, as usual, must be adhered to always and everywhere, but when drawing up terms of reference for developing programs, this rule becomes number one. A competent technical task is the first and last document that will tell about all the wishes of the customer in a form that is easy for the programmer to understand. Do you want to turn the life of your company or enterprise to a fundamentally new level? Then, the terms of reference for the development of programs is the very fulcrum with which the world will turn over in the direction you indicated. And this, you see, can not be neglected, by any means.

Communication is somewhat more difficult. Why? Yes, because communications, and even in the relatively creative process, are always difficult. Especially if you speak different languages. And there can be several languages ​​here, more precisely - according to the number of participants in the project, code-named "software development".

Simply put:

• Client, he is the Customer
• Project manager
• Project executors, they or he: programmer(s)
• Other possible participants who have an opinion: how to do it, how to do it better, and how it should end.

Naturally, creating a common project, these participants are forced to look for a language that is accessible to a common understanding by everyone. This language is intended to be the terms of reference for the development of programs. Ideally, the main thing is to establish a communication channel between the first and third links, and the less interference the second and fourth links introduce, the better the result will be, and the development of programs will bring the desired result with minimal nerve loss.

So we got to the jurisdiction, incidentally touching on the issue of "loss of nerves." Thanks to the terms of reference, it is possible to judge the conformity of the result of the development of programs and the given initial conditions. It must be said that short-lived memory suffers both for the customers of the project and for the executors. The first forget about the agreed cost, the number of edits, the possibilities of implementation and debugging, and the second - in principle, about what and when they should have done. In order to reduce amnesia and its consequences to a minimum, it is necessary again, a clear and specific TOR for the development of programs!

How to write a technical task?

Having convinced of the necessity, and even the pricelessness of the terms of reference in the development of programs, we can continue the conversation further. Now we have come to the most serious question: how to draw up a TOR so that it is competent, clear, concise, but specific ?! And we don't need anything else.

This was taken care of back in the ancient times of the USSR, having developed a whole concept of standards called GOSTs. Surprisingly, the development of programs, these standards also provide that you will agree, cannot but rejoice.

The development of programs and the preparation of terms of reference in this area is regulated by GOST 19.201-78 one system software documentation. Technical task. Requirements for content and design.

Also, two more guides will not be superfluous:

• GOST 2.114-95 Unified system for design documentation. Specifications;
• GOST 34.602-89 information technology. Set of standards for automated systems. Terms of reference for the creation automated system. This trinity, of course, can be considered the "holy of holies" in the development and preparation of technical specifications for almost any subject area. There are, of course, other standards that can and should be followed, but let's remember the "necessary and sufficient".

What do we end up with?

Answer: the general structure of the terms of reference, including the development of programs.

• What needs to be done within the framework of the project;
• Why is it needed, and for what specific purposes;
• Where the result of the project will be used (read, program development), in what area of ​​activity, and at what level;
• What requirements should be satisfied by the development of programs;
• What needs to be done in the process of working on a project;
• How will the result be evaluated by the Customer;
• What documents establish the procedure for interaction on the project;
• What is the basis for initiating work on a software development project.

The second part of the specified GOST 19.201-78, which prescribes the content of the sections, will help to draw up the terms of reference for the development of programs in more detail.

A separate point of our specifics is software development, I would like to highlight the section of software requirements. When compiling this section, the issue should be approached formally. In other words, "open a new window", "edit the current file through commands from user consoles", and "save changes when the main program window is closed" is a clear and formal approach.

Also, the development of programs must meet a number of requirements that must be stated in the terms of reference. Here is the list of requirements:

• to the set of functions performed by the program;
• on the organization of input and output data;
• to speed;
• to the reliability of functioning;
• to the duration of recovery in case of failures;
• on failures due to incorrect actions of the user;
• to types of service;
• to the number and qualifications of personnel interacting with the program;
• to the parameters of the technical means on which the normal performance of the program will be ensured;
• to source languages ​​and programming codes, information structures and third-party software tools;
• on protection and information security;
• to labeling and packaging;
• to the conditions of transportation and storage.

Also, the list of requirements for the development of programs can be changed: supplemented or reduced depending on the specific conditions of the project.

Who draws up the terms of reference?

It's time to take stock. Who should shoulder such a heavy burden on their, for sure, fragile shoulders - the preparation of technical specifications for the development of programs. Naturally, the project manager! it is this person who, with overwork, paves the way for joint happiness, harmony and mutual understanding of the Contractor and the Customer.

Naturally, the work of a manager is no less creative than that of a programmer, and in order to avoid creative chaos and disorder, it also needs a clear design. Let's put everything related to the functions of a project manager during development in their places:

1. Setting the task of the project;
2. Formation and specification of requirements for technical implementation;
3. Formulation of requirements for the developed program;
4. Coordination of stages, their duration, and preparation of documentation;
5. Indication of programming languages ​​and codes;
6. Drawing up, updating and approval of the technical specifications by the Customer.

Despite the seeming simplicity of these functions, only a small percentage of managers are capable of performing them well. and so that no one is found guilty, it is necessary to approve the terms of reference with the signatures of representatives of both parties, indicated by the terms of the Agreement for the development of programs.

Well, these parties must be guided by GOST 19.201-78, which is neither more nor less, but almost 30 years old.

related posts

The concept of "reverse engineering" is a modern formulation of the former concept - copying, improving ... With the development of computer technology, ...

Essentially, with information technology Humanity has faced and faces at every step of its life. Just…

The concept of reengineering was born in the 90s as a meaningful response to the problems that arose during mass automation ...

MINISTRY OF SCIENCE AND EDUCATION

RUSSIAN FEDERATION

SEI HPE "ADYGE STATE UNIVERSITY"

FACULTY OF PHYSICS

DEPARTMENT ASOIU

TERMS OF REFERENCE FOR CREATING SOFTWARE

PRODUCT

INTRODUCTION…………………………………………………………………………. ... 3

1. BASIS FOR DEVELOPMENT……………………………………….. ...…4

1.1. The document on the basis of which the development is carried out……………………....4

1.2. The organization that approved the basis for the development, and the date of its approval4

1.3. Name of the development topic…………....………………………………….4

2. PURPOSE OF DEVELOPMENT……………....…………………………………..5

2.1 Criteria for the effectiveness and quality of the program…....………………………..5

5

3. REQUIREMENTS FOR THE PROGRAM…………………………....…………………...6

3.1 Performance requirements………....………………….6

3.1.1 The composition of the functions performed…………………………….....……………….6

3.1.2 Organization of input and output data…………………....…………….6

3.1.3 Time characteristics and memory size…………………...6

3.2 Reliability requirements……………………………………………....……….…6

3.2.1 Requirements for reliable operation……………………....………6

3.2.2 Control of input and output information………………………….....…..7

3.2.3 Recovery time after failure……………………………………....….7

3.3 Operating conditions………………………………………………………......7

3.4 Requirements for the composition and parameters of technical means…………………...7

3.5 Requirements for programming languages………………………………….......8

3.6 Requirements for the software used by the program……......8

3.7 Requirements for software documentation……………………………………..... 8

4. TECHNICAL AND ECONOMIC INDICATORS………………………… ..... 9

5. STAGES AND STAGES OF DEVELOPMENT……………………………………….........9

6. PROCEDURE FOR CONTROL AND ACCEPTANCE……………………………………….........9

6.1 Types of tests………………………………………………………………........9

6.2 General requirements for acceptance………………………………………………..... 10

7. STAGES OF IMPLEMENTATION………………………………………………………......10

INTRODUCTION

The full name of the software development: "Program K", hereinafter referred to as the "program". The short name of the program is "PC".

At the moment there are no similar software products.

The developed program is applied at any enterprise where there is a working staff.

The developer of this software product is a student of group 4A1 Ivanov A.V. hereinafter referred to as "developer".

The customer of the software product is OJSC RTS, represented by director A.M. Gutenko.

1 BASIS FOR DEVELOPMENT

1.1 The document on the basis of which the development is carried out

The work is carried out on the basis of the assignment for the discipline "Theoretical foundations of automated control"

1.2 Approving organization and date of approval of this document

The assignment was approved and issued by A.V. Kozakov, head of the technical department of RTS OJSC.

Kozakov A.V.

1.3 Name of the development topic

The name of the development topic is “Accounting for working time”.

2 PURPOSE OF THE DEVELOPMENT

This development is a semester work on the discipline "Theoretical foundations of automated control"

2.1 Criteria for the effectiveness and quality of the program

social factor. This software development is very easy to learn and is designed not only for professionals, but also for ordinary users working in Windows. A convenient, intuitive interface, combined with a powerful system of auxiliary pictures and tooltips, allows you to work with the program without prior preparation.

Compliance with the current state of the software market of this profile. Unlike expensive and complex programs, PC is ideal for business representatives, as it contains everything they need, but is not overloaded with useless and unnecessary features. The technology of creating a program in visual programming environments makes its interface universal and compatible with Windows 95/98/2000/XP operating systems.

Economic forces. The program represents the best ratio of price and features provided to it and will undoubtedly take its niche in the market of cheap programs. The main users will be business representatives who simply cannot pay for expensive programs from 1C and the like.

2.2 Goals of program design

The creation of this program pursues a number of technical and economic goals:

Creation of a software product necessary for recording working hours.

Creating a cheap alternative to currently existing expensive programs.

Create an intuitive program with a convenient and versatile Windows.