Digital Products

Business Analysis and BRD

Clear requirements, scope and acceptance criteria that the business and the technical team understand the same way.

Add to project estimate

Many disputes between a business and its software supplier start with a requirement that each side understood differently. The business asks for a system that handles approvals; the developer builds one approval step, while the real process has three, with exceptions by amount and branch. The gap appears during testing, when changes are slow and expensive, and both sides argue about what was agreed.

Kemlat does the business analysis before anyone builds or buys. We talk to the people who do the work, document what the system must do for each role, agree what belongs in the first release, and write acceptance criteria that show how each requirement will be checked. The result is a business requirements document (BRD) that your team, your supplier and your management can all read and approve.

How we work

  1. 01

    Interview the people who do the work

    We hold workshops and individual interviews with each department involved, and review current forms, reports and system screens. We record how the work is done today, including the exceptions handled by hand.

  2. 02

    Define roles and requirements

    We list each user role and write each requirement in plain language: who needs to do what, and why. Rules such as approval limits, calculations and notifications are written down with worked examples.

  3. 03

    Agree priorities

    We sort requirements into essential, important and later, and settle conflicts between departments in a joint session. Where departments still disagree, the project sponsor decides.

  4. 04

    Set scope and acceptance criteria

    For each requirement in scope we write acceptance criteria, meaning the specific checks that prove it works. Assumptions, open questions and items outside the scope are listed separately.

  5. 05

    Review and approve

    We walk through the BRD with the business owners and, if one has been chosen, the technical supplier. Comments are resolved and the document is approved as the reference for the build or the tender.

What you receive

Business requirements and user roles

A structured list of requirements grouped by process and role, with business rules and examples.

Current and target process maps

Simple diagrams of how the work flows today and how it should flow in the new system.

Product scope and priorities

What the first release contains and what comes later, with the reason for each priority.

Acceptance criteria

Testable conditions for each requirement, which your team will use to accept or reject the delivered system.

Assumptions and open questions

What the scope depends on and what still needs a decision, each item with an owner.

What changes for you

  • Your team and your suppliers quote, build and test against the same written description.
  • There are fewer disputes during testing, because what counts as done was defined in advance.
  • Departments agree their priorities before money is committed.
  • Knowledge that sat with a few people is written down and shared.

Scope: This service produces the requirements and the scope, not the system itself. The approved BRD can be used to brief Kemlat, another supplier, or a formal tender.

Questions clients ask

Is a BRD only needed for large projects?

No. Even a small system benefits from a short document listing roles, rules and acceptance criteria. We match the depth of the document to the size and risk of the project.

Who from our side needs to be involved?

A sponsor who can settle priorities, and people from each department who know the daily work and its exceptions. Their time is needed mainly for interviews and review sessions.

Can you write requirements for a system we have already chosen?

Yes. In that case we also mark where the chosen product meets a requirement as it is, where it needs configuration, and where it does not fit.

What format will the document be in?

A Word or PDF document with process diagrams, plus a requirements list in Excel if your supplier prefers to track items one by one. It can be written in English, Arabic or both.

Start with a conversation

Tell us where you are today. We will suggest the right first step, with no obligation.