Pre-project survey 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 asks us to sell the application. Not one month, we tried to find out why they need such a system, as a result they sold them a “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 tasks 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, before drawing up the Terms of Reference , usually a small (like when) study should be carried out and a number of questions should be answered.

Key questions answered by the survey

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

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

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

The drafting of the document allows 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, drafting documents is a painstaking and sometimes unpleasant business, but it's worth it. A thought is valuable only when it is formed, and it is formed when it is formulated on paper.

What should a pre-project examination contain?

Usually, a pre-project survey means studying 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 he made his own 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 this basis 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 (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:

1. 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.
2. 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.
3. Improving the quality of internal processes. Also a classic case. For example, if when searching for new clients, managers constantly forget to call someone, lose their lead information, then it makes sense to implement CRM.
4. 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.
5. Fulfillment of external requirements. For example, a new law has appeared, or there is a requirement of the counterparty that you must have an 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 any 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 focus 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 here are questions of return, refusal upon delivery, failure of the supplier, unexpected lack of goods in stock, can elude 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 the creation of the system, it turns out that in using people or organizations violate the law. Therefore, we first need 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.

Security requirements

If you are developing a financial system or a system containing highly 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 or develop from scratch. To do this, it is necessary to compare the proposed options and select the most suitable one.

Other pre-project research documents

As we said above, the result of a good, serious pre-project study, conducted by a whole team for several weeks, is a whole package of documents. Here are some of them:

• The concept of the system (the document that we discussed in this article).
• Marketing research.
• Feasibility study.
• Project plan, including the calculation of labor intensity and resource plan.
• The plan of marketing activities.
• Project estimate.
• Plan return on investment.
• Preliminary staffing.
• System architecture
• The concept of security (in the case of a large description of the security measures can be put in a separate document.
• Presentations for the customer, potential investors and potential customers.

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:

• Development of technical specifications according to GOST 34 is easy and simple.
• Secrets of successful design of IP (information system) on the example of the construction of the hospital.
• Some notes on the design of information systems.