Last Saturday was cold and I was at home browsing through a pile of unwrapped magazines, so I came across an article by Daniel Jackson about dependable software (see reference below). The author explains the importance of software in safety-critical equipment that we come across every day and he considers approaches that offer a greater trust in them. He defines dependable systems as follows:
“A dependable system is one you can depend on—that is, you can place your trust in it. A rational person or organization only does this with evidence that the system’s benefits far outweigh its risks. Without such evidence, a system cannot be depended on…“
In the development of critical products, we use agile practices like Scrum because they make the product more dependable and safe. In this context, the requirements play an important role.
With Scrum, we can use and adapt User Stories to help to clarify this dependability:
- First, in Scrum, we formulate requirements in the form of User Stories to enforce verbal communication because talking (and listening carefully), writing and drawing is a more efficient and careful way to communicate.
- Second, User Stories help us to discuss carefully with the stakeholders the purpose they want to accomplish, the value of a requirement, not the implementation details. For example by using a template like “As a … I want to … so I can ”. This is particularly helpful when testing the system: to know in which context to test it. Example of User Story, in this case the control unit of a medical device:
As a patient, I want a view of the operating history for the last 24 hours in the simplest possible way so I can easily read it in low lightning conditions or when I am tired or confused.Commitments to the details can be postponed and made later when the first implementations and prototypes allow a better understanding. At this time, the constrains (or non-functional requirements) related to User Stories can be written down (just) in time for the implementation and make the requirements quantifiable.
- Third, for dependable systems, the critical properties of this functionality, and the assumptions that could cause problems -if untrue- could be added to the Story in the same way. When discussing or writing Stories, consider expressing the critical properties and the assumptions, and add them to the Story, for example:Assumptions:
1) Ambient luminance range: 100 to 1000 lux.
2) Viewing distance: 20cm to 60cm
3) For alarm signals, specific requirements shall apply.
Knowing the assumptions and intends of the User Story seems important enough to take the time to clarify this with the Product Owners. For the agile development of dependable products, just-enough details may mean clarifying the value, the constraints, assumptions and risks that make the story verifiable, and doing this at the latest possible time, when the first implemented features permits a better understanding of the product. In this way, we can balance the benefits and the risks, and implement User Stories where we are reasonably sure to understand the risks.
References: D.Jackson, A Direct Path to Dependable Software. CACM.ACM.ORG 04/2009 Vol.52 No. 4 – http://sdg.csail.mit.edu/publications.html