Section 2: The Requirements Phase (Gathering & Analysis)

9.2.1 The “Why”: The Most Expensive Mistake in Healthcare IT

In pharmacy, you understand the concept of leverage. A single, well-designed intervention—like adding a forcing function for an allergy check—can prevent thousands of potential errors downstream. The requirements phase of the SDLC is the point of maximum leverage in all of software development. A mistake made here is the most costly and dangerous mistake you can make. An error in coding can be fixed. A server can be upgraded. But a fundamental misunderstanding of the clinical need, baked into the foundation of the project, can lead to the development of a product that is, at best, useless, and at worst, actively harmful to patients.

Consider the exponential cost of fixing an error based on when it is discovered. A missed requirement identified during a planning meeting is a simple correction in a Word document. That same missed requirement, if discovered after the software has been coded, now requires developers to rewrite code, database architects to potentially restructure tables, and QA testers to re-run all their test scripts. If that error is not discovered until after the software has been deployed across the entire health system, the cost can be astronomical—not just in dollars for the emergency patch, but in the cost of retraining thousands of users and, most importantly, in the potential for patient harm that occurred while the flaw was live. The requirements phase is your primary opportunity to prevent these catastrophic failures. It is the most important patient safety work you will do in your informatics career.

9.2.2 The Analyst’s Toolkit: Masterclass in Gathering Techniques

Effective requirements gathering is not a passive activity. You cannot simply ask users “What do you want?” and expect a useful answer. Users are experts in their own workflows but often cannot articulate the underlying needs or imagine a better way of doing things. Your job is to be a clinical detective, using a variety of techniques to uncover the true problems that need to be solved and the opportunities for improvement.

Technique 1: The Stakeholder Interview

The one-on-one interview is the cornerstone of requirements gathering. It is a structured conversation with a specific goal: to understand a stakeholder’s role, their pain points, their processes, and their vision of a better future state. The key is to ask “why” five times. Don’t just accept a feature request at face value; dig deeper to understand the root problem.

Masterclass Table: The Art of the Interview Question

Question Type	Purpose	Pharmacist Example
Open-Ended	To start a conversation and understand the big picture.	“Can you walk me through your process for verifying a chemotherapy order from start to finish?”
Probing / “Tell Me More”	To dig deeper into a specific area and uncover details.	“You mentioned that calculating the body surface area is a frustrating step. Can you tell me more about what makes it frustrating?”
Clarifying	To remove ambiguity and confirm your understanding.	“So, if I understand you correctly, you need the system to alert you if a dose exceeds the lifetime maximum for doxorubicin, but not for other anthracyclines. Is that right?”
Pain Point Identification	To directly uncover inefficiencies or risks.	“What is the single most time-consuming or error-prone part of managing TPN orders today?”
“Magic Wand”	To encourage creative thinking and uncover unmet needs.	“If you could wave a magic wand and change anything about how the EHR handles sterile compounding, what would you change?”

Technique 2: Workflow Observation (Gemba Walks)

What people say they do and what they actually do are often two different things. Years of workarounds, shortcuts, and tribal knowledge create a “real” workflow that is invisible to anyone just looking at a process diagram. A Gemba walk, from the Japanese for “the real place,” means you physically go to the pharmacy, the nursing unit, or the clinic to observe the work as it happens, in its real context. This is where you will discover the sticky notes with crucial passwords, the unofficial paper logs used to track missing doses, and the five clicks it takes a nurse to find a PRN pain medication on the MAR. These observations are pure gold for requirements gathering.

Technique 3: Document Analysis

Your organization is filled with documents that describe the “official” way things are supposed to work. Your role is to gather and analyze these artifacts to understand the formal rules that any new system must adhere to. This includes:

• Policies & Procedures (P&Ps): These define the official, approved workflows and clinical rules. A new system cannot violate an existing P&P.
• Regulatory Guidelines: You must analyze documents from The Joint Commission, CMS, DEA, and your state’s Board of Pharmacy to ensure your new system will be compliant.
• Existing Forms and Reports: What data is currently being captured on paper? What reports are managers running? These provide a rich source of data element requirements for the new system.

9.2.3 From Conversation to Specification: Documenting Requirements

After you’ve conducted your interviews and observations, you will have a mountain of raw data. The next critical step is to analyze and synthesize this information into a structured, formal document that the technical team can use to build the software. The format of this document will depend on whether your project is using a Waterfall or Agile methodology.

Functional vs. Non-Functional Requirements: The “What” and the “How Well”

All requirements can be broken down into two fundamental types:

• Functional Requirements: These define what the system must do. They describe a specific behavior or function. For example: “The system shall calculate a patient’s creatinine clearance.”
• Non-Functional Requirements (NFRs): These define how well the system must perform its functions. They describe the qualities of the system, such as its performance, security, and reliability. For example: “The creatinine clearance calculation shall be displayed to the user in less than 2 seconds.” NFRs are often overlooked but are critically important for user adoption and safety. A system that is functionally perfect but takes 30 seconds to load a patient’s profile is a failed system.

Masterclass Table: Types of Non-Functional Requirements

Category	Description	Pharmacist-Centric Example
Performance	How fast the system operates under specific loads.	“The system shall process a batch verification of 100 medication orders in under 60 seconds.”
Security	How the system protects against unauthorized access.	“The system shall require two-factor authentication for any user accessing the controlled substance administration module from outside the hospital’s network.”
Reliability / Availability	The uptime and operational stability of the system.	“The BCMA system shall have an uptime of 99.99% (‘four nines’), with no more than 52 minutes of unplanned downtime per year.”
Usability	How easy and intuitive the system is to use.	“A new pharmacist with one hour of training shall be able to successfully verify a standard IV admixture order in under 90 seconds.”
Scalability	The system’s ability to handle growing amounts of work.	“The system must be able to support up to 500 pharmacists verifying orders concurrently without a degradation in performance.”

Documentation for Waterfall: The Business Requirements Document (BRD)

In a Waterfall project, the BRD is the definitive source of truth. It is a highly detailed, formal document that attempts to capture every single requirement before design begins. Writing a good BRD is a skill in itself. Each requirement must be:

• Atomic: It should describe a single, discrete piece of functionality.
• Unambiguous: It should be written in clear, simple language that can only be interpreted one way. Avoid words like “fast,” “easy,” or “user-friendly.”
• Testable (Verifiable): There must be an objective way to prove that the requirement has been met.
• Necessary: The requirement must be traceable back to a specific clinical or business need.

Documentation for Agile: User Stories & The Product Backlog

Agile teams reject the idea of a massive upfront BRD. Instead, they manage requirements as a prioritized list of “User Stories” in the Product Backlog. A user story is a short, simple description of a feature told from the perspective of the person who desires the new capability. The standard format is:

“As a <type of user>, I want <some goal> so that <some reason>.”

The power of this format is that it forces the team to focus on the user and the value the feature provides, rather than just the feature itself. It shifts the conversation from “what we are building” to “who we are building it for and why.”

Masterclass Table: Writing Effective Pharmacy User Stories

Poorly Written Story	Well-Written User Story	Why It’s Better
“The system needs a CrCl calculator.”	“As a clinical pharmacist, I want to view a system-calculated CrCl on the patient’s profile so that I can accurately dose-adjust renal medications without manual calculation.”	It explains the “who” (pharmacist), the “what” (view a calculated CrCl), and the “why” (accurate dosing, efficiency). This context is critical for developers.
“Add a hard stop for allergies.”	“As a dispensing pharmacist, I want the system to prevent me from verifying an order if the patient has a documented allergy to the medication class so that I do not accidentally dispense a drug that could cause an anaphylactic reaction.”	It specifies the user (dispensing pharmacist), the trigger (allergy to class), the action (prevent verification), and the critical safety reason (prevent anaphylaxis).

Acceptance Criteria: The Definition of “Done”

A user story is not complete on its own. It must be paired with a set of **Acceptance Criteria**. These are the conditions that the software must satisfy to be considered complete. They are the objective, testable details that accompany the story. A common format for writing acceptance criteria is the Gherkin “Given-When-Then” syntax.

9.2.4 The Art of Prioritization: Building the Right Thing First

Once you have a list of requirements, whether it’s a 500-page BRD or a backlog of 200 user stories, you are faced with a hard reality: you can’t have everything at once. Resources, time, and money are finite. Prioritization is the process of deciding what is most important to build first. As the clinical leader on the team, your voice is paramount in this process. Your job is to ensure the team is always working on the features that deliver the most clinical value and mitigate the most patient safety risk.

Prioritization Technique 1: The MoSCoW Method

The MoSCoW method is a simple but powerful technique for categorizing requirements into four buckets:

• M – Must-Have: These are non-negotiable requirements. The system cannot go live without them. They are often tied to core functionality, safety, or regulatory compliance.
• S – Should-Have: These are important requirements that are not critical for launch. The system would be much better with them, but it can still function without them.
• C – Could-Have: These are desirable “nice-to-have” features that would improve the user experience but have a smaller impact than “Should-Haves.” They are the first to be cut if timelines are threatened.
• W – Won’t-Have (This Time): These are requirements that have been explicitly acknowledged but are agreed to be out of scope for the current project or release.

Prioritization Technique 2: Value vs. Effort Matrix

This technique forces a conversation about both the clinical benefit and the technical cost of a feature. By plotting each requirement on a 2×2 grid, you can quickly identify the most strategic items to work on.

9.2.5 Conclusion: The Architect of Clinical Safety

The requirements phase is where your identity as a pharmacist provides the most profound value to the software development process. A business analyst can gather business needs. A project manager can track timelines. But only you can look at a proposed feature and see the potential for a “look-alike, sound-alike” error. Only you can listen to a workflow description and identify the hidden risk of a missed dose. Only you can translate a vague request for “better CDS” into a precise, testable requirement for a DDI alert that fires for a specific drug combination, but only when the patient’s potassium is above a certain threshold.

This phase is not about technology; it’s about clinical practice, patient safety, and workflow excellence. Your mastery of the techniques in this section—the art of the interview, the discipline of observation, the precision of documentation, and the strategy of prioritization—transforms you from a user of technology into its architect. A well-written requirement is a vote for patient safety, cast in stone at the very foundation of the project. It is the most powerful tool you have to ensure that the systems you help build will protect patients and empower your clinical colleagues for years to come.