Answer.

The business analytics lifecycle is a sequence of stages through which a task is resolved, starting from understanding the problem and ending with the implementation of IT systems or business changes. Typically, the cycle includes:

1. Problem identification. Defining the key task and objectives of the study.
2. Requirements gathering and analysis. Contacting stakeholders, clarifying needs.
3. Documentation and modeling. Describing requirements in the form of specifications, models, and diagrams.
4. Transferring requirements to the development team. Formalizing and clarifying expectations.
5. Implementation control and feedback collection. Participating in testing, analyzing the success of changes.

Key features:

• Understanding the role of the business analyst as a mediator between business and IT.
• Using various modeling tools (UML, BPMN, etc.).
• Iterativity of the process: requirements are refined at each stage.

Tricky questions.

What is the difference between functional and non-functional requirements?

Functional requirements describe WHAT the system should do (e.g., order processing). Non-functional — HOW the system should operate (performance, reliability, security, etc.). These concepts are often confused when only the functionality is designed.

Can requirements be fixed once at the start of the project?

No, requirements are refined throughout the project. They may change due to new inputs from the business or as a result of market analysis.

Is it necessary for a business analyst to know how to program?

No, at the level of responsibilities, it is not mandatory. Understanding business processes and basic development principles is important to accurately describe tasks and communicate with the team.

Typical mistakes and anti-patterns

• Ignoring changes in requirements throughout the project.
• Lack of clear documentation.
• Insufficient communication between stakeholders.

Real-life example

Negative case: The business analyst fixed the requirements at the start of the project and did not make changes until the end of the sprint. As a result, an irrelevant product was released.

• Plus: rapid development without changes.

• Minus: the result does not reflect the business needs.

Positive case: The analyst implemented regular sprint reviews and adjusted requirements according to feedback.

• Plus: the product accurately meets business objectives.

• Minus: increased workload for approvals.