How to develop a technical task. Part 2. Types of work in the collection of requirements for the system of accounting and information for describing business processes

The first part of the article “Development of technical specifications“ What is it, why is it necessary, where to start and how should it look like? ” Caused a lot of interest. In addition to my mailing list, I published it on the well-known Infostart website , where it caused even more interest, which is good news. As promised, I am writing a sequel.

Having thought well, I decided that it would not work again to put all the material of the planned second part into one article, otherwise it would be tops and in theory that it is written in many textbooks anyway. But after all, I set the task so that it can be put into practice, so I will no longer think about the future about how many issues it will take to finish the topic. Feedback from readers will also influence this, so please do not hesitate to write!

Taking this opportunity, I want to ask the question: how interesting would the organization of a practical training seminar in St. Petersburg be on the development of the Technical Assignment? They would have met, exchanged experiences. If such interest is not single, I promise to organize.

Since readers are not only software development specialists, but also business analysts and executives at various levels, I will try to write in such a way that everyone is interested.
')
In this part we will talk about how to organize the stage of work on the collection of requirements, what it should consist of and what tools you can use. I repeat that from the point of view of stages, these works are very similar to a survey of an enterprise with a view to describing business processes.

As usually happens in life:

As it happens in most projects
Steps	How does this happen
The decision is made, the project will be!	It is clear that there is a reason for joy, especially if the project is large, there is nothing wrong with that! The main thing is not to rejoice too long, delaying the beginning of the actual work, from this moment time will go differently.
We held a meeting with the leaders, collected some information about their vision of the result.	Usually this process is limited to several meetings with management, then with heads of departments. Having fixed certain “desires” on the part of the Customer, they are recorded in the form of general formulations. Sometimes existing documentation is added to this (someone once tried to conduct a survey, documents on existing regulations, forms of reports used) Surprisingly, after that most of the implementers of automation systems happily exclaim: “yes, we have all this in our system! Well, a little tune up and everything will work. " To the question whether it is necessary to discuss how everything should work (or how a particular process is performed) with end users, the answer is usually negative. The opinion is expressed that the head knows everything for his subordinates. And in vain ... Behind this lies many traps and obstacles, and the surrender of work can turn into a marathon along an obstacle course. As is known, the marathon is usually run on a flat road, and running with obstacles is possible only at short distances (you can not reach it).
Documenting work results	After that, the documentation of the results starts, depending on the goals of the work: If you need to develop a Terms of Reference , the consultant starts cracking the received information on the prepared document template so that it looks nice and the main requirements are fixed (those that were announced by the management, otherwise they may not approve). Realizing that in practice such a Terms of Reference is not specifically used and you have to figure everything out “along the way,” he sets the minimum goal of the Terms of Reference for the minimum time for approval and approval. And, if possible, information for an approximate assessment of the value of future work (by the way, it is also important). If you want to describe the business processes. Strangely enough, but often all previous actions look similar, as is the case with the development of the Terms of Reference. The only difference is in the design documentation. There are possible options: consultants describe the process in arbitrary words or use any rules for describing business processes (notations). In the first case, such a document turns out to be surprisingly similar to the Technical Assignment. It even happens that if you replace the title page, you will not see any difference. In the latter case, they often focus not on the correspondence to reality, but on the “correctness of the description”, i.e. formally follow the rules of description. Unfortunately, both options are not the best practice, because rather, they are a formality, and there are not many benefits.

Why did the practice as described above take shape? Frankly, I do not know. Who does not ask, no one knows. At the same time, the situation is not changing very quickly, although they constantly discuss this topic, exchange experiences, write books ... It seems to me that one of the reasons is the low quality of the corresponding education. Maybe the fact that a lot of specialists come at all from their other business can still have an effect, and they comprehend everything in practice, i.e. their experience is shaped in the environment where they are located. The attitude of universities and the absence of their desire to be closer to reality is also a fact known, but their position sometimes surprises me. For example, I had a case when a graduate student, a talented specialist, wanted to write a thesis on the 1C platform (good industry development), but at the department she was told that, regardless of the topic, it would be impossible to count on “excellent” because 1C frivolous system. Here it is not a matter of the seriousness and objectivity of such an opinion, but of the fact that the primitive task in the classical programming language was immediately considered worthy of the “excellent” mark.

Let's try to give the above process a more systematic approach. How can he look like then?



As we see, the process ends with a question, since this work is far from complete, and then the most difficult and practical will begin - exactly what will determine the applicability of the result obtained in real life. Exactly what will determine the fate of the previous work: either it will go to the closet (on the shelf or somewhere else), or it will be a valuable source of information. And even better if it becomes a model for future projects.

I would like to especially note that until the last step on the diagram (where the question is) the general principle of collecting information on the company's activities looks the same, regardless of what is planned to be done in the future, describe business processes or implement an automated system. Yes, the sequence of steps is the same, but the tools used on some of them may differ. We will definitely consider this moment when we study the techniques and tools of individual stages. We will do this in detail in separate articles, and now we will consider only the most important thing. Further steps will be different and will be determined by what is required of the project: describe the business processes or implement the accounting system.

Let's look at how you can reorganize the approach to collecting information about the activities of the company.

How can this happen with more competent work organization?
Steps	How does this happen
The decision is made, the project will be!	Here, nothing changes with respect to the first option, no one has canceled emotions.
We held a meeting with the leaders, collected some information about their vision of the result.	This step also remains, and it is of great importance. But the main purpose of the first meeting (or several meetings) with managers and owners is an acquaintance. Acquaintance first of all with people and the company. The formulated goals and wishes at such general meetings may themselves be different, including fantastic ones. All of them will, of course, be heard, but not the fact that they will be implemented. With a deeper immersion in the company's business, other goals will appear as well as previous ones will be rejected. I mean that it is impossible to formulate clear goals from preliminary meetings, all this will require careful study. At such meetings, it is necessary to take notes of all the messages from owners and top officials so that you can come back to them and discuss when enough information is collected. Even a simple at first glance, the requirement may be unrealizable or very time consuming.
Formation of a working group from the Customer and the Contractor, the distribution of roles	It is necessary to decide who will work on the project from both the Customer’s side and the Contractor’s side. Despite the seeming simplicity of this stage, it has a very large role. If you do not clearly state who is responsible for what, you run the risk of confusion during the implementation of work. If for your part you can always specify the roles in your team, then the Customer may have problems with this. What should be paid attention to: those who will in the future at least somehow influence the acceptance of the result should be included in the composition of the Customer’s working group. If we allow the situation that the employees of the Customer who did not take part in the work on setting goals and identifying requirements, will be connected to the delivery of works, then the problems are guaranteed. Even such an absurd situation is possible, that everything, it turns out, was not done as required. In my practice, I encountered such a situation more than once. Therefore, you can protect yourself if you negotiate and document it, that no one except the Customer’s working group may participate in the acceptance of works . And best of all, to prescribe this in the contractual terms (in the contract or the project charter). I remember there was such a case: the founder decided to join the process in one large project (I don’t know why, it became boring to see) and attended one of the working meetings where the issue of forming accounts for clients was discussed. He was surprised to find out for himself that the sales manager billed the client. In his presentation, an accountant should issue an account, and nothing else. But in fact, the accountant had no idea what was going on, and the manager could not imagine how to work like that, if you run to an accountant for each account. As a result, lost a lot of time, but nothing has changed, the account was still billed by the manager. And the founder remained at his own opinion, but did not interfere in the process anymore. At this stage, it is advisable to develop a project charter in which to fix the roles of the participants, the communication procedure, the rules and composition of the reporting, as well as everything else that should be prescribed in the Charter. Development of the Charter of the project is again a separate topic.
Training the project team in work methods and tools, coordination of work rules, types and composition of documentation	First, it is necessary to clarify to the project team everything that is stated in the Charter, how this will be applied in practice. Secondly, the project team of the Customer must be trained in the methods of work that you intend to use at all subsequent stages. It makes sense to discuss the formats of documents to be used, to consider samples. If any rules for describing models or business processes are applied, these rules should also be discussed so that they are clear.
Questioning	The survey stage allows a relatively quick way to get a fairly reliable cut of information about the company. The quality of such information will be determined by three factors: First of all, how you trained the Customer’s design team. They must clearly understand how the survey process takes place and be able to convey information to all participants. The form of the questionnaire itself. Questionnaires should be understandable. It is desirable that there was an instruction for filling out forms. Even better, if there is an example of filling. List of participants. It is necessary to choose the right composition of participants. If we confine ourselves only to managers, it will not be possible to collect reliable information. I recommend including in the questionnaire all those who will be in the future user of the final results. For example, if we are talking about the implementation of an automated system, then it is worthwhile to include everyone who will be a user. There are cases when out of 10 employees of one position there is one that performs some special function, about which none of the remaining 9 knows any more (for example, it prepares a special report for the management). If we are talking about further redistribution of duties or the development of job descriptions, you should do the same. I draw your attention to the fact that the methodology of the survey for the subsequent implementation of an automated system or a description of business processes in the right case is different. Of course, the structure of the questionnaires may be the same, but this is not the best option. When we describe business processes, questionnaires are usually more general in nature, because It is not known exactly what will be faced. If we are talking about the implementation of a specific automated system, it is better to have questionnaires that take into account the peculiarities of this system. With this approach, you can immediately identify all the bottlenecks of the system that are not suitable for the enterprise. As a rule, methodologies for introducing ready-made systems provide for the availability of such forms. Such questionnaires can be developed either for individual areas of accounting (for example, accounting of orders, sales, pricing), or for specific positions (financial director, for example). The composition of the questions is about the same.
Polls	A survey is an oral interview with specialists in order to ascertain the features of individual processes. It is necessary to organize a survey so that it does not look like just "met-talked", but more organized. For this it is necessary to prepare a so-called survey plan. It is possible to include those parts of the questionnaire that cause you questions, contradict the information of other questionnaires or the information is presented superficially. It is advisable to add questions and just from personal experience. Answers should be outlined without fail. Ideal if you agree on audio recording. At the same stage, it is necessary to track the completeness of the information provided on document circulation (both forms of primary documents and various reports)
Highlight key business processes or automation areas	After the survey and the survey, we can reasonably assume that there is enough information to draw conclusions about the identification of key business processes. In fact, it is already possible to single out not only key business processes, but practically everything (if the list of participants was chosen correctly). The issue of separating business processes is a completely separate and not simple topic. It is difficult to learn here and is developed mainly by experience. From the selected business processes should make a list (classifier). Then it will be possible to make decisions which of them should be investigated more deeply, which are not, as well as highlight priorities.
Formulation of key system requirements, goals, criteria for project success, processes for detailed study	To this stage all primary information about the company's activity should be collected, a list of business processes should be compiled. Now it's time to return to the goals, specify them, if necessary, discuss with the top officials of the company. When formulating goals, specific indicators should be taken into account, upon which we will consider the project a success. If we are talking about the implementation of an automated system, then a separate list can distinguish system requirements from key users. I do this in the form of a separate table, where all requirements are grouped by subsystems, for each requirement the author of the requirement, the wording and priority are indicated. This information can be used to plan the deployment of the system (the sequence of implementation of individual subsystems), as well as for proposals for the further development of the system (if separate subsystems are not planned to be introduced in the current project). If it is necessary to describe business processes, decisions are made on those processes that need to be explored in more detail.

So we got to the question "What's next?". Next, we will consider the tasks of describing business processes and developing the Terms of Reference separately. I do not accidentally consider these tasks in parallel. There is really a lot in common between them, which I want to demonstrate. First, consider the sequence of work in the description of business processes.

Steps	What and how to do
Select the business process	From the general list of business processes obtained at the previous stages, we single out one (by priority) for detailed study. With the rest then do the same.
Detailed study of the business process	Dedicated business process is subjected to a detailed study: we analyze the received primary documents, reports and their structure, used in the program process, various files (for example, Excel), talk to the final implementers. We collect various ideas on how to improve the process. It is very useful if you can observe the process in exactly the conditions in which it is performed (not many people like to be watched, but what to do)
Graphic and / or text description of the business process (primary)	We begin to describe the obtained detailed information. Before describing the process, it is necessary to decide whether it will require a graphic description. If the process is simple and clear, there are few functions in it, and the graphical representation does not improve his understanding or perception, then do not waste time on it. In this case, it is sufficient to describe it in text form in tabular form. If the process is complex, with different logical conditions, then it is better to give its graphical scheme. Charts are always perceived easier. If you decide to describe the process in graphical form, this does not mean at all that it is not necessary to give its text description. Those. textual description of the process should be in any case, and made according to the same scheme. It is convenient to do this in the form of a table in which to indicate: the performers of each step, what information they receive at the entrance, a description of each step, what information they form at the output. Below we take a look at an example of how this might look.
Coordination with the executives and the owner of the business process	The best way to understand how well you chose the style of presentation of information is to show the result to the users (executors) of the process. The most important thing in such a demonstration is an understanding of how correctly you understand how the process is performed. from the performers is quite adequate feedback. And if it becomes interesting to them, then everything will move much faster. Identified clarifications and inconsistencies must be reflected in the description (updated), if necessary, repeat the operation.
Selection of business process indicators	After the correct understanding of how the business process is performed, it is necessary to think about indicators that can measure the quality or speed of the process. It is not easy, but necessary. The indicator should be measurable, i.e. expressed in numerical terms and there must be an easy way to get this value. If the measured indicator cannot be distinguished, there is a risk that the business process is unsuccessful. In addition, it will not be possible to understand (it’s impossible to measure) whether the changes in the process will lead to its improvement or not.
Final documentation of the business process	Once we have verified that the process is being carried out (or should be), we can include it in the documentation.
Further actions (or lack thereof), depending on the objectives of the project	Further options are possible: the considered processes will be analyzed and optimized, job descriptions will be developed, decisions will be made about the need to automate individual processes, etc. This could be a separate project: a description of business processes.

Now let's look at how the approach to the study of requirements for an information system will look like with their further reflection in the Terms of Reference.

Steps	What and how to do
Select the business requirement / scope of automation	Allocating an entire field of automation as a requirement (for example, “Inventories”) is used in practice; however, this is not the most effective way of detailing requirements. The field of automation is a group of requirements, and it is better to consider them individually. For example, "Accounting for the receipt of material at the warehouse"
Detailed study of business requirements	Detailed study of a business requirement is understood as how the end user wants to see it and will use it (of course, in accordance with the objectives of the project). In software engineering, this is often referred to as the “use case”. Thus, a detailed study of the business requirements is reduced to the elaboration of use cases. An example of such a variant is given in Appendix 2 to the article. In the simplest cases, it is not at all necessary to draw use cases in the form of graphical diagrams; you can also use textual wording. For example, the requirement “When entering a nomenclature the price should be calculated as the purchase price + 20%” it makes no sense to draw. In the form of a diagram, it makes sense to present the requirements combined to the field of automation, as shown in the example in Appendix 2.
Requirements modeling in the information system	Here it is! As you probably remember, I have already paid attention to this most important element in the methodology for developing Technical Assignments. “Build a model - you will get the result!” And what should be modeled? It is necessary to model the use cases obtained in the previous step. What should be the output of the simulation? There should be a demonstration program in which user data is entered, and it is desirable that he (the user) is familiar to the ear, taking into account industry specifics, actual problems. And not just made, but it should be clear where this data came from, how it was calculated. In this place the reader should have questions: And what if it is planned to develop a new system and simply have nothing to model? What if there is not enough functionality for the demonstration, and the system needs to be improved? Of course, you have to face this situation, and this is normal. What to do? If the system is completely new (as they say "from scratch"), then it will be necessary to simulate mostly on paper, then use case diagrams will help you a lot. It makes some sense to jot down some screen forms that are supposed to be developed (right in the environment in which the development will be carried out), since drawing them in some editor will be longer and this work is boring. If a ready-made system is implemented, and there is not enough functionality in it, then there is nothing terrible, the data are entered by hand, and the user is told that after the necessary improvements, this and that should be calculated (and he sees it). It is advisable to accompany such a model with a text description, even a brief one, so that the user can independently try to work with the model in his spare time. In the same description, you can formulate requirements for modifications.
Demonstration of the information model to the working group	We show the resulting model to the Customer and tell how everything should work. It is better to carry out a model demonstration by subsystems, i.e. by groups of requirements. If it turns out that the proposed scheme will not work for the client, you need to think about other use cases, make changes to the model and show it again. Only if there is confidence that the planned model for this client “will live”, can the model be considered successful.
Test development	Why do we need tests? How we were able to implement the requirements will need to be checked. Accordingly, it is advisable to do all key areas, complex algorithms, etc., tests. Including these tests can be used in the delivery of works. It is not necessary to do tests for each function of the system, there should be common sense everywhere. If we are talking about a ready-made system, then doing a test for “entering a new element into the customer's directory” will look silly and a waste of time and effort. But if this is a completely new system, it is quite possible. Why do tests, if there is no system yet? First, the developer will understand what they want to achieve from him. Secondly, we make life easier for the tester (someone will test the result of the development). In general, testing is a separate discipline, not very simple with a variety of techniques. In practice, as a rule, the simplest testing methods are still used.
Documentation of requirements in the form of technical specifications	The collected information at the previous stages will be exactly what should be included in the basis of the “Technical Assignment” document in the section with requirements. So all that remains is to get it right.
Further actions (or lack thereof), depending on the objectives of the project	The development process, the search for partners for the project, the tender, etc., may all start longer, it all depends on the situation.

Yes, the development of the Technical Assignment process is time consuming and therefore costly. But if it is made correctly, it saves the Customer from unfulfilled expectations. The contractor has to do what the customer needs and not to redo the same thing a hundred times. Anyway, gives the whole project transparency.

Appendix 1. Described business process in EPC notation.

Appendix 2. The use of the subsystem "Orders"