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

  • Requirement Prioritization Techniques Today, it is time to describe the requirement prioritization techniques. We can transmit them using a number of techniques. Those are as follows: Ranking This technique consists in […]
  • Prolaborate and Enterprise Architect A few weeks ago, in an article about Enterprise Architect Pro Cloud Server, I described one of the tools offered by Sparx Systems, which allows access to the model repository via a web […]
  • Requirements Management – Best Practices Ian Sommerville and Pete Sawyer in "Requirements Engineering: A Good Practice Guide" described, over 15 years ago, the method of assessing and improving requirements engineering […]
  • Mappings That Go Beyond Enterprise Architecture Some month ago in the post I wrote My Favorite Perspectives in Enterprise Architecture I presented a few diagrams describing enterprise architecture from different perspectives. The […]
  • System Requirements – the Context and Boundary of the System The main tasks of requirements engineering is acquisition and documentation of system requirements. To do this, identify those parts of the real world that will affect system […]

Leave a Comment

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

Scroll to Top