Answer.

Historically, IT projects have focused primarily on functional requirements: what the system should do. Meanwhile, issues of performance, reliability, scalability, availability, security, and maintainability (these characteristics are collectively referred to as 'non-functional requirements', NFR) have long been considered secondary and often not formalized at all.

Issue

Ignoring or formally describing NFR leads to significant operational problems: the system may not be ready for expected loads, may fail to withstand cyber-attacks, may be difficult to maintain and scale, or may be unavailable for the required number of users.

Solution

A modern systems analyst must initiate, formalize, analyze, and document NFR. This includes:

collaborating with architects, DevOps, and operational teams to define technological and infrastructure limitations;
gathering requirements from the business (e.g., regarding SLA);
creating a comprehensive list of NFR with specific threshold values;
implementing measures for their control during implementation and support;
documenting requirements in separate sections of the specification.

Key features:

NFR are mandatory for any large projects.
They are defined jointly with technical and business stakeholders.
They must be unambiguous, testable, and tied to business objectives.

Tricky Questions.

What is the difference between "product quality" and "non-functional requirements"?

Product quality is a broader concept that includes not only formalizable parameters but also subjective assessments (e.g., UX/UI convenience). NFR are clearly measurable characteristics (performance, reliability, etc.) that can be automatically validated.

Can an analyst delegate the identification of all non-functional requirements to an architect?

No, the analyst is obligated to identify these requirements together with the architect and the business during the analysis phase; otherwise, the requirements will be incomplete or described only from a technical perspective without considering business needs.

Can non-functional requirements be formulated only in general terms ("the system should be reliable")?

No, such formulations are not suitable for control and testing. Specificity is required: for example, "the service recovery time after a failure should not exceed 10 minutes."

Common Mistakes and Anti-patterns

Formulating requirements without testable criteria ("fast", "cool", "reliable").
Omitting entire classes of NFR (e.g., security for internal systems).
Inconsistency of requirements between the client and support.

Example from Real Life

Negative Case: The national government services portal project did not formalize requirements for peak loads. The system "crashed" on days when popular services were launched, resulting in security incidents.

Pros:

Fast MVP

Cons:

Huge costs for improvements
Loss of user trust
Difficulties with support

Positive Case: An analyst at the start of the industrial automation plant project identified with operations that system downtimes were more critical than new features. He worked on the SLA, emergency scenarios, and defined specific metrics.