Halfway through the session the course turns from describing what exists to specifying what is needed. NR-543 Week 4 sits in the analysis phase of the system life cycle, and the written work is a needs assessment with requirements attached: a gap argued from the current-state map, stakeholders identified with what each one actually needs from the information, and requirements written so precisely that someone could later test whether they were met. Your section may print this as NR 543 or NR543; it is the same course. Chamberlain publishes no syllabi outside Canvas. The placement here is our teaching judgment from the course's catalog arc; your section's rubric decides what your week actually asks.
What NR-543 Week 4 asks for
A requirement is a testable statement about what a system or a redesigned process must do. That definition does a lot of work. It rules out preferences, it rules out product names, and it rules out anything phrased so loosely that two reasonable people would disagree about whether it had been satisfied. If a med-surg unit needs the last three daily weights visible on the screen where the diuretic order is placed, that is a requirement: a reader can check it. If the unit needs better visibility of trends, that is a wish, and no build or process change can be verified against it.
The stage also introduces the distinction between functional and non-functional requirements. Functional requirements say what the system must do: display, calculate, transmit, alert, restrict. Non-functional requirements say how well it must do it and under what constraints: how quickly the telehealth reading must appear after transmission, how many concurrent users the process must support at shift change, what must remain available when the network does not, what access rules must hold. Students routinely write eight functional requirements and none of the second kind, and the second kind is where real implementations fail.
Stakeholder analysis is the other half. The people who touch the workflow are not the only people with a stake in it, and each stakeholder group needs something different from the same information. The bedside nurse needs it visible without extra clicks in the middle of a task. The prescriber needs it trended. The unit manager needs it aggregated by month. Compliance needs it attributable. Writing those needs separately, then showing where they conflict, is the analysis the rubric is looking for, because a design that satisfies everyone equally usually satisfies no one operationally.
Typical deliverables are a needs assessment paper, a requirements table or matrix, or both, sometimes with a stakeholder map. If a discussion runs alongside, keep the post specific and final; posts do not reopen after submission in Canvas.
The NR-543 Week 4 method, step by step
Six moves for turning a mapped problem into testable requirements.
-
1. Restate the gap in one measurable sentence
Current state, desired state, and the unit of difference between them. If the sentence does not contain something countable, the requirements that follow will not be testable either, because there is nothing for them to close.
-
2. Enumerate stakeholders by what they need, not by their titles
For each group, write one sentence naming the information they need, the moment they need it, and the decision it supports. Titles alone produce a list; needs produce an analysis a grader can score.
-
3. Surface the conflicts between those needs explicitly
Completeness fights speed, structure fights expressiveness, access fights privacy. Name at least one real tension in your own workflow and say which side you would favour and on what grounds.
-
4. Draft each requirement in the shall form with a testable object
The system shall display the three most recent recorded weights on the order entry screen. One requirement per sentence, no conjunctions hiding a second requirement, and no vendor or product named anywhere in the statement.
-
5. Split functional from non-functional and fill the gap
Sort what you have written into the two categories, then deliberately write the missing non-functional set: timing, availability, capacity, access control and what must happen during downtime. That set is the mark of a graduate submission.
-
6. Rank the requirements and say what you deferred
Essential, important, desirable. Then name two or three things you consciously moved out of scope. A prioritized list with visible deferrals shows judgment; an unranked list of twenty items shows collection.
A layout and word budget for a needs assessment with requirements
Our frame for an analysis-phase submission, sized for roughly 1,200 to 1,500 words plus the requirements table. It is our outline rather than anything the university issues, and your week's rubric outranks it wherever they disagree.
| Section | What belongs in it | Word target |
|---|---|---|
| Gap statement | Current state, desired state and the measurable distance between them, drawn straight from the current-state map. | 130 to 170 |
| Stakeholder needs | Each group with the information it needs, the moment of need, and the decision it supports, one paragraph per group. | 280 to 340 |
| Conflicts and trade-offs | At least two tensions between stakeholder needs, with the position you take and the reasoning behind it. | 200 to 250 |
| Functional requirements | Testable shall statements covering capture, display, transmission and access, presented in a numbered table. | 230 to 290 |
| Non-functional requirements | Timing, availability, capacity, security and downtime behaviour, each stated as a condition someone could verify. | 200 to 260 |
| Priorities and exclusions | The ranking you applied, the criterion behind it, and what you deliberately deferred out of this scope. | 140 to 180 |
Evidence craft for requirements writing
Anchor the analysis phase in a named life cycle model. System life cycle frameworks are published, they differ in how they divide the phases, and naming the one you are using with its source lets a grader read your structure against a standard instead of against their own assumption.
Attribute every stakeholder need to how you learned it. Told to me in a unit meeting, observed during three shifts, and inferred from the workflow map are three different strengths of claim. Marking which is which is the rigor the analysis row is scoring.
Keep vendors out of requirements and into a later stage. The moment a product name appears inside a shall statement, the requirement has become a purchase decision and the analysis phase has been skipped. Selection belongs to the design stage, and doing it in order is itself graded.
Use published evidence to justify the thresholds you set. If you require a reading to be visible within a stated interval, say what makes that interval clinically meaningful and cite something that supports it. Numbers invented for the paper are visible to any grader who reads carefully.
Write regulatory and privacy constraints as requirements, not as background. Access, audit and retention obligations shape what any design may do. Folding them into the non-functional list turns compliance from a paragraph of context into part of the specification.
Five mistakes that cost points in this week's territory
- Requirements phrased as improvements. Streamline, enhance and improve cannot be tested. If nobody could design an acceptance check for the sentence, it is not yet a requirement.
- A stakeholder list with no needs attached. Naming six roles is inventory. Saying what each needs, when, and for which decision is analysis.
- Only functional requirements. Timing, availability, capacity, security and downtime are where implementations actually break, and their absence is conspicuous at graduate level.
- Two requirements in one sentence. Anything joined by and cannot be verified as a unit, and a compound statement half met is a dispute waiting to happen.
- Choosing a product before specifying the need. Naming the system you already prefer inverts the life cycle, and the inversion is exactly what this stage is testing.
Before you submit
- The gap sentence contains something countable
- Each stakeholder group has a stated need, a moment and a decision
- At least two genuine conflicts between needs are named and adjudicated
- Every requirement is a single testable statement with no conjunction hiding a second
- Non-functional requirements cover timing, availability, access and downtime
- No product or vendor is named inside any requirement
- The ranking criterion is stated and the deferred items are visible
Writing requirements for NR-543?
Send the rubric and your current-state map out of Canvas. A premium original draft comes back in 24 to 48 hours with every requirement written as a testable statement and the non-functional set complete, and revisions run until the grade lands.