9. Requirements

Estimated time to read: 22 minutes

Requirement engineering is a master course by itself, so this chapter provides only an introduction to the topic.

By the end of this chapter, you should be able to derive the features of your MVP based on your user research, clearly articulate those features, and organize them into independent issues in GitLab. This will help your team work efficiently on the project.

9.1 Template for functional requirement

In this section, the focus is on the use of natural language notation in documentation. This approach can have drawbacks, as everyday language tends to assume shared knowledge, overlook certain details, or introduce ambiguity, which can lead to misunderstandings. In the context of IT requirements, these flaws can have serious consequences.

To minimize these issues, sentence templates are used to structure requirements in a clear and consistent way. These templates help avoid the linguistic effects that can lead to confusion. The structure of a sentence template includes several key elements: the condition under which the system action occurs, the legal obligation (whether it’s mandatory or recommended), the description of the system activity, the relevant objects involved, and the action to be performed on the objects.

For example, using terms like “must,” “should,” and “will” in a sentence template helps clarify the legal obligations. The term “must” indicates a binding requirement, “should” is a recommendation, and “will” suggests a future obligation. It's crucial to ensure consistent interpretation of these terms between both the client and the service provider to avoid miscommunication.

While sentence templates provide a structured and formal approach to writing requirements, they also have some drawbacks. When a large number of requirements are documented using these templates, the resulting text can become repetitive and harder to read. Additionally, there’s a risk of contradictions or dependencies between different requirements that might not be immediately obvious.

Despite these challenges, the primary benefit of using sentence templates is that they help ensure that requirements are clear, comprehensive, and well-structured, reducing the likelihood of misunderstandings or errors in the documentation process.

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.2 Kano Model

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

It helps us understand how different features of a product affect customer satisfaction. Here's a simple breakdown and examples in the context of a fitness app

• Must-be Requirements
  • Basic Needs: These are the essential features that customers expect in a product.
  • Dissatisfaction if Absent: If these features are missing, customers will be very unhappy.
  • No Extra Satisfaction: Just having these features won't make customers happier because they are taken for granted.
  • Examples
    • Ability to log and track workouts.
    • Login and account management.
    • The app should not crash frequently.
• One-dimensional Requirements
  • Direct Impact: The more these features are fulfilled, the happier customers will be.
  • Explicit Demands: Customers usually ask for these features directly.
  • Examples
  • A wide range of workout options and exercises.
  • Ability to set and adjust personal fitness goals.
  • Compatibility with other health and fitness devices (e.g., smartwatches, scales).
• Attractive Requirements or Delighters
  • Unexpected Delights: These are features that customers don't expect but love when they get them.
  • High Satisfaction: Fulfilling these can greatly increase satisfaction.
  • No Dissatisfaction if Absent: If these features are missing, customers won't be unhappy because they didn't expect them.
  • Examples - difficult, as they might exist in some apps and hence may be expected ...
    • Real-time feedback and suggestions from an AI coach.
    • Individual tips for better sleep based on individual data, habits and goals.

Benefits of Using the Kano Model

• Understanding Needs: Helps identify which features are most important for customer satisfaction.
• Prioritizing Development: Focuses efforts on improving features that have the biggest impact on satisfaction.
• Customer-tailored Solutions: Different customer groups may value features differently, so tailored solutions can be created.
• Differentiation: Adding attractive features can make a product stand out from competitors.
• Quality Improvement: Combines well with other quality management methods to enhance product development.

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.3 Trade-Offs of Constraints

The "Devil’s Quadrangle" or "Sneed’s Quadrangle" in project management refers to the inherent trade-offs between four key project constraints: scope, time, cost, and quality. It highlights the challenge of balancing these factors, as improving one often negatively impacts another. For example, if you want to expand the scope of a project, it may require more time and higher costs, which could compromise the quality unless adjustments are made elsewhere. The concept serves as a reminder that project managers must continuously manage these competing demands to deliver a successful project.

Naturally, there are other similar frameworks with interrelated factors, such as security, time to market, user experience (UX), and others. These additional considerations often influence the primary project constraints—scope, time, cost, and quality—and further complicate decision-making and trade-offs. Each of these factors can impact the overall project success, and balancing them effectively is essential for achieving optimal outcomes.

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

9.4.3 INVEST

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.