Before buying madrasa software, the real step is building a written requirements document: each department’s work in sentences, each sentence paired with “how we will verify it” — and only then looking for vendors. Doing it backwards (shaping needs around seen software) forces the institution into the software’s mould, and real madrasa work rarely fits that mould.

What to verify: a clear description of each department’s distinct workflow

Use this structure per department in the requirements document:

Section Write Example (Hifz department)
1. Purpose what this department achieves every student’s Juz position known daily
2. Current method how it happens now the room-ustadh’s register
3. Required functions exact software tasks separate sabaq/sabqi/manzil entry
4. Reports who sees what, how often weekly weak-student list
5. Privacy who must NOT see other departments cannot view Hifz scores
6. Verification method what to make them do in a demo enter sabaq for 3 students → print report

The last section is the most valuable — in front of a vendor you simply read the verification method and run the demo, and whatever they cannot perform is evidence on the spot.

A usable sample: requirements document outline

Give the whole document this skeleton:

  1. Introduction — institution profile, structure (departments, students, boarding?).
  2. Department sections (each department in the table’s structure).
  3. Connections — where department data binds (Hifz students also pay fees? yes → link to the office module).
  4. Roles and permissions — who sees and edits what.
  5. Implementation — data import (Excel?), training, who configures.
  6. Limits and risks — what the software will not do; what stays on human rules.

Department-wise requirements: workflow steps and limitations

  1. Do not try to write it in one day — sit with each department’s owner and write their part with them.
  2. Do not write “everything is good to have” — write what is needed; extra demands raise the price.
  3. Write verification sentences as actions: “sabaq for 3 students will be entered and a monthly progress report printed” — not “Hifz feature must exist”.
  4. Limitation: the document will change — date every version; against which version a vendor quoted matters.

Department needs: questions to ask before your demo

  • Will you demo the steps of this document in the same order?
  • What you cannot deliver now — is that customization, roadmap, or “not available”?
  • Will customization cost and time be given in writing?

Compare your list against madrasa operations and the madrasha management features; for cost comparison see pricing and to start see the contact page.

Department needs FAQ

Is a requirements document mandatory?

Legally no; practically yes. Without a written document, demo comparison is opinion-based — and opinion-based comparison produces no decision.

Which language should the document use?

The language in which department owners can write most precisely — usually Bangla; add an English translation when handing to vendors.

What if a vendor copies the document?

Add a clause: “this document is for evaluation; not for reproduction in sales material.”