User Stories: Goals and phrasing pattern

Manufacturers employ user stories to express (software) requirements in a natural language that is understandable to users and customers. Typically, they use phrasing patterns such as:

“As a <role> I can <activity> so that <business value>.”

Example

As an EPAT (extracorporeal pulse activation technology) technician I can adjust the energy level delivered in increments so as to deliver higher or lower energy pulses to the patient’s treatment area.

User stories from a regulatory perspective

Regulations such as ISO 13485, IEC 62366 and FDA don’t specify any particular method and thereby also no user stories. However, they mandate that manufacturers explicitly document 

• Intended use / purpose
• Stakeholder requirements such as user requirements
• Use scenarios
• System respectively software requirements specifications

User stories mix these aspects; so do the manufacturer confuse the content of the corresponding documents.

Example (continued)

The example above reflects a user requirement. Following the phrasing pattern for user requirements the sentence would be: “The user has to be able to select the energy level from the system.”

The part “as to deliver..” expresses the goal – the business value. The goal, however, should be specified either as user need or even as aspect of the intended use description.

The "in increments" is already an aspect of the system requirements specification.

Please consider the following challenges when working with user stories:

1. One most likely will confuse user needs respectively the intended use description with user requirements. User requirements can be validated with a product, not user needs.
2. If stakeholder (e.g. user) requirements and system requirements are not clearly separated (e.g. in different documents), tracing will become an issue. 
3. Manufacturers tend to believe that the user stories are a suitable to identify the real user requirements. This is a misconception. Both, using phrasing patterns and asking customers for their requirements, are unsuitable means to derive user requirements. ISO 9241 part 110 gives guidance how to do this.

Use stories and use scenarios

Use scenarios (sometimes also referred to as usage scenarios) describe the sequence of user action and system reaction. They can be derived from a stakeholder and task analysis.

You cannot derive use scenarios systematically from user stories (nor vice versa). Neither user stories are a replacement for use scenarios. IEC 62366 explicitly requires manufacturers to identify and evaluate use scenarios for safety relevance.

Conclusion

User stories frequently cause more problems than benefit. We recommend that you rather: 

1. Explicitly describe the intended use / purpose (in a dedicated documented)
2. Use the context method as described in ISO 9241 part 110 to systematically derive user needs, user requirements and core tasks.
3. Specify based on these results use scenarios.
4. Specify the system / software requirements
5. Validate this requirements specifications with representative users (formative evaluation). 

Further support?

Any questions left? Not quite sure whether your documents meet regulatory requirements? The team of the Johner Institute is looking forward to helping you to compile your technical documents and to fast and safely pass submissions.