Get best of the week

Cheat sheet analytics: how to "dig out" a system

At the Analyst Conference of Analyst days # 10, the architect gave a presentation on how to unearth the legacy system without documentation or if there is conflicting documentation (“4 rules of an archaeologist: how to“ unearth ”the system, Evgeny Aslamov). Great report.

When an analyst comes to a new company for a more or less formed product or even a legacy system (in this case I don’t even know if the analyst was lucky or not), he is also often forced to collect a description of the functionality like jigsaw puzzles (in the companies where I worked and where the interview was described the product was when? Almost never. Maybe I was unlucky, but maybe vice versa).



I had to do it. Somewhere intuitively there was an understanding of whom to ask about. Sometimes someone from the project team suggested. It was even so that you learn about some kind of trigger in your functionality after an incident from the support department. Something cleared up as part of the functionality upgrade. Well, the most top-notch is self-testing and using the product.

Having looked at all this, I had the idea to write a kind of cheat sheet for analysts, which way to drip from.

Only it will not be 4 rules as in the report of the architect, but 4 steps:

Step number one. Collect all the documentation for the implemented solution.


1. Ideally, if it contains for each functional block:

  • a description of the need for this functionality in any tool (just text, labels, some schemes in any notation);
  • front description: element behavior, user wf;
  • description of the back: internal services, description of the database and components;
  • Description of integration services, including examples of requests and responses, statuses of responses.

2. All regulatory and regulatory documentation that defines the boundaries of products: Federal Law, regulations, orders, projects.

3. TK / TP / specifications (underline the necessary) - a document in which the requirements for functionality were described.

4. Recorded agreements in which you can trace any unfulfilled wishes.

5. User manual / instructions in case there is no description of the need in order to understand how the user should work with the system.

Step number two. Testing


Regardless of whether or not the above documents exist, the next step should be to test the product.

Just sit down and start poking everywhere and watch how the system reacts. At the same time, you record behavior, and note dubious moments for clarification among holders of secret knowledge.

Step number three. Questions


You find out from the head (line, project manager, lead, etc. - underline what is necessary) who can advise on issues. You are preparing an invoice of questions. Ask, outline the answer. You go to let it all go through you.

Step number four. Get what you got


You process the information received in the prescribed manner in your company. This can be updating documents, or creating a knowledge base in confluence, maybe even updating parent tickets in the task tracker - in general, a convenient place for you.

In a good way, the next steps should be: go work


But what I really want to say at the end of the article: the task of the analyst is to leave structured information behind.

Leave - this means to issue and put in a public place. And do not figure it out, like a schoolboy with new knowledge, and leave them with you.

Structured information - this means putting on the shelves everything that was bad for you.

Do not be afraid and go for it!

More articles:


All Articles