Should an analyst consider and anticipate risks, or is risk management solely the responsibility of managers?

In this talk, I'll try to dispel common myths about risks and show how potential problems can be turned into a driving force for our achievements. And this is not just theory from books, but also my own experience in IT and beyond. If it worked for me, it can work for you too!

Today, the very need for analysts is being doubted — “AI will replace us soon!” And although most already understand that this is not the case, the analyst’s role and functions are being reconsidered. Yet, there are areas where replacing us with AI is difficult.

Let’s look at a recipe suggested long ago by Frederick Brooks in his bestseller The Mythical Man-Month. We are vigorously discussing and applying the conclusions from his ideas of the Silver Bullet, the Mythical Man-Month, and the Tower of Babel, but we’ve somehow overlooked another — conceptual integrity — which Brooks saw as the most important factor in a system’s success.

In practice, treating the system as a single entity brings clear benefits both in terms of development and further evolution of the system. Ignoring such vision leads to inconsistencies and costly rework.

I will reveal my secrets on how analytics can help a project/product be successful and help yourself in professional growth.

Each system eventually reaches the implementation stage. Even if a system is already in use and undergoing upgrades, launching a new version often requires significant effort and specific preparations. How can we ensure a smooth deployment, avoiding issues such as overlooked constraints, unfinished tasks, or challenges arising from our team, users, or other stakeholders? 

Software development is a complex process that depends on technologies and methodologies. An analyst plays a key role by distinguishing between invariant aspects (which remain unchanged regardless of the chosen approaches) and variable aspects (which depend on specific technologies and methodologies). Critical stages, such as requirements elicitation and design, remain important, but their implementation may vary. ISO/IEC 12207 (software life cycle processes) and ISO/IEC 15288 (system life cycle processes) standards help structure the analyst's work, avoid errors, and enhance efficiency. Understanding these processes contributes to creating a quality product, minimizing risks, and achieving project goals with fewer costs, which is essential for a successful career in IT.

Let's talk about something that has been on the minds of developers (in a broad sense) for many years: analysts, architects, programmers, testers, and managers. 

• Why, even when consciously choosing methods and techniques, well-thought-out and tried-and-tested technologies, is the positive outcome of a project not guaranteed? 
• I often find myself having to change project decisions and involve employees in rework. Is there light at the end of the tunnel? Will we have successful systems developed on time and of high quality? 
• How to train new analysts for effective teamwork?

It's no secret that in the work of an analyst, a significant part involves document development. Technical writers, on the other hand, do this all day long. In the workshop, we'll discuss the value of templates in documentation, the pros and cons of their application. We'll explore how with the help of templates and documentation automation:

• Eliminate the monotony of work.
• Reduce errors that are inevitable in repetitive tasks.
• Cut labour costs at least in half.
• Ensure completeness and consistency of decisions.
• Foster collaboration between analysts and technical writers, increasing the team's overall efficiency.

The workshop is based on techniques honed in practical work on large projects.

People think in terms of the patterns that form in their heads. Telling, they share first the most important from their point of view. And only later, during the development process, we learn the details, sometimes very important and significant for the design, and sometimes for the system's architecture. Let's talk about how to keep track, not to lose the important, and not to waste time on the unimportant "bows". How to identify and track inconsistencies in requirements and decisions in the development of architecture and design. Which elements of which artefacts are connected and influence each other? And how to apply it in analysis, architecture, design and change management. And a specialist who knows how to track these needs and changes, who knows how to bring them to the team (to the RP or manager), becomes indispensable and quickly grows to the leader.

There is an entrenched view in the professional community that professional standards are unnecessary. 

However, ours is not written in an ivory tower and can be successfully applied in the following areas: 

• guidelines in the profession (where to develop and where to go); 
• using the professional standards in the system of higher education and the system of professional education; 
• using the professional standards by training centres; 
• using the professional standards for self-education of system analysts; 
• using professional standards by system analysts and those who hire, train and set tasks for them. 

Several dozen IT people have contributed to updating the professional standard. Big knowledge sets like BABOK, CBOK, and PMBOK started similarly. 

Anyone interested in this, who sees other perspectives, comes and talks about it.

An analyst's knowledge of several (the more, the better) subject areas is a significant competitive advantage of a specialist and an important value for a company with such a specialist. In the current realities of "digitization of everything", a request to create or upgrade a system in a new, unfamiliar domain can arise at anytime. It would be nice to have techniques for quick immersion, not in 3-6 months, but in adequate time.

We often hear phrases like: "The tester must ..", "The tester can ..."... At the talk, we will consider what a tester can / should do in different development scenarios in IT. With whom (with what roles in the team) interacts at each step. Like him, the tester's (quality engineer!) actions affect the quality of the system being developed. How can a quality engineer influence the success of a system. We will develop the skills of a tester not only in testing, but also in work decomposition, planning, studying software requirements, choosing testing methods, developing checklists and test cases. And we will also understand how to prepare for testing. The talk is built on my experience in all roles of the software development team.

Errors occur at all stages of software development. The earlier we detect errors, the cheaper it is to fix them. Last year, at SQA Days-29, we held a workshop where testers learned how to identify errors in requirements before the development stage. Since the interest was high, this year we decided to continue the work. 

At the workshop, we are going to review new checks for requirements — state and transitions diagrams and solution tables. And we will repeat and consolidate the rules of ISO 29148 and CRUD(L) — the requirements to be met by the system requirements.

The workshop is intended for practising requirements revision skills, following up on the talk "Ways of requirements revision". 

Steve McConnell, in his book 'How Much Does a Software Project Cost' and World Statistics, tells us that it is most expensive to correct bugs made during the requirements gathering and design phases. Sometimes the bugs detected are serious enough to require redesigning not only your system (or some part of it) but also related systems. When these bugs are detected at the testing stage, the work of analysts, developers, testers and technical writers goes in the bin. 

Can we identify at least some of these bugs at an earlier stage of work? Can a tester (requirements engineer) detect bugs in requirements before software development? 

We will look at one of the fundamental properties of requirements: completeness, including CRUDL. We will see how we can check this property.

For several years we have been following the epic of the translation into Russian of the "Guide to the Business Analysis Body of Knowledge" (BABOK 3.0). We discussed on Facebook, analyzed terms and concepts, waited for messages from the head of translation, Alexander Belin, and even performed a review. And then it happened - a red-haired volume of 600 pages in our hands.

In the talk, I will introduce you to the structure of BABOK, the content of the sections and the interdependencies of the parts. I will share recommendations for using the body of knowledge and show two or three examples from my personal practice. I'll tell you why:

a) a novice analyst is not recommended to start learning business analysis with BABOK 3.0;

b) It is helpful for the practising analyst to have the BABOK as a permanent desk guide;

c) It makes sense even for experienced analysts to occasionally look into a book.

In chat rooms and analyst groups, questions often arise: 

• How to assess the competencies of analysts?
• What competencies should a middle analyst have, what should a senior analyst have? 
• How to assess competencies? How to understand what competencies are lacking? 
• How to explain the assessment result to a person without offending him/her? 

I'll tell you about how we built a competence assessment system, assessed analysts, and obtained a tool for developing specialists and assistance in securing project work. And how to build a similar system for your needs in 5 steps.

The talk is based on the real experience of working as the head of the systems analysis department in a large IT company. Many employees have grown from Juno to lead analyst, became heads of departments, project managers, chief specialists, architects. It will be of interest to both resource managers of analysts and analysts consciously seeking their own professional development.

The quality of functional testing largely depends on the tester's knowledge of the subject area of the SOFTWARE being tested. There are a lot of subject areas, sometimes they are complex, sometimes very complex, and you need to test them. In this report, I will share techniques for rapid immersion in a new subject area. I will tell you what points you need to pay special attention to when testing the functionality of complex systems.

As a follow-up to Anatoly Levenchuk's report, we will talk about the application of systems engineering and system management methods based on systems thinking. How these methods help improve quality in the design and implementation of complex systems, reduce overhead and accelerate design work. Sergei Pchelyakov will share an example of how, with a lag of 20% in the middle of the project, using these methods, he managed to finish the project successfully, reducing the term by almost 20%.

Business digitalization, merging of business and IT leads not only to the growth of functionality of IT systems but also to criticality for a business of availability, reliability, the safety of IS. Let 's talk about how an analyst can and should influence such properties of IT systems, that is, non-functional requirements, their identification, application, reflection in project documents. Let 's look at the main classifications (international, state, industry) and scenarios of quality attributes, their application in the work of analytics. The report is based on its own experience. I will share my vision of the analyst 's work checklist to ensure the system is operational.

Many of us are familiar with the situation: the customer received a request for a presale, an urgent task for analysts, an opportunity to conclude a promising contract, but there are no experts among the Company's analysts in this subject area. Is this a reason to refuse a deal? Or is there a way out?
At the workshop, I will share my experience, how in a few days I immersed myself in a new domain, what problems arose and how they were solved. We will discuss examples of successful and unsuccessful experience and the reasons for failures. Consider using the method of mental maps (Impact Mapping), as a way to determine the boundaries of the project and the main hypotheses created by the joint efforts of the developer and the Customer. Together, we will develop a checklist of analyst immersion in a new domain.

The analyst's participation is necessary at every stage of software development, from survey to implementation. At the master class, we will review the entire software development process and the role of the analyst at each stage. Let's talk about what sources of information are used by the analyst at each stage, what results are obtained and how they are applied in the future. What you should see, take into account, provide for the successful development, implementation and operation of the software. Consider the typical problem points and resolution paths. Of course, in an hour and a half, it is impossible to consider the details, but we will have time to highlight the main stages, discuss the goals and results of each stage.

The topic of the talk was inspired by discussions in close circles of analysts  - is it possible to assess the labor work of analysts and clearly defined turnaround time? It will be demonstrated which assessment methods of labor costs and the dates of performance of the work of systems analysts we use in our daily practice. 

This talk is not for you if you have:

- experienced analysts who are able to assess own the dates of performance of the work with precision acceptable by a project manager;

- diversified,  often research works;
- innovative directions of works, mostly brainstormings and researches.

Information system of a large industrial enterprise or a government department consist of several software systems. Also these software systems interact with other organizations software systems. For various reasons, changes to the software is the constant necessities of life. Inconsistent changes of software systems have a risk of stopping work the Information System and the enterprise (the organization, the government department) in whole. The report describes the sample of the management functional requirements of the automated system. We explain about changing the documents, the system operation on the documents, the user operation on the documents and the interfaces of exchanging document between subsystem. We suggest the requirements storage structure and the methods of monitoring changes in adjacent subsystems. Change monitoring allows stable operation of an organization. In additional the system requirements management makes it possible to generate project documentation.