Week 1 lecture 1

Computer:-
In the older generation, Computers are generally referred only as desktop or laptop. But in today's
modern world they can be smartphones, digital watches, tablets, ect. However they're alone, not the
computer that we use in our day-to-day life. For example digital pedometer, microwave oven, smart tv.
So, the common connection between all the example systems is that they interact and solve complex
tasks. This interaction happens between user and system. These users are laymen users (i.e) not
technology experts.
The users may need a basic knowledge about the technology to solve or understand the problem that
arises in the system such as system error messages. If the user doesn't have any knowledge about the
system when a problem arises and if he is not able to understand it, this makes him frustrated, makes the
user anxious about whether he did something wrong, how to get out of it, should we refrain from
performing any more things. This may lead to loss of motivation to further use. To solve this problem
user-centric designs are introduced. The system design should not force the user to learn about the
underlying technology. The main challenge is how to design a system or product that the user finds easy
to use.

USER-CENTRIC DESIGNS
The process to design products, which are computers, in which the users' needs and expectations
are taken care of by considering their characteristics. Ex:- Tv remote. While designing the user-centric
designs we need to consider
● Design the element that are acceptable to the user
● Design the layout that meets user expectations.
● Help the user to perceive the system state
● Design the interaction that fulfils the needs of the users, by taking them to the desired system
state.

Historical evolution (4 phases):-

1. The prehistory (1940's-1970's) - This is before the advent of personal computers
2. The early phase (1980's till the early 21st century) - the era of personal computers
3. The Pre-modern phase (late 1990's - first decade of the 21st century) - widespread use of mobile
personal computing devices, notably smart-phones and tablets.
4. The Modern age (2011 onwards) - era of interconnected devices.
Week 1 lecture 2
Core concern - incorporating humans into the design.

Human factor:-
A computer can be used by various types of people, laymen and non-laymen users. Even Though
needs and expectations may differ between different types of user, technically they may aim to perform
the same work. While designing the system we should first understand and categorize the users.

User classification:-
● We need to know the user in order to design.
● Generic classification of user (laymen user)
○ Novice - beginner
○ Intermittent - unoften user
○ Expert - often user

Interdisciplinary:-
Identifying human factors and incorporating those in the design requires knowledge and expertise
in many fields of studies.
Considering human in design:-
The same term (user-centric design) can be viewed by different stakeholders in different ways.
● Designer- creative design(interface element and layouts).
● (industrial) product designer- shape, size, look,ect.
● Electronic engineer- adding more features at hardware level.
● Application Software developer- they need to follow a development life cycle that takes
care of users’ needs and expectations.
Usability :-
We require an explicit measure to judge our design - if we have taken care of the human
factor.this measure is called usability.
Three crucial aspects in the definition of usability:-
● The product is meant to be used by a specified group of users. In other words, a usable product
need not be designed "for all".
● The product should allow the users to achieve a specified set of goals. Thus, putting every
conceivable feature in a product does not necessarily lead to a usable product.
● The product should be designed for specified context of usage. Clearly, a usable product need not
be so for "all" usage scenarios.
Definition reveals THREE measures
● Effectiveness
● Efficiency
● Satisfaction

“Jacob Nielsen [2012] argued that usability alone can’t make a product “useful”.”
An acceptable product should have both usability and utility.

Nielsen proposed 5 quality component of usability:-

● Learnability: the "ease" with which a first time (novice) user performs "basic" tasks with the
system
● Efficiency: The speed at which the users can complete tasks
● Memorability: The "ease" with which an intermittent user, who returns to use the system
occasionally (after some gaps), can reestablish "proficiency"
● Errors: The rate at which the users make errors, the "severity" of those errors and "ease" with
which the users can recover from errors
● Satisfaction: How pleasant is it to use the design
If we compare Nielsen’s framework with ISO definition, we observe the “effectiveness" might be mapped
to “utility”. The ISO definition therefore provided only two measures for usability: the efficiency and
satisfaction. The five components of usability offer a more precise measure.

User-centered design:-
Term coined by Shneiderman (1986). Objective to design products that increase usability. Indicates
active/passive involvement of users in the design life cycle.
Related terms to user-centric designs:-
● "Cooperative design" [Greenbaum and Kyng, 1992]
● "Participatory design" [Schular and Namioka, 1993]
● "Contextual design" [Beyer and Holtzblatt, 1997]
● ISO in its standards prefers to use the term "human-centered design"

Week 1 lecture 3
To achieve that, we need a systematic approach.

Engineering a software
SDLC: build software in stages.
This process is important because it gives us a systematic look at problems in software development.
Waterfall model(fundamental model):-
This is also a well-known SDLC model although rarely used in practice. It is a stage wise Model to build
a software. There's 7 stages in the classical model.
● Feasibility study
● Requirement gathering, analysis and specifications
● System design
● Coding and unit testing
● Integration and system testing
 ● Deployment
● Maintenance
This model's stages depict a waterfall design as the name suggests.
In the iterative model the stages have iteration between states.

Spiral model:-
It is a meta-model that encompasses other SDLCs. This is not a fundamental model like a waterfall
model. It captures high-level concerns and activities that are required to implement a lower-level
fundamental-level software development life cycle. Through the iterations, progressively more complete
version of software gets built. There are 4 quadrants,
● Identify the objectives
● Risk assessment and mitigation
● Development
● Customer evaluation and planning
Characteristics
Multiple cycles (iteration)
Each spiral is one iteration
Each iteration is divided into multiple quadrants
Spiral model - quadrants
❖ The 1st quadrant - Identify the objectives and risk
➢ Identify the objectives and risks associated with those objectives.
❖ The 2nd quadrant - Risk assessment and mitigation
➢ Analysis of identified risks and steps taken to reduce them
❖ The 3rd quadrant - Development
➢ product/ prototype is developed after resolving identified risks and evaluation.
❖ The 4th quadrant - Customer evaluation and planning
➢ Review the results achieved so far with the customer and plan the next iteration around
the spiral.
 Week 1 lecture 4

To build a user centric software, we need usability which we need to take in concern about the user either
in active or passive mode. But our classical waterfall model focuses on efficient system design rather than
the usable system. In order to implement user-centric design (UCD), we require iteration between stages
to account for user feedback. So, we require a highly interactive life cycle. If we want to do this in a
waterfall model this becomes messy since there are too many iterations. So, In order to handle this we can
refine this life cycle to suit our purpose.
The requirement focuses on usability rather than system requirement.
Before going to empirical study we need to ensure that there are not too many problems because this
empirical study is also a costly affair. Once or twice a loop can be acceptable.

Week 1 lecture 5
In the YouTube video, the main point discussed is the importance of usability requirements in the design
and implementation of human-computer interfaces. The speaker explains the stages of the software
development life cycle for interactive systems, focusing on the requirement gathering, analysis, and
specification stage. They mention the iterative nature of the design process, where the interface and
interaction design are prototyped, evaluated, and refined. The video also touches on code design,
implementation, testing, and the final usability study before deployment and maintenance of the product.
The speaker states that the discussion will skip the feasibility study stage and focus on usability
requirements. Summary: The video discusses the significance of usability requirements in designing
human-computer interfaces. It explains the stages of the software development life cycle, highlighting the
requirement gathering, analysis, and specification stage. The iterative design process, code design,
implementation, testing, and usability study are also mentioned. The feasibility study stage is skipped in
the discussion.

Primary points and key takeaways from the YouTube video: 1. The lecture focuses on usability
requirements in the design and implementation of human-computer interfaces. 2. Interactive systems and
human-computer interfaces are used interchangeably. 3. Usability is a crucial concept in designing
interactive systems. 4. The software development life cycle is a systematic process for developing usable
interactive systems. 5. The stages of the development life cycle include feasibility study, requirement
gathering and analysis, design prototype evaluation, code design, testing, usability study, deployment, and
maintenance. Summaries: 1. The lecture discusses usability requirements in human-computer interface
design. 2. Interactive systems and human-computer interfaces are synonymous terms. 3. Usability is an
important consideration in designing interactive systems. 4. The software development life cycle provides
a systematic approach to develop usable systems. 5. The stages of the development life cycle include
feasibility study, requirement gathering, design prototype evaluation, code design, testing, usability study,
deployment, and maintenance

Week 2 lecture 2
 Design and Implementation of Human – Computer Interfaces
Dr.Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology - Guwahati

Module No # 01
Lecture No # 01
Interactive Systems

Hello and welcome to the NPTEL MOOC’s course on design and implementation of human
computer interfaces. Today we are going to start the course with the first topic that is general
introduction to the interactive systems and brief history. Before we begin let us understand
the scope of this course. So here we are going to talk about design and implementation of
interactive systems.

In other words we will be actually talking about how to engineer quote unquote engineer and
interactive system.
(Refer Slide Time: 01:22)

So there are 2 things involved here one is interactive system or software specifically
computer software that are interactive. So we are going to focus here entirely on software that
is interactive what is interactive software? We will soon learn about those second concepts
that are important here is that word engineering. So here we actually refer to the fact that such
software can be developed in a very systematic manner involving stages and we are going to
learn about those stages.
(Refer Slide Time: 02:06)
Given this scope of the course let us being with the major the primary concept that is
involved here that; is interactive software or interactive system. In general where we will be
implicitly referring to software whenever we; are going to use the term interactive system.
Now these interactive systems whenever we mention this term automatically questions comes
to mind why we are labeling certain software’s as interactive and how these are different from
other software.
(Refer Slide Time: 02:49)

Let us try to understand that little bit in depth so let us begin with the very concept of
computer why never we mention the term computer? What comes to our mind?
(Refer Slide Time: 03:02)
For those who are part of an earlier generation the term computer immediately brings to mind
desktop or Laptops most likely.
(Refer Slide Time: 03:21)

For younger generation the term computer may also refer to along with desktop and laptop
may also refer to smart phones or tabs or even some wire able devices.
(Refer Slide Time: 03:35)
Now this desktop, laptop, Smartphone, tabs are those only the examples of computer let us
see.
(Refer Slide Time: 03:49)

The answer is unequivocal no there are many more computers that we may be using without
being aware of them.
(Refer Slide Time: 04:04)
In fact we are surrounded by such computers let us see one simple example a digital
Pedometer. Is it a computer? To understand this question or to answer this question let us first
go with the definition of a computer. What is a computer?
(Refer Slide Time: 04:21)

According to oxford English dictionary a computer is an electronic device which is capable

of receiving information data in a particular form and of performing a sequence of operations.
In accordance with a predetermined but variable set of procedural instructions which is also
known; as program to produce a result in the form of information or signal. So in a nutshell a
computer take some input apply some program to convert it to some output and the program
performs some operations on this input and this program is pre-stored somewhere.
(Refer Slide Time: 05:11)
Now let us comeback to digital Pedometer whether it is a computer or not. So what a
Pedometer does?
(Refer Slide Time: 05:18)

The main objective of a Pedometer is to identify that the wearer is working or not? Of course
now a day’s Pedometer also have many features but let us only focus on the key function of a
digital Pedometer which is trying to determine the walking speed and the walking distance.
So essentially it tries to identify whether you are walking or not. So in order to do that; it
must differentiate between walking and standing how a device can do that?

When we are trying to do it we visually see the movement and then accordingly our brain
produces the understanding whether somebody is standing or walking. But in that case of a
digital pedometer how it can do that?
(Refer Slide Time: 06:14)

That is one issue second issue is typically digital pedometers are known to keep count of
number of steps.
(Refer Slide Time: 06:27)

So that is another function but as you may understand or as you may try to understand
counting the number of steps is not an easy task. Because you are likely to walk at different
steps at various instance of time in fact as a though exercise you can yourself try to do it try
to count the number of steps that you are performing while walking. And you will understand
the difficulty involved.
(Refer Slide Time: 07:05)
So the pedometer first tries to understand that you are walking then it try to count the steps
the number of steps. And finally from the number of steps it tries to compute the total
distance covered. So how it does that? It has to know some formula for this conversion and
based on that formula it can perform the conversion so, this formula as to be somewhere in
the device.
(Refer Slide Time: 07:43)

So there are 2 things involved one is trying to understand whether you are walking then
counting the steps and then converting it to a distance and the second thing is storing the
relevant formally as well as performing the actual computers. So if we now try to compare
the activities of a pedometer with the definition of a computer we will see that pedometer
accepts as input.
Some sensor information processes it based on the algorithm which is nothing but those set of
formulae. And based on that algorithm it produces some output which is the distance covered
or the walking speed etc. So it perfectly fits the definition of a computer so digital pedometer
we can say is a computer.
(Refer Slide Time: 08:42)

Let us see another example microwave oven many of us might have seen this in our kitchen.
So is it a computer?
(Refer Slide Time: 08:58)

Now if we look inside the oven we will see that it consist of various components broadly
these are the components who are likely to find inside a microwave oven. A magnetron tube,
turn table plate, beeper, door, front panel, display and light these are the components. And
then there is some embedded hardware and software to operate these peripheral devices. As
well as generate certain output those devices.

So here also we can see that it receives some input say for example input from this front
panel in terms of the temperature duration. Then it produces some output on the display as
well as some sound output and it performs certain operations depending on the input provided
based on stored program. So it also is an example of a computer as per definition.
(Refer Slide Time: 10:16)

A third example is a smart TV whether it can be considered as a computer or not.

(Refer Slide Time: 10:25)

Here also there are lots of components involved let us have a look at the software or the smart
TV app which can be understood in terms of layered view of the software where you have
HTML, CSS, Javascript layer, media layer and on so and so forth. So the user provides some
input to the app through some interface then the TV itself has the software which is
connected to some servers to fetch information.

And then that information is processed and displayed on the screen again it takes input
processes based on the stored program and produces output. So as per definition this also is a
computer so these examples so that we are surrounded by computers.
(Refer Slide Time: 11:33)

Now all these are actually examples of interactive computing systems and the interaction
takes place between the computer and the user. Now the most important factor is that these
users are not experts, these users are layman users. Anybody can be the user of the digital
pedometer or microwave oven or a smart TV without any specific qualification. So that is the
defining characteristic of any interactive system or interactive software or interactive
computing system.

That these are systems that are used or interacted with by a user is a layman user who does
not have any specific qualification to be a user of the system. So whenever we will be using
the term interactive system will be referring to such systems where layman users are the users
of the system rather than somebody who has special training to use the system.
(Refer Slide Time: 11:33)
Now this brings us to the next question that we should try to answer is it necessary for the
users to know about the technology behind. So I said that for an interactive system users need
not have any specific qualification. In that case to operate or interact with an interactive
system does, the user need to have any specific technological knowledge.
(Refer Slide Time: 13:24)

Let us see another example some of you may by familiar with this type of display. It used to
come in some earlier operating system, version where they are used to some error messages
displayed in this form. So this is actually an example of an error message produced by an
operating system which used to be there same time ago what it says that? There is a header
which says system error status some number which is actually in hexadecimal code.
And then what it says is that a particular system, a particular app or application initialization
failed because some device attach to the system is not functioning click ok to shut down and
reboot into safe mode. Check the event log for more details and there is only one button to
select which is okay. So whether you like it or not you have to press ok to move forward now
what this message actually tells us.

If I do not know anything about this terms or what is the hexadecimal code what is event log?
What is system accounts manager or security accounts manager? I will not understand
anything from this message although it is shown to user of the system but the user is expected
to have certain level of knowledge as is evident from particular output.
(Refer Slide Time: 15:06)

Now if I do not have that knowledge then I am not going to able to figure out what is that
error and what I am suppose to do. So that will lead me as a user to anxiety. Did I do
something wrong what is that wrong thing I did? How to get out of it? And should we refrain
from performing anymore thing so that such error messages do not come again and again.
That is anxiety that I will have if I do not know the meaning of those messages.
(Refer Slide Time: 15:06)
Now this anxiety or this kind of confusions in the mind of the user may lead to the loss of
motivation which is very important loss of motivation of further use. In effect this will make
the user think that such systems are not for me to use. So rather I should not use it which
actually will defeat the whole purpose of making the system used by the users.
(Refer Slide Time: 15:06)

So these concerns where we want to avoid the user being forced to lose to motivation or
being forced to have confusion because certain knowledge is not there. This concern actually
brings us to these important concepts of user centric design.
(Refer Slide Time: 16:43)

The principle objective for interactive system should be that the system should not force users
to learn about the underlying the technology that should be the guiding principle for any
interactive system otherwise the user will not be motivated to use the system. So accordingly
the system should be designed.
(Refer Slide Time: 17:10)

Now the main concern here is how to design the system so that users find it easy to use. So
that is the main challenge to a interactive system design.
(Refer Slide Time: 17:28)

In order to have a better understanding of this challenge let us discuss an example system
which is ubiquitous most of us have seen it. This is an example if a, TV remote control now
probably all of us have used one of such remote controls.
(Refer Slide Time: 17:56)
What are the activities that are typically with such a device? We can control brightness,
contrast, gamma correction and many more things with the device. We can input channel
number typically 3 digits but it may be different in different locations. To select a particular
channel you can control voice level. We can do certain other things like watch movies from
external devices attached to the TV or watch or view photos or watch videos from our digital
camera after attaching it to the TV. And all these things we can do by interacting with the TV
through this remote control.
(Refer Slide Time: 18:52)

So in the example remote control that we are discussing let us see which portion deals with
which of these activities. Now this top region shown in red circle typically has buttons for
channel change, volume control additionally it also has couple of buttons for change in input
source as well as power on off button.
(Refer Slide Time: 19:28)

There is another group of buttons in the middle of the device which are used occasionally to
navigate various menu options.
(Refer Slide Time: 19:46)

And finally there is a third group of buttons which are rarely used actually many of us may
not even be knowing what are the purpose of these buttons. Because either we never use them
or use them so infrequently that we forgot. So among these 3 groups the first one involving
buttons for channel change or volume control is likely to be most frequently used group of
buttons. Whereas the third group of buttons is the list likely to be used buttons.
(Refer Slide Time: 20:26)
But the thing is that in the same device all these buttons are provided. So this third group
actually supports many more functionalities which we may not require frequently. In fact in
most of the cases we never require it.
(Refer Slide Time: 20:47)

Now the thing to be noted here is that in the same device we have all the buttons are put on
the same device. So same device contains every control options considerable and supported
by the TV when is the result for such a design? It actually succeeds in scaring away many
potential users initially. But of course since it is a very simple device with few days of usage
people tend to learn.
But again as I said this third group of buttons will never be learned because those are very
infrequently used or not used at all. Whereas the first group of buttons is likely to
remembered and used most frequently so what could have been done?
(Refer Slide Time: 21:38)

Instead of designing it in this way it could have been designed in such a way such that the
most frequently used buttons are kept in very prominent way and the least frequently used
buttons are not given the same prominence as the most frequently used that would have
probably emphasized the relative weight of the or relative importance of the buttons to the
users and accordingly the user would have tried to learn them.

So this example tells us that user centric design is very important where it refers to the
process to design products which are computers in which the user needs an expectation are
taken care of by considering their characteristics. So we should know who, are users of this
remote control likely to be everybody what are their needs and expectations as I have already
mentioned.

Mostly they require this first group of buttons accordingly we should have designed and we
probably should have kept the other buttons not in a very prominent position. So that the user
should not; have been intimated it by the presence of so many control options.
(Refer Slide Time: 23:10)
So this remote control we can think of as an interface to the television rather than TV itself.
(Refer Slide Time: 23:21)

Now if we again consider this example so since user centric design is our focus so if we again
consider this example let us try to understand what we are trying to design? What we are
trying to do differently so that this product becomes user centric? Now the remote contents
buttons which we can call as elements of the interface to a computer which is the TV.
(Refer Slide Time: 23:56)
That is the first to note second thing is these buttons are placed in a particular way which
actually defines the geometric layout of the interface.
(Refer Slide Time: 24:11)

That is the second thing to note a geometric layout of the interface then when we interact
with the TV using the remote. For example to select a channel we visually perceive the
system state and its change from the TV screen or from the display so that is the third element
of an interactive system. And finally we continue the performing the operation till we are sure
that till we are achieved what we wanted?

That is the system state matches with our goal state as per our perception so when we are
talking of designing a user centric product or system there are 4 things we should consider.
One is the interface element their geometric layout the perception of the system state and
matching of the system state with our goal state. So these are issues that we should be
concerned about while going for designing a user centric system.
(Refer Slide Time: 25:25)

That means in other words so 4 things we should take care of in user centric design. First
thing is design the elements that are acceptable to the users not the word acceptable then
design layout that meet user expectations. So any layout is not good so first we need to know
the expectation of the users and accordingly we need to design it.
(Refer Slide Time: 25:25)

Then help the user perceive the system state so design the display in such a way. So that the
state of the system from the users point of view is easily understandable.
(Refer Slide Time: 26:10)
And finally design interaction that fulfils the needs of the users by taking them to the desired
system states. So design element, design layout, design display interaction these 4 are the
primary things that are designer of the interactive system should be aware of or should be
conscious about while going for a user centric design.
(Refer Slide Time: 26:41)

So with that let us learn a little bit of how this field that user centric design evolved over time.
So we will briefly mention about the mile stones that have been achieved during this journey
of last few decades.
(Refer Slide Time: 27:05)
So let us briefly learn about the historical evolution of this field of user centric design. So this
evolution we can broadly divide into 4 phases, not very distinct there will be some overlaps
in this phases but we can still broadly divide it into 4 phases.
(Refer Slide Time: 27:33)

The first phase is we can turn it as pre-history which is the period between the nineteen
forties to nineteen seventies in the last century. This is before the advent of the so called
personal computers. So during this phase also as we will see several developments took place
that advanced this field of user-centric design.
(Refer Slide Time: 28:04)
Then comes the early phase which is roughly; from nineteen eighties till the early twenty first
century which is or can be considered as the era of personal computers.
(Refer Slide Time: 28:26)

Then the pre-modern phase late nineteen nineties to the; first decade of the twenty first
century. Now during this; phase widespread use of mobile personal computing devices have
been observed notably smart phones and tablets.
(Refer Slide Time: 28:46)
And finally we can think of the modern age which is continuing which is the era of inter
connected devices. Now let us see what are the mile stones that have been achieved in these 4
phases?
(Refer Slide Time: 29:11)

In the per-history phase that is between nineteen forties to nineteen seventies before the
advent of personal computer. We have several important milestones so in the 1950 the first
video display unit came out which is called the Sage system. Then 1963 one interesting
system was developer called sketchpad by E Sutherland. Now it introduced the idea of
graphical user interfaces and the concept of interaction.

Then can the online system or NLS proposed by Engelbart and team in 1968 which
introduced an important interaction device which is uibiquitous as the Mouse. The release of
first commercial microprocessor named Intel 4004 happened in 1971 which revolutionized
the computing landscape. And finally in 1972 one product was developed although it was not
commercially very successful the Dynabook by Allan Kay which is a precursor to the
personal computers.
(Refer Slide Time: 30:34)

As compared to this phase the early phase had less number of milestones it primarily consists
of the early personal computers Xerox alto which came in 1973 then Altair 8800 1974 Apple
1 1976 and apple 2 1977.
(Refer Slide Time: 31:05)

The most impactful development happened in 1981 with the advent of IBM PC or personal
computer. Then Xerox star in 1981 also introduced the concepts such as graphical user
interfaces then WYSIWYG or what you see is what you get concept then the idea of
metaphors which have profound impact in the development of user centric systems. Almost at
the same time in 1982 the concept of direct manipulation came into being proposed by
Shneiderman.

Then Apple Mac was released in 1984 again another important milestone in that phase the
idea of World Wide Web came about in 1989 and the first wave browser was developed in
1993. So all this actually have profound impacted the advent of the user centric design area.
(Refer Slide Time: 32:20)

In the pre-modern phase we had pump pilot in 1996 which is the first example of the
successful mobile device. Nokia 9000 which came in 1996, then in 2008 Android 1.0 was
released which revolutionized the smart phone landscape. Also during this period other smart
and intelligent consumer electronic products proliferated which again affected the advent of
user Centric design field.
(Refer Slide Time: 33:00)
Finally we came to the modern phase although in this phase the smart phones still there but
the main landmark even that happened is that. Now we are no longer talking about personal
devices the single device instead we are more concerned about connected devices in the
ubiquitous computing environment where the devices are connected to each other to given
better experience to the user.

Now this term was first proposed by Mark Weiser way back in 1991 and during this period
some other related developments happened which are closely related to each other namely the
development of internet of things or rather the development of the concept of internet of
things by Kevin Ashton in 1999. Then the Cyber physical system concept or CPS by Helen;
Gill in 2006.

All these referred to the idea that now the idea of personal computer has been changed from
one user one computer to one user many computers where computers are not treated as
computer rather they are treated as any other real like daily objects. And we just use them like
we use any other objects in our daily like. So we are actually using computers without being
aware of the fact that they are computers. Now this conceptual change happens in this
modern phase which is still going on.
(Refer Slide Time: 35:10)
So with that we have come to end of this first lecture to recap here in this lecture we learned
about what is an interactive system how it is different from other systems? What are the
issues that we should be aware of while going to design an interactive system? And what is
the basic idea of user centric design and a brief historical evolution of the field f user centric
design. The material that I have covered today can be found from this book have a look at
chapter 1 section 1.1, 1.3. So that is all for today see you in the next lecture thank you and
goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology, Guwahati

Module No # 01
Lecture No # 02
Introduction to Usability

Hello and welcome to the course design and implementation of human computer interfaces. So
today we are going to go for lecture 2 namely introduction to usability before we start we will
briefly recap what we have learnt in the first lecture in the previous lecture.
(Refer Slide Time: 01:11)

So earlier we talked about the very basic idea of interactive systems what it is and what are the
concerns while going to design interactive system? We also learned in brief the historical
evolution of the field and today we are going to talk about an important concept in the design of
interactive systems namely usability.
(Refer Slide Time: 01:40)
Now this course is all about design and implementation of human computer interfaces or
interactive systems so design is the key term here one of the key terms here. Now we already
have seen earlier the major design challenge when we are talking of interactive system. Today
we are going to elaborate a little bit on that major challenge from the point of view of a user
centric system designer. So what are the main concerns? In order to do that we will start with a
definition which will be beneficial for our subsequent discussion?
(Refer Slide Time: 02:29)

So it is a definition of the term human computer interaction so we are concerned here about
design and implementation of human computer interfaces a related term is human computer
interaction. So what it is? Human computer interaction is a discipline which is concerned with
the design, evaluation and implementation of interactive computing systems for human use and
with the study of major phenomena surrounding them. So this definition actually encapsulates
whatever we are going to learn in this course.
(Refer Slide Time: 03:17)

So the key thing to notice in the definition is that we are dealing with systems for use by the
human users. So effectively it points to the fact that we need to incorporate humans into the
design so that we can take care of their needs and expectations.
(Refer Slide Time: 03:40)
This brings us to the important consideration of human factors what it is and how they are related
to the design and implementation of human computer interfaces.
(Refer Slide Time: 04:03)

If you may recollect in our previous lecture we talked about designing for the layman users. Now
we also elaborated a bit on who are the layman users and how they are different from other users
of computers? Also it is important to note why to bother about such characterization why we are
trying to differentiate between users such as somebody are laymen somebody is non-laymen.
Why it is required?
(Refer Slide Time: 04:28)
Let us try to understand the need for such a differentiation with respect to an example.
(Refer Slide Time: 04:36)

Suppose we are trying to perform a railway ticket booking task here we may refer to a traveler or
an agent but the task is same booking a railway ticket.
(Refer Slide Time: 05:01)

So what the user is expected to do that is the first thing we should be focusing at the expectations
of the user.
(Refer Slide Time: 05:17)
So the user should be able to input the name of the station, check the availability of seats in the
train between stations. If it is available then the user should be able to book the tickets and
finally once the ticket booking is done he or she should be able to make payments. These are the
fundamental tasks that a user in this case a traveler or an agent is expected to perform in other
words the system is expected to help the user perform these tasks.
(Refer Slide Time: 06:00)

Now let us look at it from a different user’s point of view a DBMS manager or a database
manager who incidentally performs the database querying to get the same information from the
railway database. So here we have 2 types of user we are talking about one is a traveler or an
agent who is trying to get some information about tickets between station and trains. And another
user who is a database manager who is also capable of getting the same information using the
same database that is the railway database.
(Refer Slide Time: 06:54)

So the second user that is the database manager is he or she performing something different than
the earlier ones that is the traveler or an agent so are these tasks totally different?
(Refer Slide Time: 07:14)

If we look at it from a pure technical point of view they are performing the same task or same set
of tasks.
(Refer Slide Time: 07:23)

What are these tasks? So essentially what they are doing is querying the railway database? So
there is this railway database containing all sorts of information about train’s seat availability
ticket price booking status and so on. Now both the traveler or agent and the DBMS manager
both technically are querying the same database to get information for the same type of tasks.
Then both retrieves the information and both uses the information but for different purposes.
(Refer Slide Time: 08:11)

So what is different here they are performing same type of operations on same resource. So is
there any difference why should we differentiate between a traveller or an agent and DBMS
manager the difference is in terms of expectations and need of the user. So when the user is a
traveler or an agent his or her expectation and need are likely to be different than when the user
is a DBMS manager.
(Refer Slide Time: 08:50)

How so if you are a travel agent or if you are a traveller yourself then you are not bothered about
how the database is structured, organized, what are the languages to be used to retrieve the
information? What is the format of the information? How to interpret the format all these things
are not of any importance to you? Whereas these are important issues for a DBMS manager so
what you are bothered?

About is how to get the task done how to get the information about seat availability, about seat
price about trains, about booking status in some form which is understandable without any
specific knowledge required. So your expectation is that you will be getting this sort of
information in an understandable form which is also your need. Whereas for a DBMS manager
that is not the case for him or her, the information may come in different format through different
process and he may not be interested in knowing the actual information.

But how to use that information for some other purpose so the need is also different. So the first
thing that we should keep in mind while going for designing a human computer interface is
designing for whom who is the user? So the first thing is we should know the user that is very
important and crucial requirement for design and implementation of a human computer interface.
(Refer Slide Time: 10:35)

Now knowing the user is somewhat ill defined term so what do we mean by knowing the user?
So we can start by classifying the user into categories a very broad and simple categorization is a
3 way categorization of users. Note that here by the time user we are not referring to users like a
DBMS manager or someone who is technically sound. Instead we are referring to users like
traveler or travel agents who are quote unquote managers who need not know about the
technology behind.

So for such type of users we can divide them into 3 categories novice, intermittent and expert.
Now with this knowledge we will be able to actually build systems that will be more acceptable
to the particular user group.
(Refer Slide Time: 11:39)
How it helps? Again let us try to understand with another example so many of you if not all have
probably used a text editor to create a text document. Now while doing that often we need to
save our work how we can do that? If you have used any text document you know that there are
two ways to do it one is using a menu option where the save menu option is located in a drop
down menu typically.

And you need to select that with your mouse or through some other mechanism to save the
current work. Another option is you can use a key combination like control plus s together to
save it. So 2 mechanisms provided to do the same task one is using menu option other one is
using a hotkey combination in this case control and S these 2 keys pressed together will do the
job. Why that is so? Because anyone would have been fine but then I just mentioned so these
mechanisms are provided to cater to different user groups.

So when we are trying to use the menu based option we are trying to cater to basically the novice
users who may not know the hotkey combinations. So novice users are those who are first time
users of a system so every feature is not yet known to the user. Intermittent users are those who
as the name suggests occasionally uses the system so they may or may not be able to retain the
learnings during each use because they use it very infrequently although more than novice users.

Whereas expert users are those who frequently use the system now here the term expert does not
mean expertise in the background technology instead expertise in use of the system. So when we
are using a menu based option it is typically meant to cater to novice users whereas when we are
using a hotkey combination to perform a job like control and s to save that is typically meant for
expert users. So these different features are provided to cater to different user groups.
(Refer Slide Time: 14:25)

Now this is very important while going to design and implement a human computer interface we
need to identify the human factors and incorporate those in the design which requires knowledge
and expertise in many field of studies. So effectively what we are talking here is an
interdisciplinary field of study where we take help of knowledge and expertise from various
disciplines.
(Refer Slide Time: 15:00)
What are those disciplines? There are many but the important ones we can identify as computer
science is the primary discipline according to (())(15:07) definition. Psychology including
cognitive psychology that is another field human factors in itself it is a field then design
including industrial design, social science, anthropology, AI, machine learning, computational
linguistics.

These are only few of all the fields that may be involved in user centric design field which is the
primary concern in this course. But as I said although there are many fields involved our primary
focus will be computer science and engineering which is considered to be the primary discipline
in this case.
(Refer Slide Time: 16:10)
So the key concern here is how to consider the human in the design process?
(Refer Slide Time: 16:20)

Now to understand that we; should be also aware of different perspectives of design. This term
user centric design actually refers to different things to different stakeholders in different ways.
(Refer Slide Time: 16:47)
A typical creative designer to him or her, the term user centric design refers to the design of the
interface elements and layouts or in other words the creative design aspects the look and feel of
the design or of the system.
(Refer Slide Time: 17:13)

For a product designer particularly industrial product designer the term may refer to the form of
the product in other words the same, size, look of the product.
(Refer Slide Time: 17:27)
Similarly to an electronic engineer user centric design may actually mean adding more features
at the hardware level in terms of more sensors, smaller chips or a more power efficient battery
maybe so essentially some hardware features.
(Refer Slide Time: 17:57)

Similarly other stakeholders may view it in different ways but our concern here is from the point
of view of or the perspective of an application software developer. So this entire course is
actually meant to discuss how to build user centric software. So whenever we use the term user
centric system or human computer interfaces we are implicitly referring to a software product or
an application.
So our concern is the perspective of the application software developer who needs to follow a
development lifecycle that takes care of the user characteristics so as to better match the user’s
needs and expectations. So effectively what it says is? That from our point of view or the
application developer's point of view we should know about the development life cycle that takes
into account the users expectations and needs. How to do that? How to take care of users
expectations and needs in the development or in the software development lifecycle?
(Refer Slide Time: 19:19)

So that brings us to the important concept of usability.

(Refer Slide Time: 19:21)
In order to incorporate the factors or the users’ needs and expectations into the design of the
software we need an explicit measure to judge our design whether we have taken the factors into
consideration or not now this major is called usability. Let us learn more about this concept.
(Refer Slide Time: 19:54)

So it is a standard term there is an ISO standard definition of usability. Which; says that usability
is the extent to which a product can be used by specified users to achieve specific goals, with
effectiveness, efficiency and satisfaction in a specified context of use. So this is the ISO 9241-
210; 2009 definition of usability which is a very standard definition. So if you look at the
definition there are certain things that you should notice.
(Refer Slide Time: 20:52)
Namely 3 crucial aspects in the definition are the product is meant to be used by specified group
of users it is not meant for all. So that is a very important thing we should note that whenever we
are talking of a usable product we are talking of a product that should be used by a very specific
group of users and we are not talking about a product which is usable to all. So we need not
design a product as usable for use by all.

The second aspect crucial aspect is that the product should allow the users to achieve specified
set of goals again it is also very important to note that. If we are planning to put every
conceivable feature in a product so as to satisfy everybody that does not necessarily lead to a
usable product. A usable product by definition or by standard definition is supposed to satisfy
specific set of goals of the users.

So it is supposed to let the user achieve only specific set of goals it is not necessary that the user
can achieve every possible goals that he or she might have that is the second thing that we should
keep in mind.
(Refer Slide Time: 22:25)
There is a third crucial aspect also which says that the product should be designed for specified
context of use. In other words a usable product need not be so for all usage scenarios so we need
not try to design a usable product which can be used in any context. So it has to be usable within
some specified context of use not for every usage context.
(Refer Slide Time: 22:57)

Along with these three crucial aspects there are also 3 explicit measures that are mentioned in the
standard definition these are effectiveness, efficiency and satisfaction.
(Refer Slide Time: 23:17)
Jacob Nielsen in 2012 argued that usability alone cannot make a product useful. So there are 2
things one is usable other one is useful and we will distinguish between the 2. So usability is
about a perception that the product is going to be easy to use to the user whereas useful means
whether the product serves whatever the user needs to achieve. That is a very broad way of
distinguishing the two and according to Nielsen usability alone is not suitable to make a product
useful.
(Refer Slide Time: 24:09)

So according to Nielsen again so there should be 2 qualities in a product one is usability and the
other is utility together they make a product useful.
(Refer Slide Time: 24:27)

In addition Nielsen proposed 5 measures of or quality components of usability.

(Refer Slide Time: 24:37)

What are these 5 first is learnability that is the ease with which a first time or a novice user
performs basic tasks with the system so that is the learnability of a system.
(Refer Slide Time: 24:47)
Then comes, efficiency which is the speed at which the users can complete tasks typically
measured in terms of task completion rate.
(Refer Slide Time: 25:07)

Then memorability again the ease with which an intermittent or occasional user who returns to
use the system occasionally after some gaps can re-establish proficiency. But it says that for
intermittent users after one use there is a gap before the next use happens. Now by the time
whatever the user have learnt about the system may have been lost. So memorability quality
indicates how much of this learner can or the user can retain during the next use even if there is a
gap.
(Refer Slide Time: 25:56)

The fourth quality is errors or error rate which is the rate at which the users make errors. Along
with that the severity of those errors and the ease with which the users can recover from the
errors. So this quality errors actually contain 3 concepts one is the rate, one is the severity,
another one is the ease with which error recovery can be made.
(Refer Slide Time: 26:30)

And the final quality attribute is satisfaction or subjective satisfaction or user satisfaction that is
how pleasant is it to use the design.
(Refer Slide Time: 26:42)
Those are the quality attributes for usability on the other hand for utility the other attribute of a
system according to Nielsen it refers to the functionality that the design is supposed to serve. It is
a measure of the extent to which a design supports the functional needs of the users or in other
words how many features it support that actually serves the functional needs of the user?
(Refer Slide Time: 27:17)

Now if we compare Nielsen's framework to the ISO definition we observed that effectiveness
might be mapped to utility. So according to ISO definition effectiveness is one of the measures of
usability however if we compare it with Nielsen's framework we can roughly see the
correspondence between this major effectiveness and the definition Nielsen provided about
utility.
(Refer Slide Time: 27:47)

As a corollary to this comparison we can say that ISO definition therefore provided not 3 but 2
measures of usability efficiency and satisfaction whereas Nielsen's framework provided 5
measures of usability.
(Refer Slide Time: 28:14)

So it is likely that the 5 usability measures or quality components by Nielsen is likely to offer a
more precise measure. So accordingly we shall assume that these are the measures of usability
and we will subsequently use these to measure usability in our subsequent lectures. So that is in
brief what we can consider as usability so to recap we have this ISO standard definition which
talks about the nature of usability.

That is an usable product need not be designed for all or for all context of use or for all sorts of
tasks instead it refers to the fact that a usable product is supposed to be usable only for a specific
group of users working in a specific context and trying to achieve a specific set of goals. It also
says that there are 2 measures of usability whereas Nielsen's framework provides for 5 measures.
And we will go by the Nielsen's 5 measures as a more precise measure of usability.
(Refer Slide Time: 29:40)

Now with this knowledge now let us try to turn our attention to the concept of user centered
design.
(Refer Slide Time: 29:45)
Now this term user center design was first coined by Shneiderman in 1986. What is the objective
of this design process? The objective is to design products that increase usability. So when we
are talking of user center design so we are essentially referring to the fact that we want to
increase usability of the product by following this design approach.
(Refer Slide Time: 30:15)

Now this user center design approach indicates active or passive involvement of the end users in
the design lifecycle. So somehow we have to incorporate or involve the users in the development
process. Now that involvement either may be active that is the users are actively participating in
the design or it may be passive. That somehow we are taking user feedback in a passive mode
and then utilizing that to design the product.
(Refer Slide Time: 30:49)

There are few more related terms also related to this concept of user centered design one is
cooperative design proposed by Greenbaum and Kyng in 1992. Then participatory design
proposed in 1993 by Schular and Namioka then contextual design by Beyer and Holtzblatt in
1997. So all these terms are broadly referring to the same fact that we are involving the users in
the design process either actively or passively. Although there are minor methodological
variations involved but broadly they refer to the similar concept of user centered design.
(Refer Slide Time: 31:42)
There is also this ISO term used by ISO in its standards which is human centered design. So the
thing to note here is that all of them referring to the similar concept whether we are using the
term user centric design, user centered design, human centered design, and participatory design
cooperative design etcetera. What we are essentially referring to is that we are referring to a
process a stage by stage developmental process which involves the end users in the overall
development of the product.

Now this end user involvement may be active involvement that is the users are actively involved
in the development process or it may be passive involvement that is somehow we are collecting
input from the users and using that input to design and develop our product. So, how to do that
how to follow this user center design approach? Will; be the subject matter of our subsequent
discussions.

So with that we come to the end of this second lecture in summary what we have learnt today is
the important concept of usability and why we need to know it? Why it is important? To recap it
is important to cater to the need of layman users which are our primary concern in design and
implementation of human computer interfaces.

So if we do not make the product usable then it will not be acceptable to the laymen users so our
objective is to increase usability of the product and that is precisely what is called user center
design which term we have learned in our previous lecture. So here we gave a more formal
definition of this term and in subsequent lectures we will see how to implement this user center
design approach for development of human computer interfaces or user centric software
applications?
(Refer Slide Time: 34:21)

Whatever we have covered today the material can be found in this book you are requested to
refer to chapter 2 section 2.1 to 2.4.2 that is all for today thank you and goodbye.
 Design & Implementation of Human - Computer Interface
Dr. Samit Bhattacharya
Department of Humanities and Social Sciences
Indian Institute of Technology, Kharagpur

Module No # 01
Lecture No # 03
Engineering for Usablity

Hello and welcome to the NPTEL MOOCS course on design and implementation of human
computer interfaces. Today we are going to discuss our next topic that is engineering for
usability this is lecture number 3 in this course. So before we proceed as usual let us first
recollect what we have learned in the previous 2 lectures.
(Refer Slide Time: 01:12)

Earlier we have learned few things namely a general introduction to the field. So we have
seen what interactive system is and what are the core challenges in designing interactive
systems the issues and challenges? We have also briefly discussed the historical evolution of
the field of user centric system design and development. And we have also looked at the core
concern in the design of interactive systems namely the idea of usability.

So as I mentioned in my earlier lecture that our core concern here is to build interactive
systems that are usable. So we have to take care of the usability of the system. Today in this
lecture we are going to talk about how to do that? In fact, we will first learn the different
concepts related to implement user centric design approach for usable system design.
(Refer Slide Time: 02:43)
So our core design concern for user centric system design and implementation is design of
usable system. Now why we need it? We need it to cater to the needs and expectations of the
users remember. That here we are referring to layman users so our objective is to cater to the
needs and expectations of the layman users. If we are able to do that then we can say with
confidence that our system is usable.
(Refer Slide Time 03:19)

To achieve that what we need to do? We need to follow some sort of systematic approach.
There should be some step by step process to build user centric software. So that at the end,
whatever we get as output is a usable system.
(Refer Slide Time: 03:45)
Now this brings us to the concept of software development life cycle so software
development lifecycle or SDLC can be used to comprehensively capture and represent the
entire set of design and development activities. So we have to perform some activities to
design and develop a software now these activities together can be used to create a software
development lifecycle. So that these activities can be performed in a systematic manner.
(Refer Slide Time: 04:33)

So essential idea here is that we need to define stages of development for building the
software. And software development life cycles are nothing but the stage wise development
process followed to build a software.
(Refer Slide Time: 04:57)
Why this stage wise development is important? Because it gives us a way to systematically
look at the problem of software development. Let us try to understand the benefit of a stage
wise development process such as the one provided by software development life cycles with
an example. Suppose we want to create a calendar app a simple calendar for say a mobile
phone.

What we should do? If this problem is given to you, how you will start, where you will start,
how you will proceed, these are some of the concerns that will immediately come to your
mind.
(Refer Slide Time: 05:51)

First thing is of course we need to understand, what is required and then accordingly we
should go for design of the app so what we need? A grid like structure that is typically found
on a physical calendar. So all of us are familiar with a calendar at many places probably we
have seen it so there the dates are mentioned in the form of a grid similar thing we want to do
in our calendar app.

Along with the dates so there are headings representing name of the month’s. So that
information also we need to put in the grid like structure.
(Refer Slide Time: 06:41)

Now for each cell in the grid will represent a month. Now there are dates within a month so
for representing the dates or days, we need to create sub grid for each cell in the higher level
grid. So that is also required so create sub grids in each cell to hold the date or days. And
finally we need to render the entire structure on the screen. These are our requirements which
we have identified. Now to render it in the way we envisage the calendar there can be many
possibilities .
(Refer Slide Time: 07:30)
One more requirement can be there that is we may also highlight the current day and month
or the current date. That may be an additional requirement we would like to have in our app.
(Refer Slide Time: 07:50)

So there can be different ways to achieve this particular objective of having a calendar app.
One possible design can be like this, so here we are mostly concerned about design of the
interface how it looks like to the user? So we will mimic entirely the way physical calendars
are there so there will be this grid like structure so maybe a 3 by 4 grid representing 12
months. So each grid element is corresponding to a month for example January, February,
March. April and so on.

Within each grid element there can be sub grid elements representing the days of the month.
Since in a month there can be at most 31 days so we can have a sub grid of 6 by 6 structure
now to be able to hold maximum 31 days. So each sub grid element then will represent 1 day
of the month and in this scheme of things we can highlight the current date that is the day of
the month. This is one way to do things there can be other possible, so there is no unique
solution let us have a look at another way.
(Refer Slide Time: 09:43)

Now since we are building an app rather than a physical calendar we can utilize the flexibility
provided by a computing system and, we can mimic another way of designing physical
calendars, typically the tabletop calendars where we can change pages same idea we can
implement here. So on one screen we will have days for a month with swipe or with tap I can
go to the next or previous month like we change pages on a table top physical calendar.

So the entire screen will contain only the days for a particular month unlike in the previous
case. And here we will have grid where each grid element will represent one day of the
month. So with tap or swipe I can go to the next month or the previous month. And this
scheme can of course be implemented by considering the fact that when I am going backward
from January then I will end up in the last year or previous year. Whereas when I am going
forward from December I end up in the next year.

So accordingly the days can be chosen or designed, so this is another way of designing
things. In fact there can be a large number of alternative ways these 2 are not the only ways
possible so the next question comes is then if there are so many ways then how we can
actually decide which one to choose?
(Refer Slide Time: 11:50)
Our intuition may not be sufficient we probably have to take a systematic study of the pros
and cons of different designs to find out the best one among the possible alternatives. And
that systematic study is nothing but what we are referring to as software development life
cycles. So given a set of alternatives, it is possible to follow SDLC’s to determine the best
alternative that is one advantage of having SDLCs.

Apart from that of course there is this added advantage, that we can look at the problem in a
more systematic manner which will make things clearer and simpler to us to proceed.
Otherwise if we are dealing with building large software then the things will quickly become
messy if we do not look at it in a very systematic manner. And then it will be very difficult
for us to come up with a usable product. Having identified the advantages of software
development life cycles let us now learn a little bit on what are the different life cycles.
(Refer Slide Time : 13:10)
So there are actually many ways to look at the software development process accordingly
several life cycle models have been proposed over the years such as the waterfall model, the
spiral model, the evolutionary model and so on so we will have a look at some of these
models to get a better understanding of what we are meaning by software development
lifecycle models.
(Refer Slide Time : 13:46)

Let us start with the most fundamental of these models namely the waterfall model. This is
also the most well-known SDLC model although this is primarily used for pedagogical
purpose for teaching purpose rather than for actual software development. Now in this model
remember that we talked about software development life cycle to be a stage wise process for
building a software. Now in the waterfall model or rather the classical waterfall model there
are 7 such stages which we should follow to build a software.
(Refer Slide Time : 14:21)

First is feasibility study before we start on the software development process, we first need to
identify whether it is feasible whether we can proceed with the available resources, available
budgetary support, available manpower and so on? So that is the first stage of the process.
Where we first check for feasibility of the whole building process. If it turns out to be not
feasible then it is preferable not to proceed further or we need to modify our goals
accordingly based on availability of resources.

The second stage is requirement gathering analysis and specification. So we need to identify
what is required to build the software. Here the requirement is not in terms of resources rather
it is in terms of user requirements. So we need to identify and gather those requirements and
analyze those to find out what is possible to be implemented? The third stage is the design
stage here we go for designing the software.

Now later on we will see that the design involves 2 thing in the context of our focus. That is
human computer interfaces here design refers to both interface design as well as the design
of the system or code. Then comes coding or actual implementation of the system along with
that we may need to test the code also for identifying bugs and taking corrective measures
so coding and testing is the next stage.

Once unit level testings are done and codes are finalized. Then we go for integration of the
unit levels and then overall system testing and the final stage is deployment of the product. It
also includes maintenance as well which may be considered to be a part of this phase or can
be a separate stage. Now these 7 stages in different places you may find that they are
mentioned in different ways so for the sake of discussion in this course we will assume that
there are these 7 stages in the waterfall model.
(Refer Slide Time: 16:48)

Now when these stages are depicted they are depicted as kind of a waterfall. As shown in this
figure so first feasibility study next is requirement gathering analysis and specification. Third
is design, then coding and unit testing system integration and testing deployment and
maintenance. As you can see here either we can have 2 separate stages or single stage
covering both.

And the way it is depicted it appears to be like a waterfall so accordingly this name is given
to this particular way of looking at the software development process.
(Refer Slide Time: 17:32)
Now that was the classical model. Now waterfall model can also have an iterative version
where we can have iteration between the stages.
(Refer Slide Time: 17:45)

For example after feasibility study we go for requirement gathering analysis and
specification. There we may find that few things are not available. Then we may like to go
back to feasibility study. After design we may like to go back to requirement gathering stage.
After coding we may like to go back to design stage or requirement gathering stage. Similarly
after system integration and testing we may like to go back to coding stage or design stage or
requirement stage anywhere.

So this type of iterations can also be accounted for in the traditional or classical waterfall
model. If we are having iterations between the stages then it becomes known as iterative
waterfall model. So that is the basic idea about waterfall model.
(Refer Slide Time: 18:59)
Another software development lifecycle model is the spiral model let us have a look at this
model. Spiral model is actually a Meta model meaning it encompasses other SDLCS so it is
kind of Meta level SDLC.
(Refer Slide Time: 19:10)

So when graphically illustrated the model looks something like this. So there are 4 quadrants
identify objectives, risk assessment and mitigation develop prototype, customer evaluation
and planning. Now as you can see here each spiral covers all the 4 quadrant. So starting from
here it goes up to here that is one iteration then again it can start from here and till it covers
the 4 quadrants that is another iteration so on. So there can be unlimited number of iterations
as per the requirement of the development process.
(Refer Slide Time: 20:07)
So there can be multiple cycles each cycle is an iteration, so each spiral is one iteration. Each
iteration is divided into 4 phases or quadrants as depicted in the figure.
(Refer Slide Time: 20:28)

The first quadrant identifies objectives of the development of the product and the risks .So
objectives of the iterative phase are identified in this first quadrant of the iteration and also
risks associated with these objectives. These are also identified in this first quadrant.
(Refer Slide Time: 20:58)
In the second quadrant that is risk assessment and mitigation so the identified risks are
analysed in details. So in the first quadrant we have identified the risks those risks are
analysed in details and then steps are taken to reduce the risks. For example if there is a risk
of inappropriate requirement specification. Then a prototype system may be developed to
gather requirements which will mitigate this risk.
(Refer Slide Time: 21:41)

Third quadrant deals with the developmental phase. So in this quadrant we can go for
building or developing the product or the prototype. The earlier iterations and product was
the latter iterations after resolving identified risks. Also evaluate the product or the prototype
whichever is the case. So as I said there are multiple iterations so initially during the initial
iterations typically prototypes will be developed and during the latter iterations, when we are
almost coming to the end of the developmental process.
Focus will shift towards building of the product and during the iteration this product will also
be evaluated. If it is product the product will be evaluated. If it is prototype then the prototype
will be evaluated.
(Refer Slide Time: 22:48)

Then comes the fourth quadrant or the last quadrant. So here whatever results we have
achieved so far after evaluation with customer in the third quadrant, those results are
reviewed and we plan for the next iteration if required. So here we are primarily evaluating
the results achieved so far and plan for the next iteration if required. So these are the four
quadrants of a spiral model. As probably you have noticed by now spiral model is not a
fundamental developmental model like the waterfall model.

Instead it captures higher level concerns and activities that are required to implement a lower
level or fundamental level software development life cycle.
(Refer Slide Time: 23:54)
And through these iterations of the spiral progressively more complex versions or more
complete version of the software gets built that is the overall objective. So with these we get
some idea of what is the software development life cycle, so we discussed one fundamental
SDLC model and 1 Meta model to get some idea of what we mean by stage wise or
systematic development of a software.
(Refer Slide Time: 24:34)

Now our concern for building interactive software is that the software should be usable this
requires the developer to take users into account in every stage of the design in one form or
the other either in active form or in passive form. Now in order to do that if we go by straight
forward approaches then that will require lots of iterations.
(Refer Slide Time: 25:15)
Now these iterations although not impossible but it creates difficulty if we want to use a
traditional SDLC such as the waterfall model. That will create a problem as you probably
have noted when I was talking about the iterative waterfall model. So there between every
stages we probably need to iterate and it may be between 2 consecutive stages maybe far
away stages to take into account user feedback properly and completely.

So the resultant model when visualized will look messy and it will be difficult to follow. If
we follow the traditional models. In the next lecture we shall learn about an alternative model
for building interactive software which is although takes care of the iteration. But it does not
look messy as in the case of the waterfall model.
(Refer Slide Time: 26:45)

Whatever we have covered today you can refer to these two books to get more material on
these topics Rajiv Mall Fundamentals of Software Engineering as and Roger Pressman
Software Engineering of Practitioners approach. You may go through chapter 2 of the first
book or chapters 2 to 4 of the second book to get a better understanding of the development
process. And the process models that is all for this topic hope you have learned the basic idea
will meet again in the next lecture thank you and goodbye.
 Design and Implementation of Human-Computer Interfaces
Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology - Guwahati

Module No # 01
Lecture No # 04
Interactive System Life Cycle

Hello and welcome to the course design and implementation of human computer interfaces.
Welcome to lecture number 4, human computer interface development life cycle.
(Refer Slide Time: 00:58)

So in the previous few lectures we have learned about the field of interactive systems what are the
code design concerns in the interactive software development? And also we have got some idea of
software engineering life cycles or system development life cycle or software development life
cycles. Now these life cycles provide us a systematic way to think about developing a software
product. In this lecture we are going to learn the life cycle for interactive software development.
(Refer Slide Time: 01:40)
So earlier we learned about the waterfall model which is the most well-known and fundamental of
all the Software development lifecycle models. It consists of 7 stages 6 or 7 stages feasibility
study requirement analysis and specification, where we identify and specify the requirements
design, coding and code testing system integration and testing deployment and maintenance. So
with these 6 or 7 stages followed one after another, we can build and deploy any software that is
the idea.
(Refer Slide Time: 02:30)

Now our concern is software to be used by layman users. As we have repeatedly emphasized this
brings us to the concept of user centric or user centred design, where the software that we develop
should be easy to use in other words it should be usable for the intended users.
(Refer Slide Time: 02:58)
Now the classical waterfall model if we want to follow those stages to build user centric software,
the model actually creates a problem. Because our core concern here is usability in order to do
that, we have mentioned earlier that we need to take into account the users either in active mode
or in passive mode. Now taking into account the users is not explicitly the concern of the waterfall
model. Instead the model is designed to build efficient systems rather than usable system.
(Refer Slide Time: 03:53)

So what kind of problem it creates in order to develop user centric system. We require iterations
between stages because that is required to take into account the feedbacks we receive at each stage
of the design.
(Refer Slide Time: 04:20)
Now if we want to do that with the classical waterfall model then the model becomes rather
messy.
(Refer Slide Time: 04:27)

For example suppose, this is a linear flow of the process from feasibility study we go to
requirement stage then design stage, then coding, stage integration, stage deployment and
maintenance stage. Now in case of user centric approach we need to take into account users in
every stage now suppose in design stage. We find out user input which does not match with the
requirement specification we have obtained in the previous stage then we may have to go back to
this stage after coding while going for testing.
We find out some issue then we may have to go back to this stage. We may also need to go back to
this stage directly rather than going in the design stage after again system testing, we may need to
go back to unit level or design or requirement stage. So; too much iteration which makes it
difficult to visualize the overall process and creates confusion in the mind of the developer in
order to handle that we can refine this life cycle to suit our purpose.
(Refer Slide Time: 05:58)

So this figure illustrates such a life cycle for implementation of user centric design approach. Like
waterfall model it has several stages starting with the feasibility study. We have requirement
gathering analysis and specification stage now. From this stage we go to a design prototype
evaluate cycle stage. Here there are 3 sub stages design, prototype building and early evaluation
these 3 are connected in an iterative cycle.

Once that cycle stabilizes that means, we do not find any more issues to be resolved based on user
feedback, we can go for implementation, we come to the coding and implementation stage once
that is done, and we go for code testing. Now after code is tested that means our system is
executing as per our requirement. We need to go for another user testing which we are calling
empirical study or empirical research.

So in this stage the system is not tested for code efficiency. Rather it is tested for usability. Based
on the findings in this stage it may be possible that we go back to this cycle. Similarly based on
the findings in this cycle, it may be possible that we go back to requirement stage and the last
stage is deployment and maintenance like waterfall model.
Now this design prototype evaluate cycle to requirement gathering stage this cycle may be
required based on the outcome of this evaluation but still it is not very frequent it is expected to be
not very frequent. Similarly from empirical study we may have to go back to design prototype
evaluate cycle which again is expected to be infrequent although may still be required to refine
our designs. So the needs of building an usable software may be taken care of with the help of
these types of life cycle model. Let us briefly have a look at different stages of the life cycle.
(Refer Slide Time: 08:53)

Now in the requirement gathering stage since we are dealing with human computer interfaces. So
here we need to identify requirements from the user’s end users or layman users. Rather than only
the customer or client of the product that is very important accordingly we have to deploy
different techniques. Those are used to capture end user requirements such as contextual inquiry
ethnographic studies, cultural probes and so on.
(Refer Slide Time: 09:30)
Next comes the design prototype evaluate cycle so it involves 3 sub stages design building
prototype based on design and early evaluation. Now why this loop is required? It is required so
first we go for a design based on the requirement. We identified now this design is prototyped and
again user feedback is taken based on the feedback. It user feedback or some feedback is taken in
the early evaluation stage.

Based on the feedback we refine the design again go for prototype building. And so on till we find
out that no further changes in the design is required. That means the design has stabilized so at
that point we break the cycle and go to the next stage of coding and implementation. So in this
cycle it is expected that there will be much iteration accordingly; our early evaluation and
prototyping should be simpler to carry out. So those should be quickly achievable. So that less
time is required to build a prototype or to evaluate a prototype.
(Refer Slide Time: 11:01)
Now one thing we should note here, when we are talking of design, 2 concepts are involved. One
is design of the interface that is design of the interface and interaction from the point of view of
the end user. In that design nothing related to implementation or coding is involved. And when we
are talking of building prototype and quickly evaluating, we are actually referring to the design of
the interface and interaction.

So we first design the interface and our interaction to build a prototype get those prototypes
evaluated quickly refine our design and so on till we find out no more refinement is required in
the design of the interface. And interaction once that design is stabilized then we designs the code
or how to implement the system. We go for that design so that is also implicitly involved in this
cycle. Although that design of code is also iterative but that iteration does not require end user
feedback instead those iterations are performed within the design team.

And their prototype is not necessary so essentially that iteration involves designing the code and
evaluation by team other team members or brainstorming. To refine the design conceptually 2
different cycles are being mentioned. In this stage one is interface design and the cycle associated
with it. The other one is code design and the cycle or iteration associated with it. So the entire
cycle of design prototype early evaluation is important for interface design. To take into account
user input whereas for code design prototyping is not required and evaluation is basically
brainstorming within design team.
(Refer Slide Time: 13:25)
Then comes implementation, so now we are talking of implementing the code design that we have
achieved in the earlier stage. Now implementation can be done in traditional way that is by
writing code and testing the code or debugging the code. So here one thing to be kept in mind is
that before we go for implementation we try to get as good a design as possible. So that we do not
need to modify the design later then it will involve changing the code also which is technically
costly in terms of manpower.
(Refer Slide Time: 14:10)

So along with code we need to test for the code so there are standard techniques available the
other important stage is empirical study. So once the system is implemented and code is tested that
means the system gets executed without any flaw. We still need to know whether this overall
product is usable or not code testing will not give us that knowledge instead what we need to do is
to get it tested with the end users again.

And that requires a systematic and scientific approach which is generally called empirical research
or empirical study. So this is required to ensure that the product conforms to the usability
requirements. And this is not an ad hoc process it requires systematic testing approaches. But
these testing approaches are totally different from what we have employed for prototype testing or
code testing.
(Refer Slide Time: 15:23)
Again the earlier stages are very important because empirical study is also a costly affair .In terms
of time resource manpower cost. So we should ensure that before going for empirical study we
should ensure that the implemented product is as good as possible. There should not be too many
problems otherwise; we have to repeat this loop multiple times it can be repeated once or twice.
That is still acceptable but if we have to do it multiple times because the earlier stages we did not
do properly then that increases the cost as well as turnaround time of the overall system.

In fact it may lead to non-delivery of product also so to summarize, we have discussed a software
development lifecycle that is tailor-made for user centric design implementation. It involves
important cycles these cycles are important to take into account user feedback and ensure that the
product is usable. In subsequent lectures we will go through the details each of these stages.
(Refer Slide Time: 16:52)
Whatever I have discussed in this lecture can be found in this book. You are requested to refer to
chapter 2, section 2.1 to 2.4.2. So that is all for this topic looking forward to meet you in the next
lecture thank you and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology, Guwahati

Module No # 01
Lecture No # 05
Usability Requirements

Hello and welcome to the NPTEL Mooc’S course on design and implementation of human
computer interfaces. We are going to start a new lecture number 5 on the topic of usability
requirements. So essentially it will deal with how to gather requirements to ensure that our
product is usable here by product we mean a software application.
(Refer Slide Time: 01:21)

Before we start again as usual we will quickly recap what we have covered in the earlier lectures.
So we have talked about interactive systems, which is our core concern here interactive systems
and human computer interfaces will be using simultaneously and synonymously. So that term
human computer interface will be used synonymously with interactive systems and most of the
time we will be using the term interactive system for brevity which will refer to human computer
interfaces.

Now when we are talking of interactive systems essentially what we are referring to is a software
system which will be used by layman users. So earlier we have learned what are these systems
why we need to be extra causes while designing these systems? What are the things that we
should consider while designing such systems? In particular we have focused on the crucial
concept of usability.

Now in order to ensure that an interactive system is usable what we should follow that also we
have briefly discussed in our earlier lectures. So essentially what we mentioned is that there has
to be a systematic and stage wise process to develop an interactive system. Now this systematic
development process we are referring to as software development life cycle. So we have seen
one such software development life cycle tailored to cater to the need for development of usable
interactive systems.
(Refer Slide Time: 03:25)

Let us quickly have a look and recap the development life cycle as I mentioned earlier. So we
will be focusing on the individual stages of this life cycle throughout this course the details of
these stages will be the main content in this course. So what are the stages there present in the
interactive development life cycle? First stage is feasibility study where we first try to see
whether the development process is feasible or not with respect to the available resources that
includes manpower, cost, time computing resources and so on.

Once it is found to be feasible we go for the second stage that is requirement gathering analysis
and specification. In this stage we try to gather requirements end user requirements which will
help us develop a system that is going to be usable. Once that is done we enter into this design
prototype evaluate cycle. So, these 3 together constitute a stage now these sub stages in this stage
work in a cycle.

So first we go for designing the system particularly the interface and interaction that design is
prototyped for quick feedback on the quality of the design and usability of the design. Based on
feedback we refine the design then again refine the prototype or create a new prototype for the
revised design. Which again is evaluated and this cycle goes on until we reach a stage where no
further changes in design is required.

So once we stabilize on the interface and interaction design or rather once we finalize the design
then we go for code design. So essentially we have to build software so we need to design the
system so from the design of the interface and interaction we convert it to design of a system or
the code design part. That design is then implemented and the code the executable code that we
have implemented is then tested in subsequent stages.

Once the testing is over and we get a working system we then have to go for a final round of
usability study for the product that is an elaborate process which generally is termed as empirical
study or empirical research. In this stage it is possible that we may find some more issues with
our design of the interface and interaction. So it may require us although infrequently but still
sometimes we may need to go back to this cycle to refine our design and then again recode retest
and then finalize the product.

So once finalization of the product is done then we go for deployment of the product and also go
for maintenance. So that is in brief the life cycle stages for an interactive system.
(Refer Slide Time: 07:34)
Now in our discussion on these stages we will skip the first stage that is feasibility study we will
not spend much time. We will assume that whatever we discuss is on the basis of the assumption
that the further development is feasible already that is found out to be feasible. In light of that we
will start our discussion so first thing that we will discuss is the first stage after feasibility study
that is requirement gathering, analysis and specification.
(Refer Slide Time: 08:20)

So essentially we are starting our discussion on the life cycle stages with the second stage here.
Now note here that the term requirement actually is referring to usability requirements rather
than system level requirements we shall see the difference in subsequent discussion.
(Refer Slide Time: 08:39)

So once we try to understand the requirements for usability we have to keep in mind that here we
are talking of requirement gatherings from the point of view of user centered design or user
centric design. So the other approaches where user centricness is not so prominent we can refer
to it as system center design. So we throughout this course we will distinguish between these 2
approaches one is system center design or the traditional design of a software and other one is
user centered design or design where users concerns are explicitly taken into account in the end
product.

Why because we want to have a usable system where the system will be usable for lay persons or
layman users.
(Refer Slide Time: 09:50)
To highlight the difference let us see an interesting example. So probably some of you or many
of you may be aware of this famous comic character which is called Dilbert. Now this comic
strip is taken from one of this Dilbert's series so, here this is the Dilbert figure the character and
this person is his boss. Now Dilbert is a software engineer or IT engineer and he is tasked to
create a system.

Now as an engineer or developer he is asking his manager for opinion. The first way to develop
as per his Dilbert's opinion is that the system could be designed with a simple point and click
interface. That means Dilbert is time trying to convey the message that it should be simple to use
for the end user. It is also possible as per Dilbert to create a system where the user need to choose
among thousands of poorly documented commands each of which must be typed exactly right on
the first try.

Also in such a case if the customers face some issue then as engineer or developer they will
never meet a customer, ourselves to understand their needs expectations problems. And so on it
appears that the manager is supportive of this idea and he also adds along with this complexity in
the system that, make the system so. So that the customer have to reboot or the user have to
reboot after every typographical error.

So essentially what it says is that as an engineer Dilbert finds it more interesting to build a very
complex system which need not take into account the user’s needs, expectations, characteristics
because the engineer will never meet the users and the manager is supportive of that idea. So this
comic strip essentially indicates that developers may be having a tendency to go for a design or
development of a product in a way such that it is not correlated with the user characteristics.

Developer may like to develop as per his or her own or the teams own understanding of the user
rather than actually studying the user.
(Refer Slide Time 13:35)

If such an approach is taken which we are referring to as system center design the main concerns
of the developer are what can I as a developer? Easily build on this platform rather than what is
required by the user. What can I as a developer create from the available tools rather than catered
to the user’s needs and for that if required create new tools? What do I as a programmer find
interesting rather than which where to write a program or add features will help the users?

So essentially the concern is about the developers own expertise skill and interest rather than the
user’s needs this is what we are referring to as system center design. Where the requirements
from the user sides are not considered at all rather the requirements are framed to support the
skills expertise and interest of the developer.
(Refer Slide Time 14:46)
In contrast to this approach we have user center design where the design is supposed to be based
on a user's abilities, context, goals or needs. So these are crucial considerations here that what the
user is capable of doing what are their goals or needs and what is the usage context? The crucial
difference here with the system centered approach is that these considerations are not based on
only the programmer’s convenience rather these are based on the user’s actual requirements.

So we will clearly distinguish between these 2 approaches one is whatever programmer feels
required another one is whatever are actually required by the users.
(Refer Slide Time 15:40)
To understand this further let us go through 1 example scenario recall the calendar app which we
discussed in our earlier lectures. For this calendar app if you are asked to gather requirements
what kind of requirements you are going to gather what will constitute requirements? So first
question is what; are the requirements and how to gather that? In other words when we are
saying that calendar app is an interactive system and we want to build it through stages where the
first stage is requirement gathering analysis and specification. So first thing we should try to
answer is what are the requirements for the calendar app?
(Refer Slide Time 16:40)

Now note that the calendar app the way we discussed is a mobile app so let us try to see what can
be the requirements? When somebody asks you what are the requirements immediately few
questions may come to your mind. One of those may be we need to develop it for a mobile
platform or for mobile platforms. Can we call it a requirement that it needs to be developed for
mobile platforms we shall see.

Another question that may come to your mind while thinking of requirements for calendar app
may be what programming language are we going to use? Is it java or shall I develop with java
scripts or shall I develop with something else? Can I call this a requirement for building the app?
Let us consider a third question which may come to some of our minds? How we are going to
store the various, information needed?
For example reminders special events so in a calendar along with the date display we may like to
add or show to the user special events such as reminders for classes, quizzes, exams or special
events. Now in order to do that what kind of storage technique I should use? Should; I go for
RDMS tools where RDMS stands for relational database management system. So some RDMS
tools should I use for example should I use my SQL which is one of the DMS tools now if this
type of question appears can I call it a requirement.

So we are seeing 3 possible queries or questions that may come to our mind when we are asked
to find out requirements for developing the app. First one is related to platform we need to
develop it for mobile platform should it be considered as a requirement. Second is programming
language to be used to build it should it be considered as a requirement? Third is the storage
technique to be used and the question is should I consider it as a requirement.
(Refer Slide Time 19:33)

These 3 are not obviously the exhaustive list of questions that may come to our mind there may
be many more. Now how do we know whether these are or these questions qualify as
requirements to build the system?
(Refer Slide Time 19:53)
In fact the 3 questions that we have seen do not qualify as requirements why?
(Refer Slide Time 20:07)

Let us see among these questions some are related to feasibility of the system whether the overall
project for building the app is feasible or not. For example the first 2 questions that we have
mentioned are actually related to feasibility we need to develop it for mobile platforms. So that is
actually a part of the feasibility study stage rather than is a usability requirement. Also what
programming languages we should use that depends on the kind of manpower available and their
skill.
So again that is of part of the feasibility study stage where we study about the available
manpower resources etcetera. So this is again not a requirement as such when we are talking of
requirement we are implicitly talking of usability requirements, usability has nothing to do with
platform or programming language. So these are or these cannot be considered as usability
requirements or requirements which we are trying to find out in this lecture.
(Refer Slide Time 21:29)

There may be some queries which are more related to the design phase rather than requirement
phase. For example the third question that we have discussed how are we going to store the
information should we use some RDBMS tools? This actually relates to the design of the system
rather than requirement for the system. So while going for identifying requirements we should be
very careful whether what we are identifying are related to the feasibility of the project or design
of the system or testing of the system so everything is not requirement.

Requirements are different than what we are what probably immediately comes to our mind so
we should be very careful.
(Refer Slide Time 22:36)
So what is our objective then? Our objective is to identify requirements that ensure usability.
That is our core objective we need to identify only those requirements that ensure usability other
things that we identify are not related to requirement identification stage. Also along with
identification of requirements in this stage of requirement identification or rather requirement
gathering analysis and specification.

So there are 2 more components analysis and specifications so whatever usability requirements
we gather or identify we need to analyze them so that we can convert them to some specification
system specification. Which will make it possible to design and implement the system, so first
thing is we need to identify the requirements and second thing is we need to convert it to some
system specifications.

So that the next stages can be carried out namely design and implementation of the system. So
there are 2 objectives one is identification one the other one is specification which involves
analysis of the identified requirements.
(Refer Slide Time 23:58)
So then what we need we need to gather the requirements and we need to analyze and specify the
requirements these 2 things we require.
(Refer Slide Time 24:10)

Now one thing we should note here so when we are talking of usability requirements these come
under non-functional requirement. Later on we will see that there is another type of requirement
when we talk of system development particularly software system development that is functional
requirement. However usability requirements are typically considered to be under non-functional
requirements. So essentially we are trying to gather one type of non-functional requirement
namely usability requirements.
(Refer Slide Time 24:45)

So before we proceed further let us quickly learn about this concept of non-functional
requirements. So when we are talking of building a system so obvious thing is to identify what
we need to build that is requirement gathering. Now we have already seen that some things need
not be requirements they may be part of other stages of the development. However whatever are,
part of requirements can broadly be divided into 2 categories functional and non-functional.

So we will talk about first non-functional requirements because we are primarily concerned
about usability requirements.
(Refer Slide Time: 25:34)
So what are non-functional requirements? These are system characteristics that cannot be
expressed as functions now. When I say functions this is a loosely used term but it refers to the
general concept that whenever there is a function it takes some input and produces some output.
So if a requirement can be specified as a function where there is some well-defined input and
well defined output then we call it as a functional requirement.

When we cannot do that then we call it as a non-functional requirement. Typically such

requirements are related to the quality attributes of the system or the software.
(Refer Slide Time: 26:30)

Now these non-functional requirements can be of different types so there are few broad
categories of non-functional requirements. We have performance related non-functional
requirements, operating constraints which are considered to be non-functional requirements.
Economic considerations these are also non-functional requirements, life cycle requirements,
interface issues.

So these 5 broad categories of requirements are generally considered to be non-functional

requirements or NFRS. Among these our core concern is usability requirements which comes
under this fifth category of interface issues but let us also try to get some idea on the other
categories.
(Refer Slide Time: 27:36)
So the first one is performance related non-functional requirements there can be many such
non-functional requirements. One is reliability which says that how to ensure that the product is
reliable how we can ensure that. Security is another performance related non-functional
requirement and which typically refers to the things that are required to make the product secure.

Then response time another performance related non-functional requirement which includes
ideal response time and practical times. So, broadly these 3 can be considered to be performance
related, reliability, security, response time.
(Refer Slide Time: 28:37)
Then comes; the second category that is operating constraints so one of these is physical
constraints the size of the system. Then availability of personnel to maybe maintain, develop the
system, skill level considerations again to develop and maintain the system. These are few things
that we need to consider while building the system also system accessibility for maintenance. So
the extent of accessibility which is required to maintain the system that also comes under
operating constraints.

So these things actually we need to specify as requirements while delivering the product. Like
the size and how to manage then available personal skill set accessibility. So, that it can be
smoothly developed maintained updated and so on.
(Refer Slide Time: 29:59)

Then comes the third category economic consideration here the non-functional requirements
relate to immediate and or long term costs for design development and implementation these
three things. So, essentially these are also required to be specified as non-functional
requirements.
(Refer Slide Time: 30:31)
Fourth category is life cycle requirements under this comes the design quality requirement for
the design quality. Here by design we mean the design document that is obtained after the design
stage both designed for interface as well as design of the code. So this quality of the design is
measured in terms of maintainability of the design, enhance ability of the design, portability of
the design and so on. So we need to specify the requirements in terms of these measures
requirements for the quality of the design.
(Refer Slide Time: 31:24)

And finally comes the fifth category of non-functional requirements namely issues related to the
interface here we may add. That this is not only interface so whenever we are using the term
interface we are referring to 2 conceptual things one is interface one is interaction so this is
related to interfaces as well as interaction. Now this nfr deals with how system is to interface
with its environment users and other systems.

So it is not only related to user interfaces but also interfacing with its environment as well as
other systems. So it includes specification of this particular non-functional requirement includes
external system interface in terms of hardware and software requirements or in other words
peripheral devices or API’s. So how to interact with the external systems and usability
requirements that is what are the requirements to make the system usable.

So, these 2 comes under interface issues related non-functional requirements so our focus is on
the usability aspect of the interface issues.
(Refer Slide Time: 33:09)

So to repeat here we are dealing with interactive systems that are to be used by non-expert users
or lay persons and for them usability is very important. So we need to ensure that the system is
usable so that lay persons find it easy to use. And our whole objective for this stage of
identification of requirements is centered around; identification of usability requirements.
(Refer Slide Time: 33:41)
So in subsequent lectures we will see what we can do to identify usability requirements but
before going to that let us first discuss what are the advantages; of specifying non-functional
requirements. So if we specify this that then that ensures that software follows legal and
adherence rules these are very important to maintain some standard. It also ensures a product that
is reliable, available on demand; ensure performance as well as scalability of the system.

So if we specify non-functional requirements then these are ensured because we are specifying
what is expected out of the product it also helps us construct security policy of the product. So
these are obvious because the corresponding non-functional requirements are to be specified.
Together all whatever we have mentioned ensures that at the end we get a product which
achieves good user experience and ease of operating the software by the user as well as the
technicians who are tasked to maintain the software. Both are ensured if we specify
non-functional requirements properly those are the advantages.
(Refer Slide Time: 35:34)
Now if we do not do that then what are the disadvantages it may lead to unsatisfied users or
clients or both as well as unsatisfied developers. So developers will not be given clear idea of
what they need to develop then at the end if they are told that whatever they have developed does
not mean meet certain requirements then definitely that will not be very satisfying for them. So
at the beginning stage all these non-functional requirements should be clearly specified as much
as possible.

Not specifying the non-functional requirements properly or clearly may also lead to inconsistent
software which is not a desirable outcome. Also not doing so in time may lead to time and cost
overrun to fix certain issues later; which of course is not a desirable outcome because we did not
specify the requirements earlier. So we need to fix it later so then that leads to time and cost
overrun and it may even lead to not delivering the product at all total wastage of time and cost.

So these are significant and severe consequences; of not specifying non-functional requirements
in time or before the development begins. So we got some idea of what we want to gather? We
want to gather usability requirements; which is one sort of non-functional requirements.
Non-functional requirements are of many types usability is only one of those but as we have seen
in developing a product software product we need to specify non-functional requirements
properly so that later on we do not face any issue.
(Refer Slide Time: 38:02)
With that brief introduction to non-functional requirements we conclude this lecture and in the
next lecture we shall continue discussion on how to gather usability requirements. So we will
focus only on usability requirement gathering rather than gathering of other non-functional
requirements. Along with that we shall also learn in details how to specify such requirements.
Specify in a way so that it becomes easier to convert the specification to system design.

Now that specification is generally called as functional requirements. So we shall also learn
about functional requirements in subsequent lectures.
(Refer Slide Time: 38:53)
So that is all for this lecture whatever topics we have discussed today may be found in these
books. So for further information you may refer to these 2 books fundamentals of software
engineering or the second book software engineering a practitioner's approach. In the first book
you may refer to chapter 4 whereas in the second book you may refer to chapters 7 and 8 to get
more information on these concepts.

So with that I would like to conclude this lecture and hope to see you in the next lecture soon
hope you have got some idea on the concepts that we covered today thank you goodbye you.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology, Guwahati

Module No # 02
Lecture No # 06
Contextual Inquiry

Hello and welcome to the NPTEL MOOC’S course on design and implementation of human
computer interfaces lecture 6 on usability requirement gathering. So we are currently discussing
on the starting stage of interactive system development life cycle namely requirement gathering
stage where our emphasis is on gathering usability requirements. Note that we skip the first stage
feasibility study and we started with the second stage of life cycle namely requirement gathering
analysis and specification stage.
(Refer Slide Time: 01:33)

So we already learned about the idea of usability and its importance in interactive system
development life cycle. In this lecture we are going to learn about one approach through which
we can gather usability requirements for building and interactive system.
(Refer Slide Time: 01:57)
Just to recap we are currently in the requirement gathering stage we are currently discussing
topics related to this stage. And in this course in subsequent lectures we will cover the other
stages as well. So there are many stages in the interactive system development life cycle first
stage is feasibility study which we are not covering in details here. We are currently in the
requirement gathering stage then we have this design prototype evaluate cycle.

Involving the design stage prototyping stage, evaluation stage and design involves both interface
design as well as code design. Then we have this coding and implementation stage testing of the
code. A final stage to again ascertain the usability of the overall system through empirical study
and then, finally deployment and maintenance. So other stages will come in subsequent part of
the lecture currently we are focusing on requirement gathering stage.
(Refer Slide Time: 03:21)
So in this lecture we are going to learn about one specific approach to gather usability
requirements from end user which is called contextual inquiry.
(Refer Slide Time: 03:38)

So before we go into the details let us recall that in the conceptualization to implementation of
interactive system one very important aspect is knowledge about the user. So we should have the
motto of know thy user or know the user here by the term user we mean end users or laymen
users.
(Refer Slide Time: 04:11)
And again there is a definition for usability which would like to recall at this stage before going
further into the discussion on contextual inquiry. That is the ISO definition of usability which is
the extent to which a product can be used by specified users to achieve specified goals with
effectiveness, efficiency and satisfaction in a specified context of use. So the standard definition
categorically talks about specific group of users who wish to achieve specific goal in a specified
context of use that is the definition of usability.

So here note the term specified context of use so we have to somehow capture the use context
before we can think of building a usable product. So which will be the context of use of the
product along with who are the users and what are their goals. All these considerations we need
to address or we need to keep in mind before we aim to build a usable product.
(Refer Slide Time: 05:46)
Now let us come to the main topic of this lecture that is contextual inquiry so this is one of many
methods available to gather end user requirements for usable product development. So this
whatever outcome we get after the inquiry process is over after the contextual inquiry process is
over those outcomes can be equate it to usability requirements. And this is not the only method
but one of many such methods available together usability requirements.
(Refer Slide Time: 06:29)

Now the method as such is not very new so its importance in user center design was highlighted
way back in 1988 about more than 30 years ago. When the graphical user interfaces, and the
personal computers were dominating the same. At that time this technique used to be referred to
as phenomenological research method and by the end of the nineteen nineties it became well
developed and quite popular together end user requirements.
(Refer Slide Time: 07:15)

Now the same method is often referred to as a form of semi-structured interview or

semi-structured interview process. However it may be somewhat misleading because contextual
inquiry is not only an interview instead in contextual inquiry we have 2 things involved one is
interview and the other one is observations. Observations are the primary method used here
along with that interviews are used as a supporting mechanism of observations. So if we are
simply referring to it as an interview then that may be misleading.
(Refer Slide Time: 08:07)
So in contextual inquiry process the primary objective is to watch and observe the users while
they are performing tasks in their natural work setting or in other words the work context. So in
contextual inquiry what typically is done is that users are asked to perform their regular activities
in their natural work settings and their behaviour; are closely observed during their regular
activities.

Now during observations the observer may ask users queries or questions to clarify certain
behavioral issues or certain activities. So during observations the observer may note some
behavior or activities; which is not very clear and at that point of time the observer or in a later
time the observer can ask the user about more clarification of the particular behavior or the
activities. So in that sense interview acts as a supporting tool in the overall observation process.
(Refer Slide Time: 09:34)
Generally the contextual inquiry process continues for 1 to 2 hours along the duration may be not
very desirable because the users may not like to participate in the process for more than 1 to 2
hours. And also for a longer duration observations the observations may reveal similar things
without much gain in behavioural knowledge.
(Refer Slide Time: 10:10)

So what is the purpose now these observations that are made during the inquiry process which
include interactions with the users in form of interviews. Enable the designers of the interactive
system to learn about the task domain, work culture and physical and social constraints that are
prevalent at the workplace. So various idiosyncratic attributes of the workplace with respect; to
the user behavior and participation can be learned through these observations.

Now this knowledge is very important because the designer should be aware of the specific work
context which is part of the definition of usability. So by these observations the designer can
become knowledgeable about the specific work context and accordingly will be able to design
usable product.
(Refer Slide Time: 11:28)

In; order to understand the importance of observations in the development of usable product. Let
us recollect our calendar app example that we mentioned in our earlier lectures.
(Refer Slide Time: 11:47)
Now suppose the target group of users, are identified as the managerial staff of some
organization. So we have pinpointed the user group they are the managerial staff of some
organization and we made some observations about their behavior during their working hours.
(Refer Slide Time: 12:17)

Without any knowledge about the intended user behavior particularly in their work settings we
can come up with all sorts of possible calendar designs as we have already discussed earlier. So
earlier we discussed couple of alternatives for the design of the calendar app but their; these were
done based on our intuition rather than any specific knowledge about the target user behavior. So
that is likely to be the case if we do not have any specific knowledge we will end up with many
alternatives.
(Refer Slide Time: 12:59)

However in contrast to that suppose we now performed a contextual inquiry and observed that
the intended users perform 2 important activities during their working hours set meeting dates
and set reminders. Suppose we have observed this that they quite frequently perform these
activities then with this knowledge when we are going to develop the calendar app we know
what features to be kept in the app. So that it becomes usable to the target group of users namely
the managerial stuff.

So if we do not keep these features then the calendar app will not be very much usable to the
intended users because they anyway perform these activities and they have to take request to
other tools at their disposal to perform these activities. But if we keep the same as features in our
calendar app then they do not need to use other tools they can directly use the app and using
those features they can perform their activities.

So it will make the product more usable to that particular user group and the idea of this feature
comes from observing their behaviour in their work settings.
(Refer Slide Time: 14:35)
So that is the importance of having performed contextual inquiry before embarking on the design
of the system. So with that we got some idea of what is contextual inquiry? To repeat this is an
observation based approach to gather end user requirements where we observe the users in their
natural work setting. And observation can be supported by unstructured interview. The observers
can ask queries or questions to the users to get more clarification on certain behaviour or
activities that they might have observed during the contextual inquiry process.

Now the contextual inquiry can be performed in different ways so broadly there are 2 ways to
perform contextual inquiry.
(Refer Slide Time: 15:38)
The active mode and the passive mode in the active mode the observer is physically present in
the work setting where the users are being observed. So observer is physically present and
captures the observation in some form either handwritten notes or videography or something
whichever the observer feels comfortable with he or she captures the observations.
(Refer Slide Time: 16:22)

In passive mode the observer is not physically present instead the user activities are recorded or
videotaped and the observer reviews those videos or recordings at a later time. So in active mode
observers, are physically preset and observes in passive mode some setup is used to record user
activities and those recordings are observed later by the observer.
(Refer Slide Time: 16:57)
One crucial thing to note here is that contextual inquiry is not about lecturing the user what to do
and what not to do? Here during the inquiry observers should act as apprentice or trainees and
treat the users as masters. So this master apprentice model is a quite popular model to perform
contextual inquiry here it is assumed that the users are masters and the observers need to learn
from the users.

So they should act as apprentice for the purpose of learning from the users learning their
behavior. So purpose is to learn from users their behavior rather than to teach them how to
behave in a work setting. So occasionally there may be a tendency in the observers to teach or
lecture the users about how to do things while they are observing user behaviour so this should
be strictly avoided.
(Refer Slide Time: 18:12)
Now let us learn about different stages so contextual inquiry can be thought of as consisting of
multiple stages of activities there are broadly 5 stages.
(Refer Slide Time: 18:25)

What are those 5 stages? First stage is plan then the second stage is initiate then we have execute,
then close and finally reflect so there are 5 stages plan, initiate, execute, close and reflect.
(Refer Slide Time: 18:55)
So what is the plan stage? So here we generally create a plan on what to do or what are the things
that we need to do? So it involves identification of the goals of observation so what we want to
observe? Knowledge gathering about task domain some prior knowledge also arrangements for
recording the, observations how to record the behavior? Identification of users and the date time
and place of observation so identification of observational setup and users.

All these can be converted to a script and can be rehearsed many times before the actual
observation takes place so that it is smoothly done. So, all these are part of the first stage that is
planning stage planning for observation.
(Refer Slide Time: 20:04)
In the second stage or initiate stage although it may look simple but this is very important and
crucial phase of the contextual inquiry. Here we need to contact the authorities for permission
and open communication with the end users so that they willingly participate in the observation
process. So occasionally if we simply drop in and asked them to let us observe then people may
not agree.

So some sort of communication should be established between the end users and the observers
before the observation takes place. So that the users become confident and allows the observers
to observe them during their working this also requires prior permission from the management
staff which needs to be obtained.
(Refer Slide Time: 21:12)

The third stage is the actual data collection stage in this stage observation takes place and data
collected.
(Refer Slide Time: 21:14)
The fourth stage is the closed stage like initiate this is also a very important stage although it may
look simple and trivial. Here generally the observation is ended with a thank you note sent to all
the participants along with the authorities. Because if this type of initiatives are not taken then
later on suppose the data turned out to be insufficient and you need to collect more data or later
on during the empirical study stage you need to engage the same users for empirical study they
may not agree if this closed stage is not properly done.
(Refer Slide Time: 22:05)

The fifth and final stage is the reflect stage in this stage the data that we have collected through
observations are analyzed to identify the design goals. Now this is not easy at all as we shall
soon see with examples why? Because there may be lots of data and going through this data to
identify specific design goals are generally not very trivial. We can make use of tools and
techniques available to analyze the data and find out design goals one such technique is the
affinity diagram method. Let us quickly have a look at the method and how it can help in
analyzing the data?
(Refer Slide Time: 23:06)

Now this method contains five steps what are those steps? Generate idea, display ideas, sort
ideas into groups, create group header, by group header it means the create names for each group
and finally draw the finished Affinity diagram. So the method involves these 5 stages generate
idea, display idea, sort ideas into group, create group name or header and finalize the diagram.
(Refer Slide Time: 24:01)
Let us try to understand these stages in the form of an example. Suppose we are trying to build a
class note taking application which is primarily meant for college going students. So we have
performed contextual inquiry to identify the end user requirements so that the application is
usable. And we are now trying to make use of the affinity diagram method to identify the design
goals for this particular application.
(Refer Slide Time: 24:47)

Let us assume that CI is already done and some observations are recorded now 2 record
observations let us assume that three tools have been used to study the behavior, a physical pain
and paper based note taking, one web application notion dot so. And xournal++ desktop software
these three tools have been used to computer based tool and one pen and paper based traditional
note taking have been used to observe and record user behavior during actual classes or the
actual work setting.
(Refer Slide Time: 25:45)

Now these observations we want to analyze using the affinity diagram method. So let us see how
affinity diagram method can help us analyze the observations?
(Refer Slide Time: 25:59)

So among the 5 steps let us concentrate now on the first 2 that is generate ideas and display
ideas? So suppose we have collected some notes during our observation in this form sticky note
form. So one observation is multi-level organization of notes not possible that is one observation
we made during our contextual inquiry phase another observation may be free hand drawing is
not accurate during not taking drawing may be part of it.

But freehand drawing generally is found to be not very accurate or of high quality a third
observation that is made is navigation between different topics is cumbersome. Fourth
observation content relocation not possible in physical note-taking approach of course something
written somewhere is not possible to move to some other page because that is the limitation of
pen and paper based approach.

A fifth observation difficult to search keywords in notes another observation cannot insert any
images. All these observations are written down as notes with sticky notes and may be pasted on
a wall for analysis that is a traditional approach for brainstorming with the observations. Note
number 7 erasing contents is a difficult and daunting task that is another observation made by the
observers. Sorting of lectures by dates is torturous yet another observation made by the
observers.

One note says incorporating mathematical symbols not supported by one of the tools probably
that is not specified but this is one note written down to record observation. Text formatting
should be handy again with respect to probably one of the 2 computer based tools used to
observe behavior. Organization of course wise notes difficult that is another observation so many
observations have been made.

So this is only a subset of all possible observations that could have been met with respect to the 3
tools and user behavior. This is just to give some idea of what is meant by data collected during
the observational phase. So these are the data that we collected in the form of handwritten notes
it can also be in the form of video and handwritten notes after reviewing the video.
(Refer Slide Time: 29:23)
Now so many notes are or the observations are recorded so what we need to do now you need to
display the ideas. So this is one way of displaying the ideas so these ideas are pasted on some
surface can be wall can be whiteboard. So that other team members who are part of analysis of
the data can have a look and then give in their comments or feedbacks.
(Refer Slide Time: 30:00)

The third stage is sort the observations into groups; third stage of the affinity diagram method is
sorts it into groups. That means behavioural observations that are similar in nature should be
sorted into groups so among these observations that have been listed what are or which of the
observations can be considered to be similar which can be then put together into a group let us
see?

So these 2 observations multi-level organization of notes not possible and sorting of lectures by
dates torturous can be considered to belong to same type of behavior so that these can be put in a
single group. Similarly organization of course wise notes difficult belongs to the same group now
these 2 notes navigation between different topics cumbersome and difficult to search keywords
in notes points to similar problem faced by users during their activities and can be considered to
be pointing to same issue in the design.

Again content relocation not possible in physical pen and paper based method and erasing
contents is a daunting task. Again implicitly refers to similar problems faced by users so they can
be considered to belong to the same group of observations.
(Refer Slide Time: 31:49)

So in this way from the display of the ideas we can try to correlate the observations and then put
them into some group. In step 4 these groups are assigned some names or some headers for
example these 3 observations sorting of notes by dates is structure as multi-level organization of
notes not possible. Organization of course wise notes difficult these three observations can be
clapped together into a single group with a, header navigation in notebook or notebook
application.
So in step 4 we assign the header to this group of observations and the header actually gives us
some idea of the issues the design issues or the usability issues that need to be addressed to make
the product usable. 2 more groups that we have seen earlier; comprising of one group comprising
of these 2 observations and this is the header. The observations are difficult to search keywords
in notes and navigation between different topics is cumbersome.

So these 2 observations are combined together into a group with header navigation in notes.
Similarly erasing contents is a daunting task and content relocation not possible in physical or
pen and paper based note taking approach. These 2 observations can be considered to belong to
the same group and a header is assigned to it namely not organization. So in this way we group
different observations together and assign them headers so that is the fourth step in the affinity
diagram method.
(Refer Slide Time: 34:06)

The fifth step is once the headers are assigned and the observations are grouped we again display
or draw the final drawing. So all these notes are now grouped say for example these 3 are
grouped together with this header these 5 are grouped together with this header. These 2 are
grouped together with header another group with header there are 4 observations in this group
with header and 3 observations in another group with header.

So there are total 19 observations made after the contextual inquiry of course this is a small
number in practice it can be 100 and then these observations are put into 6 groups. So 19
observations 6 groups and for each group one header is assigned so 6 headers so that is the
outcome of the analysis method. So to repeat we first generate ideas after observations or during
observations.

If it is active mode then during observations we generate ideas if it is passive mode then after
observation during reviewing of the recordings we generate those ideas. Then we display them in
some manner maybe on some surface then brainstorm in a team to sort similar observations into
groups and then assign some headers to those groups. So this groups with headers the set of all
these groups with headers is the outcome of the method. So what to do with this outcome?
(Refer Slide Time: 36:52)

We can come up with a set of design recommendations. For example in this case in the note
taking application case based on the observations that we have made. We can come up with the
recommendations such as for correcting mistakes there should be a provision to erase the content
this would help in keeping the notes neat and tidy. This can be one design guideline provided to
the designer which is likely to take into account users concerns and make it usable how we can
say that?

We can say because we have collected these requirements through user observations in a
contextual inquiry method which is a usability requirement gathering technique. We can actually
also come up with some functional requirements by converting this type of design resonance. As
we shall see in later lectures one thing to be noted here is that here we are not talking about how
to take into account this design recommendation how to implement it?

Rather what we are talking about here is what we need? So our objective is what we need to
make the design usable rather than how to implement the particular thing that we need? So the
outcome of affinity diagram method is set of design rationales or it may lead to set of functional
requirements. So in our subsequent lectures we will see what, is functional requirement and how
it is important in system design? So affinity diagram output can be used to come up with
functional requirements which will take care of usability requirements implicitly.
(Refer Slide Time: 39:02)

So that is all for today is topic so what we learned? We learned about contextual inquiry what it
is and how it is done? We also learned about how to analyze the data that we have collected or
we collect during contextual inquiry. I would like to repeat again so contextual inquiry is not an
interview only it is primarily an observation to observe user behavior in their work setting. And
semi-structured interview can be used as a supporting tool to get clarifications on certain user
behaviors or activities that is noted during observation.

We have also got some idea of how to analyze the data through the affinity diagram method?
Whatever we have covered can be found in this book you are requested to refer to chapter 2
section 2.4.3 of this book. That is all for this lecture hope you have learned the topic and enjoyed
it thank you and goodbye see you in the next lecture.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology, Guwahati

Module No # 02
Lecture No # 07
Functional specification of Requirements

Hello and welcome to the NPTEL MOOC’s course on design and implementation of human
computer interfaces. We are going to start lecture 7 which is related to requirement specification
particularly specification of functional requirements.
(Refer Slide Time: 01:02)

If you can recall we are currently discussing the software development lifecycle stages where our
primary concern is to develop interactive software. Now interactive software again just to
recollect refers to a class of software that are supposed to be used by layman users who are not
experts in the technology. For them we need to take into account various things most importantly
user feedbacks at different stages of development.

And in order to do that we have a special or a specific software development lifecycle meant for
building interactive software and we are currently discussing different stages of the life cycle. To
recollect there are several stages requirement gathering, analysis and specification is the stage
from where we started our discussion. We have not discussed in details the feasibility study stage
which is not very relevant for our core concepts.
After requirement there is this design stage, prototyping stage and evaluation of prototyping
these 3 sub stages in a cycle constitute the design prototype evaluate cycle. Now here design
refers to both design of the interfaces as well as interactions and also design of the system in
terms of modules. Now those modules once finalized are to be implemented using programming
some sort of programming language that is the coding and implementation stage.

Once the system is implemented we need to test it test the code that is the code testing stage after
the entire system is coded implemented and tested. And we are to some extent assured of its
executability we still need to test it for usability. Which is one of the key concerns in our
interactive systems and that is done in the empirical study stage which is expected to be done
once or twice at the most because this stage is quite costly.

However there is a possibility that output of this stage can lead here and there can be a cycle. So
once this study stage is complete and we are assumed of the usability as well as executability of
the system we go for deployment and maintenance that is our last stage. Currently we are
discussing the requirement, gathering, analysis, and specification stage.
(Refer Slide Time: 04:11)

Now we learned about usability earlier which is one of the crucial aspects of the design of
interactive system. We also have learned about the usability requirement gathering why that is
important and how it helps building a system that is likely to be acceptable to the end users? We
have gone through in the previous lecture one method of requirement gathering particularly
usability requirement gathering that is contextual inquiry.

Again it may be noted that this is only one of many such techniques however we discussed this
technique contextual inquiry technique in some details.
(Refer Slide Time: 05:01)

Now contextual inquiry technique; is used to gather the requirements. And we have also seen
how these requirements can be analyzed whatever we have gathered during contextual inquiry
can be analyzed to identify design goals or some such things through the reflect stage using
various tools such as affinity diagram method. So we discussed in details affinity diagram
methods with examples to understand how the observations that are made during contextual
inquiry can be converted to some design guidelines or something that can help us design usable
product.

In this lecture our focus is actually how to specify those designs so that other team members can
make use of the specification in subsequent stages of the life cycle. So this lecture will primarily
focus on notations and conventions that are used for specification of system requirements that is
the subject matter of this lecture.
(Refer Slide Time: 06:20)
Now before we go to the actual subject matter let us quickly recollect that whatever we have
termed as usability requirement earlier is also known as non-functional requirements. This is a
term that is used to refer to requirements such as usability and some other things so usability
requirements are one type of non-functional requirements. So what are the other non-functional
requirements let us have a quick recollection of those types.
(Refer Slide Time: 06:58)

So there we can have performance related non-functional requirements operating constraints that
can be listed as non-functional requirements. Economic considerations which are again
considered to be non-functional requirements life cycle requirements and finally interface issues
that are non-functional requirements. Now among these interface issues both hardware and
software interface issues are used are referred to and the software interface issues are generally
termed as usability which belongs to this kind of non-functional requirements.
(Refer Slide Time: 07:44)

And we have repeatedly emphasized that usability is one very important non-functional
requirement that has to be taken into account while we are going to build an interactive system.
So we have discussed several non-functional requirements which are very important in the
context of system design.
(Refer Slide Time: 08:11)
And in particular we have discussed usability which is very important in the context of
interactive system design now they are of course important. But one issue with non-functional
requirements only is that these are difficult to formally specify and unless they are properly
specified. Unless we are able to specify the requirements in a proper way a suitable way it is
difficult to convert them to design requirements or into a proper implementation of the system.

So we need to somehow be able to specify these requirements in a proper way but unfortunately
non-functional requirements are not very much suitable to be converted to that proper way. So
that we can immediately be able to convert it to some implementation or some design of the
system.
(Refer Slide Time: 09:12)

In fact whenever we are talking of system requirements and this next stage is implementation
then our objective should be to have requirements which are easy to understand and implement
in the form of a program. That is one sort of requirement of the requirements so to speak that we
should aim at. And in order to achieve that what we need is some formal way to specify the
requirements that is required.
(Refer Slide Time: 09:50)
Now when we say that we want to formally specify the requirements that means we want to
make it easy for the team to implement the next stage of the development lifecycle by team I am
in the development team. And when we are able to do that when we are able to specify
requirements in a somewhat formal manner for quick implementation those requirements are
generally called functional requirements.

They have these properties that they are easy to understand and convert to codes we shall see
with some examples what we mean by these terms that convert to codes easy to understand and
so on.
(Refer Slide Time: 10:41)
Now as the name suggests so the name is functional requirement so as the name suggests
functional requirements specify a system or the requirements of the system in terms of functions.
What are functions? Mathematically functions are defined in terms of its input output and here
also we specify the requirements in terms of functions that take some specific input produces
some specific output and these functions also typically has some purpose mentioned in the
specification. So in functional requirement we have functions defined in terms of input output
and purpose.
(Refer Slide Time: 11:35)

So let us depart into the idea of functional requirement specification what are those and how to
specify?
(Refer Slide Time: 11:50)
Now before we are able to create a functional requirement specification we should be aware of
few things first of all when we are talking of functional requirement specification the main idea
is abstraction. What is meant by this term is that? We only need to identify black box functions to
be supported by the end product or the system. And in this black box functions we need to only
specify the input and output.

So, in other words abstraction tells us that identify only the need rather than how to achieve it. So
we do not know how the function can be implemented or defined rather only what input it will
take and what output it should produce. So the function in itself appears to be a black box with
only an input and output specified rather than how the function should be implemented? So that
is the first thing that we should keep in mind here we are trying to only identify functions as
black boxes rather than trying to design algorithms to implement the functions.
(Refer Slide Time: 13:07)
Second thing is decomposition and hierarchy so when we are trying to identify the functions we
should decompose the entire requirement into some sort of hierarchy of functions and sub
functions. Otherwise it will be difficult and too complex to specify the functions. If we can think
of hierarchical representation of functions and sub functions then it will be easier for us to
specify the function input and output much more easily than if we do not follow any hierarchy.

So essentially this decomposition into hierarchical levels and the levels of the hierarchy help us
better manage the description or the functional description of the system. So we need to have
abstract notion of function as black box with only input and output. And also we need to think of
the functions in the form of a hierarchy so that we are able to better manage it easily define it and
so on.
(Refer Slide Time: 14:22)
So what are the key points that we should remember while defining these functions? First thing
is we should avoid exploratory style of definition what it means? It should not be the case that
first we should think of implementing the functions and then from there we go back and think of
creating the functional hierarchy. That is exploratory style first we keep on implementing and
then from that implementation we learn about the presence of the functions.

It should be the other way around first we should think abstractly the functions and then think of
how to implement them in a letter design stage. Abstraction as we have already pointed out the
function should be thought of in a very abstract form. We should not start thinking about the
algorithm to implement the functions rather we should think of functions as black boxes and only
input and output need to be thought of plus the purpose of the function.

And finally it will be easier to manage the specification if we can think of the functions in the
form of a hierarchy of functions and sub functions rather than only one level that will make
things easier to manage. So these 3 things we should keep in mind we should try to avoid
exploratory style, we should think of functions as black boxes and we should try to think of a
functional hierarchy to represent the all the functions in the system.
(Refer Slide Time: 16:04)
Keeping these in mind we should come up with a functional hierarchy that should be our end
product in the functional requirement specification stage. And when we put these requirements in
textual form in some specified format what we get is called the SRS or software requirement
specification document. So SRS this acronym comes from these terms these words software
requirement specification.

Now this SRS document is essentially our quote unquote formal representation or specification
of the requirements. So our objective is to create an SRS document after this functional
requirement specification stage is over.
(Refer Slide Time: 16:59)
Now in SRS there are specific formats to be used generally what is followed is a hierarchical
structure with some name given to the hierarchy levels like r 1, r 1.1 and so on. And at each level
or r where r 1.1 etcetera which indicates the hierarchy each level represents a function with
clearly defined input and output and some description which is optional. So when we are trying
to specify SRS essentially we need to use these notations that; is a common practice that we
create hierarchy label.

The hierarchies each level of the hierarchy should be given a label with some name and some
description and these levels can further be decomposed into sub levels with similar notation.
Now let us try to understand this idea of creating SRS from a functional requirement hierarchy
let us try to understand this with respect to one example.
(Refer Slide Time: 18:33)

If you may recollect we introduced this example in one of the earlier lectures this is a class note
taking application where the primary users are likely to be the college going students. So earlier
we have seen how to create usability requirements for this application using the contextual
inquiry method. Now let us try to see how we can create a functional requirement specification
for this application.
(Refer Slide Time: 19:06)
What are the requirements that we can identify for this application? One obvious requirement
can be authentication that is for a user to access the app feature so the user needs to authenticate
which is common for all the apps. So we can have such a function as a requirement
authentication function now authentication function can further be decomposed into sub
functions.

For example there can be one requirement to create an account that can be one sub function
under authentication. Then there can be a requirement to login that can be another function under
authentication function one more function can be management of the account, account
management it can be treated as another sub function of the authentication function.
(Refer Slide Time: 20:13)
So diagrammatically we can put these functions and sub functions in the form of a hierarchy as
shown in this figure. So here at the top level of the hierarchy we have authentication function
then under authentication we have these 3 sub functions create new account login and update
password. So update password can be one sub function under authentication function.

Now update password can have sub functions under it as well for example there can be one sub
function send one time password can be another sub function set new password. So this can be
one way of creating a functional hierarchy for the authentication function. Of course it may be
noted that this cannot be the only way possible you are free to create your own hierarchy for
authentication you can add more functions edit some functions and so on. So this is just one
example of how such a hierarchy can be created.
(Refer Slide Time: 21:29)
Let us look at another high level function this is related to managing the notebook in the
application. So this can be a higher level functional requirement that the user wants to manage
the notebook. Now under these functions there can function there can be many sub functions
again it can lead to a hierarchy of functions and sub functions. For example there can be a
requirement to create or delete note, can be a requirement to open or close a note. Can be a
requirement for editing a note, can even be a requirement for viewing all the notes and so on.
(Refer Slide Time: 22:33)

So we can create another hierarchy for notebook management function graphically we can have a
representation like the one shown here for such a hierarchy. So at the top level we have notebook
management functionality under this there are some functions create note, create notebook, open
note, edit note, list notebook contents, delete note, delete notebook etcetera. Under edit note we
can have further decomposition add text, draw content, insert image, manage table, delete
content etcetera.

Under draw content further decomposition is possible like draw shape, freehand drawing etcetera
similarly under manage table further decomposition is possible with sub functions like create
table, edit text, insert row, insert column and so on. So what this hierarchy shows is that? It is
possible to create a decomposed functional requirement hierarchy which will make it easier to
understand the overall requirements.

Instead of this hierarchy if we have simply mentioned this top level hierarchy like notebook
management then it would have been difficult to actually specify input output as well as
description. What this is supposed to do? Because in that case it would have been very complex
to specify those things instead of that by decomposing we are able to better manage this
complexity by dividing it into sub function.

So then now what we need to do is basically specify only the input output for the sub functions
which is much more easier compared to specifying everything for only one function.
(Refer Slide Time: 24:49)
Let us see one more functional requirement example for the same application requirement for
searching in the notebook. Now this can again be considered to be a higher level functional
requirement top level and under this there can be several sub functions again creating a
hierarchy. Requirement for searching by text this is one possible sub function another possible
sub function can be searched by date.
(Refer Slide Time: 25:24)

Then we can have a hierarchical depiction of the functional hierarchy in this form where we have
search in notebook under which there are 2 sub functions search by text, search by date.
Similarly we can have another high level hierarchy search in note and it is possible to decompose
it further.
(Refer Slide Time: 25:55)
So then what we get what we get is a larger hierarchy so we merge these hierarchical
descriptions together to get a larger hierarchy to represent the functional requirements of the
system. Of course this is not complete but it will give you some idea of what we mean by
hierarchy. So, here as you can see we have top level functional requirements authentication,
notebook management, and search in notebook, searching note.

Then we have second level hierarchy create account login, update, password similarly create
note, create notebook and so on. Then we can have third level also one time password, set new
password even fourth level in this case draw shape, free and drawing etcetera. So there is no
restriction on up to how much level we can go the more decomposition is the better for
specification.

It will bring in clarity of thought if you have very less number of levels and everything in the
single level then it is generally considered to be not a good specification assuming. That the
system is complex for very simple system of course that multiple levels of hierarchy; may not be
required.
(Refer Slide Time: 27:41)
Now so far what we have discussed is just a visual depiction but that is not a specification as
such for the requirements. Now we need to have a textual description as I mentioned before so
textual description follows its own format with level numbers r 1, r 1.1 etcetera and function
name input specification output specification and some function description. Still considering the
function as a black box rather than describing the actual algorithm to implement the function.

For example let us consider this functional requirement create new account so this is as you can
see it is second level. So we can call this level 1 and then create new account can be termed as
level 1.1 the same thing we have used to denote in the textual description this is the level
indicator then we have given it a name which is the same name that we have used earlier create
new account.

Then there is one input specification so what input this function takes it simply mentioned user
information. So it can be any information so it is possible to keep it vague at this stage because
we are not going to discuss about how to implement? So the flexibility should remain output
specification also is required here it is mentioned that some message will be given as output. And
then there is this optional section on description of the function.

So it says what the function does purpose simply says create a new account using user details
and display account creation message that is simply the purpose so in this way we can specify
the functions in the functional hierarchy.
(Refer Slide Time: 30:00)

Similarly we can create specifications for other functions say for example the second function is
login so accordingly we gave it the number R 1.2 as you can see in the hierarchy. So the first one
if it is given R 1.1 then we can call it R 1.2 then R 1.3 then this 1.3.1 and so on. So we are
following this nomenclature note that this need not be the only way to represent levels and in
different places you may find some other ways to represent these levels of the hierarchy.

However here in this course we will follow this convention so the level number is followed by
the name of the function some name you have to give, then input specification, output
specification and description brief description of what the function does? Like it simply says
verify user credentials and provides access to user data. Note that nowhere we are referring to
any details related to how the function can be implemented.

For example here in login we are not telling how this function will produce the output with from
the input. So how this processing takes place or the algorithm to create the output is not specified
anywhere it only states the purpose rather than the actual way to implement it.
(Refer Slide Time: 31:48)
Some more examples R 1.3 update password then 1.3.1 send one time password input, output
and description. It is generally preferable that higher level also you specify the input, output and
description optionally for each level function you should do that not only for the leaf level notes
that are mentioned here. So for our 1.3 also you should specify what is the input? What is the
output and what is the description?

Then do the same for R 1.3.1 that is the sub function of 1.3 as well as our 1.3.2 this is the another
sub function of R 1.3 set new password input output description. So at each level for every
function you should ideally specify the input output and description for each and every function
in that level. One common mistake occasionally we perform is that when we are specifying the
output we also specify some functional words.

For example here send one time password output we may be tempted to write send one time
password. Now the with the addition of the word send it no longer remains an output rather it
becomes a process in itself so try to avoid using this type of action words in either input or
output if you are using action words then the description is wrong. So you must keep this in mind
and avoid using action words any sort of action words in the input and output. Otherwise those
will not remain input and output instead they will become functions itself.
(Refer Slide Time: 33:59)
So another top level note create note again input output description specification is given in a
similar manner. So you can now get some idea of what we mean by formal specification. So here
we are giving a level name, a label to the level name, name of the functional requirement some
idea of the input to be provided to the function in a very flexible and open manner. It should not
be very specific because here still we are talking of black boxes as functions so we are not going
into the details of any algorithmic design.

So our input should be kept as much open as possible like here we are simply mentioning that
provide as input location and name but in which format how all these details we are not
providing so that is a flexibility that we want to keep at this stage. Similarly for output we are not
specifying the exact nature of the output instead a broad idea of what the output should look like
and what it should what purpose it should solve rather than exactly which format it should be
produced in and how it should look.

So this idea of labels, names input, output specifications. As well as the idea to keep the inputs
and outputs flexible and open to interpretation for subsequent design and implementation stages
are key things that should be remembered while designing and specifying the functions.
(Refer Slide Time: 36:04)
Then comes open note R 2.3 again with input, output and description and this openness is here
also note location but not exactly in which manner whether it is a single number, coordinate that
we are not specifying. Similarly content what this content means it is left to be decided in later
stages rather than specified here itself and also a description broad description of what the
function is supposed to do?
(Refer Slide Time: 36:42)

In this way we can specify all the functions in the hierarchy for simplicity and brevity we have
omitted certain parts. Like here R 2.4 edit note the input, output and descriptions are omitted
only the lowest level note shown to have this description. But remember to add it for each level
like R 2.4, R 2.4.2 draw content as well as 2.4.2.1 draw shape which is a sub function of this
function which is in itself; as a function of this function.

So draw shape is a sub function of draw content, draw content is a sub function of edit note and
for each of these levels we should have input, output and description as shown here input here
output here and description. So when we have created this hierarchy our next task is to create this
textual description in the format shown in the examples. Again this is not the only way to specify
there can be a different; conventions followed however broadly it should convey the message of
the level which level the function is situated at then the function name, input, output and
description.
(Refer Slide Time: 38:17)

So you should note in the examples how the functions are represented name, input, output,
description, plus the level number all 5 are important. Then another thing to be noted here is that
the abstract nature of the representation. So none of the functions that we have seen in the
examples tell us anything about how to implement those how to convert them to notes? So
effectively what we are looking at is a black box where we provide the input and get the output
without bothering about how we get the output.

So that abstract nature of specification should be noted and the hierarchy of course how we
created the hierarchy to represent the requirements should be noted and should be followed in
problems that you face. Also as I said follow the naming conventions typically what we have
shown here can be followed but there can be other possibilities.

However anyone should be followed consistently throughout the life cycle. So we have shown
one convention where we gave particular level of the hierarchy and used name for the function
then input kept it open, output kept the scope open, some optional description part which should
be done for each and every function in each and every level. It should not be considered only
required at the last level even at the higher levels also for each function you should have ideally
input, output and description specified.
(Refer Slide Time: 40:16)

The example that I have shown of course is not complete and as a put forth thought you can
think of completing the hierarchy as well as the specification.
(Refer Slide Time: 40:30)
So with that we come to the conclusion of this topic so what we have covered today is what are
functional requirements? What are the things we should keep in mind while creating functional
requirements and how to specify those requirements? So one thing you should keep in mind is
that this, functional requirements need not be created based on end user studies. Some domain
knowledge plus some discussion with the clients may be good starting point to create the
functional requirements.

Then subsequently once usability requirements are available some of those requirements can be
converted to functions and put in the functional requirement hierarchy and subsequently included
in the SRS document. We shall see in a subsequent lecture how to do that, apart from that other
things we should keep in mind is that how the functions are specified? How they are decomposed
how they are labeled and what are the things to be specified in the SS?

To recollect we need to specify for each function at each level its level, its name input, output
and purpose. And in the input and output we should not be too specific about the nature of the
input and output rather we should keep it open for interpretation at later stages of the
development life cycle. Because here we are not bothered about how the functions are to be
implemented rather what the function should do?

Accordingly we can keep the input and output somewhat open ended and flexible to
interpretation whatever I have discussed today can be found in these books for further details you
can refer to chapter 4 of the first book and chapter 7 to 8 of the second book. With that we
conclude today is lecture I hope you have got some idea of what we mean by functional
requirement and how to represent it both visually as well as formally in textual format in the
form of SRS document.

In subsequent lectures we shall see how usability requirements can be incorporated in the form
of functions in functional requirements. So that our systems can have better usability that is all
for today see you in the next lecture thank you and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology, Guwahati

Module No # 02
Lecture No # 08
Case Study on SRS

Hello and welcome to NPTEL MOOCS course on design and implementation of human
computer interfaces. So in the previous few lectures we learned about interactive system
development life cycle and we started our discussion on requirement gathering analysis and
specification stage of the life cycle. So we will continue our discussion on this stage which is one
of the several stages that make up the whole life cycle.

Now earlier we have seen that in the requirement gathering analysis and specification stage there
are 3 distinct activities one is gathering of requirements which includes both usability
requirements as well as other feather related requirements from the clients. Then we have also
seen analysis of those, requirement gathering outcome so that we can finally come up with
specification of those requirements.

We mentioned that at the end of these activities what we get is a document which is called
software requirement specification or SRS. Now SRS is the outcome of the stage of requirement
gathering, analysis and specification this document is passed on to the next phase to the next
stage of the life cycle the design stage. Where based on this document we go ahead and build a
design document. So SRS creation is very important activity and subsequent activities of an
interactive system development life cycle relies heavily on this stage.

Now so far we have seen what are the different types of requirements? Usability requirements
which are one of non-functional requirements we have also seen functional requirements we
have seen how we can specify functional requirements. We have also mentioned that
non-functional requirements can be specified as functional requirements after conversion later,
on, we will see some more examples on this.
But in this lecture what we are going to discuss is a full SRS document how it is created what are
the components present in it how it looks. And so on because so far we have discussed the
concepts related to SRS document in a piecemeal manner. Let us now try to put them together
and see the whole document for better understanding of the documentation process.
(Refer Slide Time: 03:21)

So the document is supposed to have a cover page for example here we can see the cover page of
a document SRS document created for a specific system the system is student activity monitor
and alert generator. So this is the name of the system which, does few things namely monitoring
student activities and generate some alerts based on the activities. So we can name it as software
requirement specification for this system then note that few more things are mentioned like
person name.

So it need not be the case that the final document is the only document that is created it may have
undergone several changes and evolved over time before it is finalized. So, each of these
intermediate documents are given a version number to distinguish it from earlier and later
documents or versions. And that information is ideally to be conveyed to the reader of the
document through this convention the current version of the document along with the date on
which this document is created.

Then ideally in the cover page the persons or the team that created the document should be
mentioned. So you can mention prepared by so and so and so and so giving the name of the team
members. You can also provide the place where it is created for example here it is mentioned IIT
Guwahati so IIT Guwahati it has been created. And if there is any mentor who helped in creating
the document like here the way it is mentioned.

So, in the cover page then what we should keep first this title software requirement specification
doc for student activity monitor and alert generator which is the name of the system. Then
version number then date on which the version on which this version is created. Then the people
who have created it prepared by so and so place where it is created and finally if there is some
mentor. So this of course is optional and it need not be present everywhere but other things
ideally should be kept in the cover page or the title page.
(Refer Slide Time: 06:42)

Then comes; the content section so here for better organization ideally you should include one
content table of contents. Which; will list out the content of the document in the form of sections,
and sub sections as you can see here in this document there are several sections. Section on
introduction then overall description, then external interface requirements, functional
requirements other non-functional requirements and so on.

Now under introduction section as you can see we have several subsections named and labeled
accordingly say purpose of this document, document conventions, project scope, scope of the
project. Similarly under overall description we have several subsections product perspective,
product functions, user classes and characteristics, operating environment, design and
implementation constraints, assumptions and dependencies these are subsections under overall
description section.

Under external interface requirements subsections are user interface, hardware interface,
software interfaces and communication interfaces. So, all sorts of interfaces that are part of the
documentation process are covered under this section. Then for functional requirements so we
already discussed that in the SRS there are primarily functional requirements and also
non-functional requirements.

For functional requirements we have one dedicated section functional requirements where for a
different class of users the different functional requirements are provided. For this system there
are 2 user classes identified instructor and student this system is primarily meant to be used in a
classroom setting. So there will be an instructor and several students so for each of these
stakeholders of the system or the end users you have different functional requirements listed
here.

A separate and dedicated section is there on non-functional requirements such as performance

requirements, security requirements, software quality attributes and so on. So these are the way
the overall content of the document is organized in the form of sections and sub sections.
(Refer Slide Time: 09:49)
Next ideally you should include in your SRS some revision history. As I mentioned the
document may have gone through several iterations before it is finalized so each, iteration is a
version. So how many versions have been created a brief history can be given for example for
this particular document. This section revision history notes down or indicates that there are
there were three versions created version 1, version 1.1 and version 1.2.

So version 1.0 was created on this date it was the original document created then on a later date
version 1.1 was created based on the comments received from the mentor of the team. So this
second version is modification of the original document then in another later a third version,
version 1.2 was created which was the final version for the SRS document. So this is again after
some more comments were received from the supervisor or mentor of the team.

So ideally in a SRS document you should list this revision history for record keeping then the
actual content of the document starts.
(Refer Slide Time: 11:30)

So it starts with the introduction section as we have seen in the table of content section so there
are several sub sections. One is purpose what is the purpose of this document why we are
creating it here in brief you are expected to write the purpose. For example for this document the
purpose is written as the purpose of this document is to give a detailed description of the
requirements for the student activity monitor and alert generator software.
So that indicates the purpose it will illustrate the purpose and complete declaration for the
development of system along with the system constraints that is also one of the purpose for this
document. This document is primarily intended for intended to be proposed to a customer for
their approval and as a reference for developing the first version of the system for the
development team.

This is the more crucial aspect of the purpose that it is to be shown to the customer for their
approval and then it is to be shared with the development team for them to start design and
development process. So that is in brief you should include the purpose for this document. Then
if you are using some conventions in the document for easy understanding of the readers of this
document you should list those out in a separate subsection as shown in this document.

So there is a dedicated sub section document convention under introduction section where all the
conventions that are used in this document are listed. So it is a table having 2 columns one is the
term or the notation used another one is the definition of that particular term. For example when
the term instructor is used it is defined as person who shall be using the software for monitoring
purpose.

When the term student is used it is defined as person who shall be monitored by the instructor.
When the term device is used it is defined as an electronic device using which the instructor is
delivering their lecture. Then when the term DESC or DESC is used it refers to description of
something. Rat convention refers to rational the short from of DEP dep refers to dependency. So
these are some of the conventions short forms and terms used to indicate things that are listed out
in this subsection.
(Refer Slide Time: 14:49)
Then in the third subsection of the introduction section the project scope is reported. Ideally you
should do that also so it says that this software is meant to be deployed in an IT enabled large
classroom environment wherein the lecture delivered by the instructor is via a device through
which both audio and video are transmitted. This software shall allow the instructor to
conveniently monitor the attention of their students in real time so in under the project scope
subsection you explain the need and objective for this project in brief.
(Refer Slide Time: 15:39)

Then we move to the second section that is overall description note that first section we already
covered first section on introduction where the 3 components that are shown are supposed to be
present in your document. So ideally you should list out those things and the extent to which you
provide content under each of these subsections is up to you so it can be larger smaller but
ideally it should be brief and to the point.

Now let us move to the overall description part it again is divided into several subsections one is
product perspective which lists out or which explains the perspective for this product. This
software will be a top-up on the already existing system for communication between the
instructor and the students inside a classroom. In which the slides of the lecture are delivered to
the students devices along with audio which they can listen to via earphones.

So it is talking about some existing system where something is already done and this system is
meant to be a top-up addition to that existing system. The slide transition are handled
automatically by the existing system the responsibility of the proposed system shall be to
monitor the attention of the students and ensure that they are not chatting, slacking or are
indulged in entertainment.

So it clearly tells us what is to be expected out of this system? It tells us that there is already an
existing system few things that our, that this current system is going to assume are already part of
that system. And based on that assumption that those things are already working in with the
existing system we are going ahead and building this system whose sole purpose is to add to the
existing system rather than proposing an entirely new system where everything is to be done.

So that is the product perspective in this way you are expected to write the perspective for your
product as well. Then comes, the product leverages the sensors such as gyroscope proximity
sensor, accelerometer in the devices used by the students which determine factors such as
orientation, distance from user shaking frequency which enable the system to determine the
attention of students and alert the instructor accordingly.

So it tells us that what the product assumes to be available and what it does? So it assumes that
some sensory values are already available from specific sensors that are already part of the setup.
And if those values are available then only it will work and it will produce something which is
the objective of this system namely determination of attention of students and generation of
alerts. So determination of attention and generation of alert are the objectives but it depends on
the availability of sensory values that is clearly stated in this section product function.

The application should also allow the instructor to see the summary of the data collected during
lecture which shall be helpful during feedback sessions and grading. So apart from attention
determination and alert generation one more functionality is to be expected out of this system
that is it should allow the instructor to get a summary of the data collected during lecture for
certain purposes. So that also is mentioned here so effectively this subsection reports what the
system assumes and what it expects to deliver?
(Refer Slide Time: 19:50)

The third section is also interesting subsection user classes and characteristics so from the point
of view of this system which is a classroom monitoring system we require 2 types of users. Users
are divided into 2 classes the instructors and the students the students interact with their mobile
devices having the sensors which are used to determine their attention by the software this can
then be viewed by the instructor in real time or at his or her laser.

So in this subsection what is being told is that? Who are; the end users? So there are 2 types of
end users students and instructors. Students will use the system on their mobile devices having
those sensors specified in the earlier subsection and the data generated will be processed and
produced as output and displayed to the instructor which will list out relevant details to him or
her. Now that, details can be viewed immediately in real time or it can be viewed by the
instructor at a later time so that is also specified here.

So everything every aspect related to the product is supposed to be briefly introduced in this
document. The fourth subsection under this second section is on operating environment so what
is the operating environment for the intended product it clearly states that. The environment is an
IT enabled large classroom where both the above user classes carry their devices the lecture
slides are shared from the instructor through his her device to the students along with slide
transitions and audio which can be heard by plugging earphones into their devices.

So the students can get the instructors voice through headphone or earphones due to the presence
of a large classroom it is not possible for the instructor to observe all students and therefore we
have the need for an app which measures the attention of the student. So it essentially tells us
about why we need it the smartphones or the devices that the students are carrying, with them as
well as the instructor is carrying with him or her. With their sensors take various parameters like
device orientation and others into account in determining the attention of the student.

So the operating environment is an IT enabled classroom environment students and teachers

carry their mobile devices smartphones with them. And they are connected to each other through
the system when they are using the system these sensors present in the devices capture the data
sensory data and that data is processed to produce the output required for the teacher to monitor
the students. So that is clearly stated what is the operating environment under this subsection.
(Refer Slide Time: 23:26)
The next subsection is design and implementation constraints if there are any constraints that are
likely to be faced by the teams for the above purpose of implementing the app we are forbidden
to use the camera for measuring the attention. So it is explicitly mentioned that camera cannot be
used to capture the students themselves the students might exploit the sensors used to portray
themselves as paying attention even when they are not.

So what it tells is that? The attention can be monitored by the teacher by simply utilizing the
smartphone cameras present in each student’s device however that is forbidden. That is not to be
used because the students can manipulate the camera feed and create a feed which look like they
are paying attention whereas in reality they are not. So this gives a false positive in cases when
the student uses a stand to maintain the orientation rendering the accelerometer and gyroscope
functions redundant.

Effectively what it tells is that if we use camera then it may not give us correct results so ideally
we should not use camera and that is explicitly mentioned under the subsection on constraints
under which the production should operate should be designed and implemented. The next sub
section is on assumptions and dependencies that are to be considered while building the product
so it clearly lists out what are the assumptions and what are the dependencies.

So we assume the presence of IT enabled large classroom with the availability of a system that
can display slides from the instructor to the students along with slide transition is available. This
is the assumption that all these things are available one assumption about the product is that it
will always be used on mobile phones that have enough performance. Means efficient
performance wise efficient; mobile phone that is mobile phones with good configurations.

Here by mobile phone it is specifically meant to be smartphones because only the smartphones
have those sensors that are assumed to be present in the environment. If the phone does; not have
enough hardware resources available for the application. For example the users might have
allocated them with other applications there may be scenarios where the application does not
work as intended or even at all.

Also we assume that devices have sophisticated sensors to meet our requirements of measuring
even minute checking to make the software precise. So in order to make the product we require
certain prior data and the assumptions clearly list out what we require? We require good quality
smartphones having all the requisite sensors. And we also require the existing system which does
several activities so that our product can work.
(Refer Slide Time: 26:58)

Then comes the third section external interface requirements so at several level these
requirements can be specified first is user interfaces. The software in the device should allow the
instructor to have an option note here to have an option to connect with the devices of all the
students present in the lecture classroom. The students must also have a complimentary option to
connect to the instructor's device thereafter the instructor should have options getting real-time
statistics of the attention span of the attendees.

The UI should be more focused on being organized and work oriented rather than having fancy
style and animation the interface should have rigorous error management. So these are some
broad level user interface requirements mentioned here of course as we have seen usability
requirements can be done at a lower level and we will later see how to specify those
requirements.
(Refer Slide Time: 28:02)

Next is hardware interfaces what are the hardware interfacing requirements that needs to be
specified which is done under this subsection. The student’s mobile devices should have all the
necessary sensors like the gyroscope, accelerometer, and proximity sensor with enough
specification to handle the task at hand. Also the devices should have high performance and
space to be able to run the software as a background demand service.

These are some of the hardware interfacing requirements that are specified here the instructor's
device should also have high enough performance to connect to all the users the network should
have enough capability to handle the traffic of the large classroom. Of course here everything has
been mentioned in a very broad level high enough. Now it is up to you in your specification
document you can go to more course level and specify exact requirements rather than these high
level requirements
But high level requirements are also fine at this stage. Next is a software interfaces list out the
software interfacing requirements the data collected by the devices carried by the students has to
be transported to the device being carried by the instructor. The medium of transport shall be
deduced by the design team it could be using Wi-Fi, Bluetooth or some other wired connection.
The instructor device shall receive the data from all the student devices so effectively instruct a
device get data from everything in a connected system.

The system calls required for the communication would have to be invoked for gathering sensor
data the driver modules of the student devices would have to be cooperated with. So it tells about
what we need to do if we want to build the software how to get the sensory data, where to send
it, how to send it at a software level. The final interfacing requirements are the communication
interface that is also specified the transfer rate between the devices should be sufficient enough
for the instructor to reflect upon the findings of the application.

Since the application will be exposed to a limited environment thus the encryption concerns are
not humongous. These are some of the things that are mentioned with respect to this particular
system now one thing of course you have to keep in mind while going through this example SRS
is that not necessarily everything will be required in your case. So you have to take a call on
which interfacing requirements you want to highlight and which are not very relevant.
(Refer Slide Time: 30:51)
Then come, the main content of functional requirement which can be considered to be the major
component of any SRS. Now as we mentioned there are 2 user classes accordingly 2 groups of
functional requirements can be specified one is for one class of users. So let us start with the first
user class that is the instructors for an instructor what are the functions that are to be supported
by the system.

So we have already learned about the hierarchy of functions so we will follow that hierarchy
here. Of course when we discuss the hierarchy we used one notation here the notation used is
slightly different I will just point those out while going through the functions. So first function is
start class session it should be supported by the device by the system. So we should have an id
for this function top level function which is given something like FR underscore INS underscore
1.

It should have an input specified course name and class group, it should have an output specified
related course page. Now one thing you should note here is although it is mentioned related
course page is opened this part of the statement is not required because it is talking about some
process rather than an output. So when you are specifying some output you should not mention
about the process that this is open this is closed.

Instead you should simply say what is opened here related course page that is good enough
whether it is opened or not open that need not be mentioned. So this type of action words is to be
avoided in specifying output as well as input. Then DESC remember in the convention we
mentioned DESC refers to description. So description of the function is start, the application with
the details of the current course and lecture that is the description.

Then rat this short form represents rational as listed in the convention section so one rational part
is also added although we did not discuss it in our earlier lectures. It is optional like description
so what is the rational for this function the instructor might be taking multiple courses and
lectures involving different students. So the application needs to adjust to the circumstances
accordingly so this is the rational for this function.

So ideally in any function description all these components should be present. Now under this
top level function we have second level 1.1 establish connection for instructor. Now this is
having id FR INS 1.1 again input course administration details, output connection request to all
students present and acknowledgement for the instructor. So here like I said you need not
mention that connection request sent to all students so sent is an action what you should avoid.

Acknowledgement sent to the instructor again that is sent is action what should avoid so simply
you mention this. Then DESC description says establish connection with the students present
currently in the class and rational is without connection between the devices information cannot
be communicated so we need this function.
(Refer Slide Time: 34:43)

The next function which is under this second level function established connection is real time
individual student attention statistics. So by the numbering we can understand where in hierarchy
it stands so it is ID is FR INS 1.1.1 input is provided sensor data from student devices output is
also provided details of the student’s attention at that instant. Description is an option for getting
insight on real-time attention activity of the students on an individual basis and rational is for
monitoring an individual student.

Then under the same level 1.1 we have another function real time overall class attention statistics
with an ID for INN 1.1.2. Input sensor data from student devices output summarized pictorial or
textual portrayal of the class’s attention details at that instant. And description an option for
getting insight on real time attention activity of the students on an aggregate basis and rational is
for monitoring the class as a whole. So here this specification follows the hierarchical notation
that we have learned earlier with slightly different conventions than the one we have seen earlier.
(Refer Slide Time: 36:15)

So under, 1.1 there is one more function 1.1.3 end class session with ID, input, current session
tokens; output exits the current course page and closes all impending connections. Now here lots
of action words are used exits closes so this type of output is to be avoided. So it has to be
refreshed avoiding the action word so this is a bad way of writing so in this document I will
show you the good things as well as the bad things.

So you should note that earlier things that we have discussed are good things but there are some
bad things also involved in this document like using action words in specification of input and
output for functions you should try to avoid them. Here description is given as close the currently
opened connections and the application. So in description you can use as many action words as
you want but in input and output you should be more careful.

Then under the top level hierarchy there is second function connection error notification this is
again for the instructor. Having an ID an input specified data flow across instructors and student
devices now having an output specified error message in case of interrupted or stop data flow. In
fact when you are specifying output you do not need to mention it in this details you can simply
say error message. For, whatever reason you do not need to mention here that can be explained in
description part.
As done here notify instructor in case of connection drop or a particular of a particular student
for whatever reason. And rational is in case of faulty connection or inefficient instruments
appropriate error message should be generated that is the rational for this function. So that is
about top level function which has 2 sub functions under it one of the sub functions has further
sub functions as we have seen.
(Refer Slide Time: 38:41)

Now second top level function is overall class attention this is again for the instructor it has ID,
input, output, description, rational, all specified output everywhere you can see there is this
mistake of using action words like displays it is not necessary. You can instead simply say
attention span details of entire class or attention span details of a class for a lecture. You need not
mention that displays attention class details attention level details all these things so display is an
action word we should avoid.

Whatever action word you need to use you can put it in the description part and rationalize helps
the instructor during feedback session and grading process. So under 2 we have 2.1 so that is one
sub function individual student monitor with ID, input, output and description it is not necessary
to provide rational at every function, sub function in the hierarchy 1 or 2 places is good enough
for the whole hierarchy.
And as we mentioned earlier also description if it looks repetitive you can avoid because that is
optional. So if top level function description is repeated in the lower level function descriptions
then it is better to avoid rather than repeating. Like here 2.2 here description is avoided so it is
under the top level function of overall class attention level 2 second function under it upper
division threshold filter.

One function designed here ID is mentioned, input is mentioned, output is mentioned so no

mention of description and rational. Again in output displays word is used which is not a good
thing avoid it. Another function under second function is 2.3 lower division threshold filters with
ID, input and output avoid action word.
(Refer Slide Time: 41:09)

Here again some rational is given rat because it is different from other rational given under this
same hierarchy. Then 2.4 sort students by attention span with ID, input, output, description, no
rational given. So rational description these are optional but ID name, input and output are
mandatory. So that is about instructor class for that class what; are the functions that are ideally
to be present in the proposed system?
(Refer Slide Time: 41:47)
Now let us move to the second class of users that is the student so here again like instructor class
we can have hierarchy open course page ID, input, output, description, rat. Now everywhere you
can see that in this document this mistake has been made that is use of action words in specifying
input and output like entering course name not required. You can simply specify as input course
name and lecture details.

No need to use the action word then output mentioned that related course page is opened not
required then simply say related course page so this you can avoid. Description whatever you
need to put in you can put in start the application with the details of the current course and
lecture and rational also is given here. Under one there are some subs functions 1.1 establish
connection like for instructor with ID, input, output, description, rational.
(Refer Slide Time: 43:06)
Then we have under this function, sub function, sub-sub functions 1.1.1 pause monitoring with
ID, input, output, description and rational everywhere you can see that this mistake of using
action words has been done. For example here in 1.1.1 in output you can see put the connection
on hold and provide appropriate feedback message this is not a good way of writing output.
Instead you can simply write feedback message this can be the output rather than this whole
process.

Because put the connection on this refers to; actually a process rather than a specific output.
Avoid mentioning action words which indicate process rather than output. Then we have
description and rational similarly we have under this function 1.2 that is second top level
function error notification student with ID, input and rational.
(Refer Slide Time: 44:26)
Then for user class 2 we have another top level function student attention span feedback having
ID, input, output, description, rational everything mentioned as before. So these are the functions
that constitute the functional hierarchy for the product so functional hierarchy is the main thing
in any SRS document. Later on we will see how usability requirements can be converted to
functions and added in functional hierarchy.
(Refer Slide Time: 44:26)

Apart from functional requirements and SRS document should also contain details about other
non-functional requirements. So here it includes performance requirements, requirements related
to performance of the product something is listed here. Like the search enabling the instructor to
view the summary of a student and give his analysis should be clear and well understandable.

The program must update the real time statistics at a fast enough pace so that the instructor can
have a clear view on the current attention of the class. The program must be able to handle the
information of the entire class a full attendance almost 90 students and also individually without
any glitch. So it mentions some size of the full class which is having 90 students but that is of
course variable.

Time to give the error message on losing a particular connection should be minimal so it should
be fast response. So these are some of the issues that are highlighted here related to performance
of the product.
(Refer Slide Time: 46:18)

Then there can be security requirements listed these are all non-functional requirements like the
students enter their authentication to enable access to connection to the slides. Since the
environment is local or limited to the classroom no security precaution or encryption of data is
necessary because it is to be executed over a small area network. Then software quality attributes
can be listed out. Code should be modular and well written so as to facilitate further addition and
implementation of new features and improvements.
The system should be robust enough not to fail during the class. These are high level
requirements non-functional requirements that are mentioned. So what we have learned here that
how to create an SRS documents what to be kept one thing you should keep in mind is whatever
sections and subsections are discussed in this example document need not be present in every
document.

So you have to choose depending on your application area what are the sections and subsections
to be kept. Most important component is of course the functional requirements; which lists out
the functions that are to be there or to be supported by the product to achieve the objectives. But
equally important is also non-functional requirements. Here in this example document only a few
broad non-functional requirements ideas are given but in reality it has to be a little bit more
detailed.

As we have discussed during our discussion on non-functional requirements different

requirements can be listed out. And usability; requirements which is a non-functional
requirements has to be listed out in more details than what is shown here. Also keep in mind that
some of the usability requirements can be actually represented as functional requirements which
we shall see through examples in later part of the course.

Another important thing that you should note is how to write functional requirements because
that is the core component of any SRS. In functional requirements ideally you should avoid using
action words in specifying input and output. Action words make those look like processes rather
than inputs and outputs so that to be strictly avoided. In functional requirement you should have
this level identifier name of the function, input, output specified without any action words and
optionally.

Description where you can use as many action words as you wish as well as the rational for this
function; why we are going for this function? So both description and rational are optional but it
is better to keep it in your document. So with that I would like to end this lecture so I hope you
got some idea of what is SRS? How it looks? What are to be considered while creating SRS? We
will see some more examples in subsequent lectures to understand in better way how to create
good SRS’S.
So I hope you have learned the idea of V through this example and enjoyed the lecture I am
looking forward to see you all in the next lecture. So we will meet again in the next lecture thank
you and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology, Guwahati

Module No # 03
Lecture No # 09
Case Study (Usability Requirement Gathering)

Hello and welcome to NPTEL MOOCS course on design and implementation of human
computer interfaces this is lecture number 8. In this lecture we are going to talk about a case
study on usability requirement gathering practices. So we are concerned about the design as well
as implementation of interactive systems.
(Refer Slide Time: 01:11)

In other words of human computer interfaces as we have seen in the earlier lectures human
computer interfaces or the interactive systems are distinct from other software systems. In
interactive systems primary concern is to make it quote unquote easy to use to laymen persons.
Now easy to use has a more formal notion which we are calling usability which is more
standardized way of saying the same thing easy to use.

So the objective in the design and implementation of human computer interfaces is to design and
usable system. And usable system design requires us to take users into account while designing
the system due to the necessity of taking user input into account lots of additional activities we
have to do. To systematically represent the whole design and development process we take
recourse to what is called software development life cycle?

Which is a stage wise representation of the entire development process? For interactive systems
we are discussing one such development life cycle having several stages and sub stages. So
before we start let us have a quick look at this, life cycles and its stages. So we have requirement
gathering analysis and specification stage we have design stage, we have prototyping stage, we
have early evaluation stage.

And these 3 stages design prototyping and early evaluation these together constitute a cycle. So
from design we go to prototype it then go to evaluate it based on evaluation result we refine our
design and this goes on till we come to a design where further refinements may not be required
or necessary. This cycle is generally called design prototype evaluate, cycle we can refer to this
cycle as design prototype evaluate cycle.

One thing to note here is the design refers to both design of the system and design of the
interface and interaction. So there are 2 distinct things that we wish to specify here or we wish to
refer to here. One is the interfaces and interactions which is the way in which a user views the
system. The other is the actual system which is the way a developer or programmer views the
system.

So; design refers to both types of views so from the users point of view design of the interface
and interaction and from the developers or programmers point of view design of the system. In
this cycle we refer to both the design first we will finalize design of the interfaces and
interactions and afterwards we finalize the system design. Now once the system design is
finalized it may be noted here that system design may not require prototyping but interface
design requires prototype and evaluation all these other sub stages in this cycle.

Now once we finalize the system design we go for implementing the design in the coding and
implementation stage. Then the code is tested for bugs so code testing is another major stage in
the interactive software development lifecycle. So after code testing we may get a system that is
bug free and executes properly. However we still do not know with code testing only whether the
end product is usable. Code testing will not tell us about the usability of the system it will only
tell us about the execution efficiency of the system.

So in order to know the usability we need to carry out another type of test which is called
empirical test also known as empirical study or empirical research. Here we get our system tested
with end users through a systematic and scientific process. Now result of this test may reveal
certain issues of the system vis-a-vis usability. So in order to take care of those issues we may
need to refine our design in other words we may have to go back to this cycle.

But ideally it should not be frequent because usability study or empirical study is a costly affair.
So if we need to frequently revise our design and go for empirical study then it will lead to cost
and time over run. So ideally we should aim to identify major number of problems within the
cycle itself initially in the initial stages and maybe once or twice we may enter this other cycle
this bigger cycle.

Once this usability issues are taken care of and we are ready with the final executable and usable
product we go for deployment and maintenance. That is ideally what should happen when we are
going to develop an interactive system. Now we are discussing different stages of the system so
we started with the requirement gathering stage. So earlier we discussed how to gather
requirements?

Here by requirements what we are referring to are 2 types of requirements one is usability
requirements other one is functional requirement so both the requirements are important.
(Refer Slide Time: 08:15)
Now we have learned about what are these different types of requirements and how to gather
those? In this lecture we are going to reinforce our learning with one case study of gathering
usability requirements for a practical system.
(Refer Slide Time: 08:34)

So what is our example system that we are going to discuss that is a calendar app which we have
mentioned in the earlier lectures. Now here we are specifying it in a little bit more details. So our
objective is to build a calendar app which is primarily meant to be used by students with the
objective of helping them in their various academic activities. So that is the broad purpose of the
app so user group is defined which are, students and purpose is to help them in their academic
activities.

So in this case study we will try to find out how gather usability requirements for this particular
app along with that we need to specify those requirements so we will also see in this case study
how to specify those requirements.
(Refer Slide Time: 09:35)

So usability requirement is one sort of non-functional requirement along with many other
non-functional requirements. However our main focus here is only usability requirements so we
are not going to discuss about other non-functional requirements for the app. Now in order to
gather these requirements we need to perform certain activities. So there are different ways to
gather these requirements as we have learned earlier we have seen earlier.

One of those which we have discussed in details in earlier lecture is contextual inquiry. So for
our example system let us assume that we are going to perform a contextual inquiry and based on
some hypothetical data let us see how we can get the usability requirements.
(Refer Slide Time: 10:31)
So before we proceed further let us quickly recap what we mean by contextual inquiry? So
contextual inquiry is a process which involves 5 steps now this process is observation based
primary objective is to observe the users in their work setting or context of use. To aid the
observations the observer may occasionally take recourse to interviews to get clarifications on
certain behavioral aspects of the user system interaction in the work context.

Now there are 5 stages to carry out the observations to make the observations more systematic
and less prone to errors first stage is plan. So before we start any contextual inquiry process we
should plan what we are going to do in the process preferably in the form of a script. Where we
note down the step by step sequence in which we are going to perform the inquiry so that is the
first planning stage.

Then initiate in this stage what we do we start the process but not the process of data collection
rather. We start the process in the form of communicating with the potential users for their time
and to explain to them the purpose so that they are less anxious and willing to let us observe their
behavior. After these 2 initial stages come, the actual data collection stage or the observation
stage. This is called the execution stage or execute stage here we actually observe and record our
observations.

If you may recollect these, observations can be performed in either of the 2 ways either in active
mode or in passive mode. In active mode the observer is physically present in the work setting
and observes in passive mode the observer is not present somehow the observations are recorded
and the recordings are viewed later for gathering requirements. After execute stage comes the
closed stage.

So in this stage some thank you notes are sent to the participants so that they are formally
notified about the closure of the process as well as they are given some incentives so that in
future if required their services can be availed. And finally whatever data we have collected
during observations are analyzed and results obtained in the reflect stage that is the final stage of
the contextual inquiry.
(Refer Slide Time: 13:41)

How do we analyze the data? So as again we have learned in one earlier lecture that we can
follow different methods but one method we have learnt in some details that is the affinity
diagram method. So in this method what we do again let us quickly recollect the procedure for
affinity diagram method.
(Refer Slide Time: 14:05)
So this method involves 5 steps first is generate idea that means after observations whatever you
observe from there take note or generate ideas. Then display those ideas in some manner it can
be as simple as noting down the observational behavior in some simple textual format on a sticky
pad or sticky notes and then paste or attach those notes on a simple white wall or white board for
later brainstorming.

Third stage is brainstorming stage where the ideas which are displayed needed to be sorted into
groups then once the groups are identified we need to create the group headers. And finally we
need to draw the finished or final affinity diagram where we have ideas sorted into groups with
headers and arranged in some sequence. So these are the 5 steps through which we can analyze
the observational data as we have discussed in one of the earlier lectures.
(Refer Slide Time: 15:47)
Now let us come back to our example problem so we are required to build a calendar app for use
by students to help them in their academic activities. So for this app we need to identify what is
the usability requirements for that let us assume that we have performed one contextual inquiry.
Now in this inquiry we have observed some students during their activity hours maybe inside
class or outside class in their group discussions or some such other settings we can observe them.

And let us assume that they have used paper based calendars as one mode of calendar then
desktop based calendar and also mobile calendars. And we have observed them using these
calendars only for academic activities not for any other activities because we are interested only
for such work settings. So this is actually very important that the work setting that you have in
mind while building the app should be replicated during this observation process.

So ideally if your work setting is one specific scenario and you are collecting data for another
scenario then that data may not be relevant for the particular work setting that you wish to have
while the system is used. So replicating work setting is very important in contextual inquiry
method. And here accordingly we can assume that we have observed students use calendars
either paper based or desktop based or mobile based during academic activities only.

So we have made some observations and noted down those observations may be on a sticky pad
and then we use the affinity diagram method to analyze those observations. So let us assume that
some hypothetical observations are made.
(Refer Slide Time: 18:19)

So then let us go through the let us go through the stages of the affinity diagram method. First we
will discuss the observations that we have noted on sticky pad one observation is something like
this that the calendar is used by all the users to set reminders. Be it paper based or desktop based
or mobile based everybody used it in some way to set reminders for various academic activities.
Suppose we have performed the study with 5 users so one observation that can be made is 4 out
of 5 users used the calendar to check upcoming deadlines.

So that is another use usage behavior that we have observed and noted down duly on a sticky
note. We can have yet more observations for example 3 out of 5 users used mobile calendar app
to check day and date and set reminder for assignment submission. So majority of the users who
participated in the contextual inquiry process actually made use of mobile apps because that
probably is convenient to use.

However contextual inquiry has nothing to do with the explanation of the behavior rather only
observing the behavior. So we will not go into the explanation of why this particular observation
has been made we will just observe and note down. So the observation is a majority of the users
preferred to use mobile apps for checking what day it is and what date it is and accordingly set
reminder for assignment submissions.
We probably could have made another observation which is all users use the calendars in
whatever form either paper-based desktop or mobile to check lecture schedule on a particular
day. So that is another observation that probably could have been made with calendars. A fifth
observation that possibly could have been made is that again a majority of the users 3 out of 5
used the calendar to check meeting schedule on a particular day.

So the academic activities also include several meetings maybe with peers with supervisors so on
and so forth. And it is observed that majority of the students or users checked meeting schedules
with calendars for a particular day. 4 out of 5 users used calendars to check date and then
checked timetable for that date so 4 out of 5 users wanted to know the timetable.

So they checked it from the calendar and checked timetables for that particular day to get
information about the classes on that day. Again 4 out of 5 users were found to use the calendar
whichever calendars they have access to check meeting dates. So that is another observation that
4 out of 5 users used calendars to check meeting dates. So these are some of the observations that
hypothetically can be made with a contextual inquiry method for our calendar app.

Now there are 7 observations or 7 notes which are generated and displayed. So from
observations so note here the terms idea generation and display idea so idea generation means
from observations generate those ideas that are just that have been discussed in the previous part
of the lecture. So converting observations to such short descriptions is what is being referred to
as generate ideas.

And then putting up those ideas in some form so that they are easy to visualize is what is being
referred to as display those ideas so here to display we probably can use one wall on which we
can paste those sticky notes.
(Refer Slide Time: 23:38)
The step 3 of the affinity diagram is grouping so in this step we are expected to perform
brainstorming and sort similar ideas into groups or cluster similar ideas into groups. So; let us
see with this seven notes or observational ideas whether we can form group or not. So 2
observations are one is the calendars were used by all the users to set reminders and we have also
observed that majority of the users 3 out of 5 used mobile apps to check day and date and set
reminder for assignment submission.

So everybody used calendar majority used mobile calendars so these are for setting reminders
these appear to be similar ideas so we can combine them into a group as shown here with the red
circle. The remaining observations can be combined together to form another group so you will
have only 2 groups because number of observations are less. What are the remaining
observations 4 out of 5 users used calendars to check upcoming deadlines.

4 out of 5 users used calendars to check date and then check timetable for the date 4 out of 5
used calendars to check meeting dates 3 out of 5 used calendars to check meeting schedule on a
particular day. All users used calendars to check lecture schedule on a particular day again
apparently all these seems to be pointing towards similar concepts so we can group them
together so total seven observations can be divided into 2 groups, groups of observations.
(Refer Slide Time: 25:50)
The next stage is assigning some headers which convey the broad message in a group of
observations. So we have these 2 observations one is all users used calendars to set reminders
and 3 out of 5 users used mobile apps to set reminders these 2 we already grouped together now
let us try to assign a header to this group. So broadly what these notes or the observations that we
have noted refers to broadly they refer to the activity of setting reminders or reminder setting
activity.

So we can actually assign this particular header to this group the header can be reminder setting
under which these 2 observations will fall.
(Refer Slide Time: 26:49)
Similarly the remaining 5 observations also convey some message what is that message so what
are those observations. One is 4 out of 5 use the calendars to check upcoming deadlines, 4 out of
5 use the calendars to check date and then check timetable for that date. 4 out of 5 used calendar
to check meeting dates, 3 out of 5 used the calendars to check meeting schedule on a particular
day and all users use the calendars to check lecture schedule on a particular day.

So these, again seems to be referring to a broader concept that is scheduling of academic work or
work scheduling. So accordingly we can assign this group name to these groups group of 5 notes.
(Refer Slide Time: 27:46)

Now they can be different ways to perform the grouping of course what we have just discussed is
one way. Another way can be breaking those 5 observational notes into 2 groups rather than
having a single group. One group may refer to the broader concept of overall scheduling of
activities under which these 2 observations fall. 4 out of 5 users used calendars to check
upcoming deadline, 4 out of 5 users use the calendar to check meeting dates.

So; these 2 can be grouped together into a broader group which can be given a header like
overall scheduling. Then the remaining 3 that is 4 out of 5 users use the calendar whichever
calendars they have access to. To check date and time table for that date 3 out of 5 used calendars
to check meeting schedule on a particular day and all used the calendars to check lecture
schedule on a particular day.
These 3 may be grouped together and can be given a heading such as day wise scheduling so one
is overall scheduling one is device scheduling. So we have both the options so either we can
group all the 5 observations together and have a single heading or we can split them further
create multiple groups out of those observations. Obviously the latter grouping is better because
here we can get a better cohesion among the notes.

Whereas in the previous case, when we club together all the 5 observations the heading does not
reflect everything that these observations contain.
(Refer Slide Time: 30:01)

The last stage in the affinity diagram method is very simple stage that is we need to display the
final diagram affinity diagram. So we have one group, group header is reminder setting and there
are 2 group members which are notes pertaining to observations the 2 notes. Then we have
another group overall scheduling where again we have 2 notes pertaining to observations under
this group.

We can have a third group day wise scheduling where we have 3 observational notes one, 2, and
3. So this is how we can create and display an affinity diagram at the end of brainstorming
session. So that is expected to give you some idea of what you need to do to gather usability
requirements.
(Refer Slide Time: 31:21)
However with respect to this particular example we should keep in mind few things which are
applicable whenever you are also going through the similar mechanism. First of all whatever
observations we made are not universal truths that we should always keep in mind. The
observations are for all types of calendars used in the study if any calendar type is left out then
these observations do not apply to them.

Same observations we can group in different ways. We have already seen how to do that in one
grouping we have 5 observations grouped together in another grouping scheme we have 2 groups
which we have formed out of the 5 observations. So that is those are some of the things that we
should keep in mind that whenever we are observing something we should only claim the
validity of the observations with respect to the specific work setting.

And we should not claim that these observations hold true for any work setting. And secondly
grouping is very important because once we group them then we should find out a header that
aptly describe the nature of the group. Now the more precise the groups are the easier it is to find
out a header. So accordingly our grouping activity needs to be very carefully thought out and we
should keep always in mind that there is no unique way of grouping.

So whatever grouping scheme we think of there can always be alternative schemes. So we should
always keep our thinking open and try to come up with as specific and precise grouping as
possible so that we are able to assign suitable group headers. Now we have created this diagram
so that is the first stage that we have collected usability requirements remember that usability
requirements are non-functional requirements.

So this affinity diagram method gave us some way to indicate the requirements in the form of
groups and group headers. Next is what to do with the grouping so that we will cover in the next
lecture. So that is all for today and in the next lecture we will learn about what to do with the
output of the affinity diagram method. And how to specify the requirements, so that they can be
converted easily to implementable ideas that is all for this lecture. Hope you have learned and
enjoyed the learning looking forward to see you in the next lecture thank you and goodbye you.
 Design & Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Module No # 02
Lecture No # 10
Case Study (Other Requirement Gathering)

Hello and welcome to NPTEL MOOCS course on design and implementation of human
computer interfaces we are going to continue with the case study in this lecture number 9. So we
started the case study in the previous lecture on an application development and in this lecture
we are going to continue with the case study. So before we go further we will first have a look at
where we are in this course.

So we started discussion on interactive software development life cycle. As repeatedly we have

discussed there are many stages which form the life cycle. These stages are performed in a
particular sequence and sometimes the stages form a loop.
(Refer Slide Time: 01:55)

So if you may recollect the stages first one is feasibility study which anyway we are not
focusing, on second is requirement gathering analysis and specification, third, is basically a set
of sub stages performed in a loop manner. So the sub stages are design sub stage, prototyping sub
stage, and quick evaluation of prototyping that is another sub stage. So together they form a
cycle which we are calling the design prototype evaluates cycle.

So through this cycle we do 2 things one is we design the interface as well as interaction and also
we design the system. Now once the system is designed then we go to the coding and
implementation stages this is followed by the testing stage where we test the code or the
program. Another testing stage follows which is empirical user testing or usability testing
through this testing we get to know usability of the end product.

And occasionally it may lead to returning back to this cycle design prototype evaluation cycle if
we find some problems in the usability testing phase but that is typically very infrequent. And
once we are certain about the efficacy of the code as well as usability of the product we go for
the next test that is that is deployment and maintenance. So among these stages we are currently
covering the requirement, gathering, analysis and specification stage.

We have already learned what we mean by requirement gathering analysis and specification. To
recap so there are 2 things involved one is requirement for whom and then how to specify those
requirements? First question is for whom we are collecting the requirement? In typical software
development process requirements can be obtained through interviews with clients or customers
as well as based on experience of the designers.

However in this case along with requirements provided by the clients we also need to know the
requirements of the actual end users. So here we are distinguishing between the clients and the
end users. End users are layman users who need not have any technical expertise but they just
want to use the system for achieving certain goals. So when we said requirement gathering so we
focused on these 2 aspects.

First of all to gather requirements from end users which is likely to lead to usable systems these
requirements we are referring to as usability requirements. To gather those usability requirements
what we did we have gone through one particular method called contextual inquiry method. So if
we follow this approach and implement it then we are likely to find out some requirements that
lead to better usability.
Other thing is so usability requirements are nonfunctional requirements from the point of view of
a system developer there is another category of requirements which typically comes through
interaction with clients as well as through prior experience of the designer.

Now these are called functional requirements where we actually get to know the requirements
and get to specify those requirements in the form of functions with clearly defined input, output
and some optional description of the functions. We have briefly looked at what these functions
are how they can be specified and what they refer to in the context of a system development.
(Refer Slide Time: 06:48)

Now let us come back to our case study so we are currently discussing on a case study pertaining
to the development of a calendar application or app. Now this application is primarily meant to
be developed for students who are expected to use it for academic purpose. So our user group is
fixed students more specifically college going students or students enrolled for higher studies.
And the work context is also fixed that is academic environments which include classrooms
which includes PR discussion groups and so on.

And if these are specified then what we are discussing is? How to find out the requirements both
non-functional and functional requirements? So in the previous lecture we have discussed how to
find out the usability requirements through contextual inquiry. In this lecture we will try to see
how to find out functional requirements which can be specified in the form of functions.
(Refer Slide Time: 08:20)
So calendar app is our example application development scenario and as I said this meant for
students primarily students enrolled for higher studies in colleges or universities and the app is
meant to help them in their various academic activities. So their work setting is also specified
given this specifications let us try to find out what are the functional requirements for this
particular application?
(Refer Slide Time: 09: 02)

Now before we start discussion on functional requirement let us quickly review the basic ideas.
So when we are talking of functional requirements essentially we are trying to find out functions
with specific input, output and description. Now these functions are not to be specified in details
instead we will assume that the functions are black boxes whatever input is given somehow it is
processed and generates the desired output.

So we will assume that that output is generated the function is designed in such a way rather than
focusing on how to design the function so that the output is generated from the input. So this
black box assumption of function is what is called abstract way of looking at the function or
abstraction. So this abstraction is very important we think of the functions in a very abstract way.

Second thing is decomposition and hierarchy so when we are talking of functions we should not
think of complex functions instead we try to divide functions into sub functions up to the level
wherever we feel it necessary. And we should strive to create a hierarchy of such functions and
sub functions. As we have seen in one of the earlier lectures that hierarchy actually makes things
easier to understand and implement in subsequent stages.

So decomposition of a function into sub functions and creating a hierarchy is very much
desirable along with the way to conceive the functions or the abstractions. So both are important
and should be kept in mind while we are going to find out functional requirements.
(Refer Slide Time: 11:01)

Now let us see what can be the functional requirements for this particular app. So we will here
rely on our intuition although we may think of this intuition as coming from interview with
clients or customers who have told us to build the system. It may also come from the past
experience of the developer or the development team. So whatever be the case we can still
identify few functions for this particular first of all the app should display dates in specific
manner.

So; first requirement is how to display the dates in the calendar app which is suitable for
specified user group in specified work setting. Now there are many possibilities in which we can
display these dates. Our objective is to find out one of those possibilities and then specify that
particular possibility.
(Refer Slide Time: 12:18)

So we will see how it can be done next obvious requirement is support for a student’s academic
activities. Now this may include setting reminders for lectures, setting reminder for exams,
setting other academic event reminders. Such as peer meetings, talk’s seminars so on and so forth
now here the term event should be noted carefully. In subsequent part of this lecture I am going
to use the term event to actually indicate a host of things including lectures exams meetings
talks.

So everything will be termed as event without any further disambiguation and that is good
enough for our purpose.
(Refer Slide Time: 13:16)
Now these are some obvious requirements there may be some other requirements or some
additional functionalities. Synchronization with email may be one such functionality so in this
functionality what is required is synchronize with email accounts of the user. So that if there is
any extrinsic event created with the e-mail account then it is automatically reflected on the
calendar with specified date and time.

So even if you are not explicitly using the calendar but saved some specific events with your
email then the app should be able to fetch that information from account and then display it on
the calendar. There may be another cosmetic function that is set or reset the application
background for aesthetic purpose. So user may be given the freedom to set or reset the
background so that is another requirement that we can think of.

So once the requirements are identified our next task is to specify them. Now for specification
earlier we have seen that we can use a notation for specification and the resulting document that
we get is called SRS or software requirement specification document.
(Refer Slide Time: 14:56)
So the notation involves creation of function name with description and clearly specifying the
input and output of the functions. So for each function we need to do these things clearly
specifies input, output as also provides some name and description. So; for the functions that we
have identified for the calendar app. Let us see how we can create the SRS document so first we
will focus on how to specify the functions that we have identified.
(Refer Slide Time: 15:37)

So from this specification we will get the SRS document for the calendar app now let us try to
see how it is or how it can be done?
(Refer Slide Time: 15: 48)
So we will first have a look at requirements earlier we have discussed it informally let us now
formally discuss the requirements. Now for the requirement for a user to view dates with events
if there are any such events for the specific date. Then we can have further requirements like
requirement to view months, for a year requirement, to view days for a month and requirement to
view event listings for days for each day or a special chosen day what are the events that are
listed against it.

We may also need to jump to any date from the current date with events listed for that day so this
may be one additional feature or function that should be available with our calendar app.
(Refer Slide Time: 16:59)
So accordingly we can create a functional hierarchy for all these requirements. So at the top level
of the hierarchy we have display calendar function which is the top level function then under it
comes sub function display months, display days with events and specific date view that is the
last requirement jumping to any date. So if we jump how to display that particular date note here
the abstraction.

So we still have not discussed anything on how to implement these functions rather we are only
focusing on what are the functions and how they can be organized in the form of a hierarchy.
(Refer Slide Time: 17:54)

Now let us see how we can specify it? So since display calendar is the top level function. So we
give it a name display calendar along with this label showing the level of the hierarchy. And for
this top level function we provide an input that is year month or date as input and there is an
output which is specified which is corresponding months days or lists of events for a day. So if
we are inputting on then the output will be the months of the year.

If the input is month then the output then the output will be days of the month if the input is a
day then the output will be the list of events for that day. There can be a description also but as I
said earlier this can be optional but ideally it should be there to clarify the purpose of the
functions. For example in this case we can have a description like in this function the user can
view months of a specified year or days of a specified month.
The user can also view the events deadlines in a month or days of a month or on a specific day.
So this is the purpose of the function why we are designing it to serve this purpose so description
gives us that idea of the purpose. So here we have all these components name, input, output and
description and note that name is having a label this label is representing the level of the
hierarchy.
(Refer Slide Time: 20:06)

Now below the top level function there are 3 sub functions that we have mentioned in the
hierarchy. First sub function is display month so again here we have one name with label which
indicates the level of the hierarchy. Since this comes under display calendar function so we are
giving it a level 1.1 that means under 1 this is the first sub function. So in this case the input is
year, the output is months of the year and description is in this function the user can view months
of a specified year that is the description so it is as simple as that.
(Refer Slide Time: 21:18)
Then we will move to the next sub function that is display days with events. Since; it is the
second sub function as per our hierarchical display so we are giving it a level 1.2. Now in this
case input is month and output is days of the month along with day wise event lists if there are
any such events. Description in this function the user can view the days of a specified month for
each day the associated event list is also displayed if there is any such event so this is our second
sub function in the hierarchy.
(Refer Slide Time: 22:11)

Now there is third sub function accordingly we have given it a level 1.3 and the name of the sub
function is specific date view as usual. So under this sub function we will have input output and
description. Let us see what is the input? What is the output? And what is the description for this
sub function? Input is date, output is events and description is in this function the user can view
the events for a specific date.

So if there is no event then it will not show anything if there are events then the list of events will
be shown. So that was about one requirement let us move to the next requirement for event
reminder setting.
(Refer Slide Time: 23:12)

So for a user to set reminders for academic events day wise what we need? We need to create
device events, we need to edit device events and we need to delete device events.
(Refer Slide Time: 23:45)
So these 3 sub functions should be good enough to represent this particular requirement of
setting reminders for academic events. So let us see how they can be arranged in the form of a
hierarchy so that is quite straight forward. So top level we have set reminders as the top level
function then below it sub functions come first is create reminders, then edit reminders and then
delete reminders. So this hierarchy looks similar to the previous hierarchy that we have already
covered.
(Refer Slide Time: 24:45)

Now let us create the corresponding SRS or specify these functions in the form of textual
description as we have seen earlier. First is the top level function so since it is another top level
function so we have given it the level R 2 the previous top level function was R 1 and the name
is set reminders. Now as per requirement so we have to provide the input which in this case is
date and event details with time.

And we need to specify the output which is reminder for the event at the specified time on the
specific date. Finally there is this description which says that in this function the user can create,
edit, delete reminders for specific academic events on specific dates and times. So this top level
function talks about all the three sub functions create, edit and delete and then under the sub
functions will specify which of these activities are applicable.
(Refer Slide Time: 26:09)

So as per the hierarchy we have set create reminder as the first sub function so accordingly we
have given it a level 2.1. 2 because it comes under the second top level function and 0.1 or 2.1
because it is the first sub function of the second top level function. Then there is this input which
is date event name and time together constitute the input output is reminder for specific event.
And description is in this function the user can associate a specific date and time with a specific
academic event this is the description for this sub function.
(Refer Slide Time: 27:09)
The second sub function under top level function is edit reminder so we have given it a label
R2.2. In this we have input as date and reminder output as date with revised reminder and
description as in this function the user can modify specific reminders such as time or event name
for specific dates. So this is the second sub function under the second top level function.
(Refer Slide Time: 27:53)

The third sub function is delete reminder so we have given it a level R2.3 for the same reason
that we have mentioned earlier. Here input is specific reminder, output is date without the
specific reminder and description says in this function the user can remove specific reminders
associated with specific dates. So that is the description for this third sub function of the second
top level function.
(Refer Slide Time: 28:43)

We also mentioned some other functions for example set the background user can set the
background to make it look better quote unquote better as per his or her aesthetic judgment. So in
order to have this function we need to be able to add background and we need to be able to reset
background both are requirements for setting background task.
(Refer Slide Time: 29:20)
So accordingly we can create yet another hierarchy of tasks or functions and sub functions. So
top level function is set background and under this comes set theme and reset theme so these 2
can be considered to be 2 sub functions for the top level function set background. So let us
quickly have a look at how to specify these functions and sub functions using the SRS notation?
(Refer Slide Time: 30:11)

So top level function is set background name given is set background and label is R3 because
this is the third top level function we are discussing. Its input is image or set of image output is
tab background with choose an image. So ideally its input should be one image and output
should be the app background with chosen image so the image is the background. We can write
as its description text like in this function the user can set or reset app background. So both the
activities can be written in the description of the top level function.
(Refer Slide Time: 31:16)
Then we will specify the lower level of the hierarchy the first sub function that is set theme so
we are giving it a label 3.1 because it is the first sub function of the third top level function. Now
here input is theme image output is app background with choose an image and we can have a
description as in this function the user can set app background. So this can be a simple
description of the function.
(Refer Slide Time: 31:50)

Then for the second sub function we can have a label R3.2 and the name as reset theme it can
have an input again as a theme image in the form of a theme image and output will be the
background with the chosen image. So in both the cases input output is similar in nature only the
content varies description is also similar in this function the user can reset app background so we
can have similar way to specify input, output and description for this two sub function under the
top level function.
(Refer Slide Time: 32:42)

Setting background is one requirement then we can have one more requirement which we
discussed earlier that is synchronize with other email accounts. So that if something is listed and
linked to this account then it automatically comes to the calendar display. In order to achieve that
we have further requirements one is to add account to the application second one is to delete
account from the application. So I may need to remove the synchronized account so some
facilities should be provided for that also.
(Refer Slide Time: 33:23)
So we can create in a very simple manner hierarchy so top level function is synchronized under
this comes 2 sub functions one is attach account and the second is remove account. So the
hierarchy can be created in a similar manner in which we have created the earlier hierarchy and
once this is created we go for creation of the specification document or the SRS part for these
functions and sub functions.
(Refer Slide Time: 34:13)

So how the SRS should look for this top level as well as the sub functions for the top level
function we can give it a label R4 because this is the fourth top level function and the name
remains the same synchronize. Then we have input as details of account to synchronize with
output as synchronized reminders. And description in this function the user can synchronize the
calendar with his or her respective email ids.

So that any extrinsic event meeting created with the email account is also reflected on the
calendar with date and time. Slightly longer description however it conveys the purpose of the
function. Now again take a pause and have a look at what we are doing just for pointing that out
again we are specifying a function. But nowhere we are talking about what this function should
be doing only we are giving it a name so that is abstraction and a purpose.

That is again enforcing the abstraction idea then we are specifying input and output now while
specifying we are not specifying the exact nature of the input that is also important. Again input
and output is also specified in an abstract and flexible manner like here details of account is an
input. Now how to provide that detail should it be a textual string should it be an alphanumeric
string should it be uni-code compliant string should it be in some other format.

These details we are not providing and we are not interested also because those are
implementation details so those are not part of this stage of requirement specification. That is
very important for you to keep in mind that in requirement specification we do not bother about
implementation details such as in which format to specify and how to process the information?
So neither we are interested in finding out the algorithm for this function to implement nor, we
are interested in specifying the exact input and output format.

Rather we will keep it as abstract and flexible as possible so that later on designer can make a
choice depending on availability of platforms, resources, manpower and other things. So
synchronized reminders, is output but we are not specifying what it means exactly to be having
an output called synchronized reminders. So it simply states that the reminders are now
synchronized with the display and they are now visible on the display.

But what that exactly means and how that is done is not what we are specifying here rather only
the, what should be done what is expected?
(Refer Slide Time: 37:29)
Now under the top level function there are 2 sub functions that we have seen one is attach
account. So accordingly we have given it a level 4.1 because this is the first sub function and a
name attached account in this the input is details of account or maybe more than one accounts
that we need to synchronize with the app and the output is the synchronized reminders.

A description here can be simpler than top level function in this function the user can attach
email ids to the app for synchronization. This can be simple description of the purpose of the
function.
(Refer Slide Time: 38:25)
Then comes the other sub function that is remove account so the label given is 4.2 indicating that
it is the second sub function for the fourth top level function and the name is remove account. So
the input is details of accounts to be removed or unsynchronized and output is unsynchronized
reminder list. That means now the display should not contain events that is linked to the account
which is unsynchronized and the purpose again can be simply stated as in this function.

The user can remove synchronized accounts from the app so that events attached to that account
does not reflect on the display.
(Refer Slide Time: 39:25)

So then how the complete hierarchy looks like let us have a look so we have top level function as
calendar app that is the entire top level function. Under this we have one top level function
display calendar under which we have three sub functions display months, display days with
events and display date view specific date. Then we have set reminders as another top level
function under, which there are sub functions create reminder, edit reminder, delete reminder.

Third top level function is set background so under this top level function there are 2 sub
functions set theme and reset theme. And finally this fourth top level; function synchronize under
which we have attach account and remove account. So effectively what we can think of as the
SRS should contain R1 then R1.1, R1.2, R1.3, then R2, R2.1, R2.2, R2.3, then R3, R3.1, R3.2
and finally R4. Under which R4.1 and 2 now for each of these of course we have to specify like
R1 or R1.1 we have to specify the input output and description.
So once that is done this entire thing will constitute the SRS for the calendar app which will
specify the functional requirements for the SRS to re-emphasize the point. So these are only
considering the functional requirements we have not yet bothered about specifying the usability
requirements that we have discussed in the previous lecture. Now once we put in the textual
forms of the functional requirements that will constitute our whole SRS for the calendar.
(Refer Slide Time: 42:13)

So again here you should keep in mind and note in this lecture how we have represented the
functions in SRS namely kind of name given sort name 1 or 2 words. Then input specification,
output specification and description for functions at each level then the abstract nature of the way
we have identified the functions. So essentially our focus is what we need rather than how to
achieve the requirement how to do it?

So our objective is only to specify functions which we need rather than how to get what we need
or the algorithm for the functions so that is not required at this stage. And then hierarchical
organization of the functions so how the functions are organized in the form of a hierarchy? And
also the conventions that we used for naming the functions that we already mentioned earlier
labeling convention, names and naming convention.

So as I said we have not discussed anything about usability requirements in this particular lecture
here we concentrated more on how to specify the functional requirements? First of all how to
identify and how to specify? In the next lecture what we are going to do is to see how the
usability requirements that we have discussed in the previous lecture can be incorporated as part
of the SRS. So that we can implement it as functions and at the same time ensure that the system
is usable.
(Refer Slide Time: 44:16)

How to do that we will see in the next lecture. So with that we come to the end of this lecture
here we continued our discussion on the case study and we discussed specification of functional
requirements for the calendar app. In the next lecture we are going to expand the SRS document
by incorporating usability requirements as well. And how to do that because usability; is a
non-functional requirement how we can convert it to functional requirement.

And apart from such conversions is there any other way to make use of usability requirements?
Because usability requirements, is not necessarily convertible to functional requirements. So;
how to make use of the usability requirements? That we have identified through contextual
inquiry that also we are going to discuss along with how and if we can convert it to functional
requirements. That is all for this lecture thank you hope you have learned and looking forward to
meet you in the next lecture soon thank you and goodbye.
 Design & Implementation of Human - Computer Interfaces
Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute Technology - Guwahati

Module No # 03
Lecture No # 11
Case Study-Non-Functional Requirements of SRS

Hello and welcome to the NPTEL MOOCs course on design and implementation of human
computer interfaces lecture number 10. Here we are going to continue with our previous case
study on calendar application development. Before we begin we will again go through the basic
idea of the interactive system development life cycle for easier recollection and then we will
continue with the example.
(Refer Slide Time: 01:28)

So we are currently focusing on a particular stage of the overall interactive system development
life cycle which comprises many stages. What are those stages? Just to have a quick recap we
have the feasibility study stage, requirement gathering analysis and specification stage, design
stage, prototyping stage, early evaluation of the prototype stage, coding and implementation
stage, code testing stage, empirical study stage and finally deployment and maintenance stage.

So all together we have 9 stages that make this interactive system development life cycle. Now
as you can see among these stages some stages form cycles, which means they are generally
performed in a loop iteratively at many places we can find such iterations. For example in the
design prototype and evaluation stages create a cycle as shown here in this block. That means
that when we go for design then this design has is prototyped and quickly evaluated to find out
problems with the design and this process goes on iteratively Till we arrive at a design that no
longer has many issues.

Now, when we say it does not have many issues we essentially refer to the fact that the design is
now likely to be leading to a usable product another important thing that we should again keep in
mind is that when we are talking of the term design. We are actually referring to 2 types of
designs one is the design of the interface and interaction that is from the user’s point of view.
Another one is the design of the system which is from the systems point of view.

Now when we talk of the design prototyping evaluation cycle essentially, we are referring to the
design of the interfaces and interactions. In the case of the design of the system we may not
require prototyping and quick evaluation, however, there are other ways to evaluate system
designs quickly which are covered under the code testing stage. Similarly, there is another bigger
cycle that we can see from this design prototype.

Evaluate cycle to empirical study and back so this bigger cycle is likely to be infrequent.
Otherwise, it will lead to huge costs and resource requirements. So only once or twice may
happen there is even a smaller cycle between the design and requirement gathering. So if the
design is found to be having too many problems then we may like to have the requirement
gathering to refine the design so this smaller cycle may also be there.

Among these stages we are currently discussing the requirement gathering analysis and
specification stage so we have already covered the basic concepts and currently, we are focusing
on understanding these concepts in terms of one case study one example is system development,
which is a calendar application.
(Refer Slide Time: 05:30)
So in the requirement gathering stage, we learned what is the key requirement from the point of
view of an interactive system? So what we have learned is that the key requirement from the
point of view of an interactive system is the usability of the system now usability requirement is
applicable for interface and interaction design. It is not necessarily a requirement for system
design, so currently we are focusing on the interface and interaction design for which usability is
a key requirement.

Also, we have learned about how to find out functional requirements and specify it note here that
usability requirement comes under the non-functional requirement. Now there are other ways to
specify requirements these are functional requirements that can directly translate to features of a
system. So we have seen what are usability requirements? And we have also discussed how to
find them out through contextual inquiry?

In the case study, we have seen how to find out through contextual inquiry usability requirements
for the calendar application. Separately in another lecture, we have seen how to find out the
functional requirements for the calendar application? Now in this lecture, we are going to see
how these 2 requirements can be combined and a common specification of requirements can be
generated in other words.

Here we are going to talk about how to make use of the usability requirements? That we have
identified through the contextual inquiry method to generate functional requirements that can be
integrated into the software requirement specification document, which primarily consists of a
functional requirement specification.
(Refer Slide Time: 07:43)

So we will continue with the calendar application that we were covering in the earlier lectures to
recap so we are interested to build a calendar application. Now the application is meant for
students, primarily students enrolled in colleges and universities for higher studies, and the
application is meant to help them in their academic activities. So the user group, as well as the
user context, are specified with these statements.

Now earlier we have seen how to find out usability requirements for the calendar app from the
contextual inquiry which is one of the many methods available to identify usability requirements.
(Refer Slide Time: 08:34)
So we assumed that we performed a contextual inquiry to identify the usability requirements.
(Refer Slide Time: 08:41)

Just for a quick recap what is contextual inquiry? So it comprises it is a process that comprises 5
stages it starts with a planning stage where we plan for the overall inquiry process. Preferably in
the form of a script then initiate stage where we start the process by communicating with the
potential users from whom we will collect data as well as their higher authorities in the work
setting if any such authorities exist.

In the third stage now we go for actual data collection which means we observe the users and
take note of their behaviour, while they perform their tasks in the work setting. If you may
recollect contextual inquiry is primarily an observation of user behaviour in a work setting in
their natural work setting. And occasionally this observation can be augmented with
semi-structured interviews for clarification on certain observations.

So the third stage is the actual observation and data collection stage. In the fourth stage, we close
the observation process by sending preferably thank you notes to the participants and creating a
rapport, so that in the future their services can again be availed if such need arises. In the fifth
and final stage we go for analysis of the observed data. There are many analysis methods and we
specifically learned about one particular method namely the affinity diagram method.
(Refer Slide Time: 10:42)

Now in the affinity diagram method again there are 5 stages and through those stages, we can
analyze the data.
(Refer Slide Time: 10:52)
So what are those 5 steps or stages, first is generate idea from observation then display the ideas
on some place it may be a wall, may be some screen, it may be whiteboard anywhere. Now the
ideas can be displayed in the form 5 of sticky notes and then we need to perform brainstorming
in a team to sort those ideas into groups of similar ideas. In the fourth stage we have to assign
some group header to each group of similar ideas and finally we need to draw the finish diagram.

So these are the 5 steps or stages through which we can analyze the data that we have collected
during observations in a contextual inquiry process. Now as, we have mentioned in the earlier
lecture, where we discussed contextual inquiry for the case study.
(Refer Slide Time: 12:07)
We mentioned that we performed CI hypothetically with some students, where we assumed that
the students used a paper-based calendar, a computer-based calendar. Here by the term computer.
So, in the desktops Computers are referred to as calendars that are available on mobile phones
and they use the calendars only for academic activities.

So we ensured that the work setting remains the same and while they are using these calendars in
those methods so you observed their behaviour and noted down, whatever notes we needed to
take to record their behaviour. And to note down, we use sticky notes and then we performed
affinity diagram method to analyze the data where we created the affinity diagram from the
observations.
(Refer Slide Time: 13:18)
So we discussed in detail the final diagram and how we arrived at that diagram what
observations we made how we grouped them together and how we got to know the final
diagram? So we will skip those steps here and only reproduce the final affinity diagram that we
obtained after performing the method. So we managed to get a few groups one group contains 2
observations one is the calendars were found to be used by all the users to set reminders, and 3
out of 5 users were found to use mobile apps to check days and dates and set reminders for
assignment submission.

So these 2 observations that we have noted down were found to be related and we put them
together in a group with a group heading reminder setting. Similarly, we have made another
group of observations 2 observations where there 4 out of 5 users used the calendar systems.
Either physical or mobile or desktop based to check upcoming deadlines and again 4 out of 5
users use the calendars to check meeting dates.

So these 2 again are related and we put them together under a group with a group heading overall
scheduling. We have also created a third group of observations having 3 observations one is 4 out
of 5 users were found to use the calendars to check dates and then check the timetable for that
particular date. All were found to use the calendars to check lecture schedules on a particular day
and 3 out of 5 were found to use the calendar to check the meeting schedule on a particular day.
So in all the cases as you can see a particular day is a common link so accordingly, we group
them together these 3 observations and provided a group heading for day-wise scheduling. So at
the end of the affinity diagram method, we found 3 groups of observations with 3 headings
reminder setting, overall scheduling and device scheduling. So this is the output of the contextual
inquiry that we have performed for the calendar application development.
(Refer Slide Time: 16:22)

Now the question is what to do with this output? So we made some observations and created an
affinity diagram now how we are going to use this affinity diagram that is going to be useful for
the development of the system.
(Refer Slide Time: 16:43)
We can actually make use of these observations or rather we can actually make use of this output
of the process in either of the 2 ways. One is either we can come up with a set of design
guidelines or recommendations or principles to guide the overall design of the interface. So this
is one method one way of using the output the other way of using the output is to create
functional requirements.

So one is to create guidelines for design other one is to create functional requirements for system
development. Now when we say design guidelines we specifically refer to the design of the
interface rather than the system. So given the output that we have just seen for the calendar app
what kind of guidelines we can generate?
(Refer Slide Time: 17:50)

In fact we can frame more than one guideline from the output that we got at the end of the
process.
(Refer Slide Time: 18:00)
Let us concentrate on the first group of observation that is overall scheduling. Here we have seen
that 4 out of 5 users were found to have used the calendars to check upcoming deadlines as well
as meeting dates. From these observations we can make some guidelines one guideline can be
the app resultant app should support viewing of upcoming deadlines for assignment submission
for the current day and also for next 7 days this may be one guideline.

That is the app should have some support for a specific functionality which we can frame based
on the observation. Similarly based on the other observation we can frame another guideline that
is the app should support viewing of scheduled meetings for the current date. So in the group
there are 2 observations each observation can give us some idea about a particular guideline that
is going to be helpful in coming up with a product, that is likely to be usable.
(Refer Slide Time: 19:32)
Let us see the other group of observations the day-wise scheduling under this group there are 3
observations. Observation one 4 out of 5 users were found to use the calendar to check the date
and timetable for that date. Second observation all users were found to use the calendar to check
lecture schedule on a particular day. And the third observation is 3 out of 5 users were found to
have used the calendar to check meeting schedule on a particular day. So we have made 3
observations.

So let us see how from these observations we can again frame some guidelines? One guideline
which we can call guideline 3 can be the final product that should support viewing of the
timetable on any given day. Again this indicates what functionality the final product should have
rather than how to have that functionality. Similarly, another observation can lead us to frame
another guideline that is guideline number 4.

That is the calendar app or the product should support viewing of lecture schedules on any given
day. Again this comes directly from the observations that the users are likely to use these
functions quite frequently in their work setting which in turn is going to make the product usable.
(Refer Slide Time: 21:25)
So that is one way of making use of the output of the contextual inquiry process. That is the
framing of guidelines as we have seen we have framed 4 guidelines. These 4 guidelines can be
used to add functionalities to the final product or the calendar app which are likely to be used
frequently by the specified group of users that is the students in the specified work context that is
the academic settings.

And that in turn is likely to lead to more efficiency effectiveness and satisfaction of the end
product as per the standard definition of usability. Now there is as we have mentioned another
way of making use of the findings that is the addition of new functional requirements based on
the observations. So earlier we have seen that how to create the functional requirements that is
primarily by interviewing the clients or customers.

And based on that we can create a functional requirement and specify it using a specific notation.
The usability study also can lead us to identification of new functional requirements that we can
add to the other functions in the functional requirement hierarchy.
(Refer Slide Time: 23:11)
So in this case let us see what new functions we can add before that let us just quickly recap what
functional requirement hierarchy we have created for the calendar app? So there were 4 top-level
functions display calendar, set a reminder, set background, and synchronize. Under display
calendar we had display months display days, and specific date view under set reminders. We
have created reminders edit reminders and deleted reminders.

Under set background, we have set theme to reset theme and under synchronize, we have
attached the account remove account. So these are the functions that we have identified and the
hierarchy we have created along with the specification of the hierarchy.
(Refer Slide Time: 24:05)
Now based on the affinity diagram we can actually find out newer functions and add it to the
existing hierarchy. Let us see how we can do that? So based on the observations we can add a
top-level function view since it is a top-level function and the fifth function in the hierarchy, so
we are giving it a label R5. Now its input is any date and output is a specific view for that
particular date. Now the view map, the view may be related to the timetable view submission
deadlines view, or meeting list view.

And as we learned earlier so for this top-level function we need to add some description.
Although it is optional it is always preferable to add a description so in this case what we can do
is we can add a simple description like in this function, The user can check day wise time tables
of lectures or upcoming assignment submission deadlines or scheduled meeting lists that is the
overall purpose of this view function which is a top-level function. Now under view we can have
sub-functions depending on the purpose.
(Refer Slide Time: 25:33)

So one sub-function can be timetable viewed accordingly we have given it a level R5.1. Now its
input is the date and the output is the timetable for the day it can have a simple description like in
this function, the user can check the day-wise timetable of the lectures.
(Refer Slide Time: 26:03)
Similarly, we can have another sub-function deadline view the name is deadline view label is 5.2
because it is the second sub-function under the top level function view which itself is having a
level 5 because it is the fifth function in the hierarchy. Now again its input is date and output is
submission deadlines the description is quite straight forward. In this function the user can check
day-wise assignment submission deadlines that are the purpose of the sub-function.
(Refer Slide Time: 26:45)

There can be a third sub-function as well under the function view which is meeting schedule.
Accordingly, the level is 5.3 input is debt output is list of meetings scheduled on that day and
description again can be very simple in this function. The user can check the device meeting
schedule so what we have done? From the observations we identified is that this scheduling is
important and for that, the user needs to get the information to provide the information we can
add certain functional requirements to the functional hierarchy.

Now through these requirements, we are indicating to the design team that these are to be
provided as functions of the final product or as features of the final product which will be very
much beneficial to the end users and will lead to improved usability of the product. So we have
seen one addition of functional requirement top level addition that is a view along with its
input-output and description under view we have added 3 sub-functions for 3 activities. One is
viewing the deadlines meeting schedules and lecture schedules.
(Refer Slide Time: 28:22)

So now we can add it to the hierarchy. So we have already added these 4 top level functions
display calendar, set reminder set background and synchronize. Now a fifth top level function
along with its hierarchy we can add this is the views this is the fifth top-level function.
Accordingly, we have given it a level R 5 and then under it, we have time table view, deadline
view and meeting schedule view.

So accordingly these are labelled as 5.1, 2 to so here you can see how we made use of the
outcome of the contextual inquiry process which is in the form of an affinity diagram. To identify
and add a new hierarchy of functional requirements in the existing hierarchy, that is the second
way of using the outcome of the contextual inquiry process. The other way just to recollect is to
frame design guidelines for use in a later design stage.

Now here, of course, we have shown one example, only depending on the other observations also
we can add few more functions in the form of hierarchy and further, enhance the functional
hierarchy that we have just seen.
(Refer Slide Time: 30:19)

However will not provide any more details on those functions as well as the hierarchy and I
leave it for you as a take home exercise. So I would like to request all of you to go through the
observations and add more functions in the hierarchy to make it complete. So that is all for today
so what we have learned here is? We have gone through the final part of the case study to learn
about how to make use of the outcome of a contextual inquiry method.

To enhance the software requirement, specification documents by identifying and adding more
functions in the functional hierarchy. Now one thing you must keep in mind is that usability
requirements are generally called non-functional requirements. So it is not mandatory to be able
to convert such requirements into functional requirements however in many of the cases you will
find that that is possible for certain usability requirements.

And accordingly you should try to convert those usability requirements into functions. So that in
a later stage we find it easier to implement the overall system with improved usability but I
would like to re-emphasize the point that usability requirements are non-functional requirements,
so it is not mandatory to be able to convert those requirements into functional requirements. So
in a design situation if you find that you manage to find out some usability requirements but
unable to convert them to functional requirements you need not worry that is anyway part of the
overall specification process.

So for non-functional requirements we specify them separately then functional requirements for
which we follow a certain convention which we have discussed throughout the previous lectures.
So what matters most is? At the end you get a software requirement specification document
which includes both non-functional requirement as well as functional requirements. So if you are
unable to convert usability requirements into functional requirements then you can keep that
requirement as non-functional requirement in the SRS document, and have the functional
requirements specified as per the convention that we have seen.

With that I would like to end this lecture I hope you could understand the material and you will
be able to translate it into practice I also hope that you enjoyed the learning and I look forward to
see you all again in the next lecture that is all for this lecture thank you and goodbye.
 Design & Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Module No # 03
Lecture No # 12
Introduction to Interface Design

Hello and welcome to NPTEL MOOCS course on design and implementation of human
computer interfaces lecture number 11. In this lecture we are going to talk about the next stage in
the interactive system development life cycle namely the design stage. Before we begin we will
quickly recollect the life cycle stages that we are currently discussing.
(Refer Slide Time: 01:14)

So we have seen earlier one of the stages that is the requirement gathering analysis specification
stage. Apart from this stage there are many more stages which together constitute the interactive
system development life cycle. So we have feasibility study stage, then requirement gathering
stage, design stage, prototyping stage early evaluation of the prototype that is another stage.
Then coding and implementation stage, code testing stage, empirical study stage and finally
deployment and maintenance.

Now among these stages the relationships vary for example in the 3 stages design prototype and
early evaluation they are connected in the form of a cycle. So we first design then create a
prototype then evaluate the prototype based on the evaluation results we refine the design create
again another prototype based on the refined design again evaluate and this goes on in a cycle.
So this cycle we are calling as design prototype evaluate cycle.

The cycle stops when the design stabilizes that means no further problems are found in the
design after the evaluation of the prototypes. Now this design prototype evaluate cycle primarily
refers to the design of user interfaces apart from that the design stage also refers to the design of
the code or the program which implements the design. So both designs are referred to by this
design stage and in code testing we test the code for its ability to execute properly along
expected lines.

Whereas in empirical study we test usability of the end product by involving end users in the
evaluation of the whole product or software. So these are the stages and through these stages we
try to build one interactive system that is executable as well as usable. Among them we have
already discussed one stage that is the requirement gathering analysis and specification stage.
(Refer Slide Time: 04:04)

So in this stage what we have learned? We have about the idea of usability what is meant by the
term usability requirements? Also what are the other requirements from the point of view of the
system development? So the usability requirements are non-functional requirements and we have
also learnt functional requirements and learned how to create functional requirements from
usability requirements through one case study?
More specifically what we have learned are usability requirement gathering and one method. So
there are several methods for gathering usability requirements we have learned one particular
method that is contextual inquiry. Then we have learned the affinity diagram method which
works on the data collected through contextual inquiry to analyze the results of the gathering
exercise. So we learnt affinity diagram method for analysis of the requirements that we have
gathered during contextual inquiry.

Thirdly we have learned how to specify the requirements so we have learned about SRS or
software requirement specification document how to create it what are the conventions to be
used and so on which is required for specification of the requirements. So we covered the
requirement gathering analysis and specification stage by separately learning what you mean by
gathering what you mean by analysis and what we mean by specification?

Whatever we have learned in this stage we try to explain that in terms of one case study of an
application namely a calendar application. Primarily to be used by the student community who
are enrolled for higher studies in higher educational institutes including colleges and universities
and who are supposed to use it for academic purposes.
(Refer Slide Time: 06:30)

In this lecture we are going to talk about the next stage that is the design stage which is one of
the components in the design prototype evaluates cycle.
(Refer Slide Time: 06:42)

To recollect so we have covered this stage and now we are going to talk about the design stage
subsequently we will talk about the other stages namely prototype and early evaluation and how
the cycle is formed. So in this lecture we will get a general introduction to the idea of design in a
software development life cycle. So what we mean by design and what we should know and take
care of in the design process? So when we talk of design what are the primary concerns?
(Refer Slide Time: 07:21)

There are 2 major issues or broadly 2 issues that we should be aware of and we should try to
address in our design activities. What are those issues? The first most obvious issue is where to
start the process? Where to start so; essentially when we are asked to come up with a design we
should be very sure or we should be knowledgeable about the starting point.

Where to start the process otherwise it may lead us to nowhere and we may end up with a faulty
or incomplete design. The second major issue is once we have designed something the concern is
how to specify it how to represent it? So that later on in later stages when we go for
implementing the design or go for doing something else on the design we can communicate the
idea of design clearly to the other members of a development team.

So the second major issue is how to represent our design in other words which language to use to
represent the design. So there are these 2 major issues that we should be concerned about when
we are going to work on design. First one is where to start and second is how to represent both
are very important considering that the entire life cycle is a team effort. So; one output of one
stage should be passed on to the input of another stage which may be executed by a separate
group, separate person or separate members of the team.

So this input that the team gets which is the output of some previous stage should be clearly
understandable. So that the new member can start working on the idea without any problem
without requiring to, consult the member of the team which executed the previous stage that is
very important. And from that point of view we should keep in mind that communicating ideas
from one stage to another in a very clear and precise manner is very much important and part of
this overall exercise. So we should always be concerned about that issue how to represent and
where to start.
(Refer Slide Time: 10:07)
Let us now start with the first issue that is where to start where we should start the design
activity? Obviously when the term design is mentioned it implies that we have the freedom to
think in our own way. In other words we should have the freedom for creative thinking. So as a
designer we should be able to creatively think and come up with a design now that is one way of
looking at the issue.

Now creative thinking need not work in a vacuum so when we say we are trying to come up with
a design through creative thinking. Implicitly we may be relying on our intuition or our past
experience both may be aiding in our thinking process. So effectively when we are trying to
think in a creative manner we may be aided by the intuition which we may have and our past
experience or knowledge of the domain of the problem that actually influences our creative
thinking.
(Refer Slide Time: 11:26)
Now; that is a broad way of looking at things now let us come to a bit more specific issues. So
when we talk of UCD or user center design now here the design is not a single idea here design
actually encompasses 2 distinct concepts. One is interface design that means the user interface
that the user gets to see and interact with. Now interface design also includes design of the
interaction through with this interface.

That means essentially interface plus interaction design that is one aspect of the design and
second is the design of the system or code design. So we have these 2 concerns interface design
which includes interaction with the interface as well now this is primarily from the point of view
of the user. And code design which is primarily point of view of the system so both are important
for getting or for developing an executable and usable product so how to take care of these 2
concerns?

Let us first start with the idea of interface design to recollect when we talk of interface design
essentially what we are referring to? We are referring to the user interface. That means the
system interface through which the user gets to interact with the system. Now the term interface
implicitly contains the idea of interaction as well. So without interaction interface is not of much
use so when we say interface design we are actually referring to both designs of the interface as
well as the corresponding interaction.
So when we are concerned about design of the interface we should be very careful because our
primary concern here is usability and usability primarily depends on the design of the interface
and interaction.
(Refer Slide Time: 13:54)

So these 2 affects the usability of the product because these 2 are the portal through which user
gets to view the system perceive the system and achieve goals with the system. So here the main
concern is to come up with a design that increases usability of the product. Now let us come back
to the core issues of design where to start and how to specify?
(Refer Slide Time: 14:25)
So when we are talking of interface design where to start so we can start with creative thinking
as we have seen before. So this is actually a prime application of creativity. How the interface
should look like? How the interaction can be designed? How the interface elements should be
designed? How they should be placed? Creative thinking can aid us in making all these design
decisions.

And as we have noted earlier so this creativity can be added by experience so the designer may
have experience of designing similar products before. Now that knowledge that experience can
be used can be an influencing factor for coming up with a creative design idea. The creative
thinking can also be aided by our intuition but of course intuition again is a very complex
concept and intuition comes with knowledge with experience with wisdom.

So everything actually influences the way we tend to think we tend to create so the more
experienced we are it will be easier for us to come up with a creative design solution the less
experienced it will be difficult to come up with a creative solution. So there is no ready-made
rule to tell you how to come up with a creative solution it entirely depends on your experience
intuition and creativity.
(Refer Slide Time: 16:21)

However creative thinking is a specialized way of looking at things but there are methods that
are easier to understand and access rather than having exotic skills like creative thinking. What
we can do instead is? We can make use of some guidelines or thumb rules or checklists or
heuristics as starting point of design these can also aid in our creative thinking. So that is
something very important to note that there are guidelines framed to aid designers in better
design better interface design.

Similarly there are checklists created to aid designers ensure improved interface design there are
heuristics which have been developed to help a designer come up with a good design and there
are thumb rules. So; all of these terms actually refer to a set of guidelines or principles using
which we can create quote, unquote good design which is likely to be usable. Now why we say
that when we follow a guideline we can come up with a usable design because of the history of
these guidelines or checklists or heuristics or thumb rules whatever you call it.

These are developed based on a long history of application of such guidelines rules or checklists
on building usable products. So based on the knowledge gain these sets were continuously
revised updated so that at the end whatever they contain is proven to be useful for building
usable systems. Accordingly we can claim that whatever design we come up with based on these
guidelines or heuristics can lead to improved usability enhanced usability.

That is one way of looking at the issue of where to start so we can start either as a creative
thinker, creative designer or we can start with some set of guidelines which will aid us further in
our thinking process.
(Refer Slide Time: 19:21)
Now there are many guidelines which have been developed over time for various purposes.
(Refer Slide Time: 19:29)

Some guidelines are very generic in nature that means they patent to very broad aspects of a
design of a usable design and because they are very generic. So they are usually small in size that
means the number of guidelines is less in value maybe five to ten guidelines that constitute a set
of guidelines for design of a particular system. So these guidelines because they are generic
usually cover broad aspects of interactive systems at a rather high level again there are many
such guidelines.

For example the 8 golden rule are the 7 principles the first one 8 golden rules was proposed by
Ben Shneiderman, way back in 1986 the second one 7 principles was proposed by Donald
Norman in 1988. Now both these sets actually originated during the proliferation of graphical
user interfaces. You may be familiar with this term graphical user interfaces these are the
interfaces that contains windows, icons, menus and pointers or what we generally call wimp
interfaces.

Windows, icon, menus and pointers or wimp interfaces these were ubiquitous interfaces at one
time still they are very much around us. Whenever we interact with a computer desktop
computer in particular or laptop whatever interfaces we get to see are mostly wimp interfaces. So
these interfaces were developed way back in nineteen eighties at that time what we take for
granted nowadays was not so in at that time and the idea of usability was not that much
developed.

At that time these golden rules or principles were developed by the corresponding persons in the
case of golden rules it was Ben Shneiderman and in case of 7 principles it was Donald Norman.
So these were developed to help in building (())(22:21) that are going to be usable. So that was
the background of these guidelines and another thing that we should keep in mind is that these
guidelines did not appear suddenly out of nowhere.

So they were framed based on empirical data collected over a long period of time and after
analysis of that data some behavioral models were formed and out of those models these
guidelines emerged. So they were rooted in behavioral analysis of human users so whatever
guidelines are proposed if we follow them then we are likely to get systems that will help the
users use those systems now these are some generic examples of guidelines.
(Refer Slide Time: 23:30)

There are more detailed guidelines as well which are more specific and accordingly these are
large sets that mean each set of guidelines contains hundreds or maybe even thousands of
individual guidelines. Now these guidelines the detailed ones are intended to cover very minor
aspects of the design and most often they are specifically meant for specific products.
One example can be the human interface guidelines that was developed for the apple systems
this set of guidelines contained hundreds of individual guidelines which are primarily meant to
build products on apple platforms on apple OS. And primarily products that deal with GY’S on
apple platforms.
(Refer Slide Time: 24:36)

In subsequent lectures we are going to learn about the 2 guidelines that I mentioned earlier eight
golden rules of Shneiderman and Norma's 7 principles to get some idea on what we mean by the
guidelines in this case the generic guidelines.
(Refer Slide Time: 24:57)
So that is about where to start now the guidelines help us to start design but design of what. So
here we talked of 2 types of design one is interface design other one is code design. Now the
guidelines are helpful to get us a starting point for interface design the other aspect of the design
stage is the code design for which we need to take different approach so for code design let us
see what we can do?

To repeat when we reach the code design stage once, we complete the design prototype, evaluate
cycle and stabilize the design of the interface. So first we start with interface design we design
something prototype it, test it if some issues are found out then we refine the design again
prototype is test it. So this cycle goes on till we reach a design which is stabilized that means no
further issues are found in the design.

In that case we move to the next aspect of the design stage that is code design so now we move
to design of the system or code. Now code design is totally different than interface design.
(Refer Slide Time: 26:20)

In interface design primary concern was usability and the design guidelines were again based on
users behavioral characteristics and they were primarily meant to help us design usable products.
But those are not useful in code design where our primary focus is efficiency of the
implementation. Along with that our primary focus is to make the code manageable. That means
we come up with a design which other team members can understand and manage if required
modify also so that it can be implemented.
So the objectives changes and accordingly we should change our approach to address the main
concerns.
(Refer Slide Time: 27:11)

Now earlier in the requirement stage we saw that we need to create an SRS or software
requirement specification document as the end product of the stage. Code design actually is
based on the SRS that we create so we need to translate the functional requirement hierarchy to
the design of a system that can be implemented. So when we talk of code design there are 2
distinct phases are involved the first one is the preliminary phase or high level design phase.

And there is another one that is the detailed design phase also called module specification
document. So; any code design activity involves these 2 stages high level design and or
preliminary design and detailed design or module level specification document.
(Refer Slide Time: 28:24)
So in the high level design what we need to do we need to identify the modules? That means the
units which together constitute the overall system. Then define relationships between the
modules control relationships between the modules how the modules are linked to each other.
And also we need to define interfaces between modules how the modules talk to each other so
how they are connected and how they are able to talk to each other?
(Refer Slide Time: 29:12)

So all these things we need to consider in the preliminary design phase or high level design
phase in the detailed design phase. We turn our attention to the design of individual modules
particularly the data structures and algorithms to be used to implement individual modules. So
that is the second phase of the design activity code design activity that is detailed design phase.

So we started with 2 issues broader issues for any design activity one is where to start and how to
represent? Now earlier we saw that in interactive system design there are 2 types of design one is
interface design other one is code design. For interface design starting point can be creative
thinking or it can be use of standard guidelines. Another thing we should note here is that the
second issue that is how to represent the design? In case of interface design the representation is
done with prototypes.

So prototypes effectively give us a language to express the design we will learn more about
prototypes later. In case of code design our starting point is this phases, preliminary design phase
and detailed design phase in preliminary design phase we work with high level concepts namely
what are the modules broader modules? How they are connected? How they talk to each other?
And in detailed design phase our primary concerns are the data structures and algorithms to be
used to implement each module. Now let us shift our attention to what are the languages using
which we can specify our designs.
(Refer Slide Time: 31:12)

Now as briefly mentioned so when you talk of design language; we refer to specification of the
design. Like we have seen specification of requirements using SRS which is a convention in
other words we can call it a language. Similarly we need a language to specify our design and we
require different languages for interface and code design specifications.
(Refer Slide Time: 31:44)

Again as I just mentioned earlier to express interface and interaction design we do not do it using
natural language like English or Hindi or similar languages. Instead what we do is we make use
of prototypes we take records to prototypes. Prototypes are scaled models of the designs when
we create prototype we essentially express the design. So prototype gives us the language to
express our design so we can consider a prototype to be a language for expressing interface
design.

Now in a later lecture we will learn more about what are the different types of prototypes and
how to create those prototypes? Clearly we can see here that prototypes although we; are calling
it a language but they are not a very formal language as such it does not have alphabet or
anything. Rather we are using the term language here in a very loose manner whichever allows
us to express something we are calling it a language. And in that sense prototype can be
considered to be a language to express interface design.
(Refer Slide Time: 33:11)
How we can express the code design whatever we have designed through preliminary and
detailed design phases how we can express that. So what is the language we can use for
expressing system design or code design? We can actually take records to various ways so there
are different ways to specify a system design. Definitely we can make use of natural languages
although it will lead to ambiguity.

We can make use of semi-formal languages and finally we can go for formal languages with
clearly defined syntax and semantics which are mathematically defined. So each has its own pros
and cons if we are making use of natural language to express a system. Now that is very much
subjective. So when I create a description of the system in terms of a natural language I may be
using my literary skill to express it.

But later on when I pass on the message to somebody else when I pass on the design to
somebody else in my team the particular member may not be able to comprehend it or maybe
having lots of confusions because natural languages are inherently ambiguous. So natural
languages although can be technically used but are not suitable or preferable to express design
languages. This leaves us with 2 choices semi-formal languages and formal languages.

Formal languages are the best way to express any design however because it is a very rigorous
expression it requires mathematical background. And good skills in understanding the particular
notations and conventions and also understanding the logical deductions that follow from the
specifications. A middle ground can be found with a semi formal languages based specifications
which are natural language. Partly graphical language and rather informal way of expressing
things and easier to understand but at the same time it reduces ambiguity.
(Refer Slide Time: 35:53)

In this course we will focus more on this semi-formal language based specification of design
particularly system design. So we learn 2 such languages one is DFD or data flow diagram which
is a graphical language to express design in the form of in the form of drawings images. Second
one is also a partly graphical language where we can express design in the form of some
schematic diagrams this is called UML or unified modeling language.

First one is DFD or data flow diagrams as the name suggests it contains diagrams to express
design which makes it easier to understand and makes it easier to maintain as well. Second one is
UML or unified modeling language this is again partly graphical language of course in both the
languages natural language text is also used along with the graphical notations. So these 2
languages we will learn in subsequent part of this course.
(Refer Slide Time: 37:29)
So with that we come to the end of this particular lecture so here we got an overview of what we
mean by design? To recap we are now going to start our discussion on the design phase of the
life cycle now there are 2 types of designs are important one is interface designs other one is
code design. Code design is also referred to as system design so we will use the terms
interchangeably in subsequent lectures.

Now in both the cases what we should be aware of is what we should be concerned about are 2
issues one is where to start the design process and second one is how to specify the design? In
case of interface design starting point typically considered to be creative thinking aspects but we
can also start with the help of some standard guidelines. In case of code design we start at the
preliminary design phase and also complete the design in the detail design phase.

Now the specification languages differ for each type of design in case of interface design we can
consider prototypes to be a language quote, unquote language to specify the design. And in case
of system design we can consider different languages however we will focus on semi-formal
languages to specify the designs. 2 semi-formal languages will learn one is DFD or data flow
diagram and other one is UML or unified modeling languages.

In the next lecture we will start our discussion on the design guidelines these are the guidelines
that are useful to start design of interfaces. That is all for this lecture I hope you managed to learn
the concepts and enjoyed the content looking forward to see you all in the next lecture thank you
and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology, Guwahati

Module No # 03
Lecture No # 13
Schneiderman’s Golden Rules

Hello and welcome to the NPTEL MOOCs course on design and implementation of human
computer interfaces. We are going to start lecture number 12 on design guidelines. Before we
start let us quickly recap what we have learned so far so as the name of the lecture indicates, so
we are going to talk about guidelines for design. Design of what and where in the overall
interactive system development life cycle the design fits.

We have so far learned about the life cycle and the different stages of the life cycle. So, let us just
quickly recollect what are the stages? And where we are currently now?
(Refer Slide Time: 01:34)

So, if you may recollect, we have several stages in the interactive system development life cycle.
We start with the requirement gathering analysis and specification stage. Feasibility study
although it is shown as part of the life cycle actually is a stage where we decide whether to
proceed or not? Or if we proceed then whether; any modification in the plan is required or not so.
As such it is not directly involved in the development of the system.
So, we will treat it separately and in this course, we are not discussing in detail the feasibility
study stage. We started our discussion with requirement gathering analysis and specification,
which we considered the first stage in the interactive system development life cycle. After this,
we enter the design prototype evaluation cycle. Now, this cycle contains 3stages the design stage,
the prototyping stage, and the evaluation of the prototyping stage.

Now here, we mentioned that design involves 2 types of design the design of the interface and
interaction is a key component in any interactive system development and also the design of the
actual system or design of the code. So, when we are talking of the design prototype evaluation
lifecycle, we are primarily referring to the design of the interface and interaction rather than the
code design. For code design, we may not require this cycle.

So, in the interface and interaction design, we come up with a design, then prototype it. Because
we are dealing with user center design approach so, we need to take into account the user inputs
in as many stages as possible. So, to take into account user feedback, we create a prototype of
our design, then get it evaluated. If any issues are found, then we refine our design, recreate the
prototype, and get it evaluated again and this goes on in a cycle which we call the design
prototype to evaluate cycle.

So, once we reach a stable design that means a design, where not many significant or new issues
are found through prototyping and evaluation, then we stop the cycle there and enter the design
of the coding stage. Now, in the design of the code, we plan for the overall software system. So,
to speak and then we go to the next stage. The next stage is coding and implementation. That
means once we have a design of the system ready, we go to implement it by writing programs
that is the coding stage.

After we have implemented it, we need to test it. So, this is the code testing phase which comes
after the implementation stage. Now, in code testing of course there are several levels of testing
and several types of testing, which are related to the testing of the code. Note that in the
evaluation phase we talked about in the design evaluates prototype cycle here, it is related to the
evaluation of the design from the point of view of usability.
Now when we are talking of code testing, we are talking of evaluation of the code from the point
of view of execution ability. In other words, whether; the code can be executed efficiently and as
per the expectations. So, after code testing, we go for another round of usability testing now this
time for the whole system rather than a prototype, which we call empirical study or empirical
research.

Now here, what we do is test the usability of the system with respect to end users and if we find
some problems at this stage which is possible, then we may like to go back to the design stage
and traverse the other stages again. So, this can form another cycle although this should be a
minimal maximum of one or twice, more than that will affect the overall turnaround time as well
as the cost of the project.

So, once we are assured of the usability of the product as well as the execution ability of the
product we go for deployment and subsequently maintenance stage of the life cycle .So, this is
the summary of what we are talking about we have already discussed the requirement gathering
stage and currently we are discussing the design of the interface stage.
(Refer Slide Time: 06:50)

In earlier lectures, we got a general introduction to the problem of design. What are the issues
and how do we address those issues in the design of the interface? Now, there again we talked of
2 design problems here, one is interface and interaction design where usability is a prime concern
and code design or design of the system.
(Refer Slide Time: 07:25)

Now in this lecture, we are going to talk about the design of the interface where to start the
process that is going to be our primary concern in this lecture. In this regard we are going to
learn about design guidelines or guidelines for the design of interfaces and interactions so what
are the things that we should follow while going for a design?
(Refer Slide Time: 07:55)
When we are talking of design, if you may recollect 2 issues are of primary concept. One is
where to start and the second one is how to specify? The same applies to interface design where
we should start our design process? Now, if you are an experienced designer and also you have
sufficient experience in the design of similar systems, then you can rely on your experience
which again is influenced by your intuition and knowledge level, and skills to start the process.

Even if that is the case or if you do not possess such experience, then also we can start by taking
recourse to guidelines. So, guidelines provide a starting point in the design phase of the
development life cycle earlier we talked about several guidelines.
(Refer To Slide Time: 09:08)

So, there are different ways to look at the guidelines broadly there are 2 categories of guidelines.
(Refer Slide Time: 09:14)
Some are very generic in nature and since they are generic, they only refer to broader aspects of
the design, rather than going into the minor details of specific system design. And accordingly,
since they primarily refer to broader aspects of design which is generally true for any system
rather than specific systems. Generally, these are at a very high level and the number of such
guidelines is very less.

So, the overall set of guidelines is small we mentioned a couple of such guidelines such as the 8
golden, rules by Schneiderman proposed in 1986 and principles by Norman proposed in 1988.
(Refer Slide Time: 10:10)
In contrast to these generic guidelines, we can have specific guidelines also where the guidelines
are designed to build a specific type of system. So, the target is very specified and the guidelines
are very minute in nature. So, they deal with intricate details of the overall system design. For
example, human interface guidelines for the apple systems built for apple devices. So generally,
these guidelines are very large in number and the set size is big.

So in this lecture, we are going to talk about one of the 2 generic guidelines, that we have
mentioned earlier namely the 8 golden rules by Schneiderman’s guidelines for the design of
interfaces. In particular, these guidelines are applicable for the design of graphical user
interfaces.
(Refer Slide Time: 10:49)

So, these are called golden rules so there are 8 golden rules as I said, they are originally designed
for graphical user interfaces or GUIs. Now, the golden rules were proposed by Ben
Schneiderman way back in 1986. At that time, the idea of the personal computer was coming
into being and people were trying to develop graphical user interfaces for such computers.

So, it becomes popular and acceptable to the masses in that context, the golden rules were
designed. However, as it belongs to a generic set of guidelines so, they broadly refer to larger and
broader aspects of a design which makes them suitable partly or fully for other types of systems
and interfaces as well. That is the advantage of having a generic guideline set although, it does
not provide us with details of, what to do?
But it provides us, a very broad picture of what should be done, and since it provides a broad
picture. Such guidelines are applicable for systems or interfaces other than the ones for which
those were intended.
(Refer Slide Time: 12:50)

Now let us see what are these 8 guidelines or 8 golden rules. Rule number 1 the first rule first
golden rule says that we should strive for consistency. Now, there are 2 types of consistencies
from the point of view of this particular rule. One is internal consistency. Another one is external
or environmental consistency. So, what this guideline tells us or what this golden rule tells us is
that when we are trying to design an interface, we should strive for both internal as well as
external consistency.

Now, what does it mean? Internal consistency means that whatever symbols metaphors, icons,
texts, or tasks that we are designing for one part of the system should be consistently used in
other parts of the system. For example, suppose we are designing a GUI with multiple windows,
and to close windows, we are using a red circle with a cross inscribed inside it which is a typical
way of denoting the close button.

Now, for one window suppose we are using this red-filled circle with a cross and for another
window, we are using a green-filled circle with a cross. Now, both windows are part of the same
system. But, to close one window, we need to use the red circle with a cross, and to close another
window, we need to use a green circle. So, there is a lack of consistency. If we want to perform
the action of close, we should use consistent symbols or buttons or metaphors or icons to
perform this operation across all the interfaces in the same system.

That is what is referred to as internal consistency same thing should be used everywhere with the
same meaning. What is external consistency? Now, we may use some standards in our design.
However, in our day-to-day life, we get to see something, we experience something so whatever
we are defining for our system it ideally should not violate what we experience in our everyday
situations. If these, are 2 matches, then we have external consistency. If these 2 do not match,
then we do not have external consistency.

For example, we get to see traffic signals having 3 colours red to indicate stop, yellow to indicate
slow down, and green to indicate go ahead. Now, suppose in our interface, we want to indicate
stop or close and window. So ideally, we should use red colour to indicate this operation.
Because stop or close in the context of a traffic light, which we experience in our day-to-day life
is indicated by the red color.

So, in our system, if we are using red color, then we are consistent with our real-life experience.
Now, instead of red, if we use say green to indicate close or stop. Then, of course, that is
violating external consistency. So, you may note that we may maintain internal consistency but,
violate external consistency which is quite possible. However; ideally, for an interface to be
used, it is preferred that we follow both internal and external consistency which was rule one.
(Refer Slide Time: 17:24)
Now, let us talk about rule 2 this rule states that we should design for universal usability. Now,
universal usability is a term, to be noted it indicates that our design should cater to different
groups of users. Now, it should not be confused with the idea that the system that we design
should be used by everybody. Now, that is something that violates the definition of usability as
we have noted earlier.

Instead, what we are saying here is that? We should have a system, but for a specific group of
users, a specific interface should be used. It is not that everybody gets to see everything and gets
to use everything. Now, broadly we can categorize users as we have already seen in 3 groups
novice, intermittent, and expert. So, novice users are those who typically use the system for the
first time.

Intermittent users are those who occasionally use the system maybe in between there may be a
long gap, and expert users are those who use the system regularly, and frequently. Now, for each
category of users, we should have different features in the system. That is what is meant by
design for universal usability. So, our system should be usable for novice users, should be used
for intermittent users, and should be usable for expert users.

How by designing the features and functionalities provided in the system in a way. Such that,
each group is scattered and the corresponding features are only visible to that particular group.
All user groups should not be exposed to all features provided in the system. Then it affects
usability. An example can be the use of a text editor so, all of us have used text editors such as
ms-word or word pad.

Now, in such text editors suppose, I want to create a text and save it. How I can? Save so I can
use either of 2 ways. One is using a menu-based option. So, in the menu there is a file menu
typically under file there is a save option. So, I can select the file and the drop-down menu
appears and then I can select the save option, to save the text. Alternatively, what I can do is I
can use a combination of keys these are typically called hot keys.

For example, Ctrl +S is the most common hotkey combination used to save a file. So, I can either
be using a menu or I can either use the Ctrl +S. Combination of these 2 keys control key and S
key on the keyboard. Now, the menu-based option is typically good for novices and maybe also
intermittent whereas Ctrl +S this hotkey combination may be good for experts. So, the system
that we design should have facilities for both menu-based saving and Ctrl +S or hotkey-based
saving, and the user depending on the category can use the specific option to perform the task.
Then the interface will be usable to all the groups.
(Refer Slide Time: 21:10)

Now let us come to rule number 3 it talks about the fact that when we are designing something,
we should offer informative feedback to users, whenever a user performs, some activities with
the interface. An example is a progress bar. So, whenever the user performs some tasks and the
progress of the task is shown in the form of a progress bar, then the user gets to understand how
much of the task is done and how much is remaining?

This gives the user some sort of information about the completion time. Similarly, whether a task
has been completed successfully or not can also be indicated to the user by some informative
feedback. For example, a change in color on a menu option, so typically we use save menu
option to save some editing task. And this menu option is accompanied by a metaphor of floppy
disk, which is used to indicate storage device.

Now, before saving it comes with a color and after saving the color of the disk may change, it
becomes grays which indicate that save option is done and then based on that change in color
user may get to know, whether the save option is successfully done or not. If the color does not
change, that means save is not done. So, we have to save again. Otherwise, if the color is
changed that means the file is already saved. No need to do anything else. So, these are instances
of informative feedback that should be provided to the user ideally.
(Refer Slide Time: 23:03)

Rule 4 tells us, to design dialogues to yield closure of some operations. So, if the user again is
performing some operation, then apart from providing feedback there should be some sort of
dialogue between user and system, to take the user towards the closure of the operation to guide
the user. So in order to do that ideally, we should try to organize any activity into one of the 3
groups beginning part, middle part and end part.
So, activities can be grouped into beginning activities, the middle part of the activities, and
lending activities. Ideally, some feedback at the end of each group should be provided to indicate
that a particular part of the activity is over. For example, when we are trying to purchase
something online which; is a big complex task through some interface. Then, beginning of the
purchase task actual purchase, and ending or checking out of the website, we can divide all the
activities into these 3 categories.

And after each category, we should try to provide some hints to the user in the form of dialogues,
to enable the user to understand the current stage where he or she is. This actually the dialogues
complement the informative feedback.
(Refer Slide Time: 24:53)

Then comes the fifth rule fifth golden rule of Schneiderman which says that ideally, designers
should offer error prevention and simple error handling mechanisms in the design. So, any
designer should strive for preventing errors by the users, and if prevention is not possible, which
typically is the case then, how to come out of the erroneous situation that mechanism should be
provided. The objective should be to keep error rates low and there should be some error
handling mechanism.

For example, when we are performing some activity through some window the close and start
options should not be kept closer to each other. In that case, erroneously user may select close
instead of start or start instead of close which will increase the error rate. That is a very typical
example of how to keep error rates low. Also, once some error is made error happened then,
complicated error messages should not be shown to the users ideally.

So, the error messages should be in the understandable form in natural languages with as few
technical terms as possible that should be the objective of any design of interfaces. So, rule 5
deals with, how to deal with errors.
(Refer Slide Time: 26:34)

Rule 6 in continuation of rule 5, tells us to allow users to perform a reversal of actions. So,
suppose we have made some mistakes or some errors happened, we want to get out of this. Now,
get out and go where typically we should be able to reach a state where we are safe where things
were not as bad as it is in the current state. So, that is called reversal of action. So, whatever
actions we have done landed us into this current state, we want to reverse those actions.

We want to go back to an earlier state where such errors were not there. Rule 6 tells us that, our
design should support such reversal of actions, and nowadays these are taken for granted in any
GUIs or other interfaces you have heard of these terms undo operation and redo operation.
These; actually allows us to reverse immediate actions that these; operations allow us to reverse
actions that happened immediately before the last action.
(Refer Slide Time: 27:57)
The seventh rule is number 7 it tells us that designers should strive to keep users in control or
designers should strive to let the users feel that they are in control. So, this is very important that
the users should feel that they are in control of whatever operations are being done on the
interface. To get this feeling what is needed is that? The user should be able to perceive their
interactions and change in the system state.

For example, suppose the user wants to move a file from one folder to another folder through
command line if a move command is given then the system does the move operation. But the
user does not know whether or does not feel whether the actual file has been moved or not.
Instead, if the user can quote unquote, select a file representing it as a metaphor and drag it to a
folder metaphor representing the storage and then release the selected file inside that folder quote
unquote folder.

In other words, if the user is allowed toper form drag and drop operations to achieve the file
movement task in the system. Then the user actually feels that he is able to quote-unquote see
what is happening, he is able to select the file he wants, he is able to move it to the location he
wants, and he is able to place it in the location he wants this gives the user a feeling of being in
control of the system.

So, this type of visualization of the operations helps the user, feel in control and that should be
the aim of any designer of interfaces.
(Refer Slide Time: 30:23)

Finally comes, the last rule which is rule number 8. Now, this is a little different than the earlier
rules. What it says is that the designer should try to reduce the short-term memory load of the
user. Now, here it is assumed that a human being possesses 2 types of memory long-term
memory and short-term memory. Of course, this is a very simplistic way of looking at our minds.
But, from a practical point of view, it helps a lot.

So, when some interaction takes place, it is assumed that the knowledge relevant to that
interaction is loaded into the short-term memory and from there we make use of that knowledge
and perform the interaction. Now, if the interaction requires too much knowledge, then it creates
a problem. Because short-term memory is supposed to have a limited capacity it cannot contain
an infinite amount of knowledge.

So, within the limited capacity if the knowledge is restricted then interaction takes place
smoothly and usability improves. However, if the knowledge required to interact is more than the
capacity, then it affects usability and the interaction tends to be not so smooth. So, there is one
theory by George miller, which was proposed way back in 1956 says that it is known as the 7
plus minus 2 rule which says that our short-term memory can at a time hold between 5 to 9
pieces of information.
Now, these pieces of information of course are not clearly defined. But we can assume them to
be units of information that our short-term memory can hold between 5 to 9 units and it varies
from person to person. So, average number of pieces of information that can be stored in 7 varies
from 5 to 9 from 1% to another. So, what this 7 plus minus 2 rule, tells us is that a design should
not force users to remember too many things.

Suppose, somebody can hold seven units of information, then if a design requires the user to
make use of more than seven units of information then of course that interaction is likely to fail.
Because the short-term memory; capacity is exceeded and the user will not be able to bring in
that knowledge to operate the interface. So, we should be very careful while designing our
interface. We should not force the user to remember too many things which in turn is going to
affect the interaction.

So, these are the 8 golden rules proposed by Schneiderman and while going for any interface
design, we should take these rules as a starting point. Whatever our intuition tells us about the
design we should test it with respect to these rules and see whether these rules are violated if they
are violated, then we should refine our design and come up with a modified design. So, that is
how we should proceed.
(Refer Slide Time: 34:12)

Now, let us try to understand the importance of these rules in the context of a system design let
us try to understand it with respect to a case study. So, what is the case, the case here is a web
page for railway ticket reservation, to be used by a traveler. So, the traveler wants to book tickets
online through the web page and here of course we are assuming that the traveler is a
non-technology expert or in other words layman user of the interface. So, the interactive system
principles apply and accordingly usability concerns are very relevant in this case.
(Refer Slide Time: 35:07)

Now given this problem, we need a web page that allows a traveler to book tickets for traveling
by train. Suppose somebody proposed a design of an interface for railway passenger reservation
inquiry. It contains several option there is this top-level menu containing several options then this
middle part has several sets of menus, left side, central side and there is some other web real
estate used for some other purpose.

At the bottom there are some options again there is another menu at the very bottom of the
interface. So, each of these options is essentially hyperlinks after clicking we get to see a
different page.
(Refer Slide Time: 36:17)
So, whether it serves our purpose it can serve definitely. But what are the problems are there any
problems with this interface? Let us try to understand with respect to the task that is booking of a
ticket by a traveler. So, let us first try to analyze the task from the point of view of a traveler who
is the user of this interface.
(Refer slide Time: 36:47)

Now, the ticket booking task actually involves a series of sub-tasks. So, it is not a single task it
can be broken down into sub-tasks. In sequence what is the sequence?
(Refer Slide Time: 37:04)
The first user enters the source, station details, and destination station details. To know about all
the trains that is running between the stations. That is the very first information that somebody
needs to know before he or she proceeds to book tickets. Not only the trend names along with
their timings ticket fare and availability of seat all this information is required before someone
proceeds for booking of tickets.

So, the first task is to get that information in the second subtask, based on the train information
the user selects one train. So now, the second subtask is a selection of the train along with a
selection of seats. And finally, some payment is made to book the tickets so payment is made
online to book the ticket because everything is being done online. So broadly there are these 3
sub tasks one is first to get train information then select a train with seats and finally make
payment.
(Refer Slide Time: 38:35)
If we see carefully, we will see that each of these sub tasks can further be broken down into sub
tasks and usability concerns for each of these series of sub-tasks are there. For simplicity, let us
consider only the first sub-task that is providing the source and destination information. How do
we provide the information to get the train details using the interface? So, with that interface how
can a user provide such information? Let us see let us have a closer look at the interface to find
out how a user can do that.
(Refer To Slide Time: 39:23)

So, this is the interface again, now in the interface, there is a hyperlink as marked here. The
hyperlink says that trains between important stations. So, this is all the menu options or
hyperlinks that relate to something providing station details. All other options if you check have
no apparent indication that through those links, we can provide station details. For example,
there are other hyperlink trends at a glance.

But, as the name suggests it provides information about all trends running everywhere in the
geographic location, rather than allowing us to provide some station names to get specific trend
details.
(Refer Slide Time: 40:21)

Now, the textual description says trends between important stations. This option seems to be the
closest to what the user wants to achieve. So, in order to use this hyperlink, what the user needs
to do?
(Refer Slide Time: 40:40)
As the name suggests the hyperlink only allows users to search for trends between important
pairs of stations. Now, it may so happen that the station pair that the user is interested in does not
quote-unquote important. In that case, of course, there is no way out. So, if a traveler is traveling
or willing to travel from one unimportant station to another unimportant station then this
particular option is of no use.
(Refer Slide Time: 41:14)

In fact, such users are likely to constitute a significant population of the overall user population.
Because the number of important; stations is generally much less compared to the total number
of stations in a railway network.
(Refer Slide Time: 41:38)

Now, then appeared with a cursory look at the interface it may appear that for such users there is
no option. But, that is not true the designers also have probably thought of this issue and
provided a way out for such users. So, there is another hyperlink available that can allow such
user’s to perform the task. So, on the interface, it is very difficult to find out that hyperlink.
(Refer Slide Time: 42:11)

Let us see the interface again. If we give a cursory loop can we get it now one thing we should
keep in mind is that, if an interface is provided and it takes the user a lot of time to browse
through lots of options and find out the one he or she is looking for then definitely that is not a
good interface? Because it violates certain guidelines that we will see later here you can see there
are lots of options. In the top-level menu, there are lots of options, in the middle-level menu,
there is an even larger number of options than there are these things and the bottom-level menus.
(Refer Slide Time: 43:11)

So among these options, it is really difficult to spot such a hyperlink, which allows users to
provide details of any stations not only important stations where they can be. In fact, it is there,
at the very bottom of the screen it says train between stations as highlighted here in this image.
Now, see a cursory glance at the design tells us that the placement of this particular option
actually deprives a significant segment of the user population of easily finding out the option.

Maybe after some usage, it may become easier but for a novice user, it really creates some
problems. So, then if it is not very useful to an office user then that violates a guideline that is it
affects universal usability. Let us see what else we can find out.
(Refer To Slide Time: 44:07)
Once users select this hyperlink since it is a hyperlink, a new interface appears. Now, in this new
interface, there are 2 text entry fields.
(Refer Slide Time: 44:21)

The interface looks something like this where these are the 2 text entry fields and here each field
is meant to provide information about one station. So, the fast field is for the source station and
the second field is for the destination station. But here it is not asking for names instead it is
asking for codes of a station.
(Refer Slide Time: 44:50)
Now, the code and name are different. So, the name may be very easy to remember. However,
codes need not be easy to remember and codes are a typically shorter form of the name if you are
using station code names you may be aware of which is not very easy to remember.
(Refer Slide Time: 45:17)

Then what can be done? So, for those who cannot use the code names or cannot remember the
codenames for them a link is provided where after clicking on this link a page appears where we
can get to know the station code for a given station name.
(Refer Slide Time: 46:00)
So, in summary, to achieve the goal to perform the task of entering source and destination station
names what the user gets to do. First of all the user needs to locate the appropriate hyperlink on
the screen, which as I pointed out is not very easy for novice or intermittent users, it may be okay
with expert users. Then enter station codes for source and destination and use the hyperlink
provided on the interface to learn about station codes if not known already.

Now, this is related to only the first task which is to input the source and destination station
name. Just to do that so many things the user needs to perform on the interface.
(Refer Slide Time: 46:49)
Now, many users significant user population which includes intermittent users, and no-vice users
which may not remember which is quite natural remember codes for all the stations. Now, in that
case, they are forced to use another hyperlink. Now, that actually creates inconvenience. Because
again there is a screen change and too many screen changes create inconvenience for lay-persons
lemon users.
(Refer Slide Time: 47:29)

So, these design decisions were just to enter 2 station names either the user has to remember the
code or has to use another interface to learn the code or to place the option to enter station names
or station codes. In an obscure position on the screen which makes it is difficult to find out the
link in the very first place. These types of design decisions are not very good decisions they
actually violate some of the golden rules. So, if the rules were used then probably such decisions
would not have been made.

In particular, the design that we have just discussed violets the second rule design for universal
usability, we have already seen how so effectively the design by keeping the link in a very
obscure place makes it very difficult for novice and intermittent users to locate them in the first
place. So, whenever they use it they find it difficult to find the specific hyperlink to locate the
specific hyperlink.

So, it is not very useful to novice and intermittent users for frequent users this may not be an
issue. Secondly, it violates the seventh rule which is to keep users in control. So, when we are
asking users to enter station codes and if the station code is not known then forcing the user to
select another interface then from there find out station codes. This actually makes the user feel
that they are not in control of the overall operations on the interface.

If the users would have been able to simply enter the station names instead of doing so many
things then they would have probably felt it to be in control. However, the very design that was
conceptualized and proposed makes it difficult for users to feel in control. So, that violates the
seventh rule. It also violates the eighth rule which is to reduce short-term memory load. So, when
we are asking the users to enter station codes, there can be hundreds and thousands of
unimportant stations.

Users may like to choose any pair of stations. So, hundreds of thousands of codes need to be
remembered but all those things will not be possible to accommodate in the short-term memory
.Because of its limitations, it can hold maximum it can hold for some users 5 pieces of
information for other users 9 pieces of information on an average 7 pieces of information. Each
code we consider to be a piece of information then on average 7 codes is fine but that is not
practical.

There will be hundreds and thousands of such codes and the interface forces the user to
remember them otherwise the user has to do additional operations to know it. So, the user either
has to remember or so either has to put more cognitive effort into remembering the codes or put
more physical effort into selecting the other hyperlink going through the link, going through the
information on the page and learn the code.

Both affect user’s cognitive effort and in turn, it affects the eighth rule which is to reduce
short-term memory load. So, these 3 rules are clearly violated in the particular design. That we
have seen.
(Refer Slide Time: 51:34)
Now, the design is done and we have identified that there are these 3 issues with respect to the 8
golden rules. So, what to do? Design for universal usability requires us to put this particular
hyperlink of getting to input station details for any pair of stations on a prominent place
preferably in the central place which is a design modification required. The second thing is once
this hyperlink is selected and this second page appears where station codes need to be entered.

So instead of forcing the user to move to a third page, to get to know the station code within the
second page itself, there should be some support provided. So, that user does not need to
remember the code instead the system helps the user remember the code how that is possible?
(Refer Slide Time: 52:39)
One way to do that is to use a predictive interface. Where we can predict the text from a few
characters? So, in this case, suppose the user does not know the station code. Now user
remembers the station name, so from the name few characters of the name, once the user inputs
then the code appear automatically by prediction, which will help the user in a great way.
(Refer Slide Time: 53:05)

So, the user enters characters for the station name. As soon as the user starts entering characters
system predicts station name and code both so, that the user gets to understand that this code is
meant for this name and the prediction can appear on a drop-down list. So, suppose this is the
text field. Suppose I want to know the code for the station, Howrah the moment, I enter h than in
a drop-down list, it shows codes corresponding to the station starting with the name H. So, there
may be a station name and corresponding code.

Then I enter W so to refine the list enter W then this display changes to all the station names
having HO as starting 2 letters and the corresponding codes. As soon as I locate the code, I just
select it rather than, having to find it from a big repository of information. So, this type of
predictive text interface helps us to effectively nullify the shortcomings that we have identified.
(Refer Slide Time: 54:41)
So, this can be one way of doing things. So, here the user entered K corresponding to K all the
station names appeared, and beside the name, this code appears as shown here. So here then the
user does not need to select the hyperlink and open another page to browse through the name of
stations to learn about their corresponding code. Instead, the user can simply start entering the
station name and the code automatically appears through prediction on a drop-down list and the
user just need to select it. So, this alleviates the issue of violation of the golden rules.
(Refer Slide Time: 55:32)

So, that is in summary what we can do with the guidelines. So, guidelines just to recollect.
Guidelines are starting points. Now, we may be having some intuition about design and interface
design. So, we can always use intuition to come up with the design but then whether the design is
going to be usable or not, one way to do it is by going through the entire design prototype
evaluation cycle. But before that also our intuition can be guided by the guidelines to come up
with initial designs or if we have some initial designs, we can simply apply the guidelines to
refine the design before we prototype and evaluate it.

So, in that way guidelines provide us with starting points in the design prototype to evaluate the
life cycle .So, here in this lecture, we learned about the 8 golden rules of Ben Schneiderman
which is a very generic set of guidelines applicable primarily for graphical user interfaces. But
because of its generic nature can be applied to other types of interfaces as well. In the next
lecture we are going to learn about another set of guidelines namely the 7 principles of Donald
Norman which again was proposed almost at the same time, when the eight golden rules were
proposed.

we will learn in more detail about those principles and what they refer to in the next lecture
whatever we have discussed today can be found in this book particularly chapter 2 section 2.4.4
so that is all for this lecture I hope you enjoyed the learning and got to know about the guidelines
and how it can be used in practice hope to see you all in the next lecture thank you and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology, Guwahati

Module No # 03
Lecture No # 14
Norman’s Principles

Hello and welcome to the NPTEL MOOCs course on the design and implementation of
human-computer interfaces. We are going to start lecture number 13 on interface design
guidelines. So, we will continue with our discussion on interface design guidelines which we
started in the previous lecture before, we start let us quickly recap what we are discussing. What
are these all about? So currently, we are discussing the interactive system development life cycle.
(Refer Slide Time: 01:18)

In the life cycle, several stages are there we have already covered the requirement gathering
analysis and specification stage, where we have learned how to identify and specify requirements
for a system? Now, these requirements include requirements from the point of view of the users
or usability requirements as well as the requirements by the client or customer which are
generally called functional requirements or features in the system.

Now, usability requirements can also be converted to functional requirements as we have seen in
our case study. So, we have learned how to gather these requirements and how to specify them
and create SRS documents? So, that is the outcome of this stage SRS now, once that is there then
we enterinto this design prototype evaluation cycle. Here, we start with design in design 2
designs are referred to one is interface design other one system design.

So, first, we talk about interface design. How to design the interface and interaction so as to
ensure usability? Now that design has to be prototyped and evaluated to refine the design. Once
the interface design is stabilized or finalized go for system design, which we refer to with the
same stage name design. So, at the end of the interface design cycle, we geta design document
say interface design document and at the endof the next design cycle that is related to system
design.

We get the final design document as the output of this stage. Now, this design document is then
used to implement the system which ispart of the coding and implementation stage. Here we go
forward to implement the design in the form of executable programs. So, the outcome of this is a
code now, this code is tested to check for its execution ability and this execution ability istested
through different means, which is done in the code testing phase.

In the end, there may be a test document generated after that, we get a full executable system and
then we go for usability testing of the full system throughthis method called empirical study or
empirical research method. Where; we employ end users in a controlled experimental setup to
determine usability issues. Determine and resolve usability issues after the system is designed as
usable and executable, we go for the final stage which includes deployment and maintenance.

That is the overall life cycle for any interactive system development. So, we have already
covered requirement gathering currently we are continuing with the interface design phase.
(Refer Slide Time: 04:59)
Now, in the design stage, there are 2 issues of concern one is where to start andhow to express
the design. So currently, we are focusing on where to start the design of an interface. So, we saw
that the starting point can be our experience intuition and it can be added or it can be done with
the help of design guidelines. We have already discussed one set of design guidelines which is
Schneiderman’s 8 golden rules. In this lecture we will cover another set of guidelines called
Norman's 7 principles. So, this set of guidelines is named after Donald Norman who proposed
the set.
(Refer Slide Time: 05:46)
Now, before we actually turn our focus on the actual set of guidelines or principles, we should
note that these guidelines or principles are based on a descriptive model of human-computer
interaction. So, whenever a human user interacts with a computer system here, note that the term
human user refers to layman users. Then, that interaction can be modeled. So, one such model
was used to develop these principles.

Let us first try to understand that model. So, we will first try to understand the underlying model
descriptive model which gave rise to these 7 principles. Now, this model is called the model of
interaction by Norman or Donald Norman who proposed this model. Note that this is a
descriptive model which means it can explain interaction rather than predict future effects of the
interaction.
(Refer Slide Time: 06:59)

Now, the model was proposed by Norman way back in 1988. Almost, contemporaneous to the
golden rules by Ben Schneiderman’s, which was proposed in 1986. So, the setting was similar
basically, this model was proposed to explain interaction with GUI’s or graphical user interfaces.
Just to recollect at that point in time the GUI was coming into focus, those were being
extensively developed and used in personal computing devices that were coming up at the time,
particularly personal computers.

So, because of the popularity of those interfaces, it was felt necessary to study and analyze those
interactions and come up with better designs. In that context, such models and guidelines were
proposed that include the golden rules by Schneiderman’s, as well as the 7 principles by Norman,
which is based on the explanatory or descriptive model of interaction with GUI, which again was
originally proposed by Norman.
(Refer Slide Time: 08:14)

Now, the model essentially represents the behavior of a user here. The user should be understood
as a layman user or someone who is not an expert in the underlying technology. So the model
represents the behaviour of a layman user of interactive systems in terms of a series of actions.
So, the model is nothing but a series of actions that represent the behaviour of a lay person or
layman user when he or she is interacting with an interactive system.

Now, here of course although we are using the generic term interactive system, originally the
model was developed keeping in mind interaction with graphical user interfaces which is one of
the earliest examples of interactive systems.
(Refer Slide Time: 09:16)
Now, these actions are the series of actions that is the model these actions represent 2 things. The
cognitive activities as well as the sensory-motor activities of the users so, when we say that we
are trying to model the interaction essentially what we are doing is? We are trying to model the
cognitive behaviour that is the behaviour that goes on inside the mind and the sensory-motor
behavior of the user. Sensory motor behavior refers to behaviour that is taking place through the
use of sensory organs and motor organs.

What are our sensory organs? Namely, we have 5 sensory organs eye, ear, skin, tongue, and
nose.Through this we sense the environment, and what are our motor organs. Everything can be
a motor organ like the eye which can move the mouth, head, hand, and leg. So, whenever interact
we make use of our sensory organs to sense the system state and take mental actions to process
the sensed information and then perform some motor actions to interact with the system based on
the input which is sensed through the sensory organs.

That is in a very broad sense how we can view interaction. Now in this model of interaction by
Norman this broad idea is further concretized with a set of actions presented in sequence.
(Refer Slide Time: 11:16)
To be precise the model talks of 7 such actions covering the cognitive as well as sensory-motor
activities of the user while, interacting with a graphical user interface. Now, because there are 7
actions mentioned. So, the model is also often called 7 stages of action. So, in either way, we can
call it either model of interaction or 7 stages of action both refer to the same model.
(Refer Slide Time: 11:55)

Now, these activities or actions these series of actions can be divided broadly into 2 stages. This
idea stems from the fact that any interaction can be broadly divided into 2 stages. One is the
execution stage another one is the evaluation stage. Let us try to understand what are these
stages? And what they actually imply?
(Refer Slide Time: 12:25)

So, out of the 7 actions or activities that form the model our actions are part of the execution
stage.What are these actions establish a goal that is action number 1 formulate intention action,
number 2 specify action at the interface action, number 3 an execute action, number 4 the
remaining 3 actions constitute the evaluation stage. Now, these 3 actions are to perceive system
state, interpret system state, and evaluate system state with respect to the goal.

So, these are the 7 actions. action number 1 establishes goal, action number 2 formulate
intention, action number 3 specifies action at the interface, action number 4 executes action,
action number 5 perceives system state 6 interprets system state, and 7 evaluates system state
with respect to the goal. Out of these 7 actions, 4, 1 to 4, these 4 actions are grouped together and
called the execution stage of interaction. 5 to 7 these 3 actions are grouped together and called
the evaluation stage.

So, there are 2 broad stages of interaction per the model execution stage and evaluation stage. In
the execution stage, 4 actions are defined as part of the model, in the evaluation stage 3 actions
are defined as part of the model. Now, let us try to understand what these actions are?
(Refer Slide Time: 14:33)
So, in the execution stage as we have just seen we carry out 4 actions what are these actions? Let
us see, the very first action, that we perform it should be noted that all these actions have to be
performed in sequence it is not a random sequence. So whenever, we want to explain an
interaction, we have to consider these actions happening in the sequence these are shown. So, the
very first thing in that sequence of 7 actions is to establish a goal, which is part of the execution
stage.

So, what does it mean? It means that before we start interaction we create or establish a goal to
achieve in our mind. For example we want to interact with a GUI through a selection of a button.
So, our goal is to select a button on the screen that is the goal. We have not yet selected or done
anything physically, but we have established the goal. There is this button I have to select it. So,
that is the first action in the execution stage.
(Refer Slide Time: 15:51)
Once the goal is set, the next action in the execution stage is we formulate our intention to
achieve the goal. So, that is again another mental activity that we perform before we actually
start doing the physical activity. So, the first is one mental activity to establish the goal, second is
another mental activity to formulate our intention to achieve the goal. That means, we think
mentally that this is the goal to achieve this we need to do these things. So, that is our intention
and we do that in the second act.
(Refer Slide Time: 16:36)

Next, we translate our intention into a sequence of the real-world task. Now, this is important so
mentally we define our intention or set our intention, formulate our intention that we have to
achieve this goal, and in order to do that we need to do certain tasks. But, those tasks that we
thought of mentally need not be supported by the interface. So, the third action that we should
perform is mapping the mentally determining tasks to the tasks supported by the device or by the
interface, which will allow us to achieve our goal.

So, we need to translate our intention intothe sequence of real-world tasks. As an example, we
may have set the goal of selecting a button and formulated our intention as that to select the
button we need to select, we need to point to it, and then do something to select it. Now, this
series of sub-tasks that we need to perform to select it is our mental thinking. Now to point it we
have not concretized anything.

Now in the third stage, we can think of mapping these intentions of pointing a button or locating
a button, or selecting a button in terms of things that are supported by the system. For example,
grab the mouse drag the pointer to the button, and press the button. So, these are tasks supported
by the interface. So, our intention has to be mapped to these tasks which are supported by the
system or interface that is the third action in the execution stage.
(Refer Slide Time: 18:44)

The execution stage also involves a fourth action which is the actual execution of the tasks. So,
in the first action we set a goal, in the second action mentally we formulated our intention to
achieve the goal. In the third action we translated this intention to real-world tasks and the fourth
action is actually performing these tasks. That is actually grabbing a mouse, actually dragging a
pointer, and actually pressing a mouse button. So, that is the fourth and final action in the
execution stage. So, that is the execution stage.
(Refer Slide Time: 19:36)

Now, if you have noticed there are 4 actions out of which the first 3 actions are purely mental.
So, this mental or cognitive behaviour of the user is captured with the first 3 actions. The last
action involves human motor action the last action actually captures the motor action of the user.
So first, 3 capture the cognitive behaviour, and the last action captures the motor behaviour.
(Refer Slide Time: 20:14)
Let us now move to the evaluation stage. That is the second stage of the interaction with an
interface in this context a graphical user interface. So, in this stage, we first perceive the system
state or the state of the interface. So, whenever we are using the term system we are actually
referring to the interface because a user interface is synonymous with a system. The user is not
aware of what is going on inside the computer.

So, anything that is not visible or perceivable to the user is irrelevant and whatever is visible is
relevant and that actually is the system to the user. So, in the evaluation stage, the first task is to
perceive the system state or state of the interface. For example, after we perform the task to
select a button, we look at the screen. So, to perceive the outcome of the selection operation so,
we intended to select a button we formulated intention.

We set a goal first formulated intention, translated to actual actions, and perform the actual
actions. After that, we try to perceive what happens to the interface or the screen. So, we look at
the screen to perceive the interface. That is, the first action that we do in the evaluation stage.
(Refer Slide Time: 21:54)

Perception is followed by interpretation we try to make sense of the sensory inputs. So,
perception involves perceiving through our sensory organs. Now, that collects information from
the environment then comes interpretation the second action in the evaluation stage, where we
try to make or where we try to understand the meaning of the sensory input. For example, if we
continue with our button selection task for example so, if the colour of the button changes after
we select it.

We might interpret this as the button selected if the colour does not change, we might interpret it
as a button not selected. So, after we perceive the screen and sensed through our eyes the button
with its colour and interpreted that there is a colour change. So, the button is selected that is one
outcome of this action. If there is no colour change that is sensed through our visual sensing
system that is the eyes.

We may interpret it as the button is not selected, so we may try to select it again. So, the second
action in the evaluation stage is an interpretation of the sensory input which we gather as the first
action in the evaluation stage.
(Refer Slide Time: 23:44)

The third action is very crucial that is we evaluate the result of our action by comparing it with
the goal state. So, we perceive the state interpreted the state and come to a conclusion that this is
the outcome. Now, this outcome we compare with our goal to see whether we have reached the
goal. For example, we may compare the interpretation that the button is selected to our goal state
that selects the button.

So, this comparison is the third and final action in the evaluation stage.So, in the evaluation stage
then we perform 3 actions. One is to sense the environment or sense the system state or perceive
the system state then whatever we have perceived we need to interpret as the second action and
finally, the result of interpretation is compared with our goal state to understand whether we
reach our goal state or not.
(Refer Slide Time: 24:53)

Again, if you have noticed carefully the first action that is perceived in the system state is related
to our sensory organs. So, this action actually models our perception behavior. The last 2 actions
are purely mental. So, models our cognitive behavior. So, in the execution stage, we have seen
that there are 3 cognitive actions and 1 motor action. In the evaluation stage, we can see that
there is 1 sensory action and 2 cognitive actions.
(Refer Slide Time: 25:42)
So, as you may have noticed by now that with these 7 stages, we can try to understand any
interaction with graphical user interfaces in particular and generally interactive systems of any
nature. Because these actions are very broad and generic and the overall model refers to any
interaction rather than specific interaction. So, whenever we are interacting with any GUI, for
example, one web page we can try to analyze, how we interact in terms of these 7 actions.

But once we do that, then what? So, what we gain by analyzing in terms of 7 actions. In fact,
these actions are the model if deployed properly, to understand an interaction can lead to many
interesting outcomes. One interesting application of the model is in terms of the execution
evaluation cycle. So, the model proposes to view any interaction as a cycle of these 2 stages, the
execution stage, and the evaluation stage.

So, with this model, we can think of any interaction as comprising of cycles of these 2 stages
execution stage and the evaluation stage. If the evaluation matches the goal then the cycle stops.
Otherwise, it continues till the goal is achieved. So, the last action in the evaluation stage is to
compare with the goal state. If the goal is achieved, we stop it otherwise, we start the execution
stage again with the 4 actions and then go to the evaluation stage again to compare whether we
reach the goal stage and this cycle goes on till we arrive at the goal state. So, that is a very
interesting way of looking at any interaction.
(Refer Slide Time: 27:58)
So, graphically we can represent an interaction in this cyclic form we have an execution cycle,
and evaluation cycle, so the execution cycle starts with the establishment of coal and come to the
actual action on the interface. The evaluation circle start after the actions are performed and the
perception of the state begins and it reaches the final act where the goal state is compared with
the outcome of the evaluation stage.

If it matches, then the execution stops the execution of the cycle. Otherwise again we go to the
execution stage and this continues. So, that is a nice way of looking at any interaction.But again,
so what so we get to know this cycle. Then what we can do with this knowledge?
(Refer Slide Time: 29:07)
(refer time: 29:07) This simple descriptive model of interaction can be put to much significant
use. Now, this model helps to develop 2 powerful concepts. What are these concepts?
(Refer Slide Time: 29:24)

One is called the gulf of execution. Now, this concept states that actions that we; specify to
translate intentions to action supported by the system, may not be supported by the interface.
Leading to a gap or gulf between the; first 3 actions in the execution stage and the last action in
the execution stage. So, the first reaction just to recollect tells that we first establish a goal then
formulate intention and translate intentions to some set of actions that are doable on the interface.

It may so happen that the interface does not support those actions that we identified after the
translation stage. Then in spite of having come up with a set of actions to be done on the
interface is not supporting those actions. So, we will not be able to perform those, actions. If
there is such situation then we call that there is a gap or gulf between the first 3 actions and the
last action of the execution stage so, this is called the gulf of execution.
(Refer Slide Time: 31:00)
Similarly, we can have a gulf of evaluation our interpretation of the interface state based on our
perception may not match the actual state of the interface. So, what we are perceiving and
interpreting as the system state may not match with the actual state of the system. In that case,
we call it a gap or gulf between the first 2 actions in the evaluation stage and the last action in the
same stage so, in case of a gulf of execution, we have a gulf or gap between the first 3 actions
and the last action in that stage.

And in case of a gulf of evaluation, we can have a gap or gulf between the first 2 actions and the
last action of the evaluation stage.
(Refer Slide Time: 32:15)
Now, these 2 concepts gulf of execution and the gulf of evaluation can lead to further application
of the model. These concepts were actually found to be quite useful in analyzing GUI’s graphical
user interfaces and many other interface designs and they were useful in identifying design
flaws. So, these concepts of the gulf of execution and gulf of evaluation were used heavily in
analyzing designs of GUI as well as other interactions.

That this is particularly true in the context of errors analyzing errors that may happen due to
design flaws in interfaces. The explanation of errors can be done in terms of 2 concept slips and
mistakes. So, we can make use of the outcome of the model namely the gulf of execution and the
gulf of evaluation concepts, to explain the occurrence of errors in user interaction with interfaces
particularly GUI’s in order to do that we can take the help of 2 concepts slips and mistakes.
(Refer Slide Time: 33:31)

So, there are 2 types of human error slips and mistakes. Norman's model of interaction tells us
when slips can occur and when mistakes can occur. Based on that information we can take
corrective measures in our interface design. So, let us first understand what are these concepts?
When we say that a slip has occurred during an interaction, we can explain it as due to these 3
things taking place that the user has understood the system and the goal.

The user has correctly formulated mentally the actions required to achieve the goal. But the user
has made some mistakes made some errors in performing the actions sleep happens when the
users have understood the system and goal formulated intention correctly and specified the
sequence of actions required to achieve the goal. But, made incorrect actions on the interface to
achieve the goal ten if some error happens, we call it a slip.
(Refer Slide Time: 35:01)

In contrast when you say that mistake happened? This may happen because there is some
problem in formulating a goal properly. So, if the user is able to formulate a goal and specify
actions. But could not perform the actions correctly then that is one type of error we call slip. If
the user is unable to specify or establish the goal itself the very first action in the execution stage
then if that leads to an error then we call it a mistake.
(Refer Slide Time: 35:40)
So, once we are able to understand the nature of the error whether it is a slip or a mistake we can
think of corrective actions. So, in case of slips, if we notice that slips are happening, that can be
fixed with a better interface design. So, those incorrect actions are difficult to perform. But if a
mistake happens then, interface design change may not be helpful and users need to be trained on
the interface properly.

So, it requires a better understanding of the system rather than, changing the system of course
changing the design can help in understanding. But only changing the design will not be
sufficient in case of slip so here along with the refinement of the design if required the user has
to be thoroughly trained to make him or her understand the system in a better way. So, for errors
that slip we can take one corrective measure.

For errors that are due to mistakes, we can think of other corrective measures. So, it is very
important to know what; kind of errors are happening more frequently, and accordingly, we can
take corrective measures to elevate the problem.
(Refer Slide Time: 37:06)
So, that is one very interesting application of Norman's model of interaction. So, it gave us these
powerful concepts of the gulf of execution and the gulf of evaluation. Using these concepts, we
can understand why an error happens and what kind of error happens for a given interface. And
we will be able to judge better the nature of the error, and based on that judgment, we can take
corrective measures. That is one interesting and important application of Norman's model of
interaction.

Now the same model can also be used to recommend design guidelines which can serve as the
starting point of any interface design activity like the way we can use the 8 golden rules by
Schneiderman. Now, these recommendations in the form of guidelines there are 7 such
recommendations called 7 principles. Let us see what are those 7 principles which is an outcome
of the model of interaction.
(Refer Slide Time: 38:23)
The first principle is while designing any interface, the user should be able to make use of both
knowledge in the world and knowledge in the head, use the interface and the design should
support in that behavior. The second principle states that any task that is performed by the user
who is using the interface should have a simple structure. So, the structure of tasks should be
simplified and presented in a simplified manner for the user to perform.

The third one is very important; whatever the interface does should be visible to the user so make
things visible.This helps in bridging the gulps of execution as well as the gulfs of evaluation. The
Gulf of execution and gulf of evaluation both can be bridged if things are made visible. Now, the
model talks about the mapping from intention to actual physical action.The design should be
made in a way such that this mapping is done appropriately and rightly.

So, the user is able to map rightly so the design should support actions that are easy to
understand and easy to map to intention. That is one of the important principles. While designing
the principles; also advises the designer to exploit the power of constraints both natural
constraints and artificial constraints. So, this is another recommendation that whenever you are
designing something you should be aware of the limit of interaction and you can impose
constraints in the interaction and interface elements to make it easier for the user to understand
comprehend and use the system.
The sixth principle talks about taking care of errors if during interaction error happens the design
should support error handling. So, we should design for handling errors knowing that it will
happen and the last one is somewhat interesting that if in spite of best efforts the designs are not
behaving the way they should be expected to behave. We can standardize all the interactions and
interface elements. So that it is enforced on everybody to use the way it is recommended.

So, flexibility is reduced and minimized with the process of standardization. Flexibility in the use
of the interface, as well as flexibility in interaction with the interface, is reduced with the
standardization of the design. So, that expected outcome is achieved. So, these are the 7
principles that resulted in one of the outcomes of the descriptive model of interaction proposed
by Norman.

Now, these 7 principles can be used as a starting point for interface design. So if we have any
design in mind we can see whether these principles are followed in the design of that interface.
Then, we can go ahead and prototype test and do the other things in the design prototype
evaluate cycle. So these 7 principles can act as a starting point in the same way. We can use the 8
golden rules as a starting point for interface design.

So, with that, we come to the close of this lecture. So, here in this lecture what we learned, we
learned about a model of interaction which is a descriptive model that means it cannot predict.
What is going to happen rather it can explain what is happening and why it is happening? Now,
based on that model or idea of the interaction we can do several things so the model talks of 7
actions as representative of any interaction these actions are grouped into the execution stage and
evaluation stage.

In the execution stage, there are 4 actions performed in sequence. In the evaluation stage, 3
actions are there performed in sequence and the evaluation stage actions follow the execution
stage actions the model says that these actions represent the cognitive sensory and motor
behavior of the users and these actions are performed in a cycle the execution evaluation loop,
till we achieve the goal of interaction.

So, this model gave rise to powerful concepts such as gulf of execution and gulf of evaluation
which help us to understand interactions better and interpret things that are happening with the
interaction.It also leads us to analyze the erroneous situation, understand the nature of errors that
are happening with an interface, and can help us take corrective measures to reduce or minimize
the occurrence of errors.

So, this gulf between execution and evaluation helps us to understand that errors can be of 2
types slips and mistakes.If sleep happens, we can go for a better design.If a mistake happens,
then along with design we have to train the user on the interface.If trending is turning out to be
too hard then that means the design is faulty. We need to change the design, but train on the
refined design nonetheless to avoid mistakes.

That is one of the outcomes another outcome is to come up with a set of design guidelines. So, in
this case, we have the 7 principles, that were formulated based on this model and these principles
can be used as a starting point for interface design. I hope you enjoyed the learning so far and
understood the concepts, explained in the lecture.So, that is all for this lecture.In the next lecture,
we will take up the other stages namely prototyping, evaluation, and the subsequent stages.

That is all for now whatever I have discussed can be found in this book, particularly in chapter 3
section 3.3.2. If you go through this book this chapter and section you will get to know more
about this descriptive model and how it leads to the principles so thank you and see you all in the
next lecture goodbye.
 Design & Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Module No # 04
Lecture No # 15
Prototyping

Hello and welcome to the NPTEL MOOCS course on design and implementation of human
computer interfaces lecture number 14 on prototyping. In the previous lectures we have covered
several topics.
(Refer Slide Time: 01:00)

The topics are related to the different stages of the software development life cycle for interactive
systems. Earlier we have seen how to gather usability requirements using contextual inquiry. We
have also seen how to convert the requirements into system design into design of interfaces
where we made use of guidelines and we have also covered few guidelines for the purpose. In
this lecture we are going to talk about another stage in the development life cycle namely the
stage in which we create a prototype of the design that we got after the design stage.

But before we proceed further as usual we will first have a quick relook at the stages of a
software development lifecycle for interactive system development.
(Refer Slide Time: 02:17)
If you can recollect we have several stages as shown in this life cycle we have requirement
gathering analysis and specification stage we covered this stage in details. Where we learned
about different ways to capture end user requirements and we went through one particular
approach that is contextual inquiry. Now here end user means the users who are going to use the
system rather than the clients or customers and the requirements here primarily refers to usability
requirements.

Then we have this design prototype evaluate cycle in which there are 3 stages design stage,
prototyping stage and evaluation stage evaluation of the prototype. So here design refers to 2
types of designs one is the design of the interface where usability is the primary concern other
one is the design of the system where execution efficiency is the primary concern. Now we
learned how to create a design of an interface? We talked about some design guidelines as a
starting point for designing our interface.

Now that design needs to be tested for that we need to make prototypes and get it tested through
some early evaluation methods based on the test results we can update that design and this goes
on in a cycle. Once the interface design is finalized we go for the system design where we build
the design for the code. Now there we basically focus on modularity and maintainability of the
code for quick implementation by a team.
After the system is designed we go for coding and implementation which is followed by code
testing. So the code testing primarily deals with testing the execution ability as well as the
efficiency of the code in terms of resource usage. Once this phase is over we get a working
system which is supposed to be executable and resource efficient. However we still have not
addressed through these testing’s the overall usability of the end product.

For that we have this next stage that is empirical study also called empirical research here with
end users we test the product for usability issues if any. And if some issues are found out then we
may need to go back to the earlier stages to refine and revise the design and subsequently change
the implementation. Once we get a system which is usable as well as executable we go for
deployment and the subsequent stage of maintenance. So this is in a nutshell the stages and the
overall life cycle for interactive system development.
(Refer Slide Time: 05:44)

Among these stages we have already covered requirement gathering stage; we have covered
interface design stage. We are now going to cover the next stage that is prototyping so essentially
expressing the design that we have come up with for testing purpose. In the earlier lectures we
have seen that we can make use of design guidelines to go for interface design now that provides
a starting point.
(Refer Slide Time: 06:22)
However they are just that merely a starting point with this we can go for a design but we still do
not know whether that design is going to be usable or not. So essentially what we need to do is?
Basically we need to express the design for evaluation some sort of evaluation need not be very
rigorous but some sort of evaluation.
(Refer Slide Time: 06:42)

Now to express the design our intuition may tell us that go for full implementation of the system.
Which is what most of us anyway think intuitively that ok this is the design idea let us go and
implement it and then test it to know whether it is going to work in practice but that need not be
the case. To know if the design is going to work in practice we need not fully implement the idea
first that is not necessary.
(Refer Slide Time: 07:19)

Instead what we can do we can go for building a prototype which is a lightweight

implementation in a sense to test our idea. So once we have come out with a design idea to test
the idea it is not necessary to go for full-fledged implementation of the idea in this case
interactive software interface. Instead what we can do we can much reduce our effort and cost of
development by going for lightweight implementation.

We will see what we mean by lightweight implementation in subsequent part of this lecture but
what is required is a lightweight implementation of the design idea. So that it can be tested to
know whether the design idea is going to work in practice if not then we need to revise our idea.
And that lightweight implementation is nothing but a prototype for the design idea.
(Refer Slide Time: 08:26)
So prototyping can be used for getting feedback on our design idea whether this is going to work
in practice or not. In user centric or user center design approach prototyping plays a very
important role these are built typically at a very early stage of the development life cycle. So
unless we take recourse to prototypes what we have to do is basically go for full-fledged design
and full-fledged implementation which involves lots of effort and cost.

Now once everything is done completely and then we test it and then get to know that there are
issues revising, those designs or implementations adds to the cost significantly. So we need to
avoid that for that we need to make use of prototypes which are lightweight implementation
reduces cost to a very significant extent. Cost as well as effort of development and allows us to
test without going for full-fledged implementation in that way it helps us manage the overall
effort and cost of the project.

Also typically prototypes are built at a very early stage of the development so that we get
feedback quickly and without spending too much time and effort as well as money. So these
prototypes are significant part of any user centered design approach.
(Refer Slide Time: 10:05)
Now once the purpose of a prototype is served that means we get some feedback on the design
idea by evaluating the prototypes we can discard the prototype that is what is commonly done.
So the prototype is discarded.
(Refer Slide Time: 10:25)

But that need not be the only possible way of utilizing prototype. On the other hand we can reuse
the prototype we can incrementally refine the prototype as we make progress in the development
till the end at which point it becomes the fully implemented product in itself. So what we can do?
Either we can discard the prototype after we test the design idea or we can keep on incrementally
refine the prototype. And test it and again refine it till we reach the end of the development cycle.
At which point of time the prototype itself becomes the final product that is another extreme of
the use of prototype. Now there are different ways a prototype can be made so based on
functionality that a prototype serves we can divide them into 2 broad categories.
(Refer Slide Time: 11:35)

One is horizontal prototypes what these prototypes do is basically they allow us to express the
entire interface at the surface level but without any functionality. So in horizontal prototype what
we try to do we basically express the entire interface at the very surface level without adding any
functionality to the prototype. So we cannot do any real work rather we can just test the look and
feel.

So interactions are not prototype in horizontal prototypes since we are not implementing any
functionality so we cannot do any real work in that sense that is we cannot interactively perform
any task with such a prototype. So then if we are unable to do anything then what purpose does it
serve? It serves significant purpose of course these are primarily suitable to discuss brainstorm or
elicit feedback on the interface look and feel primarily.

So the primary purpose is to get feedback or to test the look and feel of the proposed design that
is what we can achieve with horizontal prototypes.
(Refer Slide Time: 13:14)
Now there is another category of prototypes that is vertical prototypes as opposed to horizontal
prototype in these prototypes we can represent interactions. So vertical prototypes are designed
to represent interaction horizontal prototypes are designed to represent interfaces primarily.
Whereas vertical prototypes are primarily designed to represent interaction since interaction is
represented it can also represent interfaces so it can represent both.

However that does not mean that with vertical prototypes we implement every functionality; of
the system that can be achieved through interaction. Instead few selected features or
functionalities are implemented in depth that is from starting to the end point. Starting from the
first screen when the interaction starts to the screen after, the last action is performed. So,
essentially the idea is that you choose a set of activities or interactions that can be performed
with the proposed system.

Now this set has to be chosen carefully typically representative use cases should be chosen.
Secondly the use cases that are chosen are to be implemented in full that means from the starting
screen the screen when the interaction starts to the screen when the interaction ends. And all
intermediate screens in between as well as the way to interact all these things have to be
implemented in a vertical prototype. Clearly these prototypes are suitable for analysis of
interactions and features of a proposed system.
So these are the 2 categories of prototypes which we can think of based on the functionalities
that they support. There can be another way to categorize prototypes as well.
(Refer Slide Time: 15:42)

That is based on how we can create the prototypes how prototypes are implemented. So one such
category is low fidelity so how to create prototypes there are different ways to create prototypes
and broadly there are 3 categories of prototypes according to the way they are created. One
category is low fidelity prototype in this case we do not require any technological intervention to
create a prototype we do not require any computer software or anything.

Instead we can make use of objects that are easily available such as paper, cardboards, woods,
clay and so on to create a prototype for a product. A very popular example of, such a prototype
are the paper mock-ups for interface look fill and even functionality. So when we are trying to
create a horizontal prototype we can use paper mock-ups which are a low cost way of
implementing the idea.

Since we are not relying on technology and technological expertise is not required these types or
these prototypes are quick to make and cheap to create. They are also quick and cheap to modify
as well because in this design prototype evaluate cycle we need to revise our design and
accordingly recreate the prototypes. So we should have a prototype which is not only easy to
create but also easy to modify and low fidelity prototypes are best fit for that purpose.
By the very nature of its way of implementation these prototypes are good for horizontal
prototypes and generally used for brainstorming on alternative designs and get user responses on
the idea so that is the anyway the purpose of horizontal prototypes.
(Refer Slide Time: 17:58)

One special and popular low fidelity prototype is interface sketches. Now this can be considered
to be slightly different from the other prototypes low fidelity prototypes that we have mentioned
in the previous part of the lecture. So this actually offers another, low fidelity prototypes which
are nothing but drawings as the name suggests name suggests drawings depicting major
components of an interface. So again we are trying to basically create interface look and feel

So we are trying to create prototypes for interface look and feel and interface sketches allow us
to do that. Again good for horizontal prototype because it, allow us to envision appearance of the
interface. However when we are talking of interface sketches it need not be the case that they are
made with simple papers or simple woods or clays or something so they can be typically drawn
on a paper.

In that case that is low cost but they can also be created using computers so some technological
expertise may be required but in principle interface sketches are considered to be low fidelity
prototype.
(Refer Slide Time: 19:17)
let us try to understand this with an example consider a shop now the shop sells various
consumer items such as clothes, bags and so on. The shop owner wants an interactive system to
generate bills based on the selection by a customer that is the requirement that has come from the
owner of the shop. The customer selection is scanned and identified by the system and the bill is
generated.

So that is a functional requirement which again has come from the client which in this case is the
shop owner. Now the shop owner wants to have a system which allows the customer to perform
such actions and then accordingly the system responds by generating a bill. A sketch for the
proposed interface design can be made so that whatever design ideas the developers come up
with can be shown to the client in this case the shop owner and his or her feedback can be taken.
(Refer Slide Time: 20:41)
Let us see one such interface sketch here as you can see this is one idea of the interface how it
should look like so it is created on a piece of paper. So it is a low cost implementation of the
prototype of the interface only the appearance rather than any real function. Here there are
according to this design there are several components one top component, then middle
component, top left and top right there are 2 components. Then middle component, then lower
component and a central component.

So these are the components that can be part of the interface as proposed by the design team and
this design can be taken for feedback. And this prototype can be taken to the client or the shop
owner for feedback on the design idea. So the top left corner component talks about certain
things top right corner component talks about the selected product.

Central component with the menu and the details shows the billing information and the lower
component here shows the options now the same sketch can be done in a different way. So here
when we are using paper and hand draws the sketch clearly the quality is not very high. We can
do the same thing with the help of a computer or sketching software.
(Refer Slide Time: 22:29)
As shown in this next version of the prototype the same thing but now; it is created with
sketching software. Again the same components top left, top right, central component with
menus and lower components. But now it looks much better and probably it will be easier to
collect feedback if such a sketch is used. So here we are not only relying on low cost
non-technological approaches to create the prototype. We may use some computers or
technology to create a good quality prototype although that is still low fidelity prototype.
(Refer Slide Time: 23:23)

Now sketches in itself are not sufficient to prototype interaction because they are primarily used
for horizontal prototyping. Primarily to get feedback on the look and feel of the interface as
probably we have seen in the previous example. In the example if we create such a prototype of
the interface which is the sketch it is not possible to know the sequence of actions and the
corresponding changes on the interface to execute a task such as a stroller purchase.

If the customer purchases stroller using the interface what are the actions and how the screen
changes that type of information is not possible to get using simple interface sketches for that we
need to do something more.
(Refer Slide Time: 24:21)

So sketches essentially represents horizontal prototypes now using the same idea and extending
the idea a bit further we can actually make use of the idea to go for vertical prototypes as well.
For that what we need to do is not to create a single sketch rather a series of such sketches.
(Refer Slide Time: 24:32)
For that what we need to do is not to create a single sketch rather a series of such sketches for the
interfaces at different stages of interaction. Now when we create such a series of sketches where
each sketch represents an instance of the interface during the course of interaction for achieving
a specific goal that series of sketches is called storyboarding. Now in other words storyboarding
idea can be used to represent interaction or to go a little bit further we can create story boards to
have a vertical prototype.
(Refer Slide Time: 25:18)
The idea originated from the film industry where such a storyboards are used to depict a scene.
So before a scene is sought its sequence is depicted using storyboards so the same idea is used
here.
(Refer Slide Time: 25:40)

Remember that storyboard refers to a series of sketches now each intermediate sketch in the
storyboard is called a key frame again the term is borrowed from the movies. Now a key frame
can be considered to be a snapshot of the interaction at a particular point of time at any specific
instance of interaction or a particular point of time during the course of the interaction.

So when we are using the idea of interface sketches and extending it to create vertical prototype
what we need to do is we have to create a storyboard depicting the interaction. Now in a
storyboard there are key frames or intermediate interfaces which results due to the interaction
during the course of the entire interaction.
(Refer Slide Time: 26:35)
So the key frames allow us to visualize the nature of interactions in its entirety for a specific
scene. So this is nothing but what we have discussed earlier as vertical prototype we want to
visualize interactions involving change in screens or interfaces and that we can achieve with a
storyboard having key frames. Where, each key frame represents an intermediate interface which
results during the course of interaction at any given point of time.
(Refer Slide Time: 27:13)

Let us try to understand this idea with an example suppose we are trying to design a mobile app
to find spicy food in our neighborhood that is the design idea.
(Refer Slide Time: 27:29)
So in a storyboard we try to capture the sequence of actions starting from the desire to find food
to the actual finding of food along with the appearance of the intermediate screens. So that
should be captured in a storyboard as shown in this series of screens. First screen shows the
desire to find food that is the starting point of the interaction then opening the app to do the same
that is second screen where it shows some food menu and whatever is available.

Then in the third screen we go for specific food items say in this case Indian then what should be
on they are under this Indian food menu north India and south Indian. 4th screen another
category is selected north Indian food and under which some menu options are available that is
depicted here. Fifth screen shows that we have zeroed in on a specific menu item with some
description.

And finally in the last screen we can depict what to do to order that food so we have 6 sketches
one, 2, 3, 4, 5 and 6 together these 6 interface sketches constitute the storyboard. Each of these
sketches is a key frame so there are 6 key frames which together make up the storyboard. And
each of these key frames represents an instance of interaction and the corresponding interface at
that point of time.

This is how we can create a storyboard and here as you can see by specifying the sequence of
key frames we can actually specify the interaction that the interaction for selecting a food should
happen in this way. So that is how we can create a prototype for the interaction using the idea of
storyboarding and just want to emphasize again that storyboarding is a low fidelity prototyping
technique.
(Refer Slide Time: 30:18)

So apart from low fidelity prototypes we can have another way of creating a prototype that is
medium fidelity by definition medium fidelity prototypes are those which are created using
computers. Now if the computer is used to create static sketches only it still remains horizontal
prototype since no real functionality is there. So earlier we talked of low fidelity prototype where
we are using non-technology based solutions such as paper mock-ups, use of clay, use of woods
to create prototypes.

In interface sketches we have seen that we can do it in either of the 2 ways one is simply drawing
the sketch on a paper hand-drawn. Other one is using a computer tool sketching tool to create it
on created using a computer in the latter case the quality is likely to be much better than creating
something on pen and paper unless the person who is creating the sketch is a skilled painter.

Now when we are creating a prototype using, say a paper and pen that is low fidelity. When we
are using the same prototype using a computer we can call it medium fidelity rather than low
fidelity because here we are having some technological intervention. So although in principle
everything is low fidelity because we are unable to do any specific functionality using
sophisticated mechanisms still since we are using computer we can call it medium fidelity to
differentiate it from the low fidelity prototypes.
So interface using sketches created using pen and paper falls under low fidelity prototype.
Interface sketches using created using computer falls under medium fidelity prototype. Similarly
storyboards having key frames created, with pen and paper falls under low fidelity prototype.
Whereas storyboards having key frames created using computer tools fall under medium fidelity
prototype. Of course this is how we implement the prototype it does not change the nature of the
prototype that is whether it is horizontal or vertical.

With medium fidelity we can have horizontal prototypes if there is no functionality support
provided. Whereas if we are using computer to create a storyboard with support for functionality
or interaction then that medium fidelity can be a vertical prototype. However with medium
fidelity we can go even further than simply replicating low fidelity ideas.
(Refer Slide Time: 33:32)

Medium fidelity prototypes can include videos as well so instead of creating simply sketches or
story boards we can create a full-fledged video showing the transitions with a medium fidelity
prototype.
(Refer Slide Time: 33:48)
For example we can have an animation video created with some software tools such as adobe
flash tool or similar tools. And that animation video can be used to prototype the food selection
app of the previous example in the video simple controls can be provided to simulate the
interaction. For example simply pressing a keyboard button say enter button or simply clicking
on the mouse button these can be simple controls utilized to simulate change of interfaces.

So we can create an animation video and enable it with simple controls to move forward to
simulate a vertical prototype but that is not the only way to have a medium fidelity prototype.
(Refer Slide Time: 34:46)
When we are talking of vertical prototype the interaction can also be simulated with as simple a
tool as a Microsoft PowerPoint slideshow. So a simple slideshow with timer can be used in place
of other controls to basically simulate a vertical prototype. So in this case the key frames can be
converted to slides if you know already how to create slides in ppt Microsoft PowerPoint then it
will be easier to understand.

So we can create slides which represent the key frames with simple controls such as a timer or
key phrase slight transition takes place depicting the interaction and in that way the storyboard
can be converted to a particle prototype a medium fidelity vertical prototype. So when we are
referring to the term medium fidelity we are essentially referring to the idea of low fidelity but
implementing those, idea with the help of computer.

Rather than non-technological means of implementation such as papers, pens or such similar
things but the ideas remain more or less similar such as interface sketches, storyboards, key
frames all these things remain the same.
(Refer Slide Time: 36:10)

The other major category is high fidelity prototypes unlike in low fidelity or medium fidelity
prototypes in high fidelity prototypes we rely on computer programs so the prototypes are
created by writing programs. So this indirectly means actual software development activities
involved in creating the prototype. Since, we are using programs to build the prototype so these
are more sophisticated as compared to low or medium fidelity prototype. But at the same time
obviously they require much more effort including expertise in programming than the other 2
prototyping methods.
(Refer Slide Time: 37:05)

To create high fidelity prototype it is not necessary to always start writing programs from scratch
there are supports provided in the form of interface builders toolkits and wizards to ease the
programming efforts such supports are already there.
(Refer Slide Time: 37:27)
Examples of such supports include the Tcl Tk toolkit for creating GUI’S visual basic
programming language again for creating GUI’S java swing library for creating GUI’S and so
on.
(Refer Slide Time: 37:46)

Now the toolkits and libraries that are already available provide support for widgets or GUI
elements graphical user interface elements such toolkits and libraries allow us to easily create
and manipulate such widgets in a prototype. So a programmer can directly use those widgets
from the tools and libraries available rather than creating them from scratch on his or her own.
And using those widgets it is much more, easier to build GUI’s quickly without too much effort.
(Refer Slide Time: 38:32)
That is one part of the story that is to create the interface other part is to implement the
interaction that is done through programming. Essentially by writing codes to listen to user
inputs and then accordingly take actions to change the interface all these activities are done by
writing programs. So tools and libraries provide support for both creating GUI’S as well as
implementing interactions.
(Refer Slide Time: 39:05)

For implementing interactions tools and libraries again provide support for event listeners so that
user inputs can be easily captured and then necessary actions can be taken. Now since it involves
lots of effort and it provides sophisticated prototypes high fidelity prototypes are typically used
for creating vertical prototypes where sophistication is required. For horizontal prototypes such
effort may not be worth of it so for purely horizontal prototypes it is preferable to go for low
fidelity or medium fidelity prototyping approaches.
(Refer Slide Time: 39:50)

One interesting prototyping approach is called wizard of Oz approach this is actually a very
interesting approach let us quickly try to understand it.
(Refer Slide Time: 40:02)

In this technique a human subject believes to interact with an autonomous computer note the
emphasis on the word believe. So, human subject believes that he or she is interacting with a
computer in reality that is not the case. What happens is that the computer is operated by an
unseen human being who is referred to as the wizard. Now the term originated wizard of oz this
phrase originated in the early 1980s but the concept was there from before but in the early 1980s
this was put into practice.
(Refer Slide Time: 40:46)

An example of application of this concept is the testing of the listening typewriter product by
IBM way back in 1984 what happened that time is that IBM was trying to develop a speech
recognition system. Now at that time speech recognition was a very futuristic technique although
nowadays we take it for granted but in 1984 it was a futuristic technique nobody knew how to
implement it successfully.

But at that time IBM was trying to estimate whether if such a system is made whether that will
be a sellable product an acceptable product. So IBM was trying to test something which is not
yet there and they applied this wizard of oz approach. So, they wanted to test the acceptability of
the idea requiring a working system otherwise how do you test the acceptability if you do not
have a system. But the problem is at that time nobody had the speech recognizer and the
company IBM did not want to spend money and effort before testing the acceptability.

So nobody knew how long it will take or whether it will ever be possible to develop a speech
recognizer. So to test it we first need to develop it but then that is risky uncertain and involves
lots of money. IBM was not interested in spending the money before they know that if they put
in effort then actually they will come up with a sellable product. So they want to test something
which cannot be made at that time.
(Refer Slide Time: 42:30)

So they decided to go for a wizard of oz experiment.

(Refer Slide Time: 42:38)

So what was there in the experiment in this figure the experimental setup is shown in this figure
on the left side sits the user. In front of the user there is a microphone user utters something and
get some response on the screen. So user thinks that there is only this computer and the
microphone but there is a wall in between behind the wall there are seats the wizard or a human
operator of the computer.

So the microphone output is connected to the computer of the wizard and to the speaker near the
wizard which is not audible to the user. So whatever the user utters the human wizard gets to
here and based on that the human wizard types a response which is transmitted to the user's
computer. And it appears on the computer here and the user thinks that because he uttered the
word the computer understood it and then gave the response because the user is unable to see the
wizard.

Or however of his presence because the user is unable to see the wizard or however of his
presence in that way the user thinks that there is a computer which understand the speech and
then responds according to the content of the speech. So based on this understanding the user
decides whether this system is good or bad so in this setup this feedback can be collected about
the acceptability of the system.

So this overall approach is called wizard of oz where we are not relying on actual technology
fully rather we are relying on a human in the loop for creating the prototype. So that is an
interesting way of creating prototype for futuristic technologies which are yet to be developed or
which are yet to be in a matured stage. So we have learned about different ways to categorize
prototypes.
(Refer Slide Time: 44:57)
Another important issue is how to use the prototypes again there are broadly 3 ways in which we
can make use of the prototypes. It can be thrown away that means the prototype is discarded after
use. For example if we are creating a cardboard mock-up or a paper mock-up or a wooden
mock-up or a clay model or sketches drawn on paper we need to throw it out. Because they are
not anywhere computerized but throwing them out is also not a problem because they are low
cost and takes very little effort to create.

So the idea of thrown away prototypes is that we should be able to create such prototypes rapidly
and with low cost. Otherwise it becomes too expensive to discard a prototype made over a period
of time with considerable man hours spent. So when we meet these criteria then we can throw
away the prototypes and these are one way of utilizing after getting feedback we throw it away.
(Refer Slide Time: 46:02)
Another way of using prototype is the incremental approach what this approach says here the
system is designed into units. So, overall system that we are trying to test is divided into units or
modules. Each unit is separately prototyped and tested afterwards it is integrated into the system.
So the entire system is divided into units each unit is prototyped, tested, feedback collected
revised all these things done.

And then they are integrated together into the whole system so that is an incremental approach.
Here we are not discarding but we are refining the prototypes of individual modules or units of
the system. And then finally once all are tested and refined we are integrating them into the
whole system that is the incremental approach.
(Refer Slide Time: 46:58)
Third approach is called evolutionary for utilizing prototypes we can go for evolutionary
approach as well. Here also we are not throwing away the prototypes but unlike incremental
approach here we are not dividing the system into modules and separately prototyping each
module. Instead what we are doing we are creating a prototype for the whole system together and
then we are testing it.

Based on the testing the prototype of the system is altered and this goes on in a cycle and
eventually it becomes the final product. So the evolutionary approach is what immediately comes
to our mind when we think of prototypes to create the full system, test it, refine the system, test it
again and goes on in a cycle till we reach the final product so that is called evolutionary
approach. But that is not the only approach other approaches as we have discussed include
thrown away approach and incremental approach we can choose any of these approaches.
(Refer Slide Time: 48:07)
So with that we come to the end of our discussion on prototypes so here we have learned various
things about prototypes. What is prototype, how it is useful so we have seen that prototypes can
be vertical or horizontal based on what we implement as prototype. We have also seen that
depending on the use of the material and technology we can categorize them as low fidelity
medium fidelity or high fidelity prototypes.

And learned about few of the prototyping techniques such as interface sketches, storyboarding
high fidelity of course provides us the most sophisticated prototypes because they rely on
programs and purely technology oriented. Also we have seen how to make use of the prototypes
once they are built. We can either throw them away after use that is after getting the feedback on
the design idea which is typically the case with low fidelity low cost prototypes.

Or we can keep on using them till they convert to the final product so now this approach can be
done in either of the 2 ways either we can go for incremental approach or we can go for
evolutionary approach. In incremental approach we divide the whole system into units prototype
each unit test each unit separately. And finally integrate them together to get the whole product.

In evolutionary we create the prototype of the whole system itself at the beginning then
incrementally refine them after every testing cycle and finally it leads to the final product. So
that is in a nutshell we also have learned about wizard of oz approach. So that is in a nutshell
what is prototype and how we can make use of prototypes in the interactive system development
lifecycle.

So with that we have finished our discussion on several of the SDLC stages namely requirement
gathering, interface design stage with guidelines and with this lecture on prototyping stage as
well.
(Refer Slide Time: 50:33)

So if we see the life cycle again so we have already covered this stage requirement gathering
stage, design stage. Note here that when we talk of design stage we are referring to 2 types of
design one is interface design one is system design so we have covered so far interface design
stage.And with this lecture we have covered prototyping stage in subsequent lectures we will
take up the other stages namely the quick evaluation of prototype and system design stage. So
that will be the subject matter of our next lecture.
(Refer Slide Time: 51:06)
That is how to evaluate the prototypes that is the other important stage in the design prototype
evaluates cycle which is typically early evaluation of the design idea. So that will cover in the
next lecture whatever we have covered in this lecture.
(Refer Slide Time: 51:23)

Can be found in this book Human Computer Interaction User Centric Computing for Design you
can refer to chapter 2 section 2.4.5. With that we have come to the end of this lecture I hope you
enjoyed the lecture looking forward to see you again in the next lecture thank you and goodbye
you.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Lecture: 16
Prototype Evaluation I

(Refer Slide Time: 00:54)

Hello and welcome to NPTEL MOOC’s course on design and implementation of human
computer interfaces lecture number 15. So, in the earlier lecture we talked about how to create
prototypes. Prototypes are useful for testing design ideas as we have discussed elaborately during
the lecture. Now when we are talking about prototype so, it is basically meant to test our ideas
but testing means we need to evaluate it.

At the same time we have to ensure that whatever methodology we apply for evaluation should
be first we should be able to get the results quickly otherwise that will defeat the purpose why
so?
(Refer Slide Time: 01:41)
Let us try to understand this with respect to the software development life cycle for interactive
systems. So, when we talked about developing a software we also learned about the interactive
system development life cycle. If you may recollect we have talked about requirement gathering
and after that we said that there is One Design prototype evaluate cycle which consists of three
stages design stage, prototyping stage and evaluation stage.

Now here we are specifically focusing on the cycle that means once we get the design done
maybe either based on our intuition or may be using the design guidelines as a starting point or
based on our experience and so on. We express it in the form of prototype and then get it
evaluated. So, that we get to know whether the design suffers from any problem. So, when you
say evaluate it what we are trying to understand?

We are trying to understand whether the design suffers from usability problem because for
interactive systems usability is our main concern. So, we evaluate the prototypes to learn about
issues that may be there with the design. Then based on identification of those issues we go for
refinement of the design again then again we go for prototyping and again we evaluate and this
cycle goes on till we arrive at a design which no longer has significant amount of issues with
respect to usability.
Now typically when we are trying to implement this life cycle typically the design prototype
evaluate cycle takes place frequently and many times the iteration takes place. In other words we
have to be ready to execute this cycle many times. Now if our evaluation takes time then when
we need to do it many times repeatedly then overall cycle time till we arrive at a stable design
increases which is detrimental to the overall turnaround time of the project.

So, our aim should be to have an evaluation method which gives us quick result. Now typically
this evaluation is done at the early stages of design. So, specific and specialized evaluation
methods are there which help us get quick results of evaluation of the prototype just for the sake
of completion. So, once the stable design is arrived at then we go for system design from system
design you go to coding and implementation stage this is followed by code testing.

So, after code testing what we get is an executable system that system we test further with end
users to know about the usability of the final product. So, that is done in this stage empirical
study. Once we are sure that no further usability issues are there or the usability issues are very
few and not significant then we go for deployment and maintenance this is in brief the interactive
system development life cycle.

Out of which we have already talked about requirement gathering design prototyping and in this
lecture we are going to talk about how to quickly evaluate our prototypes.
(Refer Slide Time: 05:37)
So, essentially the topic relates to quick prototype evaluation. So, the word quick is very
significant here and we will see how or what methodology can ensure that the evaluation is done
quickly. Now the quick is a relative term. So, just to put it into perspective to evaluate usability
ideally we should go through rigorous user testing and that is the stage that we just mentioned
empirical study stage where we do this rigorous testing.

Now that rigorous testing takes lot of time and typically that testing is carried out only once or
twice in the life cycle. Whereas the quick evaluation that we do in the early stages in the design
prototype evaluate cycle can be performed many times and it produces results without much
investment in manpower, effort and cost. So, with respect to the empirical study we are saying
that our evaluation method should be quick.
(Refer Slide Time: 06:51)
So, let us now try to understand the evaluation methods that we can use to get quick results after
testing the prototypes. So, now suppose I ask you a question a basic question how do we evaluate
an interface what would be the answer to this question? This is a very basic question which we
should be able to answer before we try to understand what we mean by quick evaluation.
(Refer Slide Time: 07:21)

So, the answer is simple by evaluating usability in our earlier lectures we talked about the idea of
usability there is an ISO standard definition of usability which we have discussed in details. Now
that idea of usability needs to be evaluated or we need to check in our proposed design which is
expressed in the form of a prototype whether the usability idea is present or there are some
deficiencies in the design. So, that usability is affected. So, how do we do that?

There are several methods available the most fundamental method of course is empirical study or
empirical research method where we employ end users a group of end users collect usage data
from them in a controlled setting analyze that data to conclude about the overall usability of a
product. But that as I already mentioned earlier can involve cost and time overrun in the overall
product life cycle if we do it repeatedly.

Because any empirical study involves lots of time lots of effort huge manpower may be resources
so, it is a costly affair. Definitely empirical studies cannot give us quick result. So, we need to go
for some alternatives. So, there are alternative ways to get quick results.
(Refer Slide Time: 09:12)

One such alternative method is called expert evaluation method. Now expert evaluation is used
for quick and cheap evaluation of prototype. Evaluation of what? Evaluation for of prototype and
evaluation for what evaluation for usability? So, expert evolution method is a quick and cheap
method of evaluation of prototypes for usability and such method are typically applied at an
early stage of design rather than after the product is developed.
In order to perform expert evaluation we need two things. So, there are two crucial components
of this study method or the evaluation method or the testing method which we need to have
before we go for expert evaluation.
(Refer Slide Time: 10:06)

One of those things is up prototype. Now we require at least a low fidelity prototype. Recollect
our discussion on prototyping. So, we talked about two types of prototypes one is low fidelity
prototype and the other one is high fidelity in between there is a medium Fidelity which is
nothing but implementation of low fidelity ideas with the help of a computer. For expert
evaluation to take place we require a prototype at least a low fidelity prototype should be
available to let us test the system or let us test the design idea.

So, that is the first requirement along with that we also require an evaluation team. So, generally
it is done by a team rather than a single person. So, we require an evaluation team. Now who can
be team members that is a crucial question we should be aware of. Now the team may consist of
the designers. So, design team can act as testing team or it may include other skilled designers.
So, there may be other persons who are designers themselves.

Designer of the interface skill designer but they need not necessarily be part of the design of the
current interface which we are testing. In addition and optionally few end users may also be
included in the team if available. So, if we find that some end users are available and they can be
included we can include them in the testing team but that is optional not mandatory. The team
should have at least three to five members that is also another requirement.

So, there are two things one is we need to have at least a low fidelity prototype and we need to
have an evaluation team. In the team there can be designers there can be other designers there
can be some end users and at least three to five members.
(Refer Slide Time: 12:34)

Now how the testing takes place each team member evaluates individually and produces a report
it is not a group activity. So, there is a team. Now the Prototype is given to each team member
with certain things along with the Prototype which we will discuss in subsequent part of this
lecture. And each team member individually evaluates the Prototype and produces a report on
various usability aspects of the system or the interface.

So, the report contains a list of usability issues that the evaluator found out. So, each member of
the team produces such a report and all those reports are collected and combined to produce a
final list of usability issues. Once that list is available that is the outcome of the evaluation stage
and based on that final list we go for refinement of the design subsequently prototype the refined
design again we evaluate and so on in this way the cycle takes place.
(Refer Slide Time: 13:52)
So, this broad idea is called expert evaluation. Now why it is called expert evaluation? Because
we are relying on quote unquote experts to get the evaluation done rather than end users. So,
usability as per definition if you recollect the definition as per definition usability is related to the
end users but in these evaluation end users presence is optional as we just mentioned. So, in the
team optionally we can include them we may not include them.

We are relying on the testing by skilled designers who are supposed to be experts in
understanding or in the knowledge of user behaviour. We are assuming that those skill designers
have sufficient knowledge of user behavior to understand from user's point of view the usability
issues and they can produce relevant reports that is why this is called expert evaluation method.
There are several ways in which expert evaluation can take place here in this lecture we are
going to talk about two such methods.
(Refer Slide Time: 15:11)
These two are cognitive walkthrough method and heuristic evaluation method let us start with
cognitive walkthrough method. What it is? How it is done and what it produces let us try to
understand that.
(Refer Slide Time: 15:29)

Broadly cognitive walkthrough method which is a type of expert evaluation method can be
considered to be an usability inspection method. So, essentially this method refers to inspection
of a system for identifying usability issues. What are the requirements for this method? Like the
broad requirements we just discussed for any expert evaluation method here also the same
requirements are there. At least a low fidelity prototype with an additional requirement is that
that the prototype should support several interface level tasks.

In other words we not only require a prototype but the Prototype should be a vertical prototype.
Recollect our discussion on prototype where we said vertical prototypes are those that prototypes
interface state at any instant of interaction as well as the interaction itself. So, essentially the
prototype refers to a set of interfaces each interface refers to a particular stage of interaction and
it also contains the mechanism to change interfaces in other words the mechanism to perform the
interaction.

So, when we are talking of cognitive walkthrough we need to have such prototypes with us and
importantly not only a vertical prototype but many vertical prototypes for the system that means
we should have more than one tasks prototyped and available to us before we go for cognitive
walkthrough method. At least three to five member team should be their evaluation team as we
have already discussed along with the Prototype.

Now here in this team again just to recollect we can include end users if available we can include
other skill designers or only the member of the design team.
(Refer Slide Time: 17:53)
So, how it works those are the requirements based on that requirements how we can perform a
cognitive walkthrough. Let us try to understand this in terms of one example. So, earlier we
talked about a calendar application simple calendar application. So, let us now try to understand
cognitive walkthrough with respect to an interface that we have designed for the calendar
application.

Suppose we have a design for the calendar app in our app we show only the months in the first
screen once the user selects a month by some means either by Mouse click or tap another screen
appears showing the dates or the days in that in that month a user can select any day and add
some note. So, that is the interface that we propose for the simple calendar app. It shows months
at a time once a month is selected it shows days in that month.

And if we choose a date day then in that day we can keep some notables. So, that interface is
available. Now based on this idea of the interface let us try to understand whether this interface
suffers from any usability issue assume that we have prototyped it and we want to test it and we
are applying cognitive walkthrough method for identifying usability issues with this interface.
For that as we just mentioned cognitive work through requires tasks.

So, we assume prototype is available. So, what can be the tasks that a user can do with this
interface. There can be many tasks but in prototype we of course cannot implement all the tasks.
(Refer Slide Time: 20:02)
So, few will select but let us first have a look at different types of tasks that can be done with this
interface user can select a month select a day of a month add note to a particular day of a month
can get back to the month view from the day view and vice versa. So, these are some of the tasks
which are likely to be frequently performed by an end user of the Calendar app.
(Refer Slide Time: 20:26)

Now in order to perform cognitive walkthrough we need to have some prototypes ready in the
Prototype we need to replicate some task scenario and the prototype should support more than
one of these tasks. So, we can create prototypes for multiple tasks that are supported by the
interface. We can make simple paper prototypes for these tasks like we have discussed earlier we
can create storyboards to create a vertical prototype.

So, each prototype is a series of sketches depicting change of screen after each interaction this is
nothing but the idea of storyboarding where each intermediate sketch is called a keyframe.
(Refer Slide Time: 21:28)

Now we first need to before we go for creating a prototype we first need to explicitly describe a
task or rather specify the scenario to perform tasks. Now let us take one example suppose you are
an user of the calendar app and if you recollect the Calendar app when you talked about the
Calendar app we mentioned that it is to be used by either teacher or students in an academic
environment. So, suppose you are a teacher or instructor.

So, you are planning to take a lecture on that subject human computer interaction you want to
schedule a class on the first Monday of the next month that is what you want because you know
that the students are available only on the specific Monday. So, every month first Monday within
a semester the students are available other Mondays they are not available for some reason and
on all the other days of the week they have some other works.

So, they do not have any free slot for you to take the lecture. Now you want to find out the date
so, that you can inform the students about the class. So, you are given the Calendar app your task
is to find out the debt on which the first Monday of the next month falls and once you are able to
identify the debt you can inform the students and additionally you can keep some note on that
date in your Calendar app.
(Refer Slide Time: 23:24)

So, what is your task as a user of the app your task is to identify or determine the date on which
first Monday of the next month Falls. In order to perform this task we need to perform or rather
you need to perform some interface level activities or tasks what are those tasks one is to select
the next month next is locate the first Monday in the month view and the third is Mark the date
by some means along with keeping a note on that particular date regarding the schedule of the
class.

So, these are some activities that that you need to perform with the interface to know about the
date. Now let us see if with the proposed design you perform these activities whether there will
be any usability issues. We want to test for usability of the proposed design with respect to these
tasks using cognitive walkthrough method. So, then in the method what happens.
(Refer Slide Time: 24:37)
This scenario is given to the evaluators that mean each member of the evaluation team this
scenario is given then they are asked to find out the debt by performing the interface level tasks
with the prototype. So, prototype is created to carry out these tasks that means you have a
vertical prototype where screen changes take place by some means of interaction which you
specify indicating the completion of the tasks.

Now, this prototype you give to the evaluators or individual evaluators in the team and ask them
to carry out the tasks in particular carry out the interface level tasks to achieve the overall
objective of identifying the debt.
(Refer Slide Time: 25:36)
Now after giving the tasks to the evaluator so, you have identified the task scenario created
prototype identified the evaluation team and you have given the tasks or whatever prototypes you
have created to each member of the evaluation team to generate usability reports. After that you
also need to do one more step we also need to frame not the word frame you also need to frame a
set of questions which are related to usability issues beforehand.

This is essentially a way to guide the evaluators to identify usability issues. Evaluators are
expected to report on these issues while they perform the tasks. So, as a designer of the test you
are expected to come up with a set of questions each question pertains to some usability aspect of
the interface and your expected to create a list of such questions this list is provided to each of
the evaluators along with the prototype.

So, the evaluators are asked to perform the tasks and at the same time answer those questions
which will bring out the usability issues as perceived by the evaluator. It may be noted here that
each evaluator need not report identical findings. Each of them are free to report as per their
understanding what are the usability issues that is why at the end we need to compile them
together see whether there are duplicate findings or there are unique findings and we have to
identify the unique findings and create the final list.
(Refer Slide Time: 27:34)
So, when we say questions what we mean by that let us try to understand with respect to the
same example. So, in this case for this particular interface what can be the question or what can
be a set of questions that pertains to usability concerns for the interface let us see few of those
questions. One is you able to locate the month you are looking for easily this can be one
question. Next is the interaction required to change from the month view to the day view
apparent.

That means is it easily understandable how to perform the interaction to change from month
view to day view did you find it difficult to locate the first Monday that can be yet another
question. Was the date clearly visible along with the day. So, yet another question did you try to
go back to the month view was the mechanism to go back clearly visible in fact these are two
separate questions for brevity we have shown it together here.

So, these can be some of the questions, so, these questions if you notice carefully these questions
pertain to some aspects of the interface which affects the usability of the product. So, these types
of questions you are expected to frame and provide to the evaluators. Now the evaluators will
perform the tasks with the interface and while performing they will try to answer these questions.
As I have just mentioned earlier it is not necessary that every evaluator reports the same thing.
So, for example for this particular task with the specific interface one evaluator may find that the
second question is the interaction required to change from the month view to the debut apparent
one evaluator may find it not apparent or not very clear whereas two other evaluators may find
them to be apparent or easy to locate or easy to perform. So, there can be variations in the reports
produced by the evaluators.
(Refer Slide Time: 30:09)

There are few more things you should be aware of while trying to perform cognitive work
through. So, the broad purpose of this method is to identify problems users are likely to face. So,
when an evaluator is carrying out the tasks he or she has to assume that he or she is actually
representing a user rather than a skill designer or an expert. And as a user he or she needs to
answer the questions rather than as a skill designer.

So, it is very important that to get appropriate or reliable outcome after the test you choose your
design team your evaluation team very carefully. Second important aspect that should be noted is
that evaluators are not expected to answer only in yes or no. So, if we see the questions are you
able to see this are you able to see that that type of questions are framed. Now evaluators can
simply answer yes or no but that is not the purpose.

Along with yes or no they are supposed to give a detailed report on what they felt about the
interfaces and interactions with respect to each question. So, only yes or no is not very
informative way of testing. Along with that evaluators are expected to give detailed explanation
why they find it apparent or not apparent why they find something easily visible because of what
it may be colour, it may be size, it may be placement.

Or why they do not find it easily visible whether it is because of contrast whether it is because of
small size whether it is because of cluttering. So, that type of reasoning should be provided. Just
to give you an example suppose one button is there to go back to month view from day view.
Now one question is whether that button is easily recognizable. An evaluator may say yes or
evaluator may say no but that is not what we want whenever somebody says yes somebody
means the evaluator says yes why the evaluated thinks it is easily recognizable. Is it because the
size is big is it because the colour is such that the contrast with the background is good. Is it
because the placement is such that it is easily visible?

The possible reason with respect to the questions must be provided by the evaluator according to
his or her understanding. Similarly if the evaluator says no the reason has to be mentioned why it
is not clearly visible is it because of the background foreground contrast is it because of the size
is it because of the placement and so on and so forth. So, answer with explanation is expected
from each evaluator.

Now once all the evaluators submitted their report those are compiled by the lead evaluator or
team lead and analyzed to identify broader unique usability issues which will form the final list
of usability issues based on which the design may be refined or based on which we may decide
not to refine because if the list is very small that means and points to insignificant issues that
indicates that no further changes in the design is required. So, we may stop the cycle otherwise
we may continue with the cycle.
(Refer Slide Time: 34:34)
Some more examples of the questions for both for getting feedback as well as analyzing can be
understood in terms of this example scenario. So, one such question can be is the effect of the
action same as that of the goal of the user at that point this is at a broader level. Will a user see
the control for a particular action. So, these are broad generic type of questions not referring to
any specific system.

These questions can be adapted to specific scenarios as we have just seen, will a user see that the
control produces the desired effect, will user select a different control instead, will a user
understand the feedback provided by the system to proceed correctly what happens in case of an
error. So, whether error is taken care off. How a user who is familiar with other systems that
perform similar tasks is going to react.

So, these questions are slightly different from the questions that we have seen earlier these are
somewhat broader generic type of questions and based on this type of generic questions we can
frame individual list of questionnaire for each task scenario as we have done in the example. So,
that was about cognitive walkthrough which is one of the expert evaluation method. Let us try to
understand another expert evaluation method that is called heuristic evaluation.
(Refer Slide Time: 36:23)
So, we will try to understand what it is how it is done and what we get after the evaluation.
(Refer Slide Time: 36:33)

Now cognitive walkthrough which is one type of expert evaluation is useful definitely in the
early stages of design. So, it can be used definitely for quick evaluation of prototypes because it
does not require end users and it can be done with the design team skill designers to get the
feedback about prototypes. But there is one problem the method is scenario based that means we
evaluate with respect to specific usage scenarios.
Now for simple systems that is fine. For complex systems there are likely to be numerous usage
scenarios and we definitely cannot evaluate with respect to all. So, if we are dealing with simple
interfaces then usage scenarios are limited one or two and we can create prototypes for those
usage scenarios as we have seen in the example and those prototypes can be used vertical
prototypes which can be used to perform cognitive walkthrough.

But for more complex systems usage scenarios are likely to be numerous and in that case we
cannot perform cognitive work through to test prototypes for each possible usage scenario. Now
if we miss out some scenarios then we do not know whether there are usability issues related to
those scenarios that knowledge will never gain.
(Refer Slide Time: 38:16)

Now why we are unable to test for all usage scenarios in complex systems? So, there are
primarily two reasons one is we may not have that much time. So, if there are large number of
scenarios then even if we apply cognitive work through it will take long time to test each and
every scenario and that much time will defeat the whole purpose of quick evaluation. Secondly
which is more likely case we may not even be able to enumerate all possible you said scenarios.

So, in complex systems it is generally very difficult to identify all possible usage scenarios in
advance. So, we will not be able to enable it and then if we are unable to enumerate we will not
be able to prototype also and even if we are able to enumerate and prototype time may not be
there to perform cognitive walkthrough for all the possible usage scenarios.
(Refer Slide Time: 39:13)

There can be one way to address this concern that is instead of trying to enumerate and prototype
all usage scenarios we can work with representative use cases. What is a representative use case.
So, if there are large number of use cases it is not necessary that in real life situation all the use
cases are frequently performed. Instead most likely very small subset of the use cases are
frequently performed and our objective is to identify that small set of use cases which are
frequently performed.

That small set is the representative use case or use cases that are likely to represent real world
usage of the product. But this is easier said than done it is very difficult to identify in advance
when the product is not ready and used very difficult to identify what constitutes the
representative use cases. So, if we are able to identify then since the number is small we can
prototype and go for cognitive evaluation but it is not easy to identify representative use cases.

So, we have to go for all possible use cases which is time consuming and which may not be
possible either.
(Refer Slide Time: 40:40)
 In order to address this concern that is there with cognitive walkthrough method we can use
another approach. Now in case of cognitive walkthrough we are relying on task scenario. So, this
is Task Centric approach instead what we can do is instead of trying to evaluate usability with
respect to tasks in a Task Centric approach what we can try to do is, we can discard the task
Centric approach we no longer require tasks to be identified and usabilities is identified based on
the performance in the tasks.

What we can do we can go for comprehensive evaluation of the whole system without bothering
about task scenarios or tasks to be performed with the system. So, we no longer need to create
scenarios and ask evaluators to perform the tasks. Instead what we can do we can ask evaluators
to tick or select on a checklist of features of the system as a whole. So, the idea is very simple. In
cognitive walkthrough what we had is some task scenarios.

Now here we are not having those task scenarios instead we are having a checklist, checklist of
system features that are identified in advance which are related to usability of the interface. So,
an evaluator will be asked to take the interface prototype and tick in the checklist whichever of
the features the prototype supports that is the basic idea.
(Refer Slide Time: 42:23)
Now when we follow this idea this is called heuristic evaluation. The checklist is nothing but a
set of heuristics that we assume to represent usability of the interface or usability aspects of the
interface. So, the items in the checklist are called heuristics and these heuristics are used to
evaluate the overall system irrespective of tasks.
(Refer Slide Time: 42:53)

Like design guidelines which we have discussed earlier for heuristic evaluation also many such
checklists are available some are quite detailed and system specific similar to design guidelines
but there are some that are more focused on broader principles of usability. So, like design
guidelines we have detailed checklist which are likely to be system specific and broader
checklists where the heuristics in the checklist refer to broader usability aspects of the system.

So, evidently in that case the number of heuristics will be much less compared to detailed
checklists.
(Refer Slide Time: 43:38)

In order to understand the idea of heuristic evaluation let us see one such checklist or heuristics
which is a broader set of heuristics. This is a very popular checklist as well the 10 heuristics by
Nielsen proposed in 1994.
(Refer Slide Time: 44:01)
So, there are 10 such heuristics or items in the checklist. First heuristic says visibility of system
status whether status of the system at any instant of interaction is clearly visible to the user.
Second heuristic it talks about match between system and the real world. Whether the actions
and elements present on the interface have matches with our day to day experience in the outside
world then heuristic 3 talks about user control and freedom how the control and freedom
perceived by the user.

Forth heuristic it talks about consistency and standards. So, whether the; design follows
consistency and follow standards that is the fourth heuristics. Fifth heuristics is regarding error
prevention whether the design that we are evaluating supports or Aids error prevention. Heuristic
6 talks about recognition rather than recall that means whether it supports the; user to recognize
items on the screen rather than forcing the user to recall from memory before he or she can use
the interface.

Heuristic 7 talks about flexibility and efficiency of use whether these are supported by the
design. The eighth heuristic talks about aesthetic and minimalist design whether the design that
we are evaluating is aesthetically pleasing and it contains minimum number of elements as well
as minimum number of interactions to achieve tasks goals. The ninth heuristic talks about
whether the system helps users recognize diagnose and recover from errors and the tenth at the
final heuristic talks about whether the system supports help and documentation.
So, these heuristics as you can see lists some aspects of the design which are related to usability
for example recognition rather than recall. So, see this can be related to the Golden Rule of
Snyderman where it was mentioned that the 7 plus minus 2 rule was mentioned that means if the
user is forced to recall sequences or meaning of items if the number of recalls or the amount of
recall is large then of course that will exceed our short term memory capacity and that will be
difficult for the user to perform.

So, eventually the interaction will not be usable whereas if user is able to recognize actions and
items by the very design of the interface then the memory constraint is taken care of. So, a design
that supports recognition rather than recall is more usable than the opposite thing. So, what the
evaluator needs to do evaluator we will get this list and a prototype.
(Refer Slide Time: 47:55)

Now unlike cognitive walkthrough in case of heuristic evaluation we require low fidelity
prototype which can be a horizontal prototype because here we are not relying on tasks. So,
execution sequence is not important rather the elements present are more important. However
vertical prototypes can also be used to see the nature of interaction as well with respect to the
checklist. But even if we have a vertical prototype we do not need to specify any specific tasks
scenario.
So, for vertical prototype task scenarios need not be specified anything is fine but typically
heuristic evaluation is used for horizontal prototypes. This is in contrast to cognitive walkthrough
method where we rely mostly on vertical prototypes.
(Refer Slide Time: 48:51)

And like the other method we also need a team of evaluators. Now the team should contain at
least between three to five members that is the same as before. Now these team members can be
the designers or other expert designers or even end users along with the expert designers. So, this
point is very important. So, the evaluation team should not be only end users at this stage there
should be few skilled designers as experts in the team so, that we can get some expert feedback
along with simple Yes, No type feedback.

Now here as we said evaluation process is slightly different. So, we no longer require the task
scenario each evaluator checks the design or the prototype with respect to the heuristics and
report their findings. Now reporting here again is not simple Yes, No yype like in cognitive
walkthrough. So, even if suppose one item says that whether the design supports error prevention
if the evaluator simply say yes then that will not be very revealing rather the evaluator should say
why he or she thinks that the design supports error prevention.

What are the features present on the system or the design that supports error prevention that
detailing is required like in case of cognitive walkthrough. And once all the evaluators submitted
their reports those reports are combined to determine heuristics that are violated this is very
important. So, where the end result is identification of heuristics that are violated by the design
as reported by the majority or all the evaluators.

So, it may happen that one evaluator said it is violated but majority side it is not violated then we
will consider it to be not violated. So, in majority things that particular heuristic is violated we
will consider it to be violated and those violated heuristics are considered while refining the
interface or while refining the interface design. So, that is in a nutshell what is heuristic
evaluation.

With that we have come to the end of this lecture here we learned about quick evaluation
technique for evaluating design ideas which are prototyped. Just to quickly recap here we talked
about expert evaluation technique. Now in expert evaluation we require a prototype and an
evaluation team consisting of at least three to five members. Now the team members can be
designed team members or other skilled designers.

And additionally and optionally in this team you can include end users if available. We have
talked about two expert evaluation techniques one is cognitive walkthrough and one is heuristic
evaluation. These two techniques are different in terms of their approach to the evaluation
process. In cognitive walkthrough what we do is we perform the evaluation based on tasks task
scenarios accordingly vertical prototypes are created.

Prototypes along with a set of questions are provided to each evaluators. Evaluators carry out the
task and answers the questions in detail and submit and at the end all the reports collected from
the evaluators are combined to identify usability issues. In contrast in heuristic evaluation we do
not have any questions or a task instead what we have is a checklist or set of heuristics and a
prototype typically horizontal prototype.

So, each evaluator is given a horizontal prototype and the checklist they report their findings
based on the checklist detailed report like cognitive walkthrough at the end those are combined
to identify which of the heuristics are reported to be violated by the design and accordingly the
design is refined that is the basic idea. So, this is one way of performing quick evaluation of the
prototypes. In the next lecture we will talk about another way of weak evaluation technique
involving end users.
(Refer Slide Time: 54:01)

That is all for this lecture whatever material I have covered can be found in this book your
requested to refer to chapter 9 section 9.1 to 9.2 both the sections you can refer to, to learn about
these methods that we have covered in this lecture. Hope you have enjoyed the topic and looking
forward to meet you in the next lecture, thank you and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Lecture: 17
Prototype Evaluation II

Hello and welcome to the NPTEL MOOC’s course on design and implementation of human
computer interfaces lecture number 16 where we will continue our discussion on evaluation of
prototypes. So, in the previous lecture we started our discussion on how to evaluate prototypes.
So, the constraint that we have is that once a prototype is created it has to be evaluated quickly.
Here we are assuming that the design building of prototype and evaluation of prototype forms a
cycle.

And this cycle repeats frequently in the early stages of design till we arrive at a design which is
having very less significant amount of usability issues so it is very important to be able to
evaluate the prototypes quickly and rapidly. In the earlier lecture we have discussed about
specific methods of evaluations in particular we learned about expert evaluation methods two
methods we discussed one is cognitive walk through other one is heuristic evaluation.
(Refer Slide Time: 02:12)

In this lecture we will continue our discussion on how to quickly evaluate prototypes. So, today
we are going to start our discussion on another way of evaluating prototypes rapidly which is
user evaluation. So, here we will be discussing methods to involve end users in rapid evaluation
of prototype. Recollect that in our earlier discussion on prototype evaluation we said that it is
expert evaluation that means end users involvement is not necessary.

Although optionally they may be added in the evaluation team however today what we are going
to discuss in this lecture is based on user evaluation. Now generally evaluating prototypes or any
systems with users is time consuming process involving elaborate setup detailed data collection
and analysis methods which entails cost and time. However there are ways to quickly evaluate
systems or prototypes with users although the outcome will not be as robust as what we will get
if we follow a rigorous evaluation method.

But still in the early phase of design such a quick evaluation would be beneficial. So, let us see
how we can do that.
(Refer Slide Time: 03:41)

So, with expert evaluation that we have discussed earlier we rely on data provided by those who
are not likely to be the users of the system. Now, that is one thing that we emphasize that expert
evaluation primarily relies on expertise or domain expertise of evaluators. Now in the early
phases we make use of that which can be considered to be a replacement of evaluation by end
users.
However if it is possible to involve end users then we are likely to get more insight about
usability issues of a particular product from the data collected from such users.But we have to do
it in a rapid fashion.
(Refer Slide Time: 04:33)

Now one way to do that as we mentioned as one stage of the interactive system development life
cycle one way to do that is through empirical studies. Now that is actually a very rigorous
process and we will learn it in more details in a later lecture. This involves as I said elaborate
setup and expertise, expertise of the experimenter as well as expertise for analysis of data to
collect and analyze data which is not an easy thing to do and it takes time.
(Refer Slide Time: 05:15)
Now there is another way to collect end user feedback on a design which is much less complex
and here we can get feedback from users by asking them questions directly. So, you ask some
questions and answer to those questions are likely to give you some feedback about your design
idea this is called evaluation with self reports. So, this is the method that we are going to discuss
in this lecture.
(Refer Slide Time: 05:56)

The data that we can collect through this method can sometimes be called subjective or
preference data that is another way of referring to the data that we collect through this method.
(Refer Slide Time: 06:14)
Now let us learn in details what is evaluation with self reports.
(Refer Slide Time: 06:20)

Now when we want to get some data about usability issues of a product how we can get the
feedback from end users. So, there are different ways possible. We can ask the users to provide
some rating on a scale a rating scale a typical example is a Likart scale for providing feedback.
We can ask them to choose from a list of system attributes and ask for their feedback about those
attributes. Also, we can ask them direct open-ended questions such as what you feel about the
system. So, there are different ways to get the feedback.
(Refer Slide Time: 07:09)
Now which way we should use? Intuitively it may seem very easy to do if we simply ask them
about their feedback through open-ended questions like what you think about the system how do
you feel about the system do you think there are some issues and similar such open-ended
questions but as you can understand if I simply ask some user to give feedback based on
open-ended questions.

The results will not be very reliable because at that point of time when the user is providing the
feedback several things influences the answer including prior exposure to the system mood of the
user at that point of time so on and so forth. Now there is no way to actually analyze objectively
the reliability of the answers based on open-ended questions. In contrast if we try to take
feedback based on rating scales such as a Likart scale then these type of feedbacks are generally
considered to be more efficient and reliable.

So, instead of going to collect feedback based on open-ended questions ideally we should aim for
collecting such feedbacks using some sort of rating skills such as a Likart scale.
(Refer Slide Time: 08:50)
But that is also not easy. So, when we are planning to collect feedback using a rating scale it is
not an easy thing to do there are broadly two issues involved here what are those issues.
(Refer Slide Time: 09:05)

So, when you say we want to collect rating about some interface or rather design of some
interface how do we do that we collect it based on some questions. These are generally called
items which are typically can be in the form of a question or in the form of statements. For
example there can be a statement about some design that the controls are easily accessible. Now
on this statement we may ask the end users to provide some rating on a three point Likart scale.
Where one may refer to highly agree two may refer to neutral and three may effort to disagree.
So, this type of statements can be used to collect the rating. So, what it indicates it indicates that
there is a prerequisite before we go for using some rating scale based feedback mechanism. Here
what we need we first need to identify the items. Now these items can be in the form of questions
or statements as I just mentioned.

However when we have a set of such items this is typically referred to as a questionnaire
although it need not contain questions it can be a set of statements but the general term used is
questionnaire or items. So, it is very challenging to identify suitable questionnaire to collect the
feedback that is one of the major issues in rating based feedback mechanism.
(Refer Slide Time: 10:59)

There is another issue when we ask for feedback we assume user is already exposed to the
system otherwise the user will not be able to provide the ratings on the items in the
questionnaire. Now how we can make it possible how the user can be exposed to the system she
or he may be asked to use the system before feedback like in a controlled study. So, we can set
up a controlled study and ask the users to use the system in that controlled environment.

And typically what happens in such studies is that users are typically asked to perform a set of
tasks. So, a set of tasks is provided to the users and they are asked to perform those tasks using
the system in the controlled environment. So, that is generally how we can expose the user to the
system.
(Refer Slide Time: 12:13)

Now there are two points where we can collect feedback one is after every task remember that in
a controlled experiment we ask the user to perform a set of tasks. So, after every task we may try
to get the feedback of the user about the system or after all the tasks are performed which is
generally called a session at the end of the session we can try to get the feedback. Now if we
decide to collect feedback at one point and ignore the other point that is generally not very
advisable thing unless there is some real problem in collecting data.

So, it is desirable to collect data at both the points after each task and at the end of the session but
when we are using questionnaires to collect feedback. The questionnaire for getting feedback
after each task and the questionnaire for getting feedback after the whole session need not be the
same. So, there may be differences corresponding questionnaire may not be the same that we
have to keep in mind so accordingly we have to design the questionnaire.
(Refer Slide Time: 13:30)
Now which one is better is it advisable to go for collecting feedback after each task or after each
session. So, let us try to quickly compare these two data collection points one is post session
versus post data feedback. So, if we collect feedback after each task we are likely to pinpoint
problems with respect to specific tasks and parts of the interface used to carry out the task
because users are likely to remember problems better just after each task.

So, if we have faced any issue while using the system for carrying out a specific task that issue is
likely to be remembered by us and expressed by us if we are asked to provide feedback just after
the task is completed. Instead if we are asked to provide feedback after end of all the tasks then it
is possible that we may forget some of the issues that we have encountered during tasks that have
been performed earlier.

So, this is the advantage of post task feedback over post session feedback but this approach may
not be possible always.
(Refer Slide Time: 14:58)
With post session feedback what we gain we are more likely to learn about user perception on
overall system. So, after each task if we are taking feedback then we are likely to get issues
related to execution of that task with the specific parts of the interface which were required to
carry out the task. However it will not give us an overall idea of what are the issues. Whereas if
we are collecting feedback after the entire session is over that means all the tasks are carried out
then it is more likely that we will get user feedback on general issues related to usability.

So, we are likely to get general perception of the user about the overall system rather than only
parts of the systems involved in specific tasks. Now it may not be possible to relate that
perception with specific task or components of the interface. So, post session feedback need not
be related to whatever we experienced after each task.
(Refer Slide Time: 16:25)
Now as I mentioned earlier so when we are trying to take feedback after each task vis-a-vis when
we are trying to take feedback after the entire session or all the tasks performed we need to have
different questionnaires same questionnaire will not work in both the situations in most cases.
Accordingly different questionnaires have been developed over time to collect feedback at these
different points of interaction with the system post task and post session.

So, let us quickly learn about few such questionnaires for different feedback for post task
questionnaire several popular questionnaires are available like After Scenario Questionnaire or
ASQ proposed by Lewis in 1991, Expectation Measure proposed by Albert and Dixon in 2003.
So, these two are quite popular questionnaires meant for collecting feedback post task. Similarly
there are several popular questionnaires designed to collect feedback post session which include
system usability scale or SUQs questionnaire proposed by Brook way back in 1996.

Computer system usability questionnaire or CSUQ proposed by Lewis in 1995, Questionnaire

For User Interface Satisfaction or QUIS Chin et al proposed this in 1988, Usefulness Satisfaction
and Ease of Use Questionnaire abbreviated as USE proposed by Lund in 2001. As you can see
all of these are quite old primarily meant to collect feedback about GUIs mostly. And these are
quite popular questionnaires still in use for collecting feedback at different points of interaction
post task or post session.
(Refer Slide Time: 18:53)
Let us now try to understand each of these questionnaires with examples from each of these set
of standard and popular questionnaires. So, we will start with post task questionnaire and the
example that we are going to use is ASQ.
(Refer Slide Time: 19:13)

Now ASQ as I just mentioned ASQ is one questionnaire designed to collect user feedback after
each task is carried out in a controlled experiment. Now ASQ contains three statements users are
asked to provide rating on a seven point rating scale for each statement. So, there are three
statements and on each statement users are expected to provide a rating on a seven point rating
scale. Now ratings range from strongly disagree which is the rating of one to strongly agree
which is the highest rating of seven.

So, after every task user has to fill up the ratings for each question where the ratings vary from
strongly agree to strongly disagree. The lowest rating value one indicates strongly disagree and
the highest value indicates strongly agree.
(Refer Slide Time: 20:25)

So, what are the questions. So, there are three items or statements in the questionnaire item
number one I am satisfied with the ease of completing the tasks in this scenario. So, a task is
performed by the user following a task scenario and user has to provide rating for this statement
or item which is I am satisfied with the ease of completing the tasks in this scenario. Then
second one is I am satisfied with the amount of time it took to complete the tasks in this scenario.

Again here the user is expected to provide a rating in the seven point rating scale for this item
after the task is completed. Then the third item in the questionnaire is I am satisfied with the
support information which includes online help messages documentation when completing the
tasks. So, this item also needs to be rated in that 7 point rating scale by the user after the task is
complete. So, the user is given a task and then asked to provide ratings for all these questions or
items these are basically statements rather than questions.
So, it is better to call them items but the whole set of three items we can call questionnaire using
the standard terminology. Just to repeat statement one or item one is I am satisfied with the ease
of completing the tasks in this scenario. Then item number two I am satisfied with the amount of
time it took to complete the tasks in this scenario. And item number three I am satisfied with the
support information when completing the tasks where the support information include online
help messages and documentation.
(Refer Slide Time: 22:30)

As you can see from the questionnaire or rather the items in the questionnaire it is simple so the
questionnaire is designed to collect quick feedback and this is suitable because we are supposed
to collect feedback multiple times in the early phase of design. So, this questionnaire along with
this method supports that idea. Now let us try to understand how the feedback provided by rating
on these three items can be related to the idea of usability and usability issues.

So, when we discussed usability if you may recollect we mentioned three things as per ISO
standard definition of usability these are effectiveness, efficiency and satisfaction.
(Refer Slide Time: 23:28)
First statement in the ASQ questionnaire is related to the effectiveness measure that we have
mentioned in the definition of usability. Efficiency aspect is covered in the second statement if
you look at the statements closely and all the three statements taken together represents
satisfaction. So, the ratings for all the three statements together represent satisfaction whereas
fast statement refers to effectiveness and second one is refers to efficiency.
(Refer Slide Time: 24:01)

So, how we can make use of the feedback or the ratings that we get from the users. So, we can
actually take an average rating for each statement. Suppose we are collecting the rating from five
end users after they were asked to perform some tasks using our proposed design of the interface.
Now to perform the tasks it is not necessary to implement the interface rather some prototypes
are fine and the task scenario needs to be mentioned the way we did it in cognitive walkthrough.

But now here instead of expert evaluators we have end users to evaluate the interfaces. So, now
after each task is performed we can use the questionnaire to get the ratings and once we collect
ratings from all the five users we can take average rating for each item or we can take average
rating for all the statements taken together either of these are fine. And based on the average
rating we can take a decision.

For example suppose the rating is closer to one that means users are mostly disagree with the
statements in that case there are likely to be usability issues and we need to revise the design. If
the average ratings are closer to 7 which is the highest rating then probably issues are less and no
need to refine the design further that can be one of the way to conclude from the data that we
collect. So, that is about post task questionnaire.
(Refer Slide Time: 25:56)

Now let us try to understand post session feedback collection using questionnaire with respect to
one example here we will be using the example of system usability scale or SUS questionnaire.
(Refer Slide Time: 26:02)
Now SUS questionnaire consists of 10 statements. Again here we are using the term statement
rather than questions because these are in the form of statements. One interesting thing is that
half of these statements are positively worded and the other half are negatively worded. So,
statement number 1, 3, 5, 7 and 9 odd number statements are positively voted and even number
statements 2, 4, 6, 8 and 10 are negatively worded. Let us have a look at these statements.
(Refer Slide Time: 26:41)

Statement number one I think that I would like to use this system frequently. As you can see this
is positively worded statement. So, one is positively worded. Statement number two says I found
the system unnecessarily complex again this is a negatively worded statement. Statement number
three I thought the system was easy to use another example of a positively worded statement.
Statement 4 I think I would need the support of a technical person to be able to use the system
this is a negatively worded statement.

Statement 5 I found the various functions in this system were well integrated as you can see this
is another positively worded statement. Six says I thought the system was too inconsistent
example of negatively worded statement. Seven I would imagine that most people would learn to
use the system very quickly a positively worded statement. Eight is I found the system very
cumbersome to use a negatively worded statement.

Statement nine I felt very confident using the system again a positively added statement whereas
statement 10 says I needed to learn a lot of things before I could get going with this system
which is a negatively worded statement. So, here as we just have seen the odd number statements
namely 1 3 5 7 9 are positively worded whereas even number statements 2 4 6 8 and 10 are
negatively worded together they constitute the SUS questionnaire having these 10 items.
(Refer Slide Time: 29:05)

So, what to do with these items? So, post session the questionnaire is given to the users and they
are asked to provide rating for each statement on a five point agreement scale which is a Likart
scale where one indicates strongly disagree and five indicates strongly agree. So, for each item
the user has to provide feedback in the form of ratings in a five point agreement scale where 1
indicates strongly disagree and 5 indicates strongly agree.
(Refer Slide Time: 29:45)

Unlike in the case of ASQ here combining these ratings is slightly different. So, we need to
combine the ratings for all the 10 statements to obtain an overall SUS score which is a tricky
appear it is not as simple as simply taking an average which we did in the case of the earlier one.
(Refer Slide Time: 30:13)

So, how do we perform the combination? We first sum up the contribution let us call it C for
each statement to get overall score S. Now this contribution from each statement is an integer
which lies between the value 0 and 4, two components are there to calculate individual statement
contributions.
(Refer Slide Time: 30:50)

For positively worded statements that is statements which are odd numbered the individual
contribution for each statement is calculated as the rating obtained minus 1. So, it is R minus 1.
So, if the user provides some rating for that statement we deduct 1 from it to get the individual
contribution. For negatively worded statements the contribution is calculated as 5 minus the
rating. So, here it is 5 minus R.

So, whatever ratings the users provided for the negatively worded items or statements that is the
items which are even numbered we basically calculate the individual contribution for that
particular statement by subtracting the rating from 5.
(Refer Slide Time: 31:47)
And then we sum up these contributions as mentioned earlier. So, total SUV score is calculated
as summation for individual contributions by all the positively worded statements that is even
number statements R i - i where i varies from 1 3 5 7 9 within this set and contribution for the
statements which are negatively worded 5 minus R i where i varies between these numbers 2 4 6
8 and 10. Now we sum it up together all the 10 contributions and then multiply with a factor 2.5.

R i here indicates the rating for the ith statement and individual cases accordingly we vary i. So,
after multiplication the number that we get is the SUS score.
(Refer Slide Time: 32:54)
Let us try to understand it with an example. Suppose for statement one in a given situation where
the user was asked to use some particular interface design and provide the ratings the users have
provided the following ratings. For statement 1 rating is 5 for statement 2 rating is 4 for
statement 3 rating is 2 statement 4 rating one statement 5 rating 2 statement 6 rating 3 statement
7 again rating 2 statement 8 rating 4statement 9 rating 5 and statement 10 rating 2.

Now these ratings are provided by an user for a given design on the basis of the SUS
questionnaires. So, we now need to combine these ratings to get the SUS score for that particular
user.
(Refer Slide Time: 33:59)

So, there are two components we first have to combine ratings for positively worded statements
to get the contributions from those statements. So, it will be five minus one plus two minus one
plus two minus one plus two minus one plus five minus one or eleven. Then we have to combine
for negatively varied statements five minus rating that is five minus four five minus one five
minus three five minus four and five minus two this also and then we add them together.

So, this also results in the number eleven then we sum these two components. So, we get eleven
plus eleven that is 22 and then we get the overall score by multiplying the sum with the factor 2.5
to get 55.
(Refer Slide Time: 34:55)
So, how to interpret this number so, we got a score 55. So, what it means we can interpret this
core as a percentage. So, we can say that the score in the example is 55%. So, we got the number
55. So, we can say that SUS score is 55%. It is generally assumed based on several studies that
an SUS score around 70% or more is desirable for a system or an interface design to be
considered not having significant usability issues.

If SUS score is found out to be less than 70% then there are likely to be some usability issues and
it is better to redesign the interface. So, scores lower than the 70 percentage point might indicate
usability problems and it is preferable to revise or refine such designs. So, that is how we can
make use of the SUS score. So, that is what we can do with user based quick evaluation. Here we
have seen two methods.

So, the basic setup remains the same as in the case of expert evaluation. So, we have some tasks
and prototypes to carry out the tasks preferably vertical prototype here. So, that tasks can be
carried out then what we can do is we can collect feedback using rating scales from the users
after they were asked to perform those tasks in a controlled setting using the prototypes. So,
unlike in the expert evaluation method here the feedback is collected using rating skills.

So, we have two types of questionnaires to collect feedbacks from two points one is after each
task is carried out and second is after all the tasks are carried out that means at the end of the
session. ASQ is one example questionnaire that we have discussed to collect feedback after each
task and SUS is one example questionnaire that we have discussed to collect feedback after the
whole session. As we have discussed each of these methods has its own positive and negative
sides.

Post task questionnaire is likely to reveal more about the specific components of the interface
that has been used to carry out the task. Whereas post session questionnaire is likely to reveal
more about the general perception of the user about the whole system rather than task specific
perception it is preferable to use both as much as possible. So, that is what we can do to quickly
evaluate prototype with end users note that the requirement that the evaluation takes place in a
rapid manner is very important and these self reporting methods can satisfy that requirement with
that we end the topic here.
(Refer Slide Time: 38:26)

So, whatever I have discussed can be found in this book human computer interaction you are
requested to refer to chapter 9 section 9.3 to know in details about these methods. I hope you
have enjoyed the content and I am looking forward to meet you all in the next lecture, thank you
and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Lecture: 18
Case Study on Prototype Evaluation - I

Hello and welcome to the NPTEL MOOCs course on design and implementation of human
computer interfaces lecture number 17 where we are going to discuss about case studies on
prototype building and evaluation.
(Refer Slide Time: 00:57)

So, before we start let us quickly recap what we have learnt. So, far earlier we learned about
prototypes namely what is a prototype and we learned about different prototypes also we learned
about how to make prototypes and the different prototypes that we can make all these things we
have learned in the earlier lectures that is one side that is what are prototypes and how to make
them.
(Refer Slide Time: 01:25)
We have also learned how to evaluate the prototypes in the design prototype evaluate cycle we
need to build as well as evaluate the prototype. So, we have learnt 2 techniques for evaluation of
prototypes rather quick evaluation of prototypes one is cognitive walkthrough and the other one
is heuristic evaluation. I hope you can remember these techniques and in this lecture we are
going to see how the prototypes can be built and how it can be evaluated using these techniques.
(Refer Slide Time: 02:00)

So, we will specifically learn about building of prototypes and evaluation of those prototypes
using a case study. So, that is our objective for this lecture.
(Refer Slide Time: 02:13)
Before we go into the content let us quickly understand the case. So, we have already mentioned
it before this is about the calendar app which we have introduced earlier. if you may recollect we
are interested to build a calendar app it is meant for the students primarily for the students to help
in their various academic activities. Now that is the requirement stated in a very broad manner
and we have seen earlier how to gather the functional requirements for this calendar app and how
to represent them in a hierarchical manner.
(Refer Slide Time: 03:01)

Let us quickly recollect the functional requirement hierarchy for this calendar app. We need that
because what we have mentioned earlier is SRS or the software requirement specification
document is the starting point for design of the code as well as the interface. So, here our concern
is to get the interface designed and evaluated rather than the code and for that also we will use
the SRS document as the starting point to come up with an interface design that will support the
functional requirements that are specified in the SRS document. So, let us quickly recap the SRS
document for the calendar app that we have earlier gone through.
(Refer Slide Time: 03:43)

Particularly in lecture number 8 in the third week we have gone through this SRS document.
Now the SRS document contains several functional requirements arranged in the form of a
hierarchy the top level functions are there for example display calendar is one top level functions
under which there are 3 sub functions display months display days with events and specific date
view these are 3 sub functions under display calendar function at the top level.

Another top level function is set reminders here again there are 3 sub functions create reminders
edit reminders and delete reminders. Then we have a third top level function set background
under which there are 2 sub functions set theme and reset theme. We have a 4th top level
function synchronize under which we have attach account and remove account these 2
subfunction.
So, this is the functional hierarchy which we converted to the SRS document and which will be
the starting point of our interface design that means we are going to design an interface that will
support these functions.
(Refer Slide Time: 05:15)

So, first we will talk about building the prototype and getting it evaluated with the cognitive
walk through method. So, let us first see how we can build the prototype and how it looks. So, to
perform cognitive walk through if you recollect we need at least a medium fidelity prototype or
high fidelity prototype. In fact low fidelity can also work provided we design it in an appropriate
manner however it should be a vertical prototype that is the important concern here.
(Refer Slide Time: 05:47)
So, we need to create a vertical prototype and this prototype that we are going to discuss has
been created with a tool called figma this is an online tool that you can also use to create
prototypes.
(Refer Slide Time: 06:05)

Now the prototype has several of the functions not all functions are being discussed here.
Namely months in a year days in a month specific date set reminder edit reminder delete
reminder set theme where you can select the theme and after theme is applied those views those
things we have prototyped. Remember that here in this case study we are not designing a
prototype that supports all the functions that are present in the functional hierarchy a few
functions are left out particularly synchronization.
(Refer Slide Time: 06:45)

So, let us first quickly go through the interface how it looks like once the SRS is prototyped first
we will see how the months in a year looks like when it appears on the interface. So, there are
this 3 year-wise views are given say for 2 entry 21 we get to see January February March in this
way similarly for 2020 to 2023. So, essentially it will be in the form of a matrix. For each year
the months are shown in this manner.

So, it is a 3 by 4 matrix where there are 3 columns and 4 rows and the months along with the
days in the month are arranged in this matrix form as shown in the view. Now this view is what
we have prototyped to demonstrate the view of the months in a year.
(Refer Slide Time: 07:58)
Next if we want to see the days in a month. So, in the earlier view those dates or days were
shown in a very small manner which may not be properly visible. So, we want to enlarge it and
see it in that case we can get a view like this. Remember that here we are not concerned about
how we get this view only thing is this is the view for days in a month it can appear through tap
it can appear through touch it can appear through strike or finger stroke.

Any interaction is fine or mouse click but we are more concerned about the view rather than the
actual interaction. So, for example if we want to see a month say March 2022 or say April 2022
this is the kind of view that we will get where the days of the week are shown here Monday
Tuesday Wednesday Thursday Friday Saturday Sunday and then we get to see the dates or the
days in the month.

So, for example march 2022 starts from a Saturday and up to 31st of the month and additionally
with each day we can display certain events along with it in the way shown here. So, that is the
view that we want to create for our system.
(Refer Slide Time: 09:31)
Now there is this specific date view. So, that is about the earlier view was about seeing all the
days in a month. Now a specific day I want to see in details. So, then what kind of interface will
appear what is our design that can be seen here in the form of this prototype for specific date
views. So, for example 13th March 2022 it shows the events that are listed on this date software
engineering CS506 some discussion some other topics along with time of the event project
discussion along with time of the event.

So, this is all events view. Now in the bottom side as you can see we have different options time
tables deadlines meetings. Now if we select time table then we will get a timetable view where
only the classes will be shown that are there on that particular date software engineering ml high
performance computing along with the class timings. So, here these other discussions like shown
here in the under the all events view will not be shown.

So, this is what the specific date views look like and this is what we intend to design for the
system.
(Refer Slide Time: 11:05)
We can also have deadline view like a specific event deadline is there with the time or we can
have meeting view. So, all the meetings will be listed under this view for a specific date. So, for
a specific date either we can see all the events or we can see specific events like time table
deadlines meetings and so on.
(Refer Slide Time: 11:30)

Next is the view for setting of reminders. So, for a specific date say 18th March there are some
events and for some event we may set a reminder. So, this can be the place or this is the place in
our design using which we can set the reminder. So, if we select this option plus then this screen
will appear set reminder screen where you need to put some description and select the type with
the timetable deadline or meeting and the reminder and the event duration and then it will be
saved.

So, there is this save option provided here. So, you can use the save option and then this
reminder will appear with the event for that specific date as shown here. So, after save option is
selected then the reminder appeared. We can also get a similar interface to edit the reminder the
interface looks similar and there we can edit this reminder start and end times and save it.
(Refer Slide Time: 13:01)

We can also delete a reminder with this delete option the interface more or less looks similar.
(Refer Slide Time: 13:14)
The next function that we prototyped is select theme. So, this is the view that we get to see when
the select theme functionality is executed with the system. So, we have to remember here that by
the use of the term view what we are referring to is that this is how the interface will look like if
the system is implemented and this is what the user gets to see. So, there is this theme option
present. Now once this is selected then different themes appear here.

So, this is the theme window here with this boundary. So, this is the window that appears having
different themes like dark mode clouds geometrical floral and from here we can select a theme
then once the theme is selected then we get theme applied view. So, if we have selected a
specific cloud theme then it looks something like this or if you have selected dark mode then it
looks something like this and so on.

So, with the selection of the theme the theme gets applied on the interface and the user gets the
corresponding view.
(Refer Slide Time: 14:57)
Similarly the other 2 themes that we can apply plural as well as geometric themes and then these
will be applied on the background of the interface.
(Refer Slide Time: 15:08)

So, that is all about how the prototype looks and how we can implement the functional hierarchy
that we have identified during the requirement identification phase to create the prototype. Just to
recollect what we have just seen is how the interface appears to the users what the users get to
see while using the system. And our objective here is to create the prototypes for those interfaces
rather than actually writing a program to implement the system.
And those prototypes we can evaluate to see whether there are any usability issues with the
design that we have come up with for implementing the interfaces. So, now our next task is once
the prototype is ready we need to evaluate it.
(Refer Slide Time: 16:12)

So, let us see for this particular that we have just seen how we can apply evaluation techniques.
So, here we will first start with cognitive walkthrough and see how cognitive walkthrough can be
applied to know if there are usability issues with the specific design that we have prototyped and
just discussed.
(Refer Slide Time: 16:27)
Now if you may recollect for cognitive walkthrough you need to come up with a use case and
you have to give this use case to the evaluators. So, they will try to use the interface with respect
to the use case and then try to figure out problems if any and then create a report and finally
those will be compiled together. So, let us see one use case related to the usage of the calendar by
a student.

Suppose you have been given an assignment in the software engineering lab course to avoid
missing the deadline you would like to add a reminder for the deadline of the assignment. So,
essentially it is about setting a reminder for a particular assignment.
(Refer Slide Time: 17:25)

Let us first try to identify what are the interface level tasks that means what are the tasks that the
users are going to perform on the interfaces to achieve the objective that is setting of reminder
first thing is user has to navigate to the date of the deadline by choosing the correct year and
month in case the month is different from the current month. Then the user has to select the date
of the deadline select the plus button to set reminders.

Add the description of the assignment its type as deadline and the time of deadline and finally
save the reminder. So, these are the interface level tasks that the user needs to perform.
(Refer Slide Time: 18:15)
So, this is this screen shows the scenario and here let us quickly see how these tasks can be
performed.
(Refer Slide Time: 18:30)

This is an animation for the activities to be done to achieve this objective of setting a reminder
for a particular assignment okay. So, these are the things on the interface that we need to perform
in sequence which we have just mentioned and seen in the video.
(Refer Slide Time: 18:49)
Now this use case is given to the evaluators. So, remember that for cognitive walkthrough we
need a team consisting of between 3 to 5 evaluators who should not be part of the design team
but there should be experts domain experts and they have to go through the use case perform the
interface tasks on the prototype given and then come up with a report to help them prepare the
report some questions can be supplied.

So, let us see few such questions for example suppose we have set this question where you able
to navigate to the correct month easily. Now let us see different views expressed by the experts..
Expert one here the term. Expert essentially refers to a domain. Expert who is not part of the
design team but who knows how to use a calendar. So,. Expert one says in response to the
question yes I was able to navigate by swiping left from the current month with the prototype
that is given.

Expert 2 also said yes since the month being displayed was the month in which I had to set the
reminder.. Expert 3 again yes a simple swipe on the screen showed the next month's calendar this
is a common way to move to the next element in mobile applications. So, some commentary also
added.. Expert 4 said yes I was able to navigate to the correct month easily. There are of course
some variations like. Expert 2's response is somewhat different than the other 3.
And everybody has their own way of looking at the things and prepare response for the question
asked.
(Refer Slide Time: 20:34)

Then the next question is did you navigate to the wrong month by mistake if yes was the
mechanism to go to the correct month convenient.. Expert one said, yes but it was easy to go to
the correct month by swiping.. Expert 2 said no I selected the correct month. So, there was no
error made. Expert 3 said no I did not navigate to the wrong month I was able to swipe correctly
on the first attempt.

So, there again there was no error. Expert 4 mentioned no I did not navigate to the wrong one.
So, from these responses we can make out that. Expert one probably made some mistake and
then was able to come out of this erroneous situation easily whereas the other 3 experts did not
make the mistake. Another question is was it apparent that you could add a reminder by clicking
on the date or selecting the date.

Expert one said though it was not that apparent I did click the date to add a reminder on that date
the events listed below the dates helped however I am not sure about how to add events in an
effective manner which would span across more than a day that is a very relevant point added..
Expert 2 said yes not at first but I figured it out.. Expert 3 said that it was not completely
apparent but because there was not any other option for it in the default view it was extremely
likely and accordingly he has figured it out.

Expert 4 said it was not apparent that I could add a reminder by clicking on the date I just
happened to click on a date and was directed to that view that contained an option to add the
reminder. So, from these 4 views it appears that the intuitiveness of adding a reminder is not very
high with the current design.
(Refer Slide Time: 22:34)

Next question did the plus button indicate its function appropriately. Expert one said yes the plus
button made it clear that it is meant for adding a new event to the calendar. Expert 2 says yes it
was apparent that it displayed some functionality to add something which could be nothing other
than reminders. Expert 3 said yes it was apparent that the plus button was to add reminders and.
Expert 4 said again yes the plus button indicated its functionality properly I was able to easily
add a reminder. So, all agreed on this point.
(Refer Slide Time: 23:10)
Where the; input fields in the set reminder window clearly visible and was there naming
appropriate. Expert one said the input fields were clearly visible however for adding the deadline
both start and end was shown which confused me I would have liked to have just an end time of
the deadline. Expert 2 said yes the input fields were appropriately labeled and were visible.
Expert 3 said yes the input fields were coloured differently to the background the labels made it
easy to understand the purpose of each input field.

And expert 4 said yes the input fields in the set reminder were visible and their names clearly
reflected what they were meant for. So, essentially one expert disagreed with the naming
convention but other 3 agreed.
(Refer Slide Time: 24:07)
Were you able to see the assignment after adding in the deadline view that was the next question.
Expert one said yes I was able to see the assignment added in the deadline view and it was also
highlighted in the calendar the saved successfully message also confirmed the addition of the
assignment. So, this is a very important observation made by the expert that there was actually a
feedback. Expert 2 again said yes the deadline appeared in the deadline view with the banner
displaying that it was added successfully.

So, the same feedback is mentioned by. Expert 2 as well expert 3 also said I could see the event
added correctly in the specific day view although he did not mention about the feedback. Expert
4 said yes the assignment was visible in the deadline view after addition I also liked that the
assignments were sorted by time. So, some other feature was highlighted by the expert.
(Refer Slide Time: 25:02)
So, that was about one use case 4 experts were appointed to evaluate the interface and they were
given this particular use case and asked 5 questions on which they provided their response. Now
let us see another use case due to some unavoidable circumstances your class for the software
engineering course today has been shifted to 10 am from 10 am to 11 am you would like to edit
the reminder for the class with updated timings. So, now the task is to edit the reminder.
(Refer Slide Time: 25:44)

What are the interface level tasks select today's date select the software engineering class event
edit the start and end time fields to 10 am and 11 am respectively and finally save it.
(Refer Slide Time: 25:58)
So, this is how this interface level tasks can be performed. Again you can see the video and get
an understanding of how the interface level tasks can be performed.
(Refer Slide Time: 26:14)

Again few questions were asked to the evaluators to the experts and their responses were
collected. First question were you able to locate today's date. Expert 1 said yes it was highlighted
in blue colour. Expert 2 said yes the corresponding current day cell had highlighted background
in the months view. Expert 3 said yes the current days date had been highlighted in a different
colour to make it stand out and. Expert 4 said yes today's date was clearly highlighted I had no
difficulty in locating it. So, all could see the date.
(Refer Slide Time: 26:56)

Next question was, was it apparent that you could edit the time of the class by clicking on the
event. Expert 1 said yes it was clear that I will have the have to open the event first to make any
changes to it. Expert 2 said yes not at first but playing around made it clear that clicking on an
event had some functionality associated with it which was to edit and delete. Expert 3 mentioned
while it was not certain it was highly probable because most mobile applications allow editing
elements by selecting them.

So, expert 3 actually bringing in the learning from similar apps which expert had used earlier.
Expert 4 said editing the time of the class by clicking on the event was slightly ambiguous the
tiles representing the events did not look like buttons and an edit option was not explicitly
mentioned. So, it was not very intuitive to the expert.
(Refer Slide Time: 27:59)
Next question is was it apparent that the fields were editable. Expert one said it was not apparent
from the fields itself but the window popped up showing edit reminder made it clear that I can
edit the fields. Expert 2 said yes clicking the fields made them turn into edit mode then it could
be edited. Expert 3 said the edit reminder heading at the top made me confident that the fields
here were editable this was confirmed when I clicked on the input fields.

Expert 4 yes it was apparent that the fields were editable as the fields either closely resemble text
boxes or radio buttons. So, there is clearly a division in opinion some say it is apparent some
thought it is not apparent and those who said it is apparent they probably used their knowledge of
similar apps to infer that the particular functionality can be done with this particular interactio.
(Refer Slide Time: 29:11)
Next question was did you make an error while editing and saving if yes was the mechanism to
correct it convenient. Expert one said no I was able to correctly edit the time fields and save it.
So, no error met. Expert 2 also said no error met I correctly edited the fields and saved
successfully. Expert 3 said that yes while editing the event I deleted the event by mistake. So, I
had to make a new event with the same details it would be better if you could give a warning or
ask for confirmation before deletion.

So, some feedback mechanism is required which was not present in the prototype or rather in the
design. Expert 4 said, no I did not make an error while editing and saving. So, only one expert
made an error and according to the expert the feedback regarding the error should be there which
was missing.
(Refer Slide Time: 30:09)
The next question was where are you able to see the class event with updated timings. Expert one
said yes I was able to see the updated successfully message along with the update in the timings
of the event. Expert 2 also said yes in fact all experts said yes expert 3. Expert 4 it was visible in
the events view for a particular date according to. Expert 2 and banner was displayed showing a
successful update. Expert 3 said yes after saving the edited reminder the class timings had been
updated in the other views too.

Similarly expert 4 said yes I was able to see the class event with updated timings the green
pop-up indicating that the update is successful made the process transparent. So, most of the
experts appreciated the feedback given regarding the operation.
(Refer Slide Time: 31:04)
Let us consider another use case you want to meet your friends during the third week in the next
month you want to check your schedule to find out find an appropriate date and time for the
meet.
(Refer Slide Time: 31:24)

So, what are the interface level tasks swipe left in the current month to navigate to the next
month get an overview of your schedule for the third week in the month view itself select the
date in which you have the list number of events scheduled even better if you have a date where
no events is scheduled check the timings of the events and decide a convenient time to meet your
friend. So, these are the interface level tasks that you need to perform to create an appointment
with a friend.
(Refer Slide Time: 31:58)

Let us quickly see through a video how these interface level tasks can be achieved can be
performed with the prototype. As you can see swipe left then minimum event day then
appointment fixing. So, that is how you can schedule an appointment.
(Refer Slide Time: 32:21)

Similar to the earlier use cases here also the experts asked few questions and their responses
were collected first question was where you able to navigate to the next month without going to
the year's view. Expert one said yes I was able to figure out that you could go to the next month
by swiping left. Expert 2 also was asked the same question and his response was no the swipe
left feature was not so, apparent at first.

So, initially going to months view seemed to be the only option. Expert 3 said yes I did not need
to go to the year view however initially I was not very sure how to go to the next month and I
needed some time to figure it out. Expert 4 said yes I was able to navigate to the next month
without going to the months view however I feel that the transition could be made more apparent
by using a next or a forward button in place of the swipe mechanism being currently used.

So, in response to this particular question asked the experts had different opinions along with
some suggestions.
(Refer Slide Time: 33:38)

Next question asked was where the events listed clearly visible in the months view. Expert 1 said
no I felt that the font size could have been increased I noticed that not all events were shown in
the month. Expert 2 said no not all the events were listed only first 3 in the chronological order
were visible from day wise view. Expert 3 said the first few 3 events of each day could be seen
clearly however their timings had not been given.
And expert 4 said yes the events were clearly visible the events were also colour coded which
gave a rough overview of the kind and number of the events scheduled on a particular day. Again
here majority disagreed that they were clearly visible only one agreed. So, that is a very
interesting finding.
(Refer Slide Time: 34:34)

Third question asked was where are you able to determine the day with the least number of
events effectively through the month's view. Expert once said yes the month's view gave a good
idea of which day would be relatively free without the need to see the events in each day of the
week. Expert 2 also said yes but in my case I choose the day with only one event. Expert 3 again
yes an overview of each day schedule was visible with which I could make out the day with list
events scheduled.

And expert 4 also conquered that yes task headings for the tasks that needed to be performed on
a particular day were clearly specified this allowed me to efficiently determine the days with the
least number of events. So, all agreed in this particular response.
(Refer Slide Time: 35:25)
Next question were you able to decide a convenient time to meet your friend which does not
clash with the other events in the day. Note that all the questions are related to the interface level
tasks and each question has one to one correspondence to the tasks that need to be performed at
the interface level to achieve the objective. So, in response to this question expert 1 said yes after
viewing the events in the day with least number of events I was able to decide convenient time
the events being displayed in the sorted order of time helped.

So, some feature that helped the expert was also mentioned by the expert. Expert 2 said yes I
choose 12 hours to 16 hour slot on 18th April as it had the least number of events. Expert 3 said
yes I could see the timings of all events on that day and decide an appropriate time accordingly.
Expert 4 also said yes I could easily decide a convenient time to meet with my friend on a given
day the events scheduled on a given day were clearly specified and were sorted by time.

So, the same feature is highlighted by this expert as well which is helpful this allowed me to
efficiently decide a convenient time to meet with my friend. So, here again everybody conquered
with the view that they were able to decide a convenient time without any problem.
(Refer Slide Time: 37:01)
Let us see one more use case you want to change the theme of the calendar with some different
background image. So, if this is the use case then what are the interface level tasks. Click on the
figure icon click or select by some means on the figure icon which is labeled as theme select the
theme that you wish to apply. So, these are the interface level tasks.
(Video Starts: 37:34)

Let us quickly see the video on how it can be achieved so here the theme option is selected then
the themes appeared and then a particular theme is used and the theme is applied.
(Video Ends: 37:47)
(Refer Slide Time: 37:48)
So, the questions that were asked were you able to set theme correctly. Expert 1 said yes the
icons were labeled appropriately rest of the procedure was simple. Expert 2 said yes I could
easily set that theme. Expert 3 also concurred yes I applied the theme without any problems. So,
is expert 4 who said yes I could easily apply the theme. So, nobody faced any issue. Apart from
these specific questions some general questions were also asked to the experts.
(Refer Slide Time: 38:22)

For example was there any component in the interface which you could not understand unrelated
to any use case this is a general question. Expert one said no I was able to understand all the
components of the interface as they have clear functions. Expert 2 said most of the things were
fairly easy to grasp other than the year view where the months in a year were displayed. The
swiping action though was not apparent at first but it is fairly easy to grasp.

Expert 3 said the swipe method to change to adjacent months and years was not understandable
at first also changing to your view from month view by clicking on the year was not clearly
visible. Editing reminder was also not very clear at first however when I used the app for some
time I was able to understand each component. So, initially those were problematic as per expert
3 but once a user gets familiar there are no issues.

Expert 4 said I was able to understand all the components in the interface for the large part the
interface was intuitive and easy to use and the functions that were performed by individual
components were clear that is the view of expert 4.
(Refer Slide Time: 39:47)

Another general question asked was sufficient feedback provided indicating that intended actions
was or were performed successfully or unsuccessfully. Expert one said yes the feedback was
provided after each action instantly I was also able to see the updates in the application correctly
after the action. Expert 2 said yes feedback was provided showing updated deleted and saved
reminder banners in case of setting theme the theme was applied to the background.
Expert 3 also said yes feedback was given wherever required whenever a reminder was saved
edited or deleted a banner confirming the same was shown for other actions too the changes
caused by the actions were visible to the user. Expert 4 also conquered that sufficient feedback
was provided after the intended action was performed. For instance whenever I added deleted or
updated a reminder feedback related to the action was shown in a green prompt this allowed me
to easily keep track of what was going on. So, everybody agreed with the feedback.
(Refer Slide Time: 41:05)

Another general question was the interface in accordance with the conventions of the real world
applications as per their understanding. Expert one said yes the interface was in accordance with
the real world conventions the icons used and their colour followed the conventions. The
positioning of the buttons also was in accordance it was similar to most of the standard calendar
applications according to expert 1.

Expert 2 also said yes the days were listed appropriately with events the event view was as found
in different applications its adherence to common conventions makes it easier to use. Expert 3
said yes it was in accordance with the conventions delete and deadline buttons were shown with
the red danger colour file save button and confirmation of successful operations were shown in
green the plus sign was used to indicate adding reminders which according to the expert are in
accordance with the conventions.
Expert 4 said the interface was in accordance with conventions like the other experts conventions
of the real world applications. Since I had a prior experience using such applications I found the
given application very easy to use general conventions such as displaying deadlines using red
colour using the plus symbol in the button for deadline addition were followed which made the
application intuitive. So, everybody found that the conventions colour schemes icons that are
used are in accordance with the real world conventions.
(Refer Slide Time: 42:52)

Was the design appropriate for a calendar application that is a very broad and generic question
asked to the evaluators for their opinions response. Let us see how they responded. Expert one
said yes the design was appropriate and lighter background seemed good however the font size
on the month view could have been increased overall the design was neat clean and simple.
Expert 2 said yes the design follows a normal calendar be it in the month view year view it is as
one would find in a real calendar.

Expert 3 also said yes the design was appropriate with different views for a day month and year
making it convenient for the user to view the calendar at whatever level he wished. Expert 4 said
overall the design is appropriate for a calendar application certain aspects of the design such as
displaying the deadlines sorted by time giving feedback after actions made the application easy
to use however at some points the design was not very intuitive and improvements could be
made.
For instance in the view where deadlines are shown it is not very clear that I can click on the
deadline and update it because the deadline does not resemble a button. Similarly it was not
apparent that I can switch from month view to year view by clicking on the year because the year
did not resemble a button. So, some concerns were flagged by the expert. So, that is the response
rather these are the responses collected from the evaluators based on some use cases as well as
some open general questions.
(Refer Slide Time: 44:45)

Now from these we need to compile them together and identify the issues through some analysis
of the responses. So, the analysis reveals that each evaluator was able to perform the tasks
smoothly and achieve the required objective they were all satisfied with the overall experience.
The controls for essential actions such as addition deletion updation of events were provided
through buttons which reflected their intended purpose as revealed by the experts.

Whenever the user performed some action the app went through visible changes the feedback
was provided by the app to the user whenever the user added edited or deleted reminder.
Although errors were made by the evaluators at some point they were able to recover from the
error. One evaluator faced an error when he mistakenly deleted the reminder and had to go
through the process of adding the reminder again. It would be better if we could show a
confirmation prompt before saving or deleting a reminder. So, here some refinement in design is
required to address the constant raised by the evaluator.

The interface is similar to most of the other calendar applications at some points the steps to
achieve the desired functionality were not apparent but the evaluators experience with other
similar applications guided them. So, there is a potential point of concern where things are not
very intuitive and it expects the user to have some prior knowledge of using similar systems. For
novice or intermittent users probably such modifications are required for expert users the design
is all right.
(Refer Slide Time: 46:38)

So, at the level of functionality if we analyze the responses provided by the evaluators we can
find out several things. Navigating between various months and years in this case what we found
out through the evaluation is that the procedure to go for to the year view by clicking on the
current year is not apparent to some users. So, this is a point of concern. The swiping method to
go to the next month in the month view and the next year in the year view was difficult to find
for some users.

Once in the year view one can then go to the desired month by simply clicking on it which is
natural. So, there is no issue with that.
(Refer Slide Time: 47:30)
Viewing the events of a specific day the procedure to view the events of a specific day is quite
intuitive and clear as revealed by the responses by simply clicking on the day in the month view
we can view all events of the day which is apparent to the users. These events are sorted in order
of their start time further clearly labeled buttons give the user the option of seeing a particular
type of event timetable deadline or meeting each type of event is assigned its own colour.

So, the user can easily make out the type by looking at the event. These are some positive sides
of the design.
(Refer Slide Time: 48:07)
Regarding add edit delete events the plus button for adding events gives the user a clear
indication of its purpose as revealed by the responses. The procedure for editing deleting events
though is not very obvious this is one point of concern, users did not feel confident that clicking
on the event would enable them to perform those operations. So, that is another point of concern
that the users are not very confident.

Once in that edit reminder view users can easily save the events with appropriate details it would
be better to ask for confirmation before saving changes to handle errors. So, this is another point
of concern.
(Refer Slide Time: 48:47)

Regarding set theme functionality what the responses reveal is that the button to set the theme is
clearly visible in the main view and is well labeled in the next step the user can easily select the
desired theme the process is fairly simple for a layman user that is what the responses by the
evaluators reveal regarding this particular functionality. So, as you can see we started with
building the prototype we use the Figma tool to build the different views.

These views are built keeping in mind that the users are going to see the system in this way and
they are going to use the system with interaction in this way. Once the design is represented with
the prototype we set out to evaluate it through cognitive walkthrough for that we have created 4
use cases ask the evaluators to perform those cases perform the interface level tasks to achieve
those objectives mentioned in the use cases.

And while they perform those interface level tasks the problems they faced we tried to extract
those problems in with the help of a set of questions that were posed to the evaluators. So, their
responses gave us some idea of the issues that are faced by them which are likely to have
implications for usability of the interface. So, those issues we have identified during the analysis
phase also we identified some issues by posing some broad generic questions unrelated to the use
cases.

And those also revealed some positive and negative sides with respect to usability of the
proposed design. At the end when we compile the responses together and analyzed it we
identified the positive sides of the design and we also identified some issues that needs to be
addressed. So, in the design prototype evaluate cycle. So, once we identify issues after the
evaluation phase we refine the design by going to the design stage again and then prototype it
again get it evaluated as discussed in the earlier lecture.

So, in this lecture we have seen one such iteration. In continuation of this in the next part of this
lecture we will get to see how to prototype and evaluate heuristically a design. I hope you
enjoyed the material understood the concepts that we tried to learn here looking forward to
meeting in the next lecture, thank you and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Lecture: 19
Case Study on Prototype Evaluation - II

Hello and welcome to the NPTEL MOOC’s course on design and implementation of human
computer interfaces. We will continue our discussion on Prototype building and evaluation that is
lecture number 17. So, in the previous lecture we have discussed about how to build a prototype
and how to get it evaluated with cognitive walkthrough. So, there we talked about one case that
is building a calendar application or calendar app.
(Refer Slide Time: 01:14)

So, just to recap we are interested in building a calendar app which is primarily meant to be used
by students to manage their academic activities.
(Refer Slide Time: 01:23)
And we have already seen the different functions that have been identified as part of requirement
gathering phase which are to be supported by the app. Now the functional hierarchies shown here
so, as you can see there are 4 top level functions display calendar, set reminders, set background
and synchronize and there are some functions like display month, display days display specific
date.

Then create reminders, edit reminders, delete reminders, set theme, reset theme and attach
account remove account among them in our previous lecture we talked about ah creating a
prototype for supporting the 3 top level functions set background set reminders and Display
calendar. Same thing we will do here we will talk about building a prototype for this primarily
these 3 top level functions as well as getting it evaluated.

However this time we will talk about evaluation using a different evaluation method that is
heuristic evaluation.
(Refer Slide Time: 02:41)
So, the main concern here is building a prototype that supports the functions which are part of
the functional hierarchy and getting it evaluated with experts using heuristic evaluation method.
(Refer Slide Time: 02:55)

So, the Prototype that we are going to talk about is a medium fidelity vertical prototype however
vertical prototype as you can recollect is not mandatory. So, primarily we will be focusing on the
different interfaces that are part of different stages of the Prototype and the Prototype has been
built with the figma tool which we use to build our earlier prototype as well as discussed in the
previous lecture.
(Refer Slide Time: 03:31)
Now the Prototype has this month view specific date view, year view, background view where
background can be changed dark background custom background then other views like deadline
views timetable view scheduled of a day that view. So, all these things are supported which are
results of the analysis of the functional hierarchy that we have just seen.
(Refer Slide Time: 04:05)

Let us see the views although this prototype is designed as a vertical prototype to support screen
transitions. We can think of it as horizontal prototype where we will focus primarily only on the
interfaces for specific views and then we will evaluate it using heuristic evaluation. Let us start
with the year view. So, if we want to get a year view we can see such an interface where the year
is mentioned here.

And then the months are mentioned on the top and if I select a specific month the current month
the days are shown here and the year can be changed. To change the year this right hand interface
appears where we can change the year.
(Refer Slide Time: 05:03)

The month view as we have just mentioned in the year view itself the month view is available
this is for the current month it can be for other months as well. So, we have to select the month
from the top menu.
(Refer Slide Time: 05:21)
In this month view we can also have specific dates and if we choose a date like here then for this
date we get to see the events that are scheduled on that day likes shown here in this type of
interface. So, for 12th July that specific date in the year 2022 these are the events that are
scheduled CS544 a course CS361 another course 3 4 5 another course assignment submission
some other activities.

So, these are part of that activities and events that can be viewed if we select a date. So, that is
the interface for specific date.
(Refer Slide Time: 06:17)
Then we can set events for a date. So, if we choose a date then this interface appears and below
this interface there is this button and if we select this button then the other interface on the right
hand side appears where we can mention the event name start time of the event end time of the
event and some brief description which is optional. And as you can see below we can save it
save this event or we can delete also if we think that that is not necessary to save.
(Refer Slide Time: 06:54)

Then comes the background view. In this view we start with the year view where we get to see
the days of the year and below that interface there is this set background option. So, once we
select it the next interface appears in the middle where we can have either dark theme or some
other theme that we can select from the device. If we choose the dark theme then that is a pre
stored theme and this top interface appears with the background changed to the dark colour.

If we make the other selection that is select from device then some other background themes may
appear depending on what are stored in the device and we can choose from here. Like if we
select this particular theme then this next interface shows the theme applied on the year view as
shown in this interface.
(Refer Slide Time: 08:10)
For deadline view we have this deadline view option here once it is selected it shows all the
deadlines for a specific date which can be chosen from here.
(Refer Slide Time: 08:28)

Similarly to see the timetable we have this time table view for a specific date that we can select
from here and the timetable for the day date is shown in this interface on the right hand side.
Here you can see additional information along with the timetable.
(Refer Slide Time: 08:51)
Another option present there is schedule view. So, this view is meant for schedule of the month
like 12 July 13 July 14th July. So, what are the schedules it will show you the schedule for the
month in this type of interface where it can be scrolled up or down.
(Refer Slide Time: 09:19)

Another feature of the interface although that is not exactly part of the functional requirement
hierarchy. Functional hierarchy is a dialog box that is added to prevent errors. So, if there is
something needs to be saved some changes have been made or you want to close the app before
that this type of confirmatory messages appear where you can confirm or decline to confirm the
changes. So, that is all about the prototype.
(Refer Slide Time: 10:07)

Now let us evaluate this prototype with heuristic evaluation.

(Refer Slide Time: 10:20)

So, in order to perform heuristic evaluation we will follow the 10 heuristics by Nielsen just to
recap. So, these 10 heuristics are visibility of system status, match between the system and the
real world, user control and freedom, consistency and standards, error prevention, recognition
rather than recall, flexibility and efficiency of use, aesthetic and minimalist design help users
recognize diagnose and recover from errors help and documentation.
So, these are the things that are expected to be there on the interface the system status should be
visible to the user there should be a match between the system and the real world user should
have control and freedom for operations. The system should follow consistency and standards it
should support error prevention mechanisms, it should support recognition rather than recall it
should provide the user flexibility and efficiency of use.

It should have aesthetic and minimalist design, it should help users recognize diagnose and
recover from errors and finally it should have help and documentation support. These are 10
things that needs to be checked for ensuring that the interface is usable.
(Refer Slide Time: 11:50)

Now from the designer's point of view let us see what can be the view with respect to these 10
heuristics. First is visibility of system status the system should keep users informed about what is
going on through appropriate feedback within a reasonable time gap. According to the designer
the users in this system can distinguish and easily find today's date and month as it is highlighted
with noticeable colour dates with deadlines are also highlighted in red colour.

Changing the months is quite intuitive as dragging left towards text to the previous month and
dragging right towards text to the next month and also on changing the month we can see the
change in the view in real time. While selecting the year the up down buttons increase visibility
and give users feedback on the change of the year. New, events for any particular date can be just
created by tapping on the; date to which event has to be added.

Moreover in the specific date view for any date the events that have some deadline is when
created has a star symbol which helps to see the user the change taking place. In timetable view
the user can see the current time in a red line thus helping in an easy preview of current status.
So, these are what the designer thinks about conforming to the first heuristic that is visibility of
system status.
(Refer Slide Time: 13:27)

Next heuristic is match between system and the real world. What it means is that the system
should use users Daily Language with words phrases and Concepts familiar to the user rather
than any specific system oriented terms and what the designer thinks about this particular design
similar layout to real life physical calendar red colour to indicate deadlines and other cautionary
instructions like delete and reset.

Green colour to indicate instruction like save for success a star beside deadlines in dead view to
indicate the importance plus sign to add a new event. So, these are the things that are added to
ensure that there is a match between system and real world as per the designer.
(Refer Slide Time: 14:15)
Next is user control and freedom. So, this is the third heuristic users often use functions by
mistake and may need a clearly marked emergency exit to leave The unwanted state without
having to go through an extended process of rewriting the change that is what is required to
ensure this third heuristic is satisfied. So, what the designer thinks about the design with respect
to this third heuristic different themes and views are there in the system allowing user to choose
according to their preference. So, this implies freedom.

Option to edit and make changes to deadlines implies control. Prompt message before saving
allowing users to rectify the errors or to discard them completely emergency exit. So, according
to the designer the design supports this third heuristic as well.
(Refer Slide Time: 15:17)
The 4th heuristic is consistency and standards what it says is that users should have the
experience of not having to wonder whether different word situations or actions mean the same
thing or different things. In the design for this calendar app what the designer thinks with respect
to the 4th heuristic. In the design users can see the timetable of classes in timetable view and
specific date View and in both the types of views consistency in colour coding for different
courses is maintained that means it supports consistency.

Even the overall UI also maintains this colour consistency. So, consistency is supported however
nothing is mentioned about following the standard.
(Refer Slide Time: 16:03)
Error prevention is the fifth heuristic, even better than good error messages is a careful design
that prevents a problem from occurring in the first place. What the designer thinks a prompt is
added for confirmation when there is any change in the view whether it is change in background
theme or addition or deletion of any events for any specific date which helps in error prevention.
So, designer thinks that the prompt feature or the dialog box that we have seen is supporting this
heuristic.

Adding time while creating an event is handled by another view that is solely just designed to
take correct time and correct format thus minimizing human error. Again the designer thinks
because of the particular design error prevention is possible and this particular heuristic is
satisfied.
(Refer Slide Time: 17:06)
Next heuristic is recognition rather than recall which implies that the design should minimize
users memory load by making objects action and options visible. In the design adding events
saving events deleting events and changing views all have well known and heavily used icons to
recognize the feature according to the designer. Using any feature in the application does not
need recall for the user as the function names are quite self explanatory again according to the
designer.

While creating an event the user can see some text in the input fields describing what should be
entered in those input fields which according to the designer is an effective measure for
recognition for the user. So, the designer thinks because of this particular way of Designing the
design supports recognition rather than recall.
(Refer Slide Time: 18:18)
Next is flexibility and efficiency of use for different user categories namely novice intermittent
and expert users. In this design since the application is quite simple in nature as perceived by the
designer hence from novice to expert users all have the same simple interface according to the
designer. So, designer thinks the interface is quite simple. So, it does not matter whether the user
is novice or expert all will be able to use it. So, it provides flexibility and efficiency of use.
(Refer Slide Time: 18:47)

Next is aesthetic and minimalist design which states that dialogues should not contain
information that is irrelevant or rarely needed. Different types of views have the most appropriate
amount of information that is required all these qualifications are made by the designer that
whether the information is most appropriate or not again simple UI in all types of views does not
intimidate the users and hence restrict the users from abandoning the application.

So, this is what the designer thinks that the amount of information is appropriate not intimidating
and does not lead to rejection of the application.
(Refer Slide Time: 19:33)

By the user next heuristic is the design should help the users recognize diagnose and recover
from errors. In the design the calendar allows users to delete any already set events along with an
extra layer of protection prompt asking for confirmation. User can easily revert, the changes back
when needed. The designer feels so, while adding a deadline The View has a star along with it if
this is not the case then it helps the user to recognize that something might have gone wrong.

So, again there is some indication regarding erroneous situations and the designer thinks all these
design choices made the system help users recognize diagnose and recover from errors.
(Refer Slide Time: 20:27)
Finally help and documentation support for the design since the calendar mimics a basic calendar
most of the functionalities can be naturally understood by the user and no documentation is
required as such which the designer feels. In other words there is no documentation provided in
the design and the designer feels that is not required. Precise titles clearly indicate the
functionality.

So, the titles itself can be treated as documentation as per the designer and that those titles can be
used to help the users use the system. For several functionalities a small explanation is also
provided in the white space. So, that is not there for all the functionalities but for several
functionalities. So, that is one sort of documentation according to the designer. So, in summary
designer thinks that there are several design decisions made which indicates that the 10 heuristics
by Nielsen are supported in the design which in effect implies that the design is usable. Now let
us see whether that is indeed true with respect to some independent evaluation by experts.
(Refer Slide Time: 21:47)
So, let us assume that heuristic Evolution has taken place just to quickly recap in heuristic
evaluation we have a team of 3 to 5 expert users who are domain experts. They are asked t check
the interfaces and see whether the interface design satisfies the heuristics and they are asked to
prepare reports. Each evaluator prepare reports and at the end those are compiled to identify
points of concerns.

Let us assume that we have followed such a approach such an approach and let us discuss the
results. Suppose there is one evaluator who produced a report which we are terming as
evaluation one. So, the evaluator found that the visibility of system status is not satisfied. The
evaluator feels that the system status is not visible for any instances. For example when I set a
new event the system does not show any status whether it is a success or a failure.

So, the view of the evaluator is that system status is not visible. Match between system and real
world that is satisfied all the symbols words used in the system are matched to the real world
these are commonly used word and symbol. So, the second heuristic is satisfied according to the
first evaluator. User control and freedom not satisfied there are no undue and redo features for
some actions consistency and standards not satisfied the system is not consistent with the various
calendar applications.
The deadline view timetable View and the schedule view buttons are placed in the places which
is not common in the calendar apps. A separate menu bar should be provided to select these
options. So, according to the evaluator these two heuristics are not satisfied.
(Refer Slide Time: 23:53)

But the designs supports error prevention the save and delete buttons in the event creation page
are far enough to select the proper option. When I try to delete a particular event or I try to reset
the theme a pop-up comes up to confirm if I really want to do that. So, these according to the
evaluator help preventing error. Evaluator also feels that recognition rather than recall is
supported in this design.

While creating an event I can see some text in input Fields describing what should be entered in
those input fields which is an effective measure for recognition for the user.
(Refer Slide Time: 24:32)
Regarding flexibility and efficiency of use the evaluator feels it is supported since the application
is quite simple in nature hence from novice to expert users all have the same simple interface.
So, the heuristic is supported aesthetic and minimalist design heuristic is also supported only
relevant details are shown in the system no irrelevant details are asked or displayed in the
system.
(Refer Slide Time: 24:58)

Help users recognize diagnose and recover from errors not supported according to the evaluator
while adding an event if the event fails to add events it does not show the reason making it
difficult to diagnose it. Help and documentation is also not supported no help and documentation
is observed. So, these are the opinions according to evaluator one. Let us see another evaluation
report let us call it evaluation two.
(Refer Slide Time: 25:30)

Here also according to the second evaluator visibility of system strategies not supported while
adding event or uploading custom background the system state is not visible. Match between
system and real world supported used red colour to indicate deadlines and other cautionary
instructions like delete and reset. Used green colour to indicate instructions like save user control
and freedom according to this evaluator it is supported when delete option is selected a prompt
pops up to undo it once event is created it can be edited.

Regarding consistency and standards not supported the menus are placed in the odd place
according to the evaluator.
(Refer Slide Time: 26:20)
Error prevention supported pop-ups appears to prevent errors while entering date time for the
events date time interface menu pops up to enter date time in correct format. Recognition rather
than recall supported adding events, saving events, deleting events and changing views all app
well known icons to recognize the feature.
(Refer Slide Time: 26:44)

Flexibility and efficiency of use supported. The system is flexible for both novice and
experienced users, aesthetic and minimalist design supported there are not any dialogue that
contain information which is irrelevant or rarely needed. So, this is the view of the evaluator.
(Refer Slide Time: 27:04)
Help users recognize diagnose and recover from errors not supported. While adding custom
background if some PNG image is selected the background is not loaded and the information is
insufficient that means no information is displayed for not applying the change making it hard to
diagnose. Now information is displayed when event creation fails help and documentation is also
not supported no help and documentation is found in the prototype. So, this is the view of
evaluator 2.
(Refer Slide Time: 27:44)
Let us look at the view of a third evaluator. Visibility of system status not supported does not
show any system status while creating editing or deleting events. Match between system and real
world supported add edit delete icons are used as it is used in other applications.
(Refer Slide Time: 28:03)

User control and freedom supported users have the control over the created events, consistency
and standards not supported the set background button looks bigger than other buttons.
(Refer Slide Time: 28:20)

Error prevention supported used pop-ups to prevent functions like delete, reset and replace event
data or rather during edit bit of operations pop-ups were there to get confirmation. So, that helps
in error prevention. Recognition rather than recall supported the functionalities could be
recognized by the way it is presented.
(Refer Slide Time: 28:54)

Flexibility and efficiency of use supported. The system is very simple and can be used by both
novice and expert users. Aesthetic and minimalist design supported only relevant details are
given while viewing dates events and creating new events.
(Refer Slide Time: 29:12)

Help users recognize diagnose and recover from errors, not supported. While creating event if
some information is not given the event is not created however this reason is not displayed to the
user. Help and documentation not supported no help and documentation there. So, we have seen
different opinions rather different responses to the evaluation by different evaluators. At the end
we are supposed to compile them together and identify common points of concerns which will
eventually lead to refinement of the design.
(Refer Slide Time: 29:56)

So, if we summarize the evaluations what we see is that in case of the first heuristic visibility of
system status evaluator one things it is not supported two things not supported 3 also things not
supported. Second one match between system and real world all 3 things supported. Third one
user control and freedom one thing not supported 2 and 3 things think there it is supported.
Consistency and standards none of the evaluated things it is supported.

Error prevention recognition rather than recall, flexibility of use, aesthetic and minimalist design
all the evaluators things these 4 are supported in the proposed design represented in the form of
prototype. Whereas the remaining two help users recognize diagnose and recover from errors and
help and documentation support all the evaluators think these two are not supported. So, only in
case of user control and freedom there is a difference of opinion between the evaluators.

Otherwise in all the other cases all the other heuristics, 9 heuristics the opinion is same. Now
here we can say that because majority thinks it is supported out of 3, 2 things it is supported for
this particular third heuristic user control and freedom we may consider it to be supported
whereas for heuristic 1, heuristic 4, 9 and 10 these 4 heuristics are not supported. So, we have to
do something in the design to support these heuristics.
(Refer Slide Time: 31:57)

We can summarize as the evaluators noticed that no System state was visible a message can be
shown once an event is created edited deleted and background is applied. So, that is what can be
done to refine the design. Evaluator one pointed out that there is a need for undo and redo. Undo
and redo operation can be incorporated by adding undo redo for the last activity. However we
have edit option for created events.

According to the evaluators the buttons for the view are not expected in the front page first
interface this can be added in a separate maneuver. So, these are some suggestions that can be
used to refine the design. So, that the heuristics are supported while creating events and setting
backgrounds the reason of any error can be displayed as an error message. Since it mimics a
basic calendar most of the functionalities can be naturally understood by the user and no
documentation is required as such.

So, although that particular heuristic is not supported all the evaluators pointed out that the
interface is simple. So, documentation may not really be required. So, it does not matter whether
the; particular heuristic is supported and documentation is added or not because this particular
application is very simple. So, at the end what we get is some suggestions first status check of
the quality of the design with respect to the heuristics and then based on the responses we can
figure out whether we need to make improvements or it is not really necessary.

Even if the heuristic is not supported like in the case of help and documentation. So, that is all
for this topic. So, in this lecture we have learned about how to create prototype how it looks and
how we can apply cognitive work through or heuristic evaluation to evaluate the prototypes what
are the steps what reports we get how to compile them and how to draw conclusion. Based on
this conclusion we may go for refinement of design which is followed by again prototyping and
evaluation or we may say that there are no further issues.

So, we can freeze the design and go to the code design. I hope you enjoyed the content of this
lecture looking forward to meet you in the next lecture, thank you and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology, Guwahati

Module No # 05
Lecture No # 20
Basics of System Design

Hello and welcome to the NTPEL MOOC’s course on design and implementation of human
computer interfaces lecture number18 where we will start our discussion on system design.
So before we start we will quickly recap the interactive system development life cycle and
then we will understand where we what we discussed and where we are at present. Then from
there we will forward the discussion.
(Refer Slide Time: 01:17)

So if you recollect in the interactive system development life cycle there are several stages
some of the stages from some cycles. So; essentially the lifecycle contains iterative
components as well as some non-iterative components. So we started our discussion with the
requirement gathering analysis and specification stage. Where; we learned about how to
create an SRS document or software requirement specification document.

In the document we can include both functional requirement as well as non-functional

requirements. After the requirement gathering stage we have a cycle which is design
prototype and evaluation cycle. So there are 3 soft stages involved here one is the design
stage one is the prototyping stage and the third one is the evaluation of the prototyping that
stage.
Now if you may recollect here what we mentioned is that design actually refers to 2 thing one
is interface design and system design or code design. So we have so far discussed interface
design and this cycle refers to design of the interface. So once we have some design ideas
then we create a prototype get it evaluated and refine our design based on the evaluation
results and so on the cycle continuing still we arrive at some stable interface design.

Also design during the discussion we have learned about how to go for designing an interface
particularly we learned about design guidelines. In prototyping we learned how to make
different prototypes ranging from low cost and affordable prototypes to high cost system
oriented prototypes. So there are broadly 3 types low fidelity, medium fidelity and high
fidelity.

So learned about these different prototypes and how to use them also we learned in details
about different prototype evaluation techniques. We learned about to broad techniques one is
evaluation with experts and evaluation with users with the objective of getting the evaluation
done rapidly and without much cost. So once we arrive at some stable design then we go for
system design where we design the components of the system in modules and some modules.

Now then that is followed by implementation of the design in the coding and implementation
stage then comes testing of the code that is another stage. A very important stage so after
testing we get an executable system this is followed a special stage called empirical study
where we test the system or usability. So getting only an executable system is not the goal our
overall goal is to get a usable system.

So we have to conduct empirical study stage now occasionally it may happen that in
empirical study we found some usability problems. So we need to refine our interface designs
and the subsequence stages we need to carry out. So there is a loop from here but it is very
infrequent unlike the design prototype evaluate cycle. So after we arrive at an executable and
usable system we go for deployment followed by maintenance stage that is our overall
interactive system development life cycle.

Now in this life cycle we have so far covered requirement gathering stage and interface
design stage. In this lecture we are going to take the discussion forward. So we have covered
under interface design stage how to design the interface create prototype as well as evaluate
the prototype. So entire cycle we have covered for interface design and then in this lecture
onwards we will take it forward.
(Refer Slide Time: 05:54)

So we have learned about interface design issues and guidelines in the earlier lectures. And
now we are going to discuss once we design an interface how to convert the interface design
to the design of a system specifically software. Note that here in this entire course wherever
we use the term system we primarily refer to the software. So we are going to talk about
design of the system which is based on the design of the interface that we arrive at executing
the design prototype evaluate cycle.
(Refer Slide Time: 06:46)

Now the design prototype evaluate cycle as I mentioned primarily caters to the interface
design aspect of the lifecycle. Once we get a stable design so the design is stabilized that
means no further usability issues are discovered or in significant number those issues are
discovered after the evaluation stage. So no further iteration of the cycle is done and we reach
at a stable design and then we focus on converting that stable interface design to the design of
a system.
(Refer Slide Time: 07:34)

Now when we are taking of design of a system the same 2 issues come back what are those
issues? One is where to start? And the second is how to represent? In case of interface design
we encounter the same issues and if you recollect we discuss that to answer the question
where to start the interface design process we can start with design guidelines. Also our
intuition experience this can be a starting point and we say how to represent interface design
we talked about prototypes to express the design.

So in case of interface design prototypes can be used to represent the design or essentially
that is the design language. So in case of system design this same issues are there where to
start and how to represent?
(Refer Slide Time: 08:35)
 core objective

Now the core objective of a system design is to make the final code manageable what this
means? So when we are saying that we need to go for design of an interface we are primarily
concerned about what the user perceives what the user gets to see a interact with or gets to
perceive an interact with. So there our primary concern is our user now when we are talking
of system design our primary concern is implementation that is we need to built a software
for that we need to write a code and that code how to write it in a way such that it is
manageable.

Why that issue is important? Generally codes return in a team for complex system, typically
complex systems require writing of hundred or thousands of lines of code and if single
persons are interested with this task then it becomes very difficult. And there is possibility of
huge number of errors. To address this problems what happens is that? The code is divided
into units and different teams are entrusted to develop the units separately and then finally
combine them together to create a whole system.

So that is typically what is called a modular design to manage the overall development
process smoothly. So when we are going to designing the system we should keep that in mind
and try to design it in a modular way such that so that when we convert it to code the modular
development is done or is possible. So our main objective in system design is to help in
managing the code development well and help in making the code manageable. So let us
begin with the first question where to start the system design process?
(Refer Slide Time: 10:52)
Now earlier in the requirement gathering stage we saw the output is SRS or software
requirement specification document. Let us begin with the question where to start so we start
with the SRS document or software requirement specification document. If you recollect this
is the outcome of the requirement gathering analysis and specification and we start our
system design with this document.

Now when we are going for designing our system there are broadly 2 phases what are those 2
phases? One is the preliminary design where we go for designing a system at a very high
level. So this is essentially a high level design of the whole system and then there comes the
detailed design phase. Now in this phase what happens is that? We go to the minute detail of
the system now this is also known as modules specification document.

So when we are creating a detailed specification document this is also called module
specification design document. So in the preliminary stage we design at a high level at the
modular level and in detail design stage we go to minute details of the modules.
(Refer Slide Time: 12:36)
Let us begin with the high level design phase let us try to understand what we do at this
phase. So at this level as we earlier mentioned that our whole objective is to make the code
manageable. For that we need to go for a modular design approach where we can divide the
big problem into smaller modules which are easier to manage rather than trying to manage
the whole problem at a time.

So at the high level design we start with identification of modules also at this level what we
do is? We try to find out control relationships between the modules and at this level we
provide definition of interfaces between modules. So modules need to interact with each
other how they interact what kind of interfaces should be there that definition also you
provide at this phase of system design that is high level design phase.
(Refer Slide Time: 13:49)
The next question then is once we manage to come with a design how should; we represent it.
So that it becomes easier to understand by others who are going to implement the design. So
what language to use there are actually many languages which we can take request to
implement the system design idea.
(Refer Slide Time: 14:23)

Let us see one example later on we will see another example so this example actually shows
one particular language used to present a high level system design. This is called DFT or data
flow diagram as you can see here in this example so essentially what is happening is that? We
are using graphical notations to express the design idea so it is a graphical language to
represent design.

There are certain conventions and standards used like any language that we will learn later
but here I want to just give you some idea about the idea about DFT or the idea of the
graphical languages and how it can be used to express a design. Suppose we are asked to
design and web based newspaper application. So essentially we are looking for designing
software which is a newspaper application which is based on an web.

So a user can get the newspaper through a browser so what happens is that somebody as
designed this system and this is a top level view of the deign where this entire circle which
contains this text web based newspaper is the representation of the system. Whole system is
represented with this circle here then there are some rectangles used which are representing
who all can interact with the systems who all are the stake holders for this system.
For example there can be administrator there can be a special type of user or there can be
some other type of users. Also it shows how these different stakeholders who are users of the
system can interact with the system in the form of labeled arrows like the one shown here. So
this arrow is there with a level which shows what data flows and in which deduction it flows.
For example administrator can interact with the system in different ways by providing news
details user details, content details several information account details etc.,

A special type of user marked as user share can interact with the system with general
discussion providing feedback addition of comments and account details. That is how the
design is (())(18:00) and then this particular notation are used to represent the design.
Similarly other user can view or search so the other user can interact only with these 2 ways
other interaction mechanisms are not available to the other users.

In that way we can indicate who are the user how they interact and what they interact so that
is the graphical language. Now of course when we are representing the whole system with a
single circle that does not convey anything at a very high level it says that there is the system
and there are these users and those users can interact with the system in so and so manner.
But then what is inside the system?

What is the design of the system? Same language DFD can be used to represent the lower
levels of the design as well although still at a very high level.
(Refer Slide Time: 19:08)

For example that circle which represented the whole software can further be expanded in the
second level will learn about this level idea of levels and all these things in a later lecture
exclusively on DFD. But right now just to give an idea so that software contents several
modules as represented with these symbols one is faculty login module, one is faculty main
menu, one is conduct examination menu.

So this is of course not the design of the earlier system but this is design of some other
system which is related class room teaching. There is another module on faculty course
management so these particular symbols are used to represent modules or processes and then
there are symbols to represent some databases. Like the symbols used here rectangles this
represents several databases that are used by the system.

So essentially this is a second level representation top level will represent the whole system
in the form of a single circle as shown in the previous slide previous part of the lecture. And
if we want to express more details of the design in terms of the modules that are part of this
whole software then we can go for the next level of design using DFD where we can show
the modules.

Now these processes will require some data to operate on so that database also requires
something to represent so we can represent it using the rectangles as shown here. Then
interaction between modules again in the form of leveled arrows to show the direction and
content of interaction. So all this things can be represented with DFD we can go to even
lower levels, so one of the modules from the second level can be broken down into some
modules and shown as separate level of the DFD for that particular like one third level DFD
is shown for the modules shown in the earlier design of the system.

Now it may be noted that conventions used are the same like to represent process we use this
circle this notation to represent databases we use this notation leveled arrows. But this whole
thing here is actually representing one of the modules at the higher level. So one module is
divided into some module with interaction between them and the database they use and that is
that forms separate level of DFD.

We will learn about all these things in details in the later lecture so that is just to give you
some idea of just to express our design in the form of graphical language. Like DFD there are
other languages partly graphical languages are also there so later on we will learn about this
languages in more details. So that is about high level design note that in the high level design
that is where we are talking about modules and their interaction we are not telling how the
modules are implemented.

Instead we are simply saying that ok in the system there will be these many modules they will
interact with each other in this particular. In that direction and there will be some databases
which will provide data to the module and get data from the modules so on and so forth.
(Refer Slide Time: 23:45)

Now in the detailed design phase what we do? We go for detailed design of the modules and
sub modules that are part of the overall system. So here we identify data structures and
algorithms that are required for implementing different modules so that is the detailed design
phase. So that is in a nutshell what is system design so we have 2 phases of the design in the
first phase we go for designing the high level concepts in the form of modules and their
interaction.

And in the second phase we go for detailed design of the modules in terms of the data
structures and algorithms that they require to be implemented. So once we have a design
definitely the question comes whether this is a good design or bad design. So how do we
categorize whether some design is good or bad. For that we need to know what characterizes
are good design?
(Refer Slide Time: 24:48)
So let us see the characteristics that define a good design first thing is coverage. Now this
particular characteristic tells us that a good design should implement all the functionalities
that are specified in the SRS. So you have created a software requirement specification
document containing functionalities. When we are going for a system design the design will
be considered to be good if all the functionalities that are there in the SRS are part of the
design.

If we miss some functionalities then this is not a good design the second characteristics is
correctness that means a good design should be able to correctly implement all functionality
of SRS. Now here correctly means that it should be able to produce the desired output when a
specific output is given. So correct implementation of all functionalities is another hallmark
of good design third important characteristics is understandability what it means?

Any system design that you come up with a represent using some language should be, easily
understanding now this is very important. So the whole idea is that you divide the whole
problem into manageable smaller sub-problems in the form of modules and some modules.
So it is not necessary or generally it is not the practice that all the modules and sub modules
are implemented by the same team which designs the system.

It may happen and which is most often the case that the design is distributed to several teams
and they are asked to implement different modules and then finally those are combined
together. So whenever we are creating a design and expressing it with some language the
design should be easily understandable to people who are not part of the design. Otherwise it
will be very difficult to implement the design in a team.
So understandability is very essential characteristics of a good system design where
understandability means it should be understandable by other team members who are not the
part of design team.
(Refer Slide Time: 27: 58)

But maybe asked to implement it the fourth characteristic is efficiency this is another
important characteristic. The whole design should be efficient now here efficiency means that
the whole design should be made in a way such that it is possible to implement the design
idea with efficient usage of available resources. So a design should not require things that are
not available then that are not a good design.

So whenever we are going for designing something we should be aware of the resources
available and accordingly we should design so that those resources are used optimally. Fifth
characteristics is maintainability the design should be amenable to change so if there is some
change required after brainstorming over the design it should be easy to that without having
to recreate the whole design from scratch.

So we should be able to conceptualize and represent the design in a manner such that changes
can be performed at a local level without having to redo everything in the design. So those
are essential characteristics that define whether we can level a design as a good design or a
bad design. If this 5 characteristics are not there as per our evaluation of the design then;
there is a need to refine the design so that these 5 characteristics are maintained in the final
design.
So that gives us some idea of whether our design that we have come up with can be
considered to be a good design or a bad design. Now let us try to understand another
important concept in relation to design of a system.
(Refer Slide Time: 30:26)

Cohesion and coupling what it is and what are these concepts and how they are related to
good designs? As we have repeatedly said our goal is to come with the modular design so
that we can distribute the implementation work for faster turnaround time. So good software
design requires clean decomposition of the problems into modules this is very important we
should be able to very clearly and easily decompose the problem into sub problems or
modules that is not the only thing.

Also we should be able to neatly arrange the modules in the form of a hierarchy that is also
required. Now whether we will be able to do that? Whether we will be able to go for the
modular design or not depends on 2 properties of the design cohesion and coupling. So;
essentially modular design depends on cohesion and coupling.
(Refer Slide Time: 32:00)
So let us start with the idea of cohesion now cohesion typically is the property of one module.
Whenever we are trying to design a module it has a property of cohesion what this property
indicates? Several things determine the cohesiveness of a module and there are several types
of cohesion. One is logical cohesion that is if all the functions in the module perform similar
operations.

For example suppose there are several functions which are part of the error handling module
so essentially their objective is to deal with different types of errors. So all the functions are
performing error handling then we say that this error handling module is logically cohesive.
Then there is temporal cohesion that is if all the functions of a module should be performed
in the same time span.

For example whenever a system starts we have defined an initialization module so there are
several functions as part of the module and those functions initializes several maybe data
structures or storage elements databases. So all the functions are doing the initialization at the
same time span which; is at the beginning of starting of the operations of a system. If that is
the case then we say that the module in this case the initialization module is temporally
cohesive.

Then there is procedural functional cohesion which indicates or which happens when all
functions of a module are part of the same procedure or algorithm. Suppose there is a
deciding algorithm used in some image processing task image processing software. Now
decoding algorithm need not be implemented in the form of a single function instead we can
implement it as a group of functions all are part of the same module of decoding and they are
all representing the different part of the same decoding algorithm.

Then if such a situation exists then we say that particular module is functionally or
procedurally cohesive.
(Refer Slide Time: 34:45)

Then we have communication cohesion it happens when all functions refer to or update the
same data structure. As an example if a set of functions are there that are operating on a
linked list data structure. So that means they are referring to the same data structure as well as
updating the same database structure then those functions are said to having communication
cohesion property.

And finally we have sequential cohesion ouput from one element is input to the next element
of the module. For example the sequence of functions get input validate input and short input
if these 3 together form a module then the output of get input is fed as input to the validate
input function. Validated input output is fed to the short input function so then they are
sequentially cohesive module then that particular module is called sequentially cohesive
because the functions that are part of the module follow the sequential cohesion property.

So essentially this cohesion property what they say is that a module is a collection of
functions and how the functions behave in terms of input or communication between them or
execution, behavior. So those; behaviour of the functions in a module represent the cohesion
property of the module and there are 5 types of cohesion depending on how the functions
behave that is about the cohesion
(Refer Slide Time: 36:48)

Next is the concept of coupling now cohesion is property of the single module so the
functions that are part of the module coupling in contrast is the property between modules. So
when we say coupling we say that it is the property between 2 or more modules. Now there
are likewise there are different types of coupling possible one is data coupling what it says is
that? If 2 modules communicate through data item then we say that they are having data
coupling property.

For example passing an integer between 2 modules so if we are designing modules in a way
such that some integers need to passed between them then they are having data coupling
property. Then we have control coupling if data from 1 module is used to control the flow of
instruction in the other module then we say that there is this property of control coupling. For
example if there is a flag data which we said in one module and that is used to control the
flow of operations in some other module then there is a control coupling between these
modules.

Then we have content coupling if 2 modules share code then they are said to have content
coupling property. For example branch from one module leads to execution of coding in
another module. If that is there then we say that these 2 modules share the content coupling
property.
(Refer Slide Time: 38:49)
So to recollect we have these 2 important concepts which are nothing but properties of
modules one is cohesion which is a property of single module and one is coupling which is
property between modules. Now one important thing that we should note is that high
cohesion and low coupling leads to functionally independent modules. So our objective is to
have clean and neat the composition of the problem into modules.

And we should be able to represent them in a hierarchical manner now that is possible when
we have functionally independent modules and that is possible in turn when we have high
cohesion within modules and low coupling between modules. So essentially whether we are
able to achieve our goal of a very good modular design depends on whether we have been
able to design modules such that the modules have high cohesion and low coupling.

If that is satisfied then we will be able to go for a very nice modular design otherwise it will
not be high quality modular design. So our goal should be to have as little coupling as
possible and as high cohesion as per possible.
(Refer Slide Time: 40:35)
So with that we got some idea of what is the aim of system design what we need to know and
what we should be aware of? Now next task is to understand how we can go for designing
system. So what are the approaches available broadly there are 2 approaches. One of these
approaches is function oriented approaches. In this approach what we do when we go for
design of a system is that we use functions as basic abstraction.

So whole system is designed is based on functions if we are going for such a design then we
call it function oriented design approach. Now when we are using oriented design approach
to represent that design we rely on generally we rely on DFD or data flow diagram the
example that we have seen in the earlier part of this lecture. As I said on DFD we have
detailed discussion later.
(Refer Slide Time: 41:51)
The other broad approach for system design is called object oriented design. Here instead of
function the basic abstractions that we use are objects which are instantiation of a concept
called class. So in object oriented design approach we rely on objects as the basic abstraction
or basic unit and these objects are instantiations of concept called class. So that is the basic
idea on which the object oriented design approach works.

Here also we rely on some language to express the design typically we go for UML or unified
modeling language to represent the object oriented design or a system.
(Refer Slide Time: 43:05)

So in subsequent lectures we learn about both these approaches namely procedural approach
and DFD as well as object oriented design approach and UML to express those designs. And
we will learn those with case studies so that these become easier to understand and remember.
So with that we have come to the end of the lecture so in this lecture we will quickly review
what we covered?

So we started our discussion on how to for system design now we learnt what is the main idea
behind system design and what are the key concerns. So there are 2 concerns one is where to
start and how to represent where to start? Is basically; the SRS document at the end of
requirement specification stage that is our starting point. So our objective is to implement all
the functions and to represent we need to make use of different languages one example we
have seen graphical language called DFD and there are other languages as well.
Now design happen in 2 phases one is the high level design phase one is the detailed design
phase while going for design our mina objective is to go for modular design so that the code
is manageable. Now to ensure that we have to ensure that whatever design we have come up
with as high cohesion and low coupling. Cohesion and coupling concepts we have discussed
including different types of cohesion and different type of coupling.

And just to emphasize cohesive is the module property whereas coupling is a property
between modules and our objective is to have a design that supports high cohesion within a
module and low coupling between modules then only it will be possible to go for a very good
modular design otherwise our objective of modular design may be compromised. Then we
talked about 2 broad approaches to design one is function oriented approach other one is
objected oriented approach.

For function oriented approach we need to use DFD to express the design for object oriented
approach we go for UML to express the design. In the subsequent lectures we are going to
talk about these design approaches as well as the languages to express them in more details
with case studies for better understanding So that is all for this lecture hope you have enjoyed
and learnt the concept looking forward to meet you all in the next lecture thank you and good
bye.
 Design & Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Module No # 05
Lecture No # 21
Data Flow Diagram

Hello and welcome to the NPTEL MOOCS course on design and implementation of human
computer interfaces, lecture number 19.
(Refer Slide Time: 00:52)

So before we start we will quickly go through the stages of the interactive system development
life cycle, and then we will identify the stage where we are going to have the material for today's
lecture. So we have a development life cycle for interactive systems. We have several stages, the
requirement gathering stage is the first stage which we discussed. This is followed by a cycle
consisting of 3 stages; this is called the design prototype evaluate; cycle.

Where we have the design stage, the prototype stage, the evaluation stage and these 3 stages
work in a cycle till we arrive at a stable design; this cycle is primarily meant for design of
interface. Once we get an interface design ready we then start working on design of the
system,where our main focus is the modules of the system and how they interact with each other;
so that is the second type of design.
So in this interactive system development life cycle we have 2 design concepts one is design of
the interface primarily from the point of view of usability; and the other one is design of the
system primarily from the point of view of code management. Now once we are ready with a
system design then we go for the next stage that is coding or implementation of the design; this is
followed by testing of the code so at the end what we get we get an executable system.

Once the system is ready and executable we go for another stage called empirical study in this;
stage we test for usability of the end product. Now empirical study is different than; code testing
and we shall have detailed discussion on these stages in later lectures. There may be a cycle from
empirical study to the design prototype evaluate; cycle and subsequent stages. If we find any
usability issues during the empirical study then we may need to revisit our design, design of the
interface as well as system; and then revise our implementation and further test our code.

So that cycle may be there however our objective should be to minimize this cycle at maximum
one or 2 times more than that means it will result in huge cost and time overrun. So once we
have a system which is executable and usable after going through all these stages we go to the
deployment stage and maintenance stage. So these are the stages of an interactive system
development life cycle which we are discussing.

We have already covered the requirement gathering stage. We have covered in detail the design
prototype evaluate; cycle for interface design. Currently we are discussing the second type of
design that is design of the system.
(Refer Slide Time: 04:22)
So in the earlier lectures we have learnt the basics of system design, what are those basic
concepts that let us quickly revisit. We will first revisit those concepts and then we shall start our
discussion for this lecture that is one language for expressing the design of the system. So we
earlier discussed certain concepts including language for expressing our design and in today's
lecture we are going to cover one such language in detail.

And that language is DFD or data flow diagram in earlier lectures we have given some idea of
DFD in terms of one example. However, today we are going to discuss in detail the different
conventions, notations and symbols used in DFD and how it can be utilized to express a design
idea.
(Refer Slide Time: 05:35)
Before we start our discussion on DFD let us quickly recap what we have learned earlier about
system design.
(Refer Slide Time: 05:44)

So whenever we are concerned about design any design not necessarily system design then there
are primarily 2 issues. Where to start and how to represent the design in other words what
language to use to represent the design.
(Refer Slide Time: 06:08)
In the context of system design when we try to address the question where to start the design
process we said that the starting point can be the SRS document or software requirement
specification document. Now SRS is a language which is used to specify or express the
requirements for the system and SRS can give us the starting point for our system design. With
that starting we can go ahead and ideate the design however there are 2 phases in the system
design process.

First we go for preliminary or high level design; in high level design our primary concerns are
design of modules and sub modules; and how they interact with each other. Then in the second
phase we go for detailed design of individual modules and their components; and this detailed
design document which we get after this process is over is also called module specification
document. So there are 2 phases, high level design and detailed design.
(Refer Slide Time: 07:40)
Earlier we discussed both in brief what happens in high level design; we identify the modules at
a very high level. The control relationships between the modules that also we identify, and the
definition of interfaces between modules, primarily these 3 things we focus on in the high level
design phase. Now when we are trying to design a system different approaches can be taken
broadly there are 2 such approaches.
(Refer Slide Time: 08:25)

As we have seen earlier one is the function oriented design approach so when we are trying to
design a system using a function oriented approach; the basic abstraction that we consider are the
functions or procedures. So any problem is considered to be broken down into a set of functions
which are interacting with each other.
(Refer Slide Time: 08:53)

There is another broad approach that is called object oriented design approach; in this the basic
abstraction that we consider is object. So there are objects and a system is designed considering
the objects and their interaction with each other. Now the objects are instantiation of a concept
called class; so we will discuss more about it later.
(Refer Slide Time: 09:27)
Now let us come back to the second question that we encounter while we are trying to design a
system. That is once we have come up with some design idea how do we express it how do we
represent it? So, that it is understandable to others those; who are not part of the design process.
In order to do that we definitely need a language. Anything we need to express requires a
language. The same is true here. In order to express our design idea we need a language.

One such language is DFD or data flow diagram which we can use to express our design and this
language we are going to learn in this lecture. One thing we should keep in mind is that DFD is
one graphical language that means; it uses graphical notations to express the design and it is
primarily useful for functional design approaches. So when we are trying to design something
using the function oriented approach then expressing that design idea will be easier if we use
DFD
(Refer Slide Time: 10:45)

With that basic idea let us now understand and learn what is DFD, what are the conventions used
in DFD; and how we can use it to express our function oriented design ideas.
(Refer Slide Time: 11:07)
As the name suggests DFD essentially represents flow of data through a process or a
system;DFD stands for as we have seen a data flow diagram; that means it represents flow of
data through a process or a system. So the focus is on data movement between external entities
and processes and between processes and data stores. So when we are trying to use DFD to
express our design ideas the focus is primarily on movement of data between external entities
and processes as well as between processes and data stores.

So there are 3 concepts involved in this statement: one is external entities, one is process, one is
data store. Let us see what; are these concepts and how we can use DFD to express our design
using these concepts.
(Refer Slide Time: 12:22)
Before we learn about DFD, it may be pertinent to ask the question why we should use DFD. So
there are several reasons DFD provides an overview of the data that are processed by a system;
so different types of data that a system processes. It also provides an overview of the
transformations that are performed on this data by some processes. It also gives us some idea of
which data is stored and which is not; stored.

And from DFD we can get the information about what results are produced and where they go so
there are several reasons which makes DFD a good choice for expressing a system design. That
is not all there are other reasons as well, because DFD is a graphical language that means it uses
graphical notions; notations to express the design idea. Now this graphical nature makes DFD a
good communication tool between the user and the designer, as well as the designer and the
developer.

Now here the term user need not be confused with the end user rather it can be considered to be
the clients or customers of the product. They may like to see the design and to express the design
to them. DFD can be good because it is graphical and does not require too much technical
knowledge. Similarly the designers can find it easy to express their design ideas to the
development team who will be ultimately responsible for implementing the design.
Because it is a graphical language development team need not spend too much time
understanding the design so there are several reasons including; easy communication between
different stakeholders.
(Refer Slide Time: 14:56)

So what are the components of a typical DFD diagram? Earlier we mentioned that DFD focuses
on data flow between external entities processes and data stores, so these are the components. So
when we talk of components of DFD we talk of source or sink of the data which are typically
external entities; processes which as the name suggests, process the data and produce; output and
data stores which store the data.

So these 3 are the primary components of any data flow diagram along with that of course we
should not forget that since it is depicting data flow so flow of data itself is a component and
how do we depict it is an important issue in constructing DFD.
(Refer Slide Time: 16:06)
Let us have a look at how these different entities or different components of a DFD are
represented. In fact there are broadly 2 notations which are used, any one you can, use but try not
to mix them one is by Gane and Sarson, other one is by DeMarco and Youdan. So when you are
using DFD notations you should stick to any one particular notation rather than mixing up
notations from these 2 different sets of notations.

So when we are trying to represent an external entity, according to symbol 1 we should use a
rectangle with a name of the entity inside it, in fact this symbol is the same in the other set of
symbols with the same rectangular symbol with name. For; process the other component in
symbol 1, we have a special symbol, which is a rectangle with the corners, which is somewhat
circular then there is this line and then the name of the process.

Whereas in symbol 2 we have a different symbol with the name inside it which is completely
different from what is used in symbol 1. For the data store we have an open ended rectangle with
1 notation and the name of the data store inscribed inside. Now the notation is within a square
like shape; whereas in symbol 2 the same data store is represented again with an open ended
rectangle, but here the square like part is missing.

Instead everything including the identifier of the data store as well as the name both are inscribed
inside for data flow. The other component notation used is the same in both the symbol sets; an
arrow with a label which indicates the name of the data flow; in both the cases the notation used
is the same. So when we are trying to express some design using DFD we should stick to either
symbol 1 or symbol 2, we should not mix notations from these 2 symbols.
(Refer Slide Time: 19:06)

Now while using the names or while trying to assign some names to the different components
generally some conventions can be followed. So when you are trying to give a name to a process
try to give it in the form of a verb phrase. When a data flow level is to be given try to use a noun
as the name for a data store, also try to use a noun as the name. And for external entities again a
noun should be used as the name of the entity.

So out of the 4 components for processes we should use verb on verb phrase; to name it for the
other 3 namely data flow, external entity and data store we should stick to use of nouns for
naming those components.
(Refer Slide Time: 20:23)
Now let us slowly try to understand what are these components and what they signify; let us
begin with an external entity; what are these things; people or organizations that send data into or
receive data from the system. So you are designing a system, now there may be people or
organizations who; send data to the system or receive data from the system; such people or
organizations are generally considered to be external entity; for the system.

So their job is to either; supply data to the system or receive data from the system, so either
supply data or consume the data. So if an external entity is a source then as the name suggests
they supplies; data to the system; in contrast if the external entity is a sink then that means it
receives data from the system. So; external entities are people or organizations that are receiving
or sending data to or from the system. When they receive data they are called sinks. When they
send data to the system they are called sources.
(Refer Slide Time: 22:03)
The next component is the process. What is a process? As the name suggests it processes
something; so we can say that a process is a series of actions that transform data. So when we say
a process transforms data that means it acts on some data that is coming from somewhere and it
produces some data; that is going to; somewhere. So typically the notation that is used or that
straight line with incoming arrows, in coming to the process notation indicates input data flow,
which is quite obvious.

Straight lines with outgoing arrows indicate output data flow, so if we are using a process symbol
like this using the symbol 2 notation then, this is the input data flow; and this will be the output
data flow. And of course as we have seen the data flow should be labeled to indicate what kind of
data is being moved, so there should be some level on the arrows.
(Refer Slide Time: 23:31)
The third component is data store, now data stores represent permanent data used by the system.
So some data can be transferred in nature and they get destroyed whereas some data remains for
use in subsequent iteration of the processes. And data stores are essentially representing those
permanent data. Now data can be written into a data store in that case it will be denoted by an
incoming arrow or data can be read from a data store.

So in that case it will be denoted by an outgoing arrow; it is a simple convention, if data is

written into a data store indicate that by using an arrow that is going to the data store. And if data
is being read from the data store then that is represented by an arrow, with the arrowhead
outgoing from the data store.
(Refer Slide Time: 24:49)
Finally we have data flow the other component of a DFD, a data flow depicts actual flow of data
between different elements; now here by elements we refer to the other components namely
external entity, data store and process. So data flow connects these elements processes external
entities and data stores; without data flow of course, we will not be able to show the connection
between them.
(Refer Slide Time: 25:24)

And the notation as we have seen earlier is simple; an arrow with a label indicating the type of
data that is being represented. Now when we are drawing data flow or representing data flow
generally the arrow is unidirectional however; if the same data flows between 2 elements in both
directions then we can use a double headed arrow to represent the same rather than using 2
arrows in opposite directions. So that will be a shorthand notation for indicating movement of
data in both the directions.
(Refer Slide Time: 26:19)

So when we are trying to create a data flow diagram there are some rules that we should follow
while trying to create it. We should remember where data can flow, and where data cannot flow.
Data can always flow from external entity to process; from process to external entity; from
process to store data store, and back, and between the processes from one process to another
process.

So these are valid directions for data flow in any DFD from external entity to process, and vice
versa from process to external entity; similarly from process to data store, and from data store to
process, and also between 2 processes. However we should also remember invalid data flows
data can never flow from an external entity to another external entity; an external entity to a data
store directly by passing a process; from a data store to an external entity again bypassing the
process; and between 2 data stores.

So data can never flow from an external entity to a data store, and vice versa, or between 2 data
stores, or between 2 external entities. So these are the rules that we should remember while
trying to create data flow diagrams with valid data flow.
(Refer Slide Time: 28:17)
Let us see some examples of incorrect depiction of data flow, suppose you have created one
process and it produces some data, say some report in this case. So the notations are fine, the
process is represented with suitable notation, data flow represented with suitable notation.
However note that here there is no input data, in order to make the output the process should
receive some input data which it is going to work on.

If a process is mentioned without any input data but it is producing some output, then that is an
incorrect way of depicting DFD; and this is generally termed as a miracle DFD. Similarly
suppose there is a process which only takes an input but does not produce anything, that means
whatever data goes into the process vanishes this situation again is something which is incorrect
and generally it is called a black hole situation.

Sometimes it may happen that there is some input data, there is a process, and there is some
output data. But we forgot to mention where this output data goes if we simply left it; leave it
hanging like this then that is also incorrect. Output data must go somewhere, and input data must
come from somewhere so this is a situation which is called a gray hole situation; where we forgot
to mention the source or the sink of data.

So these are some of the 3 incorrect ways of depicting DFD's. It may be remembered that there
may be some other situations where incorrect depiction of DFD happens; but these are common
ones. So while creating DFD you should always keep in mind that you must specify an output
data flow when you are dealing with a process with an input data flow; or you must specify an
input data flow when you are dealing with a process with an output data flow. And you must
specify source and sync of input and output data flows for any process.
(Refer Slide Time: 31:10)

One important thing in any system design is to create the design in a hierarchical manner,
recollect our discussion from the previous lecture where we mentioned. That; in order to manage
the design and maintain the design it is preferable to break it down into smaller problems or
smaller systems. In effect we are creating a hierarchy of processes or modules to represent the
whole design. Our language should support that hierarchical design idea and DFD itself is well
equipped to support a hierarchical design.
(Refer Slide Time: 31:59)
So when we are dealing with complex designs generally systems which are very big real life
systems such systems involve a large number of processes and data stores. And it is difficult to
manage them unless we do something, if we simply try to create a DFD with this large number
of processes and data stores. Then the resulting DFD will be very complex, it will be very
difficult to understand and it will be even more difficult to modify.

So if we find some problem and we want to modify then; large portion of the DFD probably
needs to be modified in order to get the refined and revised design. So these are 3 important
problems when we are dealing with large systems involving a big number of processes and data
stores.
(Refer Slide Time: 33:02)
To manage such big systems, what we can do is we can go for the idea of decomposition of the
design. This indicates that we create a hierarchy of levels of design.
(Refer Slide Time: 33:24)

Generally it has been found that at least 3 levels are required to represent complex systems, more
levels may be necessary but lesser levels generally lead to incomprehensible and difficult to
manage designs expressed in dft. So we have level 0 which is generally called a context diagram,
level 1 generally called overview diagram, and level 2 which is a detailed diagram. Now we can
go for subsequent levels also which will be; again detailed diagrams but at least these 3 levels are
required.
(Refer Slide Time: 34:07)

Let us try to understand these levels, and how we can create these levels. Let us start with level 0
which is called a context diagram. Now this level is a special level here; there is only one
process, so the entire system is represented as a single process; with the corresponding process
notation. Data arrows so input and output from an external entity or external entities or 2 external
entities.

So at this level we have data arrows that depict data flow from external entity to process, and
vice versa. At this level there is no data store shown because we are using a single process to
represent the entire system; everything is content within that system, so separately no data store
is shown. It is assumed that it is implicitly content or these data stores are implicitly contained
within the system itself.

So at level 0 or context diagram level we have one process representing the whole system, all
external entities, data flow between external entities and processes and the process and no data
stores are shown at this level.
(Refer Slide Time: 35:38)
Let us see one example: suppose we are asked to create an application, a class note taking
application so this whole process, the whole system is represented as this context level process
class note taking application. Now there is one external entity user for this application, and this
data flow is shown with an arrow and levels. So between the external entity and the process all
data flow is shown with the kind of data that is being flown.

So data flow arrows with levels are drawn at this level note that here we have one process, here
an external entity, here the data flows all the data flow arrows to the process and from the
process but no data store explicitly shown.
(Refer Slide Time: 36:57)
Then comes level 1 or overview diagram level 1 is also called overview diagram, here all the 4
elements are utilized, that is process, data store, data flow and external entity. Data stores are first
shown at this level, so if the system has one or more data stores those are shown at this level for
the first time.
(Refer Slide Time: 37:29)

So if we want to draw a level one or overview diagram for the class note taking application it
may look something like this, of course there can be different designs, so this is one possibility.
So we have this external entity user shown here again there are 4 processes shown earlier all
these 4 processes together were shown as a single process. Now we have process 1 manage
users, process 2 manage notebook, process 3 edit notes and process 4 examine notes.

Similarly there are 3 data stores shown data store 1 user data, data store 2 notes data, data store 3
notebook data and it also shows data flow between the processes external entities and data stores
so this is level one diagram. So when we are creating level one diagrams we should remember
that we can use all 4 components of a DFD at this level for the first time and we should show
external entity data stores processes and all data flow between all these 3 elements at this level.
(Refer Slide Time: 38:59)
So that is level one then we come to level 2 which is also called a detailed design diagram, here
what we do we go for detailed representation of the processes that are depicted in level 1. So all
level 1 processes are further decomposed and shown in level 2 if required. Now the nature of this
level is similar to level 1 so here all 4 elements we can use to; so the detailed design of each of
the processes of level 1.
(Refer Slide Time: 39:49)

Let us continue with the same example, so in level 1 of the class note taking application we have
seen 4 processes we can call them; modules. So let us see level 2 diagram; for module 1 that is
manage users; so here we can see that there are 3 processes which are forming part of this
manage users module. Process 1 is register; new user, process 2 is login,process 3 is to update
user details. It makes use of the data store user, data we can use external entity notation here also
and all data flow between the processes.

And the external entities are shown with appropriate notation at this level, now this level is only
depicting the detailed design for individual processes or modules of level 1, so this is module 1
manage users.
(Refer Slide Time: 41:12)

Let us see module 2 manage notebook; it contains 4 processes: create notebook, delete notebook,
delete note, and create note; it makes use of the data stores notes data and notebook data which
we have seen at level 1. And also it uses external entities as before and shows all data flow along
with direction and level between the processes the data stores as well as the external entities.
(Refer Slide Time: 42:05)
Module 3 was edit notes which contains 5 processes: add text, add image, manage table, draw,
and delete content; makes use of the data store notes data external entity is present here also. And
all data flow between processes and the data stores, as well as between external entities and the
processes are shown in this detailed diagram.
(Refer Slide Time: 42:48)

There was a fourth process or module examining notes in level 1; which can be further broken
down into 4 processes: search by text, search by date, find in note, and view note; makes use of
the 2 data stores notebook data, and notes data. And all the data flow between the process and the
data stores are depicted like before; similarly all the data flow between the external entity and the
processes are depicted as before.

Now as you can see if we do not have the decomposition of how complex the single DFD would
be; suppose instead of level 0, level 1, level 2 this hierarchical way of showing the design we
wanted to show it at a single level. Now as you may recollect the system consists of 4 top level
modules each module on an average has between 3 to 5 modules submodules or processes. So
together there will be between 12 to 20 processes to represent this particular class note taking
application design.

Now between 20 processes if we are trying to depict data flow then there will be lots and lots of
such arrows going around; then it will become a really messy picture, really messy diagram.
Where; there will be lots of overlapping arrows, lots of crossing arrows and it will be very
difficult to comprehend the direction of data flow, the type of data flow, because there will be a
large number of levels. So it will be very difficult to read or comprehend the levels from this
messy picture. So the hierarchical way of depiction gives us a nicer and cleaner mechanism to
represent complex designs.
(Refer Slide Time: 45:32)

Hierarchy is of course one way of creating a good nice clean design, now there are some other
conventions you should follow while creating a good DFD. One is try to use meaningful names
for data flows, processes and data stores. This will be helpful in understanding and remembering
these components. Use top down development starting from context diagram and successively
creating the DFD levels.

So do not start from bottom up, that is first try to understand all the processes and then try to
create the hierarchy; should not follow that approach instead you should start from the top or
context level and then successively expand in subsequent levels the design. Stop decomposition
if levels become trivial that means no further significant changes are depicted in the levels,then
you should not go for further decomposition.

Always keep in mind that only previously stored data can be read and data stores cannot create
new data; so unless there is a process new data cannot be created, and a process can read only
data that is already available. These 2 may seem simple but there are actually cases where people
make mistakes because they do not keep these things in mind. So these are some of the things
that you should keep in mind while trying to create a good DFD, now in DFD we mentioned that
we have data stores.

However; DFD itself does not tell us how to represent data that are part of data stores. So we
have a notation to represent data stores but that notation does not reveal the internal structure of
the data. It is often useful to know the internal structure and for that we can go for another
graphical notation that is called ER diagram or entity relationship diagram.
 Design & Implementation of Human-Computer Interfaces
Dr.Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology Guwahati

Module No # 05
Lecture No # 22
Entity Relationship Diagram

Hello and welcome to the NPTEL MOOCS course on designing and implementing
human-computer interfaces. We are currently discussing a language, to express system design
particularly, when we are following a function-oriented design approach. In the previous lecture,
we talked about DFD or data flow diagrams which can be used as a language to express function
oriented system design.

We will continue our discussion on DFD plus ERD, in lecture number 19. So, both are part of the
language we can use to express function-oriented designs. We have already covered in detail the
various aspects of DFD with examples. Now, we are going to discuss the other component of the
language which is ERD.
(Refer Slide Time: 01:57)

ERD stands for entity relationship diagram in short ER diagram.

(Refer Slide Time: 02:02)
In DFD, we made use of data stores so we have seen notations to represent data stores, where we
can store various types of data. But so far, in order to represent data stores, we only used a name
and identifier. Only labels represent the store as a whole, but these labels that we assign to the
data stores do not reveal the internal structure of the data and also how the data are organized in
the data store?

So, the labels are not very informative in that sense. It only gives us an abstract idea of the
presence of stored data, but it does not tell us anything more about the nature, type, and
organization of that data. It is also possible that there may be relationships between various data
elements, which again are not revealed by the labels that are assigned to the data stores. So,
many things are hidden when we use simply a label to represent data stores in our DFD.
(Refer Slide Time: 03:31)
But sometimes it may be useful to learn or to represent the internal structure of the data that we
are dealing with. So; that, further brainstorming can be done, and further optimization can be
done before we set out to implement the system. Clearly, the notations that we have covered in
DFD, do not allow us to represent the nature of the data, the organization of the data, the type of
the data, or even the relationship between various data elements, that are used in a data flow
diagram.

One way to express the internal structural organization and relationships that; may be present in
data stores or across data stores is to use the ER diagram where the ER stands for entity
relationship. So, entity relationship diagrams, or in short ER diagrams can be used to express the
structure, organization, type, nature, and relationship of data stores.
(Refer Slide Time: 05:01)
Now the ER diagram has a long history. It was first proposed by Peter Chen, way back in 1976
that was nearly 45 years ago. Now, it includes, as the name suggests, an entity relationship
diagram. So, it includes entities and relationships. So, these 2 are the central concept behind the
ER diagrams. ER diagrams can be used to represent relational databases, a special type of
database which is used to store data, and ER diagrams are most suitable to represent relational
databases.

In fact, ER diagrams can be considered to be another graphical language to represent data. In a

similar way, DFD is used to represent the overall design of a system.
(Refer Slide Time: 06:04)
So, what are the basic components of a typical ER diagram or entity relationship diagram? There
are 3 basic components. One is an entity, which is an identifiable object or concept of
significance. Generally, it is represented with a rectangle as shown here. Then we have an
attribute, which is a property of an entity or relationship. So, the attribute can be the property of
an entity or it can be the property of even a relationship as well.

Generally, to represent an attribute, we use this elliptical shape, and finally, there is a
relationship. A relationship represents an association between entities. Generally, it is
represented with this particular shape as shown in the figure.
(Refer Slide Time: 07:20)
So using these 3 basic concepts entity, relationship, and attributes we can represent or model data
items that are used in a system design and represented using graphical notions such as DFD. So,
a data store or a database which is used in DFD can be modeled as a collection of entities with
relationships among those entities. So, both are used to model the data store or databases that are
used as part of the system design, namely a set of entities and the relationship between them. So,
let us try to go a little deeper and learn in a little more detail the idea of the entity.
(Refer Slide Time: 08:23)

The entity is an object that exists and is distinguishable from other objects. For example, a
person can be considered to be an entity, a company can be considered to be an entity, a student
can be considered to be an entity, and a customer can be considered to be an entity. So these are
some of the examples of what can be considered to be an entity. Generally, entities have
attributes or properties.

For example, if we consider a person to be an entity. Then the person can have attributes such as
names, addresses or date of birth, or age. So, these are attributes that are assigned to the entity.
Then we have the notion of the entity set. So, this is a set of same-type entities that share the
same properties. For example, a set of all persons constitute an entity set. Whenever we are
defining something as an entity, in order to model a data store, we have to keep in mind that each
entity must be uniquely identifiable. So, we have to ensure that in order to be able to suitably
model the data store.
(Refer Slide Time: 09:58)

Next is the idea of attributes. So, attributes are essentially descriptive properties of the entity. If
we are defining something as an entity and it has some properties. We call those properties
attributes. Now, attributes are broad generic terms, we can assign values to an attribute. So, that
is a particular instance of an attribute. Whenever we are assigning a value to the attribute that
means that is an instance of the attribute.

Then we can define a domain of values for an attribute, which is a set of permitted values for that
particular attribute. So, whenever we are defining an attribute for an entity, we can also define
the required domain of values that are permitted for that particular attribute.
(Refer Slide Time: 10:59)

So, there are broadly 2 types of attributes. One is a simple attribute, which contains only atomic
values and one can be a multi-valued attribute, which can contain several atomic values. Let us
consider one example; suppose we have defined an entity to be a student. So, we have defined
the student to be an entity. Now, the student has several attributes. One of those attributes is a
student id or identifier.

So here, we can store only one atomic value. So, this is a single-valued attribute. Now suppose,
along with the student we are also storing phone numbers. So, that can be another attribute.
However, a student can possess multiple phone numbers. So, for each student, we might have
more than one phone number. So, we can store phone number 1, for number 2 in that way up to
the nth phone number.

So, the phone number attribute can contain more than one atomic value where each phone
number can be considered to be an atomic value. Such an attribute is a multi-valued attribute so,
we have 2 types of attributes one is a single value, and one is multi-valued.
(Refer Slide Time: 12:33)
There can be some null attributes as well. Generally, null attributes are used when an entity does
not have a value for an attribute. We can also have derived attributes where the value that is
assigned to the attribute is generally derived from other attributes or entities. So, if we are
assigning values to some attributes which can be derived from other attributes, then those
attribute values are derived values and those attributes are called derived attributes.

For example, if we have a date of birth to be an attribute as well as age to be another attribute,
then age can be derived from the date of birth. So, age is a derived attribute. Let us see one more
example of these different types of attribute values in an ER diagram.
(Refer Slide Time: 13:32)
So, this example shows a typical ER diagram as you can see, we have an entity and several
attributes. Now, as you can see some of the attributes are single-valued like date of birth and
customer id. Some are multi-valued like the name which can have 3 atomic values; first name,
middle name, and last name. Similarly, addresses can be multivalued which can have street, city,
state, and zip code as atomic values.

Whereas street can itself be a multi-valued attribute having street number, street name, apartment
number, and so on. We can also have derived attributes like age. Now, this attribute value can be
derived from the date of birth attribute. We can also have null attributes. Suppose, with a
customer we have this attribute of the phone number, but for a particular customer, we do not
have the phone number value with us.

Then it can be considered to be a null attribute. Because we are unable to supply a value for this
particular attribute for a customer. So, we can define an entity and assign different types of
attributes to that entity.
(Refer Slide Time: 15:18)
The third crucial component is the relationship between entities. A relationship essentially
defines an association between entities. For example, suppose Sam is an entity. E-100 is an
entity. So, Sam is a customer entity E-100 is an account entity. So, these 2 are 2 entities. Now,
they are associated with each other in a relationship called depositors. So, this depositor is a
relationship.

So, Sam is a depositor holding an E-100 account. So, we can represent it graphically in this way.
So, the customer entity is there, the account entity is there and there is this relationship between
them, shown with this particular symbol. Now here, Sam is actually an instantiation of the
customer entity. E-100 are an instantiation of the account entity. But in the diagram, we are
representing generic forms of entities and relationships. So, we have a customer; we have an
account and we have a relationship with them as depositors.
(Refer Slide Time: 16:47)
Now there is this concept of degree of relationship. This is essentially the number of entities that
are associated with a particular relationship. This number defines the degree of the relationship.
We have a binary relationship or degree 2, which means 2 entities are associated with that
particular relationship. This is the most common form of relationship. But we can also have more
than 2 entities to share a relationship, such as a ternary relationship. But this is generally rare.
(Refer Slide Time: 17:25)

Let us see one example of a ternary relationship. So, we have an employee entity, a branch entity,
and a job entity. Now, the employee entity has some attributes like employee id, name, street
address, city address, and telephone number. These are some of the attributes defined for the
particular entity. The branch entity has attributes like the name of the branch, the city in which
the branch is located, and the total assets in the branch.

The job entities have attributes like the title of the job and the level of the job. Now, between
these 3 entities, we can define a relationship works on. So, the employee works in the branch and
the employee has this particular job. So, the employee’s job and branch are related or associated
through this working relationship. Here, 3 entities are associated with the relationship. So, we
can say that this relationship has degree 3 or it is a ternary relationship. But generally, such types
of relationships are rare. Relationships of degree 2 are more common than those are rare
relationships.
(Refer Slide Time: 19:06)

Now, relationships can be one to one, one to many, many to one, and many to many. Let us see
with examples what these types mean.
(Refer Slide Time: 19:22)
So, first is one-to-one. An example is a customer entity that is associated with at most one. It can
be zero also loan entity via the borrower relationship. See if we can form such a relationship then
that is one to one relationship. A loan entity is associated with at most one can be zero also, the
customer entity via the borrower. So, it is graphically shown here. So, we have a customer entity,
loan entity, and borrower relationship defined between them.

Now, the customer entity has attributes like id, name, street address, and city. A loan entity has
attributes like loan number and amount. So, when we are defining this relationship as a
maximum one, that is a customer can avail of a maximum of one loan or a loan can be associated
with a maximum of one customer. Then this particular relationship is one-to-one. So, we can say
that in this case, the borrower relationship is a one-to-one relationship.
(Refer Slide Time: 20:41)
Let us see one example of a one-to-many relationship. We will use the same set of customer
loans and borrowers. So, if we now define a loan entity as associated with at most one customer
via the borrower. But a customer entity is associated with several including zero loans via
borrower, then that is one to many relationships. So, we can have one customer who can have
many loans, if we redefine this relationship in this way then we can say that borrower is one to
many.
(Refer Slide Time: 20:24)

Then we can have many-to-one relationships. Now define a loan entity to be associated with
several including zero customers via borrower, then that is many to one. So here, we should keep
in mind that these are hypothetical examples. So, it need not be practical. But still just to give
you some idea of what these relations mean. We are redefining the settings a customer entity is
associated with at most one loan by a borrower. However, a loan can be associated with several
customers, in such a case it is many to one relationship.
(Refer Slide Time: 22:08)

Finally many too many, a customer entity is associated with several loans. As well as, loan
entities associated with several customers. So earlier, what we are seeing in the case of
one-to-one, customer entities associated with one loan entity and vice versa. In one to many, a
customer entity is associated with many loans, but one loan is associated with one customer only.
Many to one customer are associated with one loan.

But one loan is associated with many customers and then finally we have many too many, where
several customers can be associated with several loans. One customer can be associated with
several loans and a loan entity can be associated with several customers. So, both are possible in
that case we can say that the borrower relationship is many to many.
(Refer Slide Time: 23:11)
Now, we can use some notations to indicate the type of relationship. So, we can use min-max
notation, where min indicates each entity is in a relationship at least min times. The max value
indicates each entity is in the relationship at least max times. So, this is one notation to indicate
the type of relationship where we can have one value for mean say 5, then dots, then the value
for max say 10.

So, if we use this type of notation then the mean value indicates that each entity is in the
relationship at least mean times and the max value indicates that each entity is in the relationship
at most max times. There can be special cases for this notation when the mean can be set to zero.
So, this indicates that there need not be any relationship between the 2 entities and max is
represented with a star. That indicates that there can be arbitrarily many instances of the
relationship.
(Refer Slide Time: 24:43)
Let us see an example. Suppose, we are defining the relationship using the particular notation in
the example setting that is customer entity, loan entity, and borrower relationship. Now, the lines
between the entities and relationships we are now labeling with the min-max notation so as
shown here. So, there are 2 notations on the 2 lines between customer and borrower.

The association is indicated by the min-max notation 0 and star, where the mean is 0 and the max
is the star. That means there need not be any relationship there need not be any customer,
borrower relationship and there can be arbitrarily many customer-borrower relationships at the
most. Between loan and borrower, it is 1, 1. So, mean is 1, max is 1, using the min-max notation.
That means a loan can be borrowed at least once or and a loan can be borrowed at most once.

So in both cases, the value is the same. Now, that is up to us, how do we define the relationship?
If we want to have more flexibility we can have separate values for min and max so this example
illustrates the idea of min max notation.
(Refer Slide Time: 26:25)
So, with that, I would like to conclude this topic on ERD. So, one thing to be noted here is that
ERD is a very expressive language and there are many more notations and many more
conventions followed to represent complex data organization data stores. Here, we covered ERD
in a very basic way at a very basic level, but you should always keep in mind that ERD is more
expressive, having a very rich set of notations, covering many more aspects of the representation
of data.

Since a full-length discussion on ERD will be out of scope for this course, we will refrain from
doing so, however, if you are more interested then you can refer to the references.
(Refer Slide Time: 27:28)
You can find the material in these books fundamentals of software engineering and software
engineering practitioner's approach so you may refer to these books for more details on both the
topics DFD as well as ERD and how they are used to represent system design. So with that we
have come to the end of the lecture. In this lecture we have covered how we can use DFD and
ER diagrams to express a system design that we have arrived at following a function-oriented
approach.

So, we learned about several notations for DFD and we have seen examples to better understand
the DFD. We have also learned about several notations and major components of ER diagrams
and we have gone through several examples to understand the basic concepts of ER diagrams in
more detail. I hope you have enjoyed the learning and you understood the concepts that are
covered in these lectures. I am looking forward to meeting you all in the next lecture. Thank you
and good bye.
 Design & Implementation of Human-Computer Interfaces
Dr.Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology Guwahati

Module No # 05
Lecture No # 23
Case Study on DFD & ER

Hello and welcome to the NPTEL MOOC’s course on design and implementation of human
computer interfaces lecture number 20 where we are going to discuss about case study on the
concepts of DFD or data flow diagram and ERD or entity relationship diagram. Before we start,
we will have a quick look at the interactive system development life cycle and where we stand.
So, as you may recollect in an interactive system development life cycle there are several
stages. (Refer Slide Time: 01:20)

We have requirement analysis gathering and specification stage. Requirement Gathering analysis
and specification stage this is followed by a set of stages which form a cycle which is design,
prototyping and early evaluation these 3 stages together constitute a cycle design prototype
evaluate cycle. Now here if you recollect, we talk of design at 2 levels one is the design of the
interface and interaction.

For that particular design, we need to prototype and get it evaluated to understand usability
issues. If after evaluation, we find some issues we may need to go for refinement of the design
then again, we prototype again evaluate, and in this way, it forms a cycle. Once, we arrive at a
stable interface design then we go for implementation of the design. The first step of
implementation is system design.

So, the design also implies system design. So here, with the name design, we are actually
referring to both interface design as well as system design. For system design, of course, we do
not require prototype and evaluation stages. So, once we arrive at a stable interface design, we go
for the design of the system where we concentrate on modular design and there are several ways
to express the design.

As we mentioned earlier, broadly 2 such ways are there one is a function-oriented approach and
one object-oriented approach. In the function-oriented approach, we generally make use of DFD
or data flow diagrams and ERD or entity relationship diagrams to express our design. Once the
design is available, we go for implementation through coding which is the next stage. Then, we
need to test the code. Program testing which follows the coding stage. After code testing, we get
an executable system free from bugs.

However, we still do not know about the usability of the system which we, evaluate in the next
stage that is an empirical study. After the empirical study, we get to know of usability of the
system. So, after this stage, we can expect a system that is executable as well as usable. This is
followed by deployment and maintenance. So, these are the stages of an interactive system
development life cycle and some of the stages from the cycle. That means they are repeated
frequently and some should not be repeated frequently.
(Refer Slide Time: 04:43)
In the previous lecture, we learned about in details the idea of DFD or data flow diagram and ER
or entity relationship diagram. So, whatever we learned in the earlier lecture, we are going to
learn it further in terms of one case study which we will discuss in this lecture. So, we will go
through a case study in this lecture. First, let us introduce the case that we are continuing from
the earlier part of the course.
(Refer Slide Time: 05:22)

That is a calendar app or calendar application. We have already introduced the app earlier and
discussed other development life cycle stages with respect to this app. Just to recollect what this
app is all about. So, we are interested to build a calendar app which is primarily meant, to be
used by students to help in their various academic activities. So, that is the idea of the app. So,
earlier we have seen how to create a requirement specification document that is a software
requirement specification document or SRS for this app.
(Refer Slide Time: 06:13)

So, as we discussed in the previous lecture, the starting point of our system design activities is
the SRS document. From the SRS document, we start designing our system. So, let us have a
quick look at the SRS that we discussed for the Calendar app in an earlier lecture. (Refer Slide
Time: 06:38)

Particularly, lecture number 8, which we covered in week 3. So we will just briefly go through
the various requirements that we have identified for this app. If you recollect, whenever we are
trying to represent an SRS, the first thing is it should be hierarchical for improved manageability
of the code. So, we have created such a hierarchy. So, in the hierarchy at the top level, there are
several requirements.

So, we have created such a hierarchy. So, in the hierarchy at the top level, there are several
requirements. One is a display calendar under which come 3 sub-requirements or sub-functions,
display months, display days with events, and a specific debt view. Then, we have another top
level function which is to set a reminder, under which there are sub-functions create a reminder,
edit reminder and delete reminders.

A third top-level function is set to background, under which comes set theme and reset theme.
Finally, there is a fourth level. The fourth top-level function is synchronized, under which comes
to attach an account and remove the account. So, here we will be showing only the hierarchy for
a quick recap. You must remember that this hierarchy is accompanied by a detailed description
of each of these functions in the SRS. In terms of their input, output description, and so
on. (Refer Slide Time: 08:25)

Also note, that in this particular SRS that we have seen only functional requirements are
considered. If you may collect earlier, we also saw how to convert some non-functional
requirements into functional requirements and add them to the hierarchy. However here, for
Simplicity we will be ignoring that part and we will be focusing only on the functional
requirements. So, given this SRS our intention is to come up with a design and express the
system design in terms of a DFD or data flow diagram which is a graphical language to express
design ideas. Before, we start discussing the DFD let us quickly recap what we have learned
about DFD.
(Refer Slide Time: 09:19)

So, DFD represents flow of data, through a process or a system. So, here the focus is on data
movement between external entities and processes and between processes and data stores. So, our
primary concern is how the data flows between different stakeholders of a system including
external entity, processes. So here, our main intention is to represent data flow between different
components of a system and stakeholders that include external entities processes and data
stores. (Refer Slide Time: 10:07)

So, what are the components of a DFT or data flow diagram? So, we talked about a few
components, primary components. The external entity which; acts as a source or sinks of data,
processes, data stores, and finally the data flow. These are the primary components of any data
flow diagram.
(Refer Slide Time: 10:37)

So, how do we represent them? Remember that we mentioned about 2 conventions. So, you can
follow either of those 2. So, for external entity one convention tells you to represent the external
entity with a rectangle, having the name of the entity inscribed in it. In the other convention also,
the same symbol is used. For process, for representation of process, there is some difference.

In one case, we get one particular symbol with a name inscribed inside it. In another case, we get
another notation. Data store also, there is a minor difference between an open-ended rectangle in
one case with identifier and name separated by a vertical bar. Whereas in; another case we have
the open-ended rectangle and identifier name but no vertical bar to separate them.

For data flow, the notations used in both the cases are the same and arrow with a label
mentioning the name of the particular data. In both the cases we have the same symbol. So, you
can use either of these set of symbols to represent different components of a DFT. (Refer Slide
Time: 12:16)
Another important thing that we learned is about the levels. Remember that, we emphasized the
point that design should be modular and hierarchical. So, that it is easier to create and
understand. So, DFT notations allow us to represent a system design in a hierarchical manner as
we have seen earlier. So, there should be at least 3 levels in the hierarchy. Level 0 is called a
context diagram level 1 is called overview diagram and level 2 is called detail diagram.

Now, there can be levels 3, 4, 5 any number as we want all will be detailed diagrams. Too many
levels of course are not good and too fewer also not good. So, we have to maintain some balance
in the number of levels, that we are going for with that basic background and recap. Let us, now
turn our attention to the case that is the calendar app and the design of the app system and
expressing it using DFD.
(Refer Slide Time: 13:37)
So, we will start with level 0 or the context level diagram for the calendar app as shown in this
figure. Now here, we will be using the second set of symbols that we have shown earlier with
some modifications for is in explaining the concept. So, we will be using the level number here,
along with the name of the process, separated by a horizontal line within a circle. Although
ideally, we should use an ellipse, this is just to simplify the explanation.

So, at the context level as we have seen earlier there will be only one process. Now, this process
encapsulates the whole system everything in the system and the process interacts with an
external entity. In this case, it is a student, who is the primary user of the app and there is data
flow between the entity and the process. Some goes from the entity to the process and some
comes from the process to the entity.

So, student can provide to the system data such as email account details, theme details, calendar
view details, reminder details, or update set delete events date, time, information; and so on.
Similarly, system can send to the student information such as synchronization success or error
messages specific theme on display requested calendar view and some are update, set, delete
events, date and time status. So, these are the things that can be sent to the student by the process
and the process can in turn take input from the students. So, that is about level 0 or context level
diagram.
(Refer Slide Time: 16:07)
Then we come to level 1, which is an overview level. In this level, we break down the single
process that is there in context level representing the whole system and here, we show the top
level modules and their connection with each other. Along with data stores if they are there at
this level. So, in level 1, we can see that we can have a process display calendar for the app. So,
you have leveled it as 1.0, which is level 1 process. There are 2 data stores D1 and D2. D1 is
about view details database and D2 is about event details database.

Then we have the external entity shown here student and all the data flow that we have seen
earlier, with addition of data flow from data store to the process as shown here. From each data
store to the process there is to and fro data flow. That is in addition to the data flow between the
process and the external entity. But this is not the only process in level 1. Let us see what other
top-level process can be there.
(Refer Slide Time: 17:36)
So, earlier we saw Display calendar process. Now, there can be another reminder settings process
at the same level 1. Now, this process interacts with D2 event details database. But not with D1,
view details database. As well as, it interacts with the external entity and the other process as
shown in this figure, are these the only 2 let us see
(Refer Slide Time: 18:16)

We can have another process. So, we have already seen display calendar reminder settings. We
can have a third top level process that is set background. Now, this process makes use of another
data store. D3 background details and it interacts with the data store. In addition to its interaction
with the external entity student in the form of data flow from and to the external entity it also
interacts with the other processes particularly processed 2 that is reminder setting.
(Refer Slide Time: 19:09)

We can even add one more process it should be numbered 4 this is 4 accounts synchronization. In
addition to the other three processes display calendar, reminder settings, and set background.
Now, this process makes use of yet another data store which is the D4 student details database.
So, there are 4 data stores then view details, event details, background details, and student
details.

Now, one thing you can note here is that these 2 data stores D1 and D2 have used one notation
and the other 2 data stores D3 and D4 have used another notation, where we are using the
vertical bar to separate the identifier and name of the data stores this is another type of notation.
So, we should never mix these things. So ideally, we should use either of these. This is just to
show you that this mixing is not a good practice.

So, in this case, if we are following D1 and D2 data store conventions. Then this bar should not
be there. So, in level 1 as you can see, we have now, 4 processes these are top-level processes.
There are 4 data stores and there is the data flow between the processes, between the processes
and data stores, and between the processes and the external entity, that is the student. So, that is
about level 1 or overview level. Now, we move to level 2 or the detailed level. In this level, we
detailed the individual processes that we have shown in level 1.
(Refer Slide Time: 21:18)
So, we start with process one of level one. So, process 1 is a display calendar. Now, we are
showing the detailed design for this process in level 2. As you can see, here we can have 2 sub
processes managing calendar view and managing of events. One is given the identifier 1.1,
another one is given the identifier 1.2 and they make use of the 2 databases D1 and D2, the view
details database and the event details database.

Note that here, we will be using the terms databases and data stores interchangeably, they refer to
the more or less same concept from our point of view. Now, these 2 processes are interacting with
the external entity student as well as the data stores. 1.2 interacts with data store 2, 1.1 interacts
with data store 1 and there are inputs coming from the second top-level process P 2.0
and output going to the second top-level process P 2.0 that is process 1 level
2. (Refer Slide Time: 22:34)
Now, let us move to the level 2 diagrams for process 2 that is a reminder setting. Here, we have 3
sub processes or sub-functions 2.1 create events reminder, 2.2 update events reminder, and 2.3
remove events reminder. Now, 2.1 and 2.3 interact with the data stores same data store event
details database. For Simplicity, we have replicated the data store notation here. Although that is
not required, we could have simply used some arrows from this data store to 2.3.

As usual, process 2.1 produces an output that goes to process 1 and takes input from process 3.
Process 2.2 produces an output that goes to process 1. Process 2.3 produces an output that goes
to process 1. The 3 sub-processors interact with the external entity as well as the data stores D2.
(Refer Slide Time: 23:50)
Now, let us check the level 2 diagram of process 3 that is a set background. It has got 2 sub
processes 3.1 set theme and 3.2 reset theme. They make use of the data stores D1 and D2. So, like
before they also interact with the external entity as well as the data stores. Process 3.1
produces some output which goes to process 1 and process 2 that is process 3.0 level 2.
(Refer Slide Time: 24:34)

Finally, the level 2 diagram for process 4 is synchronization. Here we have 2 sub-processors 4.1,
add and Link user email account with calendar activity. 4.2 remove or D-Link or edit email
account with calendar activity. In fact, we can break it up further, but for simplicity we just kept
it restricted to 2 sub-processes. Here, we make use of the D3 student details database.

Student external entity is present here. So, process 4.1, as well as 4.2, interacts with the external
entity as you can see here through these data flow notations. They also interact with the data
store and some input is coming to process 4.1 from process 1. So, that is level 2 detailed design
of process 4. So, we have seen how we can convert the design idea namely the system design
idea into a DFD using the notations that we have learned in the previous lecture.
(Refer Slide Time: 26:07)

https://onlinecourses.nptel.ac.in/noc23_cs116/unit?unit=53&lesson=57
Now, one thing here you should always keep in mind is that what we have just seen is only one
out of many possibilities. The same SRS which is the starting point of our system design process
can be converted to different designs. So, there is no unique solution to the design problem and
we can come up with different designs. Right now, we will not go into the comparative study of
which design is good, and which is bad.

The design that you are likely to choose depends on your expertise and your skill as a designer.
So, if a skilled designer is there, then of course he or she is capable of coming up with the most
efficient design given the set of alternatives, where the efficiency is measured in terms of
manageability, resource utilization, and such considerations. But the key thing that you should
remember is that from the SRS we can get many designs, what we have seen is not the only
possible design there can be many other possibilities.

We have seen only one of many such alternative designs whether that is a good design or a bad
design. We will not enter into that argument. Here the other component that we have learned is
the entity relationship diagram or ER diagram. What is the ER diagram? Let us quickly recap and
then see how we can use this knowledge to represent the data stores that we have used in our DF
diagram data flow diagram for the Calendar app.
(Refer Slide Time: 27:56)
So, ER diagrams are generally used to represent data stores that we use in DF diagrams. So, they
are used to express the rich internal structure organization and relationships in the data stores.
(Refer Slide Time: 28:15)

What are the basic components? There are 3 basic components one is an entity, represented with
a rectangle. This is an identifiable object or concept of significance. Then we have attributes,
represented within the ellipse elliptic curve is a property of an entity or relationship. And finally,
the concept of the relationship which is represented with this symbol. A relationship refers to an
association between entities some connection which is represented with this
symbol. (Refer Slide Time: 28:58)
So, with these notations, we try to model a data store in terms of a collection of entities and the
relationship among the entities.
(Refer Slide Time: 29:12)

So, with that basic idea let us now quickly see, how we can represent the data stores that we have
just used in our data flow diagram using the notations of an ER diagram. So, we have several
data stores those we can represent as student entities, calendar view entities, calendar theme
entities, event entities, and reminder entities. So, these are all entities, that we can think off for
the data stores that we have used in our data flow diagram.
Now, the student entity has got some attributes like name, student ID, and email student. The
calendar view entity has got some attributes like view date attribute, view id, and view time. View
date is a multi-valued attribute having values such as year, month and date. Similarly, view time
is a multi-valued attribute with values that are our minute and second. Calendar theme the other
entity has got 3 attributes ID, background, and color.

Now, the calendar theme, calendar view, and student these three entities are related to each other
with the relationship get the student can get calendar view or calendar theme. So, in that way,
they are related. So, this is not a binary relationship. If you recollect it, is a ternary relationship.
Then, there is this event entity and reminder entity. The event entity has got several attributes
such as event end time, event date, event ID, description type, start time, and name of the event.

The reminder entity has got several attributes scheduled time, description ID, reminder ID, as
well as the event for which remainder it is said to be set that ID. Now, event and reminder
entities are connected through his relationship. So, event as reminders and reminders as an event
so, in both ways it is applicable. Similarly, the event entity and the student entity are connected
through a relationship which is editing an assignment relationship.

So, students can edit events and students can assign events or events can be assigned to students.
So, both ways are applicable. So, both the arrows are there. So, in this way, we can model the
data stores, that we have used in the data flow diagram. One thing that may be noted here is that
the data store levels or the rather names are not exactly the same as the names that we are using
to represent entities’ relationships and attributes.

So, that mismatch may be there however overall, the kind of data that we are using in the data
flow diagram is our main focus, and that data we can model using the ER diagram notations.
Even if, we need to use different levels for representing entities or relationships or attributes. So,
in this example, you can also see the idea of ternary relationships as well as multi-valued
attributes.
So with that, we have come to the end of this lecture. So, in this lecture we tried to learn the idea
of DFD and ERD in a better way in terms of one case study, where the case is the calendar app
that we are using throughout our course. We have seen how to come up with a level 0 diagram
for the app level 1 or an overview diagram for the app, as well as level 2 or detail diagrams for
each of the top-level modules or the processes that are part of the level 1 diagram.
Several data stores we have used in the DFD which we can model and represent using ER
diagram notations which we have also seen in this lecture that is all for this lecture. I hope you
enjoyed the material and you got a better understanding of the concepts of DFD and ERD and
how to use them in practice? In the next lectures, we will take up another way to go for system
design which is the object-oriented design approach looking forward to meet you all in the next
lecture thank you and good bye.
 Design & Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Module No # 05
Lecture No # 24
Introduction to Object Oriented Design

Hello and welcome to the NPTEL MOOCS course on design and implementation of human
computer interfaces lecture number 21. Where, we are going to start discussion on object
oriented design before we go into the topics of this lecture.
(Refer Slide Time: 01:03)

Let us first briefly recap what we have learned so far, if you may recollect we are talking about
design and implementation of software systems which are interactive systems. Now in order to
go for a systematic design approach we learned about design life cycles, for interactive systems
we learned about specific design life cycles that we are following in this course. Let us quickly
recap the stages of the design life cycle so the interactive system design life cycle consists of
several stages.

Starting with feasibility studies which; we did not discuss in detail in this course. So we will skip
it. The first stage that we discussed in detail is the requirement gathering, analysis and
specification stage if you may recollect in this stage. We gather end user requirements where end
user requirements, actually refers to both client requirements as well as the actual user
requirements.

This is followed by a group of sub stages together we call it design prototype evaluate cycle. So
it consists of a design stage, a prototyping stage and an evaluation stage together they form a
cycle as shown here. So once we gather the requirement we then go for design of the system then
we prototype it and get it evaluated to see if there are any issues with the design if there are
issues found in the evaluation.

Then we refine the design, go for prototyping again, go for evaluation again and this goes on till
we arrive at a stable design that is followed by the coding and implementation stage; where we
write the actual code for the software and we implement the whole system. The next comes the
code testing phase where we test the code that has been written to implement the system. Then
comes, empirical study stage in this stage we go for testing the usability of the interactive
system.

Recollect that usability is the most important concept that differentiates interactive systems or
software systems that are interactive from other software, and in this stage we go for systematic
study of usability of the end product. Now at this stage if we find some usability issues we may
go back to the earlier stages as shown here and repeat the stages in the sequence. However this
cycle is or ideally should be very infrequent maximum once or twice otherwise the overall cost
and turnaround time of the project will be significant.

Once we arrive at an execution-able and usable system we go for the next stage that is
deployment of the system as well as the maintenance phase. This is in summary the stages of the
interactive software development life cycle, through which we get our system developed and
deployed. You may also recollect that at the end of each stage we generate some output for the
requirement gathering stage; the output is an SRS or software requirement specification
document.

After the design stage we get the design document, after the prototyping stage we get the
prototype document or prototype systems, after evaluation we get evaluation results. After
implementation coding and implementation stage we get a code, after code testing we get the
testing documents, after empirical study we get the usability evaluation document; so these are
outcomes of the individual stages.
(Refer Slide Time: 05:37)

So far we have covered in detail the requirement gathering stage including how together and how
to specify functional, as well as non-functional requirements currently we are discussing the
design stage.
(Refer Slide Time: 05:55)

Now we are currently located in this stage here, now if you may recollect then when we talked
about design we actually refer to 2 types of design; one is interface design one is code design. So
when we are talking of interface design the design prototype evaluate cycle is important. Here
when we are trying to design for an interface which is usable we first come up with the design
idea then we prototype the idea and get it evaluated for usability with expert users.

So this is different from the other usability evaluation that is done at this empirical study stage, in
the sense that in this stage; early evolution stage we get the design tested by domain experts
rather than end users. And this cycle goes on as long as we do not get a stable interface design
with a minimum number of insignificant usability issues.
(Refer Slide Time: 07:07)

The other design; so once we get an interface design done through the multiple iteration of the
design prototype evaluate cycle then we go for the next phase of design that is code design. Here
we try to come up with a design of the entire system in terms of modules and sub modules which
can be directly implemented as code or program.
(Refer Slide Time: 07:38)
So the design prototype evaluation cycle primarily caters to interface design; it has no role to
play in the code design. Once the design stabilized interface design is stabilized and no further
changes are required we focus on code design, it can be done in parallel also. If we already know
in advance that no further changes will take place in the software requirement specification
document that we get at the end of the requirement gathering stage.
(Refer Slide Time: 08:18)

So when we are dealing with design there are primarily 2 issues one is where to start the design
process, so design is also a process we can think of as a process so where we should start this
process. And second is how to represent our design in other words what language we should use
to represent our design.
(Refer Slide Time: 08:45)

Earlier we talked about interface design, now that we have learned where to start we actually
mentioned that we can start the design process based on our own experience or intuition. Also if
we do not have sufficient experience or intuition or we want to augment this capability we can go
for a starting point as the design guidelines. So there are several guidelines available. We can
make use of those guidelines to start our design process. We learned about a couple of guidelines
namely Schneiderman's eight golden rules, Norman's seven principles.
(Refer Slide Time: 09:31)
In contrast when we go for code design our starting point is the SRS document or the software
specification document requirement specification document which we use as our starting point
for code design. Now in the design process if you may recollect we mentioned 2 phases, so when
we are going for code design we go for this design process in terms of 2 phases. The one phase is
the preliminary phase also called high level design phase, and the other one is the detailed design
phase also known as module specification document generation phase.

So these 2 phases primarily guide our approach to design of the code for implementation of the
system.
(Refer Slide Time: 10:29)
Now when we talk of the approaches, there are broadly 2 design approaches used for code design
one is function oriented. So in this case when we think of the design we think of the whole
system as a collection of functions, so the basic abstractions used in order to design the system is
the idea of functions.
(Refer Slide Time: 11:00)

The other approach is object oriented design approach in this case the basic abstractions that are
used to go for design of the system are objects, which in turn are instantiation of a concept called
class. Now earlier we learned in detail about DFD or data flow diagrams. As we mentioned this
is the language using which we can express the function oriented design of a system. So this is
primarily useful for functional design approaches and we learned various aspects of DFD.

We have covered briefly a related concept called entity relationship diagram which is useful to
represent data storage that are part of the design data storage elements that are part of the design.
(Refer Slide Time: 12:05)

In this lecture we are going to start our discussion on the other design approach namely object;
oriented design approach which is also known as OD. And in subsequent lectures we will also
learn about a design language that can be used to express such object oriented designs called the
UML or unified modeling language. Let us first learn about the basics, the basic idea behind
object oriented design approach, what we mean by objects and how we can use these concepts
for designing a system.
(Refer Slide Time: 12:47)
Let us start with the basic idea now when we are talking of object oriented design. Essentially
this is a different way of looking at the design problem. We are changing our way of thinking
about a problem vis-a-vis the functional or procedural approach. So earlier we learned about
procedural approach or the functional approach both are same. When we learned about that
approach intuitively we thought about the system as a collection of functions.

Here in object oriented design we are actually changing the way we think about a problem. Here
our basic constructs become objects rather than functions as we shall see in the subsequent part
of this lecture.
(Refer Slide Time: 13:44)
To understand the idea let us consider an example, let us consider a library management system
so as the name suggests this system is meant to manage the operations that take place in a library.
And suppose we are given the task of designing this system: how we can design the system, what
the basic units are and; how they are related to each other. Let us try to address this design
problem from both; the point of view or both the approaches namely the functional approach as
well as the object oriented approach to better understand the difference between these 2 design
approaches.
(Refer Slide Time: 14:33)
Let us start with the functional design approach for library management system design, as I said
functional approach is also called procedural approach so procedure function these will be using
interchangeably they are the same. When we are trying to design the library management system
with the help of a procedural or functional approach there we can come up with a design that
consists of a set of functions, what can be those functions.

Before we go into that, what does this signify? Let us try to understand that this signifies that we
think of the system as a provider of a set of services. Now this is very important so when we are
approaching a problem of system design and if we are taking help from a functional design
approach then intuitively we think of the system as a provider of a set of services which are
represented as functions. So that is our basic thinking that goes behind the design.
(Refer Slide Time: 15:56)

So in the case of the library management system then what are or what possibly can be the set of
services represented as functions, let us try to enumerate a few important such services. One can
be the service for registering a new user; so it essentially means that the system should provide a
service of registration to the system for a new user. Similarly we can think of another service that
issues a book, so this is a service of issuance of a book to a user.

Third service can check availability. This refers to the service of knowing availability of
particular books so the system should allow the user to know which books are available for
borrowing. There can be many such similar services that the system can provide and accordingly
we can come up with a functional design for the system. We can take; request the DFD notation
to express that design.

Remember that in DFD we talked about processes so these processes are nothing but the
functions that the system supports or rather the services that the system provides that represents
those processes or functions.
(Refer Slide Time: 17:37)

In contrast to this approach, when we try to go for; designing the same library management
system using an object oriented design approach, what changes do we bring in? Let us try to
understand that. So here in case of object oriented design approach we no longer consider
services offered by the system, so those are no longer our primary concern. Rather what we do is
we think of the system as a collection of objects and their behavior that means. How they are
related to each other.

So earlier we are thinking of a system as provider of a set of services now we are thinking of a
system as a collection of objects and their behavior or rather how they are related to each other,
now this is the change in thinking
(Refer Slide Time: 18:41)
If we try to translate this idea into the design of the library management system, then let us see
how we can now represent the system or rather the design of the system. So here now then we
have to think of a set of objects that represent the design of the system not only a set of objects,
but also how they are connected to each other, together they represent the design of the system.
So earlier we thought of the library management system as a system that provides a set of
services to its users.

Now we are thinking of the library management system as a system that consists of a set of
objects and their behavior; that means how they interact with each other and how they are related
to each other.
(Refer Slide Time: 19:34)
Let us see a few important objects that we can define for this particular library management
system, one object can be a member object as the name suggests these objects refer to the
members who are part of the library. Then another obvious candidate for an object would be a
book, so a library consists of books so each book can be thought of as an object. So there is some
register maintained to keep track of the books and their borrowing history so that a book registers
can also be an object.

Similarly we can define other objects now not only these objects, how these objects are related to
each other, that is how members are related to book objects, how book objects are related to book
registers, how members are related to book registers; all these things we have to define or rather
design. To come up with a complete design of the whole system, now if we are able to do that
then what we are getting is an object oriented design rather than a functional design.

For example the behavior of a member object can be defined as a member object can issue a
book, book object, similarly behavior of a book object can be defined as a book object can be
issued by a member object, and a book object can have an entry in the book register object. So in
that way we can define their relationship, their interactions and so on to complete the design of
the library management system.
(Refer Slide Time: 21:31)
So I hope you got the basic idea of what is the difference between a functional design approach
and the object-oriented design approach. To recollect in a functional approach we think of the
system as a provider of a set of functions and accordingly we go for the design. In an object
oriented approach we think of the system as a collection of objects and how they are related to
each other and accordingly we go for the design. Now with that basic idea let us now try to learn
in a little bit more details the idea of objects and classes.
(Refer Slide Time: 22:10)

We will start with the idea of class, so what is a class whenever you are going for an object
oriented design approach and going for implementation of object oriented design you will come
across this term of class. So class is a generic definition of objects that is the simple definition of
a class. Now the class contains attributes and operations, now these operations are also known as
methods or member functions.

So there are several ways in which the operations are known. So in a class we generally have a
component called attributes and another component called operations.
(Refer Slide Time: 22:58)

So what are attributes, simply speaking attributes are the data part of the definition of a class, so
essentially it indicates the nature of data that an object can contain. So class is the generic
definition of an object and class contains attributes as one component attribute essentially refers
to the data that can be contained in the object, which results from the class.
(Refer Slide Time: 23:35)
Operations are the action part so there is the data part and the action part is captured in the
operation component of the class definition. Now these operations indicate the actions that can
be performed with the data, so there are 2 things one is the data and other one is the operations
that are allowed to be performed on the data. Now the data part is known as an attribute and the
operations that are allowed to be performed on the data are known as operations or member
functions or methods.

Now these operations or these actions that are allowed to be performed on the data essentially
define the behavior of the objects that result from the class definition, so essentially the
operations part defines the behavior of the objects. One important thing to note here is that these
actions or operations can be defined as private or public. That means some of the operations or
the operations that are defined as private can be performed by only a specific object and the
access to those operations are restricted to the object, whereas if some operations are defined as
public then other objects can also access those operations.

So in other words the private or public tag denotes who can perform the operations whether it
can be performed by anybody or any object or it can be performed by only a specific object.
(Refer Slide Time: 25:29)
Now let us try to understand these concepts in terms of some examples, so let us start with one
simple example that is let us try to define a class called any integer. So when we are defining a
class name class and giving it a name some conventions are generally followed so if the name
consists of 2 distinct words, then each word should start with a capital letter like shown here. If it
is a single word then that word should start with a capital letter. This is a general naming
convention and it is good if you can follow this.

Now this class can have attributes and operations so let us define an attribute to be an integer
value which is an attribute for the class any integer. Now here if you again notice we are
following one convention that is if it is a multi-word name for the attribute then the first word
should start with a small letter, and the second word should start with capital letter. Now for this
attribute we can optionally mention data type, initial value and so on that is also possible.

And let us define operations for this any integer class let us define only one operation which is
converted to character, again multi word name. So we are following the convention. The first one
is a lowercase letter starting with a lowercase letter but subsequent words start with uppercase
letters as shown here. And if we are defining a member function or operation then we have to
define its input as well as output.

So we can define in this case the input to be its integer value and output is a unicode character
value representing the character so that is the simple way of defining the class.
(Refer Slide Time: 27:48)

Now once this class is defined; recollect that we mentioned class is a generic definition of the
object, so any integer is a generic definition of the objects that result out of this class definition.
And when we instantiate the class with specific values then we get an object, so object is an
instantiation of class. That means assigning values to the attributes and initialization of
operations if required, so whenever we do that we get an object.
(Refer Slide Time: 28:32)

For example we can define 10 to be an object of class any integer here the attribute value is
instantiated with or initialized with the integer value 10 and also we have initialized its member
function. Now in this case you should note that although we are using the number 10 in this
manner, but 10 is not to be confused with a simple number it is an object that means to access its
value we have to use its attribute rather than simply using this value.

And also we can use its member function to convert this object to a character value that is also
possible by calling this member function convert to character. So these things we have to keep in
mind that when we are defining something to be an object then simply using the object will not
do. We have to use the attribute of the object if we want to get the value. And we have to use its
operations if we want to perform some operation on the object.
(Refer Slide Time: 29:52)

Let us see one more slightly complex example, let us define another class called circle; now here
we are using a single word name so it starts with an uppercase letter and since there are no more
letters so other letters are lowercase. We can define three attributes here now attributes can be
defined as private or public like operations. So suppose here we are defining these attributes to
be private so one is radius of the circle, note that here we have defined its data type that is
double.

Similarly we are defining 2 more attributes one is x coordinate of the center again type double, y
coordinate of the center again type double. So, all these are defined as private, which means only
the object of this class can access it, others cannot directly access these values.
(Refer Slide Time: 30:59)
Similarly we can define its attributes as public also we can then define few operations or member
functions or methods for this class circle. Let us assume that those are defined as public that
means other objects can access these member functions so there are four member functions we
can define. Set center as the name suggests this function is used to or rather this member function
is used to set the x and y coordinate of the circle.

Accordingly it takes 2 inputs x coordinate and y coordinate both are defined as double data type
and it does not return anything return type is void. Set radius sets the radius of the circle so it
takes a radius value defined as double as the input it also does not return anything return type is
void. Then we can define another member function as draw which does not take anything and
does not return anything; it simply renders the circle on the screen.

We can also perform some computation like area of circle does not take anything but returns a
double value which is the area value for the circle using the formula that we are all aware of.
(Refer Slide Time: 32:38)
So then to define or to get objects for this class what; we can do we can initialize the attributes
with some values and initialize the functions. So if we do that we will get circle objects each of
these objects will have a specific set of assigned attribute values. We can also use the member
functions to set the center of the circles, radius of the circles. You can calculate the area of the
circles, and we can draw it on the screen using the draw member function.

So the idea is that circle class is a generic definition it; does not refer to any specific circle
whereas circle object is a specific instantiation of the class. So if we say there is a circle having a
center at coordinate values 2 and 2 respectively, and having radius of 2 units. Then that is an
object of the class circle. Why it is an object is because we have instantiated the attribute values
of the circle class with these values center x coordinate 2 center y coordinate 2 and radius value
2, hence we have created an object of type circle.
(Refer Slide Time: 34:03)
So that is briefly the idea of class and objects. These are the basic concepts that we are going to
use in our subsequent discussion on object oriented design for systems. It is helpful if we know
some relevant or related terms at this stage. So broadly there are three terms that you may
encounter one is OOA or object oriented analysis which refers to creation of SRS where
explicitly we mention objects instead of functions, so if we do that then we refer to that activity
as object oriented analysis rather than simply requirement analysis.

Then we have this term object oriented design or od object oriented design also a very related
term is object oriented programming OOP, or OOP object oriented programming. Now you may
have encountered these terms before so it is always helpful to remember that object oriented
design and object oriented programming are 2 distinct terms without any relation to each other.
Object oriented design refers to the design approach that means designing the system in terms of
object and object oriented programming is implementation of the system using object oriented
programming languages.

It is not mandatory although it is generally used or followed. It is not mandatory that object
oriented design always uses object oriented programming and vice versa. So today in this lecture
what we have learned is basic concepts of object oriented design ideas of objects and classes. In
subsequent lectures we will learn about; in more details how to use these concepts to go for
design of systems.
(Refer Slide Time: 36:19)
Whatever we have discussed today can be found in this book fundamentals of software
engineering fifth edition you can refer to chapter 7 of this book to learn in more details these
concepts, that is all for this lecture I hope you understood the concepts we will continue this
discussion in the subsequent lectures hope to see you in the next lecture thank you and goodbye
you.
 Design & Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Module No # 05
Lecture No # 25
UML

Hello and welcome to the NPTEL MOOC’S course on design and implementation of human
computer interfaces lecture number 22. Where we are going to introduce a particular language
called unified modeling language, or UML which is suitable for object oriented design. If you
recollect we are currently discussing the interactive system development life cycle consisting of
several stages; the life cycle is designed to help develop interactive systems in a very systematic
manner.
(Refer Slide Time: 01:12)

In the development life cycle we have already covered in details the requirement gathering,
analysis and specification stage at the end of this stage we get an SRS document or software
requirement specification document. Then we have talked about this design prototype and
evaluation cycle consisting of these 3 sub-stages. Now this cycle is primarily meant for interface
design once we arrive at a stable interface design taking care of usability concerns we go for
code design.
So there this prototype and evaluation is not very important we concentrate on the design part,
currently we are discussing the design of code or system. Once that design is done; we go for
coding and implementation of the design followed by testing of the code. Then the whole system
is tested for usability with end users, and finally we go for deployment and maintenance stages.
(Refer Slide Time: 02:31)

So the design stage we started our discussion in the previous few lectures particularly related to
code design. Now if you may recollect we have mentioned 2 broad design approaches one is
function oriented design, other one is object oriented design. So earlier we talked about function
oriented design in details which relies on the idea of functions, so in function oriented design the
basic abstraction that are used for designing a system are functions.

In contrast in object oriented design basic abstractions are objects which are instantiation of
generic concepts called classes or class. So in object oriented design basic abstraction units that
are used are objects now earlier in the previous lecture we introduced the concept of objects and
classes in terms of some examples.
(Refer Slide Time: 03:34)
So the basic idea of object oriented, design have already been covered in the previous lecture.
(Refer Slide Time: 03:39)

In this lecture what we are going to do we are going to learn about UML or unified modeling
language which is used to represent object oriented design. Remember that earlier what we
mentioned is for any design activity there are primarily 2 concerns; where to start the design
process, and how to represent the design. In case of code design also these concerns are there
where to start as we have already seen the starting point is the SRS or software requirement
specification document.
And how to represent in the case of function oriented design we have seen that representation
language is DFD or data flow diagram, and also we have learned about in brief ER diagram or
entity relationship diagram together they can be used to represent function oriented design of a
system. For object oriented design again the starting point can be the SRS document and to
represent object oriented design we need some language.

So in this lecture we are going to talk about one of such languages which is basically a graphical
language called UML or unified modeling language. So let us see what; is UML what are the
notations and symbols used in UML and how we can use those notations and symbols to come
up with a system design.
(Refer Slide Time: 05:11)

As I already mentioned UML stands for unified modeling language so this is an acronym for
unified modeling language like DFD. We need a language to represent object oriented design
which can be achieved with UML, but remember that UML is one of many such languages but it
is the most popular one; so what we can do with UML.

Once we come up with a design or once we conceptualize a design we can use UML to visualize
the design specify the design construct its components and linkages and document various
artifacts that are part of the overall system. So using UML we can do a plethora of activities
including visualization documentation and specification.
(Refer Slide Time: 06:25)
In a nutshell what is UML? UML is a language that allows us to represent object oriented design,
how it allows us to do that it provides a set of notations. For example rectangles, lines, ellipses
and so on to create a visual or graphical, model of the system. So this is a graphical language like
DFD it allows us to create a graphical representation of the system using notations like
rectangles, ellipse, lines, and so on.

Like any other language it has its own syntax that is the symbols and sentence formation rules
and semantics that is the meanings of the symbols and the sentences. Of course this syntax and
semantics are different than the natural languages like English or Hindi or Bengali because this is
a different sort of language. But conceptually it also has syntax like any natural language and
semantics like any natural language.
(Refer Slide Time: 07:37)
One thing we should always keep in mind is that UML is not a design methodology, so we
should not have this impression that UML helps us to design. UML does not help us to design it
does not give us any guidelines or any hints for a good design; rather it allows us to express our
design. So that distinction should be always kept in the mind. It is nothing but just a language to
express object oriented design obtained using some other methodology.

So with UML we can only express a design with UML we cannot get any help for the design that
is the crucial thing we should always keep in mind.
(Refer Slide Time: 08:39)
So with UML we can do several things broadly it allows us to create diagrams to capture
different views of the system. So essentially we look at the system from different points of views
and UML allows us to create those views using diagrams it supports 9 such diagrams to capture
5 different views of the system.
(Refer Slide Time: 09:16)

So what are those views and diagrams first is user view, how a user perceives the system. So the
system can be viewed from the point of view of the user and UML provides that view in terms of
use case diagrams. Then we can have a behavioral view of the system that means how the system
components behave during execution of the system. To get the behavioral view different
diagrams are there and UML supports different such diagrams; such as sequence diagram,
collaboration diagram, state chart diagram, activity diagram.

Any of these diagrams can be used to represent the behavioral view of the system; that means
how the system behaves during runtime. Then we can have a structural view how the system is
structured around its units for that 2 diagrams; are there supported by UML one is class diagram,
one is object diagram. Then we have implementation view and for representing this view we can
make use of the component diagram.

Finally we have the environment view and this view can be expressed in terms of the deployment
diagram. So these are the 5 views that are supported by UML user view, behavioral view,
structural view, implementation view, and environment view. And in order to represent these
views 9 diagrams are there which can be used. Use case diagram can be used for user view; any
of the 4 diagrams sequence diagram, collaboration diagram, state chart diagram, and activity
diagram can be used for representing behavioral.

View any of the 2 diagrams class diagram or object diagram can be used to represent structural;
view component diagram can be used to represent implementation view. And finally the
deployment diagram can be used to represent environment view. Among all these views and
diagrams in this lecture we are going to restrict our discussion to few of the views and diagrams,
which are most important.
(Refer Slide Time: 12:01)

Namely we will learn about what is an, user view and how to use that, how to represent that view
using the use case diagram. Similarly we will learn about behavioral view and how to represent
that view using sequence diagram. So among all the 4 different diagrams that can be used to
represent behavioral view we will learn about sequence diagram. And we will also have a look at
the structural view of the system in terms of class diagram, object diagram we are not going to
discuss in this lecture. So let us start with the first view that is user view what it means and how
it can be represented using the use case diagram.
(Refer Slide Time: 12:55)
When we are talking of user view the idea is that we want to represent user perception of the
system; that is how the user perceives the system. Note that this is different from the developer
perception of the system, where developer is mostly concerned about the internal working of the
system whereas users are mostly concerned about how input can be provided and outputs are
generated.

Now to represent users, perception in UML we can make use of dialogue or conversation
between the user and the system to express interaction between these 2 entities, namely the user
and the system.
(Refer Slide Time: 13:42)
So use case diagram is nothing but representation of the dialogue between a user and the system.
Now in order to capture that in order to capture the interaction we need some so what are the
basic components for use case diagram there is this actor component represented with a stick
figure, what is that we will see so shortly in an example. Then we have system boundary, so one
is actor one is system boundary then use case represented as ellipse, and finally the main line and
alternative sequences.

So there are primarily these 4 components which makes up the use case diagram actor
represented with a stick figure, system boundary, use case represented with ellipse, and the
concepts of mainline sequence and alternative sequence. Let us try to understand what these
components mean and how they can be used to represent use cases.
(Refer Slide Time: 15:02)

Let us try to understand that in terms of one example, suppose this is one system which allows a
store to manage price awarding scheme. Let us call it supermarkets price scheme that means, if
some customers come to the market they can participate in some lottery and win some prizes.
This is the system now from the point of view of the users, so who are the users in this case there
can be broadly 4 types of users which are very apparent.

One is the customer, one is the sales clerk, one is the manager, one can be a regular clerk. Of
course you can think of more or less number of stakeholders or users but let us stick to these 4
types of users for the system. So for customer there can be one use case; that is register customer
for sales clerk, one use case can be register sales for manager, it can be select winners. Register
customer can be use case for the clerk type of user also.

Now here you can see that these users are represented with stick figures like this one, the use
cases are represented with ellipse like register customer, register sale select winners. The whole
system is represented with this rectangle with boundaries shown in red lines, so this is the system
boundary. And there are these lines from the user to the, use cases indicating which use case is
meant for which user.

If there is only one user and one use case of course and that will be very apparent, and we can
simplify the notation; otherwise we have to make use of this type of notation. So as you can see
there are 4 users and 3 use cases we can think of, now that is the user's point of view. Now to
represent the actual interaction between the user and the system we need a dialog that dialog is
called mainline sequence. And if there is some deviation in the dialog which needs to be taken
care of then we call it alternative sequence.
(Refer Slide Time: 17:44)

For example consider the use case register customer, for the customer user; so using this use case
the customer can register him or herself by providing the necessary details. Now from the
customer's point of view what should be the interaction with the system; what should be the
interaction, and if there is some issue then what should be the interaction. So ideal interaction is
called main line sequence, assuming there is no problem in the ideal interaction.
Customer selects the register customer option from the interface then the system responds by
displaying a prompt to enter the details like name, address, and telephone number. Then
customer enters all the necessary details as prompted by the system finally the system displays
the generated id customer id and the message that the customer has been successfully registered.
So ideally this should be the interaction and this should be the view from the point of view, of the
user.

However if there is some issue with this sequence then we have to go for alternative sequence.
Now in step 4 some deviations may happen, for example at step 4 of the main line sequence the
system may display the message that the customer has already registered no need to re-register.
So in mainline sequence ideally it should generate id and display the message that registration is
successful.

So the message that the customer is already registered, so in that case mainline sequence will not
be followed in totality 1, 2, 3, 4 up to this point it will be followed then this dialogue will be
followed. There may be further deviations as well like at step 4 of the main line sequence system
may also display the message that some input information has not been entered, so the system
displays a prompt to enter the missing values.

So in ideal case mainline sequence should be followed if the case is not ideal, then either of
scenario 2 or scenario 3 it should be scenario 3 so either of scenario 2 or scenario 3 should be
followed; now these are called alternative sequences. So this is how we can represent the user
view using the use case diagram, so the diagram consists of the stick figures, the lines, the
ellipses, and the system boundaries which is accompanied by this main line and alternative
sequences. I hope the idea of the user view and the use case diagram is clear with this example.
Let us now move to the next view that is the behavioral view of the system.
(Refer Slide Time: 21:02)
So once we are able to identify the use cases and represent the use cases using the use case
diagrams, what is next; what to do after the use case identification. Remember we are using an
object oriented design approach, so our next objective should be to identify objects and classes
and how they interact. So our next objective is identify, the objects and the classes that represent
those objects.
(Refer Slide Time: 21:36)

Identification of objects from the use case diagram is definitely not very easy task so, how we
can do that? If we have experience of doing such things, or we can rely on our intuition, or we
have some domain knowledge. Then definitely those are helpful but if we do not have any of
these or our experience is not sufficient, or domain knowledge is not sufficient then we may face
problems.
(Refer Slide Time: 22:15)

Then can there be some systematic approach? There can be one very simple and systematic
approach called domain modeling approach. Using which we can identify some simple objects,
and then from there we can go for class definition for those objects. So domain modeling is
nothing but a simple and systematic approach to determine classes and objects, here the idea is to
identify obvious domain objects and their relations.
(Refer Slide Time: 22:45)
Now what are domain objects; there can be broadly 3 groups of domain objects one is the
boundary objects, these are the objects with which the actors interact for example screen, menu,
etc now these objects can be identified from use cases. So once we are ready with our use cases
we can immediately identify the boundary objects. The next category of objects; are the
controller objects; these are objects that coordinate activities between the boundary objects and
another class of objects that is called the entity objects.

So what are these entity objects, these are objects that normally hold some information so in our
system if we are using some data storage or information storage we can label them as entity
objects. For example a book, book registers and so on; so earlier we are using the term data
storage now we will be using the term entity objects to represent those objects.

So this is the idea of domain objects broadly 3 categories boundary, controller, and entity objects;
boundary objects are easy to identify from use cases, also entity objects are not very difficult to
identify. And once we are able to identify these 2 we can come up with intermediate objects that
connect these 2 types of objects which we call controller objects.
(Refer Slide Time: 24:16)

So the key thing to do is to identify domain objects for each use case, once we identify all the use
cases for each use cases we have to act separately and identify these 3 types of domain objects.
Then we need to combine them together to come up with a combined set of objects for the
system. It may so happen that in this combination some objects are repeated it is quite likely,
because there may be similar objects in different use cases. So we have to be careful and remove
those repetitions from the combined list of objects.
(Refer Slide Time: 25:09)

Once we are able to create the list of objects our next task is to create an interaction diagram for
each use case execution scenario. Why we need this diagram to represent the behavioral view of
the system that is how the system behaves during execution, in other words how the objects
interact with each other during execution of the system. Now that behavioral view we can
represent with an interaction diagram,

Remember that we mentioned several such diagrams sequence diagram, collaboration diagram
activity diagram, state chart diagram, any of these diagrams we can use to represent the
interaction between objects. Now this diagram can be useful to refine the list of objects and also
to identify classes by clubbing together similar objects. So these are the primary 2 purposes for
creating an interaction diagram between the objects which represent the interaction between
them during execution of the system.
(Refer Slide Time: 26:12)
So interaction diagrams captures dynamic system behavior again it is advisable to go for one
diagram per use case, later on we can merge this diagram together to avoid repetitions. Already I
mentioned that there are many such types of diagrams sequence diagram, collaboration diagram,
activity diagram, state chart diagram; out of these we are going to briefly learn about sequence
diagram.
(Refer Slide Time: 26:55)

With one example like we did for use case diagram so this image shows a sequence diagram for
a system, an imaginary system, a game system a video game. Now as you can see on top within
rectangles we have marked certain things, these are essentially the objects that we have identified
from the use cases. Exit menu option is a boundary object, exit controller object, then game
instance which is another object, and game records that is an entity object.

So suppose we have identified these 4 objects using domain modeling approach, for each object
we have created one vertical bar, like shown here. Now these bars are having some significance
what they signify as you can see there are 4 bars each representing one of the objects. And the
bars are of unequal length now this bar length indicates the life span of the object during
execution of the system.

In this image, in this diagram as you can see the exit boundary object has the maximum length
that means it remains active for the maximum duration of execution. Exit controller object has
somewhat lesser length than the exit boundary length that means it dies or becomes inactive
before the exit boundary object. So boundary object may remain active but the controller object
remains inactive after performing its assigned tasks.

The game instance object is even more, short which means it dies quote, unquote dies before the
boundary and controller objects. And finally the records object is the shortest which dies before
all the other objects the arrows as shown here indicates the messages that goes or passed between
the different objects. So each arrow is labeled with some text which indicates the message name.

For example exit game is a message sent to the, exit boundary object accept message and exit
application are 2 messages passed between boundary and controller objects save game is a
message passed between game instance and game records objects and so on. So we have
basically these notations namely rectangles on top indicating the name of the object vertical bars
indicating the life span of the objects; and message passing between them using arrows with
labels, the direction of the arrows indicate the direction of the message.

So this essentially indicates the behavior during execution that is how long an object remains
active; what messages are passed between objects and so on. So this is the behavior that we
capture diagram which is sequence diagram, same behavior we can capture with other interaction
diagrams that is collaboration diagram, activity diagram, state chart diagram etcetera.
(Refer Slide Time: 30:49)
So what we have learnt so far, so the sequence to be followed to create a design and represent
using UML when we are using an object oriented design approaches. First we go for use case
analysis and then get the user view with the use case diagram. From there we use domain
modeling, to go for identification of objects and those objects are then used to create an
interaction diagram which can be any of sequence collaboration activity or state chat diagram to
get the behavior of the system during execution.

So if we follow this sequence then we will be able to identify objects, classes, and their behavior
over a period of time essentially during execution of the system. Of course this is easier said than
done it requires many iterations and good amount of experience to find out the objects and create
the behavior, it is not a very easy thing to do. Once we manage to get the behavioral view what
next?
(Refer Slide Time: 32:06)
Next we need to go for representing the structure of the design that means classes and their
relationships. So earlier we talked about objects and how they interact with each other during
execution that is behavior. Now behind the objects there are classes and the classes are related to
each other with some relations we need to capture that, so use case analysis and interaction
diagrams help us to identify objection from their classes.

Then we need to represent these classes and their relationships in some form or we need to
represent the structure of the system, so that is our next step, let us see how we can do that. So
next we will go for creating a structural view of the system.
(Refer Slide Time: 33:02)
Now the structural view we will create using one type of diagram called class diagram. A class
diagram describes static system structure, unlike interaction diagram which represents a temporal
interaction between objects during execution of the system. Now class diagrams, consists of
classes, and their relationships let us try to understand these concepts, with respect to some
examples.
(Refer Slide Time: 33:46)

First of all recollect from our previous lecture the idea of class we said that a class has a name
with some convention followed attribute which contains the data values. And some operations or
member functions again with some naming conventions and input and output specified. Now this
class we can represent it in this rectangle with 3 cells name, attributes, and member function
names, so that is how we can represent classes. Once we are able to represent classes we can
represent the relationships between the classes.
(Refer Slide Time: 34:34)
What are the relationships that can exist between classes several relationships can be there
association, aggregation and composition. So classes can be related with association relationship
they can be related with aggregation relationship or the whole part relationship. And they can be
related with the composition relationship that is a stricter form of the aggregation relationship.
(Refer Slide Time: 34:54)

Let us learn about the association relationship, now association essentially describes connection
between classes we can use the concept of links to represent instances of association between 2
objects. For example suppose a person named Ramesh borrowed a book named operating
system, so here borrowed can be considered to be the link between objects Ramesh. Which can
be an instance of the; class student and operating system which can be the instance of the class
book.

So we have 2 classes, student and book, and 2 instances Ramesh and operating system; these 2
instances can be connected with the association relationship or a link called borrowed. So
association essentially describes a group of links with common structure and common semantics
that is how this relationship is defined, a group of links with common structure and common
semantics.
(Refer Slide Time: 36:12)

Usually association is a binary relation, that means between 2 classes however it is possible to
have 3 or more classes to have this relationship, but that is not very frequent mostly it is a binary
relationship. A class can have an association relationship with itself that is also possible which is
called recursive association, where the assumption is 2 different objects of the class are linked by
the association relationship.

So this is a concept related to the association relation how we can represent the relationship;
remember that in UML we need some notation for graphical representation of everything.
(Refer Slide Time: 37:08)
So for association we can use such a notation. We can use a straight line between classes where
the name of the relation is written alongside the line. So it is a labeled line like; shown here this
is a book class, and this is a member class and this straight line indicates the association relation
borrowed by an arrowhead may be placed to indicate direction of association like shown here, it
is advisable to show the direction.

Now on each side of the line a concept called multiplicity is mentioned, this indicates, like here
we have mentioned 1 and star. Now this indicates number of instances of one class associated
with other value ranges noted by specifying minimum and maximum separated by 2 dots; like 2
dot, dot 4 so we can also specify value ranges rather, than a single number. And if we put an
asterisk it is a wildcard notation and means many.

For example when this asterisk is put here it indicates that a member can borrow many books,
that is, the idea of this multiplicity notation placed alongside the line that is about association.
(Refer Slide Time: 38:42)
Next comes aggregation relationship this is a special type of association where the involved
classes represent a whole part relationship. To represent such a relationship a separate symbol is
used a diamond symbol at the whole end of a relationship. For example consider this example,
we have a bag class, a book class and pages class; now between pages and book there is a whole
part relationship.

So pages are part of book it means that one book can contain many pages, similarly between
books and back there is a whole part relationship which indicates that one bag can contain 5
books. The notations and symbols are mostly same with association except the use of the
diamond symbol instead of an arrow.
(Refer Slide Time: 39:43)
Finally comes the composition relationship; this is a stricter form of aggregation relationship
note that aggregation is a stricter form of association and composition is a stricter form of
aggregation. Here parts are existence dependent on the whole that means when the whole is
created parts are created and when the whole is destroyed parts are also destroyed they no longer
exist. For example we can define the relationship between the 3 class’s bag, book and pages in a
slightly different way, between pages and books we can define a composition relationship.

That means when a book is created the pages are created and when a book is destroyed all the
pages are destroyed. However between book and bag we need not define composition
relationship, that means when a bag is created books need not be created and when a bag is
destroyed books inside the bag need not be destroyed it is up to us how we define the
relationship between classes.

So between book and bag we can keep the aggregation relation and between pages and book we
can have the composition relations. Now here as you can see there is slight change in notation, so
for aggregation we use diamond now for composition, to indicate composition relationship we
use the field diamond at the whole end. That means here between pages and books book is the
whole pages are part of it. So at the book end of the relation we place this diamond field diamond
to indicate that the relationship between them is a composition relation.
(Refer Slide Time: 41:36)
This is one example class diagram showing the structure of the system where we have used the
rectangles to represent the classes class name and in this part we will keep the ideally we should
keep the attribute and member function details as shown in the earlier example. Then we have
these notations, various notations used multiplicity values range aesthetics even single numbers
as shown.

So the relationship between classes with this aggregation composition and association notations
are represented this is an again a hypothetical and imaginary system model represented with the
class diagram. If there is a positive space in the diagram that means we are unable to keep the
attribute and member function details within the rectangle then it can be mentioned separately as
shown here.

Like for this game class these are the attributes and these are the methods with input, output
details and the permission details, that can be also another way to represent the classes. And then
in the diagram simply show the relationship between them both are okay. Here is shown that
class details with members functions and they are explained here separately rather than doing the
same thing here itself because there is less space.

So you can create this diagram and you can separately create these details to represent the
classes. So that is in summary what we can do with class diagram, we can represent the classes
and the relationships between them in terms of the 3 types of relationships association,
aggregation and composition. So let us summarize what we have learnt so far.
(Refer Slide Time: 44:01)

If we want to follow an object oriented design approach and come up with an object oriented
design for a system we can use UML notations to represent the design. However to create the
design we can follow certain methodology like we can follow guidelines or create SRS using
requirement analysis, to come up with use case diagram. From SRS we can create domain model
also or from the use case diagram we can create domain model.

Now again from use case diagram or the domain model we can go for interaction diagram in fact
both we require to, create the interaction diagram use case diagram and the domain model. And
again domain model and interaction diagram both can be used to create class diagram and the
class diagram gives us the design of the system.

So we can make use of guidelines as well as SRS to go for use case diagram, use the use case
diagram as well as SRS to go for domain model; use the domain model as well as use case
diagram to go for interaction diagram. Use the interaction diagram as well as domain model to
go for class diagram and that gives us the design of the system. So we can follow this approach
to come up with a object oriented design of the system and use the UML notations to represent
that design.
In UML we learned about 3 views user view, behavioral view, and structural view and 3
diagrams to represent those views. Namely the use case diagram to represent user view, sequence
diagram to represent a behavioral view, and class diagram to represent structural view. All 3
together give us the overall system design. Remember that if we are designing or trying to
express a design of a system we need all these views not a single view.
(Refer Slide Time: 46:18)

Whatever I have covered today can be found in these book fundamentals of software engineering
you may go through chapter 7. I hope you could enjoy the topic that has been covered today in
this lecture later on we will try to understand these concepts in terms of one case study looking
forward to meet you soon in the next lecture thank you and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology, Guwahati

Module No # 05
Lecture No # 26
UML Case Study

Hello and welcome to the NPTEL MOOCs course on design and implementation of human
computer interfaces lecture number 23 where we will discuss about a case study on creating a
design document based on object oriented design approach using UML. In the previous lectures
we have learned about the object oriented design approach we have also gone through the basic
concepts of creating a design using the object-oriented design approach and representing the
design using a language which is UML or unified modeling language.

In this lecture we are going to see a document that is created using UML for a particular system
so the objective of this lecture is to demonstrate how to create a design document? Where we are
using object oriented approach and representing the design using the language UML.
(Refer Slide Time: 01:50)

This is about developing a game for learning. So, the name of the system is game based learning
so this is the cover page of the design document this is a software design document with a
creation date mentioned. So ideally the date should be mentioned when the document is created.
And the creators that are created by the name of the designers who have created this design
document. The date need not be a single date instead here it can be a history of fast creation then
revision, then refinement and final document creation date.

So this whole historical phases can be recorded or the first creation date can be recorded ideally
the historical evolution should be recorded in the form of different dates.
(Refer Slide Time: 02:52)

The cover page is followed by a table of content where different sections that are present in the
document are mentioned as shown here. Introduction, glossary of terms, use cases, class
diagrams, interaction diagram in the form of a sequence diagram and optionally flow chart for
the system. In the introduction if you may recollect earlier also we have seen 1 case study on
SRS document similarly here in the introduction it is desirable that we keep these sections.
(Refer Slide Time: 03:33)
General introduction this software design document is a document to provide documentation
which will be used to aid in software development by providing the details for how the software
should be built? Some general statements are written within this design document there are
narrative and graphical documentation of the software design for the project including use case
models sequence diagram class diagram and other supporting requirement information.

This is followed by purpose statements what is the purpose? The purpose of the document is to
provide a description of the design of a system fully enough to allow for software development is
to proceed with an understanding of what is to be built and how it is expected to be built. This
document provides information about touch based user interface which will guide student to
learn different sorting algorithms this is the objective for this particular system that is mentioned
under this purpose section.

This document is intended for both the developers and students or other users of the system.
Scope of project another important section ideally should be there in the design document this
software system will be a virtual game based learning system intended for students wanting to
learn different sorting algorithms. The system will help students learn while playing using touch
based mobile interface a teacher also can use this application as a supplementary for teaching
sorting algorithms. So the introduction section contains the basic objective as well as intended
users for the system.
(Refer Slide Time: 05:27)
Some references can optionally be mentioned ideally it should be there like tools that are used
for creating the diagrams other sources that are used to create the document these things can be
listed under the reference section as shown here. And there can be an overview of the document
the document is divided into 11 sections with various subsection. The major sections are
introduction, glossary, use cases class diagrams and sequence diagrams.

This is an overview of the whole document which can be there in the introduction section the
next section is the glossary of terms that are used in the subsequent document.
(Refer Slide Time: 06:20)
For example in this document there are 5 important terms that are used cube which is a 3D object
with number engraved on it. Cube array list of 3D objects with numbers engraved on each of
these objects. Bucket 3D object which can hold numbers on it. Bucket array list of buckets or 3D
objects which can hold numbers and main menu which is the screen containing these options
play game manage setting show leaderboard and exit games so what each of these mean will be
clear in subsequent part of the document.
(Refer Slide Time: 07:11)

Then, comes the main portion of the document namely use cases remember that in object
oriented design we focus on objects. And while representing the design there are 3 major views
that we discussed the use case view, the behavioral view, and the structural view. The use case
view relies on use cases so for this particular application that is game based learning let us see
what are the use cases mentioned in the document?

Actors or player now who is a player a student is a user or player who wants to learn different
sorting algorithms using touch based mobile interface this is how a player is explained in the
design document itself. Now remember that here we are just mentioning student but the same
system can be used by teachers as well so teacher can be another player however in this
particular design document will not cover the design aspects for teacher.
We will focus only on student as users. So if that is the case that is students are the users what are
the use cases for a student play games there are 4 use cases mentioned one is play games, then
leaderboard, manage settings and exit game.
(Refer Slide Time: 08:56)

The use cases are listed now we have to create the use case diagram if you recollect there are
several components in the diagram namely the stick figure which represents the actor. The
ellipses which represent the use case the system boundary and the lines. So this 4 use cases are
captured in this diagram use case diagram here is the actor represented with the stick figure then
these are the ellipses there are 4 such ellipse play game, manage setting, show leader board, and
exit game.

Note that there need not be any order in which these 4 are placed it can be of any order. Because
this placement does not indicate any; ordering between the different use cases. Now these 4 use
cases are enclosed within this rectangle which represents the whole system for a student user.
(Refer Slide Time: 10:02)
Next thing is for each use case we are supposed to come up with the main line sequence and if
required alternative sequence. Let us start with the first use case that is play game now in this use
case using this use case the player can start playing the game so that is the use case so for this the
main line sequence how it looks like according to the design proposed. One thing we have to
keep in mind is that this sequence may be different depending on the designer. So whatever the
designer feels that is captured within this sequence it needs not be unique.

So, designer one can have 1 mainline sequence whereas designer 2 can come up with a different
mainline sequence so here in the main line sequence according to this particular design there are
several steps first player or the actor selects the play game option then the system displays
prompt for the player to input name and age. Then the player enters the name and age then the
system displays a message that player profile created successfully.

And, a prompt to choose among; the 4 sorting algorithms insertion sort, selection sort, bubble
sort and radix sort. So, in this game there are these 4 algorithms sorting algorithms using which a
player can learn different sorting algorithms. After that the player selects one of the 4 algorithms
then system displays the pseudo code of the selection algorithm with a start option to decide
when to start playing the game.

Next player launch the pseudo code of the algorithm and press or select start button when ready
to play the game then the system then the system starts the game by generating and displaying a
random set of numbers placed on 3D cubes and setting of the timer. So, there is 1 timer which is
set up at this point player then start playing the game by making the moves swap 2 cubes put a
cube or a set of cubes in a bucket and pick them up back from the bucket as is necessary for the
relevant sorting algorithm.

System then moves the cubes as dictated by the player with a submit button to evaluate the
player's current configuration of the array of numbers when the player finishes making the
moves. Player then selects the submit button when done with making the necessary moves for a
particular iteration. System then evaluates the submitted configuration of that particular iteration
and award points based on the following criteria that is if the submitted configuration is correct
award the player plus 10 points.

If the configuration is incorrect deduct 10 points from the player score and show the player the
correct sequence while also setting the next configuration of the array to the correct sequence.
(Refer Slide Time: 13:26)

Then player keeps making the moves until the array is sorted as per the player's understanding
and submit the final configuration of the array. Next the system evaluates the final configuration
and awards points using the same criteria as that applied to any other move and display end of
game also calculates the player's final score displays it and enters it into the leaderboard if the
score is among the current top 5 scores.
Then, displays a prompt to allow the player to; choose between the following options new game
to start a new game, main menu to return to the main menu. Player then selects one of the 2
options displayed system then does the following if the player selects the new game option then
return to step 10 if player selects the main menu option return to step 0 or at the beginning of this
sequence that is the main line sequence as per this particular design document.

Now, there are some alternative sequences mentioned as well at step 4 of mainline sequence. The
system displays message user already exists if there exists a user with the input name and then
display a prompt to choose among the 4 sorting algorithms. In another scenario at step 4 of
mainline sequence the system displays the message that some input information has not been
entered the system then displays a prompt to enter the missing value.

Another scenario is at step 13 of mainline sequence here the player selects restart option to
restart the current game and the system restarts the game with the same initial configuration as
that of the current game and move to step 11 of the main line sequence. Another alternative
sequence at the same step 13 can be the player selects the main menu option to end the current
game and return to the main menu. Then in that case system ends the current game and return to
the main menu without calculating player's scores.

Again at step 13 another alternative sequence can be player selects the exit option and the system
ends the current game and exits the application without calculating player score.
(Refer Slide Time: 15:54)
Then at step 14 of the main line sequence there can be some alternative sequence the system
displays time up when the timer has reached to 0. Though the final array configuration may not
have been reached at that point then computes the player's final scores based on the moves he
made before the timer is 0 and display it .then displays a prompt to allow the player to choose
between following options new game or main menu.

So, these are some of the alternative sequences that are mentioned for different steps the next use
case is manage settings. In this use case the player can manage the game environment variables
such as game music game sounds and see a how to play tutorial. Here the main line sequence is
designed as follows first player selects setting option system then displays a sub menu containing
sound music how to play and main menu options.

Player then selects one of the 4 options system then does the appropriate task depending on the
option selected if sound is selected then displays a slider bar to increase decrease sound. If music
is selected then displays a slider but to increase decrease music. If how to play is selected opens
an interactive session where the player is instructed to make moves as in a normal game and if
main menu is selected returns the player to the main menu.
(Refer Slide Time: 17:28)
The third use case is show leaderboard; here the player can see the leaderboard displaying the top
5 scores of the players. Here there is only 1 mainline sequence that is player selects the
leaderboard option and system displays the leaderboard which is nothing but a table containing
top 5 scores among all games played along with the name of the player besides each score a
single player's name can appear more than once in the leaderboard.

Player then selects main menu option and system returns the player to the main menu so there is
no alternative sequence. And finally exit game so using this the player can exit from the game
here there is a main line sequence which says that player selects exit game option system then
asks user if user is sure to exit the application so there is some confirmatory dialog player selects
yes option and system moves the user out from the application.

Now, there can be an alternative sequence at step 3 that means here player select no option and
system stays in the main menu these are the 4 use cases with mainline and alternative sequences.
Our next task is to create a behavioral view for these use cases. In the behavioral view we have
to identify the objects and create interaction diagram for the objects.
(Refer Slide Time: 19:03)
Now, that behavioral view will come later before that let us see the structural view with the
classes and the relationship between the classes. This figure shows the structural view these are
the classes evaluator, leaderboard, game, user, cube, bucket, sorting, environment, selection,
bubble, radix, insertion sort these are the class names given now here we are not trying to figure
out whether the class names or the classes or the number of classes are optimum, perfect, good
anything.

So this is just a case study on design of the classes and design of the class diagram which is the
structural view of the system design. So these classes are connected with arrows indicate the kind
of relationship association or aggregation or similar such relationships as we have discussed in
the previous lecture. As you can see different types of notations are used the field symbols here
simple arrows to indicate the type of relationship along with the numerical values indicating the
details of the relationships as discussed in the earlier lectures.

So along with this diagram we also need to show in detail the classes their details namely in
terms of their attributes and member functions that is done separately because in this diagram
everything cannot be shown as that will create a very complex diagram.
(Refer Slide Time: 21:10)
So, the class definitions are added separately in the document for example the game class shown
here. So, for this game this is the details having attributes there are 5 attributes or data values and
there are 7 member functions. So that data members are player score created at sorting and
duration whereas methods are get player, set player, get score, set score, set duration get sorting
type and set sorting type.

For each method some more details are given like say for example get player, whether it takes
any argument no argument return value returns an object of the user class description get player
method is used to obtain the entire details of the user which are associated to the object of the
game class called by method is called by the main program or activity. It calls get name and gate
age methods of the user class.

So, all these details are mentioned separately for game class also in the actual definition you can
see the type of data that can be there in the attributes so player is user type data, score integer
type data, created at time data, sorting data, duration another time data.
(Refer Slide Time: 23:16)
Similarly for this class other member functions are described in details in terms of parameters,
written value, description called by and calls which are the function that it calls. So, for all such
all functions or all member functions those details are provided.
(Refer Slide Time: 23:37)

So there are 7 member functions so 7 such set of details are provided.

(Refer Slide Time: 23:47)
Next is leaderboard class it has 1 attribute games played top score and it has 3 member functions
set new entry, get top 10 cores and clear history. Like before for each method or member
function the details are provided for example set new entry function parameters objects of game
class game which have just ended return value null or void. Description this method will first
check whether the score of the game played is among the top 10.

If available score if yes then it will store the game in the top 10 score games data member. If less
than 10 games are available then the check will be made among all the available games in the top
10 score games array. In case of tie priority will be given to the game class object which was
created before. So, this summarizes the things that this member function does it is called by the
destructor of the game class. And it calls other functions such as get sorting type get player gate
score method of the game class so the dependencies are clearly specified under the description.
(Refer Slide Time: 25:24)
Similarly, for other member functions of the class similar descriptions are provided for all the
other classes.
(Refer Slide Time: 25:36)

Cube class having 3 attributes and 6 member functions.

(Refer Slide Time: 25:44)
Bucket class having 2 attributes and 4 member functions.
(Refer Slide Time: 25:53)

Evaluator having 2 attributes and 1 member functions.

(Refer Slide Time: 25:58)
Sorting having 1 attribute and 2 member functions.
(Refer Slide Time: 26:06)

User class having 2 attributes and 4 member functions.

(Refer Slide Time: 26:11)
Environment having 2 attributes and 4 member functions.
(Refer Slide Time: 26:16)

Bubble chart having 2 member functions only no attribute.

(Refer Slide Time: 26:22)
Insertions are having 1 attribute and 4 member functions.
(Refer Slide Time: 26:28)

Selection sort having 2 member functions no attributes.

(Refer Slide Time: 26:33)
Radix sort having 1 attribute and 3 member functions. So that gives us a structural view of the
system in terms of classes and their relationships with detailed description for each of the classes
including description of the attributes and description of the member functions. As you can see
this is how we can give the details there can be 1 diagram only mentioning the names of the
classes and their relationship and separate entries for details for each class.

And in the details we have to keep give details of the attributes as well as member functions for
member functions we have to give detailed information regarding its input, output, dependencies
and the algorithm or what it does exactly in the form of description.
(Refer Slide Time: 27:43)
The next thing that we should do is we should create a behavioral diagram that mean how the
objects that are instantiation of these classes behave while the system is being executed. That we
can do in terms of sequence diagram which we have learned earlier. So here what we can do is
create sequence diagram for each use cases in terms of objects on top we have mentioned the
object names as you can see here.

So, there are 1, 2, 3, 4, 5, 6, 7 objects for this use case as identified by the designer again these
are not unique diagrams. So, for the same use case a different designer or a team of designers can
choose different sets of objects and accordingly can come up with a different sequence diagram
so there is nothing unique about these diagrams for each object the life span is shown by the
length of the bar that represents the object.

For example, the first object has the maximum lifespan, and then the second object gets created
and destroyed periodically as shown with these individual bars that are true again for the third
object up to this point. The fourth object again optionally gets created and periodically gets
created and destroyed 3 such are there. For fifth object there are 2 such occurrences. Sixth object
gets created and destroyed within this range as shown with this bar. And the seventh object is the
one with list life span gets created once and destroyed as indicated by this particular bar with its
particular position. And the arrows indicate the interaction between the objects when they are
alive with the direction indicating the direction of message passing so this is for play game.
(Refer Slide Time: 30:04)
For show leaderboard use case this is the sequence diagram there are 3 objects the first object has
the maximum life span followed by the second object followed by the third object. For use case
manage setting again there are 3 objects first object with maximum life span followed by the
second object which is followed by the third object note that here the objects are created based
on the domain model so we have boundary objects, entity objects and controller objects.
(Refer Slide Time: 30:40)

And finally we have the exit game use case for which there are 4 objects first one is having the
maximum life span then the second one followed by the third object and the fourth object is
having the least life span. So, what these diagrams indicate is that when this particular use case is
being executed that means when suppose the user is exiting the game or the user is playing the
game.

Then the particular objects belonging to the appropriate classes those get created destroyed as per
the diagram and those interact with each other as per the sequence diagram or as specified in the
sequence diagram. So, these diagrams indicate how the objects that are result of instantiation of
the classes which we have seen in the structural diagram how these objects behave while a
particular use case is being executed.

While we are learning the concepts of UML and the different views and the diagrams we
mentioned that a right way to do is to first identify the use cases for each use cases create this
behavioral diagram. And get the list of objects and then merge them together to come to the
structural diagram however in this design document as you can see that sequence is not followed
instead first the use cases are identified then structural view is created.

And then the behavioral view is created this is also all right it is not that only the first approach
should be followed however it sometimes helps if we first identify the objects and from there
generalize the classes. But it is up to the designer which path to follow whether first use case
then structural followed by behavioral diagrams or first use case diagrams followed by
behavioral diagrams and from there come to the structural diagram both are all right.
(Refer Slide Time: 33:06)

So, that is in a nutshell what should be part of the design document when we are creating a
design based on the object oriented design approach and representing it using UML. So, we have
to include the use cases with use case diagram mainline sequence and alternative sequence for
each use case then we have to include the objects and their behavior during run time that is the
behavioral diagram.

We have also to include the structural diagram that is what are the classes and how they are
connected to each other how they are related to each other the particular sequence in which you
are going to include these information in the document is up to you up to the designer that is you
can first have the use cases followed by structural diagram or the class diagram followed by
behavioral diagram.
Or you can have the use case followed by behavioral diagram followed by structural diagram
either is fine optionally at the end of the document for the better understanding of the data flow
in the system you can also include a flowchart as shown here.
(Refer Slide Time: 34:34)

Although it is optional and not mandatory so that is how we can conceptualize and create a
design document following object oriented design approach. Earlier we have seen how to create
a design document following the functional approach where we use TDF and entity relationship
diagram. In this case study we have seen how to create a design document where we use object
oriented design and UML as a language to express the design I hope you enjoyed this lecture and
learned how to create such a document looking forward to meet you in the next lecture thank you
and good bye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Lecture: 27
Coding Basics

Hello and welcome to the NPTEL MOOCS course on design and implementation of human
computer interfaces, lecture number 24 where we are going to start our discussion on
implementation of the designs that we have learned in our previous lectures. So, before we start
let us quickly recap what we have learned and where we are now.
(Refer Slide Time: 01:02)

So, as you may recollect in this course our main focus is design and development of human
computer interfaces in other words design and development of interactive systems. Now for
interactive systems in order to design develop and deploy an interactive system we need some
systematic approach. For that we should take recourse to some software development life cycle
we are discussing one such development lifecycle for interactive system design.

In the life cycle there are several stages requirement gathering analysis and specification stage
then design prototyping and evaluation cycle coding and implementation stage code testing stage
empirical study stage and deployment and maintenance stage and there are cycles between the
stages as shown in the diagram. Among these stages we have so, far covered the requirement
gathering analysis and specification stage that is done.

Then we have covered the design stage also prototyping and evaluation of prototyping have been
covered in our earlier lectures. If you may recollect there are two designs we mentioned one is
design of the interface where primary concern is usability and there we require prototyping and
evaluation of prototyping to come up with an interface that is usable. The other design is the
design of the system or code design we covered both these concepts in our earlier lectures.
(Refer Slide Time: 02:59)

Once we managed to come up with a design of the system or design of the code. What is next?
Next is writing of the actual code for implementing the system and that is followed by testing of
the code. Now you should keep in mind that earlier we talked about testing of the interface in
terms of building prototypes and getting it tested with domain expert users. Here what we are
going to talk about is testing of the code after we have written the code to implement the system
we are going to test the code.

So, clearly that is different from testing of the prototype. So, these are the next things that we
should learn about. In other words we have covered requirement gathering design prototyping
and evaluation cycle and now we are going to focus on the next two stages namely coding and
implementation and code testing in this and subsequent few lectures that is our lecture topics.
(Refer Slide Time: 04:05)

So, there are two things one is writing the code to implement and second one is testing the code
to see whether the code has any problem in terms of bugs that may be syntactic problems
semantic problems. So, in testing we find out these problems and in the first is that is coding and
implementation we put our effort in writing codes. So, let us start our discussion on how to write
code.
(Refer Slide Time: 04:40)

In fact all of you may have written some code by. Now and you may be familiar with code
writing practices. However it is not necessary that you always follow good coding practice often
we have the tendency to write codes in a very brief manner in a very convoluted manner or avoid
certain things which makes the code readable and maintainable. So, it is always advisable to
follow good writing practices to take home this point let us start with an example.

Why good quadratic practices are important and what are those practices. Suppose we want to
write a program to add two numbers that is a very simple program and if I give you this problem
I am sure that most of you will be able to do it within no time. However let us see what are the
common mistakes that we are likely to commit while writing this code. So, our problem is to add
two numbers. Now this function so we want to write a function for performing this operation and
this function takes as input two integers and produces the result or the sum as output.That is a
very simple description of a problem.
(Refer Slide Time: 06:09)

If this problem is given to you many of you if not all will quickly come up with a solution and
that solution may likely to be something like this assume C syntax. So, this is a very well known
syntax I am sure all of you may be familiar with this syntax that we follow in the C language. So,
here we have declared the return type of the function int given a name to the function f then
within parenthesis we provided the definition of the input that is integer a and integer b.

So, a and b are two inputs of type integer then there is a variable defined inside the function s.
So, in test is initialized to 0 and then s is assigned the sum of the two arguments a and b. So, this
is the result. So, at the end this result is returned as output return s is the statement used for the
purpose. So, this may look like a simple program and it is actually a correct program but is it
following proper code writing practices. Let us investigate in little more detail.
(Refer Slide Time: 07:37)

If this program is given to you can you spot any problems with this piece of code I think many of
you may be thinking that this is the right program. So, there is no issue but that is not necessarily
the case let us see. One problem is with the name of the function. So, here we have given it a
name f. Now f does not convey any meaning. So, ideally the name of the function should convey
some meaning actually the purpose of the function should be conveyed in the name.

For example here we could have given a name like sum or we could have given a even more
elaborate name like sum of integers that would have been a better name than giving a name like f
which does not convey any meaning.
(Refer Slide Time: 08:28)
Then name of the variables like a b s again ideally we should name our variables in a way such
that they convey the purpose of those variables in contrast here we have given some arbitrary
name. So, they do not convey any meaning. Instead suppose we have given name as integer input
one or the first input integer second input or even better integer first number integer second
number that would have given some idea that okay we are now talking about the two inputs
where one is labeled as first number one is labeled as second number.

Similarly instead of s we could have written sum that would have been a better naming
convention than simply writing an arbitrary character such as s to represent the variable. A third
interesting thing that we should note here is that in this piece of code we have not used any
indentation. So, ideally there should be indentation here in this line in this line and in this
indentation means that should have been shifted right by some space all these three lines would
have been shifted right rather than aligning with the top line and the last line.

These things like meaningful function names meaningful variable names proper indentation and
additionally some documentation or comments conveying the purpose of the statements or the
overall function adds lots of values to any program that you are writing. In fact that helps us to
understand and maintain a program in a much better way than if we are not following this
conventions.
(Refer Slide Time: 10:38)
So, when we are writing a program what are the things that we should remember many of these
things I am sure most of you have already encountered but most of us often ignore those
guidelines or those things that we should follow while writing a code. So, let us quickly recap
those things that are useful in writing good programs or good codes.
(Refer Slide Time: 11:07)

So, those are essentially coding standards or guidelines they help to follow good practices. So, if
we are following standard coding guidelines or practices then the code that eventually we get are
better written better understood and easier to maintain. So, they help in improving readability
and understandability most importantly that helps in teamwork. So, generally code components
are written by different members of a team for large projects it is really the case that a single
developer is writing the entire code.

So, different team members write different pieces of the code as assigned to them. Now if a
standard is followed if some guidelines are followed then it is easier to understand and integrate
those different pieces of code at the end and test those. So, it helps in implementing good
teamwork.
(Refer Slide Time: 12:06)

Now organizations or companies may have their own guidelines or standards that they would
like to follow however there can be some generic guidelines that everybody can follow. So, it is
always advisable that we are at least aware of those general guidelines.
(Refer Slide Time: 12:29)
One is indentation this is one of the very basic thing. Whenever we are writing code like line one
then line two line three for certain constructs if we follow this type of indentation where
indentation means basically shifting towards the right the subsequent lines. For example while
writing the for loop or he fails statements it is advisable to follow indentation properly then that
improves readability if everything is written along the same vertical line then readability is
affected. So, indentation is one of the basic things that we should keep in mind.
(Refer Slide Time: 13:23)

Next is the use of global variables where we should follow a standard or common naming
convention. For example global variables may always start with uppercase letters and we can
also use prefix or suffix to indicate group global variables such as gbl underscore name or name
underscore gbl. So, these are some of the conventions that we can use. So, that global variables
are sufficiently distinguishable from other variables or local variables clearly that helps in
understanding the purpose of the global variables as well as differentiating between different
types of variables.
(Refer Slide Time: 14:12)

Also when we are using global variable we should remember that it is better to keep the number
of global variables limited. So, we should not use them indiscriminately and in large numbers
also they should be easy to find. Ideally they should be kept in a single or limited number of
definition files that means they should be kept in one place. So, that it is easier to locate all the
global variables used in your program.
(Refer Slide Time: 14:46)
Then it is also a good practice to use module header. So, whenever you are writing or
implementing a module there should be a header added to the module that means to each of the
files that implements a module and there are few things typically you should keep in the header
what are those things the name of the module the date on which the module was created.
(Refer Slide Time: 15:16)

Name of the author or authors; modification history so if you have made any changes in the
module. So, that history that is the dates on which the changes are made and what are the
changes those things should be summarized and kept in the header. Then a summary of the
content of the module should be kept in the header.
(Refer Slide Time: 15:36)

Also different functions supported in the module along with their input output parameters should
be listed in the header itself for a quick view of the content of the module. Global variables if any
global variables are used or modified in the module those should be listed in the header file.
These are some of the typical things there may be other things you may add but at least these
things should be kept in the header file for each module.

So, you should keep a header for each module and in the header section you should keep all
these information.
(Refer Slide Time: 16:14)
Other important thing is naming conventions so when we are trying to name variables functions
modules we should follow some convention and maintain consistency in naming that is very
important while giving names to different components of a program. We already talked about
global variables and their naming conventions. For local variables we may follow any
convention standard convention such as the names may be made up of small letters for local
variables constant names may always be in capital letters. So, whenever we are trying to define
some constant we should always use capital letters to name it.
(Refer Slide Time: 17:10)
Another important thing that we should remember is dealing with errors and exceptions how you
deal with errors and exceptions actually determines the quality of your code. Ideally we should
use some standard error condition reporting facility for example functions may return a 0 for
error or 1 otherwise consistently. So, we should follow this convention for all functions it should
not happen that.

For some functions we define the zero return value as for error and one as for success whereas
for some other functions we reverse it we say that 0 is for success and 1 is for error. Whatever
standard we follow we should follow it consistently across all the parts of the code. We must take
care of exceptional situations. So, while execution takes place if there is some exception such as
division by zero then that should be taken care of so we have to identify and take care of
exceptions that may happen during execution of any code.

Another important thing is that the code that you are writing should be well documented. So,
every portion of the code should have proper documentation to explain the meaning purpose and
content of the code.
(Refer Slide Time: 18:36)

We can follow our rule of thumb as the name suggest this is just a rule of thumb. So, nothing
sacrosanct about it but we can follow it is that at least one concise and explanatory comment on
average for every three source lines should be there. Now you can make it every five source lines
one comment or if the source lines are very obvious and self explanatory then no need to add the
comment depending on the situation you may judge. But generally for every three lines ideally a
line of explanatory comment adds quality to the code and makes it more readable.

And also it is always a good idea to create a detailed user manual and technical manual to
accompany your implementation. User manual is for high level view of the code whereas
technical manual is for detailed understanding of the code. So, those are in brief the things that
you should remember while writing the code. That is follow indentation naming conventions,
module headers, handle errors and exceptions and use documentations.

These are some standard things that we should follow while writing a code. There are again
certain things that we should avoid. So, we should consciously keep in mind things that we
should avoid what are those things.
(Refer Slide Time: 20:13)

So, some of us have the tendency of writing codes that appear to be very cleverly written. Now
the problem associated with that is that such quote unquote cleverly written codes are very
difficult to understand and difficult to maintain only the programmer knows what the code does
and others if they are asked to understand it others find it very difficult to understand the code
that affects maintainability and eventually that affects team spirit.
For example many coders actually take pride in writing very cryptic and incomprehensible code
such as writing the entire code in one line. So, you may have seen such examples and you
probably have found them very interesting but in practice if you are following that then it
actually is problematic for maintaining the code understanding the code and come up with a
good teamwork. An example is this statement a for loop initialized i equal to p i less than fin dot
size then i + equal to a very complex expression.

So, from this it is difficult to understand the purpose and also it is not necessary. So, ideally you
should try to write codes that are simple and easy to understand. So, that they are understandable
to others rather than only to you and they are easy to maintain writing such complicated code we
should always try to avoid.
(Refer Slide Time: 22:03)

So, those coding styles can obscure meaning and hamper understanding as I already said and
max maintenance difficult that is pretty obvious from the previous example.
(Refer Slide Time: 22:17)
Also we should keep in mind of obscure side effects that may result from our writing. So, what is
this idea of a side effect generally associated with the function calls which involves modification
of parameters modification of global variables and input output operations. So, these are
typically side effects associated with improper writing of code things may change without our
knowledge and without our requirement.
(Refer Slide Time: 23:03)

So, when we are writing code sometimes it becomes difficult to understand from the code itself
what kind of side effects it can create. So, those are obscure side effects which are not apparent
from the reading of the code.
(Refer Slide Time: 23:27)

So, when we are writing code we should try to write code in a way. So, that the side effects that
means whatever modifications that are likely to take place because of a function call are pretty
apparent to the person who is reading the code or going through the code. Clearly obscure side
effects affect understanding of the code because we do not know what is going to be changed.
When for example a global variable may have changed obscurely in a called module which we
are not aware of so, we are probably dealing with a changed value rather than the original value
that.

We thought is stored in the global variable. Another example is some file input output operation
is performed due to function call which again was not clear to us because that is an obscure side
effect which in turn have changed certain things in the file which is not what we want.
(Refer Slide Time: 24:27)
Similarly another thing that you should try to avoid is you should not use identifiers same
identifier for multiple purposes. We often use the same identifier to denote several temporary
entities. For example a temporary loop variable for computing and storing final results may have
used the same identifier. Now this is often done to take into account memory efficiency issues
but then while it may improve memory efficiency understanding the code becomes difficult.

So, ideally we should use different identifiers for different purposes rather than using the same
identifier for different purposes.
(Refer Slide Time: 25:22)
Also we should not use variables that do not have descriptive names indicating purpose. So, this
is already mentioned earlier naming convention should be such that the name should reflect the
purpose. So, we should not or do not variables that do not reflect the purpose. Now if you are
using same identifier for different purposes then this naming convention you cannot follow
because the purposes are different and If you want to give a name indicating the purpose then if
the identifier is same for different purposes then clearly you cannot give different names to the
same identifier.

So, you have to use a same identifier indicating one purpose whereas it is being used for other
purposes as well. So, we should avoid that situation.
(Refer Slide Time: 26:19)

Another thing that we should avoid is write lengthy functions. Now this is a very interesting
thing when we are writing functions often we are not much bothered about the length of the
function. In fact most of us may not be knowing what is the appropriate length how many lines
of code should be there in a function. One guideline you can follow is that function length should
not be more than 10 lines of code.

So, under a function ideally you should not use more than 10 lines of codes. If you are having
functions involving more than 10 lines of codes then those are usually difficult to understand and
most likely such functions can be split into multiple functions you probably instead of splitting
have joined them together and put them under same function. So, any function whose length is
more than 10 or maybe more than 15 lines of code probably is a good candidate to be split into
multiple functions.

Also if you have lengthy functions then there is high likelihood that it will lead to larger number
of bugs that is quite obvious the more lengthier the code is the possibility of having more bugs
increases that is true for functions as well.
(Refer Slide Time: 27:54)

Another thing that you should avoid is to use the go to or branching statements indiscriminately
that means you should be very careful while using branching statements such as go to statements.
Of course this is more appropriate this is more suitable for older generation of programming
environments nowadays go to statements are not there in most of the programming languages.
So, this is not a big concern nowadays but still if you are using similar constructs you should be
careful and should limit the number of such constructs in your code.

Otherwise it is very difficult to understand the logical flow in the code because there are too
many branching and that eventually makes a program unstructured and difficult to understand.
So, these are the some of the things that you should avoid should avoid lengthy functions you
should avoid having same identifier for multiple purposes and so on. Also, should avoid using
too many branching constructs. So, there are things you should follow and there are things you
should avoid.

These are some of the things that you should keep in mind while writing your program and I am
sure many of you may be already aware of these things but occasionally we fail to keep in mind
these things while we write our program. So, it is always advisable to follow these things and
write a good code which is easier to understand easier to maintain and easier to modify. I hope
you enjoyed the content that we covered in today's lecture.
(Refer Slide Time: 29:59)

Whatever I have mentioned you can find in this book particularly chapter 10 you can go through
to get more details about these things in subsequent lectures we are going to talk about testing of
the code. So, in this lecture we talked about how to write a good code which is useful for
implementation then once the code is written and the system is implemented we need to test it.
So, in subsequent lectures we are going to talk about how to test a code that we have already
written, so looking forward to see you in the next lectures, thank you and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Lecture: 28
Code Testing Basics

Hello and welcome to the NPTEL MOOCS course on design and implementation of human
computer interfaces lecture number 25 where we are going to continue our discussion on
implementation and testing. So, let us first quickly have a look at what we have covered. So, far
and where we stand.
(Refer Slide Time: 01:02)

So, we are discussing the interactive system development life cycle it consists of several stages
among those stages we have already covered some stages and currently continuing discussion on
some other stages and in future also we are going to cover the remaining stages. So, which are
the stages that we have covered. So, far let us have a quick look. So, we have covered
requirement gathering analysis and specification stage then we have covered design stage
prototyping stage, early evaluation of the prototyping stage.

Now this design prototype evaluation cycle is primarily meant for interface design keeping
usability in focus. So, we have covered all the three substages of this cycle for interface design.
Subsequently we covered design of the system or code design. Then we discussed in the previous
lecture the coding and implementation stage where we learned about coding practices what we
should do what we should avoid while writing a program.

So, currently we are going to pay our attention to the code testing stage which is our topic of this
lecture.
(Refer Slide Time: 02:29)

So, what is code testing first of all why we need testing as the name suggests testing means we
need to test the code but why. So, primarily there are three reasons for testing our code first is to
know if the code is written with proper syntax why that is required. So, that we can compile the
code and create the executable program. So, essentially we need to check for syntactical
correctness of the code.

Secondly we need code testing to know if the code performs what it is mean to perform. So, it
produces the expected outcome after execution that means we need to test whether the code is
logically accurate it does what we want it to do. There is another reason which is equally
important that is we need to go for code testing to know if the code follows convention. So, that
others can understand and maintain the code.

Now this is very important not only syntactical and semantical correctness we also need to test
code specifically keeping in mind the maintainability of the code. Others can understand the
code others can modify the code in summary others can maintain the code this is required to
implement a team effort and for that also we need to go for testing of the code.
(Refer Slide Time: 04:11)

So, once we know the reasons the next thing that comes to our mind is how we can test our code
keeping in mind these three objectives. First one is syntactical correctness how we can check for
syntax of the code whether the code syntax is correct or not whether we have written the code
correctly or not. That is simple generally that is the most simple part of code testing. We rely on
the compilers which typically comes in built with the integrated development environments.

I think most of you have probably already used such IDEs and the inbuilt compiler to check for
syntactical correctness of your code.
(Refer Slide Time: 04:58)
The other two testing situations namely testing for logical correctness and testing for
compatibility with convention our IDEs or the inbuilt compilers cannot be of any help. These
two are generally more difficult to test and more complex in nature and there are actually several
methods to take care of these two types of testing. So, let us have a quick look at different testing
methods.
(Refer Slide Time: 05:35)

Now there are two broad categories of methods one is review based code testing other one is
execution based code testing. So, whenever we are talking of code testing our primary emphasis
is for testing of logical correctness and testing of conventions whether the code is following the
conventions. Now to do that we can apply any of the several methods available broadly all the
testing methods can be divided into two categories one is review based testing one is execution
based testing.
(Refer Slide Time: 06:24)

Let us first start our understanding with the review based code testing.
(Refer Slide Time: 06:27)

Now review based testing’s are relatively less rigorous but they are also quick methods for
testing of your code. So, although they are not very rigorous but they can be used to test code
quickly generally such testing are carried out after a module or an unit is successfully compiled
and all syntax errors are eliminated. So, once you implement an unit or module and compiled it
and found out that there are no syntactical errors then we can go for review based code testing
for that particular module.
(Refer Slide Time: 07:22)

Now review based testing offers a cost effective strategy for reduction in coding errors and
production of high quality code. Of course that is the ultimate objective of any testing method
that we identify errors address them and produce high quality code. Now review based testing
provides a cost effective way of doing the same thing it produces high quality code to some
extent with methods that can be applied quickly and with less cost.
(Refer Slide Time: 08:02)
So, review based testing also can be done in different ways broadly there are two ways one is
code inspection which is somewhat similar to heuristic evaluation that we have earlier seen
during our discussion on evaluation of prototypes remember there we mentioned that heuristic
evaluation is a kind of checklist type evaluation where we tick from a list after checking the
prototype.

Similarly code inspection is kind of similar method where we have a set of predetermined things
to check and we take the code and go through it and see whether the things that are there in our
list in our checklist are satisfied in the code or not. So, here in code inspection method there will
be an evaluation team just like heuristic evaluation for prototypes team members will check the
code for violation of coding standards.

So, we have a checklist of standards to be followed while writing a code and the team members
goes through the code and see if there are any violations.
(Refer Slide Time: 09:29)
The other method is code walkthrough again this is similar to the cognitive walkthrough method
that we have seen or discussed earlier in the context of evaluation of prototypes. So, in case of
code walkthrough again there will be an evaluation team each team member will manually
execute the code this is often called hand execution I think many of us probably have done that
during our code writing practices.

And the team members will do that for some test cases which are to be representative test cases
to identify logical errors. So, like cognitive walkthrough there are some usage scenario which we
call test cases which ideally should be representative test cases just like in the case of cognitive
walk through. And those test cases will consist of input and output the members of the evaluation
team will hand execute or manually execute the code for the given input and see what output is
getting produced and will compare with the desired output.

And see whether there is any problem with the two outputs whether they are matching or not to
find out if there exist any logical error in the code.
(Refer Slide Time: 11:04)
These are broadly two ways to go for testing of code in other words we review the code in case
of inspection primary objective is to check if the code follows the standards. And in case of code
walkthrough primary objective is to check if there are any logical errors with respect to some
representative test cases. So, how these methods help these are quick methods similar to the
prototype evaluation methods namely heuristic evaluation and cognitive walkthrough these
methods can also be applied in a relatively quick way.

So, eventually they help us save development time of course they are not rigorous methods. So,
after applying these methods it may happen. In fact it is quite likely to happen that some errors
are still there which we could not detect through these methods but idea is that we identify as
many errors as possible with this quick method. So, that the quality of the code improves. Code
inspection helps to conform to good coding practices which in turn helps in maintainability and
portability of the code.

These are very important achievements when we are looking for team effort. Code walkthrough
on the other hand allows the developers to quickly identify logical errors of course some errors
may still be missed because it is not possible for a complex system to come up with all possible
test cases. But if the test cases are chosen carefully if they are representative then major points
where logical errors can happen major areas of the code can be quickly identified. So, that is all
about review based code testing.
(Refer Slide Time: 13:16)

The other type of code testing is execution based testing. Unlike review based where we
primarily go through the code manually and do the testing in execution based that is not the case.
(Refer Slide Time: 13:31)

So, review based testing is somewhat informal they are primarily meant to evaluate the codes
qualitatively that is 100% true for inspection based method but partly true for walk through
based method. Although in walk through also one of the objectives is to identify violation of
coding standards along with logical errors. So, if we are performing review based testing they
may not be able to give us all possible errors.
So, such type of testing’s are good for early evaluation similar to prototype evaluation and
testing. Now that early evaluation helps us to clean up the code before more rigorous and formal
testing is done. So, eventually we have to go for some somewhat rigorous and formal testing but
before that we can apply the code review methods to kind of preprocess the code and clean up
some important errors.
(Refer Slide Time: 14:46)

Now the formal or rigorous testing consists of providing the program a set of test inputs which
popularly is known as test cases and then observing the behaviour of the program in other words
the output primarily. So, these are the things that we generally do with more rigorous and formal
program testing methods.
(Refer Slide Time: 15:21)
If the program or the code fails to behave as expected that means the output that it generates is
not the same as the output that is expected for a given input the conditions or the inputs under
which failure occurs are noted for letter debugging and correction that is the way to go for more
rigorous and formal program testing. So, before we learn about the formal testing methods let us
quickly learn about the terminologies that we are going to use in the subsequent part of the
lecture and subsequent lectures.
(Refer Slide Time: 16:08)

First term is test case this is a very common term that we are going to use throughout this lecture
and the next lecture a test case can be considered to be a triplet I, S and O. So, here I stands for
the input data S stands for the state of the system at the time of providing input data and O stands
for the expected output. So, that is the meaning of the triplet and this triplet is popularly called a
test case. However for simplicity in subsequent discussion we will consider only the doublet I
and O.

So, we will not generally consider S that will unnecessarily complicate the discussion without
adding much value. So, we generally consider the doublet I and O to be representing the test
case.
(Refer Slide Time: 17:12)

Closely related to the term test case is the term test suit. Now a test suit refers to a set of all test
cases with which a given software is to be tested. So, generally we test a program or a software
with a set of test cases rather than a single test case. Now this entire set is popularly called a test
suit.
(Refer Slide Time: 17:40)
So, what is the aim of testing to identify all defects or problems in a software product but is that
feasible is that viable.
(Refer Slide Time: 17:51)

In practice it is generally not possible to guarantee that a software is completely error free after
testing. No matter whatever way we try no matter whatever method we apply it is a practically
impossible to guarantee that after testing we will be able to identify all possible errors and we
will be able to rectify all possible errors that is not a practical way to think of testing. Instead
what we can do is something different.
But before that why it is not possible because input data domain that means the set of values that
can act as input for most of the real life software products are generally very large in size. So, the
possible set of inputs is very very large in most of the practical systems then it is not practical to
test a software exhaustively with respect to each and every possible input because that will
consume huge amount of time if at all we managed to do that.
(Refer Slide Time: 19:14)

Now a logical question can be if it is not possible to test everything and it is not possible to
identify all possible errors then what is the purpose of formal testing review based testing would
have been sufficient why to go for testing at all.
(Refer Slide Time: 19:33)
We have to look at this problem from a different point of view it is not binary that either we test
and find out everything or we do not test rather our objective should be we test to find out major
problems knowing very well that some of the problems may still escape our attention. However
our objective should be to identify all major problems. So, testing does expose many rather most
defects which are the important ones if done properly and systematically.

Now these two are very important. So, we cannot go for testing with random test cases and
randomly created test suits rather we have to adopt a very appropriate method which has to be
carried out in a very systematic manner. So, that we are able to identify the important problems
or important defects with the system that is our goal rather than identifying all possible defects.
In that way it is more practical to reduce important defects in a system and that in turn is likely to
increase confidence in a developed system.

So, if we do not do testing then the end users or the clients may not have the confidence of using
the system in real life situations and there may always be a thinking that the system may fail
because we have never tested it. On the other hand if we test it and identify important issues then
at least we know where it can fail and we can rectify for those scenarios which are likely to be
the most important and most frequent ones.
For some minor issues there can always be some bugs which we can always fix later. We have to
always keep in mind that it is not possible to come up with a perfect system that does not exist
whatever software we develop we have to have this knowledge that there will always be some
bugs even at the end of a very rigorous testing phase. So, the key thing here is that we need to go
for a proper method with systematic application of the method to identify the major defects that
are most important ones.
(Refer Slide Time: 22:05)

Now exhaustive testing is impractical because possible input data values are likely to be
extremely large or infinite. Then we must design test suit that is of reasonable size and can
uncover as many errors existing in the system as possible that is our goal.
(Refer Slide Time: 22:29)
If we select the test cases randomly then they not necessarily contribute to the significance of a
test suit that means they need not detect additional defects not already detected by other test
cases. So, the total number of test cases in a suit not necessarily indicates the testing
effectiveness where effectiveness is defined in terms of identification of major or important
defects in the system.

Large number of test cases selected at random does not guarantee that all or even most of the
errors will be uncovered. So, our objective should not be to go for a set of randomly decided test
cases even if that leads to a very large test suit. Because it is very unlikely that that test suit will
lead to uncovering of errors that are not already detected with a smaller suit or even it will lead
to uncovering of important defects with the system.
(Refer Slide Time: 23:52)
To understand this point let us take one example suppose we have written a code to find the
larger of the two integers. So, the code snippet is given here if x greater than y then max equal to
x else max equal to y. So, if x is greater than y then max equal to x and if x is less than y then
max equal to y. So, this is likely to give us the larger or greater of the two integer values. Now
here instead of y suppose originally it was written as x. So, the code has a simple programming
error.

So, I although y should be the right one but instead while writing the code the programmer has
written else max equal to x as shown here. So, the y is not present. So, this has a simple
programming error. Now how do I identify this error?
(Refer Slide Time: 25:07)
Let us see how we can design test cases to identify this error. Consider a test suit consisting of
two test cases x equal to 3 y equal to 2 that is the input and output is 3. Similarly in the second
test case x equal to 2 y equal to 3 and the output is 3. So, in the I O doublet form we have in each
test case we have the input and the output mentioned. Now with this let us see how we can
identify the programming error that is present there.

If we put x equal to 3 and y equal to 2 then we can see that the output will be 3. So, for the first
case it produces the correct output. For the second case when we have x equal to 2 and y equal to
3 this condition fails it goes to next condition and then it produces 2. So, there is a mismatch
instead of three it produces two. So, here we have a mismatch and then we know that there is
some error once this error is detected we will be able to identify where exactly the error is and
we can rectify it.
(Refer Slide Time: 26:53)
Now let us consider a larger suit consisting of three test cases like before x equal to 3 y equal to 2
output is three x equal to 4 y equal to 3 output is 4 x equal to 5 y equal to 1 output is 5. with this
will it be possible to identify the error. Let us see when x equal to 3 y equal to 2 we get output 3
it matches when x equal to 4 and y equal to 3 again we get output as four it matches. So, we do
not detect any error.

And finally when x equal to 5 and y equal to 1 again we get 5 as output. So, again we do not
detect any error. So, eventually every time with the given input we get the desired output which
is exactly what we want. So, there is no mismatch. So, we conclude that there is no error
although we can see here that there is some error. So, this test suit cannot detect the error
although this test suit is larger in size.

So, larger test suits not necessarily give us a better test suit. So, the moral of the story is if you do
not choose your test cases carefully and create your test suit appropriately then no matter
whether the test suit is larger or not you may not be able to identify the error that means you will
fail in your objective of detecting errors.
(Refer Slide Time: 28:43)
So, the implication is test suit should be carefully designed it should not be decided randomly
that is the implication of this discussion. Now this careful design of test suit requires some
systematic approaches how we can do that. So, that systematic approach can be done in either of
broadly 2 ways functional testing. So, when we are trying to perform a test of a code we need to
systematically design the test cases and apply the testing method.

Now the systematic approach to testing can be done in broadly one of the two ways one way is
functional testing here test cases are designed using only functional specification of the software.
That means without any knowledge of the internal structure in other words suppose we have
written a function at hint 1 in 2 and it returns an int there are some statements and this is the
function. So, when we are testing we designed the test case based on only the definition of the
function that means it takes as input two integers.

And produces as output one integer rather than what is written here inside the body of the
function. So, this body we simply ignore and we test based on the definition of the function one
popular way of going for this type of testing is black box testing. As the name suggests we treat
each function as a black box only the declaration part is considered the internal or structural part
is ignored. So, we simply assume add function to be a black box and what is there inside the box
that means the body of the function is of no consent to us.
In that way we understand the function and with that understanding we create the test cases to
test the function that is black box testing which is a type of functional testing. As opposed to the
black box testing there is another method that is called structural testing. Here we decide the test
cases based on the knowledge of the internal structure of the code. Unlike in case of functional
testing or black box testing here we are concerned about the internal structure that means the
body of the functions and the body of the code.

And based on that knowledge we design the test cases one example is white box testing which is
a kind of structural testing.
(Refer Slide Time: 32:09)

So, in summary we go for testing to uncover errors present in the code testing can be done in
broadly two ways. One is a quick and cost effective way although it is not very rigorous or
formal way that is the review based testing which also can be done in either of the two ways
namely inspection based testing and code walkthrough. These are similar to the heuristic
evaluation and cognitive walkthrough methods that we discussed in the context of prototype
evaluation.

The other testing method is the execution based testing which is more formal and rigorous
testing method with the objective of identifying more and more errors. Now in that case we go
for actual execution of the system. Now there are broadly two ways to do that one is functional
testing one is structural testing. In functional testing we assume that the functions are black
boxes and only the input and output matters accordingly we designed the test cases.

In case of structural testing we design test cases based on the internal structure of the code an
example of functional testing is black box testing. An example of structural testing is white box
testing. In subsequent lectures we shall learn in details about all these testing techniques namely
review based testing black box testing and white box testing.
(Refer Slide Time: 33:54)

Whatever we are discussing in this part of the course you can find from this book fundamentals
of software engineering chapter 10 or software engineering practitioners approach chapters
19-21. Of course there are the things are discussed in much more details than what we are
discussing here but those are useful references where you can enhance your knowledge. I hope
you understood the concepts and enjoyed the topics.

We will continue our discussion on testing in the next lecture looking forward to meet you soon
in the next lecture thank you and good bye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Lecture: 29
Review-Based Code Testing

Hello and welcome to NPTEL MOOCS course design and implementation of human computer
interfaces we are going to start lecture number 26 where we are going to continue our discussion
on testing particularly we will focus on review based code testing before.
(Refer Slide Time: 01:02)

We begin our discussion let us quickly recap what we have learned where we are. Now and what
we are going to discuss to put discussion in the proper context. So, we are discussing interactive
system development life cycle in the interactive system development life cycle there are several
stages among those stages we have already covered many of the stages and we are continuing
with the remaining stages.

So, we have already covered requirement Gathering analysis and specification stage then we
covered design prototype evaluate cycle and the substages that are part of this cycle including
design, prototyping and evaluation. Now these three substages are primarily meant for interface
design also we have discussed code design. Then we discussed coding and implementation stage
where we learned about good coding practices and what we should do and what we should avoid
while converting our system design into into an executable code.

Currently we are discussing the testing stage which is located here. In the testing stage we have
already started our discussion on the basic concepts and we are going to continue that discussion
to cover the broad categories of code testing.
(Refer Slide Time: 02:45)

So, in the testing stage what we have learned in the previous lectures let us have a quick recap.
(Refer Slide Time: 02:52)
We have learned that there are broadly two groups of approaches which we can employ to test
our code. Now there are two things when we are talking about interactive system development
one is how it is going to be perceived by the user and accepted by the user that is primarily
determined by the usability of the design or rather the usability of the system. For ensuring
usability we have already seen that during this design prototype evaluate cycle we make
prototypes.

And get those evaluated by expert users to know about the usability issues that may be there with
the interface design. However so, far we have not talked about the other aspect of a system that is
how good the system behaves during execution or rather the efficiency of the code. How well the
code is written and how well the system design is implemented that part we have not discussed.
So, far that comes under the testing phase or code testing phase.

Now there our primary concern is to see that the code is error free. Now errors can happen at
multiple levels we may think of errors at the syntactic level that means whether we are following
the correct syntax while writing the code using a particular language. We may face errors at the
logical or semantics level that is whether there are any logical bugs that are there that are present
in our code. Also it may happen that we may fail to follow standard coding practices that is also
a kind of important errors or violation of conventions that we should be very careful about.

Otherwise the code that we write will be very difficult to understand by others who may be part
of your team. So, that will in turn affect the team work and that is not a good thing when you are
part of a complex interactive system development team. To determine syntactic errors of course
we rely on the compilers maybe all of you are aware of that we have already mentioned this
point in the previous lecture to determine logical errors as well as to determine errors that may
happen due to the improper use of convention we take request to several methods.

Now all these methods can broadly be divided into two groups of methods or two groups of
approaches one is review based testing method and the other one is execution based testing
methods. Now review based testing methods are as we have noted in our earlier lectures quick
cost effective way to test your code. Here primarily we try to identify major errors without
spending too much time or effort on analyzing the code.

In execution based testing method this is not the case it is more formal and more rigorous in
nature where we mostly focus on analyzing the code internally as well as externally and
accordingly we design test cases and then go for testing that is a more systematic scientific
rigorous and detailed way of testing.
(Refer Slide Time: 07:05)

The focus of this lecture is review-based testing. As we said as I mentioned review based testing
is primarily used to quickly identify major issues or major errors in the code. So, that those can
be rectified and we have to spend less effort and time for more formal testing of the code. Now
review waste testing can be of two types one is code walkthrough. Now this is similar to the
cognitive walkthrough method that we have learned earlier while discussing evaluation of
prototypes.

What we have discussed there that in cognitive walkthrough we have a small team of evaluators
between three to five members each member is given a use case scenario and they are asked to
identify usability issues while trying to use the Prototype for the particular use case given at the
end each of them produces a report which the evaluator combines and determines the major
usability issues.
Code walkthrough is similar in nature as we shall see soon. The other type of review based
testing method is code inspection. Now this is again similar to another prototype evaluation
method that we mentioned namely heuristic evaluation. So, in heuristic evaluation what we did
we have a checklist. So, we used Nielsen's 10 heuristics as the checklist and again there will be a
small team of evaluators three to five members.

Each of these members will be given a prototype and the checklist and they will be asked to
identify which of the items in the checklist are satisfied in the interface represented as a
prototype. Same idea is applied for code testing also which we call code inspection. So,
conceptually Code walkthrough is similar to cognitive walkthrough method of evaluating
prototypes and code inspection is similar to heuristic evaluation method of prototype evaluation.
(Refer Slide Time: 09:51)

Let us briefly try to understand the code walkthrough method what we do and what we get at the
end. So, Code walkthrough is an informal method for analyzing the code.
(Refer Slide Time: 10:05)
Here the main objective is to discover algorithmic and logical errors in the code. Remember we
mentioned two error types one is logical error other one is violation of conventions or standards
in Code walkthrough our primary objective is to identify logical errors rather than the violation
of Standards. However while performing walkthrough it is also possible to check for violation of
standards that can be one of the minor objectives of cognitive work through.
(Refer Slide Time: 10:42)

So, what are the steps for performing code work through. First thing is we have to have a team,
team of evaluators. Now the team members who can be the part of the development team each of
them is given the code to read and understand. So, we have a team of evaluators who can be part
of the development teams and each of them will be given the code and they will be asked to go
through the code read it and understand the code.
(Refer Slide Time: 11:28)

Next each of these members is required to select some test cases. Remember we mentioned what
is a test case that is an input output combination input is given to the code and output is
generated and then we match this with the predetermined output to see if there is a match
otherwise there is some logical error. So, each member is asked to select some test cases and then
they are asked to simulate execution of the code by hand.

Now this is a term that should not be taken literally by hand means effectively instead of using
the computer to execute they have to do so manually like the way we calculate something that
means trace execution of the steps in the code through each statement and functional execution.
So, given inputs the team members are required to execute the code that means stress the
execution of the statements in the code manually and that is what we are calling execution by
hand.
(Refer Slide Time: 13:00)
After the execution for each test case the members are required to note down their findings and
discuss in a walk through meeting in the presence of the coders. So, that is what is required at the
end of evaluation by each member. So, to repeat there is a team each team member is given the
code they have to read and understand it then each team member is expected to come up with
some test cases it is desirable that the test cases are supplied by the coders but then there is a
possibility of biasedness.

So, ideally it should have been designed by someone who is not part of the coding team and
there should be more than one test cases ideally. For each test cases each member of the
evaluation team is expected to hand execute the code and produce output and then match with
the desired output and they compile for all the test cases and at the end there will be a meeting
where all these findings will be discussed in the presence of the coders.

So, that coders know for which inputs there are some errors and they can accordingly Rectify
those parts of the code.
(Refer Slide Time: 14:32)
While going for code walkthrough some guidelines should be followed first of all the team or the
evaluation team that is performing the work through should not be either too big or too small.
This is similar to the cognitive walkthrough scenario we discussed earlier. So, ideally three to
five members should be there in the team and the team should not be too big or too small. While
choosing test cases it is desirable that representative test cases are chosen.

This is similar to the concept of representative use cases in the case of cognitive walkthrough.
Now how to determine what is a representative test case again that is not a very easy thing that
requires expertise that requires experience. However it is desirable that you come up with
representative test cases rather than any random test cases. Remember in our earlier lecture we
mentioned that randomly designed test suits not necessarily serve the purpose of identifying
errors in a code instead we should be systematically designing test cases.

Since code walkthrough is not a very formal method. So, here of course we can go for informal
way of designing test cases however it is desirable to keep in mind while going for test case
design that the test cases should be as representative as possible.
(Refer Slide Time: 16:16)
Also at the end of this team meeting where findings are discussed in the presence of coders we
should keep in mind that during this discussion the focus should be on the discovery of errors
and not how to fix errors, fixing errors will come later. During the discussion it should be
focused solely on identifying the errors. So, that is in summary what a code walkthrough method
the other method for review based testing is code inspection method let us quickly have a look at
what this method is and how it can be utilized to test codes.
(Refer Slide Time: 16:56)

So, here the aim is to discover some common types of errors that are caused due to oversight and
improper programming. For example uninitialized variables also this method is more suitable to
check for adherence to the coding standards. So, remember in the earlier case that is code
walkthrough method our primary objective was to identify logical errors in contrast in the code
inspection method primary objective is not to identify logical errors rather identify common
mistakes that happen during programming as well as adherence to coding standards whether that
is being followed or not.

So, the objectives are somewhat different for these two methods but both provide a quick and
cost effective way of identifying or achieving these objectives.
(Refer Slide Time: 18:05)

So, one thing that we should know is that typically companies collect statistics several statistics
regarding different types of errors that are commonly committed by their engineers and
programmers and identify the type of errors that are most frequently committed. So, that is a
common practice across industries that these companies generally collect the statistics regarding
different types of errors that happen in the programs written by their engineers and the most
frequently occurring errors.

Now that list can serve as a checklist during code inspection. So, in code inspection what is
required is a checklist which the evaluators will use and see whether the items in the checklists
are being addressed in the code or not. This is conceptually similar to the heuristic evaluation
that we have discussed earlier.
(Refer Slide Time: 19:18)

So, what are these common errors let us see some examples. One very common error is use of
uninitialized variables. Probably many of you have faced this while writing a program we often
declare variables but then we forget to initialize it. So, that is one very common type of errors
that is found across codes and in a checklist that can be used during code inspection. If we keep
such errors in the list then we can check whether in the code that we are evaluating such type of
errors are occurring or not.

Another common errors another common error is jumps into Loops this is also quite common
and checking against it is required during inspection. Often we forget to terminate a loop in fact
often we forget to give proper termination conditions that is again quite common maybe many of
you have faced this issue. So, keeping it in the checklist helps while going for code inspection
then incompatible assignments.

So, we assign something to something where their types mismatch and that is again quite
common many of us faced it while we are writing our programs this is not necessarily due to our
ignorance rather many a times we commit this error due to oversight so keeping it in the
checklist helps.
(Refer Slide Time: 21:02)
Improper storage allocation and deallocation is another common errors which we should be
aware of file testing a code. Use of incorrect logical operators yet another common error that we
should be aware of while testing our code a very common thing is use of incorrect precedence
among operators. So, often we do not pay attention to the precedence of operators and we use
them in very incorrect way which creates logical errors in the code. So, we should avoid that.
(Refer Slide Time: 21:53)

So, checking against such type of incorrect usage helps in keeping the code clean improper
modification of loop variables another common error we often make this mistake and it is
preferable to check against it in your code testing. So, that is in summary what we can do during
code inspection. Now few things you should remember one is like code walkthrough code
inspection also should be performed by a team again consisting of three to five members.

Each member is given the checklist and each member checks the code against the items in the
list and then generates a report again there can be a meeting like code walkthrough at the end of
the evaluation in the meeting coders can be present or rather should be present where all these
findings are to be discussed. Here again the discussion should focus primarily on identification
of Errors rather than how to solve it.

So, all the guidelines that we have covered in code walkthrough applies in code inspection as
well. So, just to summarize in review based methods we follow either walk through or inspection
method. Each of these methods has its own objective in case of walkthrough objective is to
identify most important logical errors. In case of inspection the objective is to identify some
common type of errors that may happen as well as whether the code is following coding
standards.

Whether we will be able to identify common logical errors in code walkthrough depends on how
the test cases are chosen if they are representative test cases. Then it is more likely that during
walkthrough most important logical errors can be found out. Now in walkthrough what happens
is that the evaluator executes the code by hand. So, essentially traces the steps or the statements
that are part of the code one by one for a given input and at the end calculates the output that
should be outputted by the code and matches with the actual output to see if there is any problem
or not.

In inspection no execution is required hand execution is required rather the evaluator simply goes
through the code and sees whether common errors are present such as uninitialized variables
improper assignments improper termination and so on. For these errors to identify these errors no
execution is required. Also while going through the code the evaluator look for violation of
coding standards such as improper naming conventions and improper function lengths use of too
many Global variables.
In a nutshell whatever we discussed in our earlier lectures about good coding practices those
things are also observed file a member of the evaluation team goes through the code in code
inspection method. In both the cases at the end each member produces a report those reports are
compiled and meeting is organized where coders are present. In the meeting all these reports are
discussed to identify errors.

Now the focus of the meeting should be to identify errors rather than to take care of the errors
that is about code review. Later on we will see one case study on how to create a code review
document. I hope you have enjoyed the material you have learned about the basic concepts of
code review and you will be able to actually review a code and create a document. In the next
lecture we will see how to create such a document.
(Refer Slide Time: 26:14)

The material that I covered today can be found in these books fundamentals of software
engineering chapter 10 as well as software engineering a practitioners approach chapters 19 to
21. You will find more details than what I covered but it is always good to go through things in
more details that is all for this lecture looking forward to see you all in the next lecture, thank
you and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Lecture: 30
Code Review Case Study

Hello and welcome to the NPTEL MOOCS course on design and implementation of human
computer interfaces. We will continue our discussion on review based code testing as lecture
number 26 in this lecture in this continuation of lecture number 26 we will go through one case
study for review based code testing. Just to recollect earlier we discussed about different code
testing methods.

We talked about review based code testing where we have seen two broad approaches one is
walkthrough another one is inspection. In this case study we will primarily focus on inspection
based code testing. Let us see the case study.
(Refer Slide Time: 01:32)

The case is development of a system which is meant for monitoring of Student Activity in a
classroom and also the system is supposed to generate some alert if there is some anomaly found
in the monitoring of Student Activities. So, this is the cover page remember that after this code
review phase we are expected to develop a review document. So, in this case study we will go
through one such document this is the cover page of the document code review document for
name of the system as shown here.

As we have seen earlier the version of the document ideally should be mentioned along with the
date of creation prepared by the name of the persons who prepared the document. Additional
information are provided here that the place at equity supervised by the person's name these are
optional of course but the cover page should contain the name of the system version date and
name of the persons who created the document. These are essential things that should be part of
the cover page.
(Refer Slide Time: 03:05)

Next comes a table of contents which includes the sections as well as the sub sections that are
part of the sections like here in this document there are three main sections introduction code
review and conclusion each having some subsections as listed here.
(Refer Slide Time: 03:24)
Optionally it is advisable to include some revision history like shown here that the first version
was created on so and so date named version 1.0 then it was reviewed and refined based on the
comments received from the supervisor. And revision had been created so and so date and the
revision version number is given as 1.1 which is the current version. So, this revision history
ideally kept as part of the document.
(Refer Slide Time: 04:02)

Then the introduction part where it is preferable that the purpose of this document, conventions
used in the document scope of the project all these things are mentioned. In the purpose what can
be written here what is written is the purpose of code review for the student activity monitor and
alert generation software is to discover bugs, scrutinize coding conventions and look for potential
bottlenecks and resource leakage.

This includes the team members involved with their individual reports elucidating the problems
if any. This document is primarily intended to reduce coding errors and help in producing high
quality code. So, that is the purpose of code review document basically to reduce errors. Then
the subsequent part of the document made use of some terms. So, those are listed in this section
document conventions like whenever the term instructor or Professor is used it is defined as a
person who shall be using the software for monitoring.

Then student term indicates person who shall be monitored by the instructor. Users are
collectively refers to the students and instructors both categories device an electronic device
using which the instructor is delivering their lecture. Accelerometer sensor that helps determine
the second frequency of a mobile device. Magnetometer sensor that helps determine the
orientation of students mobile device, proximity sensor, sensor that helps determine the distance
between the student and their device.

The term sensors is defined as this term differs collectively to the accelerometer magnetometer
and proximity sensors on the student's mobile device. Android is the mobile operating system
developed by Google. Google is an American multinational technology company. So, all the
details are mentioned here. It may be helpful to know that this is a part of a larger system. So, in
the larger system it is assumed that there is an ICT enabled classroom where students carry their
own mobile devices and instructor also carry a mobile device.

And these device sensors are being mentioned in this document. The whole system is
implemented using mobile devices. The next subsection talks about the scope of the project that
is the scope of the software the software is meant to be deployed in an IT enabled large
classroom environment where in the lecture delivered by the instructor is via a device through
which both audio and video are transmitted.
The software shall allow the instructor to conveniently monitor the attention of their students in
real time in brief the scope is mentioned here. These are the subsections of the introduction
section next comes the core component of this document that is the code review part.
(Refer Slide Time: 07:18)

It starts with some introduction section the intent of a code review is to catch bugs issues defects
before the offending code is deployed to a production environment and to transfer knowledge of
implementation details to the rest of the team. Code review involves a slow code inspection
phase to check errors. So, here it is clearly mentioned that this particular review document
contains a code review procedure based on code inspection method.

Then the goals of code review the main reasons for performing code review is to finding bugs
since bug finding in code review are easier to find and fix than letter in testing phase. Adherence
to coding conventions improving code quality increasing efficiency by finding trivial
programming errors like data resource wastage or use of uninitialized variables, code review
primarily consists of code inspection as per this document. Of course that is not a general
statement we can perform review either through a walkthrough method or an inspection method.

Here in this document it is mentioned that the review has been performed using an inspection
method. Then it talks about code inspection the aim of code inspection is to discover some
common types of Errors caused due to oversight and improper programming. In this phase team
members are selected and asked to perform the inspection which is firstly checking of the coding
standards then the presence of certain kinds of Errors like modifying a formal parameter while
the routine calls a constant parameter.

Considering the statistics some common programming errors which are to be checked are use of
uninitialized variables, jumps into Loops, improper storage allocation and deallocation
incompatible assignments.
(Refer Slide Time: 09:32)

Non-terminating loops, array indices out of bound, mismatches between actual and formal
parameters in procedure calls, use of incorrect logical operators or incorrect precedence among
operators, improper modification of loop variables, comparison of equality of floating Point
variables. Recollect during our discussion in the lecture we mentioned that companies keep some
statistics of common errors that generally occur while implementing some system.

So, those are essentially used to create a checklist against which a code can be reviewed some of
those are mentioned in this list. And these are checked and reported it is important to note that
code inspection is a slow phase and no more than 400 lines of code are to be checked at a time
the report is then given to the other members or to the developer of this document for appropriate
change to be done. So, this report is generated by the team and given to the developer.
So, that code can be modified. Next the document mentions the team details name and some
other section details next comes coding standard. The general coding standard is followed in
group consensus some representative coding standards are as follows. Rules for limiting the use
of global variables these rules list what type of data can be declared Global and what cannot.
Naming conventions package names should be lowercase without punctuations following
JavaScript.

So, this is specific to this document class and interface names should be capitalized using camel
case begin with a letter and contain only letters and numbers, parameter names should follow
javascripts. It can be noted here is that these are some of the standards mentioned in this
document but that need not be followed everywhere but some standards should be followed. Do
not leave commented out code in the source files.

Exception handling catch specific exception rather than high level exceptions that can mask
errors also the way errors are reported in function is noted. Do not use a coding style that is too
clever or too difficult to understand. Do not use an identifier for multiple purposes sometimes
several temporary entities are stored in the same variable citing memory efficiency but problems
associated with this practice are variables cannot be identified since their naming would be the
same and it makes it difficult to understand code.

That means we cannot assign them proper names. Error correction in such cases or further
enhancements are then difficult. The code becomes difficult to maintain manage and several
issues crop up.
(Refer Slide Time: 13:07)
The code should be well documented the length of any function should not exceed 10 Source
lines, do not use go to statements. These are some of the conventions against which the code is
checked for the purpose of creating the this particular code review document. Some of these we
already mentioned in the lecture if you may recollect. Next comes the actual reports obtained
from the from the team members.

So, there were three team members accordingly three reports were generated. Member one listed
the observations after going through the code and these observations are package names are all
lower case the class declarations are capitalized using camel case and start with letters. All the
variables are declared at the start with the type they belong to like UI binding for text displaying
and buttons censored declarations sensor values.

The variables are understood on first Loop like G text 1 is the gravity text box in the UI and the
Azimuth pitch and role convention is understood from the well commented person for it.
Comment is present for every class instantiation also class functions in the imported classes
when used are explained the get default sensor function from the sensor manager class and its
assignment is explained in the comment.

UI binding to the variables are commented in the main activity as well as in the XML document
provided with it. The purpose of the changing of the visibility of buttons and text after event is
appreciated for making the app good in display of course during inspection there is no actual
execution of the code but from the code this particular observation was made by this evaluator
the functions do not span large number of lines of code and are exactly doing what the function
name denotes.

The on accuracy changed function even though empty is needed since the main activity class
implements the abstract class sensor event listener and hence all functions are to be defined this
is understood from the comments above it. The module main activity even though abstract and
functions are small but the main activity is large contains long lines of codes for it to be a very
good design. The functions involving computations do not use variables variable duplications
and each variable has its name for its purpose. In other words each variable name reveals its
purpose.
(Refer Slide Time: 16:12)

Let us see what were listed by member two the observations made by member two after going
through the code the convention for proper variable and class naming is followed and the
variables name when seen marks its purpose in other words clearly reveals their purposes.
Azimuth role even if it was not apparent was clearly explained using the extensive comments for
it that means the code was well documented.
Lines are commented well but sometimes too many comments for a single block reduces the
code readability a little one observation critical of generation made by the evaluator. The ey
elements are understood and I could perform a visualization from the buttons used from the
comments. That is again a very interesting thing pointed out by the evaluator that even in the
absence of actual execution of the code the manner in which the code was written makes it very
clear to the evaluator how the display will look like once the code is executed that is very
interesting observation.

Functions are to the point and not very long the on accuracy change not apparent to me because
it was an empty declaration was understood since it was an abstract class and there were
comment lines present for it. The main module contains too many lines of code and split into
different modules is recommended. The functions involving computations do not use variable
duplication and each variable has its name for its purpose also.

The absolute value being declared earlier as a variable makes much more sense of how the
computations flow works. These are the observations made by the second evaluator. Let us see
the observations made by the third evaluator Java convention for naming was correct and no
apparent mistakes found. All variables declared belong to a particular type and it was
commented at the start for understanding.

Functions have a similar flow and do exactly what the function name entails the azimuth beach
role even if it was not apparent was clearly explained using the extensive comments for it. While
commented code for every part clearly understood purpose. Comments for the UI elements were
present in the main activity module as well as the XML resource module which is instantiating
them. Functions are to the point and not very long.

Why on accuracy changed was left empty was not apparent to me. So, all the evaluators
appreciated few things mentioned that many things are in line with the conventions and standards
but there are some points of concern.
(Refer Slide Time: 19:40)
Few more comments made by the third evaluator where the main activity module has too many
functions and multiple purpose. The functions involving computations do not use variable
duplication and each variable has its name for its purpose. Also the absolute value being declared
earlier as a variable makes much more sense of how the computation flow works. So, these are
the observations made by the evaluator.

So, let us summarize the code for the system was developed and given to the team of evaluators
having three evaluators. Each of them have gone through the code with the purpose of inspection
based review in inspection based review execution is not required only line by line checking of
code which at the beginning of the document is clearly mentioned that is a slow process. So, not
more than 400 lines of codes are inspected at a time.

Otherwise the results may not be very good. After going through the codes each evaluator
prepared some list of observations and those lists we have just seen for each of the evaluators.
(Refer Slide Time: 21:11)
The last section of the document is the conclusion section. So, the observation list is provided to
the developer before actually providing it to the developer the team evaluation team brainstorms
with the list and comes up with a single list with all the critical observations listed. In this
particular review document that list is mentioned in the conclusion section. From the reports of
the team members who have performed the code review we have ascertained some pros and cons
of our code.

The cons are taken to be critical points and common to all will be definitely changed that means
Pros are the positive sides points of concerns and those need to be addressed before the code is
for the tested. So, first the list of Pros the classical coding errors like memory management and
variable duplications are non-existent. All the standard coding conventions have been followed
the variable names and function names State their purpose and clearly depict the flow as stated
by all members.

Code is clearly understandable the classical coding errors like memory management and variable
duplications are non-existent. Comments are present for every part of the code and explained
correctly in case they are non apparent. The UI elements are well placed in their declaration and
commenting and Abstract visualization can be made these are the pros of the particular code
developed by the development team.
The reports also reveal some cons once the reports are compiled those cons or the negative points
are found out and those are listed here. Critical points not in all team members reports that means
there is no agreement about these points sometimes the commenting is a little much and comes at
the cost of readability. The reason why on accuracy changed function was left blank was not
completely understood.

But there are some points which are reported by all the evaluators. Critical points common in all
team members reports the main activity module is very large and should not encapsulate. So,
many functions with different purposes. Like both reading sensor and the computation part. So,
this is highlighted by all the evaluators whereas the other two points are not highlighted by all
the evaluators.

So, based on this conclusion code needs to be refined ideally the common points are to be taken
care of that means points that are found out from all the reports.
(Refer Slide Time: 24:20)

So, in the final edits part of the document it is mentioned that the main problem with the
largeness of the main activity module will be taken care of by splitting into multiple modules
each for the instantiation and the computation part of the code and we will ensure that each new
module remains small it tells how to refine the code. Also added an extra comment for the reason
explaining why on accuracy changed is empty.
So, that is apparent and the comments for some repetitive lines are removed and put for an entire
block to enhance readability. So, in this exercise the comments that are not common to all
evaluators are also taken care of. Since the coding errors on the memory allocation and data
duplications etc are non-existence we make the above changes and move on to the testing phase
of our project. So, here the development team declares that with the above actions taken based on
the evaluator reports no further changes need to be made at this stage of code development.

And the code can be now formally tested with other testing methods. So, to summarize we talked
about how ah code review document can be created how it looks like what should be there in the
document and what actions are taken that also need to be mentioned in the document. These
actions are primarily based on summarization of the reports that are received from the code
evaluation team. Now there can be two types of issues one type of issue refers to those that are
mentioned by individual evaluators.

But there is no agreement among all the evaluators about those issues. And the next type is the
more crucial type where all evaluators agree that the issue exist or those issues exist. So, there is
an agreement both these issues ideally should be taken care of in the code in particular the
common issues are to be taken care of even if the other issues are not taken care off. However
both ideally should be taken care off.
(Refer Slide Time: 27:09)
At the end of the document some references can be listed if while creating the document you
have taken help from some sources those must be listed at the end. With that we have come to
the end of this lecture this is continuation of lecture 26 where we discussed about code review
and in this lecture we saw a case study on how to create a code review document I hope you
understood the concepts and enjoyed the lecture looking forward to meet you all in the next
lecture, thank you and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Lecture: 31
Black-Box Testing I

Hello and welcome to the NPTEL MOOCS course on design and implementation of human
computer interfaces lecture number 27 where we will continue our discussion on code testing.
Before we go into the subject matter of this lecture let us quickly recap what we have learned and
what we are going to discuss.
(Refer Slide Time: 01:03)

So, if you may recollect we are discussing the interactive system development life cycle. This
life cycle is a stage wise development of interactive systems which are of interest to us
essentially when we talk about human computer interfaces. We are actually referring to
interactive systems and it helps if we follow some systematic stage wise development process to
design and develop such systems.

One such stage wise development process we are discussing here that is the interactive system
development life cycle which consists of several stages. As you can see here the life cycle is
consisting of requirement gathering stage design prototype evaluation stage coding and
implementation stage code testing stage empirical study stage and deployment and maintenance
stage. Among them we have already learned about requirement gathering analysis and
specification stage.

We also learned design stage prototyping stage evaluation stage. In fact if you may recollect this
design prototype evaluate cycle actually refers to stage wise development of interfaces keeping
in mind usability issues. Design also refers to design of the code we have also learned code
design as well code or system design. We also have learned coding and implementation stage
where we learned about good coding practices and do's and do not’s while going for writing
codes for implementing a system.

Currently we are discussing the code testing stage also at this stage it is helpful to remember that
the outcome of each of these stages is a detailed document. For example for requirement
gathering analysis stage at the end of this stage we produce an SRS document. We have seen
such document formats and some case studies on how to create such a document design
prototype evaluate cycle also leads to documents.

So, we have seen case studies on such documents design documents at the end of this stage
design document we have also seen design document for system design. So, both for interface
and interaction design as well as system design documents we have discussed. At the end of
coding stage we get the codes which are the documentation part as output of this stage.

After code testing also we produce testing reports which are the documentation parts we have
already seen such reports for review-based code testing and the other code testing methods that
we are going to learn in subsequent lectures will also produce such testing documents as we shall
see in subsequent discussions. So, at the end of each stage we should remember that we are
supposed to produce some documentation.
(Refer Slide Time: 04:46)
Now in code testing what we have learned earlier broadly there are two types of code testing one
is review based and one is execution based. So, we have discussed in details the review based
code testing.
(Refer Slide Time: 05:03)

In review based code testing we have seen that there are two types code walkthrough and code
inspection. We have also seen how code walkthrough is similar to the cognitive walkthrough
method that we have learned earlier in the context of prototype evaluation. Similarly code
inspection is similar to the heuristic evaluation method that we have learned earlier in the context
of prototype evaluation. One issue with the review based code testing is that which we have
mentioned earlier as well.
(Refer Slide Time: 05:35)

Such testing methods are informal meaning they mostly evaluates code such methods mostly
evaluate code qualitatively. So, that is one major issue with any review based code testing if that
is the case then why we go for it why we do not go for more quantitative approach because
quantitative measurements are supposedly to be better than pure qualitative measurements. Now
such methods are typically good for early evaluation when the code is built but when we want to
quickly check whether there are some issues with the code.

So, this early evaluation stage is where we apply this review based code testing methods to clean
up the code before more rigorous and formal testing is done. So, one thing to be noted here is
that we do not rely entirely on review-based code testing rather we use review-based code testing
to clean up code before such codes are subjected to more rigorous and formal testing methods
why that is done because review based testing’s provide quick way of detecting errors.
(Refer Slide Time: 07:05)
So, apart from review based code testing we have execution based code testing. Now execution
based testing is more rigorous and formal testing of the program that you are writing. So, we can
think of this execution based testing as formal program testing methods.
(Refer Slide Time: 07:28)

So, when we are talking about any formal testing method what are its characteristics. So, any
formal program testing method consists of providing the program which is being tested a set of
test inputs or test cases and observing program behaviour along with or the output. So, in review
based testing we do not really execute the code with a computer in code walkthrough method
that is done manually.
In inspection based method there is no execution at all instead we check for qualitative
characteristics of the code such as whether they follow coding standards whether some common
errors have occurred just by looking at the code rather than actually executing it. In contrast in
execution based testing we need actual execution of the code. Now that execution takes place
with respect to some inputs.

And during execution the code behaviour is also checked along with the output or only the
output is checked.
(Refer Slide Time: 08:47)

If during execution the program fails to behave as expected or there is a mismatch of output then
the conditions under which such failure occurs are noted for later debugging and correction. So,
essentially here we provide some inputs and check execution. If we notice some anomaly there in
terms of execution or in terms of output then we note down the input which serve as the
condition test condition and then we make corrections in the code to take care of such anomalous
conditions.
(Refer Slide Time: 09:33)
Just to quickly recap while trying to formally test a code we make use of some terminologies
which we have mentioned earlier. Two important terminologies are test cases and test suits a test
case is by definition a triplet where I indicates data input, S indicates system state at the time of
input and O indicates expected output. So, it is a triplet of three terms I, S and O. However for
simplicity in this and subsequent lectures we will assume that test case represents only a doublet
I and O and we will not consider S in our discussion.
(Refer Slide Time: 10:24)

The other term that we should remember is test suit that is set of all test cases with which a given
software is to be tested. Now note that we are going to use the terms program code and software
interchangeably in this context of this lecture and subsequent lectures in fact in the context of
this course these terms will be used interchangeably and synonymously. So, they will refer to the
same concept.
(Refer Slide Time: 10:57)

So, in formal program testing or execution based testing then what we need to do is we have to
have a test suit consisting of test cases which will be provided as input we will consider the test
suit as the input conditions will check program behavior and the output and then if we detect
some problem with these inputs then we will note down that inputs and take corrective actions.
Now the question is how to decide on this test suit or rather how to decide the test cases.

Generally a program or a practical real life program takes as input data or information from a
very large domain. So, typically what we find is that possible input data to a program in real
world real life are generally extremely large or infinite in size. We must design test suit that is of
reasonable size and can uncover as many errors existing in the system as possible. So, input data
values can come from a very large domain.

And our objective for formal testing is to decide on a test suit which is of reasonable size and
which can uncover as many errors as possible. Now these two conflicting conditions one is large
input size another one is uncovering as many errors as possible leads to some practical issues.
(Refer Slide Time: 12:57)
First of all if we randomly select the test cases and form our test suite will that be good.
Randomly selected test cases are not necessarily good they not necessarily contribute to
significance of test suit that means randomly selected test cases need not detect additional defects
not already detected by other test cases. So, we already have a test suit and we want to add some
test cases in the suit.

So, we random decided on some test cases and added that added those cases in the test suit and
used those cases as input data to uncover some more errors but that need not necessarily lead to
uncovering of more errors. Whatever errors we have detected so, far with the earlier available
test suit need not be enhanced with randomly decided test cases.
(Refer Slide Time: 14:10)
Also number is not a very significant factor here number of test cases is not an indication of
testing effectiveness that means if we go for a large number of test cases which are selected at
random does not guarantee that all or even most of the errors will be uncovered. So, two things
we have to keep in mind one is we did not decide on test cases randomly and secondly we should
not go for large test suits where most of the test cases are decided at random both these
approaches need not lead to uncovering of most or significant errors in the program.

We have already seen in earlier lectures some examples which actually tells us that these
randomness in test cases or randomly decided numbers are not necessarily good approaches.
(Refer Slide Time: 15:22)
So, these two things imply that our test suit should be carefully designed not decided randomly.
So, we should do something to design the test suit. This in turn implies that test should be
designed following a systematic approach. So, we should take records to systematic approaches
to design our test suits rather than going for random choice of test cases.
(Refer Slide Time: 15:54)

Now there are broadly two types of systematic approaches using which we can decide on the test
cases.
(Refer Slide Time: 16:02)
One is functional testing in this case what we do is we design test cases using only functional
specification of the software that means without any knowledge of the internal structure of the
software. So, we visualize the software as consisting of a set of functions each function is treated
to be a black box we do not know how the function the output or how the function gets its work
done. So, we have no knowledge of the internal structure we are only bothered about the input
and output of the function. Such an approach is called a black box testing approach or a
functional testing approach.
(Refer Slide Time: 16:56)
The other systematic method for deciding on test cases is the structural testing method. This is
just the opposite of functional testing in functional testing we are not aware of the internal
working of the functions or the code whereas in structural testing we are fully our of the internal
structure of the software that means how the codes get executed and test cases are designed using
this knowledge of the internal structure.

This approach the structural testing approach is also known as white box testing approach. So, in
this course we are going to learn about these two methods for formal program testing where the
way we approach the problem decides the design of test cases. In black box testing we approach
the problem as testing a software which consists of functions but we do not know the internal
working of the function we only know the input to the functions and the output of the functions
and based on that knowledge we decide the test cases.

In the other approach the structural testing approach. We are fully aware of the internal working
of the software the functions and based on that knowledge we decide the test cases.
(Refer Slide Time: 18:21)

Let us first learn about the black box testing approach.

(Refer Slide Time: 18:26)
So, in black box testing we go for designing of test cases based on input and or output values
only. So, we do not assume any knowledge of the design or code. So, suppose I am trying to test
this function add int a int b let me write it properly int a, suppose we want to test this function if
we are going for a black box testing we do not know how this add function works how it
produces the output.

So, this part the internal structure of the function is unknown to us it is as good as it does not
exist. Instead what we know is that there is a function which takes two integer values as input
into a and in b and produces some integer values only this much knowledge we have and based
on this knowledge we go for testing it. So, we do not know how the internal things happen when
we design test cases based on this approach this is a this is called functional approach or the
black box testing approach.

Now when we know of only the function input and output rather than the internal structure and
try to design the test cases. So, we can approach this problem in either of the two ways. Two
main approaches are there.
(Refer Slide Time: 21:00)
Equivalence class partitioning and boundary value analysis in fact they are not either or instead
what we do is while designing test cases we approach the problem as a problem of equivalence
class partitioning as well as a problem of boundary value analysis both are there it is not either
or.
(Refer Slide Time: 21:24)

Let us first briefly try to learn about equivalence class partitioning concept. So, when we talk of
equivalence class partitioning the first concept that comes to our mind is the term equivalence
class and then comes partitioning concept. So, first concept that we should be our office
equivalence class and second concept is partitioning. So, what is equivalence class? Remember
that when we talked about function input we said that the input value can come from typically a
large domain of values.

Now suppose we represent it as a set. So, this is the input domain set this set we can partition
into subsets like this generally non overlapping subsets those subsets are equivalence classes. So,
the idea is that we have a domain of input or input domain which is a set and we divide it into or
partition it into subsets each subset is called an equivalence class and generally these subsets are
non overlapping.
(Refer Slide Time: 22:58)

Now what is the purpose of dividing the input domain into subsets or equivalence classes. We do
that assuming that the behaviour of the program is similar for every input data belonging to an
equivalence class that means suppose we have this equivalence class partitioning that means
input domain is divided into equivalence class 1 2 3 4 and such subsets what we are assuming
here or what is the motivation behind this partitioning is that in each equivalence class we get a
set of input values input set.

For each input set the function behaves in the same way if the function is denoted by f then
behaviour of f for input set is same for each element in this set. So, the program behaviour is
similar for each element belonging to an equivalence class. Now what is the significance of that
particular statement that is program behaviour is same for each element in an equivalence class.
(Refer Slide Time: 24:38)

It means if we test our code with any one value of equivalence class of an equivalence class then
that is as good as testing with all input values belonging to that class. Remember earlier we said
that generally for real world programs the input domain size is very large number of possible
inputs is very large it may be infinite as well. So, it is practically impossible to test for each and
every possible input.

So, then what we can do is we can carefully select a finite number of input test conditions as our
test cases and then test the code which is expected to reveal all our most major problems with the
code equivalence class partitioning gives us one such method. Here by carefully analyzing the
input set and partitioning it into equivalence classes what we can do is from each equivalence
class we can choose only one input value and the matching output value as our test case.

This is because by definition equivalence class means the program behaves in the same way for
all input values belonging to a to an equivalence class that means if we test the program with one
element that is as good as testing the program with all the elements in the equivalence class. So,
in that way we can keep the size of our test suit finite that is the objective of partitioning input
domain into equivalence classes.
(Refer Slide Time: 26:41)
The other thing that we should consider is boundary value analysis this is closely related to the
partitioning approach. So, input domain is partitioned into equivalence classes such as
equivalence class one two and so on and so forth. Now while choosing an element say one
element belonging to this equivalence class one sometimes we fail to recognize that at the
boundary of the classes. Now each class is a set.

So, the set has boundary values at the boundary of the classes or the corresponding sets the
behaviour may change. So, while we are choosing an element from an equivalence class to
represent the whole class along with that the boundary values are also to be taken into
consideration for those equivalence classes because the behavior may be different at the
boundary values of such classes.

So, we have to take care of equivalence class partitioning and we have to take care of the
boundary values for those equivalence classes while deciding on our test cases that is the
important thing that we should keep in mind while going for black box testing.
(Refer Slide Time: 28:20)
In the next lecture we are going to learn these concepts in more details in terms of several
examples which will make it further clearer to you what are the equivalence classes how we can
partition and how we can use the boundary value analysis to come up with appropriate set of test
cases or the appropriate test suit which is likely to uncover most of the coding errors that we are
interested in.
(Refer Slide Time: 28:53)

Whatever we are discussing in this lecture can be found in these books fundamentals of software
engineering chapter 10 as well as software engineering practitioners approach chapters 19 to 21.
Of course these content these chapters contain the concepts in more details you may go through
these chapters to learn those concepts. I hope you understood the material that we discussed
today and you enjoyed it looking forward to meet you in the next lecture, thank you and
goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Lecture: 32
Black-Box Testing II

Hello and welcome to the NPTEL MOOCS course on design and implementation of human
computer interfaces lecture number 28 where we will continue our discussion on black box
testing. So, before we start let us quickly recap what we learned and where we are now.
(Refer Slide Time: 01:03)

So, as you may recollect we are discussing the interactive system development life cycle there
are several stages in the life cycle among these stages we have already covered some of the
stages and we are currently focusing on a particular stage. So, we have already covered the
requirement gathering stage design prototype evaluate cycle as well as the code design stage
coding and implementation stage and currently we are discussing code testing.

That is once the system is implemented or the code is written for the system implementation
what we do for testing the efficacy of the code.
(Refer Slide Time: 01:53)
There are broadly two ways using which we can design our testing process or there are broadly
two ways using which we can test our code one is review based and the other one is execution
based. In review based code testing again there are broadly two types code walkthrough and code
inspection. Primarily in review based code testing what we do we basically ask the evaluators to
go through the code and identify issues that they feel are present in the code.

Here it is not mandatory to execute the code although in the code walkthrough method some test
cases may be provided for hand execution of the code. What we get as output of review based
code testing is essentially qualitative issues that are there in the code which include conformation
with the coding standards conventions and presence of common errors mostly these type of
issues. The purpose of review based code testing is to identify as many issues as possible before
we go for more rigorous and formal testing.

It may be noted that more rigorous and formal code testing involves more effort than review
based code testing. So, if we can clean the code as much as possible before we go for this formal
code testing then our effort may be less the effort required to test the code formally may be less.
So, that is the objective of review based code testing to give us a quick review of issues that are
present in the code.
Once that is done we go for execution based code testing. Of course it is not mandatory to follow
both the methods any one is also fine as long as we have the ability to deal with the effort
required. In execution based code testing which is also the term used for referring to formal code
testing. We generally use a set of test cases which is input output pair for a given input the output
is mentioned and then we execute the code with the input to see whether the desired output is
generated or not if not then there are issues.
(Refer Slide Time: 04:48)

And then we try to rectify those issues in execution based code testing there are broadly two
ways of doing that one is black box testing or functional testing other one is white box testing or
structural testing. Now currently we are discussing black box testing what it is.
(Refer Slide Time: 05:03)
The basic idea is that here in this case we try to design test cases based on only input output
values rather than the design or the internal structure of the code. So, as we have mentioned in
the previous lectures it is very important when we go for formal code testing to design
appropriate test cases. Now randomly designed large number of test cases not necessarily reveal
errors with the program what we need is a more systematic approach to design suitable test
cases.

Now there are broadly two ways to do that one as we mentioned is a functional approach or also
known as black box testing method and the other one is the structural approach which is also
known as white box testing method. In functional approach what we do is basically we assume
the code to be a collection of functions. Now each function has its own input and it produces
some output even if that is null but still that is a void output.

When we are trying to test the code that means when we are trying to design the suitable test
cases if we are bothered only about the input and output of a function rather than how the
function actually processes the input to produce the output that is the internal code of the
function then we are going to use black box testing method that means we are looking at the
functions as black boxes which takes only input and produces output without any knowledge of
how the output is produced.
In contrast when we are actually trying to design test cases with the full knowledge of how the
output is produced that means we are aware of the internal structure of the code then what we are
following is called structural testing method or white box testing method. So, currently we are
discussing black box testing method.
(Refer Slide Time: 07:13)

In black box testing method again there are two ways using which we can design the test cases
one is the equivalence class partitioning idea and the other one is boundary value analysis. We
started our discussion on these two concepts both are important when we are going for designing
test cases.
(Refer Slide Time: 07:45)
In case of equivalence class partitioning what is the idea we assume that the input domain is a
very large set of values it is. So, large that it is not possible to actually use each and every
possible input for testing the program. So, what we do instead is we try to partition it into subsets
each subset is called an equivalence class with the idea that the behaviour of the program for any
element of an equivalence class is same.

That is suppose the class contains 20 elements or input values for each value the program
behaves in the same way. So, to test the program if we take any value rather than all 20 values
then that would be sufficient to represent the entire class behaviour. So, instead of 20 input
values we can settle with one input value and the corresponding output value as a test case to test
the behaviour of the program for the entire equivalence class of inputs that is the idea that means
we are trying to manage the number of inputs to be considered for testing and we are trying to
reduce the number to a manageable number.
(Refer Slide Time: 09:10)
And why this works because we are already assuming that testing code with any one value of an
equivalence class is as good as testing with all input values belonging to that class. So, this is
very significant. So, we have to very careful while we are partitioning the input domain into
equivalence classes. If we do not do it properly then definitely this assumption will not hold and
our testing will be flawed. Let us try to understand this concept with some examples.
(Refer Slide Time: 09:40)

We will see few examples where the idea of equivalence class how to choose it and how to select
equivalence classes so, that our testing gives us as many errors as possible that happens. So, with
few examples we will try to understand that. So, let us start with our first example. Suppose you
have written a code to compute square root of an input integer in the range 0 to 5000 both
inclusive. Now you may think that is a very odd program why it should be restricted within this
range.

If I write a program that should be able to take any value as input and produce any output. Let us
for the time being ignore those concerns and let us assume that this is what our code does for the
sake of simplicity in discussion. So, here the input is an integer within the specified range that is
between 0 to 5000 and the output is the square root of that integer. Now if this is the given
scenario then what would be the equivalence classes.
(Refer Slide Time: 11:04)

Let us start with defining only one equivalence class. So, if this problem is given to you then the
most obvious answer would be to come up with an equivalence class with a single equivalence
class which is set of all integers within the range 0 to 5000 both inclusive. So, that is the most
obvious answer that probably most of us will come up with when this problem is given to us. So,
what is our problem our problem is to identify the equivalence classes for the particular program
to be tested.

Now the program takes as input an integer within the range 0 to 5000 both inclusive and when
we are asked to come up with the equivalence class partitioning for this particular problem most
of us most likely to come up with this answer that there will be only one class that is the set of all
integers between this range 0 to 5000 both inclusive.
(Refer Slide Time: 12:19)

Now of course is that the best thing to do will that give us what we are looking for that is a
suitable test suit or the set of test cases that will be able to unearth all the problems that are there
in the program. Can this single equivalence class give us that assurance let us see whether that is
indeed the case.
(Refer Slide Time: 12:49)
So, what is the definition of equivalence class it is a set of elements where for all elements in that
particular set or the class the program should behave in the same way. So, if we are defining
something as an equivalence class then any element in that equivalence class when used as input
should lead to the same behaviour in the program that means the program should be able to
produce the same output.

In other words in an equivalence class we can choose any element to test our program it is not
necessary to choose all the elements we can choose any one element because that is
representative of all the elements that are present in the class. Then in our example if we assume
that there is single equivalence class which is the set of all integers within the range 0 to 5000
then what can be our test cases and test suit.
(Refer Slide Time: 14:06)

Now our test cases should be in the form input and output as we have already seen earlier. So,
this is the doublet of the form input and output where the input is any number taken from the
equivalence class a single number of course and output is the expected output of the program for
the given input. So, we are choosing a number as input and if that number is given to the
program it is supposed to produce some output.

So, the correct output that is supposed to be produced by the program is chosen as the output of
the test case. Now in this example if we have chosen a single equivalence class which is the set
of all integers between the range 0 to 5000 both inclusive then we can choose any one test case
because all the other inputs will lead to the same program behaviour. So, no need to test for other
inputs.
(Refer Slide Time: 15:24)

So, let us choose this one 4, 2 where 4 is the input and 2 is the output that is 4 if given as input to
the program produces the square root of 4 that is 2.
(Refer Slide Time: 15:41)

Now if we use only this single test case. So, our test suit consists of a single test case are we
going to get a comprehensive idea of the program behaviour. Here of course we are assuming
that we have a single equivalence class that means by definition we should be okay with a single
test case but does that really mean that with that single test case we will be able to identify all
issues that are there with the program.

Ideally it should be yes we should be able to identify all issues that are present with the program
because we have taken a representative case from the equivalence class. Now here of course the
term representative is not very significant because any element from the equivalence class is a
representative case. So, we do not need to do anything extra but let us see one more example of
an input.
(Refer Slide Time: 16:49)

Suppose the user inputs -9 is our program able to deal with this input in real usage scenario. Now
our program can produce output when the input is given within the range 0 to 5000 in real usage
scenario a user can make mistakes the user can erroneously put -9 in that case have we tested for
that input with our test suit definitely no. We have not tested for this case which may happen in
real world scenario because users can make mistakes.
(Refer Slide Time: 17:33)
We never tested for this input it is outside the range we considered. So, what it implies it implies
that we missed something in our equivalence class formulation. It is not necessary that when we
are thinking of equivalence class we only think of situations where there will be no errors. To our
eye is human that we all know. So, while providing input it is possible to make mistakes and we
should be also careful about handling those scenarios where user input is not within the limit that
is specified for correct behaviour of the program.
(Refer Slide Time: 18:31)

To take care of this scenario let us redefine our equivalence class definition. Now the class is
defined as the set of all integers both positive and negative because we talked of -9. So,
obviously it may come to our mind that ok then let us extend our definition let us incorporate all
integers not only the integers within that specific range but all integers whether negative or
positive. So, this is another obvious extension of the definition of equivalence classes.

Will it serve our purpose with this extension of definition will we be able to test program
behaviour for different scenarios.
(Refer Slide Time: 19:23)

The answer is still no we will not be able to test for different scenarios.
(Refer Slide Time: 19:27)
Why let us see, with this new definition again we take one test case let us say it is 9, 3; 9 is the
input and 3 is the output that is square root of 9. Now since the entire domain of integers is. Now
considered to be the equivalence class any one element here 9 it should be 9 rather than 4. Any
one element should be representative and sufficient to capture program behavior the same thing
that we have discussed earlier that is.

Now we have extended the definition of equivalence class it encompasses all integers however
for any integer within this class the program should behave in the same way as per definition of
equivalence class. So, if we choose any one integer from this class which in this case is 9 as
input then the program behaviour should be same for all other integers from this class but is it
really.
(Refer Slide Time: 20:39)

So, clearly that is not the case it still can't handle user inputs like -9. Remember that by definition
we said that equivalence classes have elements that lead to same behavior for all inputs however
this particular program that we are discussing are designed to deal with only inputs from the
range between 0 and 5000. Now if we are considering minus 9 as an input then of course this
program is not designed to take into account that input because it is outside the range.

On the other hand we have considered this as part of the equivalence class. So, clearly there is
some issue with our definition of equivalence class considering the scope of the program. Also
we do not know what happens if user inputs 5001 onwards that is 5001, 5002 some integers that
is greater than 5000 or outside the range that is defined for this program. So, with this definition
of equivalence class where all integers are involved we can choose any one integer as
representative case.

But that will not tell us anything about the program behaviour when erroneous inputs are
provided such as negative integers or integers that is outside the range namely 5001 onwards.
(Refer Slide Time: 22:15)

So, you have to be very careful. We should not simply consider the most obvious range as the
equivalence class. So, that is the biggest folly we generally make when we think of equivalence
class as the most obvious range of values. It may affect our ability to form suitable test suit for
comprehensive testing if we are unable to properly identify the equivalence classes.
(Refer Slide Time: 22:44)
Now let us go for a non-obvious solution for the same problem that is testing the code which
produces square root for any integer within the range 0 to 5000. So, instead of 1 let us now
consider 3 equivalence classes. First equivalence class: that is set 1 which is set of all negative
integers which represents invalid input range. So, from the point of view of the design of the
program any negative integer provided as input is an invalid input.

So, we consider a separate equivalence class for all invalid inputs where inputs are negative
integers.
(Refer Slide Time: 23:40)
Then we have another set that is set to that is set of all integers in the range of 0 to 5000 both
inclusive. Now this represents the valid input range.
(Refer Slide Time: 23:53)

and then we have another set that is set of all integers that are larger than 5000 which is another
invalid input range. So, we have. Now three equivalence classes one represents all negative
integers one represents all valid input that is integers within the range 0 to 5000 both inclusive.

And one represents all invalid positive integers that is integers which are greater than 5000. If we
have these three sets as our equivalence classes then what will be the test suit.
(Refer Slide Time: 24:29)
Test suit must include representative input from all equivalence classes that means in this case
there will be three test cases comprising of the test suite one is for the three equivalence classes.
Now in the test case of course along with the input we need to provide also the corresponding
output to complete the doublet.
(Refer Slide Time: 24:57)

For example we can have a test suite like these three test cases comprising of these three test
cases minus 5 with the corresponding output 500 with the corresponding output 6000 with the
corresponding output. Now in minus 5 that is an invalid input in case of minus 5 which is an
invalid input the output can be a message a message that invalid input. Similarly when 6000 is
provided as input output can be a message like invalid input.

Whereas in case of 500 output can be the square root of 500. So, with this will our problem be
solved. Now before we go to that question let us just note these two things that is it is a set of
three elements that means our test should consist of three test cases each element or each test
case is a representative of the corresponding equivalence set that is set 1 set 2 and set 3. Each
element is of the form input and output. So, these things we should keep in mind while we are
going to design our test suit.

Now if this is the scenario where we are forming three equivalence classes for the input domain
and we are going for non obvious classes then will it be able to handle all possible scenarios. Of
course in this case the answer is yes we know what happens when the invalid inputs are provided
and we know what happens when the valid inputs are provided. So, it gives a better partitioning
than the earlier obvious partitioning schemes.

So, thus with a more granular classes we could take care of different situations and once
problems are identified we can accordingly modify the code to take care of those let us give one
example of how to identify the issues and take care of those. So, when the test should suppose
minus 5 and output is given where output is coming as null. So, probably this is not a very
informative output. So, we may like to provide to the user a message mentioning invalid output
rather than simply printing null. So, then there is some issue.

So, maybe we need to rectify the corresponding code for dealing with invalid inputs and then
there we need to print message. So, that is one way of taking care of issues while testing the
code.
(Refer Slide Time: 28:14)
Now let us go for another example to better understand the concepts let us assume that you are
asked to write a program which computes intersection point of two straight lines and displays the
result and you are asked to test it that means you are asked to design suitable test cases or the test
suit to test this program. What you are going to do your job is to identify the equivalence classes
and then correspondingly identify the test cases or the test suit.
(Refer Slide Time: 28:44)

So, in this program we have as input two integer pairs m1 c1 and m2 c2 each pair defines a
straight line assuming the form y equal to mx + c. So, m is the gradient and c is the intercept part.
Now the output is the intersection point of these two lines if this is the problem that we are asked
to design suitable test cases for this testing of this code then what would be the equivalence
classes. If we go by the obvious choice that is we can settle for set of all lines as representing the
equivalence class will it work? It will not work. Why it will not work?
(Refer Slide Time: 29:34)

For the same reason we will not be able to create a test suit to capture variations in input that
means we will not be able to capture different execution scenarios for different inputs. So, what
are those different scenarios what are the variations that we are referring to here, let us quickly
have a look at those variations. Now the input is pair of straight line when we talk of variation
we should look to capture different relationships between the pair from the point of view of
intersection. So, what can be the different relations between those input lines.
(Refer Slide Time: 30:18)
There are three possibilities there can be parallel lines that is m1 equal to m2 and c1 not equal to
c2. We can have intersecting lines m one not equal to m two we can have coincident lines m1
equal to m2 c1 equal to c2. So, these three relationships can be there between the input pairs
between the input lines parallel intersecting or coincidental lines.
(Refer Slide Time: 30:55)

So, if that is known that is apparent to us then what would be the equivalence classes. Clearly to
take care of these three different relationships we need to have three equivalence classes, set of
all parallel lines, set of all intersecting lines and set of all coincident lines. So, we have these
three equivalence classes one is set of all parallel lines second one is set of all intersecting lines
and third one is set of all coincidental lines.
(Refer Slide Time: 31:34)

An example test suit is shown here. So, we have three elements each corresponding to one of the
equivalence classes in each element we have two pairs this is line one this is line two this is m
this is c. So, for each element that is each line it is represented with these two values gradient and
intercept. Now we can have these three elements corresponding to these three equivalence
classes of set of all intersecting lines set of all coincidental lines and set of all parallel lines.

So, when we are talking of set of all parallel lines we have m1 equal to m2 but c1 not equal to c2
and this input represents a representative element from the equivalence class. Of course here we
have not provided the output for simplicity in ideally here we should also provide the output.
Then we have set of all intersecting lines m1 not equal to m2 and set of all parallel lines where
set of all coincidental lines where we have m1 equal to m2 and c1 equal to c1.

So, this is the input along with that we have to specify the output in each case. So, this is one
equivalence class which this is one test suit based on the definition of the equivalence classes for
this particular example which ideally should take care of the different scenarios. So, we will be
able to know the program behaviour for these three different scenarios.
(Refer Slide Time: 33:41)
Now let us quickly try to figure out this other problem. So, what would be the equivalence
classes if instead of lines we. Now consider line segments. So, input is of the form x 11 y 11 x 21
y 21 and so on where each pair indicate one end point and the output is intersection point or null.
So, instead of lines we are now providing line segments as input and output is intersection point
or null. Now if that is the case what would be the equivalence class or classes for testing this
program. This is given as a take home exercise you may try it whenever you get time.
(Refer Slide Time: 34:31)

Let us now move to our third example. This is a slightly different example earlier once mostly
straightforward examples but this one is more practical more realistic example. Suppose you
have developed an user authentication system which is part of a bigger system that you are
working on. The authentication system or the function let us consider this whole authentication
system as nothing but a function.

It takes as input user id and produces success or failure messages which can be used to proceed
further for this given program that is the function which takes as input user id and produces some
message if I want to test this program what would be the equivalence class or classes how do we
design our test suit for this program.
(Refer Slide Time: 35:30)

Now here we know that input is user id or user identifier but that simple bit of information is not
sufficient we need more clarity on exactly what is the user identifier before we go for designing
our test suit.
(Refer Slide Time: 35:48)
So, first thing is you have to get more clarity on the input. Suppose better clarified input is
provided which is the user identifier is nothing but an alphanumeric string is it a sufficient
information? Still not sufficient. For further clarity we probably require length information also
what is the length of the string. Is string of any length acceptable or the string must have a length
restriction.

Suppose it is further specified that the length of the string is restricted to 5 and exactly 5 that is
user id must be a five character string it cannot be a 4 character string it cannot be a 6 character
string or any number other than 5. So, that is a very clear way of specifying the input that is the
program takes as input a 5 character alphanumeric string as user identifier and produces a
message of success or failure while authenticating the user.
(Refer Slide Time: 37:04)
Now with that knowledge let us try to go for design of the test suit. So, the obvious or intuitive
solution for equivalence classes would be set of all alpha numeric strings but is it sufficient is it
capable of identifying all issues with the program of course not.
(Refer Slide Time: 37:25)

Program behavior for a 10 character string and 5 character string should not be the same because
we have specified that it should only accept 5 character string it should not accept 10 character
string. So, definitely the output that means the behaviour of the program for these two different
string lengths should be different.
(Refer Slide Time: 37:48)
What can be a better solution let us have two equivalence classes set of all alpha numeric strings
of length 5 and equivalence class 2 is all other strings, will it work? It looks like it should work
but will it really work it may not work.
(Refer Slide Time: 38:10)

Let us have an even better solution. So, we have class one which is that is equivalence class one
which is set of all five character alphabetic only strings equivalence, class 2o set of all five
character numeric only strings, class 3 set of all five character alphanumeric strings, class 4 set of
all alphanumeric strings with length greater than 5, class 5 set of all alpha numeric strings with
length less than 5 class 6 set of all strings with special characters that is characters other than
alpha numeric characters.

So, if we have these six sets will it give us some better way of designing our test suits definitely
yes if we have only two equivalence classes one is set of all five character alphanumeric strings
and set of all strings that are not of five character length that will not give us many scenarios as
listed here we will have our test suit comprising of only two cases which will not be sufficient to
deal with these many scenarios that are listed in this improved solution.

That means what happens when we are inputting string with only numeric characters string with
only alphabetic characters string with alphanumeric characters string with special characters
although it may be a five character length strings of length more than five or less than five. So,
all these different situations cannot be dealt with only two equivalence classes instead we have to
go for more granular classes what is shown here.
(Refer Slide Time: 40:14)

So, in this case what will be our test suit one input output pair from each set. So, that means at
least six test cases we can have which will give us a better idea of the performance of our
program in different input scenario in comparison with the test suit that we would have got had
we been considering the two equivalence classes as mentioned earlier. Can we do any better than
this six classes.
In fact these six classes are still limited there are other scenarios that are possible which will not
be taken care of with these six classes. So, you can think of a better solution I am leaving it as a
take home exercise like the earlier one where we are considering line segments instead of lines.
So, that is all about understanding the concept of equivalence class partitioning I hope you got
the idea that is when we are going for equivalence class partitioning we should be very careful
what is not so, obvious can give us much better solution.

So, we should not always look for obvious solutions we should think hard think deeply to come
up with suitable equivalence classes. The three examples are meant to give you an idea of how to
think about suitably partitioning the input domain into appropriate equivalence classes. The other
crucial component in designing our test suit while dealing with black box testing method is
consideration of the boundary values or rather it is known as boundary value analysis.
(Refer Slide Time: 42:09)

Programming errors frequently occurs at the boundaries of equivalence classes. So, equivalence
classes are sets typically range of values at the boundaries of this range we often ignore those
boundaries and at the boundaries of this range it is possible to encounter some error in the
program. Now when we say that once an equivalence class is defined only one element from the
class is good enough to test for all the values in that equivalence class.
We are ignoring this fact that at the boundaries program behaviour may change and we should
also think carefully about our test cases when the boundaries are involved. So, due to oversight
programmers often fail to notice special processing required for inputs at class boundaries for
example while defining equivalence classes to define the set we may improperly use less than
instead of less than equal to or conversely less than equal to instead of less than.

So, there may be oversight of defining these class boundaries and because of that oversight we
often ignore some input values that may lead to different behaviour.
(Refer Slide Time: 43:38)

So, in order to address this issue this boundary value analysis is also important while designing
the test suits for black box testing. It essentially refers to selection of test cases at the boundaries
of the equivalence classes it is as simple as that. For example let us reconsider the earlier
function to compute square root of integer values in the range of 0 to 5000 that is the first
example that we have seen.

Now earlier we have seen that there are three equivalence classes that we can define to take care
of different scenarios accordingly we can have three test cases comprising our test suit.
(Refer Slide Time: 44:24)
So, what are the three test cases one test case each for each of these equivalence classes that is
set of negative integers set of integers in the range of zero to five thousand and integers larger
than five thousand these are the three equivalence classes that we have defined and for each of
these three classes we can choose one input output pair resulting in three test cases or a test suit
comprising of three elements for testing our code.
(Refer Slide Time: 44:53)

Now along with those three test cases we also should take into account the boundaries of these
equivalence classes. So, one boundary is the value minus one that is the boundary for negative
integer for that boundary what should be the output we should take care of this one can be zero
that is one of the boundary for valid inputs one of the boundaries for valid input and the
corresponding output should be there 5000 is the other boundary for valid inputs and the
corresponding output should be there 5001 is another boundary for invalid input and the
corresponding output should be there.

So, these are the boundary cases for the three equivalence classes which we should consider that
means our test suit should have three plus this five this four boundary cases that means total
seven test cases. So, only choosing test cases based on equivalence classes may lead to some
problem if we ignore the boundaries because while defining the equivalence classes we may
have one definition but that definition may be due to some oversight

And some improper usage of notations may lead to some confusion on interpreting the classes
accordingly some values we may miss which may lead to different program behaviour. So, it is
always preferable to be extra careful while defining the equivalence classes and include the
boundary cases in the test suit. So, keep in mind to include boundary cases along with the
equivalence classes while designing the test suit.

So, with that I hope you got some idea about the concepts that we are discussing namely
equivalence classes and boundary values and why those are important few things we should note
here.
(Refer Slide Time: 47:22)
One is equivalence classes are sets that means while trying to express those classes we should
ideally use set notations. When you are defining test cases it should contain both input as well as
the expected output. So, only one is not sufficient you must have this input output pair. And as a
rule of thumb always keep in mind that you have to include test cases from valid classes invalid
classes and boundary cases in the black box test suits.

Of course you should not consider this statement to be indicating that there will be only two
equivalence classes valid and invalid. Valid classes can further be divided partisan as we have
seen in our earlier examples similarly invalid classes can also be further divided into multiple
equivalence classes. So, you should keep in mind that while designing equivalence classes you
should consider valid cases or valid inputs invalid inputs and also while designing test suits you
should consider boundary values for the equivalence classes.
(Refer Slide Time: 48:42)
In the next lecture we will go through one case study on how to create this testing document. So,
as I said in this interactive system development life cycle at the end of each stage we produce
some documentation earlier documents we have seen. After the code testing we also produce
some documentation. So, after review based code testing as we have seen we produce a
document after black box testing we can equally; we can similarly produce one document.

In the next lecture we will see how that document looks how it can be created in one case study.
So, that is all for this lecture I hope you understood the concepts the last few things that we
mentioned should be kept in mind that is equivalence classes are sets. So, you must use you must
use set notations to represent them while creating the documents and there are three things you
should keep in mind while going for equivalence classes.

That is think of valid inputs think of invalid inputs and think of boundary cases and while
specifying the test suit you must include both input as well as output not only input which is a
common mistake that we often make.
(Refer Slide Time: 50:22)
Whatever we are discussing can be found in these two books Fundamentals Of Software
Engineering and Software Engineering A Practitioners Approach you can look at chapter 10 in
the first book and chapters 19 to 21 in the second book to know more about software testing in
more details. I hope you enjoyed the content and understood the concepts looking forward to
meet you all in the next lecture, thank you and goodbye.
 Design and Implementation of Human – Computer Interfaces
Prof. Dr. Samit Bhattacharya
Department of Computer Science & Engineering
Indian Institute of Technology, Guwahati

Lecture: 33
Black-Box Testing Case Study

Hello and welcome to the NPTEL MOOCS course on design and implementation of human
computer interfaces. We will continue our discussion of lecture 28 that is the previous lecture on
black box testing in this lecture which is the continuation of the previous lecture we are going to
have a look at a case study of a practical system and the corresponding black box testing of that
system in fact the system that we are going to talk about in this case study has already been
introduced earlier.

That is a student activity monitoring system and alert generation system which we have
mentioned in a couple of previous case study lectures we will continue that same system and
here in this lecture we will see how to create a black box testing report for the system.
Remember that in this course we are learning a stage wise development of interactive system at
the end of each stage we are supposed to generate a document.

Same is true for this code testing stage where we are going to generate a testing report. We have
already seen such a report for a system in case of review based testing in this lecture we are
going to see such a report for our system for black box testing.
(Video Starts: 02:16)

So, the system in question is student activity monitor and alert generator. We have already
introduced this system earlier in some other case studies in this lecture we will see a report on
black box testing of this system. As usual the cover page of the report contains the person
number shown here along with the date of the person that is followed by the name of the persons
who have prepared the report the place as well as some additional information like who is
supervise the report but of course this is optional you may or may not include this that is the
cover page.
Next comes a table of content where all the sections and subsections are listed introduction
section having these four subsections. Then the testing report which is the core component of this
document having several subsections in these subsections as you can see there is some
introduction to black box testing then the goal of testing evaluation of test cases unit testing then
the testing report for individual functions that were tested.

Namely these three functions were tested compute orientation calculate proximity and second
frequency. So, we will talk about what these functions are and how those are tested for each of
these functions details were provided like the domain of input values domain of output values
then equivalence class partitioning boundary value analysis and observations that is given for all
the three functions that were tested for this system. And the document ends with a conclusion
section.

At the end of the document it is advisable to add references if some references were used for
preparing the document. After that like before some revision history may be mentioned ideally it
should be included to show the historical evolution of the document when it was first created and
when it was created next or refined next the whole history along with the version numbers given
to each of the persons then comes the first section that is introduction.

So, in this section common things are listed these things are mostly common to all the documents
that are outcome of each of the stages namely purpose, purpose of this testing. So, the purpose of
black box testing for the particular system is to start planning as soon as the artifacts are ready
the main intent of this is that the developers can realize if their requirements will surface and if
the program does as based on the functional requirements.

Then the hardware used for testing is mentioned in this case it is mentioned that mobile device
used for testing was a particular make and model with the following specification amount of ram
processor details and additional memory space used if any. This is followed by the conventions
used in the subsequent part of the document that is whenever this term occurs instructor
professor it refers to person who shall be using the software for monitoring.
If the term student is used that refers to a person who shall be monitored by the instructor users
are basically persons who can be either students or instructors. Device refers to an electronic
device using which the instructor is delivering their lecture accelerometer a sensor that helps
determine. The second frequency gyroscope a sensor that helps determine the orientation of
students device proximity sensor sensor that helps determine the distance between the student
and their device.

Whenever the term sensors are used they collectively or the term collectively refers to the three
sensors accelerometer gyroscope and proximity sensors on the students device. Android refers to
the android operating system Google refers to the Google company. So, this list provides us the
conventions terms that are used in subsequent part of the document. Then comes project scope
this software is meant to be deployed in an IT enabled large classroom environment where in the
lecture delivered by the instructor is via a device through which both audio and video are
transmitted.

This software shall allow the instructor to conveniently monitor the attention of their students in
real time and if required generate some alert. So, that is the overall scope of this system or the
project. So, that is the content of the first section that is introduction. Next comes the main part
of the document that is the report on black box testing of the system. So, in the black box testing
section which is the main section of this document it starts with an introduction this talks about
in brief black box testing and what it does.

So, black box testing attempts to find errors in the external behaviour of the code in the
following categories. So, it lists some categories in which the errors are analyzed incorrect or
missing functionality interface errors, errors in data structures used by the system is by the
interface behaviour or performance errors initialization and termination errors concurrency and
timing errors. These are broad categories of errors that are analyzed in black box testing of
course in our lectures we did not mention about these categories but these categories are a
primary concern here.
Through this testing we can determine if the functions appear to work according to specifications
that is the overall objective of this testing it is suggested that the black box testing is performed
by an actor who is not a developer as the tests are made to ensure the functions perform as
needed by the customer. Black box testing is also called functional testing and behavioural
testing. These are about some information on black box testing some general information.

Next comes the subsection goals of the testing because black box testing purposely disregards
the program's control structure that means the internal structure of the code attention is focused
primarily on the information domain that is the data that goes in and the data that comes out. The
goal is derive sets of input conditions or test cases that fully exercise the external functionality.
So, it says that black box testing that does not consider internal structure.

So, the goal is to come up with suitable test suits to test different functional aspects of the code.
Next section is evaluating the test cases again it talks about the general idea of the testing
considering the number of input classes and enumeration of test cases in each of the total number
of test cases will be too long or too large for testing. To avoid this issue these two things are done
first we perform equivalence class partitioning.

That is followed by boundary value analysis all these things we have already discussed in details
in the lectures hence we use the technique called equivalence class partitioning which partition
the input domain into equivalence classes where the set of test cases in the same class as the
property that set of data should be treated the same by the module under test and should produce
the same answer.

In other words any one input value taken from an equivalence class should be representative of
the whole class of input values thus all test cases can be assigned to a limited number of
equivalence classes and output is found immediately. In other words we can manage the number
of test cases by dividing the input domain into equivalence classes. Now in this document it is
mentioned that black box testing was performed for both system testing and unit testing.
However the document primarily lists unit testing findings. So, it first talks about unit testing.
Here we divide the system into modules each pertaining to a single function of computation and
evaluate the test cases according to it. Now one module or function that is mentioned is compute
orientation that is one module then it presents the input domain or the domain of input values for
this module. So, input domain is device orientation.

Now this orientation has three components there are three degree of rotations namely azimuth
Pitch and Roll. These are measured in radians azimuth's angle of rotation about the z axis this.
So, there is some short description of this concept this value represents the angle between the
devices y axis and the magnetic north pole. When facing north this angle is 0 when facing south
this angle is pi likewise when facing east this angle is pi by 2 and when facing west this angle is
minus pi by 2.

Thus the range of values is minus pi to pi pitch is the angle of rotation about the x axis this value
represents the angle between a plane parallel to the device's screen and the plane parallel to the
ground. Assuming that the bottom edge of the device faces the user and that the screen is face up
tilting the top edge of the device towards the ground creates a positive pitch angle the range of
values is minus pi to pi.

Then comes Roll, Roll is the angle of rotation about y axis. So, earlier we talked about of
rotation about z axis, x axis. Now it is about y axis this value represents the angle between a
plane perpendicular to the devices screen and a plane perpendicular to the ground assuming that
the bottom edge of the device faces the user and that the screen is face up tilting the edge left
edge of the device towards the ground creates a positive role angle the range of values is minus
pi by two to pi by two.

So, here in this description as you can see it talked about the nature of the input domain for this
particular function a brief explanatory note on the input values including its components which is
helpful for the reader to understand the concept. Hence the information is input as or the input is
defined as a triplet Azimuth, Pitch, Roll in this form. Then comes the output explanation. So,
what is the output domain for this input the output is a Boolean value true or false which is
displayed when correct orientation function determines whether it is correct or not.

So, there is some function mentioned which produces this output. So, overall function which
contains some other functions of course but this overall function takes as input this triplet
Azimuth, Roll, Pitch and produces an output as a Boolean value true or false. Now with that
knowledge let us now proceed to the next stage of black box testing that is to identify the
equivalence classes for design of the test suit.

So, we need to now identify the classes or the equivalence classes by partitioning the input
domain from the input domain we observe the range of the parameters and set the equivalence
classes in the following way note some note is mentioned which is all values are taken to be in
degrees as we are converting them in the compute orientation function. So, some other function
is also mentioned which is used to convert from radian to degrees.

For the orientation triplet Azimuth, Pitch, Roll the equivalence classes for each parameter are for
azimuth the range of values are all floating point numbers and hence there are two equivalence
classes as defined by the creators of this document. All values between 180 and minus 180 in
other words this range minus 180 80 with a representative value 0. Now this as we have already
mentioned equivalence class is nothing but a set.

So, in set notation we can represent this as set of all x's whereas x is the variable where x belongs
to the real numbers and x is greater than minus 80 and less than x is greater than minus 180 and
less than 180 that is one equivalence class. One more equivalence class for Azimuth input values
all values not between minus 180 and 180 that means the set that does not belong to this range. A
representative value chosen is 250 and in the set notation this can be represented as set of all x's
where x does not belong to r minus does not belong to this set and x is greater than minus 180
and less than 180.

Next is the pitch component. So, for pitch there are three equivalence class partitioning why
because we have a pitch error margin of 5 and an absolute value of 0 hence there will be 3
equivalence classes as defined by the evaluators with values specified in degrees. One
equivalence class is all float values between minus five and zero that is minus five zero
representative value taken is minus two in the set notation this is represented as set of all x, x
belongs to r x greater than minus five less than zero.

Next equivalence class is all floats between zero and five that is this range zero and five
representative value taken is three the set form set of x, x belongs to r x greater than 0 less than 5
and the third equivalence class is all values not between minus 5 and 5 that is a set excluding
these values representative value taken is 45 in the set form set of x and the x is defined in this
way. Then comes roll we have a role error margin of 15 and an absolute value of 45 hence there
will be three equivalence classes pertaining to the error margin.

Class 1 all floats between 30 and 45 that is this range 30 to 45 representative value taken 37 set
form set of x, x belongs to r where x is greater than 30 less than 45 then all floats between 45 and
60 this range 45 to 60 representative value 52 set form set notation this class can be represented
as set of all x, x belongs to r x greater than 45 less than 60 and the other class is all values not
between 30 to 60 that is the set excluding these values representative value taken is 45 and set
notation is shown here.

So, this is how the equivalence classes are chosen note that this is one way of choosing the
equivalence classes this need not be the best way or need not be the only way as we have already
discussed during the previous lectures that choice of equivalence classes is very important to
cover as many errors as possible and here in this document one such choice is shown where for
the input domain comprising of this triplet azimuth rule pitch total eight equivalence classes were
chosen.

Now total number of equivalence classes then will be actually ten when we combine them
together for each class there will be three role giving us nine combinations and one class for
azimuth being anything other than between minus 180 and 180 and accordingly there are 10 test
cases chosen which is the test suit. So, it shows the input combination the output combination for
each of these test cases as you can see here test case 1 2 3 4 5 6 7 8 9 and 10.
For each test case the input and output combination is shown to take care of the different
scenarios. Now once these test cases are chosen actual execution were performed for each of the
test cases for this total 10 test cases and the output was observed for each test case. So, this
column shows the actual output that is observed during execution of the code as you can see here
expected output is true and the observed output is also true.

So, there is no error true true no error false false that means no error output is as expected true
true no error true true again no error false false no error false false no error false false no error
false false no error and instead of error message it exits that means there is some issue here
ideally it should have shown some error messages but instead the program simply exits. So,
some correction may be required at this stage for this particular input combination.

In fact it can be also concluded as for this equivalence class or the set of input values belonging
to this equivalence class there is a mismatch between the expected outcome and the actual
outcome and the program should be suitably rectified to take care of this equivalence class of
input. Now once the equivalence class partitioning is done next is boundary value analysis for
this module for azimuth the boundaries for the minus 180 180 class will be as mentioned in this
line that is minus 181 minus 179 180 179 and 181.

For pitch boundaries for minus 5, 0 and 0 5 will be the test suit minus six minus five minus four
minus one zero one four five six for roll boundaries for 30 to 45 range and 45 to 60 ranges will
be the test suite 29 30 31 44 45 46 59 60 61. So, for each of these boundary cases some test cases
can be designed and then the program behaviour can be observed to be double shear about the
program be aware at the boundaries.

So, for azimuth there can be four such test cases designed with input value and expected output
and then it can be compared with the actual output which is shown in this table. So, in the first
case instead of error message the program exits. So, there is some issue in other cases true true
true true. So, no issue no error but again in the last case instead of error message it exits. So,
again sum is similarly for pitch for the boundary cases three such cases can be defined and here
as we can see the expected output and the actual output are matching true true true true false
false.

So, no issue for role three cases and expected and actual outputs are matching in all the three
cases, so, no issues here as well. So, finally it can be concluded the observation can be concluded
as all the outputs match the expected case except when the azimuth does not lie between -180
and 180 where instead of an error message the program exits. So, some rectification may be done
there the next function that is or the next module that was tested is named as calculate proximity.

Here the input domain is defined as proximity value the proximity value for our used mobile
device Moto G play gets the proximity range from 0 to 100 and output domain is again boolean
true or false which comes at the checkoff is correct proximity in the check attention function
some details are given which is irrelevant for our discussion. So, given this input and output
domain information then let us see equivalence class partitioning for this function.

The units for the values are mentioned in centimeter four equivalence classes were designed all
floats between zero and twenty with the representative value taken as eleven all floats between
twenty and twenty five with a representative value taken as twenty four all floats between 25 and
30 with the value taken as 27 and all floats between 30 and 100 with the representative value
taken as 55. So, where it should be range 30, 200 again I would like to repeat here is that.

This is not the only way to create equivalence classes this is only a sample document showing
how the classes were designed of course the rationale was not mentioned in details that is also
not required you can simply list the classes as per your choice. Now like before here also for
these four classes four test cases were designed with the representative values and the expected
output. So, in the first test case representative value or the input is 11 outputs is false where after
execution they got the false output as well.

So, perfect match second case 24 input true output and actual output also observed to be true 27
true third case actual output also matches 55 false and here also actual output matches with the
expected output next is the boundary value analysis for these equivalence classes with some
assumption that we can ignore here for proximity the boundaries for the equivalence classes 0 to
20 20 to 25 25 to 30 and 3200 and the corresponding test cases will have 0 1 19 20 21 24 25 26
29 30 31 99 100.

So, accordingly four test cases were designed for a group of boundary values one expected
output false and program was executed and for those values false output was observed. So,
match for another group of boundary values true was the expected output and true was actually
observed after execution another group of boundary values observed value was true whereas the
expected value was also true.

So, again perfect match and one value this should be twenty five instead of minus 25 for 25 one
boundary value expected output was true actual output was also true, so, no deviation. So, it
behaved as per expectation. So, finally the observation is all the outputs correspond to the
expected output and hence there are no ambiguous results that mean no error was noticed in this
black box testing of the particular function.

The third function that was considered is checking frequency note that here we are not bothered
about what is actually there in the function that is not the idea of black box testing instead we are
just mentioning the name of the function and what input it takes and what output it produces that
is good enough for performing black box testing as we have repeatedly mentioned in our earlier
lectures.

So, the two functions that we have discussed you may be wondering what were those functions
how those were written and more details about those functions that is not at all required because
in black box testing we simply assume that the functions are black box what we need is only the
name its input and its output and that is what we are seeing in this document as well you need not
bother about the details of the function or how they work you should only learn its name and the
input domain and the output values.

So, the third function that was considered is checking frequency its input domain was defined as
proximity value the second frequency for the mobile device that was used for testing gets the
checking frequency from anything above 0 and the output domain was defined as the output is
again a binary or Boolean value true or false which comes at the Checkoff is correct frequency in
the check attention function. The details that is provided here how the output comes is actually
not required we can as well remove this part.

And that is true for the earlier cases as well although it is given here how this output comes is not
of any use for this particular testing method we can simply ignore that. So, in your document
whether you keep it or not keep it is up to you. Then let us see the equivalence classes for this
function from the input domain the classes were designed two equivalence classes were designed
by the designers by the evaluators one is all floats between 0 and 5 within this range with a
representative value 4 a set notation given.

And second class is all floats above 5 that is between 5 to infinity representative value taken as
20 and a set notation is also given. Accordingly two test cases were designed in each case the
input value and the expected output were mentioned and the program was executed with this
input and the output was observed the actual or observed output was found to be matching with
the input both are true for the other range other test case both are found to be false.

So, again there is a match between the expected behaviour and the observed behaviour after
execution when we come for boundary value analysis for this case for this particular module
again the assumption is made that the rest of the parameters will lead to a true case. So, based on
this assumption the boundary values were decided for frequency the boundaries for these two
ranges 0 to 5 and 5 to infinity we will have test cases 0 4 5 6.

So, there will be 4 test cases in the test suit designed for boundary value analysis input 0
expected output true and the observed output after execution was also found to be true input 4
expected output true observed output true input 5 expected output true observed output true input
6 expected false observed false. So, in all the cases there is a match between the expected and
observed.
So, what we did here or what the evaluators did they first identified the equivalence classes
correspondingly test suit was designed then the boundary cases were identified and
correspondingly another test suit was designed for each function then these test cases belonging
to the test suits were used to execute the program for those inputs the outputs that were produced
by the programs or the functions were observed those observations were matched against the
expected outcomes.

And if there is a match then conclusion is no issues are there with the programs and if there is a
mismatch then the conclusion was that there were some issues and some rectification may be
required. So, in this case in the case of third function and the corresponding boundary value
analysis the observations were all the outputs for both equivalence classes and boundary values
corresponding to the expected output and hence there were no ambiguous results or rather in
other words there were no issues with the program.

So, that is about observing the functions that are primary functions in the code and after
performing the black box testing we compile the observations and come to a general conclusion.
So, the last section is the conclusion section in this section we list the overall observations the
only discrepancy found while testing was in the checked orientation case. When the value of
azimuth that is the z axis rotation variable was out of bounds or not in the given range.

In that case ideally an error message should have been there but in reality when the program was
executed with such a value then the program abruptly exited this is resolved by adding an else
statement to the required program part with error message. So, in the conclusion also it is
mentioned how the issue was resolved however that is not mandatory that need not be added
here. All other outputs correctly match expected results also we have exhaustively gone through
the input parameters and validated all the test cases.

And some conclusion that black box testing is completed for the units and we have ascertained
that all the modules output the correct result for a particular pair of inputs belonging to an
equivalence class. So, what it tells is that what is the final observation how that issues if any that
were observed during the testing were resolved and then it says that the testing is complete. Now
resolving the issues as I just mentioned need not be part of this document however if you keep it
for later use that is still all right.

So, overall what we can say is that in this document in this black box testing report what you
should include primarily are the functions or the modules that you have tested detailed
description of their input domains and output values that each function or module takes then
based on those input and output information what are your equivalence classes optionally you
may include some rational behind going for those equivalence classes.

Although that was not clearly mentioned here but ideally if you can keep such an information
that it will help others to understand your logic then details of those classes including
representing them with set notations for clarity. Corresponding test cases with input and output
pairs result of observation after executing the program or the function or the unit whatever you
are terming it with the input and output pairs for each test case.

Then comparing the output that is observed with the expected output that you have already
identified and then finally concluding whether there are any mismatches that you have noticed
the same thing you have to do for boundary value analysis also. So, for each of the equivalence
classes that you have identified you have to identify the boundary cases and correspondingly up
to design test cases and for those test cases also you have to identify the expected output execute
the program to get the actual output.

The actual output has to be compared with the x with the expected output and see whether there
are mismatches. If miss matches occur you have to note it down for later actions you have to do
it for each and every function. So, these are the key things that you should include in the test
report including set notations for all the equivalence classes. Detailed explanation of the input
output is mandatory set notations for equivalence classes is mandatory.

Justification for choice of equivalence classes although optional ideally should be part of the
document for understanding by others. And conclusion about the test observations if there are
any issues found and optionally you may also include like shown here how those issues were
resolved at the code level at the end you may add some references like those shown here. So, this
section says that to prepare this document the developers have gone through these references.

So, nine references were mentioned of course you have to follow some standard although here it
was not done following proper standard conventions but that is what is also required.
(Video Ends: 42:55)

So, with that we have come to the end of this case study where we have seen how to prepare a
report on your black box testing. The key components of the reports are highlighted some
additional things you may keep including justification for equivalence classes some things are
optional like details on how the issues are resolved although if you keep it there is no harm in it.
I hope you have understood the document the lecture content.

And you will be able to prepare your own black box testing report without any problem with that
I would like to end this lecture here hope to meet you all soon in the next lecture thank you and
goodbye.
 Design and Implementation of Human-Computer Interfaces
Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology – Guwahati

Lecture – 34
White–Box Testing

Hello and welcome to the NPTEL MOOCS course on design and implementation of
human-computer interfaces, lecture number 29. At this stage, let us take a pause and reflect
on what we have learned and what remains. As we have repeatedly mentioned in all the
lectures almost we are learning on the development of interactive systems. Human-computer
interfaces are nothing but interactive systems and we are learning a stage wise process to
develop such systems.

At this stage, it may be useful to just recollect why we are going for this stage wise
development. We are going for the development because for interactive systems an important
consideration is usability of the system that means whether the users perceive it to be usable.
Now, that requires us to first properly collect and analyse the user requirements, specifically
requirements from the end users, not the clients of the product because these two need not be
the same.

Once the user requirements are gathered, it is also important to convert these requirements to
a proper design of the system and equally important are to test the system to know whether
the system meets the usability requirements. So, we need to ensure that the system is usable
as well as we need to ensure that the system is executionable, that means the system is
executable. So, there are two requirements usability and executability.

Executability of course is required for every software product, but usability is required
primarily for interactive systems or human-computer interfaces. In order to ensure that the
system is usable, we make use of several methods. Also, in order to ensure that the product is
executable we make use of several methods. Now, together these methods can be considered
to represent a stage wise process of development of the interactive system.

In other words, what we are talking of is an interactive system development lifecycle. There
are slight differences between interactive system development lifecycle and regular software
development lifecycle because in interactive system development lifecycle we specifically
take care of usability. One such interactive system development lifecycle we are currently
discussing which comprises of several stages. What are those stages? Let us have a quick
look.
(Refer Slide Time: 04:04)

One is the feasibility study stage, which we have not covered in details in this course because
that is not very relevant, although important but we have not covered it. Next is the
requirement gathering analysis and specification stage. In typical software development
lifecycle this stage is present, in interactive system development lifecycle this stage adds to
what is already there in typical software development lifecycle in terms of gathering
requirements for usability.

So, we need to gather requirements for software system as well as gather requirements from a
usability point of view. Then there is this design prototype and evaluation cycle. Now, this
cycle is required to take care of primarily usability concerns. So, objective is to design usable
interfaces and interaction for interactive systems or human-computer interfaces. In order to
do that, we need to first come up with a design based on the requirements that we have
gathered in the earlier stage.

Then that design needs to be prototyped and evaluated, where evaluation takes place with
experts. If some usability issues are found in the evaluation, then we refine our design and the
cycle continues till we arrive at a stable interface design. Once a stable design is arrived at,
we go for converting this design to a system design or design of the code that is the second
type of design that we are bothered about in this interactive system development lifecycle.

In code design, we primarily try to create a hierarchy of modules and submodules and then
we define the relationships between them and the interfacing between those modules and
submodules. Once system is designed, we go for implementing it with the coding and
implementation stage that is the next stage. The implemented system is tested, then the whole
system is tested again but not for testing the code rather testing the usability of the whole
system.

Note the cycle here, at this stage if you find some usability issues then it may be required to
go back to the design phase and the subsequent stages may need to be executed again.
However, this cycle should not be frequent, should be maximum once or twice, otherwise the
whole turnaround time maybe impractical. Once the system is found to be executable after
code testing and usable after empirical study, we go for deployment and maintenance.

Now, these are the stages of an interactive system development lifecycle for systematic
development of the human-computer interfaces. Among these stages, we have already
covered requirement gathering analysis and specification stage. So we have learned how to
gather requirement, broadly two types of requirements, functional and non-functional. We
have learned how to gather functional requirements, we have learned how to gather
non-functional requirements.

In this context, those non-functional requirements or usability requirements with techniques

such as contextual inquiry and we have also learned how to convert non-functional
requirements to functional requirements. Then we have discussed the design, prototype and
evaluate stages. In the interface design stage, we have learned to use design guidelines. Then
we talked about specific guidelines like Shneiderman's eight golden rule and Norman's seven
principles.

We have also learned how to create prototypes. What are the different prototypes that are
possible and we have learned how to evaluate quickly those prototypes with experts through
methods such as cognitive walkthrough and heuristic evaluation. Next, we learned about
system design where we learned about the modular design idea as well as languages to
express designs such as DFD or data flow diagram to express functional design or procedural
design and UML or Unified Modelling Language to express object oriented design.

We learned about the coding and implementation stage, particularly talked about how to write
good code, what are the good practices in coding. So, once coding is done, we need to test it
for finding out errors with the code and rectify those errors. For that, we need code testing,
currently we are discussing code testing. And in this lecture, we are going to discuss the
remaining part of the code testing at the unit level that is white-box testing.
(Refer Slide Time: 09:54)

So in testing, if you can recollect we have broadly two ways of testing, one is the review
based and the other one is the execution based. We have covered in details the review-based
code testing. What we do in review-based code testing, here instead of executing the code
with a computer, we manually go through the code, we just inspect the code, hand execute the
code to find out faults with the code.

The purpose is to get a quick evaluation of the code done with a team of evaluators. So, this
is again broadly of two types. One is code walkthrough in which there are some test cases
designed and those test cases that means the input output pair are used to hand execute the
code and see whether the output of execution matches with the expected output, if not, then
there are some errors which are flagged.

In inspection-based code testing, the evaluators go through the code line by line to check for
errors in terms of coding standards conventions, whether those were followed or not, whether
some common mistakes have been made like uninitialized variables or type mismatch and so
on and so forth. So, you also saw how to create a document when we go for review-based
code testing. The other code testing type is execution based.

In execution-based code testing, we actually execute the code with a computer with the help
of a set of test cases or a test suit. And then see the output produced by the code after
execution and output that should happen after execution that is expected output and observed,
we see both are matching, if not then there are some issues. We note down the corresponding
input cases and rectify the errors.
(Refer Slide Time: 12:45)

Now, execution-based testing which is also a more formal and rigorous way of code testing
can be done in two ways. One is functional testing. In this testing method, test cases are
designed using only functional specification of the code without any knowledge of the
internal structure how the function is written. This is also called black-box testing. We have
gone through the details of the black-box testing in the previous few lectures. So, this testing
method is already covered in details.
(Refer Slide Time: 13:19)
There is another execution-based testing that is structural testing. In this case, test cases are
designed using knowledge of the internal structure of the code. So, here we know the
instructions that are part of a piece of code and based on that knowledge we try to design the
test cases. This is also called white-box testing and we are going to talk about white-box
testing in this and subsequent few lectures.

So, white-box testing is the focus of this lecture. Also at this stage, it may be useful to
recollect that after every stage of the development lifecycle, we produce a document. Now
that document can be the code itself or some reports. After requirement gathering analysis
and specification stage, we produce a document that is called SRS or Software Requirements
Specification. After design phase, we produce a design document.

After prototyping phase, we may produce details of the prototype. After evaluation of
prototype phase we may produce the evaluation report. After code design phase, we may
produce detailed code design document expressed in either DFD or UML. After coding
phase, the code itself is the document along with that there may be some technical manual
and user manual to understand the code.

After testing phase, we generate testing reports for the code. After review-based testing, we
can produce one document, we have already seen how to create those documents, what
should be the content of that document. Similarly, after black-box testing, we have seen case
studies where such documents are discussed to give you some idea of the content of such
documents.
Similarly, after learning about white-box testing we will see how to generate a white-box
testing report, what should be the content in subsequent lectures. But first, we will learn the
basics of white-box testing.
(Refer Slide Time: 15:52)

So, let us begin our topic for this lecture on white-box testing. As we have already
mentioned, white box testing is meant to test internal structure of the code. So, in black-box
testing, we tested each function assuming it to be a black box, we do not know what is inside
the function, so there is no test of the internal structure. In white-box testing, we do the
opposite.

We basically first learn about the internal structure of the code that is the set of instructions
that are written as part of the code and then based on that we design test cases to test the
structure. Obviously, if we want to do that, then we need to know the internal structure of the
code, how the code is written that was not required in case of black-box testing. Since we
have to know the internal structure, it may sometime appear to be harder than black-box
testing.

Because here the internal structure can be complex and accordingly design of test cases may
be complex like in black-box testing where we need to only bother about the input domain
and output domain rather than how the code is written. So, that is possible that the white-box
testing turns out to be harder to do than black-box testing for complex pieces of codes. In
order to make our job easier, in order to make the design of test cases easier, we need some
method.

A complex code is very difficult to understand we all know. Now, if we want to design test
cases based on the knowledge of a complex code, then somehow we have to make sure that
the code is understandable easily so that we can go ahead with design of the test cases. Now,
how to make a code understandable easily?
(Refer Slide Time: 18:06)

One way to do that is to visualize the code. In other words, if we can visualize the flow of the
program, then that makes it relatively easier to design the test cases. So, the key thing here is
to be able to visualize the program and the program flow in a code. So, there is one approach
through which we can perform this visualization that is known as Control Flow Graph.

So, this is a graph like structure which can be used to express program or rather the flow of a
program to help us visualize the flow. So, in order to be able to understand white-box testing
approach, it is helpful to know about the control flow graph and how to use it to design test
cases.
(Refer Slide Time: 19:16)
So, let us quickly learn about control flow graph or CFGs. So, as the name suggests this is a
graph which represents control flow in a program. So, it is a graphical representation of
sequence of instruction execution. So how the instructions get executed, in which sequence is
represented graphically with the control flow graph. In other words, it represents how the
control of the program flows through the program. So, both are same. To visualize the
sequence of instruction executions and to visualize the control flow are the same concepts
and control flow graph helps us to do just that visualize the flow of control in a program.
(Refer Slide Time: 20:10)

So, the definition is simple. A control flow graph is a visual representation of the flow of
control in a program. Now, since it is a graph, so it consists of nodes and edges, so there will
be some nodes and there will be edges and since it shows some direction, so edges will be
directed. So, in other words it is a directed graph. Now, what should we consider to be a node
and what should we consider to be an edge?

How to create edges between nodes these are some of the issues that we should understand
before we are able to construct a control flow graph. So, then first what can be the nodes in a
control program or CFG? What we can do is we can assign numbers in sequence to all the
statements of a program. So, program consists of instructions or statements, each statement
can be assigned a number, a unique number of course.

Then, we can create a node in the CFG for each numbered statement. So, if we have a
program say statement 1, statement 2, statement 3 and so on, so we can assign numbers 1, 2,
3, etc., and then can create a node like this a circle with this number 1, circle with this
number 2, circle with the number 3. So, each will be a node representing a statement. So,
these represent the statement, this one will present statement 1, this one will represent
statement 2 and so on.

So, number each statement in the program, for each numbered statement create a node. In the
node, a node is nothing but a circle with a number inside it where the number corresponds to
the corresponding statement in the program.
(Refer Slide Time: 22:32)

Then, what we can do is so once the nodes are created like 1, 2 3 etc, we can add an edge
from one node to another node if execution of the statement representing the first node results
in a transfer of control to the other node. In other words, suppose after statement 1 which is
numbered as 1, statement 3 happens numbered as 3, in between there is another statement,
statement 2 numbered as 2.

Now, if I create these three nodes 1, 2 and 3 in my program, after 1, 2 does not happen, 3
happens so then I should not add a node between 1 and 2. These nodes should not be there,
instead there should be a node between 1 and 3. So, whichever statement gets executed after
the previous statement an edge should be added between those two corresponding nodes that
is the basic idea.

So, we first number each statement, create a node for that number or the number statement, a
node means a circle with a number inscribed inside which represents the statement and then
add an edge between nodes when execution of the first node results in transfer of control to
the second node that is the program, then executes the second node after the first note is
executed. So, this is a simple idea for constructing a CFG that is create node and add edges as
per the flow of control.
(Refer Slide Time: 24:52)

Let us see few examples about different types of control flow in a program and the
corresponding construction of CFGs. The most simple form of control flow is of course as we
all know sequential control flow. So, the statements are listed in sequence and they are
executed also in sequence. Suppose, this is a code segment consisting of two statements, an
assignment statement equal to 5 and some computers and statement B = to A + 10.
Now, if these statements are executed in sequence that means after 1, 2 happens, so what
should be the CFG for these two statements? For 1 we have a node a circle with 1 one
inscribed inside, for 2 again we can have a node that is another circle with 2 inscribed inside
and since they are sequential 2 gets executed after 1 is executed. So, we simply add directed
edge from 1 to 2. So, this indicates that 2 gets executed after 1.
(Refer Slide Time: 26:18)

Now, let us move to a slightly complex code segment that is conditional execution. So, now
suppose there are these 4 statements. First statement is an if statement that is if followed by
some condition A greater than 10. Second statement is what happens if this condition is
satisfied that is C is assigned to 1. Three says else C is assigned to 0. Four says C = C into 10.
Here one point is that sometimes we tend to write else C = 0 in two lines that is instead of
writing it in a single line you can write else C = 0.

So, then one confusion may come with that this should be 3 and this should be 4, then
whether it should be the last one should be 5 or both should be considered as a single
statement like we have done here as 3. Since, only else has no significance, so it is preferable
that we consider them together as we have done here, although even if we considered them
separately then also there is no effect on the CFG.

Only thing is it gets more nodes and the resulting CFG becomes complex to manage. So,
considering them in single line is perfectly alright rather than considering them as two
separate nodes. So, that is the thing that often may create some confusion, so you should keep
this in mind.
(Refer Slide Time: 28:08)

Now, let us see assuming else C = 0 represents a single node in the CFG let us see these 4
statements and how they can be converted to a CFG for visualization. So, for statement
number 1 we have this node with 1 inscribed inside. For statement number 2 we have this
node with 2 inscribed inside. For statement number 3 we have another node where 3 is
inscribed inside and finally we have statement number 4, so there will be another node, but
before that let us see how the control flows.

So, depending on the condition it can go to either 2 that is if this turns out to be to be true,
then it can go to 2, otherwise it can go to 3 and for the fourth statement there is another node
with 4 inscribed. Now from both 2 and 3, 4 can be reached. So, if this condition is true, if this
is true then the path followed is 1, 2 and 4. If this is false, in that case the path followed is 1,
3 and 4. So, depending on the condition, a specific path is followed.

So, when conditional statements are there then we can have this type of CMGs. Now, let us
have a quick look at what would have happened if we would have considered this statement 3
not as a single statement but as two statements. Three says else, then 4 says C = 0 and 5 says
C = C into 10. So, in this case the last statement becomes 5 instead of 4. So, then we will
have 1 as before 2, 3, 4 and 5.

Now, if condition is true then we will go to 2, if condition is false then we will go to 3. Now,
since this is simply an else statement, then 3 and 4 are sequential, so 3 will be followed by 4
and then we will come to 5. So, there will be slight modification with the addition of one
node and one edge. So, earlier there were 4 nodes if we would have considered 3 as a single
statement. Now, there are 5 nodes.

Similarly, earlier there were 4 edges, but now, if we consider 3 to be not a single statement
but two statements then there will be 5 edges. Now, if we extrapolate it to the whole program,
then the edges and nodes will increase manifold and the resultant CFG may become more
complex to visualize. So, it is preferable to go for single statement when else type of
statements are there. So, that is about conditional statements and how to construct the CFG
out of those statements.
(Refer Slide Time: 31:45)

Next, let us think about another important construct in a program that is loop or iteration. Let
us consider this segment while followed by a condition then some statement B = + 1 followed
by another statement. These three statements are numbered as 1, 2 and 3. So, then how the
CFG will look like? For statement 1, we will construct one node as shown here. For 2 we will
construct another node.

Now, there will be a connection from 1 to 2 which we can generally expect when the
condition is satisfied. So, there will be one directed edge from 1 to 2, but then it is a loop or
an iteration. So, this condition will be checked repeatedly that means this instruction or node
1 will be visited repeatedly from 2 so after node 2 gets executed, so then we will add a loop
edge from 2 to 1. For statement 3, there will be another node and from 1 we can go to 3.
Note that here from 2 there is no edge, only from 1 when the loop condition becomes false
we can come to 3. So, this is typically how we can construct a CFG for a loop. So, you have
seen three important constructs and the corresponding CFGs namely for sequential
statements, for conditional statements and for iterative statements. So, with that basic
knowledge now let us move forward and see how the internal structure of a code can help us
construct test cases when we visualize the code using CMGs.
(Refer Slide Time: 34:00)

So, when we go for test case design for white-box testing, our core concern is coverage of the
code as much of the code as possible that means as many instructions in the code as possible.
For that of course, we need to know how many instructions are there, how the control flows
from one instruction to another that is the internal structure. So, the concern is test cases
should cover as much code as possible where the coverage means extent of code accessed
during execution.

So, when we provide a test case, a set of statements in the code gets executed. So, our
objective should be to come up with test cases that forces the system to execute as many
statements as possible.
(Refer Slide Time: 34:50)
Keeping this objective in mind, we can approach the test case design problem in several
ways. There are many approaches. We can have an approach called statement coverage
approach. We can have branch coverage approach. We can have condition coverage
approach. We can have path coverage approach. We can have control flow testing approach,
data flow testing approach and so on.

Statement coverage, branch coverage, condition coverage, path coverage, control flow
testing, data flow testing these are all methods to achieve the same goal that is to come up
with test cases that help us execute as many statements as possible to unearth errors in the
code. Among them, we will be focusing on the first four that is statement coverage, branch
coverage, condition coverage and path coverage.
(Refer Slide Time: 36:04)
So, let us start with the idea of statement coverage what it means. So, when we are trying to
design test cases using the statement coverage approach, our aim is to design cases such that
every statement is executed at least once. So, when we are aiming for statement coverage
objective is to have test cases that forces the system to execute every statement at least once.
The idea is simple, unless a statement is executed, it is hard to determine the existence of
error in that statement.

So, this is the most intuitive way of looking at testing a code. One note of caution though,
executing a statement once and observing correct behaviour for some input does not
guarantee correct behaviour for all input values. So, this is one very crucial thing to note that
we may have come up with test cases which generates correct behaviour for all statements,
but that does not mean that for all input this assumption will hold.

Remember that here we are not talking about first creating equivalence classes and then
designing test cases which can be representative of all inputs in that class to manage the
number of inputs. So, here we have to look at the problem in a different way.
(Refer Slide Time: 37:47)

Now, then with that basic aim, let us see a code segment and how we can design test cases by
constructing a CFG from the code segment and then going forward to design the test cases.
So, suppose this is the code segment, a function having six statements. Now to construct a
CFG from these 6 statements, we need to take into account the nature of the statements. So, it
is a while loop having an if else construct.
So, both, iterative sequential, so all the 3 constructs are there iterative, sequential as well as
conditional. So, let us see how the CFG looks like. So, for each statement we have this node.
So, there are 6 statements, so 6 nodes; 3, 4, 5 and 6. Now, since statement 1 represents and
iterative statements, so there is a loop construct from 5 here to here because here the loop
starts and here it ends.

Now, you may think that having simple bracket not necessarily requires you to create a node,
but that thing we have done here to let the discussion happen in a simple manner, otherwise
we could have equally ignored the statement and the corresponding node but then showing or
visualizing the code would have been a bit difficult. So, to avoid that to keep the matter
simple, we just included this node here.

So, there is this loop construct from 5 to 1. Now, once this condition is true, as long as this
condition is true from 1 the control comes to 2, now 2 is a conditional construct, so there are
two parts. From 2 if it is true then it can go to 3, if it is false then it can go to 4. And then if it
is false, then it comes back to the first statement and if it is false then it goes to the sixth
statement from 1 and come back to 6.

So, this is the construct, I hope the construct is understandable to all of you the CFG how it is
constructed with this knowledge now, suppose we want to execute each and every statement,
then what kind of test cases we should design? So, if we have inputs like x = 3 and y = 3,
then which statement it executes? So, while fails, so statement 6 gets executed. If x = 3, y = 2
then it enters the loop.

Now x greater than y, so this gets executed, this gets executed and this gets executed but not
this one for this second input and then 6 six gets executed. Now, when x = 3, y = 4 then this
gets executed, this gets executed, this one gets executed, this does not get executed and this
one gets executed for this third pair of input. So, you can see that we can execute all the
statements if we provide these three.

In fact, since 6 gets executed anyway for the second and third input, so first one we can
simply ignore. So, we can have only these two.
(Refer Slide Time: 42:06)
Now, let us move to the next approach that is branch coverage. Here the idea is that the test
cases are designed to cover each branch condition, both true and false values. Now, this
approach is also known as edge testing. So, what happens here? It guarantees statement
coverage, stronger strategy compared to statement coverage. So, in statement coverage, we
have to look for inputs which executes each and every statement.

In branch coverage if we look for inputs which only covers the branch conditions for both
true and false situations, then it ensures the statement coverage as well. So, our effort in
finding out test cases are less in that sense it is stronger, a stronger approach than statement
coverage.
(Refer Slide Time: 43:06)
So, let us consider the same example. So, we have this CFG and if we are only focusing on
the branch coverage, so this branching can happen here or here. So, true and false conditions
both we have to check. So accordingly we can decide on these three. Note that the input pairs
are the same and they anyway perform the statement coverage. So, these three inputs are
designed to take care of true and false conditions in both branching points here and here.

So, here we are only focusing on identifying test cases that result in true or false conditions in
the branching statements, we are not bothered about whether that other statements get
executed or not. So, we are restricting our search space into finding out branching conditions
only, so our effort becomes less but at the same time it ensures that other statements get
executed.
(Refer Slide Time: 44:13)

Third is condition coverage. So here what happens is the test cases are designed to make each
component of a composite conditional expression as you both true and false values. So here
the focus is specifically on conditional expressions. For example, if this is a composite
conditional expression, c 1 and c 2 or c 3, then test cases should make c 1, c 2 and c 3 each
assume true and false values.

So, we are focusing only on the conditional statements and true and false values for each
component of the conditional statements. Earlier in the branch coverage or edge coverage, we
are considering true and false value for the entire statement, now here for each component we
are considering true and false value. So, it is even more complex than the branch condition.
So, if there are n components, 2 to the power n test cases for each composite condition has to
be designed.
(Refer Slide Time: 45:27)

So, branch testing is one form of condition coverage approach, simplest condition coverage
strategy, true false values are considered for whole condition rather than individual
components. But, in general we have to focus on individual components rather than the whole
condition. So, if we are doing that then that guarantees branch as well as statement coverage.
So, this approach condition coverage is even stronger than the branch strategy or the
statement coverage strategy.

We may note here that this approach may be impractical if conditions are complex that means
the number of test cases need to be designed can increase to a very large number, which may
become unmanageable.
(Refer Slide Time: 46:22)
And finally, we have the idea of path coverage. What it says? It says that test cases should
ensure all linearly independent paths in the code are executed at least once. So, it introduces a
new concept linearly independent path, what is a linearly independent path in a CFG or
control flow graph? First what is a path? As the name suggests in a graph path means a series
of nodes and edges.

So, a node and edge sequence from starting node to a terminal node of a CFG of a program,
of course CFG is corresponding to a program only, that is called a path. We can define more
than one terminal nodes in a CFG, so accordingly we can have several paths.
(Refer Slide Time: 47:16)

Now, once we know what is a path, let us try to understand what is a linearly independent
path. Any path with at least one new edge or node not included in any other linearly
independent paths of the CFG is defined as a linearly independent path. So, if we define a
path which is not a sub path of any other path, then that path can be a linearly independent
path.
(Refer Slide Time: 47:52)

So, in this example for this code segment that we are discussing, we have this CFG
comprising of 6 nodes and how many edges are there? 1, 2, 3, 4, 5, 6, 7 edges. So there are 6
nodes, 7 edges to represent this code segment. In this CFG let us try to identify the linearly
independent paths. So, first let us try to identify the paths, what are the paths? One path can
be the sequence the node number 1, 2, 3, 5, 1, 6 this can be one path.

Let me just clear it. Then there can be another path 1, 2, 4, 5 then 1, then 6 can be another
path. Simply 1 to 6 can also be another path from starting node to a terminal node. So, these
are the paths and what are the linearly independent paths, how do I identify those?
(Refer Slide Time: 49:36)
There is a concept called cyclomatic complexity. It actually is a measure of upper bound of
number of linearly independent paths for CFG.
(Refer Slide Time: 49:55)

So, what it tells us is a way to identify linearly independent paths. So, let us see how we can
compute this cyclomatic complexity. One way to compute is with this expression E – N + 2
where E represents number of edges, N represents number of nodes. Another way is with this
explicit D + 2 where D represents number of decision statements. So, there are two ways to
compute cyclomatic complexity. One is the expression E – N + 2 that is in terms of edge and
node, number of edges and number of nodes. Other one is D + 1 where D represents number
of decision statements, so in terms of decision statements that are part of the code.
(Refer Slide Time: 50:42)
Given that definition of cyclomatic complexity, let us try to understand how many linearly
independent paths can be there. If we follow the first method, we can have the complexity
value to be 3 because edge number is 7, node number is 6, so E – N + 2 gives us 7 – 6 + 1 or
the value 3. If we follow the second method, then the decision statements or decision nodes
are 2, this node 1 and node 2, D = 2. Then the complexity is D + 1 or 3.

So both the methods lead to the same value that is 3. So, in this particular CFG we can have 3
linearly independent paths and those 3 paths we have already mentioned earlier. So, let us
summarize what we have learned. So, in this lecture we covered the basic concepts of
white-box testing where we mentioned that we need to understand the structure. Now, to
understand the structure visualizes and helps, so there is a way to visualize the code that is
called CFG or control flow graph.

We have seen different constructs like sequential construct, iterative construct and conditional
construct and how to construct a CFG out of these constructs. And we have seen how to
design test cases for white-box testing with a CFG in hand. So, essentially different
approaches can be applied. We have learned about four approaches; statement coverage
which is the most intuitive idea of designing of test cases.

Then branch coverage which is stronger than statement coverage in the sense that if we
follow branch coverage, then anyway statement coverage will be done. Then there is
condition coverage, which is even stronger than statement coverage, but sometimes it may
become impractical to follow it. And finally, we learned about path coverage which is very
strong and it can cover the other approaches.

For path coverage, we need to identify linearly independent paths and design test cases to
execute statements that are part of these paths. So, first task is to identify linearly independent
paths. In order to do that, we need to first know how many such paths are there and then as
per definition we need to identify those. To know how many sides paths are there in our CFG
we can make use of the concept of cyclomatic complexity.

We have seen how to compute those and using that computation we can know the number
and accordingly we can identify the paths. All these concepts we have learned with examples
to make things easier for you.
(Refer Slide Time: 54:01)

Whatever I am discussing or we have discussed so far can be found in these books

Fundamentals of Software Engineering chapter 10 or Software Engineering: A Practitioner’s
Approach chapters 19 to 21. I hope you understood the concepts and enjoyed it. Next lecture
we will go through one case study of a white-box testing report as a document as the outcome
of the stage like we did before. Looking forward to meet evolve in the next lecture. Thank
you and goodbye.
 Design and Implementation of Human-Computer Interfaces
Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology – Guwahati

Lecture – 35
White–Box Testing Case Study

Hello and welcome to NPTEL MOOCS course on design and implementation of

human-computer interfaces. We will continue our previous lecture that is lecture number 29.
So, this is a continuation of lecture number 29. In the previous lecture, what we have learned
is about white-box testing. So, if you may recall it so this is one of the several code testing
methods. Broadly, there are two categories of testing, review based and execution based.

We have seen the review-based testing earlier. We have gone through one case study for
review-based code testing. We have also seen that there are two types of execution-based
code testing, one is black-box testing and the other one is white-box testing. Earlier we have
gone through in details about black-box testing and also we have gone through a case study
on black-box testing.

In the previous lecture, that is lecture number 29, we have learned about white-box testing in
details including the different ways to perform white-box testing. In this lecture, we are going
to continue that discussion and we are going to go through a case study to better understand
white-box testing approaches.
(Refer Slide Time: 02:01)
Like in the previous case study discussions, here also we will show you the documentation
for white-box testing, how to create the document, how it looks like and also what should be
there inside the document. So, like before we will have a cover page which will mention the
purpose of that document like here it is mentioned that it is a testing document for business
management software.

Also, there is this version information, version 1.1, date of creation of this document like
before we have seen, the creators, the place of creation and some additional information like
who was the supervisor, who supervise the document creation that is the cover page like we
have seen in the earlier case studies.
(Refer Slide Time: 03:02)

In the next page as usual, we will have the table of contents. In this particular testing
document, the document contains some revision history, then an introductory section which
includes purpose, conventions scope, all this information that we have seen already in the
earlier documents. Then one section on mapping between DFD and function. So, this testing
document actually makes it easier for the reader to understand the functions that have been
used in this system.

And how those functions were obtained from the system design document that is the DFT. So
according to this document, this whole system contains 5 modules module 1, 2, 3, 4, 5 and
each module contains several functions so that mapping is shown in this section, mapping
between DFD and functions. Then it has one section on choosing three important functions.
So, this section of course is optional.
And this is only used to demonstrate the idea because showing all the details of all the
functions and test report for all the functions would have lengthened the document without
adding any extra pedagogical value. So here instead, what we have chosen to do is basically
focus on three important functions and so how those three functions were used to perform
white-box testing and also black-box testing in this test report.

So next section contains a report on black-box testing for those three functions and the
subsequent section contains a report on white-box testing for those three functions. Earlier of
course we have seen black-box testing, so we will not spend much time on this black-box
testing report part and we will focus on the white-box testing report. The document ends with
a conclusion section followed by a set of references.
(Refer Slide Time: 05:10)

The next page contains some revision history as before. So, it records the historical evolution
of the document, first person when it was created, then when it was revised and second
person was created and so on. In this particular case, there were only two versions, so those
two were recorded here. But in a typical situation, there may be many more such versions, so
this history will contain all details about all those versions.
(Refer Slide Time: 05:41)
Now, that is followed by the introduction section. Since we have already seen in the earlier
documents how the introduction section should be created, so we will skip the details here,
only we will mention what are the subsections namely purpose, purpose of this document,
then conventions that are used in the document, scope of the project all these details should
be mentioned here in this introduction section as we have seen in the earlier case study
reports.
(Refer Slide Time: 06:13)

To better understand the system, let us first quickly have a look at the second section that is
mapping between DFD and functions. It will give us some idea of what this system is all
about and what are the functions that are part of the system. In other words, it will give us
some idea on the overall complexity of the system. So, as we have seen in the table of
contents part there are 5 modules for this system.
Module 1 contains 3 submodules as shown here. Module 1.1 is a function create new account.
Module 1.2 is another function login user account and module 1.3 has sub submodules 1.3.1,
1.3.2, 1.3.3. Now 1.3.1 is a function change password, 3.2 is another function forgot
password and 3.3 is a third function set new password. As you can see, each module and
submodule is mapped to a function. So, that is about module 1 primarily related to login and
setting, resetting of passwords.

Then module 2 contains 5 submodules. Module 2.1 is the view stock data, module 2.2 is
search stock items, module 2.3 contains 3 sub modules; 2.3.1 add new item, 2.3.2 update item
and 2.3.3 void delete item. Module 2.4 is purchase list and module 2.5 is update purchase list.
As you can see from this module, this overall system is related to management of a business
that means whatever items are bought, sold, entered into stock.

All these things can be done with the software essentially this is a kind of ERP software
which allows someone to run business smoothly. So, the first module is related to logging
into the software, second module is related to the details about the stock items. Module 3
contains 4 submodules, 3.1 is add sold items, 3.2 is view sales record, module 3.3 is add
purchased item, 3.4 is view purchase record.
(Refer Slide Time: 08:49)

Then Module 4 contains 5 submodules, 4.1 is add record, 4.2 is update record, 4.3 is delete
record, 4.4 is search record and 4.5 is show debt record. And finally module 5 contains 4
submodules; 5.1 is create new employee, 5.2 is delete employee, 5.3 is mark employee
attendance, 5.4 view attendance record. So essentially, this software allows us to log in, to
maintain details about the employee including their attendance.

To keep track of the items that are sold, that are purchased, in short everything that a business
requires to keep track of. So, these are the modules and each module contains several
submodules. Some of the submodules contain further submodules as we have seen and each
of these submodule or sub submodule or a module is mapped to a function as listed in this
section. Now, you can see that there are a large number of such functions.

The purpose of this lecture is just to demonstrate how to create a test report. So, there to keep
things simple what we have done is we have chosen three of the important functions and for
those three functions, we have created the testing report. So, what are those three functions?
Login user account, search stock item and add sold item detail. Also, there is some
justification given for why these three functions are considered to be important and
emphasized for creating the report but that is irrelevant for our purpose.

So, these three functions as you can see are highlighted here. In module 1 we have this login
user account function. In module 2 we have search stock item function and in module 3 we
have this adds sold item detail function. So, login user account is basically a function which
we get when we map module 1.2. Search stock item is a function which we get when we map
module 2.2. And module 3.1 is mapped to add sold item details.

And also in this function as you can see the function login user account does not return
anything and it takes as input user email id and password. Search stock item take as input
item name and returns the stock details or the records for that particular item. Add sold item
detail function takes as input item name and the quantity and returns nothing. So, these are
the three functions that we have chosen for further elaboration of the case study.
(Refer Slide Time: 12:02)
So, there is black box testing report which is part of this testing report document. Of course,
we have seen a case study on black box testing earlier, so we will not spend time on this
black box testing here, only just to recollect in black box testing what we require is
identification of equivalence classes which have been done here. And then based on the
equivalence classes, so test suit needs to be created.

So for each of the functions, equivalence classes were identified like for login user account
function these are the equivalence classes, correct password, incorrect password, unregistered
email, invalid email.
(Refer Slide Time: 12:42)

And correspondingly some test cases were created to form the test suit.
(Refer Slide Time: 12:48)
In this particular function case, no boundary cases have been considered.
(Refer Slide Time: 12:55)

However, four search stock item function equivalence classes were mentioned, valid product
names and invalid product names as well as boundary value analysis was done.
(Refer Slide Time: 13:06)
And same is true for the third function that is add sold item detail. However, we will not
spend time on this as we have already covered it in detail in earlier lectures.
(Refer Slide Time: 13:21)

So, we will directly go to the next section that is white box testing that is section number 5 in
the test document. So, in white box testing, what we are supposed to do? We are supposed to
first go through the structure of the code, so it is a structural analysis. So, we need to know
the internal structure, then that structure has to be converted to a CFG for analysis of the code
and identification of test cases.

So, let us first see the code for the first function that is login user account function. This is the
function, as you can see each line of code is marked with some number like first declaration
statement like 1 is a line of code, 2 is another line of code, then you have 3 another line of
code. So, the comment parts are not given any line number as you can see here. Also the
insignificant parts were not given line number such as the private void login user account, the
function name is not given any line number.

The opening this is not given any line number. So only the significant parts of the code are
generally assigned line numbers for further analysis. So, you should not give line numbers to
function name, base, comments these types of things. So line number 1 is one line of code, 2
is another line of code, then 3 is if statement, 4 is the body inside the if statement, 5 is a
return statement. Note here again that this base, the closing base for the if statement is not
given any line number.
(Refer Slide Time: 15:12)

The 6 is another if statement, 7 is the body inside the if statement, 8 is return statement, then
9 another piece of code, 10 is if statement, 11 is the body inside if statement, 12 is another
statement inside the body, 13 is again another statement inside the body.
(Refer Slide Time: 15:37)
The 14 is another statement inside the body of if, then 15 is one more statement and the last
brace is given a statement line number 16. So, here the rule is of course not followed that
should not assign any line number to the braces because this is the end of the code. So, one
exception is made here to keep things clear.
(Refer Slide Time: 16:05)

Now, from this code, we have to create a CFG or control flow graph for visualization of the
flow of the code and then based on that visualization, we have to identify linearly
independent paths for path coverage testing. So, there are 16 lines of codes in the function.
So, correspondingly we can make a CFG following the convention as you can see here. So,
this is the control flow graph for the function that we have just seen.
So, this graph contains several node, 1 followed by 2, followed by 3. Since 3 is an if
statement, so from 3 there are other paths, one goes to 4, one goes to 4 followed by 5 and
then comes out at 16 that is the end of the code. Now at 6, there is another if statement, so
two more paths 9 followed by 10 or 7, 8 followed by 16. At 10, there is one more if statement
so again two more paths followed by 11, 12, 13, 14 or it can go to 15 and eventually they can
come to 16 that is the end of the code.

Now, in order to understand how many test cases we require, we need to perform cyclomatic
complexity analysis for this code. If you may recollect, so it shows how many linearly
independent paths are there. So, the cyclomatic complexity is basically E – V + 2 where E is
the number of edges, V is the number of nodes or vertices. In this CFG we have E as 18, V as
16, you can count it from this CFG the number of edges and number of vertices. Then C is E
– V + 2 or 4.

Now, 4 indicates that there are 4 linearly independent paths. So, what are those paths? 1, 2, 3,
4, 5 followed by 16 of course, then 1, 2, 3, 6, 7, 8 and 16, at the end it should come 16. Then
1, 2, 3, 6, 9, 10, 11, 12, 13, 14, 16 that is 1, 2, 3, 6, 9, 10, 11, 12, 13, 14, 16. So, this path as
shown here is another linearly independent path and then 1, 2, 3, 6, 9, 10, 15, 16 so the other
path, So, these are the 4 linearly independent paths that we can have from the CFG.

Corresponding to each path, we have to then design a test case so that each of these paths are
tested and then that will give us a path coverage testing. So, we have to have at least 4 test
cases to cover the 4 paths. Now, the test cases can be like the ones shown here. In the first
two tests, the first path we can have one input as byte string followed by some invalid email
ID. Then to test the second path that is 1, 2, 3, 6, 7, 8 and 16 we can have another test case as
shown here.

To test the third path 1, 2, 3, 6, 9, 10, 11, 12, 13, 14, 16. we can have this third test case as
shown here and to follow the fourth path and perform a testing for the fourth part that is 1, 2,
3, 6, 9, 10, 15, 16 we can have the fourth test case as mentioned here.
(Refer Slide Time: 20:15)
So, in the first case we have input a blank and invalid email id, then expected output is enter
email message, system output is enter email message. So, here note that each of these are
called a test case, not test suit, so there is some typo here, it should be called test case 1, test
case 2, test case 3 and test case 4. Together these 4 test cases will comprise a test suit. And
for each of these test cases, we have so the input, expected output and during testing we got
some output that is the system output.

Now, whenever there is a match, then so the test was successfully performed, whenever there
is a mismatch so there is some problem in the code and we need to refine it. So those points
are marked. Those test cases where the system failed to produce the expected output are
marked. So, in this document you are supposed to provide the input, the expected output as
well as the system generated output as shown in these cases.
(Refer Slide Time: 21:22)
Let us move to the next function that is search stock item function. So, here as you can see
like before, we have provided line numbers to each significant line of code. So, there are 1, 2,
3, 4, 5, 6.
(Refer Slide Time: 21:51)

7, 8, 9, 10, 11, 12, 13. So there are thirteen 13 lines of codes. That means there will be 13
nodes in the CFG. Let us see the CFG how it looks.
(Refer Slide Time: 22:07)
So, as you can see here, there are 13 nodes in the CFG. The 1 followed by, 2 now at 2 there is
an if statement, so there are two paths. One path goes to the node 5, other path goes to the
node 3 that is a third line of code, from 3 it goes to 4 and then comes to the end of the code
that is 13. The other path goes to line number 5, then line number 6, then line number 7, then
line number 8, 8 is another if statement, so two more paths.

One path goes to line number 12 and comes to the end of the program or code and the other
path goes to line number 9, 10, 11 and then comes to the last line of the code that is 13. So,
here number of edges is 14 and number of vertices or nodes is 13. So, the cyclomatic
complexity is E – V + 2 that is 3. So, there are 3 linearly independent paths possible. What
are those paths? One is the path 1 followed by 2 followed by 3 followed by 4 followed by 13
that is 1 followed by 2 followed by 3, 4 and 13.

Then second is 1, 2, 5, 6, 7, 8, 9, 10, 11, 13 that is this path 1, 2, 5, 6, 7, 8, 9, 10, 11, 13. And
the third one is 1, 2, 5, 6, 7, 8, 12. Since there are 3 linearly independent paths that means at
least 3 test cases are required together they will constitute a test suit. So in this case for the
second function for white box testing, we require a test suit comprising at least 3 test cases
each corresponding to one of the linearly independent paths in the CFG.

The three test cases are shown here. So, for first path 1, 2, 3, 4, 13 the test case is blank, enter
stock name message. For second path 1, 2, 5, 6, 7, 8, 9, 10, 11, 13 input is pen, output is stock
data. Third path 1, 2, 5, 6, 7, 8, 12, 13. input is chair, output is no record message.
(Refer Slide Time: 24:49)
Like before, so expected output is mentioned. Expected output is stock data, system output is
stock data in the first case. In the second case, expected output is no record message, system
output is no record message. In the third case, expected output is no record message, system
output is no record message. So, all the details are mentioned.
(Refer Slide Time: 25:15)

Similarly, we come to the third function that is add sold item detail. Like before we assign
line numbers to each piece of code, each line of code that is of significance. So, just to repeat
we do not assign numbers to the function name or the brace or the comments, we assign it to
significant line of codes. And one exception is the last base or closing base of the entire
function maybe assigned a line of code to indicate the end of the program.
(Video Starts: 25:58) So, here we have 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17,
18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32. (Video Ends: 26:22) Total 32
numbered lines in the code that means in the CFG there should be 32 nodes. Let us see the
CFG or the control flow graph. (Video Starts: 26:35) So, it is a pretty big one because there
are large number of nodes and as you can see we start with node 1, 2, 3.

And at 3 we have if statement, so there are 2 paths, one goes to 6, one goes to 4, 4 followed
by 5 and then it comes to the end of the program at 31. Then we have from 3 we can take
another path that is 6. At 6 there is one more if statement, so 2 more paths, one goes to 7, 8
followed by the end of the program, other one is 6 followed by 9 followed by 10, 11, 12. At
12, one more if statement, so two more paths, one goes to 13, other goes to 31 and it comes to
the end at 32.

So, this last statement should be 32, last node marking. Last ode level should be 32 instead of
31, there is a typo. Then from 12, we can also come to 13, 14, 15, 16, 17, 18, 19, 20, 21, 22.
At 22, there is one more if statement, so 2 more paths, one goes to 23 and one comes to the
end node that is 32. So, 23 followed by 24, 25, 26, 27, 28, 29, 30 and 32 that is the other path
which can be taken from node number 22. (Video Ends: 28:10)

So, there are so many branches as you can see in this CFG which indicates that the code is
relatively complex compared to the other codes that we have seen.
(Refer Slide Time: 28:22)
So far this how many linearly independent paths are there. So we will apply the formula, we
have edge 34, vertices 32, so we will have 34 – 32. So here we have edge 34, vertices 32 and
the complexity it should be 4, so there are some typos, in this case we have edge 35, vertices
32 and cyclomatic complexity will be 35 – 32 + 2 that is 5. So 5 means there are 5 linearly
independent paths.

So the 5 possible paths are 1, 2, 3, 4, 5, 32; 1, 2, 3, 6, 7, 8, 32; 1, 2, 3, 6, 9, 10, 11, 12 so on up

to 32; 1, 2, 3, 6, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 32 and the fifth one is 1,
2, 3, 6, 9, 10, 11, 12, 31, 32. Since there are 5 such paths, so we will have at least 5 test cases
comprising our test suite to perform white box testing for this particular function. So, the 5
test cases as shown here.

First test case for the first path that is 1, 2, 3, 4, 5, 32. Then second test case for the second
path 1, 2, 3, 6, 7, 8, 32. Third test case for the third path 1, 2, 3, 6, 9, 10, 11, 12, 13, 14, 15,
16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 8, 9, 30, 32. Fourth one is fourth path that is 1,
2, 3, 6, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 32 and the fifty one is for the fifth
path that is 1, 2, 3, 6, 9, 10, 11, 12, 31, 32.

So, these are the minimum 5 test cases that are required one each for each of the linearly
independent paths. So, this minimum 5 we require to perform our white box testing. We can
have more as we have noted earlier, but at least 5 are required to create our test suit.
(Refer Slide Time: 31:01)
And like before for each of these test cases, again here ignore the typo it should be test case
1, test case 2, each of these test cases we provide the input, provide the expected output and
we also provide the system output. So, whatever we achieve after providing this input to the
program and the system generated output. If there is a match that means the test succeeds, if
there is a mismatch between the expected output and the system output then that test fails that
means there is some issue with the code.
(Refer Slide Time: 31:40)

So, in our case we can see here that in case of test case 4 there is a mismatch. So, expected
output is a fail message, whereas the system given output is success message. So, there is
some issue with this piece of code, we need to take corrective action. So, among the 3
functions, we have seen that when we performed white box testing with the test cases,
identify it with the help of CFG and the cyclomatic complexity analysis.

In one case, we encountered a problem that is the expected output and the system generated
output did not match. That means there is some issue with the code and we need to address
that issue that is the idea behind this testing. So, the failed test case needs to be recorded in
the document itself so that later on modifications can take place.
(Refer Slide Time: 32:47)
So, with that we come to the conclusion of this document. Here we mentioned what we have
found out and what can be done, like that one test case there was a failure, so that particular
function needs to be corrected, to take care of that failure, these typse of things you can write
in the conclusion.
(Refer Slide Time: 33:19)

And finally, the document ends with some references that were used to create this particular
document. So, that is in summary what should be there in a test report. So, earlier we have
seen several such reports, namely review-based testing report, black box testing report and in
this lecture, we have seen white box testing reports. The common format we have seen. So,
there will be a cover page followed by develop content followed by some sections which are
common. And then we record the actual testing details.
I hope you enjoyed the lecture and you have understood the things that needs to be mentioned
while you create a report. Remember that this is only one of several documentations that are
part of this execution of the interactive software development lifecycle for better
maintainability and refinement of the overall system. That is all for this lecture. Looking
forward to meet you all in the next lecture. Thank you and goodbye.
 Design and Implementation of Human-Computer Interfaces
Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology – Guwahati

Lecture – 36
System Integration and Testing

Hello and welcome to the NPTEL MOOCS course on design and implementation of
human-computer interfaces, lecture number 30 where we will continue our discussion on how
to test the system. As is the practice we are following before we start the lecture, let us
quickly recap the things that we have learned and where we are currently.
(Refer Slide Time: 01:09)

So, if you may recollect, we are discussing interactive system development lifecycle. In this
lifecycle there are several stages. We have covered many of the stages and we are currently
covering the implementation stage. So, among the stages we have covered requirement
gathering analysis and specification stage. Outcome of the stages the SRS document as we
have noted earlier.

Then we have covered design, prototyping and evaluation stages which together constitute
the design prototype evaluation cycle. In the design we have also covered the system design
as well as the interface and interaction design. Outcome of the design stages the design
document, both for interface design as well as system design. Outcome of the prototyping
stage is the prototype that is created and outcome of the evaluation stages the evaluation
report of the prototypes.
We have covered the coding and implementation stage as well. In the coding and
implementation stage, we have learned about good coding practices and do's and do not’s for
coding., the outcome of the stages the code. Currently we are discussing the code testing
stage. So, in this stage we are discussing how to test the code that we have written to
implement the system.
(Refer Slide Time: 02:43)

So, we have learnt about implementation using code and we are discussing the testing. Code
implementation involves code writing which involves following good coding styles and
testing can be done at different levels. At unit level, we have learnt about the review-based
testing and the execution-based testing. Review-based testing involves code walkthrough and
code inspection methods which we have discussed in details.

Execution-based testing involves black box testing and white box testing, which also have
discussed in details in the earlier lectures. Outcome of each of these testing methods can be
testing document as we have seen earlier. Now, all these testing that we have discussed so far
are done at the unit level. Recollect that while talking about design of a system, we talked
about designing it at module level, creating a module level hierarchy. So, the unit level is
basically referring to the implementation and testing at the module level.
(Refer Slide Time: 03:56)
So, in this lecture we are going to talk about how to test the whole system once we put
together all the modules or the units. So, putting together of units and testing of the whole
system together is the subject matter of this lecture.
(Refer Slide Time: 04:27)

Now, as we know or we have already noted in the earlier lecture, particularly during our
discussion on system design, the whole system is not a monolith. So, it consists of subsystem
subsystems, in other words modules and units. So, we are supposed to create a module
hierarchy, hierarchy of subsystems to go for the design of the whole system that makes it
easier to understand and maintain the system.

Therefore, while implementing we also go for implementing one unit at time rather than
trying to implement the whole system together at the same time. So, testing the whole system
at a time becomes difficult because we have a modular hierarchy and we require some
alternative approaches for testing the whole system once all the units are implemented and
linked together to form the whole system.
(Refer Slide Time: 05:24)

In order to test the whole system, we follow broadly two approaches. One is bottom-up
testing and the other is top-down testing. So, what are these concepts? What is bottom-up
testing and what is top-down testing? Let us try to understand these different testing
approaches.
(Refer Slide Time: 05:50)

In the bottom-up testing what we do? Each subsystem is tested separately and then the full
system is tested. That means as the name suggests we go from bottom to top. At the bottom
level, there are subsystems and at the top level there are subsystems put together to form the
whole system. So, we test the subsystems or units and then test the whole system. Now, a
subsystem may consist of many modules, which communicate with each other through
well-defined interfaces between modules.

So, do not confuse it with user interfaces, these interfaces between modules that form the
subsystem. So, while we go for bottom-up testing, our primary purpose is to test the
interfaces whether the interfaces are working properly. Now, there are two types of interfaces,
control interfaces and data interfaces. So, we test both types of interfaces in the bottom-up
testing.

The test cases that we designed to test the interfaces should exercise all interfaces in all
possible manners that is the general principle that is followed while we use bottom-up testing
method for testing the whole system. So, then in the bottom-up method what we do, we first
test the units and then join them together and test the whole system. In the testing, the
primary emphasis is given on how the interfaces are performing because already we have
done testing at the unit level.

No need to test them separately, but whether their communication is taking place as per
expectations that is what we need to test, so it tests the interfaces. Both control and data
interfaces we test and our test cases should be designed in a way such as that all these
interfaces are tested in all possible manners that is the general principle guiding the
bottom-up testing approach.
(Refer Slide Time: 08:13)
Next is the top-down testing. What we do in this top-down testing? Here the testing starts
with the main routine. So that means we are starting with the main routine at the top and then
slowly going to the bottom. After top-level skeleton is tested, the immediate subroutines of
the skeleton are combined with it and tested and this process continues till we cover the
whole system.

So, first we start with the main routine, a skeleton version of it, then we combine it with the
immediate subroutines and test it and this process continues till the entire system is tested.
Now, the problem with this is that while we are testing at the top, we may not have access to
the lower-level routines. So, in order to implement this approach, we require additional
support.
(Refer Slide Time: 09:20)

So, these approaches may require a concept called as stubs. Stubs simulate effect of
lower-level routines called by the routines under test, particularly when we are following a
top-down approach. So, we require stubs which simulate the effect of lower-level routines
while we are following top-down approach. So we start with main routines, but the lower
routines are not available.

So we use stubs instead of the actual routine so that the effect of the lower-level routines for
the given test cases can be simulated, but that is not only restricted to the top-down approach,
in bottom up approach also we require some additional support. We require driver routines.
These routines are used during bottom-up testing approach to simulate the behaviour of upper
level modules that are not yet integrated.
So, in bottom-up approach, we start at the bottom and slowly go up. While going up all the
routines that are available at the higher level may not be available to the person have the
system under test, so at that time we use driver routines to simulate the effect of those
routines that are not yet available. So, for full system testing either bottom-up or top-down,
we require some additional things to do.

If we are following a top-down approach, we require the help of sub modules. If we are
following a bottom-up approach, then we require the help of the driver modules. So, those are
the two broad categories of approaches we use for system testing. Now, let us quickly have a
look at different stages of systems testing. How many stages are there and what they do?
(Refer Slide Time: 11:26)

There are mainly three stages; alpha testing, beta testing and acceptance testing. Let us see
what is what.
(Refer Slide Time: 11:38)
Alpha testing, this is the first stage of system testing. In this stage what happens is that the
full system testing is carried out by a test team which is part of the organization. So, within
the organization the testing takes place.
(Refer Slide Time: 11:58)

Next is beta testing. Unlike the alpha testing, beta testing is performed by a select group of
friendly customers which may be specially recruited. So, in case of alpha testing all the
members of the test team’s are part of the organization, so no outsiders are involved. In case
of beta testing that is not the case, select group of friendly customers are specially recruited to
perform the testing. Note that here we are talking about customers, not the end users.
(Refer Slide Time: 12:43)
The third and final stage of testing is acceptance testing. This is entirely performed by
customer. It can be any customer, not necessarily a select group of friendly customers
specially recruited. So, this is the last stage where customers provide feedback on the
performance of the system. So, we have learned about broad approaches, stages of testing, let
us focus on types of testing. What are the different types of system testing?
(Refer Slide Time: 13:24)

So, in system testing what do we test? We test functionality and performance. These are the
two things that we test.
(Refer Slide Time: 13:31)
When we test functionality, SRS is our primary document. Whatever is listed in SRS those
things we test to see if the system satisfies the functional requirements that are specified in
the SRS.
(Refer Slide Time: 13:54)

In the performance test, that is the other broad category of tests, what we do is perform
non-functional requirement testing. So, in the performance test testing is for non-functional
requirements. What are those requirements and how those are tested, let us have a quick look.
(Refer Slide Time: 14:13)
First is stress testing. In this testing system performance is evaluated under abnormal or
illegal input conditions in short time periods. So, that is one kind of performance test that we
popularly perform or frequently perform during non-functional testing.
(Refer Slide Time: 14:41)

Then comes volume testing. Here what we test? We test system performance for large input.
So, in the previous case stress testing within a short time span, we provide large amount of
input or illegal or abnormal input and test. In case of volume testing, timespan is not the issue
rather the amount of data that the system is being asked to process is the issue. So, we test
how much data it can process, the volume of the data.
(Refer Slide Time: 15:18)
Then comes configuration testing. So, you have stress testing, volume testing, then comes
configuration testing. This testing is done to analyze the behaviour of the system in various
hardware and software configurations specified in the requirements. Typically, when you
specify the requirements for the system, you specify operating environments including
hardware and software. Now, in configuration testing those specifications are tested, whether
the system is actually performing under those specifications that we test in configuration
testing.
(Refer Slide Time: 16:08)

Then comes compatibility testing. So, in this testing we check if the system interfaces
properly with other systems. This is another special type of testing, sometimes it may so
happen that the system under test needs to work with some other system for that some
specific interfaces may be defined, and in compatibility tests we check if those interfaces are
working as per expectations.
(Refer Slide Time: 16:45)

Another testing is regression testing. In this case, we test the backward compatibility of the
software with older platforms or systems. Sometimes softwares are upgraded to newer
versions. Now, whether those newer versions work with compatible software of older
versions those things we need to test and those testing are done under the broad concept of
regression testing.

So, in compatibility testing we do not check for backward compatibility, we check for current
compatibility whereas in regression testing, we check for backward compatibility.
(Refer Slide Time: 17:34)
Then comes recovery testing. Under recovery testing what we test? We test system response
to faults, what are those faults? Loss of power, faulty devices, faults in services, faulty data
and so on. So, when we perform these types of tests that is recovery testing, so how the
system behaves or how the system responds when faulty environment is there. Now, fault can
happen in any one or multiple of those things such as loss of power, devices, services, data
and so on.
(Refer Slide Time: 18:30)

We also have documentation testing, what happens here? As the name suggests in this testing,
various manuals and documents are created and tested for understandability. It may appear
that this is not a very significant test and any document created should be understandable, but
that is not the case. When we create documents, it should be thoroughly proofread and tested
for understandability, readability and maintainability, those things are also tested as part of
performance test of a system under documentation testing.
(Refer Slide Time: 19:18)
Finally, comes usability testing which is the most important non-functional requirements in
the context of our focus that is interactive systems or human=computer interfaces. So, far
when we talked about different types of testing at unit level or system level such as review
based testing, black box testing, white box testing or these top-down and bottom-up testing.
primarily these were meant to test functionalities.

So, the starting point of system design was SRS and these testing are done to see how much
the implementation confirm to the requirements specified in the SRS document. Now, as we
have noted earlier in case of interactive systems one important consideration is usability. So,
functional requirements are not the only thing, usability requirements are also very important
to make a successful human-computer interface.

So, far in our testing we did not discuss much about usability requirement testing except in
the design prototype evaluate cycle where we mentioned that interface designs are prototyped
and evaluated with experts to check for usability issues. But that is a very quick way of
testing, we require more rigorous systematic and scientific testing methods which is a major
stage in interactive system development lifecycle.

In the subsequent lectures, we are going to talk about usability testing in details. Other
performance testing that we have mentioned like stress testing, volume testing, compatibility
testing, regression testing, configuration testing and so on we will not devote much time on
those and we will have only the brief idea that we have discussed here. However, on usability
testing, we are going to devote several lectures next to understand in details how usability
testing can be performed with end users in a very systematic and rigorous manner.

So, that is in summary what we need to test when we are testing the full system. Just to recap,
we mentioned about two broad approaches to test the whole system, top-down and
bottom-up. Earlier we have seen unit level testing in top-down and bottom-up approaches
along with unit level testing we test the whole system. When we talk about bottom-up
approach, we essentially test the unit individually and then put them together.

And we test the interfacing between the units so that the whole system is tested. In top-down
approach we start with the main routine and progress in an iterative fashion by adding
immediate subroutines to the main routines and this process goes on the next immediate
subroutine to the subroutine attached to the main routine and so on. And this process goes on
till we manage to test the whole system.

In both the cases, we require additional implementations to support the testing because your
whole system is not available at a time. So testing whole system at a time is difficult, so we
require additional support. If we are following a top-down approach, then stub modules are
used to implement or simulate lower-level responses which are not immediately available to
the main routines or the higher routines.

Similarly, if we are following bottom-up approach, then we need to implement driver

modules which are used to simulate response of the program for higher-level modules which
are not immediately available for the subsystem under test. Now, these top-down or
bottom-up approaches are primarily meant for functional testing. Along with that, we also
need performance testing. In functional testing or the top-down and bottom-up approaches,
there are primarily three stages of testing.

Alpha testing where the testing is done within the organization, beta testing where some
selected customers are part of the test team and acceptance testing which is done by the
customers. Along with functional testing, we also perform performance testing. Several
performance testing’s are there including stress testing, volume testing, compatibility testing,
configuration testing, regression testing, documentation testing as well as some other
testing’s.
One of the important testing’s here is the usability testing, which is our primary focus in this
course. In usability testing, we test for usability issues with end users. So, in subsequent
lectures we are going to learn about such testing methods and the process involved.
(Refer Slide Time: 24:56)

Whatever we have discussed today can be found in these books excluding details of usability
testing of course, but the broad ideas of these different testing methods can be found in these
books; Fundamentals of Software Engineering chapter 10 and Software Engineering A
Practitioner’s Approach chapter 19 to 21. Of course, in these chapters you will find the
concepts in more details than how we covered.

For our purpose, this brief description is sufficient to explain the concepts. Next, we will
focus more on details of usability testing. Hope you have enjoyed the lecture and understood
the concepts. With this, we have come to the end of our discussion on the code testing stage.
As you can quickly recap in this code testing stage, we have learned several concepts mostly
focused on unit level testing that includes code review, execution-based testing.

And also, we have covered in brief ideas that are important for system level testing. Next, we
are going to talk about usability testing, looking forward to meet you all in the next lecture.
Thank you, and goodbye.
 Design and Implementation of Human-Computer Interfaces
Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology – Guwahati

Lecture – 37
Empirical Usability Evaluation - 1

Hello and welcome to the NPTEL MOOCS course on design and implementation of
human-computer interfaces. We are in lecture number 31 where we are going to start a new
topic. As the convention we are following in the previous lectures, before we start we are
going to talk about briefly what we have learned so far and where we are now in the context
of this overall course. If you may recollect, we are discussing about interactive system
development.

So, when we use the term human-computer interfaces essentially what we are referring to is
development of interactive systems. Interactive systems are those systems that are supposed
to be used by the lay persons those who are not experts in technology. Also, it may be
recalled at this stage that when we talk of system, our primary intention is to refer to software
systems rather than any hardware.

So, when we are talking about interactive systems or human-computer interfaces as the title
of this course suggests, we are essentially referring to the development of interactive software
that are to be used by lay persons who are not technology experts, who are not experts in the
knowledge of how the technology works in the background and who are also not interested in
knowing or having that knowledge.

What they are interested in is primarily to get their work done. For those type of users, we
require special type of considerations to build the software.
(Refer Slide Time: 02:31)
Now, in the previous parts of this course, in the previous 29 lectures and the few case studies
that we have covered so far, we learned in details about the idea of interactive systems, what
are those and how those are different from other systems. We have also learned how to
identify requirements for those systems and how to translate those requirements into the
design of a system and then how to implement that as a software.

Now, we are going to learn about an important aspect of the development of such type of
systems that is how we can ensure that the system that we have developed meets the
expectations, the needs, the goals of the end users. In order to ensure that the system actually
meets the needs and expectations of the end users, we take help of a systematic system
development process. Now in this process, there are several stages.
(Refer Slide Time: 03:56)
So, we started our discussion with the requirement gathering stage that is the first stage. At
the end of the stage, we identify the requirements that are there, that are to be considered for
making the system acceptable to the end users. At the end of this stage, we produce a
document called SRS or software requirements specification document. After that, we have
learned about the design prototype evaluate cycle. In this cycle, there are three stages.

Design stage, prototype building stage and evaluation stage. So, in the design stage we
primarily focus on design of the interface and interaction which is the primary component
from the point of view of the user. So to a user an interactive software essentially refers to the
interface and interaction of that software rather than the internal design of the software. This
is followed by prototyping.

So once the design is done, we prototype it and then we evaluate it with experts. This process
continues till we arrive at a stable interface design where not many issues are identified or not
many issues remain. At the end of each stage, we produce a document. There can be a design
document, prototype document as well as an evaluation report of the prototypes. So, once we
finalize interface design, we go for system design and produce a system design document.

If you may recall it system design can be done either in a functional oriented approach or
procedural approach where we use languages such as DFDs and ERDs to create the
document. In case of object-oriented approach, we can use languages such as UML to
produce the design document. Once the design is done, then we implement the system using
coding and there we have seen what kind of coding practices should be followed for a good
implementation.

It will be recalled that after design activities for the system gets over, we need to produce the
design document. Then this document is used for implementing the system. At the end of this
implementation stage, we produce the code which may be documented with comments and
also some manuals to understand that code. After that, we have covered in details the testing
of the code, the purpose of testing is to ensure that there are no bugs or as little bugs as
possible.

And we have learned in details different techniques which include review-based testing. We
have learned in details different testing methods which include review-based testing, black
box testing and white box testing. So, each of these methods can result in a testing report as
we have seen in our earlier lectures. Now, let us come to the subject matter of this lecture in
the context of this interactive system development lifecycle.

So, we are going to now start discussion on the next stage of this lifecycle that is empirical
study. This is going to be our next topic and we will devote this lecture as well as subsequent
few lectures on explaining this stage.
(Refer Slide Time: 07:47)

So, empirical evaluation of the system is going to be our next topic. Just to put it into
perspective, so earlier we have seen evaluation of the system from the point of view of the
code. So, we have written a code and we tested it using different methods so that ensured that
the code is bug free to the extent possible. The purpose of empirical evaluation on the other
hand is not to identify bugs in the code.

Rather it is related to the objective of ensuring that the product is acceptable to the end users,
the product is designed in a way such that it meets the expectations and needs and goals of
the end users. In other words, the objective is to ensure usability of the product. So, that is the
major purpose.
(Refer Slide Time: 08:44)
Now, let us quickly recap the idea of usability. When we say that we perform empirical
evaluation of the product that we are developing or rather the interactive software that we are
developing what we really mean, what is usability? If you may recollect, we discussed
usability at the beginning of this course in the first week itself, the idea of usability was
discussed in details.

Since usability is going to be the main objective for this stage, so let us quickly recap the idea
again here. What is usability? Briefly we can refer to it as an explicit measure, measure for
what? So, it is an explicit measure to judge our design if we have taken care of the human
factors. So, this is the important consideration when we are talking of interactive systems. As
I just mentioned, it is meant to be used by lay persons who are not technology experts.

They are not interested actually to learn about the technology behind the working of the
system. What they are interested in is basically to get their work done. For example, if a
traveller wants to book a train ticket and he uses a ticket booking app, the traveller is not
interested to know how the app works, rather the traveller is interested to achieve the goal of
booking a ticket using the interface provided by the system as well as the interaction
supported by the ticket booking app.

So, whether the traveller will be able to do that or not depends on whether we have
considered the human factors in our design of the ticket booking app. Now, those human
factors have to be taken care of in the design of any interactive software. Now, the idea of
usability actually is to give us a measure to know whether those considerations are taken into
account, so that is the idea of usability.

And an explicit measure to judge our design from the point of view of a consideration of
human factors that are relevant for our system. It may be noted that a product which we found
to be usable for a specific group of system need not be usable for another group because the
human factors for the other group may be different than the group we are considering, so that
is also very important.
(Refer Slide Time: 11:27)

Let us quickly recall the definition of usability, definition provided by the International
Standards Organization, the standard number 9241-210:2009. So, according to this definition
of usability, usability is the extent to which a product can be used by specified users to
achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of
use. We have already covered this definition in details including the significance of the terms
mentioned here.

Just to recollect, there are three things mentioned that is usability is a measure to know
whether a product can be used by a specific group of users to achieve specific set of goals in
a specific usage context with effectiveness, efficiency and satisfaction. So, these three terms
effectiveness, efficiency and satisfaction together constitute the measure but equally
important to notice that we measure usability against a specific what context, specific group
of users and specific set of goals.
So, as I said whenever we are talking of usability, we should keep these things in mind that
usability is defined in the context of specific work contexts, specific group of users and
specific set of goals. So, same group of users may find a product unusable if the set of goals
change or the work context change. So, these things are key considerations while we are
talking about usability.
(Refer Slide Time: 13:35)

Now with that background knowledge which we just recollected, let us come to the main part
of this topic, empirical study. So, our objective is then to learn whether a product is usable,
earlier we have briefly talked about measuring usability in the context of prototype
evaluation. So we said that once we build a prototype, we employ a set of quote unquote
experts, who are essentially domain experts, not the technology experts to measure usability
of the product in a quick manner.

But that evaluation methods were as pointed out done by experts mostly on prototypes, in fact
only on prototypes and in a limited scale. So, it is a limited kind of measurement ad it may
not give us true measure of usability when the product is to be used by end users. Experts are
limited in number and they may not reflect fully the behaviour of the end users. So, what we
need is we have to go for full scale evaluation.
(Refer Slide Time: 15:01)
We need to evaluate our systems with end users, so here users mean end users. Now, the term
end user is very important here. In the context of software development, we have to keep in
mind that sometimes the task of developing the software can be given to a developer by a
customer who is not necessarily the end user. So, customer is the user of the software, but
there can be another group called end user, so here our focus will be only on end users.

So, what we need is, we need to evaluate our system with end users to get an idea of usability
of the final software. This is in contrast to the earlier evaluation where we evaluated our
prototypes with experts on a limited scale, now here we are talking of evaluating the whole
system with end users, actual users in a more rigorous manner.
(Refer Slide Time: 16:09)
In order to do that, what we need to do? We require to collect behavioural data from the end
users. Again, I would like to emphasize on the point end users, we need to collect behavioural
data from the end users for the purpose of usability evaluation that is what we require.
(Refer Slide Time: 16:31)

So, essentially what we need to do is we need to collect data from end users, the data is
behavioural data. When we perform a controlled experiment to collect and analyse data on
user behaviour, the entire process is known as empirical research. So, when we are using the
term empirical study or empirical research of end users for usability, essentially we are
referring to a general process, a controlled experiment we are carrying out to collect
behavioural data from end users. So, this is in general known as empirical research.
(Refer Slide Time: 17:20)
It may be noted here that this term empirical research is not specific to the evaluation of
interactive systems only. So, it is not specific to this human-computer interfaces, it is a
generic concept, any study involving observation-based data collection and analysis for any
purpose is empirical research. So, when we are actually going for collecting data based on
observation and then analysing that data that is called empirical research.

So, it is not only collecting end user data for usability evaluation of human-computer
interfaces, it is a generic concept which we are applying for our purpose of usability
evaluation of human-computer interfaces. Now, the data that we get from such observations
is called generally empirical data. So, that is a common term a generic term rather than term
specific to our context here that is evaluation of usability of human computer interfaces.
(Refer Slide Time: 18:44)

One problem is or rather one issue with empirical research is it is not easy. You may find or
you may think what is the big deal here? We simply ask some users about our system that we
have developed, we may take their feedback, we may ask them whether they find it usable or
not directly and based on their response, we may decide whether it is usable or not, but it is
not as simple as that.

To obtain reliable empirical data that leads us to reliable conclusion, we have to follow a very
systematic process which consists of a series of stages in sequence. So, if we simply take our
system that we are developing to a group of end users and ask for their feedback that is tell us
what you think about the system, tell us whether you find this system usable or not, you may
think that is one way of evaluating usability, but it is not as simple as that.
The feedback provided by the end users once they are asked this question may not be reliable.
If we ask them the same question tomorrow, their answer may vary. Now, this variation may
come due to the external factors such as their mental state, the environment in which they are
working and similar such things. So, what we need is some sort of evaluation which will give
us reliable conclusion.

So the evaluation process should be able to produce reliable data from which we can draw
reliable conclusions that is not an easy thing to do. It requires a very systematic and rigorous
approach consisting of several stages which we are going to learn in this and subsequent
lectures. So, what are the stages for empirical research?
(Refer Slide Time: 20:54)

Broadly there are four stages. First stage is identification of research questions. Second stage
is determinism variables. Third stage is design of experiment and the fourth and final stage is
analysis of empirical data. So, together these four stages constitute the overall empirical
research method. We are going to learn about each of these stages in details with examples
for better understanding.
(Refer Slide Time: 21:28)
Let us have a brief understanding of these stages. Let us start with the first stage that is
identification of research questions. So, in empirical research, we can think of this process as
seeking answers to one or more questions. So, the whole purpose of empirical research can be
thought of as trying to seek answers to few questions. It can be one question, it can be
generally more than one questions.

For example, how good is my system? But one issue with that is what kind of questions we
should frame for which we are looking for the answer, is this question how good my system
is is a good question to ask or to seek answer of it is not necessarily a good question, why we
will see later. So, it is very important to find a good question for which we seek the answer.
The good question actually guides us in conducting the subsequent stages of the empirical
research.

So, unless we are able to find a good question, our research method may be faulty. So,
finding a good question is generally difficult and it requires some sort of expertise. So, our
objective is to always start by clearly specifying one or more good research questions that is
the first thing that we should do and that is the first stage also.
(Refer Slide Time: 23:01)
Next, what we need is to identify variables. We require to identify variables to remove
ambiguity in observations. For example, unless we specify variables, we do not know what to
observe. So, if we are unable to identify variables properly, then we will not be able to
actually go for observations because it will not be clear to us what to observe and that will
again lead to a faulty empirical research method.

So, after we formulate a good research question or more than one good research questions,
we should go for identification of appropriate variables and the variables are required to
record our observations for later analysis. So, that is the purpose of identification of variables
to record our observation, unless we are able to identify the variables we will not be able to
know what to observe and how to record it.
(Refer Slide Time: 24:07)
In the third stage, we need to design the experiment or the study. So, study not simply going
to a group of end users and asking them questions, tell us this, tell us that. It is a systematic
process, a very rigorous scientific process and we need to put in some effort to design the
process, design the experiment. So, the experiment design stage essentially refers to planning
and execution for the study.

So, the study is the core component of any empirical research method where we need to
observe record observations which we will later analyse. Now, this observation and recording
of observations requires some planning and some design of experiments that is the third stage
of the empirical research method.
(Refer Slide Time: 25:00)

In fact, this is the core stage also, then comes the final stage that is analysis of the observed
data. So, before we go to that one crucial point to note is why we need to design experiment
is that we need to get right users and in right numbers to perform the experiment properly,
otherwise the results may not be reliable. It is also necessary to determine appropriate tasks in
a suitably controlled environment ad without that we may again end up with unreliable data.

So, even if we have good research questions and properly identified variables, still we cannot
immediately start our experiment that is the controlled experiment unless we are able to find
out right users in right numbers and able to identify appropriate tasks and able to control our
environment suitably. If we do not do all these things, then we may end up with unreliable
data leading to unreliable conclusion. So, these are very important and these requires us to
properly plan the study.
(Refer Slide Time: 26:28)

So, once that study is done and we are able to capture the data, the final stage is to employ
appropriate data analysis technique to extract conclusions. Let me give you a quick example.
Suppose, in an experiment we found that majority of the participants in the experiment that is
majority of the end users who took part in the study opined that our system that we are testing
has no usability and we directly conclude from here that our system is free from usability
issues, not necessarily so.

We have to ensure that the opinion or the results that we obtained is reliable. For that we need
to employ proper analysis techniques to first judge the reliability of the conclusion and then
we can go for conclusion. So, appropriate analysis technique is also very important, which is
the final and fourth stage of the empirical research method. So, in brief these are the four
stages which we go through while performing empirical research to study about usability of
our interactive system.

Now, let us go through each of these stages in details, let us try to understand each of these
stages in details with examples. So, we will start with the first stage that is formulation of
research question. Let us try to understand this stage with one example scenario. This will
give us a better way to understand the importance of this stage.
(Refer Slide Time: 27:59)
Suppose, we have developed a new text entry interface. We can think of it as a GUI or
graphical user interface which can be used for text input. So, you want to input text and we
have developed a GUI to provide the input to the computer. Now, that is one system that we
have come up with. So, we have gone through all the stages, requirement analysis stage,
design, prototype, evaluate cycle.

Then system design, stage coding stage, implementation stage, testing stage, testing of the
code and finally we are left with the implemented and code tested system. Now, we want to
understand its usability through empirical research. So, the first stage is we need to frame a
research question for which we want to seek an answer. With that research question we wish
to collect empirical data to measure usability or rather to get an idea of the usability measure.

So, the first step is we frame a research question. So, what can be a research question to
measure usability of this particular interactive system that is text input interface.
(Refer Slide Time: 29:30)
Let us start with a simple question straightforward, obvious, intuitive question. Is the new
technique that we have developed good rather is the new system that we have developed
good? Whenever you are asked to measure usability, many of us may immediately come up
with such type of questions and we must try to seek answer to these questions through
empirical research to know about usability of the product.

So, what do you think of this question, is the product good? It may appear that this is a good
question because ultimately what we are interested in is to know whether our product is good,
but is it really a good question? Let us try to understand it in a little more details.
(Refer Slide Time: 30:29)

Now with this question, we are supposed to observe, note that empirical study is all about
observations, so we are supposed to observe if the interface that we have developed is good.
So, here when we use the term interface essentially it refers to the system and we are trying to
observe whether the system that we have developed is good or not.
(Refer Slide Time: 30:57)

To make the observations, we set up an experiment. Now, at this stage we will not talk about
the other stages of empirical study that is how to set up experiment, how to design
experiment, how to identify variables, rather we will simply tell about the experiment. So,
what is the experiment?
(Refer Slide Time: 31:17)

We present the interface to a user and ask the user to judge its quality. Note that we are
interested to know whether the system is good, quote unquote good. So, it is essentially a
qualitative attribute, so we ask the user to judge its quality. And since one user’s data may not
be sufficient, so we repeat the process a few times. Let us assume that for five users we
repeated the process and that is all about our experiment.

So, in the experiment what we did? We employed five end users, we give the system to each
of them to learn about the system and then we asked each user to say something about the
quality of the product because whether the product is good or not is a qualitative attribute.
(Refer Slide Time: 32:22)

Let us assume that we got responses from all the five users. So, this is what the responses
look like. So, we have logged the responses and produced an experiment log which records
the observations for our product quality from the five users. So, user 1 mentioned that the
quality is good, user 2 said quality is poor, user 3 said not very good, but not very bad either,
user 4 said good and user 5 said very bad.

Now, why they gave these qualitative answers is not our concern, our concern is whatever
responses they have given. So, there are five users each gave one response. User 1 said good,
2 said poor, 3 said not very good but not very bad either, user 4 said good and 5 said very bad
that is our experimental log that means that is the observation that we made and recorded.
(Refer Slide Time: 33:35)
So, immediately the question that comes to our mind is now our observation is done, so we
need to analyse and come to a conclusion, but the thing is what can we do with the
observations? Can we really do anything with this observation? Obviously, we cannot do
much. As you can see, there is no agreement between the users about the quality. So, two
users, 1 and 4 said it is good, the user number 2 said it is bad whereas user number 5 said it is
very bad.

So, these two we can consider it to be referring to bad quality. So, two said good, two said
bad. And user number 3 did not say anything definitive. So, according to that user it is not
very good, but not very bad also, so a middle ground. Now, with this can we really conclude
whether the interface is good or bad? Not really, we will not be able to come to such a
conclusion.
(Refer Slide Time: 34:41)
Why? Because the opinion is equally divided. Two said good, two said poor or bad and one is
in between, neither good nor bad. So, we are not likely to get answer to the research question
that we have framed that is whether our product is good. Note that in any empirical study, we
try to seek answer to one or more questions. So, here in this simple case we framed one
question whether our product is good. And from the observations, we really cannot get
answer to this question because of the nature of responses that we have received.
(Refer Slide Time: 35:27)

Now, why we cannot get answer from the observations? This is because they are elements of
vagueness in both the question that is the question that we framed as well as the observations.
So, the question is not unambiguous, the observations are also not unambiguous.
(Refer Slide Time: 35:59)
When we asked the users for their feedback on the quality whether it is good or bad, we
actually did something which is not very clear to the user. So, the idea of interface quality
whether it is good or bad is rather vague. It is not clear what it means. Does it mean that it is
good in the sense of look and feel only or it is good in the sense of functions or it is good in
the sense of both that is look and feel as well as functions? We did not specify or clarify on
this issue while seeking feedback from the users.

The observations can also be vague as we have just noted. For example, the user opinion can
be vague that is the opinion of user number 3, who said it is not very good, but not very bad
either, a middle ground, so neither good nor bad in between. Now, if the question that is
asked is vague, it is expected that the answers can also be vague, but that is not necessarily
always correlated. So, even if the question is not vague, the answer can be vague.
(Refer Slide Time: 37:14)
So, what is the problem here then? We are dealing with observations that are difficult to
interpret due to the vagueness inherent in the research question. So, why this problem
happened? Because we framed a question that is inherently vague. And when we asked the
users to provide answers to this question or rather provide feedback on the basis of this
question, the vagueness appeared in their responses as well.

So, the responses were difficult to interpret because of the inherent vagueness in the research
question. So, then we have to somehow overcome this issue. So, we have to frame a question
in a way such that the question does not have vagueness and accordingly we can expect the
responses that are unambiguous, but that also depends on the kind of responses we are
seeking. So, if we try to seek responses in the form of opinions, then they can be vague.

But if we try to seek responses that are not in the form of opinions, but rather in some other
form then we can avoid vagueness. So, we have to improve on both aspects that is reduce or
remove the vagueness in the research question as well as reduce or remove the possibility of
vagueness in the opinions.
(Refer Slide Time: 38:39)
So, we can do better, in fact we have to do better, and how this betterment can be done we
will learn about those in the next lecture. So, with that we have come to the end of this
lecture. In this lecture, we have just introduced the first stage that is the formulation of
appropriate research question which is the first stage of any empirical research method.

We have also learned the need for empirical research and the way it can be done that is the
four stages which have to be performed in sequence. I hope you have understood the concepts
that we covered today. We will continue our discussion on these concepts in next and
subsequent lectures.
(Refer Slide Time: 39:24)

Whatever we are discussing can be found in this book Human-Computer Interaction:

User-Centric Computing for Design. You may refer to chapter 7 to learn about the topics that
we are covering in this lecture and subsequent lectures. That is all for this lecture. Looking
forward to meet you all in the next lecture. Thank you and goodbye.
 Design and Implementation of Human-Computer Interfaces
Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology – Guwahati

Lecture – 38
Empirical Usability Evaluation - 2

(Refer Slide Time: 00:54)

Hello and welcome to the NPTEL MOOCS course on design and implementation of
human-computer interfaces. We are going to start lecture number 32 where we will continue
our discussion on empirical study. As is customary before we start, we will quickly recap
what we have learned so far and then we will come to the topic of this lecture. So, we are
discussing the interactive system development lifecycle.

This is a systematic approach to build interactive systems. Human-computer interfaces are

nothing but interactive systems. And the objective of having a systematic approach is to
ensure that the end product which in our case is an interactive software meets two conditions,
it is executable as well as usable. In the earlier lectures, we have talked about the various
stages of the lifecycle in details including case studies on the outcome of those stages.

These stages include requirement gathering, analysis and specification stage. Outcome of this
stage is software requirements specification document or SRS which we have seen earlier in
details. Next is the design stage, in this design stage we primarily concentrate on design of
interfaces and interactions and outcome of this is a designed document. Now, the design
document is created based on the experience of the designers as well as some design
guidelines.

Now, once the design is created it needs to be prototyped for quick evaluation. So,
prototyping stage also we have discussed, outcome of this is the prototype. Then comes quick
evaluation of prototypes which is typically done with experts. Now, the objective of this
design prototype evaluation cycle is to ensure that we come up with end usable interface
design. After we arrive at a stable design of interface and interaction, we go for system design
which is part of this design stage.

In system design, we try to design the code that is going to be written for implementing the
system. Now, here our primary objective is to go for a modular hierarchical design and we
can follow either of two design approaches. One is procedural approach; other one is
object-oriented approach. For procedural approach we can make use of DFD as a language to
express our design, for object-oriented approach we can make use of UML as a language for
expressing our design.

So, the outcome of the system design phase is a design document of the system. Whereas the
outcome of the interface design phases the design document for the interface. After the
system is designed, we go for implementing the system, so we come to the coding and
implementation stage. In the coding and implementation stage, we follow coding standards
and guidelines to implement the system by writing programs.

So, the outcome is obviously the code itself along with some documentation of the code for
better understanding. Once the code is written, we need to evaluate it for bugs. Now,
evaluation can be done in different ways. A quick evaluation method is the review-based
evaluation of the code where either of the two approaches or both can be deployed, namely
inspection-based code review and walkthrough-based code review.

Outcome is as obvious a testing report. Now, the quick evaluation is one approach, also we
can go for rigorous evaluation, more formal rigorous evaluation of the code following a
functional approach which is known as black box testing and structural approach which is
known as white box testing. In black box testing we do not bother about the internal structure
of the functions, rather we consider them to be black boxes and our only knowledge about
those functions are what inputs they take and what outputs they produce.

Based on that we test the code that is black box testing and at the end we generate a testing
report. In structural testing or white box testing, we are aware of the internal structure and we
design test cases to execute the instructions or the statements that are present in the code. The
outcome is again another testing report. So, testing is essentially a way to know about the
code; whether the code is executable, what are the bugs and how we can overcome them.

Now, this testing does not say anything about the overall usability of the product. For that, we
go to the next stage that is empirical study. Currently, we are discussing empirical study. In
the previous lecture, we talked about few basic concepts of empirical study and started our
discussion on different stages of empirical study. We are going to continue that discussion in
this lecture as well.
(Refer Slide Time: 06:22)

Now, as we have already mentioned earlier also in one of the stages, we talked about
empirical evaluation, we talked about usability evaluation. First of all, why we need empirical
study to understand usability of the end product? Now, earlier during design prototype
evaluate cycle we talked about usability evaluation, but that was on a limited scale done by
expert users on prototypes. So, that actually still do not reveal everything about usability
issues as compared to getting it evaluated with actual end users.
(Refer Slide Time: 07:00)
So, we need to evaluate our product for usability with end users and that too in a very
systematic manner. We cannot go for evaluation in an ad hoc manner.
(Refer Slide Time: 07:12)

In order to perform systematic and rigorous usability evaluation of our product, we need to
perform a controlled experiment, observe user behaviour during the experiment and from
there need to conclude about usability of the product. So, this controlled study and
observation of behaviour in that study is generally termed as empirical study, but this is not
specific to usability evaluation only as we have noted earlier in the previous lecture.

This is a generic term where we observe and conclude based on observations. Here also, our
primary objective is to observe user behaviour in a controlled environment that means we
provide them tasks and we control the experimental conditions and under that controlled
environment, we observe how they behave while performing the tasks and based on that we
conclude about usability by analysing the observed data that is the basic things that we have
already discussed.

Also, we discussed in the previous lecture about the different stages of empirical research.
So, empirical research or empirical study these terms we will use synonymously. In empirical
study, we do several things and it is always useful to think of the study as consisting of
distinct stages for better understanding of the process.
(Refer Slide Time: 08:51)

So, there are four stages that are there in any empirical study. What are those four stages?
Identification of research questions that is the first stage, determinism of variables second
stage, design of experiment third stage and analysis of data that is fourth stage. Briefly, what
these stages do? When we talk of empirical research, we start by asking questions. The whole
objective of empirical research can be thought of as trying to find out answers to those
questions.

So, first step is we have to frame questions that is what we are calling as research questions.
Good research questions are essential to perform a good empirical study. If the research
questions are not properly framed, then the study results and the corresponding analysis of
those results may not be very reliable. Once we are able to identify appropriate research
questions, next thing is to identify what are the variables in our study.
Unless we are able to identify variables, we will not know what to observe and how to record
those observations, so this is also very important. After that, we need to come up with a
proper design of the experiment that we need to perform to collect empirical data or observed
data. It requires planning, it requires careful considerations and balancing several trade offs
so that design of experiment is our third step.

Once the experiment is done, we need to analyse the data, to come to a conclusion that is our
fourth stage. One thing we need to remember which we already mentioned or already noted
in the earlier lecture is that empirical study including all the stages are required to conclude
reliably about the usability of a product. So, you may think of ignoring these stages, simply
go to the users and ask for their feedback.

And based on that try to conclude something about the usability of a product, but that
feedback may not be reliable. So, we require to collect reliable data to come to a reliable
conclusion and for that we require a very systematic approach. And these four stages if done
properly can provide us that systematic approach to come to a reliable conclusion about the
usability of a product. So, in the previous discussion, we started our understanding of framing
of research questions, let us continue that discussion in this lecture as well.
(Refer Slide Time: 11:40)

So, we took a case to understand the issue. So, the example case, example scenario was that
we have developed a new text entry interface or a graphical user interface for text input and
we want to understand its usability through empirical study. So, what kind of research
questions we should frame to evaluate the usability?
(Refer Slide Time: 12:10)

Note that our objective is to collect empirical data and to collect empirical data we must have
a question based on which we will collect the data, so what should be that question? That is
the first step, framing of the research question.
(Refer Slide Time: 12:22)

In the previous lecture, we have seen that we can frame one research question which can
come intuitively, too many of us; I am not saying all, but too many of us. The moment I say
that you are supposed to frame a research question immediately this may be one of the
questions that may come to our mind that is, is the new system or technique or the interface
that we have developed is good? That seems to be a very intuitive question that comes to our
mind. And based on this question, we have conducted an empirical study.
(Refer Slide Time: 13:09)
We have presented the interface to a user and asked for his or her opinion to judge its quality.
Basically, we asked the users and we did this process for five times with five users. So,
essentially in our empirical study, in our experiment what we did is we employed five users
asked for their judgment on the quality of the interface because our question says that
whether it is good; now good or bad is a quality. So, you ask the users for their judgment on
the quality of the interface and recorded their responses.
(Refer Slide Time: 13:50)

Now, the responses that we recorded are like this which you have already noted earlier. User
1 said good, user 2 said poor, user 3 said not very good but not very bad either, user 4 said
good and user 5 said very bad. So, here user 1 and 4 they have agreement that the interface is
good. User 2 and 5 they disagree, according to them the interface is not good, it is either poor
or very bad. Whereas user 3 did not give any definitive answer.
So according to that user it is neither good nor bad, somewhere in the middle. So, from these
responses can we really conclude about the usability of the product? In fact, can we really
conclude anything about the answer to the question whether our interface is good assuming
that answer corresponds to the usability? That is very difficult because we do not have
agreement, it is equally split between the users, the participants in the experiment, so very
difficult to come to a conclusion.

In fact, it is impossible in this case, we cannot say with certainty whether we can call it good
or bad. Now, why this problem happened? In spite of us framing a research question and
asking for feedback, we did not get some observations which can lead us to definitive and
reliable conclusion about the usability of the product, why this happened?
(Refer Slide Time: 15:34)

This happened because here we are dealing with observations that are difficult to interpret
because we have framed a question which is vague. So, some vagueness is inherent in the
question when we ask the users about their judgment on the quality where we explained the
quality as either good or bad, we did not specify what is good, what is bad. So, users
interpreted it in different ways and accordingly they gave the responses. So, the question
itself is very vague and accordingly the answers; the feedback that we received were vague
and difficult to interpret.
(Refer Slide Time: 16:16)
Can we do any better? Definitely we can and we have to do better to come to a reliable
conclusion. So, let us see how we can improve on this situation, how we can come up with a
better question. Let us know compare our interface with other similar interfaces, that means
other text input interfaces. So, earlier we are not comparing anything, instead we were simply
presenting the interface to the users and asking for their subjective opinion about the
goodness of the interface.

We never said whether this interface is good with respect to so and so interface, so no
comparison was made. Now, let us see if we compare the interfaces between our interface
and some other already available similar text input interfaces, then whether we can do any
better. So, first thing we have to do is we have to reformulate the research question.
(Refer Slide Time: 17:19)
So, let us frame another question, a revised question, let us call it RQ2 which is, is our text
input interface better than the text input interface provided by some other interface, in this
case MS Word, which is another text input interface Microsoft Word. So, here we are using
the term better which is a competitive term. So, we are not using any definitive term like
good or bad.

In comparison to some other interface whether our interface is better, so that is our research
question. Now, if we conduct the same experiment that is ask 5 users for their feedback on
this question, what kind of responses we are likely to get? Let us see.
(Refer Slide Time: 18:13)

Now, we see somewhat different responses. User 1 said no, MS Word has many features.
User 2 said yes, it is a clean interface; it means our interface. User 3 said, again middle
ground, difficult to say; user 3 still not very sure about the interface. User 4 on the other hand
said yes, minimal useful feature set, easy to remember. User 5 on the other hand said no, can
do, it should be do.

Let us rectify it to remove ambiguity it should be do; can do many things with MS Word. So,
are we in any better position? Apparently not because again here there is no agreement. User
1 and user 5 still agree that it is not better than MS Word. User 2 on the other hand and user 4
agree that it is better than MS word whereas user 3 is still noncommittal, still no definitive
answer from user 3.
(Refer Slide Time: 19:33)
Now, from these observations, what kind of conclusion we can make? When asked to
compare, users give somewhat more concrete feedback. So, it is now in a better position to
know exactly what is going on in the mind of the users who are giving the feedback. Better to
some means more features, to others means less features. Note that here when we say is it
better, some may think that better in the sense of having more features, so in that sense their
answer will be no because MS Word provides more features.

Whereas others may think that it is a minimalist design, better means minimalist design, less
features, so in that case they will answer yes because our interface is purportedly having less
features than the MS Word. Some may still be confused, user 3, that is still possible. So, the
takeaways are firstly somewhat more definitive, more concrete responses compared to the
previous case.

But still there is ambiguity about the meaning of the word better and some users may still
give confusing response. So, at the end we can say that we are in no better position than the
earlier case, we cannot still draw any definitive conclusion which is reliable based on these
feedbacks. But we get somewhat better responses compared to the previous one. Can we do
even better? Yes, definitely we can do even better.
(Refer Slide Time: 21:16)
Let us reframe the question, third revision of the question. So, earlier we have seen RQ1 and
RQ2, now let us go to RQ3 a revised version of the question. Does the new interface let me
enter text faster than MS word? Note how the questions are changing. Initially, we asked
whether the interface is good irrespective of anything else. Next, we asked whether it is better
than some other interface.

Now, in this third revised version of the research question what we are asking is a more
concrete measure that is whether the interface let me enter or input text in a faster manner as
compared to MS Word that is the other interface with which we are comparing.
(Refer Slide Time: 22:11)

Now, in this case of course we do not need to take recourse to opinions or feedback of the
users, we can actually measure the text input speed on the two interfaces and then decide
ourselves whether one is faster than the other. So, here we do not just ask for feedback. Now,
why that is good because we have already seen that the feedback may be vague and subject to
interpretation, so the feedback that comes from the users need not be in agreement.

Different users may interpret the research question differently and accordingly provide
feedback. So, it is subjective feedback based on individual interpretations and the feedback
can be vague, it is difficult to conclude from the feedback. Instead, what we can do? We can
give them some tasks and ask for their feedback. Now, the tasks are since we are dealing with
text input interfaces the task can be input a text and then we can ask for feedback.
(Refer Slide Time: 23:29)

Now, they have been given the task and they perform the task and then they are giving their
feedback whether it is faster or not. Now, we are recording slightly more details. Along with
the feedback, we are also recording number of objects present on the interface, however we
will come to that later. So, for interface 1, user 1 said yes, it is faster. User 2 said yes, it is
faster. User 3 said no, it is not faster. User 4 said yes, it is faster. And user 5 said yes, it is
faster.

So, here what is the implication of this observation? If we ask whether our interface is faster
than MS Word or any other comparable interface in a hypothetical case we are talking off and
we ask the users to perform some tasks and then provide their feedback. We may expect that
the feedback that we now get is likely to lead us to definitive conclusion.
(Refer Slide Time: 24:43)
It is now easier to answer RQ3 as we have seen and in fact it is easier to analyse the data
avoiding subjective biases. Now there is no scope for individual interpretation, we have
clearly stated that we are interested only in typing speed and typing speed can be measured in
say words per minute or characters per second, we can measure the speed and then say
whether speed on one interface is higher than the speed on other interface.

And then we can say it is faster than the other interface. So, no scope for ambiguity in the
interpretation of the question. So, if we remove that ambiguity, then we get better
observational data as we have seen with RQ3.
(Refer Slide Time: 25:36)

Now, this can be done in another way as well. So, instead of asking for their feedback, we can
do something on our own. Suppose, we gave them the same task. So, all of them perform the
same task that is the same text to input with the two interfaces, then we ourself recorded the
text entry speed in say CPM or characters per minute that is the unit of measurement for text
entry speed.

Now, instead of asking for their feedback, what we can do is we can compare the CPM values
of the 5 users and come to an objective conclusion. So, we no longer rely on their feedback,
instead we can check ourselves the values because we have recorded those and then come to
a conclusion about the speed of text entry on our interface in comparison to the other
interface. So, rather than relying on the users' subjective feedback on the idea of faster, we
can do it ourselves.

Although we said faster is less ambiguous compared to others, still faster to some can create
confusion. So, instead of relying on their subjective interpretation which may lead to some
sort of ambiguity in the outcome that is the feedback that they provide, we can simply
remove the feedback component, we can record their speed by some means while they are
performing the text entry tasks.

A simple way to do that of course can be suppose we have asked them to enter a 10
characters text, when they start entering, we start a stopwatch and then when they stop
entering we stop the stopwatch. So, the time gap we can record and then we can easily
compute characters per minute or characters per second from that time gap that we have
recorded.

So, we do that for every user for every task and create a table and from there we can see their
performance and we can say that given the tasks for user 1, one interface is faster than the
other, for user 2 same interface is faster than the other and so on. So, this type of conclusion
we can ourselves draw based on the observations that we have made. So, here there is no
need for feedback which removes any possibility of ambiguity in interpretation of the
research question. So, what it tells?
(Refer Slide Time: 28:32)
What is the difference between RQ1 and RQ2 and RQ3? What is there in RQ3 that makes it
better than RQ1? I hope you realize that RQ3 is much better than RQ1 because it leads us or
it can possibly lead us to a definitive conclusion to our research question in opposite to RQ1
where it is difficult to interpret the observations. So, RQ3 has two major differences as
compared to the earlier questions that we have framed.
(Refer Slide Time: 29:10)

Lack of ambiguity. This is the first thing we should note. Here, we are specifying that we
wish judge quality of interface in terms of speed of text entry. So, we are removing all sorts
of ambiguity about what we mean by the quality of interface. So, we are avoiding the terms
like good which is subject to interpretation, better which is again subject to interpretation and
we are replacing those terms with a very specific term that is faster which is unambiguous.
And there is no possibility of different interpretations for this term. So, lack of ambiguity is
the past characteristics of RQ3 which differentiates it from RQ1 and RQ2 that are the
previous two research questions. There is a second crucial difference also.
(Refer Slide Time: 30:08)

Now, we are dealing with measurable quantities, so this is very important. In first research
question or second research question what we are observing, we are not actually observing
anything that is measurable, instead we are collecting subjective feedback which we cannot
measure. Whereas in case of research question 3, what we did? We defined a quantity faster.
We introduced a quantity faster, which we can measure as I just mentioned.

How we can measure? We can simply record the time required to enter the text and then
depending on the number of characters in the text and the total time required to enter so many
characters, we can compute the speed and we can compare the speeds to know which one is
faster. So, here all quantities that we are dealing with are measurable quantities, we can
measure them and we can measure them objectively.

So, there is no scope or subjective interpretation of the quantities. We cannot measure

interface quality like goodness or better, these are not measurable, it is always subjective.
Whereas, in RQ3 we have replaced unmeasurable concepts such as goodness or betterment or
better with measurable quantity which is text entry speed and using text entry speed, we can
compute another measurable quantity that is faster.
We can simply compare, take the difference and see what is faster. So, both are measurable.
So, we are replacing non-measurable quantities with measurable quantities in the third
research question. So, these two are the crucial differences between the earlier questions and
the third question that is lack of ambiguity and presence of measurable quantities.
(Refer Slide Time: 32:09)

Now, when we have measurable quantities in a research question, then we call it testable and
when we do not have measurable quantities then we call it non-testable. So, R3 is testable,
whereas R1 is non-testable. Now, we are introducing two terms, testable research questions
and non-testable research question. Testable research questions are those which involve
measurable quantities, non-testable research questions are those which do not involve any
measurable quantities such as R1 and R2.

Now, there is a tradeoff between the type of research questions that we can have, whether it is
testable or non-testable. Each has its own positive and negative sides and there is a tradeoff
which needs to be balanced when we go for forming of research questions. So, let us try to
understand the tradeoff.
(Refer Slide Time: 33:12)
What is our aim in empirical study? Ideally, our aim should be to frame testable research
questions because this will lead us to reliable conclusions, definitive conclusions which is not
dependent on subjective interpretations, so that should be our aim. Now, the problem with
achieving this aim is that testable questions are designed to seek answers to specific queries,
such questions may lack generalizability to conclude about overall usability.

Now, earlier we have seen that we asked for comparison in terms of whether one is faster
than the other and that is a very specific thing. One thing we should notice that that specific
question when asked leads to answer to those specific questions only. So, we can conclude
that one is faster than the other, but then can that conclusion be generalized to say that one is
more usable than the other or one is better than the other? That is not possible.

So, testable research questions by nature deals with specific queries which lead to specific
answers and those answers lack generalizability.
(Refer Slide Time: 34:40)
So, we have already mentioned about this third research question RQ3. So, objective is to
determine which interface is faster, will that alone represent the interface quality? So, here in
terms of usability, we are more interested to know whether the interface is usable. But if we
answered the question that one is faster than the other, can we conclude anything about the
more generic concept of usability?
(Refer Slide Time: 35:04)

Text entry speed which is the thing that we used to answer that particular question RQ3 is not
the only component that determines usability of an interface. This should be obvious earlier
we have talked about the concept of usability, it includes many things and only concluding
about usability based on text entry speed and correspondingly whether something is faster
than the other similar systems cannot lead us to a generic conclusion about the overall
usability of the product.
(Refer Slide Time: 35:41)

There may be other aspects of the interface that determines usability that includes number of
features supported, learnability, error rate and so on. So, all these things we have already
discussed in our earlier lectures when we talked about the idea of usability, so this is a
problem. On the one hand, we aim to have testable research questions.

But then the problem is with testable research questions it may be very difficult to come to a
generic conclusion about the overall usability of the products because testable questions lead
to specific answers to specific queries. Now, those specific answers are not amenable to
generalization about the overall quality or usability of the product.
(Refer Slide Time: 36:49)
For example, as we have seen RQ3 the third research question answers only one aspect of the
overall usability that is the efficiency, how fast we can carry out the text input task, but it
does not answer other qualities, memorability, error rate, learnability, satisfaction, etc. If we
go by Nielsen's five measures or if we go by ISO standard definition of usability, it talks
about efficiency, but it does not talk about effectiveness and satisfaction.

So, we cannot really conclude based on answer to R3 whether our interface is usable. We can
say that our interface is faster than other interfaces, but we cannot say whether it is usable as
compared to other interfaces.
(Refer Slide Time: 37:42)

This is in contrast to RQ1, the first question we framed which encompasses everything and
thus untestable since we do not know what to test. Now, earlier we said RQ1 is not a good
research question. But in another sense, it is a good question because it tries to come to a
conclusion about the overall quality of the system that is whether it is good. But then since it
tries to talk about everything, all aspects of the system, rather usability of the system.

It is untestable because we do not know then what to measure. There is no specific measure
and it becomes very ambiguous to record observations. Based on what we will record
observations we do not know, so it becomes untestable. Although the answer to this question
can give us a generic answer to the broad question that is whether our product is usable.
(Refer Slide Time: 38:44)
However, if we can somehow get the answer to RQ1 we are supposed to get the true
conclusion that is whether our product is usable. But to get the answer of RQ1 we need to test
it which we cannot do because it is untestable, so that is the problem.
(Refer Slide Time: 39:04)

In scientific terminology, this is known as validity of the research question. So, this situation
that we are discussing relates to a concept called validity of the research question, whether it
can answer generic questions or it can answer specific questions.
(Refer Slide Time: 39:25)
We can draw only specific conclusions from observations made for some research questions.
Such conclusions depend on the specific test conditions and generalization is not
straightforward, in fact it can be impossible also as we have just seen.
(Refer Slide Time: 39:49)

So, the extent to which the observations made for a research question depends on the test
condition is known as the internal validity of the question. So, if the observations made for a
research question depends on the test conditions, the extent to which it depends on the test
condition is called internal validity. That means the more dependent the observations are on
the test conditions, we can say that it has more internal validity. And if it has more internal
validity, then it is very difficult to generalize.
(Refer Slide Time: 40:38)
In contrast to that, the extent to which we can generalize the conclusions drawn from the
observations is called the external validity of the question. So, the extent to which the
observations are not dependent on the test conditions is called external validity. So, the more
external validity that questions have, the more possible it is to generalize the conclusion
drawn from those observations. So, what is the trade off?
(Refer Slide Time: 41:12)

We cannot frame questions that are based on generalized concepts such as RQ1, those are
likely to be untestable. If we go for more specific questions such as RQ3, we might get
testable questions, however we may not get the true answer that is the tradeoff. We want true
answer, for that we need to frame questions but those are not testable. Now, if we frame
testable questions, we might get some reliable conclusions but that is not what we want at the
end. So, there is a tradeoff between internal validity and external validity.
(Refer Slide Time: 41:50)

So, the research questions that we should frame should balance between internal and external
validity. The more internal validity a question has the less generalizability, the more external
validity a question has the less testability is and we need to balance the two, how we do that?
We can balance the trade off by framing multiple testable questions. This is one way out
instead of having a single question or limited number of questions.

We can set multiple testable questions, so multiple questions with high internal validity and
the conclusions for these multiple questions can be together used to give us a conclusion
about the overall usability or overall quality of the product. So, that is one way out and that is
the way to balance the tradeoff.
(Refer Slide Time: 42:58)
So, let us try to understand that with a few more questions that we can frame for our example.
(Refer Slide Time: 43:05)

Let us frame another question RQ4, is the error rate within 1 hour of use less in our interface
as compared to MS Word? That is another question, which is of course testable. Another
question, testable question is does the number of features supported in our interface sufficient
to perform common tasks? In this case, we can ask the participants to provide feedback on a
rating scale of one to five, where 1 indicates not at all and 5 indicates totally agree.

Yet another testable question, can you remember the features easily on a rating scale of 1 to 5
where 1 indicates not at all and 5 indicates totally agree. Why we are calling it testable?
Because we are now collecting feedback on scales, it is not subjective opinions rather it is a
quantitative sort of feedback collected on rating scales.
(Refer Slide Time: 44:16)
Now, with these questions are RQ3, 4, 5, 6 we can capture different aspects of usability of the
system our interface, error rates, subjective satisfaction and memorability along with speed.
Now for each of these questions, we perform empirical research separately. Observations
made for each of these questions can lead to conclusion on the overall usability that is
whether the interface is good.

So, if we find that our system is faster, more satisfying, easier to remember, less error rate
then we can say that it is definitely good or it is better than other systems in terms of
usability. So, we can come to that conclusion based on the conclusions we have drawn on
these individual research questions. So, this is not possible with any one of the research
questions.

So, we need to frame multiple questions, conduct experiments for each of these questions,
draw conclusions for each of these questions and from those conclusions we can draw
conclusion on the overall question. So, we have multiple testable questions and with high
internal validity and for those questions we conduct experiments, perform empirical study
and draw conclusions.

And based on those conclusions, we draw conclusion for a generic question that is whether
our product is usable, whether it is good, whether it is better whichever is the generic
question which has high external validity. That is the way out, that is the way to balance the
tradeoff between internal and external validity of research questions between testable and
non-testable research questions.
(Refer Slide Time: 46:17)

Now, one thing is there. There is a positive correlation which seems to be obvious between
the testable questions and the untestable questions. We are likely to arrive at a generalized
answer for an untestable question from the specific answers to multiple testable research
questions, this correlation probably exists.
(Refer Slide Time: 46:43)

Because that correlation exists, we can then follow this approach where we can have multiple
testable questions and based on that we can draw a conclusion to the untestable question. So,
this is better than having only untestable question and user feedback which we have seen
earlier.
(Refer Slide Time: 47:09)
So, we will end this with a small note on the idea of hypothesis. So, what is hypothesis and
how it is related to empirical study because that terminology will be useful while you perform
empirical study and analyse the data. Testable research questions are more popularly known
as research hypotheses in the domain of behavioural research. So, they are similar in
meaning, testable research questions are generally called hypotheses, but in a different form.
(Refer Slide Time: 47:39)

We start our empirical study with two hypotheses, null hypothesis and alternative hypothesis.
Both originate from the same testable research question. So, we have one testable question
which can give rise to two hypotheses; one is called null hypothesis, other one is called
alternative hypothesis.
(Refer Slide Time: 47:56)
For example, let us consider RQ3 that is our system is faster, is our system faster than MS
Word? From there we can frame two hypotheses, one is called H 0, other one is H 1, H 0 is
called null hypothesis, H 1 is the alternative hypothesis. So, in H 0 we frame it as our design
is not faster than MS Word and H 1 we frame it as our design is faster than MS Word. So,
what this tells us?
(Refer Slide Time: 48:28)

One thing is we are no longer posing any questions, so question mark at the end of the
research question is gone, so it is no longer a question. Secondly, there is one important
difference that is a single question research question gave rise to two hypotheses. So, earlier
we are dealing with one research question, now we are dealing with two hypotheses which
originated from the same question.
(Refer Slide Time: 48:55)
In the null hypothesis denoted by H 0, we are essentially stating that the test condition is not
going to affect the outcome or in this case our judgment. So, the null hypothesis typically
states opposite to what we set out to establish that is effect of the test condition on the
observations, this is what we set out to establish and null hypothesis typically states the
opposite to that.

In contrast, the alternative hypothesis denoted by H 1 which state just the opposite. We are
stating that the test condition does affect outcome. So, then what is our goal for any empirical
study?
(Refer Slide Time: 49:48)

In an empirical study or alternatively empirical research, what we try to do? We aim to find
statistical evidence, now this is a very crucial time to note, statistical evidence to refute or
nullify the null hypothesis and support alternative hypothesis. So, the objective of any
empirical study is to find statistical evidence to refute or nullify null hypothesis and support
alternative hypothesis. Now statistical evidence is not the same as simple conclusion. It
requires proper analysis of data which we shall cover in a later lecture.
(Refer Slide Time: 50:33)

So, with that we have come to the end of this lecture. Here we talked about research
questions, the issues, nature of the question, testable versus non-testable, the tradeoff which
depends on the validity of the question. So, on the one hand we require questions with high
internal validity to make them testable, but on the other hand our overall objective is to
answer questions that are more generic having high external validity.

So, how to do that we discussed. The idea that we discussed is that we frame multiple testable
research questions to come to a conclusion about more generic non-testable question. And at
the end, we briefly talked about the idea of hypothesis, so that is similar to the concept of a
research question, but instead of research question which is a question as the name suggests,
hypotheses are not questions.

We have two hypotheses from one research question, one is null, one is alternative
hypothesis. Our objective in any research, empirical research or empirical study is to refute
null hypothesis and support alternative hypothesis with statistical evidence which is a special
data analysis technique that we shall learn in a later lecture. I hope you enjoyed the lecture
and understood the concepts.
More about this topic can be found in this book Human Computer Interaction chapter 7.
Looking forward to meet you all in the next lecture where we will continue our discussion on
the other stages of the empirical study. Thank you and goodbye.
 Design and Implementation of Human-Computer Interfaces
Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology – Guwahati

Lecture – 39
Experiment Design - 1

Hello and welcome to the NPTEL MOOCS course on design and implementation of
human-computer interfaces. We are going to start lecture number 33 where we are going to
start our discussion on another stage of the empirical study that is identification of variables;
this comes under experiment design phase. So as is customary before every lecture, we start
with a quick recap of what we have learned and where we stand at present in the context of
the overall course objective.

Now, in this course, we are going to learn about two things design and implementation of
human-computer interfaces. Human-computer interfaces, we have equated with a special
class of software systems that are called interactive systems. So, essentially we are interested
in two things, design and implementation of interactive systems. In order to achieve these two
objectives, we need a systematic approach.

For that purpose, we can follow a development lifecycle. We are currently discussing as part
of this course one such interactive system development lifecycle comprising of several
stages.
(Refer Slide Time: 02:09)
In this lifecycle, we have so far covered requirement gathering requirement gathering
analysis and specification stage. Outcome of this stage is software requirements specification
document. Then, we have covered the design stage for interface and interaction design,
outcome of this is a design document. This is followed by a prototyping phase where we
create prototypes for the design ideas that we have come up with.

Then, we go for weak evaluation of our prototype, so that we know whether there are any
usability issues. Now, this design prototype evaluate lifecycle continues till we arrive at a
stable interface and interaction design. This is followed by design of the code where we
create a code design document comprising of modules and the interfaces between modules.
We can use either DFT or UML languages to create the document.

Once the code is designed, we go for coding an implementation that is the next stage. So,
their outcome is the code of the system. This is followed by code testing where we test for
bugs that may be present in our code. At the end we produce a test report. The next stage is
empirical study where we study the usability of the end product. Currently, we are discussing
the empirical study stage.
(Refer Slide Time: 03:52)

We have already covered several lectures on empirical study. So, the basic ideas have already
been discussed. As we have seen the study is a systematic way of ascertaining usability of a
product. Now, it comprises of four stages, what are those stages? Identification of research
question that is stage number 1, this is followed by determination of variables stage number
2, this is followed by design of experiment stage number 3 and finally we come to the fourth
and final stage that is analysis of observed data or empirical data.
(Refer Slide Time: 04:35)

Earlier in the previous lectures, we have discussed the idea of the first stage that is
identification of a research question or framing of suitable research questions. Just, to quickly
recap why that is important. So, empirical study is all about performing a controlled
experiment, observe user behaviour in that experiment and come up with conclusion. Now,
the conclusion should be a reliable conclusion which can only be possible if the data that we
collect is reliable data.

To collect reliable data, we have to design, we have to plan a very systematic and scientific
experiment process where we will observe the behaviour and record the behaviour. In order
to know what to observe and what to record, we need to come up with appropriate research
questions. Earlier we have seen what happens if the research question is not appropriate and
how we can come up with an appropriate research question.

In this lecture, what we are going to do is we shall continue our discussion on the stages of
the empirical study and we will start our discussion on the next stage that is identification of
variables.
(Refer Slide Time: 06:06)
So, once the research questions are framed, we identify the variables. Now, just to quickly
recap, at the end of the previous lecture, we talked about the idea of hypothesis. What we
discuss there is that research question is one way of looking at things. Generally, what is done
is based on the research questions that we frame, we come up with hypotheses and then try to
refute or justify the hypothesis. For each question, there can be two hypotheses.

One is the null hypothesis which you wish to refute or nullify, the other one is alternative
hypothesis which we aim to establish. So, once the research question or the corresponding
hypotheses are framed, we need to identify the variables. Why the variables are needed to be
identified to observe and record one quantitative data. So, you want to record some data
quantitatively so that we can perform data analysis techniques on them to come to a reliable
conclusion about the outcome of the study.
(Refer Slide Time: 07:23)
In order to understand this problem, this issue, let us reconsider the earlier research question
that we have framed which we termed as research question 3, RQ3. What was that question?
Does the new interface let me enter text faster than MS Word that was the question we frame
and we seek answer to this question in the empirical study.
(Refer Slide Time: 07:54)

So, with respect to this question, what we need to do? We want to observe text entry speed
for this particular research question to answer this research question. So, here obviously text
entry speed is a variable and this variable can take values which are real numbers in this case
in the form of CPM or character per minutes, it can be CPS also that is characters per second,
WPM that is words per minute or WPS words per second.
So, any of these four variations we can use to record text entry speed. The basic idea is that
text entry speed is a variable that can take different real numbers as values and these real
numbers signify these things, how many characters were entered per minute or how many
characters were entered per second or how many words were entered per minute or how
many words were entered per second.
(Refer Slide Time: 09:04)

Another thing we can note here. Text entry speed varies with respect to interface. So,
interface can be considered to be another variable. So, we can take the interface as another
variable related to this research question and this particular variable the interface variable can
take as values different instances of interfaces, for example, our design can be one value, MS
Word can be another value.

Word Pad can be another value, any other text editor can be another value for this variable.
So, you have then two variables identified for this research question, one is text entry speed,
other one is interface.
(Refer Slide Time: 09:56)
Once we know the variables and their values, what we can do is we can set up test conditions
by varying the values systematically that is a crucial thing that we should remember that the
overall idea of identifying variables is to be able to set up test conditions that is assigning
values in a systematic manner to these variables.
(Refer Slide Time: 10:30)

And once we are able to identify different test conditions in a systematic manner, we can
perform the empirical study. So, empirical studies are done based on these test conditions. In
other words, identification of variables is necessary to be able to perform the study. Along
with the variables, it is also important to suitably define their values. So, what kind of values
they can take that also needs to be carefully decided and defined.
This brings us to the idea of measurement scales. We need to have some knowledge of
measurement scales to be able to suitability define the values of the variables that we are
going to use in our study.
(Refer Slide Time: 11:22)

So, what is this idea of measurement scales? In empirical research as we have repeatedly
mentioned, overall objective is to observe, in our case to observe user behaviour and record
the behaviour by some means. Now, there are broadly two ways in which we can record the
observations, what are those two ways?
(Refer Slide Time: 11:48)

One can be manual recording that means there is a human observer who is actually there in
the experimental setup where the study is taking place and manually recording the observed
data. Other can be automatic recording that is we can also record the observed data
automatically without the intervention of any human observer, how we can do that? With the
help of technology such as computers, different sensors, camera, logging software, etc.

So, these can also be used to automatically log or record the behavioural data instead of
somebody sitting there and manually recording the data. So, these are broadly two ways,
manual recording and automatic recording.
(Refer Slide Time: 12:48)

Now, when we talk of recording of observed data, it involves the idea of measurement of the
data. How do we measure and represent it?
(Refer Slide Time: 13:02)

We can do so, we can measure data using scales of measurement and there are broadly four
such scales that are available.
(Refer Slide Time: 13:14)

One is the nominal scale of measurement, what this scale implies? If we are going to use a
nominal measurement scale, then what we do is we assign some arbitrary codes to attributes
of observational data. So, some arbitrary code is assigned to the data for the purpose of
recording the data. For example, if we wish to record gender data in an empirical study,
instead of recording data in terms of male or female, what we can do is we may assign the
code 1 two male and 2 female.

Again, this is a very arbitrary assignment, so there is no particular logic inherent, but we can
do so, we can assign the code and then record the data in terms of the code, these two
numbers. So, whenever male needs to be recorded; we record it as 1, whenever female needs
to be recorded we record it as 2. The nominal scale of measurement also occasionally termed
as categorical data. So, whenever we are using nominal measurement scale and recording
data that data is sometimes called as categorical data.
(Refer Slide Time: 14:41)
Next scale of measurement is ordinal scale. Here what we do? We can assign some order on
the observed data with this particular scale. Let us try to understand this within an example.
We may observe performance say in terms of playing a game, it has defined the idea of
performance as a game playing experience.

So, we may observe performance of 3 mobile phones and record our observation by ranking,
introducing a rank among the 3 three phones by ranking those phones, that is their
performance in the form of first, second, third, etc. So, this first, second, third this type of
recording is using ordinal measurement scale.
(Refer Slide Time: 15:47)

Next is the interval scale of measurement. So, here what we do is we record observations in
terms of equally spaced values. So, in the interval scale of measurement, we use equally
spaced values to record our observations. For example, if you see a thermometer closely, you
may notice that there are some closely spaced marker or lines, each of these lines indicate
some value, for example 98 degree, 99 degree and so on.

So, the gaps between those values are same, so they are equally spaced. And if we are using
this to record our observation that is the temperature then we are actually using the interval
scale of measurement that is the third scale of measurement.
(Refer Slide Time: 16:36)

We also have a final and most sophisticated measurement scale that is ratio scale of
measurement. So, this scale uses ratio of two quantities to record observations. For example,
the idea of CPM or character per minute, so this is a ratio of two quantities, number of
characters typed and the minutes spent on typing. So, if we take the ratio of these two
quantities, then we get the data and here we can say that we are using ratio scale of
measurement. Now, ratio scale is considered to be the most sophisticated scale of
measurement.
(Refer Slide Time: 17:32)
It will be useful to note that the ordinal scale is heavily used for rating. So, occasionally we
need to rate various aspects of a design and the ordinal scale is primarily used for that
purpose. A popular rating scale is the Likert scale, it is named after its inventor Likert which
was invented way back in 1932 and the inventor was a psychologist who came up with the
idea of this scale. Likert scale is a very popular scale that is used for rating. So, there are four
scales of measurement; nominal, ordinal, interval and ratio.
(Refer Slide Time: 18:05)

Now, what should be our objective or what should we strive for while trying to choose a
particular scale of measurement? We should strive to use interval or ratio scale as much as
possible. So, whenever we are trying to design some experiment and need to record data, our
objective should be to design the experiment in such a way that we can record data either
using interval scale or ratio scale that will give us a better way of recording data.
Why we need to go for these types of scales? These skills support a wide array of analysis
techniques as opposed to the other scales. So, one objective of collection of data is to be able
to analyse them so that we can come to a reliable conclusion about the observations about the
system. If we use interval or ratio scale, then we will be able to employ a wide array of
analysis techniques on the data which can help us get to a reliable conclusion.

If we use the other scales, then we may not be able to use those techniques, so it will be
difficult to conclude. So, we should strive for using either of these two scales, ratio scale is
even better if we can manage with only ratio scale.
(Refer Slide Time: 19:45)

Now, one more thing that you should note here is that the ideas of the measurement scales are
important for the observed variables only. In fact, when we; are talking about variables,
different types of variables there. Now, the measurement scales are not required to be
considered for variables that are not observed that are controlled, we need to consider
measurement scales for observed variables only.
(Refer Slide Time: 20:13)
For example, let us reconsider the research question 3 that we have seen earlier. Now, one
variable there is the interface variable. It may come to you that for this variable; which scale
of measurement we should use? What should be the most appropriate scale of measurement?
Remember that interface variable takes value as different instances of typing interfaces. Now,
we may assign arbitrarily an integer to each interface. In other words, we will be using the
nominal scale of measurement as per definition of the nominal scale.
(Refer Slide Time: 20:55)

Then, we formed a research question having a variable that take nominal data. So, that is the
situation we are in if we choose to use nominal scale of measurement for interval variable.
Now, is that the right thing we did? Do we need to change the variable? These are maybe
some questions that may confuse our mind that may agitate our mind.
(Refer Slide Time: 21:24)
But the answer to both the questions is a big no. In fact, the questions themselves are not
relevant at all, we do not need to bother about the measurement scale for the interface
variable, why?
(Refer Slide Time: 21:42)

The interface variable is used to generate test condition that is we are assigning it different
values so that we can set up different experimental conditions. If we assign it the value of our
interface, our design; then we have one test condition where users will type with our design.
If we assign the interface the value of MS Word, then the users will get to type with MS
Word. So, we are essentially using the variable to generate test conditions by assigning
different values, but these assignments have nothing to do with observation of the values.
So, we are not going to observe anything, we are simply assigning So, interface is not an
observed variable. What we are observing in this case? We are observing text entry speeds.
So, text entry speed is the observed variable, not the interface. So, whether we use any
measurement scale or not for interface is irrelevant, we need not bother about that. What we
should bother about is what kind of measurement scale we should use for the observed
variable here that is the text entry speed.

So, the concern about the measurement scales applies only to the text entry speed variable.
Those are the basic ideas about variables. What is a variable, why we need it, what kind of
variables are there. How to decide on measurement scales for a variable. Which scale is good
and for which type of variable the scales apply. Now, let us learn a little bit more about
different types of variables.

Earlier we have broadly categorized them as observed variable and non-observed variable,
but that is not the right term to use, so we will use more popular frequently used terms. The
first such terms that we should know about are dependent variables and independent
variables.
(Refer Slide Time: 23:49)

So, variables are broadly of two types, one is called dependent variable, other one is called
independent variable. What are these variables let us try to understand.
(Refer Slide Time: 24:01)
Let us reconsider the research question 3. Now, we have considered two values for the
interface variable as we have mentioned earlier. One value is the; our design that is the GUI
that we have designed for text input, other value is MS Word an existing text input interface.
So, these two values we have used to instantiate the interface variable.
(Refer Slide Time: 24:32)

What is the purpose? We wish to observe text entry speed for each of these interfaces that are
for our design and for the MS Word interface.
(Refer Slide Time: 24:45)
Now, how we have arrived at these interfaces? How we have chosen these two values? We
assigned some values to the variable. By assigning values to the variables, we have arrived at
these two interfaces on which we are going to perform the study and observe the text entry
speed. So, essentially what we did? We controlled in a manner its values.
(Refer Slide Time: 25:12)

Such variables which are controlled by us, the experiment designers are known as
independent variables. So, the interface is an independent variable. Sometimes, in fact quite
frequently we use the term factors to denote these variables. So, either we can use the term
independent variable or we can use the term factors to denote variables that we are
controlling in order to generate different test cases.
(Refer Slide Time: 25:52)
So, when we are assigning values to independent variables or factors, those values are also
known as levels. So, if we use this terminology then in our example of the research question
3, RQ 3 we have one factor that is interface and we have two levels that is our design and MS
Word. So, each value is a level and the factor name is interface.
(Refer Slide Time: 26:24)

When we combine the factors with levels, we get the test conditions. So, factors combined
with levels give us test conditions for the experiment, which is the primary objective of
identification of variables. For example, observe text entry speed for a given text with our
design. So, here we are combining the factor that is interface with the level that is our design
to generate this test condition that is observe the speed for a given text with our design.
Since, we have one factor into levels, we can have two such test conditions in our example.
So, if we have supposed two factors and each factor can have two levels, then how many test
conditions we can generate, 2 into 2 equal to 4 such test conditions we can generate. So, by
multiplication we can get the number of test conditions that we can generate, multiplication
of factor and levels.
(Refer Slide Time: 27:36)

Now, the next question that may come to our mind is how do we set the levels for a factor?
How do you decide what are the values are to be assigned to an independent variable? There
can be many ways to do that. Such assignment may come from prior knowledge and
experience, we may already have some experience of doing that. Theoretical analysis of the
problem can also reveal that.

If all else fails, we might take recourse to a pilot study which is a small scale, typically
informal and unstructured, study to prepare for the bigger study. So, we may conduct a pilot
study to identify the levels of a factor that are going to be suitable for the particular study that
is about the idea of independent variables and its values.
(Refer Slide Time: 28:29)
The other type of variable that we mentioned is dependent variable. Now, in the research
question that is RQ3 another variable was used that is text entry rate or TER to decide
whether one is faster than the other. Now, this text entry rate variable depends on the
interface. In other words, as we change the levels of the interfaces, the rate is expected to
change. Since it depends on the independent variable that is the factor, we call TER as the
dependent variable, dependent on the independent variable.

So, that is the idea of dependent and independent variable. So, when we control the values to
generate test conditions, we control the values of a variable we call that variable as
independent variable. Often, such variables are called factors and the values they take are
often called levels. Depending on the number of factors and number of levels in each factor
we can compute by multiplying the total number of test cases that we can test, scenarios that
we can generate for our study.

And there is another category of variable that is the dependent variable which depends on the
factor and levels that is one set of terminology. Another set of terminology we should be
aware of is the idea of control variable and confounding variable. Let us see what are those
variables.
(Refer Slide Time: 30:17)
Let us start with the idea of the control variable. In a controlled experiment, we already
mentioned that we control independent variables, this is very important, assuming those to be
the only factors that influence observation. So, when we are setting up an experiment, we
generally assume that the values of the independent variables that we are controlling are the
only thing that needs to be controlled.

There are nothing else and these control values only influence the outcome, but we need not
be entirely correct, we may be wrong. There may be other factors that we are not controlling,
which can potentially affect the observations, which can influence the behaviour and affect
the observations.
(Refer Slide Time: 31:15)
For example, in our earlier research question 3, we assumed that only the interface
independent variable or factor affects the dependent variable that is the text entry rate. But
then what about another factor say user gender, speed of a male user may differ from a female
user, quite possible for the same interface, we have no knowledge and we have not explicitly
taken into account this factor.

So, it can be a potential factor, but we are not controlling it. So, later on the data that we
record may be biased, how? Say in our experiment we only considered male participants to
collect data vis-a-vis conducted another experiment where we considered majority of male
participants and few female participants. In a third way, we can consider majority of female
participants and few male participants and in another case we can consider only female
participants.

We do not know what kind of participants we are going to use because we have no idea that
the gender of participants can affect the potential outcome. So, we may miss this factor and
its influence on the outcome.
(Refer Slide Time: 32:41)

But if we know gender is a factor, then we may treat it as another independent variable and
add it to our list of factors that is possible.
(Refer Slide Time: 32:52)
There is another way of looking at it. We may not be interested to know the effect of gender
on speed, although we know that gender may affect the speed, but we are not interested to
know how it affects unlike the earlier case where we are interested to know how a design
affects the speed. So, in that case what we can do? We need not consider it as a factor as a
variable, we need not vary it.
(Refer Slide Time: 33:24)

Rather, what we can do is we can use it as a control variable with a fixed value. Although we
are using the term variable, we do not vary it, we keep it fixed. For example, in our
experiment what we can do is we may use only the male participants or only the female
participants, but not a mix of them. So, in that case we are fixing the value of gender to a
fixed value that is either male or female.
Therefore, we set the factor gender to male if we use only male and use the setting for the
whole experiment, so essentially we are treating this variable as a constant, although we are
calling it control variable, but we are treating it as a constant value.
(Refer Slide Time: 34:11)

Now, this can solve our problem of not complicating the experiment, but this introduces
another problem which we should be aware of that is any conclusions that we draw based on
the data that we collect from only male participants will be applicable for male participants
only. So at the end of the experiment, we collected some data about this speed and then
decided to analyse it.

And concluded that our design is faster than MS Word based on data collected from only
male participants then our conclusion will be applicable only for male participants. It may
change for female participants because in our experiment we are not considering gender as a
variable rather we are fixing the value of the gender value. So, conclusion will also be
accordingly applicable only to the fixed value of the control variable that is about the idea of
control variable.

Where although it may be an independent variable or a factor, we are not treating it as a

variable explicitly, instead we are fixing a value of this variable and using that value
throughout our experiment. So, in other words we know that that can be affected, but we are
not interested to know the relationship between that factor and the outcome.
(Refer Slide Time: 35:13)
Another group of variables is known as a confounding variable. Sometimes what may happen
is that we may not even be aware of the existence of factors other than those we already
identified. So, earlier we said that there are factors that affect the outcome that is the
dependent variable. First, we learned about independent variables that affect the outcome.
Later on, we learned about control variables that may affect outcome.

So we are fixing their values, all these assume that we are already aware of them. Now, it
may so happen that we are not even aware of presence of some variables that may affect
outcome, so then what will happen in that case? The outcome that we get without knowing
that there are other variables at play may not be the exact outcome that we are looking for.
Let us see one example.

A very common example is the factor called the practice effect or the learning effect. This is
one such variable whose presence we often do not recognize, but it affects the outcome. What
is this?
(Refer Slide Time: 36:50)
In the experiment for RQ3, research question 3, suppose a participant sees the two interfaces
in a particular sequence. After typing with the first interface participant gathers some
experience of typing with the first interface and grows some expectations about the nature of
the interfaces because some tasks have been performed with the first interface. Now, this
experience and expectations potentially affects the way the participant types with the second
interface.

Now, while typing with the second interface, the participant expects that the feature should be
at a particular place or the layout should look something like this or the icon should be
something like this because already the participant has experienced similar things with
another interface. So, that expectation may affect the performance, participant may spend
some time looking for such things, then realizing that this is a different thing, so eventually
his or her speed of entry may get affected. So, this is called the practice effect.

So, we practiced with one thing and gathered some experience with that thing, then next
when we are asked to do or perform some tasks with some other interface, then the effect of
the practice with the first interface may affect the outcome with the second interface, this is
the practice effect or the learning effect. We have learned the first interface and expect the
second interface to be similar to the first one, although they are different and this affects the
outcome.
(Refer Slide Time: 38:43)
Now, practice effect varies with test conditions in a systematic manner, although we are not
taking into account this variation. So, when we design the experiments, we often miss to
recognize that there is this thing called practice effect and we design test conditions in a way
where the practice effect may vary systematically. So, this is an example of a different type of
variable called confounding variable. What are these variables?

We are either not aware of these variables or do not take into consideration their existence in
spite of them influencing observations. So, in case of control variables we know that they
exist and we control them by fixing their value. In case of confounding variables, we are not
aware of their existence or are not taking explicitly into account their presence in spite of
those variables affecting the outcome.

Of course, the question may come to your mind that if such is the case, if they are
confounding variables and we are not taking care of those variables, then how reliable will be
the data, the observation because as I said confounding variables may not be known to us, so
how do we take care of it? There are some common confounding variables such as the
practice effect, we already know they exist.

So there are ways to take care of those variables and in subsequent lectures we shall learn
about a method to deal with the practice effect. But, of course, in general if we are not aware
of the presence of any arbitrary confounding variable, then it will be difficult to take care of it
and the conclusions that we draw may be biased and may not lead to a reliable conclusion.
So, in this lecture we have learned few things.
We are discussing the second stage of the empirical study that is identification of variables.
So, what we have learned? First of all what is a variable, why it is needed? Then we learned
about measurement scales and why that is important. So, there we broadly saw that we need
to bother about measurement scales only four variables whose values we are observing rather
than variables whose values we are not observing.

Now, broadly we have divided variables into two groups, dependent variables and
independent variables. Independent variables are also known as factors and the values that
they take are known as levels. Whereas dependent variables are those that are dependent or
the value of those variables are dependent on the independent variables and their values. We
have also talked about control variables.

That is there are some variables which we are aware of which we know that they are present
and they affect the outcome, but we are not interested to know about how they affect
outcome. So, in that case, we simply fixed their values, we treat them as constants, those are
called control variables. And also, we discussed about an important class of variables,
confounding variables.

These variables are more difficult to handle, we may not be even aware of their presence.
However, there is a very common confounding variable that is called practice effect or
learning effect. And later on, we will see how to deal with such a variable.
(Refer Slide Time: 42:39)
Whatever I discussed in this lecture can be found in this book Human-Computer Interaction,
you can refer to chapter 7. I hope you have enjoyed the content and understood the concepts
that we covered today in this lecture. We are going to continue our discussion on the
empirical study, the other stages of the study, namely the experiment design stage and the
data analysis stage. That is all for this lecture. Thank you and goodbye, looking forward to
meet you all in the next lecture.
 Design and Implementation of Human-Computer Interfaces
Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology – Guwahati

Lecture – 40
Empirical Usability Evaluation - 2

(Refer Slide Time: 00:56)

Hello and welcome to the NPTEL MOOCS course on design and implementation of
human-computer interfaces. We are going to start lecture number 34 where we will continue
our discussion on how to design experiment. So, before we start like we do for every lecture
we will quickly recap what we have learned and where we are currently in the overall course
and then we will go to the subject matter of this lecture.

So, we are discussing the interactive system development lifecycle containing several stages.
We have covered most of the stages in the previous 33 lectures including case studies related
to the outcome of the stages. So, let us quickly recap what are the stages that we have covered
and what we are currently going to cover. So, we have covered the first stage requirement
gathering analysis and specification. We are assuming this to be the first stage, although in
principle feasibility studies should be the first stage.

However, as we mentioned earlier, we will ignore feasibility study in this discussion and
assume that the lifecycle starts with the requirement gathering stage. So, we covered that in
details. Next, we covered the design stage, design of interface and interaction. This was
followed by the prototyping stage. How to create prototypes, followed by the evaluation of
prototypes, how we can quickly evaluate prototypes, poor usability issues.

And this form the cycle which we need to perform probably many times before we finalize on
a stable interface and interaction design. This was followed by design of the code or code
design stage followed by the coding and implementation stage where we have learned about
how to use good code practices for implementing the system. Next, we covered the code
testing phase, there we learned about different ways to test our code to find out bugs in the
code and to come up with an error free code.

Currently, we are discussing the next stage that is the empirical study stage. We have already
covered basic concepts of the stage and we are going to continue our discussion on the
empirical study in this lecture as well. Just to recollect empirical study in the context of
interactive system design refers to the fact that in order to identify usability issues with our
end product the interactive software after code testing, the testing does not stop, we need to
test for usability.

Now, we do that in the empirical study stage where we set up controlled experiment, imply
some end users, collect behavioural data of the end users while they use the developed system
and we analyse the data to come to a conclusion about the usability of the system. Now, the
empirical study broadly consists of four stages as we have mentioned in the earlier lectures.
(Refer Slide Time: 04:12)
Stage number 1 is identification of research questions, what do we do in this stage? In this
stage, we first identify a suitable question for which we perform the study. So, a study means
we are trying to seek answer to some question, those questions are called research questions.
Unless we are able to identify suitable research questions, it will be difficult to proceed
further in the empirical study.

It will be very difficult to set up the experiments and collect data. So, the very first and
essential step is to identify suitable research questions. Also, it may be noted that generally in
literature you will find that instead of research questions in empirical study we try to deal
with hypothesis. So, they are essentially the same concept, a research question leads to two
hypothesis, null hypothesis and alternative hypothesis.

In the null hypothesis, we try to say something that is opposite to what we want to establish
and an alternative hypothesis we say something that is what we want to establish. Our
objective is to statistically refute or establish either of the hypothesis. So, either we refute the
null hypothesis based on statistical evidence or we establish the alternative hypothesis based
on statistical evidence that is how we proceed.

The next is determination of variables. This is also very important to let us know exactly
what we are going to observe and measure. So, unless we are able to identify the variables,
we cannot decide what to observe and how to record, so identification of variable is the other
crucial component that we should take care of. Third is the design of experiments. So, once
research questions or hypotheses are framed and we are able to identify the variables, we go
for design of the experiment.

And finally, we analyse the observed data. In this lecture, we are going to discuss the third
stage design of experiment.
(Refer Slide Time: 06:36)
So, in the earlier lectures we have already covered the first two stages that is identification of
suitable research questions as well as identification of variables. In this lecture, we are going
to concentrate on how to design the experiment, what are the issues involved, how to
overcome those issues and how to come up with a suitable design of the experimental
procedure that we are going to perform to collect behavioural data? So, we are going to talk
about experiment design in this lecture.
(Refer Slide Time: 07:09)

Let us try to understand why experiment design is important. Let us revert back to our earlier
example, the research question 3. Now, we have already identified a testable research
question RQ3. Remember, the question is testable if we can measure the dependent variables
in a quantitative manner. We also have identified the factors or the independent variables and
the levels or the values of those variables for that research question that is the two types of
interfaces that we considered, that is our design and existing design in the form of MS Word.

So, because there were two levels, so there were two interfaces that we used for our study.
Now, the first two stages are done. So, we have identified the research question and we have
identified the variables, what we should do next? Of course, our objective is to answer the
question that which of the interfaces is faster? So, if this is asked of you that now try to find
out the answer to this question, what you will do?
(Refer Slide Time: 08:42)

Most likely, we will follow the easiest way that is we will rely on our close friends to get
participants who will participate in the study, who will be asked to perform the tasks and
generate their typing speed data. So, of course we require participants and we approach our
friends assuming that to be least problematic to get the data. So, you have asked 5 of your
friends to participate.

To each of these friends you show the two interfaces and ask them to type, you have given
them the typing tasks. Then you record it the typing speeds. And with that you got your
empirical data based on which you can come to a conclusion. Sounds pretty simple,
straightforward, and not much hassle. Of course, you have to somehow convince your friends
to do these things which seemingly is not very difficult if you have good friends.
(Refer Slide Time: 09:58)
So, it sounds quite logical and straightforward, is not it? Unfortunately, there are many issues
with this seemingly straightforward approach. Apparently, it may seem to you that you have
followed all the stages. So, you have framed the research question, you have identified
variables, then you have conducted the experiments by collecting participants that is your 5
friends and ask them to carry out the tasks and recorded their data.

And finally based on the data you analysed and come to a conclusion. So, apparently you
have followed all the stages, which we mentioned earlier. Then can there be any issues? Was
there anything wrong? There can be several issues with this seemingly straightforward
approach, let us try to understand those issues. What can be those issues which are of concern
to us?
(Refer Slide Time: 11:13)
First thing is participants, let us see why choice of participants is very important. When you
asked your friends to participate in the experiment and perform the tasks, you did not
consider one thing. So, your friends are likely to belong to same age group with similar
background, it is very rare that we choose friends who come from a very diverse background,
generally our friends are of similar background in terms of education, socioeconomic
conditions and cultural background.

Also, they are likely to be of same age group. So, we can usually term these people, these
friends, the group of 5 friends to belong to a homogeneous user group that means a group
having similar characteristics. Older people on the other hand may have different typing
behaviour than teenagers. So, your friends assuming to belong to a particular age group,
person from a different age group may behave differently which your friends will not be able
to replicate.

For example, older people are likely to have different typing behaviour than teenagers. It is
also likely that typing speed is different between a regular computer user and an infrequent
user of computers that is another common sense knowledge that if your friends are regular
computer users they are typing speeds are likely to be different than someone who is not a
regular computer user. So, there are several issues with the choice of the friends as
participants.
(Refer Slide Time: 13:01)

So, essentially, what we are referring to here is that we are talking of user profile. So, when
we choose participants, we should be aware of the profile of the users. This is more popularly
called user profile and this term occur very frequently in the relevant literature. So, you
should be aware of this term user profile. So, when we develop a system, we develop it for a
group of users. As we have already mentioned earlier usability is applicable only for a
specific group of users. Now, that group of users should have specific characteristics, which
we call usually and popularly as user profile.
(Refer Slide Time: 13:47)

When we choose the participants for our experiment, definitely the profile of the participants
should match with the profile of the intended user group of the system. Now the user profile,
maybe factors that means independent variables. We may like to use them as independent
variables or factors in our study. We may like to know the relationship between different parts
of the profile, different characteristics in the profile and the outcome.

For example age, gender, economic background, cultural background, educational

background, each of these can be a potential factor which can influence the outcome. So you
may like to use them as factors as well.
(Refer Slide Time: 14:40)
The problem is there can be a very large number of such factors which will in turn lead to a
large number of test conditions. So, we have to carry out experiments for quite some time for
a large number of test conditions, so that will increase the complexity of the experiments. In
order to keep our experiments simple, what we can do is we may like to keep them out of
consideration, keep those factors out of consideration.

That means we may not like to vary them, instead we may like to use them as control
variables, we like to use them as constants throughout the duration of the experiment. So, we
will fix their value. At the same time, we should take into account their effect on observation.
Of course, we should be aware that these variables may affect the observation, so we should
be very carefully controlling them.
(Refer Slide Time: 15:39)
As I said, we can do so by treating them as control variables, earlier we have seen what is a
control variable. These are variables which we use as constants that means we do not let them
take different values instead during the experiment we fix the value for them so that it
becomes a constant. So, the user profile also can be used as a control variable by fixing the
profile characteristics.

For example, we may decide to have a specific user group that is teenagers, so we are fixing
the age group. Also frequent users of computers, so we are fixing the experience. Suppose,
we are fixing these two, so we are essentially using the two independent variables, namely
the age group and the experience as controlled variables with fixed values. Now, if we do
that, then we can roughly say that our friends may fit this profile.

So, in order to make your friends fit the profile, we probably need to analyse the situation a
little bit more, try to identify the control variables, fix their values so that those matches with
our friends’ profile. So, then apparently it may seem that the problem gets resolved. So, we
have chosen now a participant who belongs to the intended user group, although they do not
represent the whole group, they represent a part of the group.
(Refer Slide Time: 16:59)

So, what is the downside? The major downside is that they do not represent the whole user
group. So, if you are approaching your friends and asking them to be part of your experiment,
then you cannot claim that the conclusions that you draw based on those experimental data is
applicable to any user belonging to that intended user group. At most, what you can do? You
can say that you are concluding for only those users whose profile matches with those of the
participants.

So, what we just discussed is that when we talk of a system it has a specific group of users.
Those users are characterized by their profile. When we choose the participants to perform
empirical study, we need to match the user profile with the participant’s profile. If we do not
match, then another way out is that we treat some of the profile characteristics as control
variables and fix their values so that the participants’ profile matches with the design that is
fixed values for the control variables.

But in that case, whatever data we collect and conclusion we draw based on those collected
data are not applicable to the entire user group. Those are applicable only to those users
whose profile matches with the participants’ profile. This is a very important thing that you
should keep in mind while choosing your participants. That is about profile of the participants
and whether those matches with the user's profile.
(Refer Slide Time: 19:05)

The other important issue that we should be aware of is number of participants. So earlier, we
loosely say that let us approach 5 friends who will produce the data which we will use for
analysis. But is that number 5 a good number of participants? Remember our objective is to
come to a conclusion which is reliable. So, from the 5 users suppose we generated the data
and we analysed that data to come to a conclusion. Can we say that those 5 users’ data will
lead us to a reliable conclusion.
Later on, we will see that the data analysis that we perform on the observed data relies on
statistical methods, so the number of participants and the corresponding amount of data that
they produce should have some statistical significance. Now, what is a good number then?
Should we go for a bigger number, say 10 to have the statistical significance of the data? Is
that sufficient or we need even bigger value? These are some of the questions that we should
be aware of and we should take care of.
(Refer Slide Time: 20:36)

Unfortunately, there is no definite answer to this question. We cannot say with certainty that
so and so number of participants produces enough amount of data that can be used for
reliable conclusion, so there is no definite answer to this question. According to one estimate,
note that it is only estimate, 5 participants are good enough for empirical research, although
there are alternative views as well; that means 5 participants are not good enough for
empirical research.
(Refer Slide Time: 21:18)
In fact, more studies have revealed that 5 is not a good number and we need to employ more
participants. Again, unfortunately studies could not converge to a single number. So, although
studies have revealed that data generated from 5 participants did not lead to a reliable
conclusion, none of the studies could definitely say or agree on a single number. So, different
studies tell us about different numbers.

So, what we get from the literature is a range of numbers instead of a single number between
5 and 25 both inclusive. So, essentially what it says is that the number of participants should
belong to this range 5, 25; at least 5, at most 25 and both these numbers are included. So, we
should have at least 5 participants or at most 25 participants to get reliable data for reliable
conclusion.
(Refer Slide Time: 22:37)
For any pilot study, that is small-scale studies that we have mentioned in the earlier lectures,
5 is probably a good number. So, if you want to conduct a pilot study or a small-scale study,
then probably you can settle with 5 participants like asking your 5 friends. However, the
conclusions that you can draw from the data from those 5 participants or less or nearby
number of participants say 5 or 6 may be treated as indicative and more studies may be
required.

So, you cannot, ideally you should not conclude based on the data collected from 5
participants about the overall behaviour of the users. Instead, at most what you can say is that
what is revealed by the data is indicative of the behaviour and more studies may be carried
out to come to a definite conclusion.
(Refer Slide Time: 23:43)

To draw a reliable conclusion from empirical data, we should probably use between 12 and
25 participants both inclusive. That means, within this range of 12 at least and 25 at most.
Although 12 is the lower limit, but more is better. So, that is what literature tells us that with
5 participants we may carry out pilot study for initial indicative conclusions and we may
carry out more rigorous empirical study with between 12 to 25 participants, the more the
better, that means closer to 25 probably is a good number.
(Refer Slide Time: 24:27)
One thing you should note here is that these numbers are suggestive only. Based on some
studies these numbers were found. It does not mean that you cannot employ more
participants. So, if you wish to have more participants in your study, if you manage to get
more participants, you can go ahead, no need to bother about this upper limit. However, it is
less likely that you will get different conclusions with more numbers than the ones already
got with the numbers suggested.

So, that means whatever conclusions you can draw based on the number of participants
between 12 to 25 and whatever conclusions you are going to draw if you imply more
numbers are not likely to be significantly different. So, you may not get a large number of
significantly different conclusions from larger number of participants. So, essentially what it
tells us is that between 12 to 25 is a good number, you can do most of the things with this
number that lies within this range.

Of course, here it is suggested to have higher number of participants within this range that
means around 25, but if you employ more participants then whatever conclusions you may
get may not be significantly different than whatever you can draw with up to 25 participants.
So, that is about answering two major issues if you want to go for experiment design that is
how to choose the participant profile and how to choose the number of participants. Let us
move our focus next to another issue for experiment design that is designer tasks.
(Refer Slide Time: 26:25)
In order to observe the user behaviour in our case, what do we do? We are supposed to ask
participants to perform some tasks, some tasks that can be performed with the interface and
interaction. In our example, the tasks can be typing of text strings. So, the typing task is one
task that we asked our participants to perform to answer RQ3. So, it is very important to
decide appropriate tasks before you go for the experiment, otherwise observed data may not
be useful. So, unless you have carefully designed your tasks, the data that you may get may
not be useful.
(Refer Slide Time: 27:19)

An interface may support a very large number of tasks depending on the number of features
that are present on the interface. Now, it is typically not necessary to ask participants to
perform all these tasks. In fact, an interface may support a very large number of tasks.
Consider the tasks that are supported by a text entry editor that is MS Word, enumerating all
the tasks is a really humongous job and it will result in a very large number of tasks.

So, when we say that to carry out experiment, you first need to identify the tasks
appropriately. Does that mean that whatever tasks are supported by the interface we have to
identify and then accordingly we have to set up the experiment? Not necessarily so. Number
of possible tasks with an interface may be very large, but we do not need to ask participants
to carry out all the tasks, rather we do not need to design our tasks so that all these tasks can
be carried out by the participants that may be impractical for many real-life systems.

As the number of tasks is very large, so it will take very large amount of time of the
participants to complete the tasks, the participants may not like to do all these tasks for such a
long time and they may quit in between. So, whole experimental process may become
problematic to carry out.
(Refer Slide Time: 29:04)

So, instead of that, what you can do is you can ask participants to perform a set of
representative tasks. Remember we introduced this term earlier where we said that a
representative task is such a task which is expected to be performed by the users frequently in
a real usage scenario. So, not all the tasks supported by an interface are done frequently by
the users, few of those are frequently done and those few are the representative tasks.

So, our job is to identify those representative tasks and ask users to perform those
representative tasks only. For an example, let us consider this typing situation. So we want to
compare the two interfaces know which one is faster up, one is our design, one is MS Word
design. So, here what can be representative task? There can be several tasks like save a file,
open a file, type in a file, type on the screen, delete, add, etc.

But, how can we choose a representative task? Of course, when we are talking of text input
tasks, the representative task is nothing but typing a text string, but what kinds of text string?
Is it single character typing, a set of 5 characters that need to be typed? A full sentence to be
typed? A full paragraph? Many possibilities are there, but what type of typing we should
consider to be representative?

For that we can perform actually a statistical analysis technique on a corpus and find out a
string that is commonly typed in real life situation for a particular language and that string we
can ask the users to type during their typing session. So, during experiment we are going to
give the user a specific string obtained through statistical method from a purpose of text
which is likely to be typed frequently.

May not be the exact text but those characters and their relative positions with each other are
likely to be typed by the users in real life situations that is a representative typing task for the
particular experiment that we are using as an example.
(Refer Slide Time: 31:51)

So, there were two test conditions for our empirical study related to RQ3 corresponding to
two interfaces. So, we should design at least two tasks and ask participants to perform these
tasks.
(Refer Slide Time: 32:07)

So, the next question is once we are able to identify the representative task, there are 5
participants, two interfaces. The next relevant question is how do we ask the users to type the
tasks for those interfaces? All the 5 users are supposed to perform the tasks for both the
interfaces.
(Refer Slide Time: 32:29)

So, how do we assign these tasks? Before that we need to know about some terminology that
is within-subject design or also known as repeated-measure design and between-subject
design. So, what is within-subject design? When each participant in a study performs the
tasks corresponding to all the test conditions, we call the study designers within-subject
design or alternatively repeated-measure task design.
So, in our example we have two interfaces, 5 participants, each participant was asked to
perform tasks on both the interfaces, so all participants perform the same way. So, our
particular study design we can call repeated-measure or within-subject design.
(Refer Slide Time: 33:27)

But that need not be the only way we can assign tasks. Sometimes there can be a problem.
Let us assume that the number of test conditions that is the interfaces are 10. The number of
test conditions is 10 that means there are 10 interfaces, so each participant has to type on 10
interfaces. Now, if we ask our participants to type on those 10 interfaces, then they may
object, they may simply say that we do not want to type for so many interfaces.

They may refuse to perform those tasks that is the text entry tasks for so many interfaces that
is quite possible. Participants are after all human. So, if you ask them to do too many things,
they may simply refuse to do that.
(Refer Slide Time: 34:23)
In that case, what we can do? There are two ways to resolve these issues.
(Refer Slide Time: 34:27)

So, we may introduce breaks in between the task sessions for each participant. So maybe we
can design the experiment in this way that there are several sessions for performing the tasks.
In the first session, a participant performs with two interfaces. Then there is a gap, maybe 1
hour gap, then another session with two more interfaces, in that way total 5 sessions for 10
interfaces. So in that case, the participants may not feel the burden and the sessions can be
spread over multiple days as well rather than on a single day that can be a straightforward
solution.
(Refer Slide Time: 35:13)
For example, a participant performs the tasks over a period of two days. First day, 5
interfaces, maybe over 3 sessions which is a manageable number. And the rest performed on
the next day again over 3 sessions or maybe a different day with 1 day gap in between;
anything is possible. So, these are manageable numbers and participants may not refuse in
such cases.
(Refer Slide Time: 35:41)

Otherwise, we may ask each participant to perform text entry tasks for only a subset of the
interfaces. So, that is another way to do things. So, not all the participants are performing for
all the interfaces, a participant is performing only for a subset of the interfaces.
(Refer Slide Time: 36:04)
Suppose we have 20 participants, we divide them into four groups. So earlier instead of 5,
now we have 20 participants, we divided them into four groups, so 5 participants in each
group. We ask each group of participants to perform tasks only for 5 interfaces. So, there are
total 10 interfaces, so each group performs only for 5 interfaces. So, then each participant in a
group performs the tasks for all the 5 interfaces.
(Refer Slide Time: 36:42)

If we design our experiment in this way, that means we assign the tasks in this way then this
is called a between-subjects study. That means when we distribute the tasks to the
participants in such a way where not all participants participate in all the test conditions, then
such a study is called between-subject study. So, we have within-subject or repeated-measure
study design as well as between-subject study design.
These are related to how we distribute the tasks to the participants. If the numbers are
manageable, then within-subject is fine, if the numbers are not manageable then
between-subject can be used.
(Refer Slide Time: 37:23)

It may be obvious that within-subject designs are easier to manage. But the problem with
within-subject design is that they are maybe the practice effect. So earlier we introduced the
idea of practice if that is the sequence in which the tasks are performed by a participant or a
user can induce some expectations or goals within the users’ mind and because of that in
subsequent task conditions, the outcome may get affected that is the practice effect as we
discussed earlier in the previous lecture.

So, within-subject design although manageable, easier to manage, may lead to practice effect
because all participants are taking part in all the test conditions. On the other hand,
between-subject design reduces the practice effect, but then combining the data may be
problematic because not all participants are participating in all the test conditions. So, both
have positive as well as negative issues, pros and cons. So, it is not easy to decide on the right
design, which one we should go for within-subject or between-subject.
(Refer Slide Time: 38:49)
The decision depends on availability of participants. Typically, between-subject design
requires more participants. So, if we have more participants and more test conditions, then we
can go for between-subject design. Even if participants are available, they may not be able to
participate for long that may be another condition, within-subject design requires longer
involvement of the participants.

So even if we have less number of participants, participants may not be available for long
maybe because of their professional commitments or physical abilities, they may not be able
to participate for all the test conditions. So in that case, we have to go for between-subject
design rather than within-subject design, although the number of participants may be less. It
also depends on availability of other resources such as study assistants, computers, laboratory
space and so on.

Definitely all these are supporting infrastructure that are required to carry out the empirical
study. So, if they are available in sufficient quantity that determines what kind of study we
can design.
(Refer Slide Time: 40:06)
So, it is necessary to carefully consider these issues and balance the tradeoff between the two
design approaches, within-subject and between-subject.
(Refer Slide Time: 40:17)

Now, if we go for within-subject then there is the issue of practice effect. So, to avoid the
practice effect in within-subject design, we can employ one technique that is called
counterbalancing. So, what we can do is we can counterbalance the sequence in which the
tasks are given to the participants. So, task sequence for each participant is different from the
other participants in that counterbalancing technique.

So, we do not provide the same sequence to each of the participants, for each we change the
sequence so that practice effect is statistically minimized.
(Refer Slide Time: 41:00)
So, how we can implement the counterbalancing technique? We can use one popular
technique that is randomizing the sequence for each participant. Now, of course
randomization does not always lead to totally different sequence, it may lead to similar or
partially similar sequence as well.
(Refer Slide Time: 41:23)

Another way to address this is to use a more systematic method known as the Latin Square
method. In this method, what happens? We organize a sequence of tasks given to the
participants in the form of a square matrix with the condition that each task occurs only once
in each row and column. So, we form such a square matrix where each task occurs only once
in each row and column. If we can frame such a matrix, then we can assign tasks following
the matrix. Let us see one example.
(Refer Slide Time: 42:06)
Let us assume that there are 4 participants, participant number one 1 to participant number 4
and each of them performs the text entry tasks for 4 interfaces. So, there are 4 participants
and 4 interfaces. So, each participant then performs 4 tasks numbered R1 to R4. Now, the
question is how do we assign these tasks, in what sequence each participants get these tasks?
If we follow the Latin Square method, how can we form the square and how the tasks are
assigned?
(Refer Slide Time: 42:41)

This can be a possible assignment. So, P1 gets the task in the sequence R1 followed by R2
followed by R3 followed by R4. Then P2 gets the tasks in this sequence R2 followed by R3
followed by R4 followed by R1. P3 gets a different sequence R3 followed by R4 followed by
R1 followed by R2 and P4 gets yet another sequence that is R4 followed by R1 followed by
R2 followed by R3.
So, does it satisfy the condition that each row and column contain the task only once? Let us
consider this row. So, here each task appears only once, so it satisfies the condition. And what
about this column? So, here also we can see that each task appears only one, so it satisfies
that condition. Similarly, this column also each task appears only once, in the third column
also it holds, in the fourth column also it holds.

Similarly, second row it holds, third row it holds and fourth row also it holds. So, this is an
example of a perfect Latin Square to assign tasks in a within-subject design to avoid practice
effect and to implement counterbalancing. So, counterbalancing can be done in two ways,
either we can randomize which may result in similar task sequences or to follow a more
systematic method such as the Latin Square method.

So, these are the things that we should consider in the third stage of the empirical study that is
how to design experiments. So, just to recap what we have learned here experiment design is
not easy. It involves considerations for lots of issues. First issue is what kind of participants
we should employ for our study. The idea is that the participants’ profiles should match to the
intended users’ profile.

If the match is not there, then whatever conclusions we draw are applicable only to those
users whose profile matches with the participants’ profile. Second issue that we need to deal
with is the number of participants what should be a good number to collect data. As we have
seen 5 is a number suggested for carrying out pilot studies, but for a proper study we require
between 12 to 25 participants, the more the better.

So, a number around 25 is probably a good number. Third issue that we need to consider is
what kind of assignments it should follow. So, there are two ways we can design the
experiments, one is within-subject, one is between-subject. In within-subject design also
known as repeated-measure design, what we can do is we can ask each participant to
participate in all the test conditions.

Now, if the number of test conditions are large or the participants have some problem,
physical or professional, then probably that may not work., so we have to go for
between-subject design. In between-subject design, we do not ask each participant to
participate in all the test conditions rather a subset of test conditions. Each design has its own
pros and cons. If we go for within-subject design, then there is an issue of practice effect.

So, to avoid that we can go for either randomization of the task sequence in which the tasks
are assigned to the participants or we can use systematic methods such as a Latin Square
method. We have also talked about how to design tasks because tasks are important
considerations in empirical study. So, we should be very careful in designing tasks, we should
focus on representative tasks and design those tasks to be given to the participants.

I hope you have understood the concepts and enjoyed the content of this lecture. So, we will
continue our discussion on the empirical study in the next lecture as well. So, far we have
covered three stages, remaining stage is data analysis which we will take up in the next
lecture. Looking forward to meet you all in the next lecture. Thank you and goodbye.
(Refer Slide Time: 47:25)

The material that we have covered today can be found in this book Human-Computer
Interaction, chapter 7. That is all for this lecture. Thank you and goodbye.
 Design and Implementation of Human-Computer Interfaces
Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology – Guwahati

Lecture – 41
Empirical Data Analysis

Hello and welcome to the NPTEL MOOCS course on design and implementation of
human-computer interfaces. We are going to start lecture number 35 where we will continue
our discussion on the empirical study, the remaining portion of the discussion on empirical
study. As is customary before we start let us quickly recap what we have learned so far and
where we are now.
(Refer Slide Time: 01:08)

We are discussing interactive system development lifecycle, human-computer interfaces on

interactive systems and when we try to develop them, we follow a particular stage wise
approach which we are calling interactive system development lifecycle. It contains several
stages. Each stage produces some outcome document. So, we have covered so far most of the
stages that includes the requirement gathering, analysis and specification stage.

In this stage along with customer requirement, we also capture or gather and analyse the
requirements of the end users from the point of view of usability, which is very important
concern for interactive system development. Outcome of this stage is SRS or software
requirement specification. Next, we have covered design stage, here primarily focused on
interface and interaction design, outcome is a design document.
Then we covered prototyping, how to make prototypes out of the design document, what are
the different types of prototypes, all these things we have covered, outcome is the prototype.
Next, we covered quick evaluation of prototypes. Now, this evaluation is with the primary
aim of unearthing usability issues. But here the evaluation is done by primarily quote unquote
experts who are domain experts and here end users may not be part of the evaluation process,
but it gives us a quick way of getting usability issues.

If usability issues are found, we can refine our design go for prototyping and evaluate again,
so this cycle may continue till we arrive at a stable design. So, design prototype evaluate
cycle we covered. Next, we cover design of the system where we have seen how we can
come up with a modular system design using different approaches, we can follow either a
function-oriented approach or object-oriented approach.

In the former case, we can use DFD to express the design system design in the latter case we
can use UML to express the design. Outcome of these design stage is the system design
document. Next, we covered coding and implementation stage. We learned about good
coding practices and outcome of this stage as is obvious is the code, the system
implementation which may include along with the code the documentation for the code also.

Next, we went through the details of code testing, several testing methods we have learned
that includes review-based testing, then structural testing, functional testing. Functional
Testing is also known as black box testing whereas structural testing is also known as white
box testing. So, all these testing methods we have learned, outcome of this stage is testing
document, testing reports.

Now, the testing purposes to find whether the code is executable. The next stage is empirical
study where we try to ascertain whether the code is usable with the help of end users. So,
currently we are discussing the stage empirical study.
(Refer Slide Time: 04:48)
We have already covered several lectures on this topic, empirical study. So, the empirical
study essentially refers to observation of user behaviour while they are asked to use our
proposed system, in a very simple manner we can say this is an empirical study, we observe
and then we analyse the observed data. Now, this is a very systematic approach. It is not to be
done in a very random manner, ad hoc manner or casual manner.

In order to do it systematically, we divided into four stages. In the first stage, we try to
identify the research questions. Second stage is determination of variables. In the third stage,
we go for the design of the experiment and the fourth and final stages analysis of empirical
data. So, these four stages together comprise the overall usability study process.
(Refer Slide Time: 05:50)
In the previous lectures, we have covered the first three stages namely identification of
research question, determinism of variables and design of experiment. In this lecture, we are
going to cover the last topic or last stage that is analysis of data. Unless of course we analyse
the data will not be able to come to any conclusion about the observation. So, analysis of data
is a very important stage and we should be careful while analysing the data.

So, in this lecture we are going to learn about issues and challenges in data analysis as well as
the methods that can be followed for analysis of empirical data. Let us begin our main
discussion for this lecture. So, in order to understand the issues that are involved in data
analysis, we will revert back to our earlier example.
(Refer Slide Time: 06:42)

So, earlier we are talking of a text entry interface that we propose and we want to compare its
performance with that of the existing systems. So, we framed a research question, research
question number 3 that is whether our system is faster than MS Word. Now, earlier in the
previous lectures, we mentioned about using 2 interfaces and 5 users to explain the concepts.
For the sake of discussion here, we will expand that setup.

What we will do here, we will assume that there are 12 participants instead of 5 as we have
seen earlier. Also instead of 2 let us assume for the sake of discussion that we compared the
text entry speed of our design with another 11 interfaces. So, total there are then 12
interfaces, one is our design and the 11 are existing designs, earlier we talked about 2, one is
our design and the other one was MS Word. Now, we are talking of 12 designs.
This is a hypothetical situation of course, so these can be any 11 interfaces, you can think of
any 11 existing text entry interfaces as per your knowledge. In the last lecture, we learned
about different experiment designs, we talked about within-subject or repeated-measure
design as well as between-subject designs. So, let us further assume that we have conducted a
repeated-measure experiment that is the within-subject experiment.

And in order to take into account the practice effect which we have discussed in details in the
previous lecture, we used the Latin Square method approach for counterbalancing that is
nullifying the effect of practice effect. To recap these concepts, you may refer to the previous
lecture where we have discussed in details what is the Latin Square method and what is the
idea of counterbalancing.

So, if that is the situation, we have 12 interfaces and 12 participants and it is a repeated
measures design that means each participant perform text entry tasks on all the 12 interfaces.
So, total we have 144 data items. Now, here each data item refers to the text entry speed. So,
12 into 12 or 144 text entry speeds we have collected.
(Refer Slide Time: 09:10)

Let us think of such a table. In the table on the one side we have interfaces, on the other side
we have participants, participant 1, 2 to up to 12 and interfaces 1, 2 up to 12. So, each cell
indicates the text entry speed that the participant achieved with the particular interface. So,
for example 3 here in this cell indicates that the participant one performed text entry with
interface 1 and achieved a speed of 3 characters per minute.
In that way we can interpret all the other values. So, this is the data we have collected. In
other words, this is our so called empirical data. Now, the objective of any empirical study is
to analyse this data to come to a conclusion. So, how we can analyse? Let us follow a very
simple approach that is for each interface we can take an average value for these numbers that
means for interface 1 average text entry speed obtained is say something n 1, this is n 2 and in
that way we get n 12.

Now, we can simply compare these n values, see the one with the maximum speed and then
we can say that that particular interface provides maximum text entry speed. This sounds
quite simple, fair and logical, but is it going to be the correct way to look at the data that is
the question that we are going to understand in this overall lecture.
(Refer Slide Time: 11:02)

So, the question is what to do with this data? Definitely we can use this for drawing some
conclusions on the efficacy of our design whether it is faster in comparison to other
interfaces. As I said, we can simply take an average of each interface for all the 12
participants and draw a conclusion. But if we draw such a conclusion and conclude that
particular interface is faster as compared to the other interfaces that need not be the correct
conclusion, it may be actually misleading, why it is so? Why it would be misleading?
(Refer Slide Time: 11:41)
One thing is we made use of 12 interfaces. Now, these 12 interfaces represent only a fraction
of all possible text input interfaces. So, when you draw a conclusion like our interface is
faster than any other text input interfaces, ideally we should compare it with all possible text
input interfaces that are available in the market, but 12 may be a very small number, in fact
11 because the other one is our own interface.

So, we have compared with 11 other existing interfaces, now that 11 may represent a very
small fraction of all possible text input interfaces that are available in the market. We may not
be aware of all such interfaces, so we cannot draw a general conclusion based on these 11
interfaces solely using a very simple method. Another concern is there are 12 participants
who participated in our study.

Now, this is also a very small fraction of all the potential users. Suppose, we define the users
to be the English speaking teenagers within the age group of 15 to 25, now if we employ say
only 12 out of these population that represent a very tiny fraction, so conclusion drawn on the
basis of these tiny fractions’ behaviour did not be applicable to all the other members of the
user group.

So, even if we are considering specific demographic profiles, still we may not be able to work
with a large set of users belonging to that profile because of practical considerations. And can
we really draw any generalizable conclusion based on that behaviour that we observed for
that tiny fraction of the whole population, is that possible?
(Refer Slide Time: 13:41)
So, what it actually tells us is that we are dealing here with samples, samples of the interface,
samples of all available text input interfaces, sample of the user group. So, we are dealing
with samples rather than the actual population, actual population means all members of the
particular groups, so all users or all interfaces represent the actual population. So, we are
dealing with samples.

Now, the question is where is the guarantee that the observations were not due to chance, it
may happen that whatever we have observed happened because of pure luck, pure chance
instead of showing the actual behaviour of the user group.
(Refer Slide Time: 14:36)

Why that is important? We need to ensure that suppose today we conducted one such
experiment and observed the text entry speed of the participants, tomorrow we conduct
another study with a completely different set of participants and interfaces. The participants
belonging to the same user group whereas the internet is belonging to the same group of text
input interfaces. So, we want to ensure that tomorrow what we observe is not completely
different from what we observe today.

That means tomorrow we are not going to end up with a completely different data set. If that
is the case, then of course our conclusion will change and we are going to end up with a
different conclusion than what we can conclude based on the data we have collected today.
So, the issue is this. Today we are conducting a study, in this study we have employed some
participants and used some interfaces and based on that study we got some data and we are
analysing the data to conclude.

We want to ensure that the data that we have observed is not due to chance, it is because of
the actual behaviour of the users, otherwise if we conduct a study tomorrow with a different
group of users and different set of interfaces, then we may end up with another data set and
analysing which may lead to a different conclusion, which of course is not desirable.
(Refer Slide Time: 16:13)

So, how likely is that possibility that the data we got is not due to chance or rather the data
that we got is purely by chance. So, we need to answer that question first. So, that is our
primary concern in analysis of data. Whatever data is collected, whether that is reliable or
whether that did not happen due to chance that we need to answer first. Now, to answer this
question, we need to perform a statistical significance test.
And this particular question points to statistical significance of the data, in other words, the
reliability of the data whether the data is statistically significant and for that we need to
perform statistical significance test of the data. So, let us try to understand statistical
significance.
(Refer Slide Time: 17:03)

So, the fundamental concern here is we work with samples, small set of the actual population,
but, a big but, what we want is we want to draw conclusion on the larger population or the
entire population. So, we are working with samples, but we are trying to draw conclusion on
the population, so that is our fundamental concern. Is that possible or what are the issues that
we should answer or address before we can draw such a conclusion?

So, we wish to conclude if the result is applicable for any user and any text input interface in
the specific context of our example rather than applicable for only the 12 participants and
interfaces. So, in the example, we made use of 12 participants and 12 interfaces including
ours the data we observed and collected.

If we analyse the data and come to a conclusion whether that conclusion is applicable to any
interface, text input interface and any user belonging to that user group or it is specific to only
the 12 participants and the 12 interfaces that we have considered. This is the fundamental
constraint that we have.
(Refer Slide Time: 18:29)
So, in order to address this concern, it is necessary to determine the nature of the data. Is the
data occurred by chance or the data occurred due to specially designed test conditions? That
is in our case the interfaces, which is often termed as treatment conditions. This is a more
popular term used that is the data occurred due to the treatment condition. So, in our case,
specially designed test conditions where we made use of 12 interfaces. So, this nature of data,
we first have to understand whether the data occurred by chance or because of the treatment
condition.
(Refer Slide Time: 19:04)

In order to understand whether the data occurred by chance or due to the treatment condition,
we need to go for statistical significance tests, special category of tests which answers this
particular concern. If we perform significance test on data items and find that the statistic is
significant with p less than point 0.05, we can say with confidence that the data is due to the
treatment condition and not by chance in 95% of the times.

This is a very simple interpretation of the statistical significance test outcome. So, we will
learn about these terms what is p, what is this value 0.05. But if we find something like this,
then we can conclude that the data happened due to the treatment condition and not due to
chance or data is going to happen, the kind of data that we observed that event is going to
happen in 95% of the cases and in 5% of the cases it may happen due to chance.

So, if we conduct the experiment 100 times, in 95% of the times we are going to get similar
data whereas in 5% of the cases there may be deviation from the kind of data that we have
observed which may happen due to chance. So, in this way we can actually conclude what is
the confidence with which we can say that data is not by chance.
(Refer Slide Time: 20:38)

So, here our starting point is a statistic. In the context of user centric research, it is the mean
or average of a group of data items. Now, the data items are essentially samples or collected
from samples and we are dealing with the mean of the data items. Typically, we are interested
to test the significance of the difference between the means of several groups of data and this
is the situation in most of the cases.

So, when we are analysing empirical data, in most of the cases we are interested to know
about the difference between the means of multiple groups and whether those differences are
statistically significant or not. So, note that we are not directly dealing with averages, we are
computing our ages are calculating mean or averages, but then the difference between
averages is what we are more interested in than the absolute value of the averages. Let us try
to understand this with example.
(Refer Slide Time: 21:40)

So, let us assume that only two interfaces are there as originally done in RQ3 instead of 12
that we started with. Now there are 12 participants as before. So, then we get two groups of
text entry speed data, one group belongs to text entry speed for one interface and other group
belongs to the other interface.
(Refer Slide Time: 22:07)

So, we can represent the data in this way. So, there are 12 participants, P 1 to P 12. Now,
there are two groups of data, one group belongs to our design where these participants
produce some text entry speed based on the tasks that are given to them and then these are the
values. So, there are 12 values in this group and we computed the mean of this group which is
3.25. Similarly, for the other interface MS Word there are 12 values and this is the group
mean 2.

Now, here you can see that there are two mean values, one is 3.25 for our design and 2 for
MS Word. We may be tempted to immediately conclude that since our design produces a
higher speed on average, so it is higher than the MS Word, this may be a very tempting way
to conclude immediately based on the group means.
(Refer Slide Time: 23:12)

Now, the mean along with other measures which you may be already aware of such as
median, mode, variance, standard deviations these are all called descriptive statistics. They of
course on their own can reveal many things. For example, two means reveal that our design
provides faster text entry than MS Word, but that is what apparently it seems. But can we
really conclude like that?
(Refer Slide Time: 23:44)
Problem is we cannot have such a general conclusion unless we perform some more
statistical significance tests. Because of the same reason, where is the guarantee that the
difference between the mean shall remain the way it is if we conduct the experiment with
different setup that is different interfaces and different group of participants. Now here that
we are talking of difference in group means.

So, group mean for our design is greater than other group mean that is what we observed in
this study, but where is the guarantee that this relationship will hold in another study that we
may conduct tomorrow? We have to first ensure that before drawing the conclusion that our
design is faster than MS Word.
(Refer Slide Time: 24:41)
So, one thing we should keep in mind is that we are not concerned about absolute values,
those values may change. Rather what we are concerned about is relative difference between
those values. Now, the only way to be confident of the reliability of the observations is to go
for the significance test. So, the only way to know whether this difference between absolute
value shall hold in any other experiment that we conduct tomorrow is to go through the
significance test of the data that we have collected.
(Refer Slide Time: 25:18)

A point to be noted here is that we perform significance tests. Here the term significance is
not the general term significance as in English, but here we have to understand it as statistical
significance. So, always remember that whenever we use the term significance, we are
referring to the term statistical significance. Now, these two are different. For example, we
may say that, suppose there is a group mean 1 with the value 100 and another group mean 2
with value 5.

This is obtained after some data collection process that we followed. So, the difference
between them may look like significant. Difference may be significant it may appear, but it
was so happened that they are not statistically significant that is although the difference
between them is 95 which looks like a significant difference between these two numbers,
statistically this difference may not be significant as we shall soon see.

So, what may look like significant may not be statistically significant and what may be
statistically significant may not look like significant. So, both way you have to keep this in
mind.
(Refer Slide Time: 27:04)

Now, as I said we perform statistical significance tests for hypothesis testing. Let us see how
we can do that. Let us consider the research question RQ3 that is does the new interface let
me enter text faster than MS Word that was our original research question. So, the
corresponding hypothesis which is the null hypothesis as well as the alternative hypothesis,
there can be two, recall our discussion on hypothesis.

The null hypothesis is denoted by H 0, our design is not faster than MS Word and the
alternative hypothesis denoted by H 1 is our design is faster than MS Word, suppose these
two are the two hypotheses we started with.
(Refer Slide Time: 27:54)
With the significance test, we try to refute the null hypothesis that is the primary objective of
significance test. Now, let us try to understand the process with one simple, probably the
simplest statistical significance test, let us try to understand this.
(Refer Slide Time: 28:21)

This is an example of a t-test which is one of many available significance tests. Suppose, we
have performed the t-test, a paired sample t-test. Once you perform the t test, you are likely to
get something like what is shown in this table. The difference in group means 1.25. The
two-tailed p value 0.02058, t = 2.702015 some number, degrees of freedom df 11. And the
conclusion is the difference is statistically significant. So, what it tells?
(Refer Slide Time: 28:55)

Now, in the table as you can see there are several entries. You will get this table if you
perform the t-test with some automated tool. So, there are several entries in the table. First
one is of course the actual difference, then the p value, t value, the degrees of freedom value
and the final conclusion. So, all of these need not be reported in this same manner, the same
way that is shown in that table.

But all these entries are of course very important. Difference of the means is found to be
statistically significant that is the final conclusion that is written in the table. We simply
report these facts along with some other information that we shall see. Now reporting this
conclusion at some form, so generally you will find the conclusion is reported with this type
of format.
(Refer Slide Time: 29:50)

For a paired sample t-test we use the symbol t within parenthesis 11 that is the degrees of
freedom df equal to the value of the t that is 2.70, then we report p less than 0.05 and
statistically significant. So, this is the notion that typically is used to concisely report
everything that is present in the table. So, this is about how to report what is the format in
which we should report.
(Refer Slide Time: 30:28)
In the format, as you can see we use the lowercase t. After it, we put degrees of freedom df
that is 11 in our case within parentheses and without any space in between this is important.
This is followed by an equal to symbol followed by the t-statistic which in our case is 2.70.
Then we put a comma and a space character finally we write the p value as p less than 0.05.
This is the notation typically used.

Of course, there may be some other notations used, but this notation is more commonly used,
so you are advised to use this notation that we have just discussed, namely in this format t 11
without any space and within parentheses equal to t-statistic value comma space p less than
0.05, do not write it .05, you should always write it 0.05 and then comma and then the
conclusion statistically significant.
(Refer Slide Time: 31:42)
Now, let us try to understand the significance of these notations. The p value rough roughly
indicates the probability that the data occurred by chance. So, the value 0.05 is a predefined
threshold value, generally we use this value to conclude whether the possibility of the data
occurring by chance is less than 5% or not. So roughly we can interpret it in this way. So, p
indicates roughly the probability that the data occurred by chance.

And 0.05 is the threshold value above which we generally do not consider the data to be
statistically significant, generally. So, if we are using the value 0.05, then that indicates that
the probability of getting the results by chance is about 5% or less that is the meaning of this
threshold value and the significance of the notation p.
(Refer Slide Time: 32:46)

Since the test result indicates difference between means is statistically significant, we reject
the null hypothesis. So, if we find that the result is statistically significant, then we can reject
the null hypothesis and establish the alternative hypothesis.
(Refer Slide Time: 33:05)
Now, one issue that we have to keep in mind is that the tests run the risk of two types of
errors. So, it is not that there is no issue with this type of testing, so there are maybe two
types of errors and we have to be aware of it and we have to be careful about data analysis
using statistical significance tests.
(Refer Slide Time: 33:33)

There is a type 1 error which is also known as the alpha error or false positive. Now, this type
of error occurs when we reject a null hypothesis, which is true and should not be rejected that
may happen. To avoid type 1 errors, typically use a very low value of p which is p = 0.05. So,
if you set p to be higher, then you run the risk of having type 1 errors. So, what is the type 1
error? To recap type 1 error is the error when we reject a null hypothesis which should not
have been rejected.
(Refer Slide Time: 34:17)
Then there is a type 2 error. It is also known as beta error or false negative. So, type 1 error is
called alpha error or false positive and type 2 two error is called beta error or false negative.
So, this type 2 error indicates a situation where we do not reject a null hypothesis, although it
is false and should have been rejected. So, this is just the opposite of type 1 error. In type 1
error, we rejected the null hypothesis which should not be rejected.

Here in type 2 error, we are not rejecting a null hypothesis we should have been rejected.
Now to avoid type 2 errors, it is generally recommended to go for larger sample sizes so that
amount of data items should be larger to avoid type 2 two errors. So, we should be careful
about these types of errors possibility of them occurring in our conclusion and accordingly
take corrective actions.
(Refer Slide Time: 35:24)
So, many important terminologies and issues such as p value, two-tailed distribution, etc., we
mentioned in passing, so rather casually. Our aim is to primarily introduce the idea rather
than going for an in depth study of statistical significance test. So, if you want to know more
about these things, more precise definitions of p values or these ideas of two-tailed
distributions, what they mean, what they signify then you may refer to the reference books
that are going to be mentioned at the end of this lecture.
(Refer Slide Time: 36:05)

Also, we did not explain the actual calculations here, we just reported the values that is to
keep things simple not complicate with unnecessary details. In fact, the calculations you need
not perform by yourself at all, there are already tools available which you can make use of
such as SPSS tool or any other statistical packages. So, we can make use of any of these, just
feed them your data and ask them to calculate the particular statistic.

It will automatically be done with all the details that we have just discussed. So, those are the
two things that we explicitly did not cover, one is the precise definitions as well as more
details about the specific terms that we used like the p value or the two-tailed distribution,
these are some terms that we have used, but those details we have not covered here, you may
refer to the references that are going to be mentioned at the end.

Also the actual calculations we did not discuss here in details; how to perform those
calculations, how to get the t-statistic in particular or some other statistic that we are going to
learn soon, for that statistical packages are available, you may choose any of the statistical
packages and make use of the features provided to get those values automatically. Now, let us
move to our next topic of this lecture that is different techniques or t test that we have just
seen is only one of many statistical significance tests that are possible.

Let us have a quick look at different techniques and which technique is applicable in which
situation that also is very important to know, we are going to learn that also in brief.
(Refer Slide Time: 37:54)

So, the t-statistic that we have just used in our example is not the only way to test for
statistical significance as I just mentioned. There are in fact a large number of such tests
available and very important to choose the right test method. So, given the data it is of course
not advisable to randomly pick up a testing method and apply it on your data, you have to
very carefully choose a testing method for analysis of a particular data set.
(Refer Slide Time: 38:36)
Now, the different techniques that are available for statistical significance test can be broadly
categorized into these two groups, parametric tests and non-parametric tests.
(Refer Slide Time: 38:50)

Now, t-test is an example of the many methods that are collectively known as the parametric
methods or parametric significance tests. Now, these tests are applicable subject to the
fulfilment of three conditions. So, we should first check whether these three conditions are
satisfied, then only we should go for one of the several parametric tests.
(Refer Slide Time: 39:15)

Now, what are the conditions for application of parametric tests, parametric significance test
or other parametric statistical significance tests? Now, the data should come from a normally
distributed population. So, whatever data we are dealing with should have come from a
normally distributed population that is the first condition that has to be satisfied. Second is we
should use at least an interval scale of measurement to record data that means with equally
spaced intervals to record data for that dependent variable.

A ratio scale is even better. So, we should preferably use ratio scale, if that is not possible,
then at least interval scale should be used to measure and record the data. Otherwise,
whatever data we record using the other scales nominal and ordinal are not useful for
application of parametric testing methods. Variance in the groups of data should be
approximately equal, this is another important condition.

So we are dealing with several groups of data and the variance in those groups should be
approximately the same or equal. So, these three conditions must be satisfied if we are to use
parametric methods for testing statistical significance of the data that we have collected.
(Refer Slide Time: 40:51)

So, let us see. Did we do the right thing by applying that t-test on our data as explained
earlier. So, we simply used the t-test without actually bothering to check or apparently
without bothering to check whether these three conditions were satisfied with our data. So,
did we do the right thing? Let us see.
(Refer Slide Time: 41:12)
So, in our data collection method, we use the ratio scale that is the text entry speed. So, we
are not violating the second condition for a parametric test that is the use of ratio scale. Now,
what about the other two conditions that is whether the data came from a normally distributed
population and whether the variance in the groups are almost equal, let us make some
assumption to understand this.
(Refer Slide Time: 41:41)

Text entry speeds follow a normal or Gaussian distribution that is one assumption we are
making. Now, when we talk of distribution, the distribution is used to refer to the entire
population. So, how we get this distribution? We plot the speed of all the users, all possible
users if that is possible. Now, our sample data that is the speed of 12 participants drawn from
a normally distributed population and sample data in itself need not be normally distributed.
So, we actually do not have in this case any way to know whether the distribution that we are
likely to see for the entire user population that is their text entry speed is going to be normally
distributed or not. Let us make that assumption that it is from normal distribution. Now, we
are drawing the samples from that distribution.

So, even if this particular samples do not follow normal distribution that does not matter, it is
drawn from the normal distribution as per our assumption, so we can say that it holds the first
condition if we assume that to be correct, in general that kind of assumptions hold.
(Refer Slide Time: 42:57)

And of course, whether the variance is approximately equal or not we can simply calculate
and in the kind of data that we have reported, you can check whether the variance between
the two groups are approximately equal or not. So, it is of course easy as you can see from
this example to check for conditions 2 and 3, second and third conditions are easier to check
that is whether the variance are approximately well and whether we have used the at least an
interval scale.

Here of course, we have used ratio scale which is anyway satisfying the condition and we can
check the variance. So, second and third condition checking is generally easy. Problem is
with the first condition that is whether the data that we have collected comes from a normally
distributed population because it is not possible to capture data for all users belonging to that
population, so it is generally difficult.
(Refer Slide Time: 44:01)
Now, if there is some element of uncertainty, then we have some way out. What we can do is
we can go for additional tests, some additional statistical tests such as Shapiro-Wilk test or
the Kolmogorov-Smirnov test. So, these tests again you did not do it yourself, the statistical
packages can do it on your way up. These tests will reveal if the sample data is taken from a
normally distributed population or not.

So, either we can assume based on our intuition or we can go for these additional tests to
check whether the first condition holds. If all the three conditions hold, then only we can go
for parametric tests on our data.
(Refer Slide Time: 44:54)

The other category of tests is called non-parametric tests. If your data do not support any one
of the three conditions that we just mentioned, then you should not use parametric testing
methods, instead you should go for non-parametric statistical significance tests. So, any one
of these three conditions if violated, then you should go for non-parametric testing methods.
(Refer Slide Time: 45:21)

So, let us summarize then our discussion so far. So, which kind of test we are going to use
depends on our experiment design. So, if we are designing an experiment following the
between-subject design approach with one factor having to levels, remember factor means
independent variable, levels mean the values that it can take. So, this is our experiment design
set up between-subject design with one factor and two levels, then we can go for a
non-parametric test that is Chi-square test.

There is no corresponding parametric test available, so this is not possible. If we are using
nominal categorical scale of measurement with this kind of experiment design that is
between-subject design with one factor having two levels and nominal or categorical scale of
measurement, then we should go for Chi-square test this is one nonparametric test. So, there
is no corresponding parametric test available for this type of design.

If we are using within-subject design with one factor having two levels like before and
nominal or categorical scale of measurement, then we can go for McNemar's test, this is
another non-parametric test. Again, there is no corresponding parametric test available for
this experiment design. So, in the first case when we are talking about between-subject
design, one factor two levels and nominal scale of measurement, we go for Chi-square test.
In the second case when we are having within-subject design one factor two levels and
nominal scale of measurement we go for McNemar’s test, both are non-parametric tests.
When we are having a design that is between-subject with one factor having two levels, we
can have independent samples t-test if the three conditions get satisfied as parametric test,
and if not then Man-Whitney U test that is a non-parametric test.

Within-subject design with one factor having two levels, paired sample t-test that is a
parametric test and in case of the conditions not getting satisfied we can have Wilcoxon
signed ranks test. If we have between-subject design with one factor having more than two
levels then we can go for one-way ANOVA as parametric test and Kruskal-Wallis test as
non-parametric test.

So, parametric test is applicable when this general design is there plus the three conditions are
satisfied and non-parametric test is applicable when either of the three conditions is not
satisfied. When we have between-subject design with two or more factors each having two or
more levels, then we can have factorial ANOVA, there is no corresponding non-parametric
test available here.

Then so when we have between-subject design with two or more factors each having two or
more levels for parametric case we can go for factorial ANOVA, for non-parametric case the
same Kruskal-Wallis test is applicable. When we have within-subject design with one factor
having three or more levels, then we can have repeated measure ANOVA under the
parametric tests and Freidman test under the non-parametric test.

Now, this is also applicable in within-subject design with two or more factors each having
two or more levels. So we have several parametric tests like independent sample t-test, paired
sample t-test, one-way ANOVA, factorial ANOVA, repeated measure ANOVA; these are
parametric tests. And under non-parametric we have Chi-square test, McNemar’s test,
Man-Whitney U test, Wilcoxon signed rank test, Kruskal-Wallis test, Freidman test.

And for each test we have to first ensure that the particular experimental design as mentioned
in this table is satisfied and the three conditions that we have mentioned earlier, either they
are satisfied or not satisfied. If they are satisfied, then we go for parametric test; if not then
we go for non-parametric test. So, this is in summary different tests that are available and the
situations in which we are going to apply those tests. So, now let us summarize the entire
workflow of empirical study.
(Refer Slide Time: 50:21)

So, first thing is we frame research question. So, generally we are supposed to frame multiple
testable questions to seek answer to broader question as we have already discussed in details.
This is followed by determinism variables. What we do here? We identify the dependent and
independent variables with their levels. Now, independent variables are also called factors
and the values that they take are called levels along with the control and confounding
variables.

So, I hope you remember the idea of control variables, the variables that we use as constants
and confounding are those variables whose existence we are not aware of. Then we go for
choosing our participants. Between 12 to 25 participants should be chosen to carry out a
reliable test with reliable conclusion. Should be chosen according to the profile of the
potential user, so they cannot be randomly taken.

First you have to identify the profile and from that group of users whose profile matches with
the profile that you have identified, you can choose the participants Next you should go for
experiment design. You have to decide whether you should go for within-subject or
between-subject design depending on the availability of resources, volunteers or participants,
etc. Also, you have to identify the test conditions and other setup, decide on the tasks and the
procedure for data collection.
Next is the data collection, actual data collection where you ask the participants to perform
the tasks and the data they produce you observe and record using either of the recording or
measurement scales. The next is data analysis that is here you go for statistical significance
test to ascertain the reliability of the data that is whether they happen by chance or due to the
test condition. Now, this is also called hypothesis testing, which involves formulation of
hypothesis.

So, although we discussed it during the research question framing, so actually it is required
when we go for that mystical significance testing of the data. These are the steps that we have
covered in the previous lectures. There may be one additional step which is not the focus of
this course as well as this lecture, but I will just mention it here that is model building. So,
once you are satisfied that the data is not due to chance, what you can do?

You can perform some regression analysis on the data between the dependent and
independent variables to come up with explicit mathematical models or you can use the data
for training in some machine learning or deep learning based approach to learn and model
user behaviour. So, from the point of view of our interest in this course, we can stop at this
stage here as soon where we conclude based on the analysis of the data.

But if required we may go one stage ahead and come up with a model of user behaviour
which can be used to automate certain aspects of the system as well as the design process. So,
that is in summary what we can do in empirical study. As you can see, the study is not a
simple thing. Initially, when we started it may have seemed simple, we just asked friends to
give feedback on our design.

But it is not as simple as you may be thinking and probably by now it is clear to you after
going through the previous few lectures that it is a very rigorous process, involves lots of
carefully considered stages and carefully considered activities to complete the process.
(Refer Slide Time: 54:31)
So, whatever we have discussed so far, you can find in this book. In fact, several concepts we
have mentioned in the passing as mentioned during the lecture, So, in this book some of those
concepts are explained in detail. Also in this book, you will get reference to further study
materials where you can learn in more details about those concepts. So, you are advised to
refer to chapter 7 of this book to know in more details about those concepts.

So, with that I would like to end this lecture. I hope you have understood the concepts and
enjoyed the lecture, looking forward to meet you all in the next lecture. Thank you and
goodbye.
 Design and Implementation of Human-Computer Interfaces
Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology – Guwahati

Lecture – 42
Project Management

(Refer Slide Time: 01:00)

Hello and welcome to the NPTEL MOOCS course on design and implementation of
human-computer interfaces. We are going to start lecture number 36 where we will talk in
brief about the concepts of project management. Before we start, let us quickly recap what we
have covered so far. We are discussing the interactive system development lifecycle. This
lifecycle is required to develop and deploy human computer interfaces, which are examples
of interactive systems.

Just to quickly recap why this lifecycle is important, so in interactive systems or more
specifically in the context of human-computer interfaces what we need is basically a system
that is executable and at the same time usable. So, we have discussed the idea of usability in
several lectures and we need to ensure that the system that we develop is usable as well as
executable. In order to achieve that, we need to follow some systematic development
approach.

Lifecycle development models that are typically followed in software engineering provide
such systematic approaches. So, there are several models. For example, we have seen the
water-fall model, the spiral model. Spiral model is of course a meta level model and it
involves everything whereas water-fall model is not suitable for use in the development of
interactive systems.

In interactive system development what we require is involvement of the end users, not the
clients or customers, rather the end users in the development process either as active user or
passive user. In other words, what we are trying to do is to follow what is called user centred
design approach. Now, that involves lots of feedback from the users which needs to be
incorporated in the development process which in turn implies that our lifecycle should have
iterations between stages.

So, the characteristic of any interactive system development lifecycle is the presence of
iterations and incorporation of user feedback through these iterations in the end product. In
this course, we are learning such an interactive system development lifecycle model. In our
model, there are several stages which we have covered. So, there is the feasibility study stage
which we ignored. This is of course very important and should happen at the beginning of
any development process.

We started our discussion with the requirement gathering analysis and specification stage.
Next is the design, prototyping and evaluation cycle comprising of these three stages; the
design, prototyping and evaluation. Now, this cycle is meant to take into account the usability
concerns. So, design refers to design of interfaces and interactions. These designs are
typically done based on guidelines to ensure that the interfaces and interactions that are
designed are usable.

However, to test whether they are indeed usable or not, those are prototyped and evaluated
with experts. If some problems are found, then the designs are refined, again prototype, again
evaluated and this goes on in a cycle design, prototype, evaluate cycle. Note here that we are
taking care of the iteration here. We are taking care of the user feedback through the iteration
here. Now, of course in this evaluation, we are not actually involving the end users actively.

Instead, we are using representation of such users in terms of domain experts who are
supposed to represent the end user behaviour. So it is kind of we can think as passive
involvement of end users. This is followed by design of the system, which is not shown
separately in this lifecycle model. So, once we arrive at a stable interface design, we go for
designing the system in terms of modules and submodules and their connections that is
followed by coding and implementation of the design system followed by testing of the code.

This is followed by, one is missing here, this is followed by a phase called empirical study in
this phase which we have covered in details in the previous few lectures. We test the usability
of the system with actual end users. So, input testing we test the execute ability of the system,
in empirical study we test the usability of the system. Now it may so happen that at this stage
we may find some usability issues, which we can fix by going back to the design stage.

There we may or may not follow this design, prototype, evaluate cycle again depending on
the availability of time and resources. However, we may refine our system design, refine the
code, test the newly added code part and then we may conduct another empirical study to
check whether the system is usable. Now, here also there is one cycle as you can see from
empirical study it goes back to the design stage. So, at multiple places we have these cycles.
Another cycle exists between the design stage and requirements specification stage.

So, in the design stage if we find too many problems, then we may need to revise our
requirements and then go back to the design. So, three places we have cycles or iterations
between the requirement and design phase; in the design, prototype, evaluate cycle and
between the empirical study and design phase. Finally, we come to the deployment and
maintenance stage. So, these are the stages and the systematic approach to develop interactive
system.
(Refer Slide Time: 07:24)
Now, what do we do in these stages? Let us have a quick look. In the requirements stage, we
gather requirements at two levels, from the client or customer as well as the end users.
Traditionally in software development, client requirements are gathered whereas in case of
interactive system development along with client requirements, we also need to gather end
user requirements.

So, typically client requirements can be represented in terms of functionality requirements,

plus there will be some non-functional requirements that are part of client requirements as
well. Whereas when we gather requirements pertaining to end users, we call it usability
requirements. Now, we have discussed one such technique, there are several techniques
available for collecting end user requirements.

We have discussed one such technique which is called contextual inquiry. This is an
observation-based requirement gathering technique if you may recollect, where we observe
the user behaviour and record those behaviour for analysis. At the end, what we get his SRS
document which is our starting point for system design. In the interface design phase, what
we do? We use design guidelines as mentioned earlier for ensuring usability.

Now, a couple of such guidelines we have studied; Shneiderman's eight golden rules,
Norman's seven principles all these things we have studied. In the system design phase, what
we do? So, we should treat them separately, one is interface design, one is system design. We
come up with design of the system. Now, we can follow either of the approaches. If we
follow the functional approach then generally, we use DFD or data flow diagram to represent
our design.

Alternatively, we can use object-oriented approach or object-oriented design approach OOD,

there we can use the UML notation Unified Modelling Language notation to represent the
design. Now, it may be recalled here that in system design our primary focus is hierarchical
design, where we divide the problem into modules and submodules so that it can be
distributed to a team for parallel development.

And also it is very important to define the interfaces between the different modules. Now, in
the prototype phase that is related to the interface design as well as the evaluation phase, we
develop prototypes. So, we learned about several techniques to build prototypes, high fidelity,
medium fidelity, low fidelity as well as vertical, horizontal. Also, you have learned about
couple of prototype evaluation techniques such as cognitive walkthrough and heuristic
evaluation.

So, these are used for evaluating interface design and refine the design if required, but these
are not relevant for system design. In system design as I mentioned, so use functional or
object oriented and correspondingly we use the languages such as DFD or UML for
representation. This is followed by coding stage. In coding what do we do? We write codes to
implement the system.

So, good coding practices are the primary concern here, we should follow those to write code
that is understandable and maintainable. This is followed by code testing, we try to find out
whether there are any issues with the code that we have written. Now, code testing there are
several methods, we have learned about those. A quick testing method is the review-based
methods. Here we have learned about code walkthrough method and code inspection
methods.

These are similar in nature to cognitive walkthrough and heuristic evaluation methods as we
have discussed during the lecture. This is followed by a more systematic method namely the
functional testing or the black box testing as well as the structural testing or white box
testing. Now, these testing are primarily done at the unit level at the module level. So, we
divide the code system into modules, implement them and test them using these methods.
It is also necessary to perform testing of the system after integration of the modules, so that is
also important and we have seen several such testing methods. Finally, we discussed in the
previous few lectures about another aspect of system testing that is usability testing through
empirical method where we have seen that we follow a very systematic and rigorous method
comprising of four steps; research question formulation, variable identification, design of
experiment and data analysis.

In data analysis, we primarily test for statistical significance of the data that we observed to
draw a reliable conclusion about the usability of the end product. So, these are in summary
the things that we have already covered in our previous lectures.
(Refer Slide Time: 13:32)

One stage that remains to be covered is the final stage that is deployment and maintenance.
Of course, this is very important, but in this course we are not going to discuss much about it
that is not the focus of this course. It will be sufficient to know here that in the maintenance
stage, what we do is we need to keep track of issues with the system that we have already
deployed in the market and we need to provide updates to the clients, fix bugs if some are
reported by the clients and so on.

These are typically part of the maintenance stage. What we are going to focus next is a topic
that is very important and typically that is done at the beginning of the development process,
although we are discussing it at the end, but typically you should keep in mind that this is
supposed to be done at the beginning before the full development takes place that is project
management. Let us see what are the issues in project management and how we can address
those issues.
(Refer Slide Time: 14:32)

Now, project management is a very important issue when we are dealing with practical large
and complex systems. So, they are if we simply start development process without actually
properly planning for different stages of execution as well as allocation of resources, then it
may end up in complete chaos and we may miss the deadlines. So, it is very important to do it
before we start the process. Now, what it involves?

It involves prior estimation of the manpower that may be required, resources that may be
required and the cost that is going to be incurred before the development is complete and the
system can be deployed. So, typically these three things we are interested in; the manpower
requirement, the resource requirement as well as the overall cost. So, a project planning in
order to answer these questions of manpower requirement, resource requirement or cost we
need to properly plan the project.
(Refer Slide Time: 15:47)
Now, planning involves some estimation. Prior estimation before the actual things take place
prior estimation of the size of the project, cost, duration and effort that is required to be put
in. So, these are key considerations while we go for planning of a project.
(Refer Slide Time: 16:05)

Once we are able to make such estimates assuming that we can do that, once the estimates are
made, then what a project manager needs to do? A project manager needs to create staff
organization and staffing plan, so how to allocate staffs, how to hire staffs. Plan or arrange for
other resources, hardware, software, infrastructure, physical infrastructure such as seating
arrangements, electricity, etc. Identify risks and plan for mitigation of those risks.

So, while the development is taking place, what kind of issues that may crop up, what are the
risks involved and how to mitigate those in case of those risks are encountered during the
development phase. Also, the manager needs to make plan for quality assurance, quality of
the end product that needs to be assured. So, these are some of the key considerations, there
are other considerations as well.

So, once some estimate is made based on the project size, cost, duration, effort, then the
manager can plan for these activities how to hire staff, then resources required, then the risks
that may happen, risks associated with the development and how to mitigate if those things
happen, quality assurance how to take care of that. All these issues need to be taken care of
by the project manager. So, the job of the manager is not easy.
(Refer Slide Time: 17:51)

Now, let us have a brief idea about these different estimates that we need to make. The most
crucial estimate is project size. So, how do we estimate the size of a project? Now, here we
can simply estimate the size in terms of the size of the system. So, essentially a project is
nothing but development of a system, so the size of the system we can use as the size of the
project. Now, the size of the system, so here we are talking of software systems.

So size of the system can be simply the size of the software that is the lines of code or Lo C
that is the total number of lines of instructions that is part of the system. Of course, this
consideration excludes any line that is used as comments. So, we need to focus only on the
lines of instructions rather than comments. So, line of code is one very obvious and intuitive
way of estimating the size of a project. But there are issues involved.
Most importantly, it is very difficult to estimate at the beginning of the development what is
going to be the size of the project. That is of course as you can understand is very difficult to
estimate at the beginning unless you have some experience of developing similar systems.
Another way to overcome it is to make use of the modular hierarchy. So, this requires you to
first design the system in terms of modules and then go for estimation, so anyway this cannot
be done at the very beginning.

It has to be done after some progress is made in the development process, namely
requirements are gathered and we have arrived at the design stage. If we want to avoid that,
then probably we have to rely on prior experience. In fact, in the modular hierarchy also, we
can have prior experience for similar systems, how many modules are typically part of such
systems and based on that experience also some estimates can be made. So, all depends on
primarily the experience of the manager.
(Refer Slide Time: 20:16)

Another metric for estimation of project size is function point or FP. So, it tells that project
size is related to the number of functions which is supported by the system. So, essentially
what it tells is that the system or the software is nothing but a collection of functions. So, the
total number of functions that is going to be part of the software can be used to estimate the
project size and we call this function point metric.

Of course, there are some other considerations as well, but those we can ignore for simplicity
and say that function point metrics refers to the number of functions that is part of the
software. Again, here some prior experience is required to estimate this number before the
system is developed that is about size estimation. So, we discussed two concepts; one is line
of code, other one is function point.

There are many other ways to estimate size, those are more complex. So, we are not going to
deeper into those concepts to keep it simple.
(Refer Slide Time: 21:39)

Next is the estimation of cost. There is a very famous model, although very old, that is called
COCOMO which stands for constructive cost estimation model. Now, this model was
developed way back in 1981. It was proposed by Boehm say about 40 years ago. And this
model can be used to estimate the cost of a project. It can also be used to estimate the
duration and effort required for developing a system along with the cost estimates.

So, earlier we have seen size estimation, with COCOMO we can estimate the cost, duration
and effort, the other three primary concerns of a project manager.
(Refer Slide Time: 22:31)
Now, the COCOMO is not a single model. According to Boehm, software cost estimation
should be done through three stages and accordingly three different models were proposed.
One is the basic COCOMO model, one is the intermediate COCOMO model and other one is
the complete COCOMO model.
(Refer Slide Time: 22:58)

The basic COCOMO model gives estimate with an equation that is effort is expressed or can
be computed in this way a into K LoC to the power a 1 PM, now here PM stands for person
months and K LoC stands for kilo lines of code or 1000 lines of code. Another metric is T
dev time to develop which is b into effort to the power b1 and the unit is months. So, the unit
for effort is person months and the unit for total development time is months.
Now, in these equations a, a 1, b, b 1 these are constants and these takes different values for
different types of projects. So, you can categorize projects into different types and depending
on the types these constants take different values. Those values were estimated empirically
after studying several projects. Let us see what kind of values they take for different types of
projects.
(Refer Slide Time: 24:20)

One project type is organic. Now, what this project talks about is that if a project deals with a
well understood application program and the team size is reasonably small with only
experienced team members. Then we call those projects belonging to organic types. So, to
repeat there is one category of projects called organic type of projects, these are projects that
are basically dealing with well understood application areas that involve team size small and
all the team members are experienced in similar projects.

So, if that is the case and we are dealing with such a project, then the constant values a, b and
a 1, b 1 takes these values; a = 2.4, a 1 = 1.05, b = 2.5 and b 1 = 0.38. So, with this set of
values what we can do is as we can see once we know these values, so for organic projects
we know the values, then we can replace these a, a 1, b, b 1 in these equations and with our
estimate of lines of codes.

We can first calculate effort by replacing a and a 1 with those values then effort is calculated
and with the effort value and replacing b and b 1 with those values for organic project we can
get development time. So, these will help us in estimating the effort and time. Another
category is semidetached. So, here we consider the project to belong to this category if the
team that is going to develop the project consists of a mixture of experienced and
inexperienced staff.

So, earlier we talked of a team where only experienced staff are part of the team, whereas in
semidetached projects the team comprises of experienced and inexperienced staffs. So, in that
case we have a = 3.0, a 1 = 1.12, b = 2.5 and b 1 = 0.35 that is when we are considering
semidetached projects. Finally, we have embedded projects. Here a project belongs to this
category if the corresponding software that we are developing strongly coupled to some
complex hardware.

So, the software has some associated hardware attached to it, so we are specifically building
for that hardware or if there are stringent regulations on operational procedures for
developing a software, some constraints are there. So, if we are dealing with such a project
where we are asked to build a software that is coupled to a specific hardware or some specific
constraints are there then we call this project to belong to this embedded category.

In that case is different value 3.6, a 1 is 1.2, b is 2.5 and b 1 is 0.32. So, broadly there are
these three categories organic, semidetached and embedded. And depending on the category
of the project, we can choose the values of a, a 1, b, b 1 these constants. We can use these
values in the basic COCOMO model to compute the effort and development time which are
basically estimates and then based on that we can make project related decisions.

One thing that we skipped here is that although we mentioned that there are three models
basic, intermediate and complete COCOMO, we briefly discussed only the basic COCOMO
model for simplicity. Now, total cost estimation involves estimating these three stages and
then going for cost estimation. So, we only discussed basic COCOMO, we skipped the other
parts for simplicity. Next is scheduling.

So far we talked about the major concepts that is size estimation. So, we saw that we can do
that using lines of codes or function points. Then cost estimation, we have seen that we can
use the COCOMO model. The model also gives us estimates enough effort and development
time. Another important job of a project manager is to go for scheduling.
(Refer Slide Time: 29:44)
Now scheduling involves identification of tasks and subtasks to be done for the development
of the system and then scheduling those tasks and subtasks in appropriate manner. So, after
this identification, the manager needs to determine the dependencies between those tasks and
subtasks, how one task is dependent on others. So, this can be done with the help of a
graphical language that is called activity network.

Once those dependencies are known, then the manager can allocate the resources to carry out
those tasks and this can be represented with a Gantt chart. And finally, a time schedule needs
to be prepared which can be represented using a PERT chart. So, all these activities need to
be performed to properly schedule and represent that schedule. So, let us have a quick
understanding of these concept; activity network, Gantt chart and PERT chart.

First thing is we need to identify we as a project manager. If we are project managers, then
we need to first identify what are the tasks and subtasks required to complete the
development process and we need to create some sort of hierarchy for better understanding.
(Refer Slide Time: 31:19)
So, one example scenario we are considering here that is one specific application which
belongs to broadly the MIS application category, Management Information System
application category. Now, here as you can see there are several tasks identified.
Requirements specification is a task, design is another task, code development is another task,
testing is another task, document creation is another task.

Now under design, there can be subtasks like database part design, graphical user interface
design. Similarly under test, there can be database part testing, graphical user interface part
testing. Roughly it follows our lifecycle of course, but this is a simple example of identifying
tasks and dividing it and organizing it into hierarchical form.

So, that is the first thing that a project manager needs to do, identify the tasks and come up
with some sort of hierarchy of these tasks for quick understand. Next thing is the manager
needs to then find out dependencies between these tasks. Another example is shown here.
(Refer Slide Time: 32:29)
So, this shows a particular notation which comes from the presentation scheme called activity
network. So, here suppose there are several tasks. So, specification part takes some time,
mentioned here, we can consider it as to be weeks or months or days anything or hours up to
us. So, a specification involves some time. Then from specification there is this design
database part which again involves some time.

Coding of the design database part involves some time, then integration and testing with time
mentioned how long it should take, finally reaches the finish stage that is one path, this path.
There are two other paths, from specification it goes to design GUI part with some time
mentioned say 30 days, then could code GUI part say 45 days it takes, from there it goes to
the integrate and test part, so this is another path and from there it goes to finish.

Alternatively, from specification it can go to write user manual part 60 days suppose and then
go to finish part. So, one path indicates that design and testing of database part, another path
indicates design and testing of GUI part and third path indicates creation of document that
path. So, what this network shows us? It shows that we need to follow these three paths in
these orders. We cannot follow the other orders like first we create the code and then go for
design.

We cannot follow that or we cannot start with this integrate and test part before we finished
these other parts like design database, design GUI, write manual and code database, code
GUI. Unless we do these things, we cannot do the integrate and test part. So, this shows the
dependencies, what is done after what or what precedes which activity or task. So, this is a
graphical way of representing the dependencies between tasks that have been identified in the
earlier stage.
(Refer Slide Time: 35:22)

Also, from this activity network we can do some more things. One important thing that we
can do is called critical path analysis. What it does? It tells us the minimum time required to
complete a project. Now, we can compute it from the time units that are mentioned for each
task. Of course, those are our estimates and from those estimates we can compute the
minimum time required to complete the whole project incorporating all the components of
the project and that is called critical path analysis.

So, how we can do that? By finding the maximum of all paths from start to finish in the
activity network. Now, this can be done by using the critical path method or CPM. So, we
will again skip, we will not go into the details of this method, but that is what we can do if we
are able to represent our dependencies between tasks in the form of activity network with
time estimates mentioned for each task.

If that is the case, if we are able to do that, then we will be able to basically find out the
critical path that is the minimum time required to complete the project by following the
critical path method.
(Refer Slide Time: 37:06)
Then we need to allocate resources and for that also we can use one graphical notation that is
called Gantt chart. So, this is a special type of bar chart which is named after its developer
Henry Gantt where each bar represents an activity and the bar length is proportional to the
duration planned for activity. For example, here we can show a Gantt chart of course shows a
kind of schedule so as you can see specification is shown in the form of a bar, horizontal bar
and on top you can see the dates are mentioned.

So, as you can see here in this example specification task is represented with this horizontal
bar, it is to be completed between January 1 and January 15, so 15 days of time is given. Now
you know how we get this time in the activity network, so we can schedule it in this way.
Then between January 15 to April 1, the design database part as well as the design GUI part
needs to be completed, so that is the total duration.

Then from April 1 to July 15, the code database part needs to be completed whereas code
GUI part is supposed to be completed between March 15 to somewhere here as shown with
this line. So, no date specifically is mentioned just for simplicity, but you are supposed to put
a date here. Integrate and test this activity needs to be done between July 15 to November 15.
And between April 1 to July 15, manual writing activity needs to be done.

So, in this way it can be sewn how the different tasks can be scheduled and accordingly you
can plan for allocating resources to those tasks so that those tasks can be completed on
schedule. And the length of the bar is of course as it is obvious proportional to the time it
takes to complete the activity. So, the longer it takes the length will be larger. So, under
scheduling, we talked about identify tasks and subtasks that we have covered.

Then for determining dependencies, we first need to create an activity network and from
there we can see that dependencies. To allocate resources we need to create a Gantt chart and
based on the schedule that we have created there, the times we can allocate resources so that
those activities get over within that scheduled time within the deadline. The last thing that
remains is the time schedule. This we can achieve with a PERT chart. So, let us see what is a
PERT chart.
(Refer Slide Time: 40:58)

Now PERT stands for Project Evaluation and Review Technique, so this P E R and T together
produces this acronym PERT. So, this is another graphical notation to represent the time
schedule. Now, it consists of a network of boxes and arrows somewhat similar to the activity
network, but with some additional information. So, the boxes represent activities and the
arrows represent task dependencies, we have seen earlier.

The boxes are usually annotated with pessimistic, likely and optimistic estimates. So, there
are three estimates now, instead of one which was there in the activity network. So these three
estimates stand for pessimistic estimate, likely estimate and optimistic estimates for every
task. For example, specification earlier we mentioned only one estimate which was 15 days
as we can see from the Gantt chart.
But now we also had a pessimistic estimate and optimistic estimate, so optimistic estimate is
12 that is it will take less time and pessimistic estimate is 20 that is it will take more time.
Similarly, for design database we now have optimistic estimate of 40, likely estimate of 45
days and pessimistic estimate of 60 days. So, we now have 40 days as optimistic estimate, 45
days as likely estimate and 60 days as pessimistic estimate.

Similarly, code database there we have 95 as optimistic, 105 as likely and 120 as pessimistic.
The same thing we can do for all the other parts design GUI, code GUI, write user manual,
integrate and test, everywhere we can now have three estimates rather than a single estimate.
So, in activity network what we have seen is that we have only one estimate that is the likely
estimate, we can consider it to be the likely estimate.

Whereas in the other cases, along with likely estimate we have optimistic and pessimistic
estimates as well. Now, the advantage of having this PERT chart instead of a simple activity
diagram is now here we can actually come up with better estimates of the project completion
time along with some time overrun limits that we can estimate. So pessimistically what time
it should take that is the longer time, optimistically what time it should take and the likely
estimate that we have estimated earlier.

So, it will lead us to better estimation of the total time required to complete the project from
this dependency diagram. So, PERT chart is a better way to represent the time schedule than
activity networks. These are broadly the issues that are important for project managers when
they try to estimate various things about a project. Just to recap, project management is a very
important part of any project development.

Earlier we have not discussed it, but it should be kept in mind that this is the first thing that
should be done before the development activity starts because unless this stage is done
properly, then the allocation of resources and estimation of requirements cannot be done
properly. So, as a project manager, a project manager is primarily required to estimate project
size, cost, duration, effort.

Then prepare schedules and allocate resources for smoothly carrying out the development
process. Now, in this endeavour manager can take help of several graphical notations to plan
and represent those plans. For example, they can make use of the PERT chart or Gantt chart
or both together or activity diagram and task hierarchy, etc. For estimation of cost, time, etc.,
COCOMO model can be used.

It may be noted here that whatever concepts we have covered in this lecture are covered in
very brief manner to keep the discussion simple as this is not the primary focus of our course.
The primary focus of our course is the development process for interactive systems rather
than how to manage the development process.
(Refer Slide Time: 46:23)

So, for more details, you may refer to this reference Fundamentals of Software Engineering
chapter 3, there you will find these concepts in more details plus you may refer to any other
book on project management for managing complex software projects. I hope the material
that I covered in this lecture is of interest to you and you have understood the concepts.

Of course, we kept it at a very introductory level and for more details you have to refer to the
references, other resources. But I hope you enjoyed the material and I look forward to meet
you all in the next lecture. Thank you and goodbye.
 Design and Implementation of Human-Computer Interfaces
Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology – Guwahati

Lecture – 43
Note on Agile Development

Hello and welcome to the NPTEL MOOCS course on design and implementation of
human-computer interfaces. We are going to start lecture number 37 where we will talk about
a different way of developing a software system that is known as the Agile method. So,
before we start, we will first try to understand whatever we have learned so far, what are the
issues with those and why Agile development methods often found to be useful in
comparison to what methods we have learned in the preceding lectures.

So, if you may recollect, we are dealing with human-computer interfaces. Now,
human-computer interfaces are examples of interactive systems. We have seen earlier how a
systematic development approach helps us in developing an interactive system software. So,
here by the term system we have to remember that we are talking about software
development mainly.

So, we require systematic development methods in order to address several concerns that are
related to the acceptability of the end product to the customers as well as the end users. One
way to do that is to follow software development lifecycles.
(Refer Slide Time: 02:26)
Now, in the early part of this course, in one of the lectures, we have learned about the idea of
software development life cycles and also we have seen in details two such lifecycle models,
water-fall model and interactive system development lifecycle model. Apart from that, we
have also briefly mentioned about several other models that include the spiral model, iterative
model, evolutionary model and so on.

So, these are models of software development process, how the process should proceed in a
stagewise manner. So each of these models represent the whole development as a
combination of stages that are to be performed in a particular sequence. Now, these are all so
called traditional models that means in most of the models except probably the spiral model
which is a meta level model, most of the model stages are mostly the same with variations in
execution sequence.

So, how the stages are to be executed that sequence may vary, but the stages or the core
concept of the stages remains the same in almost all the models. Another important
characteristic of these so called traditional models is that there is equally rigorous
requirements. So, each of the stages need to be executed in a very rigorous manner with strict
requirements for almost all of these models.

So, two primary characteristics of these traditional models are that mostly they include the
same or similar stages and the stages need to be carried out in a very rigorous manner with
strict requirements. Those are the defining characteristics of these traditional models. So, we
have seen in details throughout the course the interactive system development lifecycle
model.

This is one example of the traditional models. Let us quickly see what are the stages and
where the rigor comes from and what we mean by strict requirements. Let us first try to recap
the model.
(Refer Slide Time: 04:29)
So, the model comprises of several stages. First is feasibility study stage. So, we will denote
it with this acronym PS, feasibility study. This is followed by requirement gathering analysis
and specification stage. Now, from here it goes to the combination of substages which
together form a cycle, we call it design, prototype, evaluate cycle. So, here we have the
design stage, prototyping stage and evaluation of the prototype. And this cycle continues till
we arrive at some stable interface design.

This is followed by a system design stage. So, in this design prototype evaluate stage we are
primarily concerned about interface and interaction design to take care of the usability
concern, which is one of the primary concerns for interactive system. Once that is done and
we arrive at a stable design of the interface and interaction we go to the next phase that is
system design where we design the overall structure of the system in terms of modules and
submodules.

Now, this is followed by coding and implementation stage. After that, we go for code testing.
This is followed by empirical study and this is followed by deployment and maintenance
stage. Now, as we have noted earlier, so there may be cycles at this stage. So, from
requirements gathering analysis specification, we will go to this design prototype evaluate
cycle, but if we find too many problems here then we may come back to refine our
requirement gathering process and find out more requirements.

There can be a cycle here as well. So, from empirical study stage if we find some problems,
we may go back to this interface design phase, refine our design and then follow the stages
again. So, at multiple places there are the presence of cycles, but this cycle should be
infrequent, otherwise it will lead to huge cost and time overrun. This cycle may be frequent,
actually this is a frequent cycle.

This cycle need not be frequent, it can be between the DEP and the requirement gathering,
this cycle need not be frequent, not frequent the cycle. So, we have many cycles in our
interactive system development lifecycle that we have covered extensively in the previous
lectures. Among them one cycle may be frequent that is designed prototype evaluate cycle,
other cycles should not be frequent. So, this is what our interactive system development
lifecycle looks.
(Refer Slide Time: 09:29)

Now, in the stages what we have done? In the requirement gathering analysis and
specification stage, we have learned about how to gather functional requirements as well as
usability requirements. For usability requirements we can perform techniques such as
contextual inquiry, we have covered in details the way to perform contextual inquiry method
to gather usability requirements.

So, both functional and usability requirements are gathered, analysed and specified at the end
of requirement gathering phase. The specification document is called software requirements
specification document or SRS. In the design phase what happens? So, there are two design
phases, in one design phase which is part of this design prototype evaluate cycle what we do
is we use design guidelines to come up with initial interface and interaction design.
Then we prototype it and get it evaluated with experts for quick evaluation. For quick
evaluation, we can follow cognitive walkthrough or heuristic evaluation methods as we have
seen earlier. Cognitive walkthrough is a scenario based evaluation method whereas heuristic
evaluation is a checklist based evaluation method. Apart from that, we also have system
design, there we follow a modular design approach.

And we can follow either functional design or object-oriented design approaches to design
our system and represent it with a corresponding language. For functional design we can use
the DFD or data flow diagram and for object-oriented design we can use that UML or unified
modelling language to express the design. Coding and code testing, in these stages we follow
good coding practices and then we test our system implementation to find out bugs and fix
them.

So, different testing methods we have studied namely review-based testing for quick testing
of the code, then black box testing or functional testing, white box testing or structural
testing, then integration and overall system testing, alpha, beta, acceptance test, etc. plus
different performance tests. So, all these things we have covered in details and we have
learned in details. In the empirical study stage, what we perform is usability testing.

So, in code testing phase we test the code for executability, in empirical study stage we test
the system for usability. We have seen how rigorous the usability testing phase is, it
comprises of four stages; research question formulation, variable identification, experiment
design and data analysis. So, each of these stages have to be done with great care and in a
very planned manner so that at the end we can come to a reliable conclusion about the
usability of the product based on the empirical observations.

So, these are the things that we have already covered in details in the previous lectures. Now,
each of these stages as we have discussed is a very elaborate and rigorous stage, it needs to be
carried out in a very elaborate and rigorous manner which is likely to take a very long time,
reasonably long time.
(Refer Slide Time: 13:18)
For example, in the requirements stage, we need to analyse for functional requirements, also
we need to analyse for usability requirements which involves application of methods such as
contextual inquiry. Now, as we have discussed contextual inquiry is not a very simple
method, it cannot be done in few hours or 1 or 2 days.

It requires several days for planning for approaching the participants, for observations, for
brainstorming to come to a conclusion about the observations and so on. So, the overall
process cannot be completed in a very short span of time, at least 1 week to 2 weeks are
required to complete these processes provided everything goes on as per plan.
(Refer Slide Time: 14:02)

Next, based on the requirement analysis, we can go for design of the interface. Now, it is a
cycle, this design cannot be done in one shot as we have seen, so it is a cycle. Design is
followed by prototyping followed by quick evaluation, then followed by design refinements
and so on. So, when we talk of the cycle, it is not something which can be done quickly. First
of all, based on the design guidelines and our own intuition within the design group, we have
to brainstorm that takes time.

After brainstorming, we have to come up with a design idea and then we need to create
prototypes for that. Finally, we need to go for evaluation using either or both of the methods
such as cognitive walkthrough or heuristic evaluation. Now, evaluation also requires forming
a team, asking them to perform the evaluation, prepare report, brainstorm, so it has to go
through several steps.

Overall, this process again cannot be done in a very quick manner within hours or days, it
will take weeks to carry out this process of interface design at least a few weeks are required
to come up with a good and stable interface design.
(Refer Slide Time: 15:28)

Next comes system design. Now, in system design we have to think of the modular hierarchy,
then we have to think of representing our design for that we have to create either DFD
diagram if we are following the function-oriented approach or we have to create UML
diagrams if we are following object-oriented approach. These diagrams need to be
brainstormed to find out any issues with those initial design ideas, then rectifications may be
required.
So, again some sort of iteration needs to be performed before we can finalize on system
design. So, it is not one shot approach and that iteration again may take weeks. Of course, it
can be done in less time compared to the previous stages if we have a very well experienced
team and a good amount of effort is put in in this design activity, but generally it cannot be
done very quickly, it takes significant amount of time, maybe n weeks.
(Refer Slide Time: 16:38)

Coding is the next stage. Coding of course takes up its own time. So, we need to go for unit
level coding, then we need to test the code at unit level, review-based testing we need to
follow for quick feedback on the code and then we need to refine the code. Then we have to
go for rigorous testing methods that include black box testing at functional level and white
box testing at structural level.

We also keep on creating documents for all these activities. We also need to go for integration
and overall system testing. So, integration of the units or modules that we have put it as well
as the overall testing of the system that includes functional testing as well as performance
testing. In functional testing, we test for functional support with respect to the SRS document
or software requirement specification document.

Whereas in performance testing we test for several non-functional requirements that are listed
in the SRS document. This again cannot be done quickly, it requires a good amount of effort
from coding team, from testing team and it again is likely to take weeks to complete.
(Refer Slide Time: 18:00)
Usability testing, as we have seen is not very easy either or is a quick process either. How
long it can take? We need to first frame research questions that require some brainstorming,
Then we need to identify variables and design the experiment that may be done reasonably
quick manner, carrying out the actual experiment to collect data takes time depending on the
availability and intention of the participants.

Data analysis also takes some time. So overall this can also take weeks, it cannot be done in
hours or minutes or in days. However, if participants are readily available and everything is in
place, then it can be done in a single week, but in general it may take weeks to carry out.
(Refer Slide Time: 18:58)

So, each stage as we can see requires to be carried out with full rigor and that implies that the
stages are going to take significant amount of time resulting in a large turnaround time. Now,
the problem with this traditional SDLCs as we have just noted is that rigidity. So, whatever is
prescribed as part of a system, as part of a stage of the development process has to be done.
Deviations are generally not encouraged or allowed and in order to do those things that are
prescribed to be done requires time and it also entails cost.

So, this rigidity may lead to time and cost overrun. To comply with the standard practice,
time and cost overrun may happen and because of that at the end whatever we get may not be
acceptable to the customer. The customer may want them quickly, whereas because of the
rigidity of the stages and the overall process, the development team may require more time
and cost than permitted by the customer. So, at the end it makes the product unacceptable to
the customer.
(Refer Slide Time: 20:20)

Now, why this problem comes? Due to the strict requirements at each stage, we have just
seen what are those requirements, in the requirement gathering phase we have to identify all
requirements, so later on we should not focus on requirement gathering. So, first we have to
start with requirement gathering and for that we have to ensure that all the major
requirements are gathered in the requirement gathering stage itself, so that requires time.

In every stage we need to create detailed documentation that entail lots of documentations.
So, what are the documents that need to be generated for our ISLC that is what we have
already seen in previous lectures. And also, it is necessary to implement all the requirements
before the deployment. So, whatever requirements we have identified in the requirement
gathering stage needs to be implemented, tested, finalized before we go for deployment.
So, first of all we need to identify all possible requirements that itself takes time and we also
need to implement and test all those requirements before we go for deployment that takes
time plus we have this issue of detailed documentation at each stage, which also takes a
considerable amount of effort and time. So, what are those documents that we need to
develop, let us try to list. In the requirement gathering stage we have SRS which contains
both functional and non-functional requirements.

So, we have already seen how these documents look like, how it can be created, what are the
sections that are part of the document. In the design, prototype, evaluate cycle we have
designed document for interface design, then the prototypes as documents for prototypes and
test reports after each evaluation. In the system design stage, we have either DFD or UML
documents created to represent the system design.

In the coding stage, we have the code with comments plus some code related documents such
as technical manuals and user manuals, these can be created at this coding stage. In that code
testing stage, various test reports that includes review-based test report, black box test report,
white box test reports are to be generated. Now, in the reports of course you have to describe
the method and other details in each of these reports.

For example, in black box testing report you have to mention the equivalence classes, the
functions, equivalence classes for each function, test cases that you have used. All these
things have to be mentioned as we have discussed in case studies. Empirical study also
involves creation of a detailed study report incorporating the research questions, the
hypothesis, the experimental procedure, method, setup, design, then detailed statistical
significance testing method and results.

So, all these things have to be fairly and properly documented after carrying out the
corresponding stage. So, just to repeat we require several documents starting with SRS in the
requirement gathering analysis and specification stage as outcome of the stage. After the
interface and interaction design stage we produce design documents, prototype documents
and test reports.
After the system design phase, we produce DFD or UML documents to represent the design
of the system. After the coding phase, the code itself is the document with comments of
course plus some technical manual and user manuals for better understanding of the code.
After the code testing phase, we produce test reports, several test reports can be produced
depending on the amounts of tests done. So, if we are following review-based testing first,
then review-based test report.

Then if we are performing more rigorous tests such as the black box test and white box test,
then for each test the corresponding reports need to be produced with all the details of the
testing process. Finally, for empirical study we need to produce another report detailing
everything about the study including the research questions, the hypothesis, the experiment
design, method, setup and statistical significance test details. So, all these documents we have
to produce.

And somebody has to check the documents as well requiring additional manpower, additional
time, additional cost. So, you can see how rigorous and how time consuming this process is
which involves rigorous execution of the stages as well as rigorously creating the documents.
So, the result of all these things that is the strict requirements and documentation
requirements imply that if we follow traditional system development method, then it is likely
to take long amount of time.

Also it is going to entail good amount of cost because of maintaining the sanctity of the
process, the strict requirements. In order to address this issue because sometimes this time
and cost factors become very important, sometimes it is the objective of the developers to
deliver a product quickly even if that requires compromising with the development process to
some extent, but the objective is to quickly deliver the product in some acceptable condition
that brings us to this concept of agile development.
(Refer Slide Time: 27:15)
As the name suggests, agile which means fast, agile development process implies a quick
turnaround time of the end product. So, quick turnaround of the project that is what is the
primary objective of this type of developmental activities that is called agile development
process. In order to be agile, what this process does is try to eliminate unnecessary things and
documentation that may deem unnecessary at certain stages of the development.

So, although you are using the term unnecessary, which is generally used to differentiate
between traditional and agile development processes, it may be noted that this term is too
strict. The stages and the requirements need not be unnecessary if we look at it very holistic
point of view. However, in agile it is considered to be unnecessary if some requirements are
not relevant at particular stages for quick turnaround time. We will see what it means.

Other key aspect of agile development is that it relies on the philosophy of start small that
means do not try to do everything from the very beginning unlike the traditional methods
where we try to first gather all requirements in the requirement gathering stage, we try to do
all development in the development stage, so everything we try to do in a complex manner
whereas in agile that is not the philosophy. In agile, it is said that try to start with small
things.
(Refer Slide Time: 29:13)
So, how the process flow looks. You will find similarity with traditional SDLC of course in
terms of the basic concepts, but there are differences. So, it starts with conceptualization of
the overall process. This is followed by inception stage which includes creation of a team for
development purpose, arranging for funds, resources, etc. Now this is followed by an
interesting concept called iteration or sprint which is the development cycle.

We shall soon see what is there in the cycle. Once the cycle is over, it goes to the release
stage which involves testing, training and necessary documentation. This is followed by
production stage which includes ongoing support as well followed by retirement stage of the
product that is end of life activities. So, these are broadly the stages that are part of any
generic agile development process.

So, it starts with the conceptualization stage, ends at the retirement stage, in between there is
inception after conceptualization followed by iteration popularly known as sprint followed by
release followed by production. So, these stages from the core of any agile development
process.
(Refer Slide Time: 30:39)
Now, the iteration or sprint is the heart of the process, there actually the development takes
place. Now, typically in an agile development environment, the iteration should not take more
than 4 to 6 weeks. Now, of course since we are imposing some time constraint that means we
are cutting down on some strict requirements that are part of the development process, if we
follow a traditional approach. So, in this iteration what happens?

First there is some requirement gathering, so that is part of the requirements stage. In this
stage what happens is that based on the product or backlog from the previous iterations as
well as customer or stakeholders or both feedbacks, some quick requirement gathering takes
place. This is followed by the actual development process, development of the system based
on the requirements that is the coding.

This is followed by testing, testing of the things that have been developed which include
training and documentation and this is followed by delivery to the production stage and this
goes on till we finish delivering all the features in the product that are supposed to be
delivered. So, how it is different from the other development stages in traditional methods? In
traditional methods, what we try to do?

We try to gather all requirements at the beginning and try to develop all requirements in the
system before we deliver. Here what we do? We start small, we try to gather some
requirements at the beginning, develop the system, test it for those requirements only and
release it and then we continue for other requirements that is what this iteration means. So,
we do not try to gather all requirements at the beginning.
We do it in an incremental manner, in an iterative manner and at the same time we keep on
releasing updated products. So, in that way it is expected that the customers get something
after a small amount of time 4 to 6 weeks rather than waiting for the whole cycle to complete
and all the requirements are identified and developed and tested before it is given to the
customer.
(Refer Slide Time: 33:22)

So, how to make it work? How we can ensure that within 4 to 6 weeks of time we can deliver
a product starting with requirement gathering to coding to testing and finally releasing to the
customer. For that we; we means the project managers, require to conduct daily meetings of
the development team. These are some of the traditional steps that are followed to ensure that
the agile development works. Then live demo after each iteration that is required.

This is followed by feedback. So, we need to regularly collect from the stakeholders or the
customers or even the end users’ feedback and share with the team before next sprint. So that
is what I said requirements are not collected at the beginning, all the requirements, and
requirements collection also depends on feedback. So once something is developed, then
based on the feedback we can refine the requirements and then go for next iteration or next
sprint.

So, these regular collections of feedback should be part of the overall process as it helps us to
carry out the next sprint quickly just after the finishing of the earlier sprint. Remain agile that
means the team should be open to make changes based on feedback. So, it is not that now I
have developed something and whatever I have developed is very good, take it or leave it,
instead what the philosophy should be is that okay I have developed something, more can be
developed depending on feedback.

So, whenever the feedback comes, I should be ready for development with another sprint that
should be the philosophy imbibed by the team members. So, these are some things that we
need to follow to ensure that we abide by the agile development process. It involves regular
meetings regarding the sprint, live demo of the product that has been developed and tested at
the end of each iteration or sprint.

Regular feedback from stakeholders or customers or both for getting more information about
the product as well as to prepare for next sprint if required and remain agile that means, we
should have this mentality that whatever we have developed can be improved and we should
be able to improve it quickly in an agile manner depending on the feedback. These things
primarily determine whether the method that you are following can be agile or not.

Sometimes we have this mental blockage of accepting the fact that whatever we have
developed lacks something and we need to develop it again, so that needs to be removed. So,
agile development method is a very generic concept. Now there are specific technologies
developed, specific process or methods developed to implement this agile development
concept.
(Refer Slide Time: 37:03)
Some are very popular, namely the scrum which is an agile method, extreme programming or
XP another agile method very popular, disciplined agile delivery or DAD, dynamic systems
development method or DSDM, etc. So, some of these are quite popular others are not so
popular. So, if you are following a scrum method that means you are following an agile
method that is the significance of these terms.

So, that is in brief what is agile development method. Just to recap, we have learned
traditional software development methods. Now, these methods come with lots of stages.
Each of these stages needs to be carried out in a very rigorous manner and at the end of each
stage we need to produce rigorously extensive documentation, both these activities require us
to invest heavily on manpower and increases the cost of the overall project in terms of time as
well as money.

Sometimes that may make things unacceptable to the end users. In order to avoid that, this
agile development philosophy came into being. It is not very new, it is quite old now, but
many a times this methodology is followed. Here, the idea is that we do not try to do
everything at every stage, instead we start small do something, deliver it and then we go for
delivering something more unlike traditional methods where we try to deliver everything at
the end.

So, in between deliveries not considered whereas in agile method we keep on delivering to
the client things in an incremental manner that is the primary difference. In order to do that
several concepts have been introduced including the concept of iteration or sprint. Each sprint
takes about 4 to 6 weeks’ time and in each sprint what is done is some requirements are
identified, then it is developed into a system.

The system is tested and the tested system is delivered. Now, the requirements need not be all
the requirements that are there, only a few. And once the sprint is over based on the feedback,
we can go for another sprint to add more features or more requirements into the system. So,
after 4 to 6 weeks, it is expected that some products can be delivered to the clients so that
clients are also happy that is the primary idea.

And in order to make this agile method work several things need to be taken care of including
regular meetings between the team members, among the team members, then regular
feedback, open mind that whenever feedback comes based on that we should be ready to
change and live demo after each sprint. So, there are some popular methods namely Scrum,
XP, DAD, etc., which are used to follow the agile development concept.

With that, we have come to the end of this lecture. I hope you have enjoyed the material that
we have covered, although we covered it in very brief this is a very important concept, very
interesting also and it is preferable if you try to understand in more details about the concepts
that we have briefly introduced.
(Refer Slide Time: 41:05)

For more details on these concepts, you can refer to these materials, they are online materials.
The primary document is Agile manifesto. Also, you can follow these 12 agile development
principles that you can find in this link that is shown on the screen. So, apart from that if you
can get access to any book on agile development method, you are also advised to follow that
book to know more details about the method.

So, whatever method we learned that is the interactive system development lifecycle and how
it is different from agile approach that distinction by now should have been clear to you. One
thing we should keep in mind is that although I talked of agile method, but it does not mean
that the other methods, the traditional methods are useless. Sometimes the time that is
required to implement a fully traditional method may not be acceptable to the clients that
time we may have to follow an agile method.
So, we should be aware of the existence of such methods, however that does not mean that
we should totally discard the traditional development method. Knowledge of both is good,
but it is not mutually exclusive. So, we should not think that one method is sufficient, other
method we need not know. With that I would like to end this lecture. Hope you have enjoyed
the content and looking forward to meet you all in the next lecture. Thank you and goodbye.
 Design and Implementation of Human-Computer Interfaces
Dr. Samit Bhattacharya
Department of Computer Science and Engineering
Indian Institute of Technology – Guwahati

Lecture – 44
Concluding Remarks

Hello and welcome to the NPTEL MOOCS course on design and implementation of
human-computer interfaces. We are going to start our last lecture concluding lecture that is
lecture number 38. In the previous 37 lectures as well as some additional addon lectures on
case studies, we have covered several key concepts and materials related to the design and
development process of interactive systems. So, what was our goal in this course?
(Refer Slide Time: 01:29)

At the beginning, we mentioned that what we want to learn in this course is how to design
and implement human-computer interfaces. Now, human-computer interfaces are examples
of systems that are called interactive systems. So, in order to develop and implement, in order
to design and implement human-computer interfaces what we need is to know how to design
and implement interactive systems.

Here by the term system what we are referring to is a software that is to be run on some
hardware, but hardware design is not our concern here, our concern is to develop software.
So, when we talk of developing a software. What is the difference between design and
implementation of any software and design and implementation of interactive software?
When we are talking of interactive software, we have primarily two concepts.
(Refer Slide Tim: 02:36)

In general, when we are talking of developing any software, the idea is to make it efficient
from the point of view of execution. So, whether the software is executable and whether the
software is executable in an efficient manner that is the primary concern that is the concern
that we also have when we are talking about interactive system development and
implementation.

Along with that, we have another crucial concern that is the concern of usability. So, whether
our software is going to be usable. Remember that earlier we talked about the definition of
usability that is the software should be effective, efficient and satisfactory to specified group
of users in specified context of use to achieve specified goals. This is the ISO definition of
usability. So, when we are building a software, we need to ensure that the software is
effective.

Efficient and satisfactory to the target group of users to achieve a specified set of goals that
the users may have in a specified work context. So, both are very important concerns when
we are talking of design and implementation of interactive systems. Whereas, for other
systems any software which is not interactive, the primary goal is to design a system that is
executable in an efficient way.

In order to ensure that we can achieve these objectives of ensuring these two things usability
and execute stability, we need to follow some systematic development approach random ad
hoc on the fly approach may not work, mostly it will not work if we are talking of complex
real world systems. So, some systematic development approach needs to be followed which
brings us to the concept of interactive system development lifecycle.

In general that is one type of software development lifecycle, which we have studied in this
course. And we have specifically studied one such development lifecycle which we are
calling interactive system development lifecycle. It contains several stages.
(Refer Slide Time: 04:29)

First phase is the feasibility study stage. This stage we have not covered much, we just
mentioned it in the passing it is not related to our main purpose of this course. We started our
discussion with the next stage that is requirement gathering analysis and specification stage.
This is followed by the cycle design, prototype, evaluate cycle as shown here So, in this
cycle, we go for design of the interface, user interface as well as the user interaction with the
system.

We prototype that design for quick evaluation. Based on the evaluation results, we may need
to refine the design, again we prototype that refined design, go for evaluation, and this cycle
continues till we arrive at a stable design. This is followed by a system design, where we
primarily aim to come up with a modular system design and we can use functional or
object-oriented approaches to design and express the system.

This is followed by the next stage that is coding an implementation. We have discussed this
stage in details followed by the testing of the code, again we have covered it in significantly
details. This is followed by the empirical study, covered in details. Now, there are several
cycles or iterations as you can see. There is an iteration between this design, prototype,
evaluate cycle to requirement gathering cycle as shown with these two arrows marked in
cross, this should not be frequent.

The meaning of this cycle is that if in the design of interface stage, we find some issues
which are not being getting resolved then we may need to refine the requirements. We may
go for newer requirement gathering, so this cycle may happen, but it should not be frequent.
Then we have this cycle design, prototype, evaluate cycle marked with these crosses, this
may be frequently done.

Its purpose is to execute frequently so that we can arrive at a stable interface design. There is
this cycle also between empirical study to the design stage and this cycle also should not be
frequent. At the end, we have this deployment and maintenance stage, this stage also you
mentioned in brief. So, what we have covered in those stages?
(Refer Slide Time: 07:22)

In the requirements stage, we collect functional and usability requirements. Usability

requirement is collected through several methods, application of either of several methods.
One method we discuss that is contextual inquiry. In the design phase, for interface design we
may follow some design guidelines to ensure usability of the interface. For system design, we
may follow functional approach with the DFD as the language to express the design.

Or we can follow the object-oriented design approach with UML as the language to express
the design. So, UML is the language to express object-oriented design whereas DFD is the
language to express functional design. Additionally, we can use the ER or entity relationship
as part of the design to express the structure of databases in the design in functional approach.
In the prototype stage, we have covered several ways to create prototypes.

And also we have seen how to evaluate those prototypes quickly using either of cognitive
walkthrough or heuristic evaluation methods. We have learned in details these methods. In
the coding stage, we have seen several good coding practices and we have talked about what
to do and what not to do during coding. In code testing, we have covered review-based
testing, black box testing, white box testing.

We have also seen integration of different units or modules into a full system and testing the
full system for functionality as well as performance. Finally, we have covered usability
testing in details.
(Refer Slide Time: 09:09)

So, let us quickly go through the concepts that we have learned in each of these stages. In the
requirements stage what we have covered? We have learned about how to gather functional
requirements and how to analyse those requirements to come up with the specifications. Also,
we have learned about the idea of non-functional requirements, in particular usability
requirements, because that is the very crucial concept with respect to the scope of this course.

So, you have learned about usability and we have learned how to gather usability
requirements. There we talked about the contextual inquiry method. In the contextual inquiry
method if you recollect, there are 5 stages starting with planning, then approaching the
management that is called initiate, then execution that means actually collecting data.

Then close that means sending thank you notes to the participants as well as organizations
and finally reflect or analysis of the collected data. So, we have seen through several case
studies how the data can be collected, recorded and analysed.
(Refer Slide Time: 10:25)

Next, we covered the design stage. So, there we actually talked of two types of design, one is
the interface design, other one is the code or system design. So, in interface design what we
have covered?
(Refer Slide Time: 10:38)
The design, prototype, evaluate cycle that we have just mentioned in the previous slide is part
of the interface design stage. Now, we carry out this cycle to ensure usability of the design.
Usability is our primary concern. So, we ensure usability by performing this design,
prototype, evaluate cycle. Now, in the design stage design of the interface, we covered some
design guidelines.

So, when we want to design some interface either we can rely on our intuition or experience
or design guidelines or a combination of all these three. So, we covered several guidelines,
particularly two sets of guidelines, Shneiderman’s eight golden rules and Norman's seven
principles, these are generic guidelines. We have also seen there can be specific guidelines,
specific to products.

With guidelines we need to brainstorm to come up with interface design, this is followed by
building of prototype. So, we have seen that that prototypes can be of different types. We can
have low fidelity prototype which does not require any use of sophisticated technology
including computers, then we can have medium fidelity and high fidelity prototypes. We have
also seen the concepts of vertical prototypes and horizontal prototypes.

As well as how to use the prototypes incremental way, evolutionary way, throw away
prototypes; all these things we have covered. We have covered in details how to evaluate the
prototype quickly with experts who are supposed to represent the behaviour of the target user
group. Why we are going for expert evaluation? Because we want quick evaluation as we
have noted later in empirical study, if we need to get it evaluated with end users it requires
significant time and effort.

But in the early stage, we want to find out problems quickly so that we can refine and
perform the cycle several times before we stabilize the design, so they are we rely on experts
for quick evaluation with feedback. And for such an evaluation we covered in details these
methods cognitive walkthrough and heuristic evaluation. In cognitive walkthrough, we start
with usage scenario, typically representative usage scenario, ask the evaluators to carry out
those tasks in the scenario and prepare reports.

Typically, the team contains 3 to 5 members. Similar type of teams we use for heuristic
evaluation, but here instead of usage scenario, we provide the evaluators with checklist and
they check the system against the checklists and prepare reports. We have seen the 10
heuristics by Nielsen as one of the checklists and we can use that for heuristic evaluation
purpose. So, all these things we have discussed in details during the relevant lectures.
(Refer Slide Time: 13:54)

Other thing that we have learned in details is how to go for code or system design. The
objective is to ensure efficient implementation of the system. So, we have seen that the
primary way to do this is to think of the system as in the form of a hierarchy of modules with
well-defined connections between the modules. Now, we can approach this design in either
functional way or object-oriented way.

If we are following an object-oriented approach, then to express our design we can use UML,
unified modelling language. If we are following a function-oriented approach, then to express
the corresponding design we can use DFD in combination with your ER where DFD stands
for data flow diagram, ER stands for entity relationship diagram. We can use these two
together to express the design. All these things we have discussed in significant details.
(Refer Slide Time: 15:05)
Next stage that we have covered is the implementation stage. In implementation, we have
learned about good coding practices, what we should do, when we are going for
implementing a system, also what we should not do when we are going for implementing a
system. There we have learned about some simple rules like length of a function in terms of
number of instructions should not be more than 10 ideally, naming conventions of variables
of functions, how to use global variables and so on and so forth.

This was followed by detailed discussion on testing of the code. So, once we are able to
implement the system by writing code, next we need to test the code to see whether there are
any bugs, whether there are any issues. There is a quick way of testing and there is a rigorous
way of testing, we discussed both. The quick testing involves review-based testing and
rigorous testing involves more systematic way of testing.

Now, when you are developing what typically happens is that first unit level developments
take place that means at the module level, then the modules or units are combined together
into the system and the system level testing takes place. For unit level testing, we can use
review-based testing methods for quick testing to quickly know about the issues with the
code so that we can refine and go for more rigorous testing.

Two set testing methods we have seen, one is code walkthrough and the second one is code
inspection. Now code walkthrough; conceptually similar to the concept of cognitive
walkthrough that we have seen earlier in the context of prototype evaluation. Like in
cognitive walkthrough in code walkthrough, we start with a carefully selected test cases, one
or more such test cases and manually or through visual inspection we try to execute the code
for the cases and see whether there is any issue.

In code inspection we check the code for violation of standards and guidelines. This is similar
in concept to the heuristic evaluation or checklist-based evaluation for prototypes. Then, we
have learned also in details about several rigorous methods namely the black box testing
method and the white box testing method. In black box testing, the key thing is to divide the
input domain into equivalence classes and then choose the appropriate test cases, also you
need to perform boundary value analysis.

In white box testing, we decide on the test cases based on either of several approaches. We
primarily learned about path coverage approach and how it can be used to decide on test
cases. So, those are unit level testing. Also you have learned about integration and system
level testing including use of driver and stub modules for performing system level testing
while all the units are not integrated.

So, we are broadly seen that two approaches bottom-up and top-down approaches. And also
we have seen functional and performance testing of whole system as well as the other
concepts of testing, namely alpha testing, beta testing and acceptance testing.
(Refer Slide Time: 19:32)

Finally, we talked about empirical study where our objective is to test the usability of the
product. So, there are four stages of the study that we have learned in detail. One is research
question formulation. Stage number 2 is variable identification then in stage number 3 design
of experiment is done and fourth stage is data analysis. So, these are the stages through which
we carry out the empirical study.

And at the end of data analysis, we conclude about the usability of the product. Here of
course, data analysis is not a simple thing, in fact none of the stages can be done in a very ad
hoc and simple manner, it requires careful considerations as we have seen during the lectures.
So, once we follow all the stages to develop the system, what is the benefit that we get?
(Refer Slide Time: 21:11)

Now, if we follow these stages, then we can be sure that the product is usable depending on
the conclusion drawn and the product is executable that means the product can be
implemented in an efficient manner in terms of use of resources. So, both are important and
by following this lifecycle both can be ensured if we follow them properly.
(Refer Slide Time: 21:38)
But the following of stages is not the only thing and the development of the system is not the
only thing, along with that at every stage some documentation is done. Now, this
documentation has to be done very carefully, very elaborately so that the overall development
process is recorded and equally crucially the development process can be understood by
others. So, the documents should be understandable and maintainable for future maintenance
and bug fixing.

So, the software is not the only end product, along with that the documents are also there for
maintenance in future and there are several documents, not a single document. After the
requirements stage, we get this SRS plus usability requirement reports. SRS stands for
software requirements specification. After this design phase, we get this interface and code
design documents which includes documentation on prototype building.

And evaluation of prototypes, reports related to the evaluation of the prototype including the
team composition, the tasks that are given, the feedback received, compilation of those
feedbacks, etc., in every cycle. In case of code design, we create these design documents
either in the form of DFD or UML. Then, we generate code testing documents, for each type
of testing documents should be generated.

For example, if you are performing review-based testing also then documentation related to
that, if you are performing black box testing documentation related to that, if you are
performing white box testing documentation related to that, everything you need to generate.
Now, usability study reports that is empirical study reports has to be produced at the end of
empirical study stage outlining in details everything related to the study.

Including research questions, hypotheses, experimental procedure setup, design of

experiment and how the data were analysed. Along with that, we need to also create the user
documents, user manuals and technical manuals. So, user manual is to help the user
understand the system features and technical manual is required to further understand the
code as well as update the code if required.

Help documents are also useful that is part of user manuals, you can think of it as part of user
manuals. So, we have covered several case studies to see how these documents look like. We
have explicitly discussed how these documents look like for SRS, four testing documents, for
design documents which are primary components of these types of documents. So, along with
the software, this document creation is also very important for recording the process for
future maintenance purpose.
(Refer Slide Time: 25:14)

So, both are important; the execution of the process as well as creation of the documents. If
we follow the process properly with required rigor and if we create the documents properly
then that ensures that we end up with a usable and executable end product that is
maintainable and also acceptable. So, four key words are important here; usable, executable,
maintainable and acceptable.
All these four are important and if we follow these stages in a systematic manner with all the
required rigor and the documentation properly, then we can ensure that all these four
keywords are satisfied. However, as we have discussed in the previous lecture, sometimes
following this development lifecycle may require long time and involve cost which may not
be acceptable to the end users, in that case we may have to go for some compromise, we may
have to go for agile development methods that is also possible.

So, with that we have come to the end of this course. I hope you have learned all the
concepts. I hope the lectures were good learning experiences and I also hope that by going
through these lectures, by covering this course, you are now in a better position to understand
the development process of an interactive system. And also, you are now ready to develop
and deploy your own system which is a human-computer interface or in other words another
interactive system.

For example, if you are now trying to make a game, a video game, then you know what are
the things to do and you are expected to follow those things so that your game is acceptable
to those who want to play such games. You must remember that whenever you are building a
product and usable product, it need not be usable to everybody. So, if you are building a
game, it need not be visible to everybody, only to those who are interested in similar type of
games.

So for that you need to properly identify the requirements and you need to properly go
through all the stages to develop the usable end product which is also executable. We
generally have this tendency of only focusing on executability of the software, whether it can
run on a given system rather than focusing on usability. So, through the lectures and
throughout this course, my objective is to also emphasize on the point that along with
executability, a software which is interactive needs to be usable also.

So for that whatever is needed to be done you have to do. And I hope by now you are quite
aware of the things that need to be done to make the product usable as well as executable and
you will be able to translate that knowledge into practice. With that hope I would like to end
this lecture as well as this course. Hope you have enjoyed the course. Thank you and
goodbye.