Answer.

History of the issue:

Initially, in IT projects, systems analysts focused primarily on business requirements, while technical constraints were either ignored or passed on, leading to non-functional or overly expensive solutions.

Problem:

Technical constraints are not always declared – the client may not be aware of them, development may overlook them, and the result may contradict the capabilities of the infrastructure or integration systems.

Solution:

The systems analyst actively interviews architects, DevOps, QA, and integrators:

• Determines technology stacks, business and infrastructure dependencies.
• Coordinates requirements with architectural principles: SLA, fault tolerance, scalability, licensing or security constraints.
• Documents and validates compromises between capabilities and business desires.
• Applies approaches such as "Scenario-based analysis" and "Non-functional requirements".

Key features:

• Early identification of constraints and dependencies with all responsible parties.
• Documentation of compromises and implicit limitations.
• Constant alignment of project solutions with the company's architecture.

Tricky questions.

Can implicit technical constraints be ignored if they are not stated explicitly?

Correct: No. Implicit technical constraints (such as integration timeouts, message size limits) always require elaboration and documentation, even if they are not explicitly mentioned.

Should the analyst participate in architectural calls/workshops?

Correct: Yes, the systems analyst is a link between the business and the architects, translating requirements to both sides and documenting decisions.

Is it sufficient to collect only business requirements without analyzing inherited constraints?

Correct: No, inherited code, licenses, and integrations (legacy) sometimes impose more constraints than explicitly stated requirements.

Common mistakes and anti-patterns

• Underestimating hidden constraints and dependencies of legacy systems.
• Ignoring "unwritten" architectural rules.
• Documenting only the business side without considering technical feasibility.

Real-life example

Negative case: An analyst documented the integration based on the business process but did not inquire about data transmission speed limitations in the interface.

Pros: Quick specification implementation. Cons: The system could not handle the load, resulting in business losing money and time.

Positive case: The analyst participated in architectural sessions, identified limitations (maximum threads = 100, integration once every 10 seconds), and agreed on cutting limits with the business.

Pros: The solution is functional, stable integration. Cons: Compromise was needed to cut functionality and justify it to the client.