Nurse Informaticist SDLC Role Description Assignment Guide

The deliverable is a **role description**, not an essay about informatics, and getting that genre right is most of the assignment. A role description is a working document: it says what a person is responsible for, what they contribute, whom they work with and what they are accountable for producing. It is written in the second or third person about the post, not in the first person about your opinions, and it can be handed to somebody who would then know what to do. A paper that discusses the importance of nurse involvement in health IT has written an essay with a role description's title on it. Two to three pages across five SDLC phases is roughly half a page each, so the format has to be economical — headed sections with responsibilities set out as statements rather than as prose paragraphs.

The five phases are named in the brief and each must appear: planning and requirements definition, analysis, design of the new system, implementation, and post-implementation support. That list is the structure, and the discipline it imposes is that the nurse's contribution has to be genuinely different in each. If your planning and your analysis paragraphs both say the nurse represents the end user's perspective, one of them is doing no work. Ask what the *output* of each phase is, and what a nurse specifically can contribute to producing it. The phases also differ in who else is in the room, and saying whom the nurse works with at each stage — clinicians, analysts, vendors, trainers, IT support — is what turns a list of responsibilities into a description of a role. Say what the nurse is accountable for at each phase as well as what they contribute, since a responsibility with no deliverable attached to it is an intention rather than a role.

Phase by phase, the contributions that are actually distinctive are worth naming precisely. In **planning and requirements definition** the nurse translates clinical work into requirements and identifies which workflows the system must not break. In **analysis** they validate that documented workflows match what nurses really do, which is frequently not the same thing. In **design** they evaluate screen flow, click burden, terminology and alert logic against bedside reality. In **implementation** they lead testing with real scenarios, plan training and act as the unit's credible voice. In **post-implementation support** they collect what is failing, feed optimisation requests and monitor for unintended consequences. Each of those is a different verb — translate, validate, evaluate, lead, monitor — and using different verbs is a quick way to check that the five sections have not collapsed into one.

The brief's preparation step asks you to consider *benefits and challenges* of involving a nurse leader, and the challenges half is what separates a strong role description from an advocacy document. The real difficulties are concrete: backfill for clinical time, the risk that one nurse's preferences are mistaken for the unit's requirements, the credibility problem when the representative has been away from the bedside for months, and the tension between what clinicians want and what the vendor's product can be configured to do. Acknowledging those inside the role description — as accountabilities, escalation routes or time commitments — is more persuasive than a paragraph listing them. A role that names its own failure modes is one a manager could actually staff, which is the test this document should be written to pass. Say how the role escalates a disagreement too, because the point at which clinical requirements and vendor constraints collide is the moment the post exists for.

Graduate-level is specified and it should visibly change what the role contains. A graduate-prepared nurse on an implementation team is expected to appraise evidence, understand standards and interoperability at least well enough to ask the right questions, evaluate usability systematically rather than by impression, contribute to measurement of outcomes after go-live, and lead rather than only represent. Write responsibilities that a staff nurse could not reasonably be asked to hold, because the level is part of what is being assessed. Include something about evaluating the system's effect after implementation, since post-go-live measurement is the clearest marker of graduate-level contribution and the phase most often written as a support desk. Say what qualifications or experience the post requires while you are at it, since a role description that specifies the level explicitly is more useful than one that implies it through the tasks.

On mechanics the brief is short but two items are checkable. Two to three pages, and *let your citations match your references* — an instruction that appears because mismatched lists are common, so audit both ways before submitting: every in-text citation present in the reference list, every reference cited somewhere in the text. A role description still carries citations in an academic assignment, and the natural places for them are the challenges and the graduate-level responsibilities, where a claim about what nurse involvement achieves needs support. Review the rubric before drafting, since it asks specifically that the description support a graduate-level nurse's participation across the named phases and that is exactly the completeness a marker will check first. Keep the citation density low but real, because a working document loaded with references stops reading as one and the marker is assessing both the genre and the support.