9. Requirement Engineering

9.1 Requirements

As you have learned or learn in software engineering there are functional and non-functional requirements. We mainly focus on the functional requirements. For a real product requirements of all stakeholders are relevant, e.g. time constraints etc.

Requirement engineering is a course by itself. However, try to write down and prioritize all requirements learned during the user research.

9.2 Template for functional requirement

It is difficult to write clear and unambiguous requirements, the following template helps.

Or with an additional condition

Here is a check list for clarity

• Are the requirements clear and unambiguous? (Are all aspects of the requirement understandable and not subject to misinterpretation? Is the requirement free from indefinite pronouns (this, these) and ambiguous terms (e.g., “as appropriate,” “etc.,” “and/or,” “but not limited to”)?)
• Are the requirements concise and simple?
• Do the requirements express only one thought per requirement statement, a stand-alone statement as opposed to multiple requirements in a single statement, or a paragraph that contains both requirements and rationale?
• Does the requirement statement have one subject and one predicate?

This list is very similar to ISO/IEC/IEEE 29148

9.3 Kano Model

The Kano model, created by Noriaki Kano in the 1980s, is a framework for product development and customer satisfaction.

Attractive requirements or delighters "are the product criteria which have the greatest influence on how satisfied a customer will be with a given product. Attractive requirements are neither explicitly expressed nor expected by the customer. Fulfilling these requirements leads to more than proportional satisfaction. If they are not met, however, there is no feeling of dissatisfaction." ²

A "delighter" refers to a feature that creates customer excitement or delight when included in a product. These features go beyond basic expectations and can significantly enhance customer satisfaction. Delighters are considered unique innovations or surprises that generate an outsized positive response from users. A delighter sets your product or service above your competition. It might be your unique selling point (USP). However, not every USP is a delighter nor vice versa. While delighters enhance customer satisfaction by surprising and delighting users, USPs aim to differentiate a product in the market and attract new customers by offering something unique that competitors do not provide.^{3 4}

"A unique selling point can be thought of as what you have that competitors don't."⁵

9.4 MVP

It is basically the first version of a product, which shows the main idea, contains a minimum set of features. Do not focus on tedious work, but ensure at least one delighter and your unique selling point is addressed properly.

The following approach might help to define, which features should be part of the MVP and which might be added in later versions.

A more detailed discussion may be found in the article: Feature Driven Agile Product Innovation Management Framework.⁷

9.4.1 Vision

⁸"A good vision is inspiring for people. It's a description of a dream, of a state to become. It's a dot on the horizon that you're working towards. It's also stretching for people. On the other side, a vision statement should also be short and clear for people. By short and clear we don't mean short term. It should be a dream for the long term, but people also need to be able to understand the vision, so it should offer clarity. A nice way to start with your vision statement is by using the vision statement template (see below). Beware: it's just an example to get you started, you don't have to force your vision into this template!

9.4.2 User Story

After you decided, which user stories or features should be developed in the near future. It is time to write them down in a clear and readable format. The typical template for a user story is

    As < role > I want to < function > so that < benefit >

And an example

To make the user story more personal and let the team emphasize with the persona and her needs it is recommended to use the name of your persona instead of the role only, hence use the following template

Each user story should follow the INVEST principles

• Independent: Backlog items should be independent of each other. This means that a backlog item can be considered on its own and implemented without the need for further backlog items.
• Negotiable: Backlog items are negotiable. They do not represent a contract that has to be implemented in exactly the same way, but leave the developers enough freedom to work out the details in a sprint together with the stakeholders.
• Valuable: Backlog items provide a value. Usually a value for the customer, or for the future user. In this context, it is irrelevant how large a backlog item is. Even the smallest backlog items must deliver a value. If this is not the case, then you should seriously question their existence and the need to implement it.
• Estimable: Backlog items must be estimated (see chapter 6.3). This estimation helps, for example, to sort the backlog item into the product backlog, or to be able to make a statement about how large the backlog item is. In order for the backlog item to be estimated, it needs to be understood by everyone involved. Otherwise, estimation will not be possible.
• Small: Backlog items should be small. The smaller they are, the more specific they usually become. But this is not the only decisive factor; the sprint length also plays a role. After all, the backlog item should be able to be fully implemented in one sprint. Accordingly, we have to choose the size so that the item can fit into the sprint but also leave enough buffers so that the smallest surprise does not immediately jeopardize the implementation in the sprint. But be careful. Do not tend to cut the backlog items too small. This will only increase the administrative workload without adding any value.
• Testable: A backlog item should be testable. This means that it is sufficiently well understood as to be able to describe how it can be verified whether the backlog item has been implemented according to the wishes. The use of acceptance criteria for the respective backlog items is suitable for this purpose."⁹

The following pragmatic rules will help you to write good user stories

• Is everybody able to implement the story without further discussion and questions?
  • Beginners miss clarity in their stories
• Is it possible to implement the story in 4h?
  • Beginners write too big stories
• Are acceptance criteria clearly defined, i.e. you could give the implemented issue and the criteria to another person and this person could clearly say, if the criteria are fulfilled
  • Beginners formulate the issue itself and acceptance criteria too vague
• Is it possible that different team members work on different stories?
  • Beginners are often not possible to write independent stories, they tend to interweave stories which requires a sequential work and thus slows down the development process

9.5 Issue

User stories are one type of issues. Use gitlab issue templates for the following types of issues

• bug
• user story/feature
• technical evaluation, proof of concept, or spike
• task -- if the story is too big, break it down into tasks -- if it is really not possible to write a smaller user story
• refactor

Use the following properties for issues to be organized better

• labels
• weight
• health status
• time tracking
• milestone

9.6 Story Board

Organize your issues in a story board and plan the next sprint in detail and the sprint goals up to the next release.