User Stories vs Requirements

When writing any specification of requirements and the product register and sprint register, non-functional requirements should be included in this specification.

While the user’s story itself usually represents functional requirements, in my opinion a small problem is with non-functional requirements that represent system-level expectations. Lack of non-functional requirements or their insufficient quantity are often a source of programming problems as well as testing.

Good management of expectations is extremely important – especially because many people still have a wrong idea of ​​the rules, possibilities and limits of agile ways of doing things. Only when expectations are known, can they be harnessed and linked to requirements.

Personally, I think that you should use tools that allow you to map non-functional requirements to user’s stories. Enterprise Architect (Sparx Systems) is the obvious solution for me.

The product owner is responsible for defining the acceptance criteria for each item in the product registry. These are necessary conditions that must be met in order for the product owner to be pleased to admit that all functional and non-functional requirements have been met. The owner of the product may also write acceptance tests or recruit experts from a given field or the members of the development team for this purpose based on acceptance criteria. Regardless of the approach taken, the product owner should make sure that the acceptance criteria (and often also specific acceptance tests) have been created before the item goes into the process of planning the sprint. Without them, the team will not fully understand the item and will not be able to accept it for execution in the sprint. For this reason, many scrum teams attach the existence of clear acceptance criteria to their checklist of preparedness definitions.

The user experience requirements are most easily saved in the form of sketches, storyboards, user interface diagrams and prototypes. My experience suggests that teams prefer these kinds of artifacts than the user interface guidelines presented in graphical form.

When managing non-functional requirements, it is best to distinguish between global and local requirements. The former usually refer to all functional requirements and form a small group. An example is the performance limitation. Global non-functional requirements should be described in detail as soon as possible – when creating a vision or adding new items to the product registry.

Finally, remember that Scrum breaks with the current model, which assumed that at the time of launching the project, the client knows exactly what his needs are. All you need to do is document it and follow the case. Scrum says something completely different. Instead of wasting time describing something that can change during the next stages of work, talk, ask, explain doubts, do not be afraid of your ideas.

Saving non-functional requirements at the high level allows you to refine them at the level of individual sprints. What’s more, Scrum assumes dialogue, which means that unrealistic (means very expensive in production and less useful) functional and non-functional requirements will be clarified in such a way that a consensus between the objectives and expectations of the Product Owner and the technical capabilities and skills of the development team will be achieved.

More from my site

  • User Stories vs. Use Cases We are currently in a “strange situation”. There are user stores and usage case scenarios, of which the latter can be divided into formal and informal use cases as well as summaries of […]
  • Categorization of Requirements According to the Kano Model Defining the requirements that will increase the satisfaction of stakeholders from the system being created is crucial for the process of acquiring requirements. Implementation of too many […]
  • Business Requirements vs System Requirements There is a lot of talk about the need to identify project goals, organization goals and the need to identify business and system requirements. All in order to better understand the […]
  • The Requirements Are the Most Important During my work, I noticed that the requirements are a big problem. The difficulty is not to write them down. It is difficult to articulate them. I omit the turbulence associated with the […]
  • Tracking of Relationship Between Requirements An important aspect of requirements management is the ability to trace the relationships between requirements and other artifacts (including other requirements). The ability to track […]

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top