Usability requirements and their elicitation

Lucas Machado, Menglin Xu,

Muhammad Qasim, Silvia P. H. Rubio

(SIS) School of Information Sciences – University of Tampere

October 25, 2013

Abstract

This essay is a result of a group work about us-

ability requirements, testing and their elicitation for

the Requirements Engineering course. The content

of this article is organized as follows: Section 1

introduces concepts and general ideas, Section 2 is

about usability requirements styles and testing, and is

based mainly in the article by Lauesen and Younessi

(1998). Section 3 is based mainly in the article

by Jos Trienekens (2012) and is about categorizing

usability requirements elicitation methodologies and

exploring the most suitable of them for determined

project needs. In Section 4, some practical experience

with requirements engineering of one of the authors

is reported. Finally, Section 5 gives the conclusions.

Key concepts: usability requirements,

methodologies for eliciting and analyzing us-

ability requirements, usability testing.

1 Introduction

Engineering involves building of purposeful artefacts

often known as machines. Software engineering as a

subdiscipline of engineering, concerns with the config-

uration of a general-purpose machine (the computer)

to work for a specific purpose. Before building a ma-

chine or artefact to fulfil a specific purpose, it is im-

portant to understand what that purpose is. This

understanding and knowledge of the purpose leads

us to requirements engineering; an approach to pro-

cure useful specifications (requirements) which aid in

deciding on how to build an artefact. Requirements

engineering is, as its name suggests, the engineer-

ing discipline of establishing user requirements and

specifying software systems (Sutcliffe, 2013). It in-

volves finding out what people expect from a soft-

ware system and specifying their expectations (pur-

pose of software system) in terms of software sys-

tem design. Nuseibeh and Easterbrook (2000) give

a more comprehensive definition as ”software sys-

tems requirements engineering (RE) is the process of

discovering that purpose, by identifying stakeholders

and their needs, and documenting these in a form

that is amenable to analysis, communication, and

subsequent implementation”.

Requirements of a software system are gathered

and implemented to produce a usable system. To en-

sure the easiness of use and acceptance of this system,

its usability must be validated. Usability is a quality

attribute of a system. It is the extent to which spe-

cific users to their satisfaction can perform a specific

goal effectively and efficiently in a specified context

(ISO, 1998). The usability of a system is stated by us-

ability requirements. Usability requirements are the

specifications that incorporate five usability factors:

1. Ease of learning: Both novice and experienced

users must quickly learn the system.

1

2. Task efficiency: The system must be swift and

responsive for user tasks.

3. Ease of remembrance: The system function-

ality must be easy to remember by casual users.

4. Understandability: The user must under-

stand the system effortlessly.

5. Subjective Satisfaction: The user must be

satisfied with the system after using it.

These requirements may interact with each other,

and so should be prioritized for a particular system.

These requirements are elicited and analysed by var-

ious approaches, for example, by analysing the cur-

rent systems, by observing the interaction of a user

with a system, or by following guidelines and doing

heuristics analysis. Usability requirements play cru-

cial factor in determining the success of a software

system. Accurateness of usability requirements be-

ing transformed into usability features of a system is

directly proportional to the acceptance of the system

by the users. In order to guarantee the acceptance of

the system, validation of the usability requirements is

required which is done by conducting usability test-

ing. Usability testing is a technique to evaluate a

system for usability problems by testing it with real

users. The users with relevant background are pro-

vided with the tasks to test a system or a prototype.

This testing ensures the ease of use, learnability and

satisfaction of a user from the system. Usability test-

ing should not be delayed into the later stages of the

software development process but it should be done

concurrently with production of the components of

a software system. Addressing usability at the re-

quirements stage has the same benefits as consider-

ing other quality attributes early on in the develop-

ment process (Mario R. Barbacci, 2003): “The ear-

lier key quality attribute requirements are identified

and prioritized, the more likely it is that the essen-

tial quality attributes will be built into the system.

It is more cost-effective to reason about quality at-

tribute trade-offs early in the lifecycle than later in

the lifecycle when modifications are often difficult,

impractical, or even impossible.”

There exist many issues regarding the usability re-

quirements elicitation, their methodologies, and their

validation. In this essay, we will discuss two emer-

gent issues. First issue is “What is the relation be-

tween usability requirements elicitation and usability

testing?” and the second issue is “How to iden-

tify the most suitable usability requirements elicita-

tion methodology according to the needs of different

projects/situations?” With regard to first issue, six

styles for usability requirements elicitation are dis-

cussed with focus on their verification, using them

during development process and how usability testing

is useful in eliciting the data for specification. It will

help to understand at what extent theses styles ad-

dress usability issues in a software system. There are

also many methodologies for the elicitation and anal-

ysis of usability requirements available in the litera-

ture. But the challenge is to select the best method-

ology for specific needs. So, in second question we ar-

gue which method/methodologies are the best suited

according to the particular demands of the project

for gathering usability requirements. The results of

this discussion help non-experts of usability to select

the best suited method in accordance to the software

system requirements or project needs.

2 What is the relation between

usability testing and usability

requirements elicitation?

The concept of usability requirements has been de-

scribed previously, but it is important to note that

there are several ways of writing these requirements.

In their paper “Six Styles for usability requirements”

Lauesen and Younessi (1998) explain the different

styles in which usability requirements can be repre-

sented according to the part of the development pro-

cess that they are focused on and it is also described

2

how usability testing is involved in the elicitation of

these requirements. These six styles mentioned in the

paper are: performance, defect, process, subjective,

design and guideline.

Performance-based requirements specify dif-

ferent user groups and a set of tasks- a work that

needs to be completed by the user with help of the

system - that the users must undertake. A perfor-

mance objective is established for each task. If we

consider an ATM system, the following could be an

example of a performance-based requirement:

Customers with ATM experience from other

banks: In their first attempt, they must be

able to withdraw a preset amount of cash

within an average of 2 minutes. (Lauesen

and Younessi, 1998)

In this example, we can identify the user (cus-

tomers with ATM experience from other banks), the

task (withdrawing a preset amount of money) and

the performance objective (taking an average of 2

minutes).

The initial elicitation of performance-based re-

quirements follows the same steps as any other func-

tional requirement by evaluating the stakeholders’

needs and possibly some previous systems. How-

ever, usability testing is used to verify and modify

(if needed) these initial requirements.

There are several techniques in usability testing. If

we consider the previous example of a performance-

based requirement, the testing could be done by

recording a group of ATM users (randomly chosen)

while using the new system and evaluating the way

they interact with it. These users could also be asked

to perform their task while saying what they are

thinking (think aloud usability testing technique) or

even a combination of the two techniques described

previously. Regardless of the testing technique, the

goal of usability testing in this case scenario is to

verify the usability requirements initially elicited and

evaluate whether the performance objectives need to

be changed or refined and most importantly if any

new usability requirements emerge.

Usability testing in this style covers most of the us-

ability factors, however, subjective satisfaction can-

not be analyzed with this kind of requirements as it

only provides the information on how well the user

performs a task and even though they do well in one

particular task, their overall impression on the sys-

tem can be different.

Defect-style requirements are very similar to

performance-based ones, they also work with tasks

but the main focus is on the limit of usability prob-

lems that users can encounter while performing this

task. A usability problem arises when a user makes

mistakes or finds difficulties while using the system.

For instance, if we think of the ATM scenario this

could be an example of a defect-style requirement:

Customers with ATM experience from other

banks: In their first attempt, no more than

0.2 task failures can be encountered. (Laue-

sen and Younessi, 1998)

The same kind of usability tests proposed to verify

performance-based requirements could be used in this

case. However, since the focus is in usability prob-

lems, these have to be counted and then the data ob-

tained can be analyzed. The importance of counting

usability problems is that they can reveal usability

defects which are the defects in the system design

that cause the usability problems. To reveal usabil-

ity defects feedback needs to be collected from users,

an example of this would be interviewing a user and

asking: “What did you find difficult in this particular

task?” when referring to a task where the user failed

or had difficulties with.

Once again, usability testing provides a way to get

feedback from users that allows the validation and

refinement of the initial requirements and even the

elicitation of new ones. It is also important to point

out that these tests can be executed even before the

system is ready with the use of prototypes, this is

3

important to guide the development process in the

right direction.

As with performance-based requirements, the sub-

jective satisfaction cannot be tested with this kind of

requirements because the fact that users do not en-

counter problems in certain tasks does not mean that

they will be satisfied with the complete system.

Depending on the system being implemented, per-

formance objectives and usability defects may be dif-

ficult to identify. In these cases, it is better to spec-

ify the requirements that will ensure usability and

how they will be addressed during the design process

rather than the usability requirements on the product

itself.

An illustration of this process-style require-

ment is the following:

During design, a sequence of 3 prototypes

has to be made. Each prototype must be us-

ability tested and the most important defects

corrected. (Lauesen and Younessi, 1998)

In this example we can observe instructions that

must be followed during the design process to achieve

usability. Even though these requirements do not al-

ways specifically request usability testing, most expe-

rienced developers will request usability testing dur-

ing the design and development process as getting

feedback from users is the only way to make sure

that usability is achieved.

With process style requirements, the usability fac-

tors measured depend on the requirements chosen by

the developers, the downside of this type of require-

ments is that they only address usability testing dur-

ing the design process and usability factors could not

be tested after this stage.

Another way of eliciting the requirements is based

on measuring the user experience as a whole. This

style of requirements is subjective and its measure-

ment can be imprecise as different users may have

completely different perspectives of the same issue,

however, a general idea of the usability of the prod-

uct can be obtained.

For instance, one subjective-style requirement

in the ATM case scenario would be:

80% of customers having tried the ATM

at least once must find the system helpful.

60% must recommend it to friends if asked.

(Lauesen and Younessi, 1998)

In this example, we can observe that the require-

ment is not related to any task in particular but for

the satisfaction of the system as a whole. Usability

testing is again required to validate that the require-

ments are being met; during the development period

and most importantly after the product is ready, feed-

back from the users has to be collected to verify that

users are satisfied with the product.

This requirement style is, as its name states, partic-

ularly good for analyzing the subjective satisfaction

factor. However, this is a very complex factor to ana-

lyze because satisfaction can vary among users (even

in the same situations) depending on the culture and

even their personality.

Design-style requirements specify what the

prototype design should look like. These require-

ments are set by the requirements engineer and un-

like other usability requirements, which are consid-

ered as non-functional requirements, design-style re-

quirements are part of the functional requirements of

the system as they specify what the prototype should

have.

An example of this style would be the following:

The menu points and push buttons shall

function as shown in App. yy

With this approach, inspections and validations are

necessary throughout the development process. Simi-

larly to previous requirements styles, usability testing

is used in design-style requirements to get feedback

from users and evaluate if the requirements are cor-

rect and complete.

Moreover, usability testing in design-style require-

ments is also used to elicit the initial usability re-

quirements. In order to do so an initial prototype is

4

built and tested, after that, the feedback obtained in

these tests is used as the initial requirements for the

design.

Experts have suggested many guidelines to achieve

usability, some companies even have their own guide-

lines that they follow when developing a new sys-

tem. The last requirements described in the paper

are guideline-style requirements, which are basi-

cally focused on how the final product must meet the

specifications of certain preset guidelines.

The following is an illustration of a guideline-style

requirement:

The system shall follow the MS-Windows

style guide. (Lauesen and Younessi, 1998)

Following this kind of requirement style is a chal-

lenge because inspections and verifications can re-

quire too much work (guidelines are usually too long)

and still not lead to usability. Once again, a solution

to this problem is usability testing, after selecting the

guidelines that the system will follow a prototype can

be built and tested. Testing is used to refine this first

prototype according to the user’s needs and then this

prototype can be used as the guideline that develop-

ers need to follow.

To sum up, there are several styles in which usabil-

ity requirements can be elicited. Each style focuses

on different aspects of the development process but

all of them have usability as a common goal. Also,

usability testing is closely involved in the elicitation

process of these usability requirements, it is generally

used as a way to validate that the initial requirements

are being met, to refine initial requirements and in

some cases even to elicit new or initial usability re-

quirements.

3 How to identify the most

suitable Usability Require-

ments Elicitation Methodol-

ogy according to the needs of

different projects/situations?

Usability Requirements Elicitation is a complex task

that should not be performed without following a

structured methodology. There are several different

methodologies to elicit usability requirements and as

more options become available to those project man-

agers and developers there is an emerging need to

identify which of the methodologies is more suitable

for a project in terms of cost, time and effort.

Jos Trienekens (2012) propose a framework to com-

pare what they consider the four most important ap-

proaches in the requirements elicitation and analy-

sis (i.e. The Usability Engineering Lifecycle (UEL),

The Delta Method, Approach Centered on Usabil-

ity and Driven by Use Cases (ACUDUC) and Guide-

lines for Eliciting Usability Functionalities (GEUF)).

However, in this paper we will focus in understand-

ing how the framework works and how it can help

project managers identify the best methodology for

their project. In order to do so, only the Delta

Method and the Usability Engineering Lifecycle will

be addressed.

The framework divides each methodology into

several methods, which are single functions of the

methodology, and then evaluates each one of these

methods according to some preset criteria. Conse-

quently, an overall score is assigned to the methodol-

ogy based on the individual scores of all the methods

for a specific criterion.

The criteria are divided into four categories: ex-

ternal factors, characteristics, maintaining the in-

tegrity of the specifications and quality and effective-

ness. Each category encircles the criteria related to

that area, criterion are basically questions about the

method. The set of categories and their criteria are

5

the following:

A. External factors: This refers to the environ-

ment in which the project is to be developed. Three

main questions are the subcategories in this criterion:

• C1.1. Does a methodology/method need

a human computer interaction (HCI) ex-

pert? A score of (+) is assigned if the method

needs an HCI expert, (-) if not needed.

• C1.2. Does a methodology/method need

access to representative users? A score of

(++) is assigned if the method needs a deep of

involvement from the users, (+) if needs involve-

ment from users, (-) if involvement is not needed.

• C1.3 Does a methodology/method work

with non-experienced users? A score from

1 to 5 is assigned to represent how much experi-

ence a user must have for this particular method.

This may not be applicable to some methods.

B. Characteristics: This refers to the character-

istics of each methodology. There are two criteria in

this category:

• C2.1. Does a methodology/method give

strict guidance to help the developers to

carry it out?

• C2.2. Does a methodology/method take

the user feedback into account for further

improvement?

C. Maintaining the Integrity of the Specifica-

tions: This category encircles the criteria related

to the effort required by methods. Two criteria are

specified in this category:

• C3.1. Is a methodology/method time con-

suming?

• C3.2. Is a methodology/method common

in the software development process?

D. Quality and effectiveness: The criteria in

this category address the level of detail that is elicited

using the methodology/method.

• C4.1. Does a methodology/method elicit

enough information to help the developer

specify the fit criterion?

• C4.2. Does a methodology/method elicit

the dependencies between the usability re-

quirements and other functional and non-

functional requirements?

Now that all the criteria have been explained, it

is important to understand each methodology to an-

alyze their representation in the framework. First,

we will describe the Usability Engineering Lifecycle

(UEL) methodology which was one of the first to pro-

vide methods to incorporate usability engineering in

the product development process. UEL methods can

also be applied in the usability requirements elicita-

tion and analysis, these methods are the following:

Know the user refers to obtaining information

about the users (e.g. job, gender, computer experi-

ence, etc.), observing users do their tasks and their

interaction with the system, as well as follow their

learning of the system.

Competitive analysis refers to doing heuristic

analysis (using given usability guidelines) and proto-

typing on existing (competition) products. Products

from the competition are a very good source for pro-

totyping as they are currently working products and

analysis on their strengths and weaknesses can con-

tribute to a good design.

Setting usability levels indicates establishing a

set of usability goals beyond the main five usability

characteristics (e.g. learnability, subjective user sat-

isfaction, etc.). To do so, levels of usability should be

defined (i.e. worst acceptance level, planned usabil-

ity level, current level and best possible level) that

indicate specify measurable usability goals.

Participatory design means involving the repre-

sentative users in the design by having regular meet-

6

Figure 1: Analysis results for the UEL methodology. (Jos Trienekens, 2012)

ings with the designers. Users can ask questions and

help to discover problems with the designers’ vision

of the task and the real task.

Coordinated design means having one (or more)

coordinator(s) that can supervise the user interface

design in order to achieve consistency not only in

the current design but in further development of the

product (e.g. future versions). Agreements on the

user interface design, prototyping and following stan-

dards are also recommended to achieve consistency.

Guidelines and heuristic analysis encircles fol-

lowing pre-established guidelines (e.g. usability, user-

interface design, product-specific, etc.) and perform-

ing heuristic evaluations based on such guidelines.

Prototyping indicates building and testing differ-

ent prototypes throughout the development process,

it is recommended to prototype early and often to

avoid extra effort in implementation of unnecessary

or erroneous assumptions of the user needs.

Empirical testing refers to users performing tests

on the product and then analyzing the collected re-

sults. Testing can be done with early or late versions

of the product.

Collect feedback from field use is a method

similar to empirical testing.

Figure 1 shows the extract of the framework pro-

posed in Jos Trienekens (2012) paper that corre-

sponds to the UEL methodology. We can observe

that each method has been evaluated with all of the

criteria and then an overall score was assigned to the

methodology based on the combination of all the in-

dividual scores.

Based on the information in the table the UEL

methodology:

• Needs advice from a HCI expert.

• Needs frequent access to the representative users

of the product in most of the methods.

• Does not require experienced users

• Does not provide strict guidance to developers.

• Gets users’ feedback to improve usability.

• Requires a lot of effort from the developer team.

• Does not provide a lot of methods commonly

used in the software engineering process.

• It provides the developer with enough informa-

tion to elicit requirements.

• It provides enough information to elicit the de-

pendencies between requirements.

As an example, we can think of the manager of a

new mobile app project who has his/her customers

spread in five different countries and needs to launch

7

Figure 2: Analysis results for the Delta method. (Jos Trienekens, 2012)

this product in less than two months with a small

group of novice programmers. Just by using this

framework in less than five minutes he/she could de-

cide that this methodology is not suitable for this

particular project for several reasons: it demands a

lot of time and effort, it requires constant access to

the users and it provides no guidance for the novice

developers.

The second methodology that we will be discussed

in this paper is the Delta method. This methodology

is a task-based and usability-oriented approach used

in requirements engineering. It consists of the five

following methods:

Pre-study addresses the evaluation of the “hard”

requirements (e.g. policies, industry standards, etc.)

and the agreement on a vision scope from all parts

involved.

User profiling involves recording an overview of

the users by means of a questionnaire containing

users’ preferences, problems, main tasks, etc.

Task Analysis refers to interviewing the different

representative users of the system in order to identify

and describe their working tasks in detail including

information about the current problems they have in

performing these tasks.

Usability specification refers to agreeing on the

desired level of usability which is established in a

measurable form that can be tested later on in the

process; the inputs for this process are the concep-

tual design and the previous documentation.

Prototyping and Usability Testing indicates

that a first paper-based prototype is built and tested

(using the usability specification) and based on the

feedback collected from users are the foundations for

the design process. These steps are repeated through

the entire development process with several proto-

types until the goals are achieved.

Figure 2 contains the extract of the framework

proposed in Jos Trienekens (2012) paper that cor-

responds to the Delta method. Once again, each

method was evaluated with all the criteria and an

overall score for the methodology was derived from

the combination of all the methods and criteria.

Based on the information in the table the UEL

methodology:

• Does not need advice from a HCI expert.

• Needs access to the representative users in all

the methods.

• Requires moderate experience from users.

• Provides strict guidance to developers (through

questionnaires, usability specifications, etc.).

• Gets users’ feedback to improve usability in some

of the methods.

• Does not require a lot of effort from the devel-

oper team.

• Some methods are commonly used in the soft-

ware engineering process.

8

• It provides the developer with enough (not quan-

titative) information to elicit requirements.

• It does not provide enough information to elicit

the dependencies between requirements.

If we consider the same example from above (the

project manager dilemma), he/she might consider

this a more suitable methodology in this particular

project for the following reasons: it does not require

a lot of effort (less time-consuming), it requires less

experience from the developers as it provides guid-

ance and even though it still needs involvement from

the representative users it can be completed faster.

Finally, there is probably not a “perfect” method-

ology for a project but since each project has its own

priorities this framework can be a precise and reli-

able tool to analyze the benefits and drawbacks of

each methodology, it can help managers make the

necessary trade-offs and ultimately choose the most

suitable methodology to elicit usability requirements.

4 Practical experience

It is possible to observe the software engineering tech-

niques, as well as the usability requirements elicita-

tion in the practical work experience of one of the

authors. As an example, there was a system being

developed that went through by three different stages

in the company, these stages are described as follows:

In the first stage, the company was not using the

proper requirements-engineering techniques in the

project. So the objective of the requirements engineer

was actually just generating documentation, and the

requirements quality was poor.

In the second stage, when some parts and compo-

nents of the system were being be integrated, a lot of

problems and conflicts were found due to the lack of

specification and poor interfaces. With this problem

in hands, the team managed to redo all the require-

ments specification of the components that were in

trouble, but did not update all the documentation.

In the third stage, when the user interfaces were be-

ing coded and tested, some of them were not needed

anymore, and there was the need for other interfaces

that were not specified too. Also, in the developed

interfaces, a lot of problems of usability were found

because the requirements were not correctly managed

and there was no much attention to them.

With all of that, the user interfaces of the system

had to be rebuilt, but at this time, guidelines, check-

lists of common features, and usability testing were

established, so the system could finally have an ac-

ceptable services quality and easy of use. However,

the project used much more resources and time than

what was originally planned.

This example clearly shows the importance of the

requirements engineering, and the need to have clear

and well-developed requirements. Also, in the last

stages the usability requirements suffered the same

problems as the functional ones, then needing an-

other set of rework to fix them. With well-designed

functional and usability requirements, and using us-

ability testing, the project was finished. If a method-

ology of usability requirements elicitation was used

since the beginning along with good processes of func-

tional requirements development, the project could

have saved extra expenses.

5 Conclusion

Usability is an important feature in a software, and

can be determining in its success. It influences the

system performance, adoption and easy to use, but

often does not receive the deserved attention in the

development and it is hard to analyze, recognize the

gaps and implement them.

To help solve this issue, there are methodologies

in the requirements engineering that can be used to

gather and establish usability requirements. Usabil-

ity testing can also be used to detect usability prob-

lems in the system and correct or prevent them (de-

pending on the style, testing can be done with a func-

9

tional software or even with prototypes or design).

There are differences between the methodologies in

a way that we need to choose a proper one based

in the needs of the project. The first addressed

methodology of the described UREAM framework by

Jos Trienekens (2012) (Usability Engineering Lifecy-

cle) is more suitable to large scale projects in large

companies as it requires several resources and a great

amount of effort and time. The second addressed

methodology, the Delta Method, is easier to apply

as it not requires many resources (like experts or

user involvement) and is less time-consuming. Then

it should be appropriate for smaller and simpler

projects.

It is also possible to skip some of the methods

within a methodology, as well as adding others de-

pending on the project or system needs. The method-

ologies should be interpreted as good practices and

not as strict instructions.

The different styles of usability requirements elic-

itation are all aimed at improving the usability of a

system in different ways and by complementing all

of them we can have a wide coverage over the main

usability problems that can occur in a system.

Finally, usability testing can be closely involved

with the requirements elicitation as a way to improve

the general usability. When a system is already func-

tional, they can refine or create new requirements

based on feedback, or they can even prevent usabil-

ity problems during the design or prototyping stages

by eliciting initial requirements.

With a proper selection of the usability require-

ments methodology and/or methods, along with in-

tegrated usability testing, depending on the style of

these methods of requirements elicitation, it is possi-

ble to minimize the problems and improve or achieve

a high level of usability in a system.

6 Division of work

The work division for writing this essay was mainly

based in its sections. Section 1 was written by

Muhammad, Section 2 was written by Silvia, Sec-

tion 3 was written by Menglin with Silvia’s help, and

finally Sections 4 and 5 were written by Lucas. Ad-

ditionally, all the group members revised the entire

document and made corrections.

References

P. Carlshamre and J. Karlsson. A usability-

oriented approach to requirements engineering.

In Requirements Engineering, 1996., Proceed-

ings of the Second International Conference on,

pages 145–152, 1996. doi: 10.1109/ICRE.

1996.491439. http://ieeexplore.ieee.org/

xpl/articleDetails.jsp?arnumber=491439.

ISO. ISO 9241-11:1998 Ergonomic requirements for

office work with visual display terminals (VDTs)

– Part 11: Guidance on usability. Technical

report, International Organization for Standard-

ization, 1998. http://www.userfocus.co.uk/

resources/iso9241/part11.html.

Rob Kusters Jos Trienekens. A framework for

characterizing usability requirements elicitation

and analysis methodologies (uream). In ICSEA

2012, The Seventh International Conference on

Software Engineering Advances, page 308 to

313, Lisbon, Portugal, November 2012. IARIA.

http://www.thinkmind.org/index.php?view=

article&articleid=icsea_2012_11_30_10254.

Søren Lauesen and Houman Younessi. Six styles

for usability requirements. In Eric Dubois,

Andreas L. Opdahl, and Klaus Pohl, edi-

tors, REFSQ, pages 155–166. Presses Univer-

sitaires de Namur, 1998. ISBN 2-87037-272-

8. http://dblp.uni-trier.de/db/conf/refsq/

refsq1998.html#LauesenY98.

10

Anthony J. Lattanze Judith A. Stafford Charles

B. Weinstock William G. Wood Mario R. Bar-

bacci, Robert J. Ellison. Quality attribute

workshops (qaws), third edition. Technical

report, Software Engineering Institute, 2003.

http://resources.sei.cmu.edu/library/

asset-view.cfm?assetID=6687.

J. Nielsen. The usability engineering life cycle. Com-

puter, 25(3):12–22, 1992. ISSN 0018-9162. doi: 10.

1109/2.121503. http://ieeexplore.ieee.org/

xpl/articleDetails.jsp?arnumber=121503.

Bashar Nuseibeh and Steve Easterbrook. Require-

ments engineering: a roadmap. In Proceedings of

the Conference on The Future of Software Engi-

neering, ICSE ’00, pages 35–46, New York, NY,

USA, 2000. ACM. ISBN 1-58113-253-0. doi: 10.

1145/336512.336523. http://doi.acm.org/10.

1145/336512.336523.

Alistair G. Sutcliffe. Requirements Engineering

from an HCI Perspective. The Interaction Design

Foundation, Aarhus, Denmark, 2013. http://

www.interaction-design.org/encyclopedia/

requirements_engineering.html.

11