How an Analyst Influences the Quality of an IT Product: A Practical Perspective

When teams talk about “product quality,” everyone puts their own meaning into this term: for some, speed is crucial; for others, design; and for some – that it “just works.” That is why the same product can simultaneously receive feedback like “well done” and “everything needs to be redone.”

At the core of such contradictions lies a simple thing – misaligned expectations. And this is where the business analyst becomes a key person who helps translate vague ideas into clear requirements.

Quality Starts Not with Testing, but with the Structure of Requirements

In product teams, an analyst is not just someone who “writes requirements.” They are the person who forms a shared vision of the product between the customer, developers, testers, and users.

As soon as a requirement is unclear, the product becomes unpredictable.

Example:
Requirement: “The system must process requests quickly.”

• How quickly?
• Under what conditions?
• For which categories of users?

Without answers, we get three different interpretations and, accordingly, three different implementations.

Therefore, one of the analyst’s tasks is to remove “suitcase words,” clarify expectations, and ask all the “uncomfortable questions.” This is the foundation of quality.

Internal Quality: What Is Built Under the Hood

Although an analyst does not work with code, their work directly affects the technical foundation of the future product.

Important aspects for which the analyst is indirectly responsible:

• clear descriptions of integrations and system scenarios;
• performance and security requirements;
• consideration of constraints and dependencies;
• agreed Definition of Done criteria.

Example:
If you do not specify how the system should behave under peak load, the product will work perfectly… until real users open the application simultaneously.

Another important internal quality tool is code quality control systems (such as SonarQube).

They are used by developers, but the results are also visible to the analyst:
when there is a lot of “red” in the report, it is a signal that the module may be unstable.

External Quality: Seeing Through the User’s Eyes

External quality is what a person who uses the product sees and feels.This is where impressions like “convenient / inconvenient,” “logical / confusing,” “works / doesn’t work” are formed.

In this context, the analyst’s role closely intersects with the work of a QA specialist.

A tester checks two aspects:

1. Does the product meet the requirements (verification).
2. Does it solve a real user problem (validation).

The second point often reveals things that are not obvious at the requirements-writing stage.

Example:
The “Upload document” button formally works, but it is hidden in the third submenu.
The tester says: “Finding it is like a quest. Users will hate it.”
And they are right – this needs to be fixed before release.

That is why the analyst ↔ QA dialogue is one of the most valuable.

Documents That Help Control Quality

To make product quality not a “feeling” but a measurable process, the team uses several key artifacts.

1. Test Matrix

Shows:

• list of requirements,
• test cases for each requirement.

An analyst can open the document at any time and understand which parts of the product are already covered by test cases and review their coverage.

2. Traceability Matrix

This is a mapping of:
requirement → test cases → automated tests → results.

If the matrix is filled in, the analyst can easily assess the real state of product testing even without meeting with QA.

Shared Responsibility for the Product

In high-quality teams, there is no culture of “this is not my responsibility.”
Quality is a shared result.

Analysts set the framework, developers implement, testers verify, managers organize.

If any of these elements falls out, the product starts to wobble like a building with a poor foundation.

Conclusion

Quality is not a set of beautiful interfaces and automated tests. It is the product’s ability to truly do its job: stably, logically, predictably, and in a way that is convenient for users.

And the analyst is one of those who defines this direction from the very first days of working on the project.

What to Do Next?

• Review your own requirements: are they really precise and verifiable?
• Talk to QA in your team: ask whether they have a test matrix or a traceability matrix.
• Try to describe requirements in a way that does not allow “double interpretation.”
• Deepen your knowledge of the analyst’s role and product quality through SkillsUp’s author courses led by leading IT experts – this will help systematize processes and work at the level of mature teams.

Register with the code NY2026 and get a 20% discount until the end of the year.