Answer.

Business requirement is a description of the desired business goal or task that an organization wants to achieve with a new solution. System requirement describes how the information system should specifically implement these business goals. This separation is crucial for a correct hierarchy of documentation and for preventing misalignments between business expectations and technical implementation.

Examples:

Business Requirement: Increase lead conversion by 15% within the quarter.
System Requirement: The system must automatically send a reminder email if a potential client has not responded within 48 hours after the first contact.

Key features:

Business requirements are formulated from the perspective of stakeholders and reflect the organization's goals.
System requirements specify the functions that the IT system must support to achieve business objectives.
A clear division helps manage changes and control the fulfillment of requirements during the testing phase.

Trick Questions.

Why should we not only describe system requirements, skipping business requirements?

This approach leads to "narrow" solution development: the technical team implements not what the business truly needs, but only what is specified in the technical specification (TS). As a result, strategic goals or significant unaccounted needs may be missed.

Can business requirements change during the project, and why is it important to document each change?

Yes, business requirements often change due to changing market conditions or clarification of goals. It is critical to document changes to maintain traceability of the requirements sources and timely adjust system requirements.

Does it mean that a system requirement is only technical and does not affect business outcomes?

No. A system requirement is directly related to achieving business outcomes, as its fulfillment ensures the realization of the corresponding business requirement.

Common Mistakes and Anti-Patterns

Confusing business and system requirements by formulating tasks only in IT language.
Insufficiently developed business requirements, leading to frequent changes and conflicts.
Lack of traceability between layers of requirements.

Real-Life Example

Negative Case

A business analyst immediately writes a technical specification with system requirements without documenting the business goals.

Pros:

Quick start of work.

Cons:

Discrepancy between the final product and business expectations, costly rework, and conflicts.

Positive Case

The analyst documents business requirements, obtains confirmation, and then formalizes system requirements based on them.