Answer.

History of the question:

Automating non-standard or emerging business processes has long been considered a complex task due to the lack of clearly defined scenarios and high volatility. Traditional systems analysis approaches do not always fit, requiring a more flexible methodology.

Problem:

The main issue when working with such processes is their dynamism: the initial description often does not reflect the essence of some operations, and client requirements can change or be clarified quickly during the work.

Solution:

To accurately identify and describe requirements, iterative approaches (Agile, Lean) are applied, data is collected through observation and rapid prototypes, users are actively engaged (e.g., through workshops), and requirements are documented in the format of user stories, supplemented by live documentation in Confluence, Miro, Figma, etc. Key features of the approach:

Continuous feedback from users and the business team
Use of prototyping and rapid MVPs to clarify vague scenarios
Incremental refinement of requirements: documenting only what is viable and repeatable

Tricky Questions.

Are the requirements the same at the beginning and at the end of the analysis of an unstable process?

No, as a result of the analysis, the requirements change: some become outdated, and some are only formalized after applying prototypes in real practice.

Is it necessary to document the entire business process at once if it is changing?

No, only the verified and operational fragments should be documented; the rest should be left as hypotheses or clarified as development progresses.

Should only one method for documenting requirements be chosen?

No, it is important to use multiple channels: stand-up boards, electronic drafts, prototypes — for different audiences and stages.

Common Mistakes and Anti-Patterns

Attempting to detail all aspects in advance (waterfall)
Ignoring feedback from the user
Working exclusively with already approved documentation or only verbal requirements, without live examples

Example from Life

Negative case:

A company decided to automate a process that has not fully stabilized yet. The analyst described the process strictly according to the scheme, recording everything that the employees reported. After launch, the process changed rapidly, and the system did not respond to new realities.

Pros:

Existing schemes were integrated quickly

Cons:

The process was only partially automated, most changes were not accounted for, leading to costly rework

Positive case:

The analyst performed partial documentation only of stable stages, built an MVP with a minimal set of functions, collected feedback, refined requirements together with the business, leaving room for changes.