Mobile App for Agricultural Extension Workers
An agriculture department wants a mobile app for 3,000 field extension workers to record crop disease observations. Requirements gathered in two workshops: workers need offline entry because many villages have no data coverage; photos must be attached; supervisors need dashboards by district; and the department's IT unit must maintain the app after handover. The vendor proposes a 12-month plan with a full requirements document frozen at month two, then build, then a single acceptance test at month twelve. Field workers were not consulted. The budget is fixed, and a pilot in two districts is desired before national rollout.
1. Critique the vendor's process and propose a better one.
Read the worked answer
Freezing requirements at month two with no field-worker input is the central flaw: offline sync, photo size and form length are exactly the details field workers would reveal, and discovering them at month twelve would be catastrophic under a fixed budget. A single acceptance test gives no early feedback. A better process is iterative: a short inception to agree scope and architecture, then two-week iterations delivering working software, with field workers testing on real devices in real coverage conditions from iteration two. Use a pilot in two districts as a formal release gate, with measurable criteria (e.g. sync success rate, time per observation). Keep a prioritised backlog so scope can be traded against the fixed budget rather than the schedule.
2. What are the key technical risks in offline-first design, and how should they be handled?
Read the worked answer
Conflict risk: two workers may edit the same record offline; use server-assigned IDs and last-write-wins with an audit trail, or restrict editing to the creator. Sync risk: large photo uploads over weak networks will fail; compress images, upload in the background with retry and resumable transfer, and never block data entry on upload. Storage risk: low-end phones may run out of space; cap local cache and warn users. Security risk: lost phones may hold sensitive data; encrypt local storage and require a PIN, with remote wipe. Data quality risk: offline validation must match server rules to avoid rejected records. Each risk needs a test in the pilot, not just a design note.
3. How should handover to the department's IT unit be structured?
Read the worked answer
Handover must be a planned workstream, not a final meeting. Require source code in the department's repository with build instructions, architecture and API documentation, a test suite, and a runbook for deployment, backup and incident response. Pair department developers with vendor developers for at least the last two iterations so knowledge transfers through work, not slides. Include training for supervisors on dashboards and for IT on operations. Define warranty and support terms after go-live. Acceptance should include the department successfully deploying a minor change unaided - that is the real test of maintainability.