Conferences for professionals in the information technology industry

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

Saint Petersburg


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


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)