Must-Have Everything in a Cold-Chain Logistics Platform

An all-Must backlog is not a prioritization; it is a symptom that the stakeholders have not agreed on decision criteria. MoSCoW only works when 'Must' means non-negotiable for the release, typically a legal or regulatory obligation or a failure that makes the product unusable, not 'important to me.' The analyst should first separate mandatory constraints from desirable capabilities: for each of the 87 requirements, capture rationale, source, and the consequence of omitting it from this release. Then facilitate a session with the sponsor, quality unit, and operations to agree on criteria: regulatory compliance, patient safety, revenue protection, operational cost, and risk. Use a technique such as weighted scoring or cost-of-delay to rank requirements against those criteria, and record the decision and dissent. Because 26 requirements lack acceptance criteria, add a definition-of-ready rule: no requirement enters the release baseline without a testable acceptance criterion. The immediate output is not a final cut but an evidence-based shortlist and a list of true constraints the sponsor cannot waive.

First test whether the conflict is real. 'Real-time every 30 seconds' and 'offline for 8 hours' can coexist if the device samples every 30 seconds, buffers readings locally, and forwards them when connectivity returns, provided the regulatory obligation is about data completeness, not instantaneous transmission. The analyst should clarify the underlying need: what decision does the quality unit make with 30-second data, and what happens if data arrives 10 minutes late? Then define operational modes: online, degraded (buffering), and offline. Specify maximum acceptable data loss, maximum buffering duration, timestamp accuracy, and reconciliation rules. If the regulator truly requires live telemetry for certain vaccine types, the offline requirement must be scoped to non-critical shipments or to read-only local operation. Resolve it with a decision record that states the chosen mode, the rationale, and the acceptance tests. Do not average the two requirements into 'near-real-time'; that hides the operational risk and is untestable.

Extend the traceability matrix upward: link each requirement to a business goal, regulatory obligation, or stakeholder need, and downward to design, test, and release. Use stable identifiers and record the link type (derives, satisfies, verifies). Start with the 87 requirements, but do not attempt a perfect matrix in one pass; prioritize the 20 requirements with the highest safety or regulatory exposure and the two conflicting telemetry requirements. Add a rationale field and an owner. Then use the matrix in the next prioritization workshop: a requirement with no upstream goal is a candidate for deletion or challenge; a goal with no requirement is a coverage gap. For change impact, a proposed change can be traced to affected goals and tests. Keep the matrix under configuration control and review it at each baseline. The benefit is not documentation for its own sake; it is the ability to defend a 'no' to the sponsor with evidence.