Answer.

History of the issue:

Initially, the focus when formalizing requirements was on functional capabilities, but over time it became clear that "invisible" criteria (performance, security, reliability, etc.) are critically important for the successful implementation and viability of products. Ignoring them led to failures and unpredictable behavior of the software after launch.

Problem:

Non-functional requirements are often recorded in a templated manner, without studying the context. They are specified just for the sake of compliance or are formulated too abstractly, for example: "The system must be user-friendly" or "The system must be fast." This does not provide developers, architects, and testers with clear KPIs.

Solution:

The system analyst conducts sessions with the business, IT, and operational specialists to identify real constraints, records numerical metrics (e.g., SLA, TPS, latency metrics), explicitly describes non-functional requirements in specifications, and further ensures their testability by linking them to test cases and architectural artifacts of the project.

Key features:

Use of quantitative (measurable!) characteristics.
Inclusion of a formalization and justification stage through agreement with key IT experts.
Linking requirements with testing methodologies.

Tricky questions.

Can groups of requirements be left simply as 'The system must be available 24/7' without further detailing?

No, it is essential to specify the availability parameters (for example, 99.95%) and recovery conditions.

Is it enough to state 'The response time must be fast'?

No, such formulations are not workable. It is necessary to specify, for example: Response time < 3 seconds for 95% of requests with load X.

Are non-functional requirements formalized if they are only written in a general specification without further detailing?

No, they need to be decomposed and linked to architectural decisions and testing plans; otherwise, they will remain unachievable or unverifiable.

Typical mistakes and anti-patterns

Leaving vague formulations that do not allow for testing.
Copying required metrics from other projects without analyzing specifics.
Ignoring consultations with IT/SRE and operations.

Real-life example

Negative case: An e-banking project was launched with the requirement "availability 24/7, fast operation," without specifying SLA.

Pros:

Quick preparation of requirements

Cons:

Frequent failures, unresolved disputes with the outsourcer
Customer complaints

Positive case: The analyst collaborated with the operations department, recorded 99.9% uptime, Max Response 2 sec, described degradation scenarios.