Depending on the size of the project you are working on and its level of complexity, there are several different tools you can use to describe the problem you are attempting to solve. These include (but are not limited to) user stories, requirements, and use cases. In this section, we’ll focus on user stories and requirements. We’ll come back to use cases later.

User Stories

User stories are short – one to three sentences long – that describe one thing the user will do, and why they want to do it. The key point is that a user story is limited to one thing the user will do with the system. A general structure for a user story is provided below.

It is important to note that user stories are not about the system. Instead, user stories provide us with information about the user. Specifically, user stories describe things a user expects to do when using a system.

It is also important to note that user stories are not about implementation. User stories do not tell us how something needs to be built. Consider the following user story:

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

While this user story informs us of what the user might want to do, it doesn’t tell us how they might do it. There are several ways that they might look up their grades. For that reason, user stories are not instructions.

Requirements

A requirement, much like a user story, represents one thing the software is expected to do. Unlike user stories, requirements include extra information, cover more actors, and have a broader scope.

First, requirements include a MUSCOW label. While MUSCOW will be further described in a later section, know that the possible labels include Must, Should, Could, and Won’t. Clearly, the label describes the level of importance the requirement has in relation to the rest of the requirements.

While user stories focus on actors that fall under the “user” label, requirements are necessarily broader than this. That is, requirements might describe functionality that the user would be interested in, but they can also describe functionality that might exist between systems. For example, it may be necessary for your system to connect with the PayPal servers to verify a transaction. In this case, the actor of the requirement would be the system you are designing.

Why wouldn’t the actor be PayPal?

The simple answer to this is that you aren’t designing PayPal. Your system might use it, but building a requirement for PayPal is well outside the scope of your project, and likely not something you can control or implement.

In addition to the functional requirements of your system, your list of requirements might also include non-functional requirements. These requirements might include, for example, legal requirements (e.g. level of AODA compliance), aesthetic requirements (e.g. identification of a particular colour palette or font choice), or other client/user requests that aren’t explicitly about system functionality.

Finally, requirements tell you what needs to be developed, not how to do it. Again, there will likely be many ways to build a solution that satisfies the list of requirements that you will identify. Some solutions might be better, and some might require more time and money. And some solutions might make more sense to the client than others. As a designer, you will need to learn to balance all of these things to deliver a product that satisfies the list of requirements and provides the client with a tool they can use.

Some of the main differences between requirements and user stories are provided in the table below.

Activity: User Stories & Requirements

Consider the following user story. You’ll note that it does not tell you anything about implementation; it simply describes one thing a user would want to do with the system you are intended to design. Take a moment to consider the different ways in which you might achieve this user story. Are some of your solutions better than others?

Identify at least three ways you could implement a solution to satisfy this user story.

Consider your potential implementations. Which of them would you consider to be the best solution? Which of them would require the most time and money? Which of them are quick and cheap to do? Can you identify one that would provide the most return on investment (that is, not too time-consuming or costly, but adequately satisfies the user story)?

Referring again to the user story provided, and imagining the user has pressed “submit” to sign into the system, what might the system do in response?

Activity: Case Studies

For each of the following case studies, consider if you would develop a set of user stories or requirements to outline and understand the problem that needs to be solved.

Review Questions