Requirement Gathering & Gap Analysis

Techniques for eliciting requirements from hospital staff, conducting fit-gap analysis against Bio Ecko modules, and documenting business requirements.

February 2026 · 18 min

Manual area

FC Training Programme

Coverage

8 sections

Operator notes

3 implementation notes

The Art of Asking the Right Questions

Hospital staff are domain experts but not technology experts. They describe their needs in clinical language, not system language. The FC's job is to translate.

Golden rule: Never ask 'What do you want the software to do?' Instead ask 'Walk me through what happens when a patient arrives.' The first question gets you a wish-list. The second gets you the real workflow.

Elicitation Techniques

Use a mix of techniques -- no single method captures everything:

Technique	When to Use	What You Learn	Duration
Shadowing	First 2 days at hospital	Real workflow, workarounds, pain points	4-6 hours per department
Structured Interview	After shadowing	Specific requirements, rules, exceptions	1-2 hours per HOD
Workshop	Cross-departmental processes	Integration points, handoffs, conflicts	2-3 hours with 5-8 people
Document Review	Anytime	Existing SOPs, forms, registers, reports	Self-paced
Questionnaire	For large hospitals with many departments	Standardized data collection at scale	Distributed, 2-3 days turnaround

Pro tip: Always shadow before you interview. If you interview first, people tell you the ideal process. If you shadow first, you see the actual process -- including the workarounds they are embarrassed to mention.

Shadowing Checklist by Department

What to observe and document when shadowing each department:

Registration / Front Desk:

How is patient identity verified? (Aadhaar, phone, name + father's name?)
What forms does the patient fill? How long does it take?
How are appointments booked? (Phone, walk-in, app?)
How is the queue managed? (Token, first-come, scheduled?)

OPD Consultation:

Does the doctor type notes or dictate? Paper or computer?
How are prescriptions written? (Pre-printed pads, EMR, verbal?)
How are lab/radiology orders communicated to the respective departments?
Average consultation time?

Pharmacy:

How does the pharmacist receive prescriptions? (Paper, screen, runner?)
How is stock managed? (Manual register, spreadsheet, existing software?)
How are controlled substances tracked?
Average dispensing time per prescription?

Laboratory:

How are samples collected and labeled?
How are results entered? (Manual, analyzer interface?)
How are critical/panic values communicated to the doctor?
Turnaround time from order to result?

Billing:

How many payment modes are accepted?
How are insurance patients handled differently?
Average time to generate a discharge bill?
How often do billing disputes occur?

Fit-Gap Analysis Framework

After gathering requirements, map each one to Bio Ecko's capabilities:

Fit Category	Definition	Example	Action
Direct Fit	Bio Ecko does this out-of-the-box	Patient registration with Aadhaar	Configure and demo
Config Fit	Achievable with configuration (no code change)	Custom approval matrix for discounts > 10%	Document config steps
Customization	Requires code change or new feature	Integration with specific lab analyzer model	Raise change request with effort estimate
Workaround	Not directly supported but achievable differently	Specific report format -- use export to Excel + manual formatting	Document workaround steps for user
Out of Scope	Not feasible or not in current release	AI-based diagnosis suggestion	Document for future roadmap

The fit-gap report is a spreadsheet with columns:

Requirement ID (e.g., REG-001, OPD-015, BILL-007)
Department
Requirement Description
Priority (Must-Have / Should-Have / Nice-to-Have)
Fit Category
Bio Ecko Module/Screen
Configuration Details or Gap Description
Effort Estimate (for customizations)
Status (Open / Approved / Deferred)

Writing Good Requirements (BRD Format)

A Business Requirement Document (BRD) for each module should include:

Business Context -- Why does this department exist? What is its mission?
Current Process (As-Is) -- Step-by-step current workflow with pain points highlighted
Proposed Process (To-Be) -- Step-by-step Bio Ecko workflow
Functional Requirements -- Specific capabilities needed, written as: 'The system shall [do X] when [condition Y] so that [business outcome Z]'
Business Rules -- Validations, calculations, approval thresholds, auto-triggers
Data Requirements -- What master data is needed, what transactional data is captured, what reports are generated
Integration Requirements -- What data flows to/from other modules or external systems
Non-Functional Requirements -- Performance (page load < 3 seconds), availability (24x7), concurrent users

Example of a well-written requirement:

Bad: 'The system should handle insurance billing'
Good: 'The system shall allow the billing clerk to submit a pre-authorization request to the configured TPA with patient demographics, policy number, diagnosis (ICD-10 code), and estimated cost. The system shall track the pre-auth status (Pending/Approved/Rejected/Query) and alert the billing clerk when the TPA responds.'

Handling Conflicting Requirements

Different departments often have conflicting needs:

Pharmacy wants mandatory doctor authorization for every drug change. Doctors want the flexibility to verbally order changes during emergencies
Billing wants all charges captured before discharge. Nursing wants to discharge the patient quickly and handle billing later
Lab wants 24-hour TAT for routine tests. Doctors want results within 2 hours

FC resolution approach:

Acknowledge both perspectives -- never dismiss a requirement
Quantify the impact -- How often does this scenario occur? Daily? Weekly? Once a month?
Propose a system solution -- Can we have a normal workflow AND an emergency override with audit trail?
Escalate if unresolvable -- Document both positions and present to the Project Sponsor for a decision
Document the decision and the rationale so it does not resurface later

Key principle: The FC is not the decision-maker. The FC presents options with pros/cons. The hospital management decides. The FC documents and implements the decision.

Requirement Prioritization: MoSCoW Method

Not every requirement can be delivered on day one. Use the MoSCoW method:

Priority	Meaning	Go-Live Impact	Example
Must Have	System cannot go live without this	Blocks go-live	Patient registration, OPD billing, prescription
Should Have	Important but has a workaround	Degraded experience	SMS notifications, auto-appointment reminders
Could Have	Desirable but not critical	No impact	Custom dashboard widgets, dark mode
Won't Have	Agreed to defer to a future phase	None	AI-based drug interaction checking, telemedicine

FC rule of thumb: 80% of Must-Haves should be Direct Fit or Config Fit. If more than 20% of Must-Haves are gaps requiring customization, either the product is not a good fit for this hospital, or the requirements need to be re-evaluated.

Always get written sign-off on the prioritized requirement list from the Project Sponsor before starting configuration.

Common Mistakes in Requirement Gathering

Mistakes freshers commonly make:

Taking notes but not validating -- Always read back your understanding to the stakeholder: 'So if I understand correctly, when X happens, you do Y and then Z. Is that right?'
Documenting the solution, not the problem -- Write 'Billing clerk needs to split payment across two modes' not 'Add a split-payment button'
Ignoring edge cases -- Always ask: 'What happens when this goes wrong? What if the patient cannot pay? What if the doctor is not available?'
Not capturing the frequency -- A process that happens 100 times/day needs automation. A process that happens once a month can tolerate a workaround
Forgetting night shift and weekend workflows -- Hospital processes change after hours. ICU billing, emergency pharmacy, night-shift nursing notes all have different patterns
Not involving the actual end users -- HODs describe the ideal process. End users describe the real process. Talk to both

Notes

Tip

Carry a small notebook during shadowing sessions. Taking notes on a laptop creates a barrier between you and the staff. Write quick notes by hand, then type them up the same evening while memories are fresh.

Warning

Never promise a feature during requirement gathering. Always say 'I will check and get back to you.' Premature promises create scope creep and erode trust when you cannot deliver.

Info

For a 200-bed hospital, expect to document 300-500 individual requirements across all departments. Use a spreadsheet with unique IDs from day one -- trying to organize unstructured notes later is a nightmare.