Requirements

The requirements stage is where we explore the problem that we wish to address, and determine what to build. This is the time for market research, talking with customers, and determining the details of how we want our feature to work (note: these are the “what to build” decisions, not the “how to build them” decisions). At the end of this phase, you should have a detailed list of product features that you will consider implementing.

Traditionally, this would be done by a product manager (business or marketing specialist) based on what they perceived as the market need for that feature. In other words, they would determine what to build based on what they thought would sell.

However, we want to ensure that we design and build a product that is compelling for our users, so we want to make sure that we include our users in this process and get their input as a primary means of determining what to design. This focus on users-first is a critical tenet of User-Experience Design (or UXD).

UXD can be traced back to the mid-1980s, when Don Norman suggested that design should focus making products more usable for the people that use them. His book, The Design of Everyday Things became the foundation for the UX movement that followed. Through the 1990s and early 2000s, significant research in HCI and related disciplines contributed to a whole-scale shift contributed to the widespread acceptance of human-centric product design. Today, it is widely accepted that our best practices in requirements and design are human-oriented¹.

Our first step is to gather information that will help us understand our users and their problems, and determine what features we need to design and implement for them.

Characterizing Users

You want to clearly understand:

• “Who are my users?”
• “What are they trying to accomplish?”
• “How do they relate to the problem that I’m trying to solve?”

A key objective at the start of the project is to determine who your users are. In some situations, you may be told what users to target, and your early efforts would be to interview people and refine your understand of user roles (e.g. imagine you’re told to create a new system for airline booking agents; you would probably start by interviewing everyone that relates to that role, who in turn may help you identify other potential users).

In other situations, your users may not be obvious: you may need to interview people to determine your potential user base.

Interview 5-6 users [Nielsen 2000] and ask open-ended questions about the problem. Use followup questions to to make sure that you understand their goals and motivations. The outcome from interviews should be detailed interview notes.

Good interview questions:

• Describe the problem that you have.
• How would you accomplish X?
• What do you like about this system? What do you dislike?
• How would you expect (some feature) to work?"

Another useful technique for gather information is to survey users. Surveys are relatively inexpensive, and it is fairly easy to collect information from a large group of users quickly. However, response rates for surveys tend to be low, and you are limited to fairly simple questions (plus, unlike interviews, you cannot ask follow-up questons!).

From your interview notes, it can helpful to characterize your target users, and the tasks that they want to perform. This involves generation of Personas and User Stories.

Personas

A persona is an archetypal description of a user of your application or product. They are often based on “real people” but are generalized descriptions that represent a category of people that share similar characteristics. We use personas a stand-ins when discussing product goals and features.

Each role or “type” of user that you identifed should generate a unique persona. You typically have 2 or 3 personas for even a small solution.

To build a persona, you interview one or more users representing that role in an organization. You then write a fictional portrait of a user, which represents as accurately as possible the consensus among your users in that role.

There are some basic elements that your user persona should include:

• Personal info: Present personal information first, including name, job title, company, job description, family status, and more. Include any details that can help your team understand the persona better.
• Demographic info: Other demographic information, such as age, gender, income, education, location, and other background information can help you create a more authentic character.
• Image: Images speak louder than words. A vivid image, sketch, or cartoon can help your team picture your users clearly, and help you establish a consistent understanding of the target users. Use a photo that reminds you of this user.
• Goals & motivations: You should also make it clear what your audience wants to get or to do with your product. List all possible goals and motivations that you’ve found from your user research.

Here’s an example:

Actors

In UML notation, a user would be an Actor. Actors aren’t nearly as well documented as personas, but are still generalized standins, representing a particular user role. One peculiarity of actors is that they can also represent other systems that engage with your system.

In this course, we’ll use personas to characterize our users. Actors will only be used if we need to show an interaction on a UML diagram.

Determining Requirements

Affinity Diagrams

The outcome of your interviews will likely be a lot of qualitative data – opinions, suggestions and ideas that the user expressed. The challenge is extracting ideas, themes from this narrative that you can use in your design.

We use thematic analysis to do this, and the mechanism that we will use is the creation of an affinity diagram.

To create an affinity diagram:

1. Record all notes or observations on individual cards or sticky notes
2. Look for patterns in notes or observations that are related and group them
3. Create a group for each pattern or theme
4. Give each theme or group a name
5. Create a statement of what you learned about each group (provide your analysis or key insight)

You should end up with clusters of related ideas, all around a common theme. You can them examine these to expose critical ideas or themes from the user’s ideas. (You can even do this across multiple users and looks for which themes occur more frequently!).

https://www.invisionapp.com/freehand/templates/detail/affinity-diagram-template

User Stories

From your user interviews, you should have identified some basic tasks that you will need to address. Often, these will come in the form of stories or narratives from your users, which you’ve recorded. Your job in this step is to extract these common stories or tasks from your interview notes.

User-Stories are a description of activities that are performed with a system to perform a particular task. A user story is often simple text, and is intentionally describing the problem at a high level:

“As the HR manager, I want to create a screening quiz so that I can understand whether I want to send possible recruits to the functional manager.”

“As a user, I can indicate folders not to backup so that my backup drive isn’t filled up with things I don’t need saved”.

User stories are useful because they help identify users and their high-level goals, and they serve as an excellent starting point for discussions.

User Story Maps

Once you’ve collected a number of user stories, you might arrange them into User-Story Maps to show their larger relationships. They can also be plain-text, but often include diagrams, sketches and other visual elements that help describe a user’s interaction with the system.

User Stories Maps often include three levels:

1. Activities represent the high-level tasks that users aim to complete in the digital product. e.g. deposit a cheque.
2. Steps sit directly underneath activities and also display in sequential order. They represent the specific subtasks that users will go through in the product to complete the activity above. e.g. enter pin, select deposit from the menu, and so on.
3. Details are the third level of the story map and describe the lowest-granularity interactions that the team anticipates users will experience to complete the step above. e.g. enter pin by pressing the numbers in order, and ok when complete.

https://www.nngroup.com/articles/user-story-mapping/

These activities should be logged as requirements in your tracking system, along with the steps and details that have been captured. Each activity is a feature, and the steps and details provide information helpful in the implementation of that feature.

Use Cases (Optional)

You may choose to convert these user stories into more detailed Use Cases and Requirements.

A use case is similar to a user story, in that it describes a particular action or set of actions by a user. However, where a user story is high-level and leaves out a lot of details, a use case is much lower level and attempts to describe all of the required details.

Use cases were first introduced by Ivar Jacobsen while working at Objectory, as a way of specifying how actors (users) interact with functional requirements. Here’s an example, using simple UML notation showing a series of related use cases.

https://cacoo.com

Use cases in this example include “Search for items”, “Place order” and “Obtain help”. You can see which Actors (or Users) interact with each use case. This particular example also shows which use cases will be addressed in which software release.

Although user stories often sufficient, the extra level of detail that use cases provides can be helpful in determining exactly how functionality should work. A full realized use case might provide this level of detail:

Finally, you want to realize these use cases as features in your product. Use cases should be much more specific than user stories and should be realizable. In other words, you should attempt to provide enough detail in the task description that the Design and Implementation phases can act on this requirement.

Your final step should be to convert these requirements - derived from your affinity diagram, and use cases - into actionable items.

• Log each item into your GitLab project as an Issue (better to have a custom type?)
• Don’t assign anything yet!
• Assignee: Unassigned
  • Milestone: No milestone
  • Due date: Unselected

These unassigned issues constitute your Product Backlog. You only schedule this during Sprint planning, and only if the team agrees to take it on.