From a Clinical Need to a Testable Use Case
A dosing service can produce a mathematically valid result and still fail to meet the clinical need. It may be invoked for the wrong decision, omit information the clinician needs, or return a recommendation in a situation outside its intended scope. A use-case specification makes these boundaries explicit: who uses the service, what prompts its use, what information it needs, what it returns, and how a reviewer can determine whether the specified behavior occurred.
The earlier material on Mapping the Clinical Workflow for Precision Dosing helps locate the service within clinical practice. A use-case specification turns a selected point in that workflow into a bounded statement of required behavior. It does not, by itself, establish that a dosing model is clinically valid or that a recommendation is safe for every patient.
The specification should describe the clinical service, not jump straight to a screen design or a model formula. For a precision-dosing service, a useful use case identifies the clinical decision being supported and the point at which the user requests support. It then names the required information and the response the user must receive. These statements help developers, clinicians, and testers agree on what the service is expected to do.
The Parts of a Testable Specification
A complete specification makes several distinct questions answerable. The intended user might be a pharmacist reviewing a proposed regimen; the trigger might be a scheduled dose review. Required inputs are the information needed for that particular decision. Outputs describe what the service returns, including whether it provides a recommendation or indicates that it cannot do so. Operating conditions state where, when, and for whom the use case is intended. Exclusions name circumstances in which the service is not intended to provide the specified recommendation.
Avoid defining scope with words such as “typical patient” or “appropriate information.” Replace them with observable boundaries. For example, “adult patients aged 18 years and older” has a checkable boundary, while “adult patients” may not clarify how the service handles a patient exactly 18 years old. Similarly, “respond promptly” is not an acceptance criterion until the response time and the conditions under which it is measured are stated.
Inputs and outputs belong to the use case, but a use case is not a full data dictionary, interface specification, or model implementation plan. It can name the information required for a decision without defining every data mapping or technical exchange. Those details can be specified separately. Here the test is whether the use case gives a reviewer enough information to construct a scenario and determine what result or behavior is expected.
Name the clinical question the service supports and identify the intended user and trigger.
List required inputs, outputs, operating conditions, and exclusions for that decision.
For each requirement, state a scenario and a result that a tester can verify.
Acceptance Criteria: From Ambition to Observable Behavior
Phrases such as “accurate,” “safe,” and “easy to use” express important goals, but they are not independently testable. A criterion needs a defined scenario, an observable outcome, and—when the outcome is quantitative—a threshold and unit. “The service is fast” can become “each request returns the specified result or status within 30 seconds under the stated test conditions.” “The dose is appropriate” needs a named reference result or a precisely stated rule against which the output can be compared.
A compact way to express a check is to define \(c\) as a test scenario, \(O(c)\) as the observed system response, and \(A(c)\) as the set of responses permitted by the criterion. The scenario passes exactly when the observed response belongs to that permitted set:
This is a simple test definition, not a claim about the clinical correctness of the permitted responses. The important discipline is that the response set is decided before the test result is observed. If an expected recommendation is 750 mg every 12 hours, for example, the specification must say whether the test requires that exact regimen or allows a stated tolerance. Otherwise, reviewers can disagree after seeing the output about whether it “looks close enough.”
Worked Example: Specifying an Adult Dose-Review Use Case
Hypothetical scenario. A fictional medicine, Drug X, has a point-of-care service used by a pharmacist to review an adult patient’s current regimen after a measured trough is available. For this example only, assume that the approved reference case specifies a recommendation of 750 mg every 12 hours for the particular test inputs. This is a test fixture, not a clinical dosing rule.
Trigger and user. The use case begins when an authorized pharmacist requests a review of the current Drug X regimen for a patient aged 18 years or older.
Inputs and operating conditions. The test scenario supplies age, current dose and interval, the measured trough concentration with its unit, and the fictional reference-case identifier. Assume all required inputs are present and within the scope defined for this example. The use case applies only to adults being reviewed for the specified routine dose decision.
Output. The service returns a recommended dose and interval, or a stated no-recommendation status. For this reference case, the expected output is 750 mg every 12 hours.
Acceptance criterion. Given the specified scenario, the returned recommendation must be exactly 750 mg every 12 hours. A response of 750 mg every 24 hours fails because the interval differs; a no-recommendation status also fails for this in-scope test case. The criterion is unambiguous because both the amount and interval are checked.
This example also shows why a use case should distinguish the intended clinical decision from the reference value used in a test. The test can establish whether the service returns the specified response for this scenario. It does not establish, on its own, that 750 mg every 12 hours is appropriate for every patient with similar inputs.
Specify Exclusions and Safe Non-Completion
A testable use case describes not only what the service does when the request is in scope, but also what happens outside the scope. An exclusion should name the condition that puts the case outside scope and the required response. “Do not use in complex cases” is too vague: neither the boundary nor the expected behavior is stated. A more useful exclusion names a condition and says whether the system must return a no-recommendation status, direct the user to an alternative process, or take another defined action.
Do not treat an exclusion as an untested footnote. For each important boundary, create at least one test scenario on the excluded side and, where useful, a boundary scenario on the included side. This makes the rule checkable and helps identify accidental expansion of the intended population. The specification should also state whether the system is expected to explain why it did not provide a recommendation; if so, the explanation must be described in observable terms.
Worked Example: Testing an Age Exclusion
Hypothetical scope. A fictional service is intended to support a particular adult dosing use case for patients aged 18 years or older. The specification explicitly excludes patients younger than 18 years from that use case. It requires a no-recommendation status and the message “Outside the intended age range” for an excluded patient.
Excluded test case. The test supplies an age of 17 years and otherwise complete, in-scope example inputs. The expected behavior is no dose recommendation and the specified message. If the service instead returns a dose, it fails the exclusion criterion even if the dose appears plausible.
Boundary test case. A second test supplies an age of 18 years with the same otherwise in-scope conditions. Because the stated boundary includes age 18, the age criterion alone must not trigger the exclusion. The expected behavior is the ordinary in-scope behavior for the supplied reference case.
The two cases test both sides of the boundary: 17 is excluded, while 18 is included. This checks the written scope rather than relying on an informal interpretation of “adult.” Other exclusions would need their own conditions and expected responses; passing these age tests does not establish that every exclusion has been implemented correctly.
Operational Conditions and Measurable Service Criteria
A use case can include operational requirements when they affect whether the user can complete the intended task. These requirements should specify the test conditions as well as the result. Response time, for example, depends on what is measured and under what workload. State the start and stop events, the time limit, and the test environment or workload relevant to the requirement. Otherwise, different reviewers may measure different intervals or run incomparable tests.
Similarly, a user-facing output requirement should say what must be visible or recorded for the task. “Show the recommendation clearly” is open to interpretation. A more testable statement might require the dose amount, administration interval, and a recommendation status to appear together in the result presented to the user. Visual design still requires judgment, but the presence and correctness of required information can be checked directly.
Worked Example: Writing a Response-Time Criterion
Hypothetical scenario. A fictional dosing service is intended for use during a pharmacist’s point-of-care review. The operating requirement is that the service return either a recommendation or a no-recommendation status within 30 seconds of the user submitting a complete request.
Test conditions. Run 20 complete test requests in the stated test environment. For each request, start the timer at submission and stop it when the complete response is available to the user. Record elapsed time in seconds.
Acceptance criterion. Every one of the 20 requests must return its complete response in 30 seconds or less. If 19 responses take 28 seconds and the twentieth takes 31 seconds, the use case fails this criterion: one observed response exceeds the specified limit. The criterion does not assert that 30 seconds is a universally appropriate clinical threshold; that threshold must be selected and approved for the intended service.
The fixed start and stop events prevent a tester from timing only the calculation while another times the entire user-visible interaction. Stating the test environment also makes the result interpretable rather than presenting a response time without its conditions.
Common Failure Modes and Alternatives
A concise use case is useful only if it remains precise. Common weaknesses include describing an aspiration instead of a requirement, leaving boundary cases implicit, and stating an output without saying what makes it acceptable. A requirement such as “recommend a safe dose” cannot be verified until “safe” is tied to an approved criterion and a test scenario. A requirement such as “support pharmacists” is incomplete until the relevant pharmacist task and expected system response are stated.
- Vague inputs: “Use patient information” does not say what is required for the decision. Name the information required by this use case, without attempting to define unrelated technical details.
- Unbounded population: “For adults” may leave the boundary unclear. State the rule that determines inclusion, and test a case at that boundary.
- Unspecified failure response: If the system cannot provide a recommendation in an excluded scenario, state what it must return instead.
- Unmeasurable acceptance: “Accurate and timely” needs a defined comparison and a threshold with units and conditions.
- Changing the criterion after testing: Decide in advance what outputs pass. Otherwise, the result is vulnerable to post hoc judgment.
A use-case specification is not the only way to document requirements. A workflow diagram can show sequence and handoffs, but may leave input boundaries and pass/fail rules unstated. A user story can capture a user’s goal compactly, but often needs accompanying acceptance criteria to support testing. A detailed technical requirement can specify implementation behavior more narrowly, but may obscure the clinical task if written without a clear use-case context. These approaches can complement one another; none replaces a testable statement of the intended behavior.
Use-case testing also has limits. Passing a finite set of scenarios shows that the observed behavior met the written criteria for those scenarios. It does not prove that all possible inputs, workflows, or clinical situations are safe, and it does not independently establish model validity. The quality of the tests depends on the quality of the specification, the relevance of the scenarios, and the authority of the reference expectations. A precise but clinically inappropriate criterion can be implemented perfectly and still lead to an inappropriate service.
Check Your Understanding
Answer each question by applying the specification principles above. The solutions follow the questions.
- A requirement says, “The service should respond quickly.” What additional information would make it testable?
- A use case includes patients aged 18 years and older. What two ages make useful tests of the stated boundary, and what should each test check?
- A reference test expects 500 mg every 8 hours. The service returns 500 mg every 12 hours. Does it pass if the criterion requires an exact regimen match? Explain.
- Why does a passing test of an expected dose not prove that the dose is clinically appropriate for all patients?
- Name one way a workflow diagram can complement a use-case specification and one reason it may not replace acceptance criteria.
Solutions. (1) State the event that starts timing, the event that ends timing, the maximum elapsed time with units, and the conditions or workload for the test. (2) Test age 17, which must trigger the stated out-of-scope behavior, and age 18, which must not be excluded by the age rule alone. (3) No. The amount matches, but the interval differs from the exact expected regimen. (4) The test checks only whether one scenario produced the specified output; it neither covers every possible patient nor establishes that the reference expectation is clinically valid. (5) A workflow diagram can show task order or handoffs. It may not define a measurable expected result for each scenario, so acceptance criteria are still needed to determine pass or fail.