01 · What breaks
Design for the failure modes, not only the happy path.
Requirements documents usually fail in one of two ways: they are borrowed from somewhere else, or they list everything anyone has ever wanted. Both produce proposals that cannot be compared.
Copying another NGO's requirements
Another organisation's requirements describe their programme, their funders and their reports. Borrow the structure of a template, never its content. A skilling programme and a child protection programme may both need case notes, with completely different access rules and review cycles.
Hundreds of fields without purpose
A list of 400 fields hides the twenty that matter. For each field, name the meeting, report or service decision that uses it. If nobody can, leave it out. Long forms also cost data quality: entries get less careful as a field visit drags on.
Non-functional needs omitted
Offline use, languages, device types, expected record volumes, data retention, audit trails and who may export what are rarely written down, yet they change the platform choice and the price. Give them their own section, with the field locations and phones your teams actually use.
Success defined only as launch
If the only success measure is that the system went live, nobody checks whether it is used. Write two or three measures for three months after go-live, such as attendance entered within 48 hours or the monthly report produced without manual reconciliation.
02 · Minimum viable model
Write the template around the work, then list the features.
These six sections are what EdZola asks for before a design is drafted. Most can be filled from documents you already have: registers, current sheets, funder report formats and the Theory of Change.
| Section | What to include | Example entry |
|---|---|---|
| Journey | Each step, who does it, where it is recorded today | Field facilitator marks attendance on paper; centre coordinator types it into a sheet on Fridays |
| Central record | The unit, its ID format and the duplicate rule | Participant ID; duplicate check on name, date of birth, guardian and village |
| Status model | Every state and the reasons for leaving it | Enrolled, active, completed, dropped (reason from a fixed list), transferred |
| Reports | Audience, frequency, formula, data freeze date | Quarterly funder report: completion rate equals completed divided by enrolled in the period |
| Organisation record | Registrations the system must check before acting | PAN, 12A or 12AB, 80G validity dates, FCRA status, NGO Darpan ID, CSR-1 number |
| Non-functional | Offline, languages, devices, volumes, retention, export rules | Works offline for three days on a shared Android phone, in Tamil and English |
| Section | What to include | Example entry |
|---|---|---|
| Journey | Each step, who does it, where it is recorded today | Field facilitator marks attendance on paper; centre coordinator types it into a sheet on Fridays |
| Central record | The unit, its ID format and the duplicate rule | Participant ID; duplicate check on name, date of birth, guardian and village |
| Status model | Every state and the reasons for leaving it | Enrolled, active, completed, dropped (reason from a fixed list), transferred |
| Reports | Audience, frequency, formula, data freeze date | Quarterly funder report: completion rate equals completed divided by enrolled in the period |
| Organisation record | Registrations the system must check before acting | PAN, income-tax registration and 80G approval with validity dates, FCRA status, NGO Darpan ID, CSR-1 number |
| Non-functional | Offline, languages, devices, volumes, retention, export rules | Works offline for three days on a shared Android phone, in Tamil and English |
03 · Implementation sequence
Move through reviewable gates.
Fill the template in this order. Each step is cheaper than discovering the same gap during testing.
Complete the programme journey first
Draw the journey as swimlanes, one lane per role, from first contact to the last follow-up. Mark in red every step done in WhatsApp, email or on paper. Write down the people who consume the output as well as those who enter data; the second list is usually longer, and it is where scope creeps in.
Work through one representative case
Pick one real, slightly messy case, for example a participant who joined late, moved centres and returned after a break. Walk it through the draft template. Every question the case raises (which centre owns the record, is the person counted twice) becomes a written rule.
Mark must-have versus later
Mark each requirement as must-have for the first phase or later. A must-have names the decision or obligation that fails without it. Vague requirements become precise questions: "records should be deleted" becomes when, after whose review and after what grace period.
Attach examples and definitions
Attach sample registers, current sheets and each funder's report format, with personal details removed before anything is shared. Define every indicator with its numerator, denominator and source, so two people calculating it separately get the same number.
Review with field, MEL and leadership
Read the draft aloud with a field team member, the MEL lead and a leadership sponsor in the same room. Field staff catch impossible forms, MEL catches broken definitions and leadership catches scope that will not be funded. Record who agreed to what.
Issue a controlled version for proposals
Freeze a numbered version, share the same file with every shortlisted partner, and log any later change with a date and reason. Ask each partner to answer against the template, so you compare responses to your programme rather than to their demonstration. The custom versus off-the-shelf guide helps with that comparison.
04 · Evidence
Measure whether the work became clearer.
You will know the template worked when partner proposals can be compared line by line and testing finds few surprises. Teams starting from scratch can use the nonprofit technology assessment first.
05 · Responsible automation
Let systems prepare. Keep consequence with people.
Systems can support
- Turning a RACI into a permission matrix
- Checking every field against a named purpose
- Comparing partner responses line by line
- Keeping a versioned change log
People should decide
- Scope and trade-off decisions
- Accepting security risk
- Choosing the implementation partner
- Signing off the final requirement
06 · Common questions
Practical questions teams ask.
Common questions from programme heads and MEL teams preparing to brief a technology partner.
What should a nonprofit MIS requirements document include?
It should include the programme journey step by step, the central record and its ID and duplicate rules, a status model with exit reasons, a permission matrix by role, each report with its audience and formula, non-functional needs such as offline use and languages, the data to migrate, and two or three success measures for after go-live. Sample sheets and forms should be attached.
How detailed should MIS requirements be before asking for proposals?
Detailed enough that a partner can count the work: how many modules, forms, roles, workflows, reports and integrations. You do not need screen designs. Those come later, in a paid design stage. If two partners would read the same requirement and build different things, it needs a rule or an example.
Who should write the requirements for a nonprofit MIS?
A programme or MEL lead usually holds the pen, because they understand both the field work and the reports. Field staff should test the journey and forms, finance should check anything touching budgets or donor receipts, and a leadership sponsor should approve the must-have list and the success measures.
Which compliance details belong in an MIS requirements template in India?
List the registrations the system must check before acting, such as 80G approval before issuing a donation receipt, or FCRA status before tagging funds. Note that, as of October 2026, the Income-tax Act, 2025 has renumbered the old 12A, 80G and Form 10BD references. Add consent rules for personal data, especially children's. A chartered accountant should confirm your obligations.
How do we stop the requirements growing during the project?
Freeze a numbered version before proposals, and agree that anything not in the signed design is a change request with its own estimate. Keep a change log with a date, reason and decision for each request. Most growth comes from consumers of reports who were never consulted, so list them at the start.