.png)
Out of all of our blog posts, our Writing Good Software Requirements post consistently gets the heaviest traffic. While it surprises me, since it is a very old post, it made me realize that people are looking for help writing requirements. So I’d like to add some further expertise on the subject by discussing User Stories. Recently we are seeing an increasing use of them, especially for web and mobile applications. This blog discusses the pros and cons of User Stories and traditional Software Requirements, and how we use both.
User Stories are a clean, easy-to-understand input, particularly for mobile and web apps. They are a great way to communicate what the software needs to do for the user, and I really like it when our clients provide them as input to the User Interface. Their format is usually “As a User, I want,” e.g.“as a User, I want to see the time and date on each screen.” There can also be variations for the different user roles, e.g. “As an Admin user, I want to be able to create new user accounts.”
One problem with User Stories is that it is just one perspective. There are other perspectives to consider, and some might even be in conflict with what a user would want. For example, security features might conflict with usability. Requiring that a mobile phone is not jail-broken makes sense from a security standpoint, but is probably not desirable from the user perspective (especially a user with a jail-broken phone). Other perspectives include: data analyst, system engineer, test engineer, technical support, legal, security expert, regulatory, marketing, and manufacturing. All these perspectives might add requirements that are not seen by the user.
Another problem with User Stories is that they are generally broad-stroke. Good requirements are complete, clear, and unambiguous, with technical detail as required. For example, a User Story might say they want their data to be stored securely. A requirements specification would indicate the specific technology to use for encryption (ex. AES256), which data is encrypted, and where the key is generated and stored.
Software requirements take the perspective of the software implementer and tester. They cover all functions and features that the software must provide. In a sense, they provide a detailed contract between the stakeholders and the engineering team so that there can be no misunderstandings.
Written correctly, they are:
● Unambiguous – they do not leave anything open to interpretation.
● Complete – they include all significant requirements with technical detail as needed.
● Consistent – they do not conflict with each other.
● Modifiable – They avoid redundancy and intermixing with other requirements.
● Verifiable – There must be some process that allows a person or machine to verify without subjectivity.
Software requirements are harder to read and write without a software background and training. They can be very technical, and less intuitive for stakeholders than User Stories. They generally require significantly more time to write and review, and need more updates as the project progresses and details are flushed out.
User Stories have their place and add value, particularly at the start of the project. They are a great way for multiple stakeholders to communicate desired features of the system. But they should not be considered a substitute for good software requirements for medical devices. The detailed and unambiguous documentation that software requirements provide are the gateway to quality controlled implementation and test.
Working on a project utilizing software requirements? We can help by reviewing your them or any of your submission documentation.
