Discover Requirement

5/18/2021 Chapter 11: Discovering
Requirements
Human Computer Interaction (HCI)
Zeyad Tarek, Sara Alaa,
Mahmoud Samir
3RD YEAR | GROUP 3 BIS

Agenda
Introduction.........................................................................................................2
1) What Is the Purpose of the Requirements Activity?.........................................3
2) How to Capture Requirements Once They Are Discovered? ........................4
3) Why Bother? Avoiding Miscommunication......................................................4
What Are Requirements? ...................................................................................5
Goals for requirements activity: ...............................................................................5
Shapes of discovering requirements:.......................................................................5
1) Atomic requirements shell (By Suzanne Robertson & James Robertson):.....5
2) Why user stories?................................................................................................6
There are Different types of requirements:..............................................................7
7 product Dimensions: ..............................................................................................7
Usable Security ..........................................................................................................7
There are Common types of requirements: ............................................................8
Data Gathering: ..................................................................................................8
Many Different types to Discover Requirements: ............................................9
1) Using Probes to Engage with Users: ..................................................................9
Four types of probes: .............................................................................................9
2) Contextual Inquiry:...........................................................................................10
3) One-on-one field interviews (called contextual interviews):........................10
The contextual interview has four parts: ............................................................11
Brainstorming for Innovation ...............................................................................12
Personas and Scenarios:..................................................................................12
Goals:....................................................................................................................13
1. Personas:...........................................................................................................13
What is a persona?..............................................................................................13
Persona format tips:.............................................................................................14
2. Scenarios:..........................................................................................................14
What is a scenario? .............................................................................................14
Scenario types:.....................................................................................................14
Use-cases:.........................................................................................................15
What is a use-case?.............................................................................................15
Benefits of a use-case: ........................................................................................15
Elements of a Use Case:......................................................................................16

Introduction
Requirement discovery can be conducted through different ways, so we need a
clear statement of the problem by explore and define the problem space to
know what will be developed. But in case of interaction design we must know
our target users, user capabilities, product features, current tasks, goals, and
contexts; constraints on the product’s performance. this form is the foundation of
product requirement and design, but it’s difficult to differentiate between
requirement, design and evaluation because they are linked with each other.
we can differentiate between them using iterative development cycle, it is a
software development approach that breaks the process of developing a large
application into smaller parts. Each part, called “iteration”, represents the whole
development process and techniques Discovering requirement is a cyclic or
continuous process which may involve many steps and procedures within the
business analysis activities and it contains requirement, design, evaluation and
testing steps
A Requirement Refers to
“what”, A Design
Refers to “how”. the
product must be
designed to meet through
the set of requirements in
the Requirement
Specification.
The Requirement should
state what the customers, users
need from product in terms of features,
material, functions, performance, constraints, and
quality,
The Design reflects the design and provides directions to the builders and coders
of the product by containing information about the product architecture and
describe how each component will contribute to meeting the requirements.
Requirement is written in terms of what the product must do or qualities it must
have. customers, users have to define these requirements. Sometimes states their
requirements in terms of design, often unintentionally. There are requirement best
practices for correcting this problem and for giving the designers the latitude to
define the best solution.
• implementation: all requirements and design docs up to this point are
coded and implemented into this initial iteration of the project.
• Testing: testing procedures to identify and locate any potential bugs or
issues

• Evaluation: Once all prior stages have been completed, it is time, to
examine where the project is at, where it needs to be, what can or should
change, and so on.
1) What Is the Purpose of the Requirements Activity?
Requirement discovery is the act of collecting information about the target or
existing systems and getting the user and system requirements from this
information.
The purpose of discovery of requirements is to get knowledge and general view
about the problem and analyze the problem domain, because the problem
domain is the starting point where a system analyst set system specifications and
scenarios from to identify as many requirements as possible to prepare solutions
for the stated problem.
The requirements activity sits in the first two stages of the double diamond of
design
The Double Diamond design model
stages work as a map designer can use
to organize their thoughts in order to
improve the creative process
• Discovery Stage It is aim to
learning more about the different variables
that affect the problem and its possible
solution. It’s common for companies to start this
process by laying down their problem.
For example, you might want to find out why an assumed customer group does
not use your own product or why a target group that is not directly addressed is
showing a lot of interest.
• Definition Stage It is aim to filtering through all the information you got from
stage one, and elaborating on it. This can mean identifying bottlenecks or
resource waste, seeing hidden opportunities or setting a list of things the
design team definitely shouldn’t do. A poorly defined problem that tries to
solve everything all at once will lead to an unclear starting point and to an
unsatisfactory
Requirements may be discovered through targeted
activities, or tangentially during product evaluation,
prototyping, design, and construction. as shown in
iterative development cycle
Prototyping
It is an incomplete version of
a physical or digital product,
to be taken into user testing.

2) How to Capture Requirements Once They Are
Discovered?
Requirements Capture is a research exercise that is undertaken early in a project
lifecycle to establish and qualify the scope of the project. The user requirements
capture is useful for projects that have a lack of focus or to validate the existing
project scope. Capture requirements refers specifically to the practice of
defining software requirements, but really every project has requirements, user
requirement capture project can include many different usability research
methodologies including; surveys, structured and unstructured interviews,
usability tests, and competitor analysis. Typically, the research is undertaken on a
one-to-one basis between a usability consultant and an end user,
But poor capture and management of requirements are significant causes of
angry customers, massive cost overruns, rework, missed opportunities,
embarrassment, and other project frustrations. capturing requirements explicitly is
beneficial in order to make sure that key requirements aren’t lost through the
iterations, it may be disappointing if the system shall work just like the previous
one, but on a new platform
there are different kinds of requirements due to prototypes or operational
product Through structured or rigorous notations Different capturing mechanisms
emphasize and deemphasize different aspects because notations emphasize
different characteristics.
3) Why Bother? Avoiding Miscommunication
Good communication is the foundation of produces usable products. If parties
are not on the same page and do not understand each other, they will be
unsatisfied and the ties hardly ever will last. You must be specific, detailed, and
avoid assuming that the reader knows what you mean Even if you think that the
reader must know what you are talking about, avoid assumption. Write down
even what should be assumed and don’t be afraid of being repetitive if this is
needed A lack of clarity or incomplete information opens the door for
misinterpretation and faulty assumptions. The cost of miscommunication includes
wasted time, conflict, and projects not getting done right or on time. User-
centered design with repeated iteration and evaluation along with user
involvement mitigates against this from happening

What Are Requirements?
A requirement is a statement about an intended product that specifies what it is
expected to do or how it will perform.
Goals for requirements activity:
1) Identify requirements
2) Clarify requirements
3) Capture requirements
The process of discovering requirements is iterative, allowing requirements and
their understanding to evolve. In addition to capturing the requirements
themselves, this activity also involves specifying criteria that can be used to show
when the requirements have been fulfilled. For example, usability and user
experience criteria can be used in this way.
Shapes of discovering requirements:
1) Atomic requirements shell (By Suzanne Robertson & James Robertson):
-Atomic requirements shell: When you have a requirement that is measurable,
testable, traceable and detailed enough to define all aspects of a need without
further breakdown then you have an atomic requirement.

-This shell indicates the information about a requirement that needs to be
identified in order to understand it. The shell is from a range of resources,
collectively called Volere, which is a generic requirements framework
2) Why user stories?
An alternative way to capture
what a product is
intended to do is via user stories.
User stories communicate
requirements
between team members. Each
one represents a
unit of customer- visible
functionality
and serves as a starting point for
a conversation to extend and clarify requirements.
User stories may also be used to capture usability and user experience goals.
There are three things affect requirements (work as a product partners):
1) User (customer)
2) Business
3) Technology

There are Different types of requirements:
1) Project Drivers
2) Project Constraints
3) Functional Requirements: which describe what the product will do
4) Nonfunctional Requirements: which describe the characteristics (sometimes
called constraints) of the product
5) Project Issues
7 product Dimensions:
Usable Security
One of important requirement for user is security because the wide range of
security breaches, in particular of Individuals’ private data, that have occurred in
recent years has heightened everyone’s awareness of the need to be secure.
The security requirement doesn’t detract from the user experience. This included
informing users about how to choose a secure password, but it also highlighted
that ignoring a user centered perspective regarding security will result in users
circumventing security mechanisms. Users are not necessarily ignoring password
advice when they create weak passwords or write them down, but instead they
are carefully managing their resources and expending more effort to protect the
most valued accounts

There are Common types of requirements:
• Functional: what is the product will do.
• Data requirements: capture the information the information related
to the data (for example: Size –type –accuracy).
• Environmental requirement: are related to the social, physical,
organizational, and technical environment the product is placed.
• User: Is related with the characteristics of the specific user group
that they are going to user the product (novice-Expert).
• Usability: is related to the functional and cognitive aspects that the
design should have in order to the product to be understood and
used by the users.
• User experience: User Experience refers to the feeling users
experience when using a product, application, system, or service. It
is a broad term that can cover anything from how well the user
can navigate the product, how easy it is to use, how relevant the
content displayed is etc.
Note:
Different interactive products will be associated with different requirements.
Every user has its own requirements.
Data Gathering:
The three data gathering techniques Data Gathering” (interviews, observation,
and questionnaires)
In addition to these techniques, several other approaches are used to discover
requirements.
• Documentation, such as manuals, standards, or activity logs, are a good
source of data about prescribed steps involved in an activity. Studying
documentation can also be good for gaining background information,
and it doesn’t involve stakeholder time.
• Researching similar products can also help identify requirements.
-It is usual for more than one data gathering technique to be used in order to
provide different perspectives.

Many Different types to Discover Requirements:
1) Using Probes to Engage with Users:
Probes come in many forms and are an imaginative approach to data
gathering. They are designed to prompt participants into action, specifically by
interacting with the probe in some way, so that the researchers can learn more
about users and their contexts. Probes rely on some form of logging to gather the
data—either automatically in the case of technology probes or manually in the
case of diaries or design probes
Four types of probes:
1. Cultural probes:
The idea of a probe was developed during the Presence Project (Gaver et al.,
1999), which was investigating novel interaction techniques to increase the
presence of elderly people in their local community. They wanted to avoid more
traditional approaches, such as questionnaires, interviews, or ethnographic
studies, and developed a technique called cultural probes. These probes
consisted of a wallet containing eight to ten postcards, about seven maps, a
disposable camera, a photo album, and a media diary.
2. Design probes:
Inspired by this original cultural probe idea, different forms of probes have been
adapted and adopted for a range of purposes, For example, design probes are
objects whose form relates specifically to a particular question and context. They
are intended to gently encourage users to engage with and answer the
question in their own context.
3. Technology probes: mobile phone app as mobile music listening app.
4. Provocative probes: Provocative probes are technology probes designed
to challenge existing norms and attitudes, for example, the Box to challenge
domestic laundry practices:

2) Contextual Inquiry:
Contextual inquiry was originally developed in the 1990s.Contextual inquiry is the
core field research process for Contextual Design, which is a user-centered
design approach that explicitly defines how to gather, interpret, and model data
about how people live in order to drive design ideation. However, contextual
inquiry is also used on its own to discover requirements.
One-on-one field interviews (called contextual interviews):
are undertaken by every member of the design team, each lasting about one-
and-a-half to two hours. These interviews focus on matters of daily life (work and
home) that are relevant for the project scope. Contextual inquiry uses a model
of master/apprentice to structure data gathering, based on the idea that the
interviewer (apprentice) is immersed in the world of the user (master), creating
an attitude of sharing and learning on either side.
Four principles guide the contextual interview, each of which defines an aspect
of the interaction and enhances the basic apprenticeship model.
Which are:
1) The context principle: emphasizes the importance of going to the user,
wherever they are, and seeing what they do as they do it. The benefits of this are
exposure to ongoing experience instead of summary data, concrete details
rather than abstract data, and experienced motives rather than reports.
2) The partnership principle: creates a collaborative context in which the user
and interviewer can explore the user’s life together, on an equal footing. In a
traditional interview or workshop situation, the interviewer or workshop leader is in
control, but in contextual inquiry, the spirit of partnership means that
understanding is developed together.

3) Interpretation: turns the observations into a form that can be the basis of a
design hypothesis or idea. These interpretations are developed collaboratively
by the user and the design team member to make sure that they are sound.
4) Focus: is established to guide the interview setup and tells the interviewer what
they need to pay attention to among all of the detail that will be unearthed.
The contextual interview is also guided by a set of “cool concepts.” Cool
concepts are an addition to the original contextual inquiry idea, and they are
derived from a field study that investigated what it is about technologies that
users find “cool”
Seven cool concepts emerged from this study, and they are divided into two
groups: four concepts that enhance the joy of life and three concepts that
enhance the joy of use.
• The joy of life: concepts capture how products make our lives richer and
more fulfilling. These concepts are: 1) Accomplish (empower users).
2) Connection (enhance real
relationships),
3) Identity (support users’ sense of self).
4) Sensation (pleasurable moments).
• The joy of use: concepts describes the impact of using the product itself;
they are: 1) Direct in action (provide fulfillment of intent).
2) The hassle factor (remove all glitches and inconveniences).
3) The learning delta (reduce the time to learn).
The contextual interview has four parts:
(Getting an overview, the transition, main interview, and wrap-up). The first part
can be performed like a traditional interview, introducing each other and setting
the context of the project. The second part is where the interaction changes as
both parties get to know each other, and the nature of the contextual interview
engagement is set up. The third part is the core data gathering session when the
user continues with their activities and the interviewer observes them and learns.
Finally, the wrap-up involves sharing some of the patterns and observations the
interviewer has made.
During the interview, data is collected in the form of notes and initial Contextual
Design models and perhaps audio and video recordings. Following each
contextual interview, the team holds an interpretation session that allows the
whole team to talk about the user and hence establish a shared understanding
based on the data.

During this session, specific contextual design models are also generated or
consolidated. There are 10 models suggested by Contextual Design, and the
team can choose the most relevant for the project.
Brainstorming for Innovation
Brainstorming is used in requirement gathering to get as many ideas as possible
from group of people. Generally used to identify possible solutions to problems,
and clarify details of opportunities. So Brainstorming is a generic technique used
to generate, refine, and develop ideas. the participants know that no ideas are
criticized or debated.
There are suggestions for successful requirements brainstorming sessions are as
follows (Robertson and Robertson, 2013; Kelley with Littman, 2016)
1. Include participants from a wide range of disciplines with a broad range of
experience.
2. Don’t ban silly stuff.
3. Use catalysts for further inspiration.
4. Keep records. Capture every idea, without censoring.
Personas and Scenarios:
User stories capture the essence of a requirement, but neither of them is sufficient
on their own to express and communicate the product’s purpose and vision.
Both can be
augmented with
prototypes, working
systems,
screenshots,
conversations,
acceptance
criteria, diagrams,
documentation,
and so on.
But these two
techniques
complement each
other in order to
bring realistic detail
that allows the
developer to
explore the user’s
current activities, future use of new products, and future visions of new

technologies. They can also guide development throughout the product
lifecycle.
Goals:
• express and communicate the product’s purpose and vision.
• augment the basic requirements information
• bring requirements to life
• help the designer make design decisions
• remind the team that real people will be using the product
• develop solutions, products and services based upon the needs and
goals of your users.
• express enough understanding and empathy to understand the users.
1. Personas:
What is a persona?
Personas are rich descriptions of typical users of the product under development
on which the designers can focus and for which they can design products. They
don’t describe specific people, but rather they are realistic, and not idealized.
Any one
persona
represents
a synthesis
of a
number of
real users
who have
been
involved in
data
gathering,
and it is
based on
a set of
user
profiles.
Each
persona is
characterized by a unique set of goals relating to the particular product under
development. In addition to their goals, a persona will include a description of
the user’s behavior, attitudes, activities, and environment. These items are all
specified in some detail.

A product will usually require a small set of personas rather than just one. It may
be helpful to choose a few, or maybe only one, primary personas who represent
a large section of the intended user group.
Persona format tips:
The style of personas varies widely, but commonly they include a name and
photograph, plus key goals, user quotes, behaviors, and some background
information. Main persona creation steps are:
• Hard Facts
• Interests and Values
• Computer, Internet and TV Use
• A Typical Day
• Future Goals
2. Scenarios:
What is a scenario?
A scenario is an “informal narrative description”. It describes human activities or
tasks in a story that allows exploration and discussion of contexts, needs, and
requirements. It does not necessarily describe the use of software or other
technological support used to achieve a goal.
During the requirements activity, scenarios emphasize the context, the usability
and user experience goals, and the activities in which the user is engaged.
Scenarios are often generated during workshop, interview, or brainstorming
sessions to help explain or discuss some aspect of the user’s goals.
Scenarios can be text, audio or video. They found that the animated scenarios
helped participants to describe problems better
Scenario types:
• Goal- or Task-Based Scenarios: state only what the user wants to do. Do
not include any information on how the user would complete the
scenario. These scenarios are useful in helping to define your site
architecture and content. You should give these types of scenarios to
users in a usability test. It gives them a reason and a goal for going to the
site, but it lets them show you how they would use the site to accomplish
that goal
• Elaborated Scenarios: give more user story details. These details give the
Web team a deeper understanding of the users and users’ characteristics
that may help or hinder site interaction. Knowing this information, the

team is more likely to develop content, functionality, and site behavior
that users find comfortable and easy to work with.
• Full Scale Task Scenarios include the steps to accomplish the task. A full-
scale scenario can either report all the steps that a specific user currently
takes to accomplish the task or it can describe the steps you plan to set
up for users in the new site. Scenarios at this level are very similar to use
cases, but they lay out the steps from the user's point of view rather than
from the website's point of view. They explain how the site supports the
goal-oriented scenarios that you started with.
Use-cases:
Use cases focus on what the users are trying to achieve. Understanding why
people do things as they do and what they are trying to achieve in the process
focuses the study on human activity rather than interaction with technology.
What is a use-case?
A use case is a written step-by-step description of how users will perform tasks on
your website. It outlines, from a user’s point of view, a system’s behavior as it
responds to a request. Each use case is represented as a sequence of simple
steps, beginning with a user's goal and ending when that goal is fulfilled.
Benefits of a use-case:
Use cases add value because they help explain how the system should behave
and, in the process, they also help brainstorm what could go wrong. They

provide a list of goals and this list can be used to establish the cost and
complexity of the system. Project teams can then negotiate which functions
become requirements and are built. It includes:
• Who is using the application?
• What the user wants to do?
• The user's goal
• The steps the user takes to accomplish a particular task
• How the application should respond to an action
Elements of a Use Case:
• Actor – anyone or anything that performs a behavior (who is using the
system)
• Stakeholder – someone or something with vested interests in the behavior
of the system under discussion (SUD)
• Primary Actor – stakeholder who initiates an interaction with the system to
achieve a goal
• Preconditions – what must be true or happen before and after the use
case runs.
• Triggers – this is the event that causes the use case to be initiated.
• Main success scenarios [Basic Flow] – use case in which nothing goes
wrong.
• Alternative paths [Alternative Flow] – these paths are a variation on the
main theme. These exceptions are what happen when things go wrong at
the system level.

Discover Requirement

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Discover Requirement

Semelhante a Discover Requirement (20)

Último

Último (20)

Discover Requirement