Describing Problems: User Stories and Requirements

Before we can design software, we need a way to describe the problem we are trying to solve.

This may sound straightforward, but one of the most common reasons software projects struggle is that different people have different understandings of the problem. A client may describe one need, users may have different expectations, and developers may interpret those expectations in entirely different ways.

As software designers, our job is to create a shared understanding of the problem before we begin building a solution.

Fortunately, there are several tools that can help us do this.

Depending on the size and complexity of a project, software teams may use:

• User stories
• Requirements
• Use cases
• Process models
• Prototypes
• Workflows
• Other design artifacts

In this chapter, we will focus on two of the most common tools used during the early stages of software design:

• User stories
• Requirements

We will explore use cases later in the course.

Why Do We Need These Tools?

Imagine that a client tells you:

“We need a better way to manage volunteers.”

At first glance, this seems simple enough.

However, what exactly does “manage volunteers” mean?

Does it mean:

• Recruiting volunteers?
• Scheduling volunteers?
• Tracking volunteer hours?
• Communicating with volunteers?
• Generating reports?
• All of the above?

Without a structured way to describe the problem, different members of the team may leave the same meeting with completely different interpretations.

User stories and requirements help us avoid this problem by providing a consistent way to document needs and expectations.

They help us move from vague ideas toward a clearer understanding of what a successful solution should accomplish.

User Stories

A user story is a short description of something a user wants to accomplish.

Typically, user stories are only one or two sentences long and focus on a single task or goal.

The key idea is simple:

User stories describe what users want to do and why they want to do it.

They do not describe implementation details.

They do not tell developers how to build a feature.

Instead, they help us understand the needs, goals, and motivations of the people who will use the system.

A common format for a user story is:

As a [user type], I want [some action] so that [some reason].

For example:

As a University of Guelph student, I want to look up my course grades so that I can calculate my cumulative average.

Notice what this user story tells us:

• Who the user is
• What they want to do
• Why they want to do it

Notice what it does not tell us:

• What database to use
• How the grades should be displayed
• What buttons should exist
• What programming language should be used

There are many ways we might design a system that satisfies this user story.

That flexibility is intentional.

User stories focus on understanding the user rather than prescribing a solution.

What User Stories Help Us Learn

When we write user stories, we are really learning about people.

We learn:

• Who our users are
• What goals they have
• What challenges they face
• Why they interact with the system

This information helps us design systems that are useful, meaningful, and aligned with user needs.

For this reason, user stories are often used early in a project when teams are still trying to understand the problem space.

Requirements

Requirements build upon the ideas captured in user stories.

Like user stories, requirements describe something that must be accomplished by the system.

However, requirements are typically more detailed, more structured, and broader in scope.

While user stories focus primarily on users, requirements can describe:

• Actions performed by users
• Actions performed by the system
• Interactions between systems
• Functional behaviour
• Non-functional expectations

Requirements help define what a completed solution must do in order to be considered successful.

The Structure of a Requirement

Throughout this course, requirements will often include a priority classification using the MoSCoW framework:

• Must
• Should
• Could
• Won’t

We will examine MoSCoW prioritization in greater detail later. For now, it is enough to recognize that not all requirements have the same level of importance.

Some requirements are essential.

Others are desirable but not strictly necessary.

Requirements Can Involve More Than Users

One important difference between user stories and requirements is that requirements can involve actors other than users.

For example, imagine that your software must verify payments through PayPal.

A requirement might describe the interaction between your system and PayPal’s services.

In this case, the actor is your system.

Why not PayPal?

Because you are not designing PayPal.

Your project may interact with PayPal, but you have no control over how PayPal itself operates. Requirements should focus on elements that are within the scope of your system.

This distinction becomes increasingly important as systems become more complex and interconnected.

Functional and Non-Functional Requirements

Many students initially think that requirements only describe functionality.

In reality, requirements can describe much more.

Functional Requirements

Functional requirements describe what the system does.

Examples include:

• Creating an account
• Submitting a form
• Generating a report
• Processing a payment

Non-Functional Requirements

Non-functional requirements describe qualities or constraints that the system must satisfy.

Examples include:

• Accessibility requirements
• Privacy requirements
• Security requirements
• Performance expectations
• Branding requirements
• Legal compliance

A client may not explicitly ask for these things, but they are often essential components of a successful system.

Requirements Are Not Instructions

Like user stories, requirements tell us what must happen, not how it should happen.

This distinction is extremely important.

When we focus too quickly on implementation, we risk limiting creativity and overlooking better solutions.

Consider the requirement:

The user must be able to securely sign into the system.

There are many ways we could satisfy this requirement:

• Username and password
• Multi-factor authentication
• Single sign-on
• Biometric authentication

Each solution has different costs, benefits, risks, and levels of complexity.

The requirement defines the need.

The design process identifies the best way to satisfy that need.

User Stories Versus Requirements

Although user stories and requirements are related, they serve different purposes.

User Stories

User stories help us understand:

• Who the user is
• What the user wants to accomplish
• Why the user wants to accomplish it

They are user-focused and often used when exploring needs and expectations.

Requirements

Requirements help us define:

• What the system must do
• What constraints must be satisfied
• What interactions must occur
• What constitutes success

They provide a more complete description of the solution space.

In practice, many projects use both.

User stories help teams understand users.

Requirements help teams understand the system that must be built.

Activity: One User Story, Many Solutions

Consider the following user story:

As a user, I want to securely sign into the system so that I can update my profile settings.

Notice that the user story does not specify how sign-in should occur.

Take a moment to brainstorm different solutions.

Could users sign in using:

• A username and password?
• A Google account?
• A University account?
• Multi-factor authentication?
• Facial recognition?

Now consider the trade-offs associated with each approach.

Which option is:

• The most secure?
• The least expensive?
• The easiest to implement?
• The easiest for users?
• The best balance of cost, effort, and usability?

There may not be a single correct answer.

Software design often involves evaluating competing priorities and selecting the solution that provides the greatest value within available constraints.

Activity: Choosing the Right Tool

Not every project requires the same level of detail.

Consider the following scenarios.

For each one, ask yourself:

Would user stories alone be sufficient, or would detailed requirements also be necessary?

Case 1: A Dating Application

You have been asked to develop a mobile dating application and accompanying web platform that connects local singles using a proprietary matchmaking algorithm.

How much information would be needed before development begins?

Would understanding user goals alone be enough?

Case 2: Art in the Street

You have been asked to create a website for an annual arts festival in downtown Guelph.

The website needs to provide information about presenters, locations, schedules, and event details.

How complex is this problem?

Would user stories provide enough information, or would formal requirements also be useful?

Case 3: Air Traffic Control Software

Your team has been tasked with designing a new software system for North American air traffic controllers.

The system will replace aging infrastructure responsible for monitoring flights and managing airspace.

What risks are associated with failure?

How much precision would be required?

Would user stories alone be sufficient?

Or would highly detailed requirements be essential?

As projects become larger, more complex, and more safety-critical, the need for detailed requirements generally increases.

Part of becoming a software designer is learning when a lightweight description of a problem is sufficient and when a more formal specification is necessary.

Throughout CIS3750, you will practice both approaches and learn how to select the right tool for the situation.