Non-Functional Requirements as User Stories | David Tzemach
Updated: Mar 3, 2022
Non-Functional Requirements (A.K.A – Technical Requirements/ Operational Requirements/System Qualities) are defined by the Scrum development team. These requirements reflect different system attributes relating to the development process that is not about a specific functionality, like application scalability, security, usability, performance, and technical requirements.
Examples include:
The site can process 2K requests per second.
Password complexity is enforced.
An authentication timeout occurs after 45 seconds.
Non-functional requirements are as critical as any other functional Epics, Features and user stories. This is because they can significantly influence the development lifecycle, including design, architecture, and technology used. All these are critical factors to ensure the quality of the system. Note: the terms Non-Functional Requirements and Technical Stories are equivalent.
Non-Functional Requirements are (almost) always treated as a constraint for other user stories. A constraint is a specific condition that allows the team to define the work to be done to align the functional requirements with the quality expectations.
The following are some of the common types of technical user stories that are added to the product backlog:
Bug Fixing – This technical story will represent a cluster of bugs that the team will resolve before continuing the development effort.
Spikes – Stories used by the team to research before starting work on functional stories (We will discuss this in more detail soon).
Code refactoring – Stories that the team will add for areas that are refactoring candidates. Refactoring can be for designs, the logical structure of the code, syntax, etc.
Development infrastructure – Stories that support development activities and their ability to deliver software (packaging tools, new automation framework, etc.).