Client Deliverable Package
Sample — fictional data
1 · RFP-Ready Requirements Draft (excerpt — 1 of the sample’s 8 user needs · 2 of its 15 requirements)
Vendor-neutral, prioritized (Must / Should / Could), structured to drop straight into your RFP.
The anatomy every requirement follows — this structure is the deliverable’s point. I spent years on the vendor side answering lab RFPs, and they arrive as a duplicated mix of user needs and requirements — with on-prem questions sent to cloud products. This format exists so vendors can answer precisely and responses score cleanly:
- User need — the outcome the lab must have, stated once; every requirement traces up to exactly one
- ID — stable and citable, in the RFP and in vendor responses; atomic — one testable assertion per ID, so “partial comply” is never ambiguous
- Priority — Must / Should / Could, with the rationale stated rather than assumed
- Statement — “The system shall …”, vendor-neutral; priority lives in the tag, never the verb
- Who — the department(s) whose work depends on it
- Testable acceptance — Given / When / Then, so vendor claims can be verified in demos and UAT instead of taken on faith
- Source — the named interview or document it traces to; the source column is not optional
UN-01 · [User need · Accessioning] — Every specimen must be positively identified from the moment it enters the lab — chain-of-custody depends on it.
Source: Interview — Accessioning Supervisor.
Source: Interview — Accessioning Supervisor.
REQ-001a · [Must] The system shall assign a unique, human-readable accession identifier to each specimen at accessioning.
User need: UN-01. Who: Accessioning. Testable acceptance: Given a new specimen, when accessioned, then a unique identifier is generated. Priority rationale: accession identity underpins chain-of-custody; ambiguity causes mislabeled results.
User need: UN-01. Who: Accessioning. Testable acceptance: Given a new specimen, when accessioned, then a unique identifier is generated. Priority rationale: accession identity underpins chain-of-custody; ambiguity causes mislabeled results.
REQ-001b · [Must] The system shall print scannable barcode labels bearing the accession identifier at the accessioning workstation.
User need: UN-01. Who: Accessioning. Testable acceptance: Given an accessioned specimen, when labels are requested, then scannable barcodes bearing its identifier print. Priority rationale: unlabeled specimens break downstream scanning and tracking.
User need: UN-01. Who: Accessioning. Testable acceptance: Given an accessioned specimen, when labels are requested, then scannable barcodes bearing its identifier print. Priority rationale: unlabeled specimens break downstream scanning and tracking.
One need, decomposed into individually scoreable shall-statements — a vendor answers each on its own, and a lab scores each on its own. This was one compound “requirement” before the decomposition; an “and” in a requirement is two requirements.
… 7 further user needs and 13 further requirements across seven categories: sample management, order management, workflow, integration, compliance, reporting, and billing.
3 · Requirements Conflict Register (excerpt — top 3 of the sample’s 4 entries)
Where department requirements collide or trade off — each flagged with severity and the decision to settle before the RFP goes out, while it is still cheap to resolve.
| ID | Departments | Conflict | Severity | Decision needed |
|---|---|---|---|---|
| CON-001 | QA vs. Bench/IT | QA requires immutable 7-yr on-prem audit retention; bench/IT favor vendor-hosted instrument integration where standard log rotation is 3 years. | High | Confirm the regulated retention period and hosting model with QA/RA before issuing the RFP. |
| CON-002 | Accessioning vs. Billing | Accessioning wants fast walk-in order entry; Billing wants a mandatory eligibility check before accessioning, which slows intake. | Medium | Decide whether eligibility is a hard gate at accessioning or an asynchronous background check. |
| CON-003 | Bioinformatics vs. QA | Bioinformatics wants auto-release of low-complexity variant calls to speed turnaround; QA requires manual sign-out on all reportable variants. | High | Set the auto-release policy with QA and the Medical Director’s approval. |
… 1 further conflict in the full register — every entry carries a named owner and status.
The full package — five deliverables, plus the workbook behind them
What a complete E1 engagement delivers. The two sections excerpted above are shown in part; the rest is walked through on the discovery call.
- RFP-Ready Requirements Draft — vendor-neutral, atomic, testable, every requirement traced to a user need, across all seven categories · excerpted above
- Cross-Department Requirements Map — what each function needs from the system: lab operations, IT, quality/compliance, finance, clinical
- Requirements Conflict Register — where department needs collide, with severity, owner, and the decision to settle pre-RFP · excerpted above
- Vendor Evaluation Criteria — a weighted scoring framework aligned to the prioritized requirements, ready to score RFP responses
- Requirements Assumptions Register — the unstated assumptions each department is making about what the system or vendor will do
Plus the engagement workbook — every requirement, conflict, criterion, and assumption traces to at least one named source (“the Source ref column is not optional”), and the workbook is machine-checked for internal consistency before anything is delivered.
SAMPLE — fictional data · HelixWrks LLC · This excerpt shows parts of 2 of the package’s 5 deliverables.