Conferences for professionals in the information technology industry

Леонова Наталья

Saint Petersburg


Тестировщик, перешедший на сторону бизнес-анализа. Люблю коммуникации во всех их проявлениях, новые предметные области и понятную документацию.


How long does the tech spec remain?


On the one hand, the Requirements Specification cannot die. The specification of requirements is a direct expression of the essence of a systematic approach and thinking. The more complex the system, the more accuracy and care required when making any changes. And the created systems do not become easier... 

On the other hand, the Facts are a stubborn thing - honest process/architectural work with a cascade of formed specifications, classic As-Is To-be transitions come across much less often, from start-ups unicorns are born, and certainly there weren't any specifications in them... 

We invite you to a discussion at the round table: 

  • Influence of two paradigms on Business and System Analysis: design and product. 
  • How to move from one paradigma to another with minimal personal and organizational losses.
Audience level
Round Table

Special requirements - describe and analyse them!


Requirements are the keystone for an analyst. It doesn`t matter in which domain the analyst works, what kind of project he (or she) conducts and what a software methodology is used  -  the analyst's primary task is to identify, analyse and describe the requirements. But the requirements can be different, and sometimes the analysts and the rest of the project team have to face a new level of complexity - "special" requirements, which are out of bounds of the standard IT world.

We will discuss a system and requirements for disabled users, their specifics, identification and description. What such requirements differ from "standard" requirements, what features of communication with the customer and the customer itself appear in this case and how these requirements affect the life cуcle of the application. We will check on the example of a real project how we can work with these requirements, analyse them and implement into the project.

Audience level
Lightning Talk (20 min)

Communication failures and their friends


Communication is probably one of the most important parts of the analysts work. Communication with customer during clarification of requirements, communication with developers and testers, and also a simple communication with colleagues  - all these things require certain communication skills. Every analyst knows that a clear and uncluttered written document needs a lot of time and effort spent on it. 

There are often difficulties in communication process  that make our live more complicated. And if misunderstandings can occur in case of communication with colleagues and clients, that speak one (native) language, how we can behave if a job includes communication in a foreign language, and sometimes no only one. 

We will discuss a number of terms and concepts that will help us to cope better with the difficulties in communication, as well as they will contribute us  to begin "to call a spade a spade". We will check on the example of the multicultural project that it really works.

Audience level
Lightning Talk (20 min)

How we specified a project with UML


Business analysts have to write documentation in the different conditions - it isn`t always clear what our customer wants. It could happen that requirements are written after the "magic" of development.

In the talk, we consider a project when analysts were integrated after development, and the main task was to find a convenient way of documentation that would be good for all project's members .

The situation is also complicated by an international team - part of the development and analysis were in St.Petersburg, and customers - in Germany. Things were not running well with normal specifications and documents became quickly obsolete, we solved this problem using the modeling language UML, and we described web services as diagrams, using Enterprise Architect.

Pictures are always a good idea and they play an important role in the documentation. As a result, we have a "living" and clear model of the project, and with some small tricks, it`s possible to generate a "paper" version of the spec.

Audience level
Regular Talk (40 min)

Effective tester & analyst cooperation


In the software development process communication between the testing and analysis is inevitable. To give tester a clear and high-quality documentation, analysts need to understand what he should change / reword / clarify and that`s why a dialogue and teamplay are required. All team members should also clearly understand how to deal with each other - analysts can be different and sometimes they speak an unknown language.We all know that a true (waterfall) testing should begin as soon as possible - with the documentation. So the testers questions occur in the early stages of creating / writing of the documentation. In general communication between the two camps is more active than it seems.  That`s why (as well as for other reasons) an analyst rides whip and spur to the tester - all for software quality! A good example is a large number of tools for tests -requirements synchronizing, for example, Polarion or QC. 

Audience level
Lightning Talk (20 min)