At the pre-project stage, the business analyst identifies key business constraints related to budget, timelines, resources, regulatory requirements, technological compatibility, internal company policies, or external market conditions. The analyst documents these constraints in detail, highlighting their impact on requirements and possible workarounds.
A specific section in the requirements specification is used for documentation, for example:
**Constraints:** - Maximum budget — 5 million rubles. - Launch no later than 01.09.2024 - System to operate only on existing infrastructure (Linux servers)
Key features:
Are constraints part of business requirements?
No, constraints are external conditions or limits within which requirements are executed, not the requirements themselves.
Can unformalized constraints be ignored?
No. Even unformalized constraints (e.g., internal company rules) are extremely important to identify and include in documentation; otherwise, the project risks being derailed.
Is the business analyst responsible for accurately describing technical constraints?
Yes, the analyst must describe both business and technical constraints, although technical details can be clarified in consultation with the architect or technical expert.
Negative case: In a project for a bank, legislative data storage constraints were not taken into account.
Pros: The process moved faster at the start. Cons: At the finish, the product failed the audit and was blocked, requiring the company to urgently redesign the architecture.
Positive case: The analyst included the legal department in discussions from day one and documented every constraint regarding compliance with Federal Law 152-FZ.
Pros: Problems were identified early; solution was immediately designed with consideration of the law. Cons: More time was required for document approvals.