Answer

Background:
Modern information systems often operate under load, with increasing numbers of users and data volumes. Businesses demand high performance and scalability of the product, fault tolerance, and minimal downtime risks.

Problem:
Performance requirements are rarely formulated clearly, often formally as "works quickly" or "scales to 100,000 users". Poorly elaborated criteria lead to the inability to verify, agree upon, or test the solution, and sometimes to resource overruns.

Solution:

1. The analyst initiates collaboration with architects/infrastructure for gathering benchmarks and analyzing peak loads.
2. During the requirements gathering stage, usage scenarios are clarified: maximum number of simultaneous users, transaction volume, SLA on response time.
3. Measurable non-functional requirements are formed: "Load 10 million items in 5 seconds with 1000 simultaneous requests".
4. Profiling and prototyping tools are additionally used to assess actual performance.
5. All parameters are agreed upon and linked to business goals (e.g., SLA of customer service).

Key features:

• Focus on measurable criteria (specific metrics, SLAs)
• Collaboration with architects and DevOps on load testing issues
• Balance between “ideal” and real business priorities

Trick questions.

Can standard metrics from the industry be used without analyzing the product?

Standard metrics are useful for guidance but must be adapted to the specifics of the business and the target audience of the product. Otherwise, key scenarios and load may be overlooked.

Is the load during development testing sufficient to be confident in scalability?

No, test environments often differ significantly from production in terms of infrastructure parameters. Load tests must be conducted as close to reality as possible and repeated periodically.

Is it possible to achieve maximum performance without compromising business functionality?

There is almost always a compromise: sometimes limits are introduced (e.g., batch processing or caps for specific scenarios) for stability and budget compliance.

Common mistakes and anti-patterns

• Formulating requirements "by eye" without specifics
• Lack of repeated measurements after releases and changes
• Ignoring scalability in the design stages (postponing until "when there are many users")

Example from life

Negative case: The technical specification stated "operates under high load," but did not define metrics. In the release, data loading took hours, and the business lost clients. Pros: Quick agreement on requirements. Cons: Unpredictable system behavior under load.

Positive case: The analyst requested business scenarios, together with architects, fixed limits, and conducted load testing. In the release, the system handled the peak load during promotions. Pros: Predictable growth, successful marketing campaigns. Cons: Delay in release due to additional testing.