Becoming an analyst

I want to devote this article to the sometimes difficult but fascinating profession of an IT analyst. On Habré there are not so many materials on this discipline. For example, project management - an order of magnitude more. But the recently published two articles ( one and two times ) seem to have aroused interest, therefore, I would also like to make my modest contribution. I myself have been working for more than 8 years as an analyst, so I will try not to waste your time.
I will not retell the theory (it can be found in the wonderful book of Wigs or in BABOK). I would like to focus on the practical side of the issue - to describe the squeeze of "combat" experience, both of my own and of some other people with whom I was fortunate enough to work.

Immediately structured further narration:

1. Short introduction
2. Analysts - who is it? + technical retreat
3. Why do we need analysts? (hello cap)
4. Who and how to become an analyst?
5. What should an analyst know and be able to learn and how?
6. Conclusion

Some of these topics look obvious. I will try to captain to a minimum.

Note from the future:
Having added to clause 5, I realized that in the volume planned at the beginning, the material turns out to be too large. The fifth paragraph deserves a separate article, or even a few. This is a matter of the future. In this post I will touch on this topic only superficially.
')

Short introduction

There are enough dry formal definitions and other similar materials on system and business analysis on the Internet, so I will not repeat it. Also in no case am I going to retell the content of the book “The Way of the Analyst. Practical guide IT-specialist.
Recently, the area of ​​knowledge has been given very modest attention. This is expressed in a variety of things. For example, there is still no de facto standard for the profession “System Analyst”. Of course, there is the International Institute for Business Analysis (International Institute of Business Analysis, IIBA) with its BABOK and its own certification system. But they are not widely used (for example, PMI / PMBook in the discipline of project management), especially in Russia.
By the way, the Russian branch IIBA is currently being created. I will not advertise, but anyone can easily find the appropriate group on LinkedIn.

Also, the number of books on IT analytics is noticeably less than on other IT disciplines (I will be happy to make a mistake on this issue - perhaps some important books in this area have passed me by). Even on Habré, articles directly on analytics for the last couple of years can be counted almost on the fingers of one hand ( 1 , 2 , 3 , 4 ). Well, we have what we have. In the end, everything is in our hands.

Analysts - who is it?

By and large, in the field of IT, two types of their specialization can be distinguished:

• System analysts
• Business Intelligence (this role does not only apply to IT).

Despite the fact that the tasks to be solved and the required skills of them differ significantly, on IT projects in most cases both of these roles are united by one employee (or a group of employees). Separation is sometimes found (for example, usually on projects for financial organizations), but such cases are in the minority.
Formal definitions easily googling, but in essence:

• The main tasks of the system analyst: the collection, analysis, formalization and harmonization of system requirements. In other words, requirements management throughout their life cycle. The main, though usually not the only, output document is a technical assignment or its equivalent. Let us dwell on this below.
• The main tasks of a business analyst are the study, description, analysis and (if necessary) reengineering of business processes. The main output document is a description of the business processes As Is (required) and To Be (if necessary).

The first must necessarily have a good IT background. For the second, though it is desirable, but not mandatory. Often, business analysts are people with an economic education. The first one should be fluent in the same language with developers and business users; for the second, only business users are sufficient.
In other words, you can get a business analyst on a large project, not really understanding the intricacies of IT (I saw this in one of the largest Russian retailers), but it is almost impossible to get a system analyst, being unable to communicate with end customers (whether due to lack of communicability or unwillingness to understand the client’s business).

Brief technical retreat

Let's deliberately interrupt the story and dwell on the requirements themselves. As for the types, attributes, characteristics, approaches to the collection and execution of requirements - perhaps more “mess” is difficult to find. The composition and content of the documents with the requirements vary significantly (take, for example, our GOST and RUP, and IMHO is not a comparison of a gun and a slingshot). The set of requirements attributes is also given in each approach, often quite ambiguous (for example, in BABOK). To top it off, the results of the analysis and design stages are often confused, forcing the implementers to include in the analytical documents the final form of the class diagram and the complete database schema (see below).
Without pretending to ultimate truth or some kind of know-how (approximately the same is written in Wikipedia), we formulate two key ways to classify requirements.

By level:
Business requirements
Top-level requirements that define software creation goals. Examples of such requirements may be the achievement of a 20% reduction in costs or an improvement in the quality of management (for example, due to the possibility of prompt reporting).
These requirements are usually described in a separate document - “Vision of the Project” (Vision) or “Business Requirements”, which also includes defining the main roles of future users of the System and listing its main use cases. If there is no such highlighted document, then all this is often included in the technical task or its equivalent.

User requirements
They define a set of user tasks that the System should solve, with a description of the scenarios for solving these problems. User requirements are usually presented as an enumeration of the use cases of the System and interrelations between them (as a rule, in the form of a Use-case diagram of the UML language).
The use cases themselves are described as part of their sequence of actions with all possible pre / postconditions and branchings. Often the description is textual (this topic is well described in Alistair Coburn’s book Modern Methods for Describing Functional System Requirements).

Functional requirements
Describe in detail all the functional elements that must be directly implemented in the System in order to ensure that all the use cases described in User Requirements can be performed.
Functional requirements are the most detailed. They describe, among other things, input / output data and their verification, data processing algorithms and user interface elements (without design).
As a rule, these requirements are drawn up in the form of a separate document (“Terms of Reference”, etc.). The same document details the use cases of the System (User Requirements), which are usually associated with functional requirements.
An example of a functional requirement: “By clicking on the button <Button A> on the form <Form B> , a modal dialog box containing <Window content> ” should be displayed.

Type:
Functional requirements
Describe directly the functional implemented by the System (an example is given above in the description of the classification of requirements for their level in the item “Functional requirements”);

Non-functional requirements
Describe the characteristics of the system and its environment, as well as the restrictions imposed.
Examples of non-functional requirements include restrictions on the hardware platforms and operating systems supported by the System being developed, as well as requirements for performance, security, etc.

Note:
As can be seen from the description above, functional requirements are a category of requirements both in their level and in their type. Unfortunately, at the moment such an ambiguous terminology has emerged (from the experience of many projects and several employers). If you have other approaches, please share.

I will not describe the characteristics (consistency, completeness, etc.) of quality requirements and all their attributes (status, source, etc.) here so as not to inflate the post. If this topic is interesting, I will gladly cover it in a separate article, although all of this is easily googled. For the same reason I will not describe here the statuses / versions / cuts (baseline) requirements.
However, I would like to dwell on some basic principles of working with requirements (this list is far from complete):

The sequence of works and their results
The results of the analysis and design stages should be clearly distinguished. At the stage of analysis, the requirements for the System are formed.
All details of the implementation of the System are determined at the next stage - the design stage. Thus, if necessary, include in the "Technical Assignment" the database model of the System or class diagrams you need to understand that in this case:

1. There will be a mixing in the same document of the results of different types of work performed by different people (analyst and architect);
2. The deadline for the specification will be increased, because to complete it, you will need some results from the design phase.
   The results of the design phase are more efficiently documented in a separate document describing the system architecture.

However, some deviations, such as the inclusion in the "Technical Assignment" of the designed interface layouts (without design / decoration), are permissible, because performed by the same people who develop the technical task itself.

The procedure for collecting the requirements themselves:

1. First, the objectives of creating a System (business requirements) are identified. It may seem that fixing these requirements is not mandatory for development. But in this case, the Contractor will not be able to control the compliance of the developed System with the goals for which it was created, as well as the ability to establish semantic dependencies between the goals of developing the system and the scenarios for its use;
2. Further, the roles of the System users (both people and other software systems) are determined. After that, scenarios of using the System for each of these roles are identified and described. This is how user requirements are formed.
3. Further, the full set of requirements for the System functionality is developed in such a way that this functionality allows to fulfill all the scenarios described in User Requirements. The restrictions for the System and the parameters of the environment of its operation are also fixed.

No duplication in requirements
The key to managing requirements is the lack of duplication, i.e. each requirement should be recorded only in one document and only in one place of this document. Deviation from this principle will lead to a serious increase in labor costs for supporting these documents, and to the inevitable violation of their integrity (since it is difficult for a software system to take into account all the nuances of all new requirements in parallel in all documents is a complex and resource-intensive task).
If necessary, instead of duplicating the descriptions of the requirements, you should use a link to the original of this description. This will allow both to take into account the interrelationships between requirements, and to avoid the problems described above.

Change management
When developing modern software systems, it is often required to make changes to the requirements already at the end of the analysis stage. Here it is important that the parties understand and accept the following principles:

• The Contractor understands that the requirements can not always be formulated by the Customer fully and correctly in the initial stages of the project. Accordingly, changes in requirements during the course of the project are allowed.
• The customer understands that changing the requirements entails an increase in labor costs and product delivery dates.

Availability of information resources, stakeholders, subject matter experts and technical specialists
To form a complete and accurate list of requirements for the System, the Contractor’s specialists should have sufficient access to:

• to all related to software development materials;
• to all key information carriers and persons with the required authority

In the second case we mean:

1. interested people
2. subject matter experts
3. persons involved in the approval and approval of requirements
4. technical specialists from the customer or other contractors / subcontractors.

On this, perhaps, we finish this small digression. The language of the story turned out to be dry, I repent. But the topic is quite formalized.

Why do we need analysts? (hello cap)

Until now, from some developers (although now very rarely) one can hear that analysts (as well as project managers, product managers, etc.) not only do not make a useful contribution to the business, but simply “interfere under their feet” . They climb, you understand, with their processes, pieces of paper and other bureaucracy - they do not allow a simple developer to work quietly (smile).
Excessive bureaucratization is certainly evil, but it is unrealistic to implement a large project “on the knee”, and even the efforts of specialists of only one profile in the modern world. No one disputes the important role of developers, but will they sell, draw up a bunch of related documentation, try to understand the peculiar language of customers, etc.? Let me suggest that it is unlikely that many of them will be interested.

By the way, if all the above-named comrades (analysts, managers, etc.) were ordinary parasites, they would not have hired tough competition in our world in such quantities and would not pay them such money. I will only make a reservation that we are talking about Enterprise-projects. Create a successful mobile application and make clear money on it now (for now?) Under the power of one person.
Returning, in fact, to the role of analysts. In order not to spread the idea of ​​the tree, just list the main points with which they have to deal in real projects:

• Listen to the customer. Sometimes it is already difficult - some are able to talk for hours about anything, and it is not always easy to translate communication into a constructive one. Here the key is the skill of active listening.
• Sometimes understand the customer’s bird language and formulate its requirements in clear language, fully and without contradiction. Those. to turn the stream of consciousness of the client into a set of formalized requirements.
• In some cases, when the customer “does not know what he wants”, propose the optimal solution or “bring” the customer to him;
• Analyze the impact of new requirements on the existing architecture and functionality. Here the advice of an architect will often be helpful.
• Document requirements in the form of a document or set of documents in the required form. Then coordinate them and approve.
• Create tickets in the system of tax-tracking and in the future to track their difficult fate. Can lead and architect or dev. lead on TK, but more often it makes the analyst.
• To carry out a high-level control over the compliance of the implemented functionality with the requirements.
• Manage requirements changes.
• To carry out all interaction with customers on the requirements.
• Often - to participate in the delivery of the product to the customer.

Also, analysts often “plow” to tasks that are not entirely relevant for them, such as participating in testing, implementing and developing user documentation. Fighting it or coming to terms is, by and large, a personal matter for everyone. Participation in presails is also more interesting, although it is also not quite a profile activity. By the way, often this activity is very exciting and developing (although extremely time consuming).

Who and how becomes an analyst (on labor)?

There are not so many business analysts involved in IT projects. In most cases, their tasks are performed by system analysts. And I admit, I have no representative sample to judge where they come from.
As for system analysts, simply by experience: it’s usually impossible to become an “immediately” analyst (without previous experience in the IT field). At least for the whole time of my work I have not managed to meet a single such person. Apparently this is due to the fact that both the requirements for the candidate and the responsibility are initially high.

In practice, successful testers and, sometimes, technical writers often become analysts. Also, developers often become analysts: someone because he understood that development is not his, someone really wants to be an analyst, for someone it is just a shorter way to PM.
Only once met an analyst who grew up from a system administrator. Here I will not undertake to draw conclusions - again, too small a sample. I also know one PM, who has passed into analytics, but this is more likely an exception.

What should an analyst know / be able to learn and how?

Those who read the above mentioned book “The Path of the Analyst. The practical guidance of an IT specialist, ”especially those colleagues who are just starting their careers in IT, must have been somewhat surprised by the amount of knowledge and skills that the author suggests to master the unfortunate reader. In short, following this book, the analyst must master all the experience accumulated by mankind in this field with all the methodologies, techniques and tools, and at the same time, to the maximum extent, possess all the positive personal qualities inherent to human beings.

In my humble opinion, a certain spherical analyst in a vacuum is described there as an ideal to which one can (but not the fact that one should) strive. A fanatical desire to master all the knowledge and skills at once will, perhaps, in Kashchenko. I bet for a bottle of Talisker 16 yo, (with someone one, and the same, uneven hour, there are Sheldons (smile)) that there is no one in nature who fully corresponds to the image promoted in the book (with all the described set of knowledge and skills), including the author of the book.
I don’t say that the skills offered there are not important, I just need to be able to prioritize. By the way, for the analyst is a key quality. And, whatever I wrote here, this book is definitely worth reading.

However, as I mentioned in the introduction, the knowledge and skills of the analyst and the ways of acquiring them are a very big topic. And in order not to inflate this post, I will not try to highlight it here in detail.
And if in a nutshell, then of course you should have an idea:

• about software life cycle;
• about several key development methodologies (waterfall, RUP, something from Agile, it would be better for Scrum, for state customers - GOST 19 (for programs) and 34 (for automated systems));
• about the basics of system analysis (Vighers is perfect);
• about notations and design and modeling tools (perhaps the most popular on the market: Sparx Enterprise Architect and Rational Rose; and UML / Aris / IDEF0 and IDEF3);
• about the theory of relational databases;
• etc.

I don’t even write about the need to master Word or its equivalent (smile). But the need to own at least one tool for designing interface layouts is worth mentioning. Dedicated interface designers are rare, so this work often falls on analysts. Here, in addition to the obvious Visio, I can advise a simple and convenient Evolus Pencil.
Plus, some personal qualities, such as responsibility, interpersonal skills and attention to detail, are really worth “pumping”. For this there are special techniques.

Conclusion

Dear colleagues, I will be sincerely happy if this post was useful. I am ready to discuss any questions that may arise, or to highlight in more detail, as far as I can, the topics of interest. If you disagree with something, please write. Let's learn. And long live Lifelong learning!