Software in Medical Devices, by MD101 Consulting

When user-stories are not software requirements

This is the first choice. User stories are not software requirements. What are they, then?
Obscure answer for software development engineers: they can be seen as micro change requests!
Non-obscure answer: they can be seen as bribes of requirements, which will be used to instanciate new requirements and/or to update existing requirements.
Example:

• REQ1: The software shall display the images in true colors or inverted colors.
• REQ2: The control panel shall contain a checkbox to activate the inverted colors mode.

Here comes a new user story:

• As a user, I want to display the images in grey scale or in black and white.

We have to update our existing requirements to:

• REQ1: The software shall display the images in true colors, inverted colors, grey scale or black and white,
• REQ2: The control panel shall contain a combo box to choose the display modes found in REQ1.

The advantage of this method is to remain in the beaten track of software requirement specifications, as they're expected by regulatory reviewers.
The drawback is, well, to be less agile than managing user stories.

When user-stories are software requirements

This is the second choice. User stories are software requirements.
The formalism of user-stories matches well with the expectations on software requirements: As <a persona>, I want to <do something> so that I can <get a benefit>.
This formalism allows to express requirements in terms that avoid ambiguity and allows to establish acceptance tests criteria.

Non-functional requirements

At first sight, some categories of software requirements, the non-functional requirements (NFR) cannot be easily worded as user-stories (US). Fortunately, there's a solution: using persona who get a benefit from these NFRs.
Example 1:

• NFR: The system shall be able to export data in HL7 format,
• US : As a user of a LIMS, I want to receive data in HL7 format, so that I can display and store data from your system.

Example 2:

• NFR: The system shall be updated from binary images stored remotely in a secure manner,
• US : As an IT administrator, I want to update the software from the software vendor server, so that I can have an up-to-date version without requiring the intervention of the software vendor technical support.

Example 3:

• NFR: The AI algorithm shall have a false positive rate of maximum 5%,
• US: As a doctor, I want to have a false positive rate of maximum 5%, so that I can be confident enough with the system.

This looks sometimes a bit far-fetched, but that's the price of respecting the user-story formalism.
Remark: the US formalism adds some more information in the "so that" part. This additional information is noteworthy!
Corollary Remark: for people fond of clinical validation, you see in the third example how the US draws a direct link with the clinical performance!

Absence of contradiction

Another difficulty is hidden in the flow of user-stories coming into the sprints:

• A first user story requires "A"
• A second a few sprints later, requires "A prime", not to far from "A" (that's OK),
• And a third one, a few other sprints later, might require "B". After analysis, "B" is equivalent to "not A if ZZZ".

So collecting the user stories is not enough to make a set of software requirements. It's necessary to perform some sanity checks on new user stories, to ensure that they don't contradict one another.
Implementing new user-stories requires refactoring of the existing code. Likewise, adding new user-stories requires refactoring of the existing user stories.

With these sanity checks, we come back more or less to the first choice. There's no miracle. A work of consolidation is required to make our software requirements a set of artifacts consistent enough to describe the behavior, functional or non-functional, of our software.