Pre-project surveys in the development of an information system

What happens without a pre-project survey?

In due time, I had to develop and sell systems for drawing up transport routes: points with orders are displayed on the map, you circle them with the mouse and place them in cars. One company is asking us to sell the application. Not one month, we tried to find out why they need such a system, as a result, they sold the "box", they asked for it. Then this company decided to attract us for implementation. And then it turned out that first of all they needed functionality for fuel accounting, which in our system was completely absent from the word.

And sometimes you join the project during the development of the system, study the project documentation and the already developed functionality. And at some point an awareness comes: there is an interface, the program does something, but to answer why it is developed, what business problems it solves, what indicators should be achieved, none of the project team is capable of. Is it possible in this way to create a system that meets the requirements of the customer?
In other words, even before drawing up the Technical Assignment, it is usually necessary to conduct a small (this is how) research and answer a number of questions.

Key questions answered by the survey

As they say, you need to understand WHAT, WHERE, WHEN. Namely:

What is the purpose of development, what benefits will the customer.
What is the proposed business scheme, a process that will be automated with the help of the system being created.
What are the main user functions of the system.

Why do I need to write, why is it not enough to discuss and speak?

Drawing up a document allows you to formulate the idea at a completely different qualitative level than with oral discussion. Many details remain uncovered in the conversation, some of the information is forgotten and later overlooked. And paper keeps all thoughts.

Yes, the preparation of documents is a painstaking and sometimes unpleasant business, but it is worth it. Thought is valuable only when it is formed, and it is formed when it is formulated on paper.

What should a pre-project survey contain?

Usually, a pre-project survey means the study of business processes of an enterprise. Many articles and books have been written about it. But unfortunately, a simple presentation of the processes is not enough.

The result of the study may be a whole package of documents ( some of them are given at the end of the article ). The central (and, unfortunately, often the only) document I usually have is the System Concept document. We will discuss this document in this article.

Developing my own structure of the Concept, I took as a basis the report prepared in accordance with GOST 34 at the stage “Formation of Requirements for the AU” (see RD 50-34.698-90 “Guidelines. Information technology. A set of standards and guidance documents for automated systems. Automated systems. Requirements for the content of documents "). But at the same time made their additions.

The “system concept” can contain 2, and sometimes 30 pages. It all depends on the formulation of the problem. The “concept”, as a rule, is coordinated with the top management of the customer, and only on the basis of this can the Technical Assignment be developed .

The purpose of the creation (modernization) of the system

By purpose of creation, I mean business goals. “Automate” is not a goal. Adding a function is also not a goal. And “optimizing” is not the goal. For example, an employee sits and he can sleep a couple of hours a day right at the workplace (a real case, by the way). And someone asks to automate his activities. What for? So he slept for four hours?

For several years of analyzing dozens of projects, only five possible targets for creating (modernizing) a system have been identified:

A new business is being organized (for example, an online ordering system). It is clear that if the business is planned to be carried out via the Internet, one cannot do without development.
Reduced operating costs. This is a classic case when, as a result of automation, personnel is reduced or it is possible with the help of better planning to do more with less.
Improving the quality of internal processes. Also a classic case. For example, if, when looking for new clients, managers constantly forget to call someone, lose their lead information, then it makes sense to implement CRM.
Reducing risks with dependence on key employees (such as "golden nails"). It happens that because of the low level of automation and the complexity of the processes, a number of operations can be performed by 1-2 employees, the dismissal (or illness) of which can put an end to the whole business. And it will take more than one month to find and teach new ones.
Fulfillment of external requirements. For example, a new law has appeared, or there is a requirement of the counterparty that you must have electronic document management or control over the work of mobile employees.

It is clear that the goal is desirable to make tangible. If we want to reduce costs, how much and at the expense of what. If we organize a new business, then we need to understand at least an approximate amount of operations and the number of operators. If we improve the quality of processes, we should outline a range of problems and propose a solution.

System idea

In case the “Concept” document turns out to be quite voluminous, it makes sense at first to briefly outline the very essence of the system, its idea. For example, you want to create a specialized social network (go to museums and share your impressions). I would first describe the need for communication between visitors, and then briefly the essence: a mobile application is being developed in which the user can write his impressions of an exhibit.

Comparing old and new

The most effective way to understand the essence of the system being created is to go from the opposite.

For this you need:

briefly describe existing processes;
point out their shortcomings;
propose a new scheme that eliminates the described disadvantages.

The purpose of this section is to justify the need to introduce a new scheme. A detailed description of business processes is better to make a separate document. Here we concentrate on drawbacks and suggestions.

What are we going to earn?

If you are developing an application with the help of which you plan to earn money, then you should definitely determine the methods of earning: advertising, paid subscription, paid services, interest charged, etc. The selected method (or methods) can greatly affect the functionality being developed.

Interest of the parties

If the functioning of the created system requires the participation of other organizations, then it is necessary to decide how to involve them and interest them. In other words, we first build the entire business chain, then everything else.

Description of automated processes

The purpose of this section is to give a general but complete picture of the process. For example, you are developing an online store. Obviously, you need a catalog, a basket, integration with an acquiring bank and delivery. But the questions of return, refusal upon delivery, failure of the supplier, unexpected lack of goods in stock may slip away from your attention. It is better to think over all possible options in advance and decide what will be automated from this, and which cases occur so rarely that it is better to “rake” them in manual mode.

For the description it is not necessary to give the scheme. In the general case, a plain text script reveals the essence of actions much more completely.

Legal support

Often, after creating a system, it turns out that in using people or organizations violate the law. Therefore, it is first necessary to find a legally pure scheme, and then develop technical solutions.

List of functions

The “Concept” document is not a Terms of Reference ; therefore, business functions are described, the top level. There is no point at this stage to talk about authorization and work with the user profile. But it is necessary to give a general idea of functionality.

Safety requirements

If you are developing a financial system or a system that contains strictly confidential data, then you must provide a list of security standards. For example, the requirements for encrypting stored or transmitted data. Do not forget about all the tightening requirements for the processing and storage of personal data.

Selection of options for implementing the system

Sometimes, depending on the needs, it is necessary to determine the type of application (web application, native), platform (Windows, Linux), general architecture (one server or several clusters), whether to take a typical system and refine it or conduct development from scratch. To do this, compare the proposed options and select the most appropriate.

Conclusion

In the article we ran very quickly through the main sections of the pre-project survey. Why fluently? Because such a survey is an extremely creative exercise. The main thing is that when reading the concept there should be a complete understanding of how this should work. And the rest of the two documents with the results of the study may not be similar to each other. Accordingly, the list of sections in your document can be very different from the one above.

Read other articles by the author:

Tags: