В аналитике с 2013 года.
An analyst for a system, as a therapist for the patient
An analyst is not a wizard, not a psychic, he can't foresee the development of a system. However, the analyst is a therapist who can diagnose the symptoms of the system, gives recommendations for healing and predicts further behaviour.
In the talk, I will tell you what you need to do to detect and treat the symptoms correctly. Also, I will provide some recommendations on how to build an analyst team and interact with a development and testing team. In addition, I will give you a number of recommendations on how to change the attitude of developers and testers to the analysts' work. This is important to propel the process of creating and maintaining the system to a new level.
Also, in the talk, I will describe how the analyst, installing "anchors" in the design of the system, can help to make the system maintenance cheaper.
Requirements Management when Working with a Remote Team
For many companies, working with a remote team has become a common practice. However, when organising such kind of work, the requirements management stage is often neglected. It should be remembered when working with a remote team, the requirements management process does not disappear, however, it adjusts slightly.
In the first part of my talk, I will tell you how professional books and articles on specialized resources advise you to manage requirements when you work with a remote team.
In the second part of my talk, I will share our experience in organizing the analyst’s work with a remote team and demonstrate you how the classical process of requirements management (RUP) changes in this case. Moreover, I will show you a set of tools that can be helpful in this respect, and tell you how to provide remote access to requirements management tools.
Requirements Management with Enterprise Architect
Every system analyst knows what requirements are, where they come from, what kinds of requirements exist, how to collect and analyse them. Unfortunately, requirements management is often confined to these aspects only. In fact, requirements management is needed until the customer accepts the product.
I’ll present you a set of practices, which we use in requirements management. I’ll tell you how to record requirements collected, their estimation and distribution of resources, how to create patterns on the basis of common requirements, how to track changes to requirements and what should be done to prevent losing requirements in the process of engineering.
Then I’ll show you the examples of how to apply these “analytics lifehacks” in Enterprise Architect. This tool allows establishing the connection between the documented need of the customer and the function that implements this need, via connection with the formalised requirement. I’ll outline the advantages of EA.