Understanding the landscape and stakeholders
Each country/region implements various health interventions, and with the current SDG focus on people/beneficiary-centric approach, understanding of the landscape in which 'health-related data will circulate, cleaned or modified, utilized for single (screening/diagnosis/treatment/another service) or diverse reasons(Monitoring/Evaluating/Mentoring/Policy Making/Policy Modification/Public Opinion, etc.'.
Avoiding duplication and errors
- In today's era, many digital interventions are happening that the world is not able to keep track of. Duplications of efforts are common and should be tracked before de novo synthesis. Some projects in the past might have proved successful but never got scaled up due to one or the other reason.
- Product development team needs to calculate the resources available at hand (Man, Money, Material, Method and Measurement). SWOT analysis followed by a scientific approach will be critical to ensure the offered product doesn't just meet expectations but also has a scope of sustained use as well as expansion with the capacity to incorporate future developments in a project/program/policy.
- There needs to be a clear understanding among individuals/teams about what needs to be tested to ensure that the software functions properly when completed.
- It is always good to check the existing digital ecosystem and how the product under consideration will be connecting in a seamless manner for better productivity
Collect and Document Requirements
System development demands that expectations and product match. It is essential and one of the first steps to understand and note the requirements.
- It ensures mutual understanding and scope for clarification where needed and allows two parties to work with a unified goal with a crystal clear vision. The time spent on these discussions helps in valuable output i.e. quality software development that can be utilized with or without minor modifications. This helps in reducing friction or conflict in the later stages of development and brings confidence to both parties.
- It also serves as a process for putting down what is in the customer's head and ensuring that the whole team is on the same page with what is to be created.
- In case there are any disagreements or lack of in-house capacity, the exact needs to be addressed as it affects the precious time and product delivery
- Writing details of each component and managing requirements during the course of development is essential because many times policy or program guidelines change and that component might have yet to be included in the initial discussion. Keeping a scope for flexibility and clear cut timelines are essential ingredient for product development.
How to Elicit Requirements
- Introductory meeting: One of the most common methods for eliciting requirements is to conduct interviews or seeking concept note mentioning the purpose for which the digital health intervention is being opted for.
- Stakeholder Consultation: Taking on board all those (including community representative/patients) and engaging them for providing insight into what system should look like and be utilized for. National and State Program Manager at times misses the integrities of the system and that can backfire at later stage. Collect as much details as possible and foresee the challenges or enablers within the system or support that would be needed from higher level.
- Provider Perspective: The level of digital literacy, data entry tools, pros and cons of current system and value addition of digitization should be studied in depth. Who will be affected by the system change and how to gain maximum control over system without compromising the data ailments, quality and security, are essential features.
- Few other methods include
- Creating user stories (Healthcare worker/Patient/Doctor/Lab or pharmacy personnel/Other department personnel with access to health records)
- Scenarios about how the system will be used (Field based/Hospital Based/Other setting)
- Possible cases where the system may not work or work with low output (eg. No internet in hilly regions)
Regardless of the method(s) selected, an iterative approach generally works well. Get input document it and then refine the documentation with more input.
It is also suggested that potential risk, time required and support needed is noted down for a healthy and realistic planning for a successful outcome.
Resources and Templates
Functional Specification Template (with examples).docx - This template can be used to document the expected behavior of the system. It encompasses not only the requirements, but the design of what they system will look like and how it will behave.
Gherkin is also a "language" or a formatted process that is being used to define some feature specifications and requirements. The DHIS2 team is capturing their feature files in GitHub. Example feature file