The business analyst is responsible for the complete collection, agreement, and documentation of both functional and non-functional requirements: system performance, security, scalability, availability, user interface usability. To do this, they closely interact with stakeholders (especially with business and IT), use scenarios, and analyze standards. They must not only gather explicit expectations but also identify hidden requirements (for example, data protection regulations). Ultimately, the analyst formalizes non-functional requirements in documentation, agrees on them with the project and technical teams, and also monitors compliance with these requirements throughout the project.
Key features:
Is it enough to just describe non-functional requirements in text without metrics and specifics?
No, abstract formulations ("fast", "secure") are unsuitable for validation. Clear parameters are required: for example, response time of no more than 2 seconds.
Are non-functional requirements only a concern for technical specialists?
No, the analyst must identify and formalize such requirements together with the business, as non-compliance can lead to unsatisfied key business interests.
Is it possible to postpone working with non-functional requirements until the final stages of the project?
No, such requirements are often critical to the architecture of the solution. Identifying them at later stages leads to rework and high costs.
Negative case: Described in the terms of reference the expected "usability" and "performance" without fixing specific metrics. Pros: Less costly at the time of writing the document Cons: Unable to raise claims with the team when the result did not meet the client's expectations
Positive case: Agreed: "Page load speed — up to 2 seconds with a load of up to 1000 users, SLA level — 99.95%". Formalized requirements for personal data protection. Pros: Clear result verification, risk reduction for rework, transparency for all participants Cons: Required time and agreements with IT and legal teams.