User Stories versus Software Requirements

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.

The definition of Requirement in the dictionary, with the word "Requirement" highlighted

Pros of User Stories

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.”

3 co-workers collaborating on a user story board covered in colorful sticky notes

Cons of User Stories

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.

A stack of papers with a blue background. The top paper says "REQUIREMENTS" and has a checklist beneath it.

Pros of Software Requirements

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.

Cons of Software Requirements

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.

Need help on this topic?
Contact Us
Frances Cohen

Frances Cohen is President of Promenade Software Inc., a leading software services firm specializing in medical device and safety-critical system software. Frances has more than 20 years of experience leading software teams for medical device software. Starting with heart defibrillators for Cardiac Science and following with Source Scientific LLC and BIT Analytical Instruments Inc., Frances has overseen dozens of projects through development and the FDA, including IDEs, 510(k)s, and PMAs.  

Frances has a B.S. in computer engineering from the Technion, Israel Institute of Technology.

linkedin logo
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Promenade Software, Inc. specializes in software development for medical devices and other safety-critical applications.
Promenade is ISO 13485, and CypherMed Cloud is SOC2 Type II certified.