Тестировщик, перешедший на сторону бизнес-анализа. Люблю коммуникации во всех их проявлениях, новые предметные области и понятную документацию.
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.
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.
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.
How we specified a project with UML
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.