17.11.2014

Any work begins with a task, and the work of a technical writer should begin with a technical task. All that remains is to figure out what it is and why we need it. Read Kimberly Chan's article to avoid ending up in the same situation as the developer from a comic book series we already love.

What is a technical specification for software development?

Most developers prefer to work with a technical specification for software development, since 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?

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

How to write technical specifications for software development?

There is no standard method for writing a technical specification, but we can give some tips:

Create a diagram

If you don't already have a template, you can find them online. Use the template to create a document outline. Modify it to suit your organization's needs.

Statement of work plans vary depending on the organization and its processes. Some of them can be simple, others are more detailed and complex.

Here is an example of a simple technical specification 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 a plan, you can write a specification. Here are some tips:

Choose to write the best

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 people assume that having a technical writer involved in the process helps prevent misunderstandings. There are writers who are more experienced than developers, with a talent for bringing precision and clarity. Technical writers know how to collect and process relevant information; they also know how to communicate customer requirements.

Make information visual

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

Don't document too much

Avoid including items that do not need to be documented. The statement of work may become too long, so avoid unnecessary information.

Create an online version of the technical specifications and constantly update it

As tasks are completed or if changes occur in staff or processes, the TOR will need to be updated. For this reason, keeping a virtual version will help ensure that the entire team receives an updated document whenever a change occurs.

1. Introduction
1.1. Program name
1.2. Purpose and scope of the program
2. Program requirements
2.1. Requirements for the functional characteristics of the program
2.2. Requirements for program reliability
2.2.1. Requirements for ensuring reliable operation of the program
2.2.2. Program recovery time after failure
2.2.3. Program failures due to incorrect operator actions
3. Terms of use of the program 3.1. Climatic operating conditions of the program
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 software used by the program
3.4.4. Requirements for the protection of information and programs
3.5. Special Requirements
4. Requirements for program 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. Stages of program development
6.2. Stages of program development
6.3. Contents of work by stages
7. Procedure for control and acceptance
7.1. Types of tests
7.2. General requirements for acceptance of work

1. Introduction

1.1. Program name

Program name: "Test program"

1.2. Purpose and scope

The program is designed for...

2. Program requirements

2.1. Functional requirements

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

2.2. Reliability requirements

2.2.1 Requirements for ensuring reliable operation of the program

Reliable (sustainable) operation of the program must be ensured by the Customer’s implementation of a set of organizational and technical measures, the list of which is given below:
a) organizing uninterrupted power supply of technical equipment;
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 Resolution of July 23, 1998.
On approval of inter-industry standard time standards for work on servicing PCs and office equipment and software support”;
d) regular compliance with the requirements of GOST 51188-98. Data protection. Testing software for computer viruses

2.2.2. Recovery time after failure

Recovery time after a failure caused by a power failure of technical equipment (other external factors), non-fatal failure (not crash) of the operating system,
should not exceed 30 minutes, subject to compliance with the operating conditions of the hardware and software.
The recovery time after a failure caused by a malfunction of hardware or a fatal failure (crash) of the operating system should not exceed the time required to eliminate hardware malfunctions and reinstall software.

2.2.3. Failures due to incorrect operator actions

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

3. Operating conditions

3.1. Climatic operating conditions

The climatic operating conditions under which the specified characteristics must be ensured must satisfy the requirements
requirements for technical equipment 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 - the system administrator and the end user of the program - the operator.
The system administrator must have a higher specialized education and certificates from the operating system manufacturer. The list of tasks performed by the system administrator should include:
a) the task of maintaining the operability of technical means;
b) the tasks of installing (installing) and maintaining the functionality of system software - the operating system;
c) the task of 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 technical means must include an IBM-compatible personal computer (PC), acting as a server, including:
3.3.1.1. processor Pentium-2.0Hz, no less;
3.3.1.2. RAM capacity, 1Gigabyte, no less;
3.3.1.3. RAM capacity, 1Gigabyte, no 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. Multi-threaded 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

There are no additional requirements

3.4.3. Requirements for software used by the program

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

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 program documentation

4.1. Preliminary composition of program documentation

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

5. Technical and economic indicators

5.1. Economic benefits of development

Estimated economic efficiency is not calculated. An analogy is not drawn due to the uniqueness of the development requirements.

6. Stages and stages of development

6.1. Development stages

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

6.2. Development stages

At the stage of development of the technical specifications, the stage of development, coordination and approval of this technical specification must be completed.
At the detailed design stage, the following stages of work must be completed:
1. program development;
2. development of program documentation;
3. testing the program.
At the implementation stage, the development stage must be completed - preparation and transfer of the program

At the stage of development of technical specifications, the following work must be performed:
1. statement of the problem;
2. determination and clarification of requirements for technical means;
3. determination of program requirements;
4. determining the stages, phases and timing of the development of the program and documentation for it;
5. coordination and approval of technical specifications.
At the program development stage, work must be done on programming (coding) and debugging the program.
At the stage of developing program documentation, the development of program documents must be carried out in accordance with the requirements for the composition of the documentation.
During the testing phase 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. adjustment of the program and program documentation based on test results.
At the stage of preparation and transfer of the program, work must be completed to prepare and transfer the program and program documentation for operation at the Customer’s facilities.

7. Procedure for control and acceptance

7.1. Types of tests

Acceptance tests must be carried out at the Customer's site within the specified 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 upon by the Customer.
The Customer and the Contractor document the progress of acceptance tests in the Test Report

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.

One constantly hears about technical specifications, their importance and correct preparation. Technical task for the creation of websites, technical specifications for design projects, technical specifications for software development, technical specifications for this, technical specifications for that... Is this very important, technical specifications, familiarly called TK? Let's figure it out!

As an example, let’s highlight one of the most common areas - drawing up technical specifications for software development. And, perhaps, we will begin to gradually answer the questions that arise.

Why technical specifications?

Answering the question: “why?” It's important to understand what we're really talking about. As already indicated above, program development was chosen as an example of drawing up technical specifications. And this means that the enterprise, firm, organization has real-life, current problems that can and should be solved more efficiently than is currently being done. In other words, it is necessary to replace human labor, which is expensive and of variable quality, with efficient, and much less expensive, software work.

Indeed, employees need 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. Program development, on the contrary, not only does not bring the identified problems that replace one another with enviable regularity, but on the contrary, it solves them!

But let’s look at the solutions in more detail. Since the list of current problems that need to be solved through software has already been formed, it is time to think about the solution process itself. We gather, we sit down, we argue, we find out, and in the end, here it is, the more or less general opinion of the people in charge about what the future program will do. This is how the prerequisite for drawing up technical specifications for software development is born, slowly but surely.

Of course, things could be completely different. We entrust the preparation of technical specifications to specialists from a company offering software development. A couple of meetings in a businesslike but friendly atmosphere, ready-made briefs, forms, contracts, forms. Everything was filled out, everyone is happy. At least for now.

The owner, as they say, is a master, and is always free to choose the best option, both in price and quality. Ideally, of course, both should be balanced, but compromises always have to be made. If the price is too low, the software development trade-off naturally shifts towards a sharp deterioration in software quality. However, paradoxically, the same thing happens when the terms of reference for software development are not drawn up correctly. The money is paid, the product is received, it works, but it doesn’t work.

Here, in fact, the answer to the question of why you need to draw up a competent technical specification for software development is obvious. Go ahead.

For whom is the technical task?

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 understandable to a 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 software development should tell the contractor about the company, its goals, and its objectives. Moreover, the more specific the story is, the better - both for the narrator, that is, the Customer of program development, and for the listener, that is, for the project executor.

In general, the technical specification has several goals, and although this may have been said at the very beginning, it is never too late to correct omissions. So, the goals:

• Organization
• Information
• Communication
• Jurisdiction.

The organization should be aimed at the process itself, in other words, to streamline the creativity and creation of a program or software complex. Strictly, the structure of the technical specifications for software development should be clear and at the same time concise. Since a creative programmer simply cannot read 120-150, or even more, pages of indigestible technical text. This means that brevity is the sister of talent.

The information component of the technical specification must be complete, but concise.

And again, a simple rule, “necessary and sufficient.” As usual, it must be adhered to always and everywhere, but when drawing up technical specifications for program development, this rule becomes number one. A competent technical specification is the first and last document that will tell about all the customer’s desires 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 point of support with the help of which the world will turn over in the direction you indicate. And you must agree, this cannot be neglected.

Communications are a little more complicated. Why? Yes, because communications, and even in a relatively creative process, are always difficult. Especially if you speak different languages. And there may be several languages ​​here, more precisely - according to the number of participants in the project, code-named “software development”.

Simply put:

• Client, aka 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 all end.

Naturally, when creating a common project, these participants are forced to look for a language that everyone can understand. The terms of reference for program development are intended to become such a language. 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 loss of nerves.

So we got to the jurisdiction, simultaneously touching on the issue of “loss of nerves.” Thanks to the technical specifications, it is possible to judge the compliance of the result of program development with the specified initial conditions. It must be said that short-term memory affects both the project customers and the performers. The former forget about the agreed cost, the number of edits, the possibilities of implementation and debugging, while the latter forget, in principle, what and when they should have done. In order to reduce amnesia and its consequences to a minimum, it is again necessary to have a clear and specific technical specification for the development of programs!

How to draw up technical specifications?

Having convinced yourself of the necessity, and even pricelessness, of technical specifications when developing programs, you can continue the conversation further. Now we come to the most serious question: how to draw up technical specifications so that it is competent, clear, concise, but specific?! But 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 is also provided for by these standards, which, you see, cannot but rejoice.

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

Two more guides will also be useful:

• GOST 2.114-95 Unified system of design documentation. Technical specifications;
• GOST 34.602-89 information technology. Set of standards for automated systems. Terms of reference for creation automated system. This trinity can undoubtedly be considered the “holy of holies” when developing and drawing up technical specifications for almost any subject area. There are, of course, other standards that can and should be followed, but let’s remember “necessary and sufficient.”

What do we end up with?

Answer: the general structure of the technical specifications, including for the development of programs.

• What needs to be done within the project;
• Why is this needed, and for what specific purposes;
• Where will the result of the project be used (read, program development), in what field of activity, and at what level;
• What requirements must software development satisfy?
• What needs to be done while working on the project;
• How will the result be assessed 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 you draw up a technical specification for the development of programs in more detail.

A separate point of our specificity is software development; I would like to highlight the section on software requirements. When compiling this section, the issue must be approached formally. In other words, “open a new window,” “edit the current file using commands from user consoles,” and “save changes when closing the main program window” is a clear and formal approach.

Also, the development of programs must satisfy a number of requirements that must be stated in the technical specifications. Here is the list of requirements:

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

Also, the list of requirements for program development 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 put such a heavy burden on their probably fragile shoulders - drawing up technical specifications for developing programs? Naturally, a project manager! It is this person who, through backbreaking work, paves the way to joint happiness, harmony and mutual understanding between 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 clear design. Let’s put everything related to the functions of a project manager during development in its place:

1. Statement of the project task;
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. Specifying programming languages ​​and codes;
6. Drawing up, updating and approval of technical specifications by the Customer.

Despite the apparent simplicity of the listed functions, only a small percentage of managers are capable of performing them well. In order to avoid finding someone to blame, it is necessary to approve the terms of reference with the signatures of representatives of both parties, indicated by the terms of the Program Development Agreement.

Well, the 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 previous concept - copying, improvement... With the development of computer technology,...

Essentially, with information technology humanity has encountered and is confronted 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

GOU VPO "ADYGHE STATE UNIVERSITY"

FACULTY OF PHYSICS

DEPARTMENT OF ASOIU

TERMS OF REFERENCE FOR THE CREATION OF 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 THE DEVELOPMENT………………....…………………………………..5

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

2.2 Objectives of program development……………………………………………5

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

3.1 Requirements for functional characteristics………....………………….6

3.1.1 Composition of functions…………………………….....……………….6

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

3.1.3 Timing 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 software used by the program.........8

3.7 Requirements for program 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. IMPLEMENTATION STAGES……………………………………………………......10

INTRODUCTION

Full name of the software development: “Program K”, hereinafter referred to as “program”. The short name of the program is “PC”.

At the moment, there are no similar software products.

The developed program is used at any enterprise where there are workers.

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 RTS OJSC, represented by director A.M. Gutenko.

1 BASIS FOR DEVELOPMENT

1.1 Document on the basis of which 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 The organization that approved this document and the date of its approval

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

Kozakov A.V.

1.3 Name of the development topic

The name of the development topic is “Working Time Accounting”.

2 PURPOSE OF THE DEVELOPMENT

This development is a semester-long work in 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 for 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 the capabilities it provides and will undoubtedly occupy 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 Program development goals

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

Creation of a software product necessary for recording working time.

Creating a low-cost alternative to currently existing expensive programs.

Creating an intuitive program with a convenient and universal Windows.