UNIT-3

DESIGN ENGINEERING
Design Engineering
 Introduction to Design process
 Design quality
 Design concepts
 The design model
 1.INTRODUCTION TO DESIGN
PROCESS
 There are two major phases to any design process: diversification
and convergence. Diversification is the acquisition of a repertoire
of alternatives, the raw material of design: components,
component solutions, and knowledge contained in catalogs,
textbooks, and the mind.
 During convergence, the designer chooses and combines
appropriate elements from this repertoire to meet the design
objectives, as stated in the requirements document and as agreed
to by the customer.
 The second phase is the gradual elimination of all but one
particular configuration of components, and thus the creation of
the final product.
 Purpose of Design
 Design is where customer requirements, business needs, and
technical considerations all come together in the formulation of a
product or system
 The design model provides detail about the software data
structures, architecture, interfaces, and components
 The design model can be assessed for quality and be improved
before code is generated and tests are conducted
 Does the design contain errors, inconsistencies, or omissions?

 Are there better design alternatives?

 Can the design be implemented within the constraints, schedule,

and cost that have been established?
 A designer must practice diversification and convergence
 The designer selects from design components, component
solutions, and knowledge available through catalogs,
textbooks, and experience
 The designer then chooses the elements from this
collection that meet the requirements defined by
requirements engineering and analysis modeling
 Convergence occurs as alternatives are considered and
rejected until one particular configuration of components
is chosen
 Software design is an iterative process through
which requirements are translated into a
blueprint for constructing the software
 Design begins at a high level of abstraction
that can be directly traced back to the data,
functional, and behavioral requirements
 As design iteration occurs, subsequent
refinement leads to design representations at
much lower levels of abstraction
From Analysis Model to Design Model

 Each element of the analysis model provides information that is

necessary to create the four design models
 The data/class design transforms analysis classes into design
classes along with the data structures required to implement the
software
 The architectural design defines the relationship between major
structural elements of the software; architectural styles and
design patterns help achieve the requirements defined for the
system
 The interface design describes how the software communicates
with systems that interoperate with it and with humans that use
it
The component-level design transforms structural
elements of the software architecture into a procedural
description of software components
Component-level Design

(Class-based model, Flow-oriented model

Behavioural model)

Interface Design

(Scenario-based model, Flow-oriented model

Behavioural model)

Architectural Design

(Class-based model, Flow-oriented model)

Data/Class Design

(Class-based model, Behavioral model)

 DESIGN QUALITY
Through out the design process, the quality of the design
process is assessed with a series of formal technical
reviews or design walkthroughs.
The three characteristics of a good design.
The deign must implement all explicit requirements of the
analysis model and implicit requirements of the customer.
It must be readable ,understandable for the
programmers, testers and maintenance people.
It should provide the complete picture of the software
addressing the data, functional and behavioral domains
from an implementation perspective.
Design Quality Guidelines
 A design should exhibit an architecture that
 Has been created using recognizable architectural styles or
patterns
 Is composed of components that exhibit good design
characteristics
 Can be implemented in an evolutionary fashion, thereby
facilitating implementation and testing
 A design should be modular; that is, the software should be
logically partitioned into elements or subsystems
 A design should contain distinct representations of data,
architecture, interfaces, and components
 A design should lead to data structures that
are appropriate for the classes to be
implemented and are drawn from
recognizable data patterns
 A design should lead to components that

exhibit independent functional characteristics

 A design should lead to interfaces that reduce
the complexity of connections between
components and with the external environment
 A design should be derived using a
repeatable method that is driven by
information obtained during software
requirements analysis
 A design should be represented using a

notation that effectively communicates its

meaning
Quality Attributes
Hewlett-Packard developed a set of software quality factors that has been given the
acronym FURPS—functionality, usability, reliability, performance, and supportability.

• Functionality is assessed by evaluating the feature set and capabilities of the program,
the generality of the functions that are delivered, and the security of the overall system.

• Usability is assessed by considering human factors , overall (look)aesthetics, consistency,

and documentation.

• Reliability is evaluated by measuring the frequency and severity of failure, the

accuracy of output results, the mean-time-to-failure (MTTF), the ability to recover from
failure, and the predictability of the program.

• Performance is measured by processing speed, response time, resource consumption,

throughput, and efficiency.

• Supportability combines the ability to extend the program (extensibility),

adaptability, serviceability—these three attributes represent a more common term,
maintainability—in addition, testability, compatibility, configurability , the ease with
which a system can be installed, and the ease with which problems can be localized.
 3. DESIGN CONCEPTS
 Abstraction
 Procedural abstraction – a sequence of instructions that have a
specific and limited function
 Data abstraction – a named collection of data that describes
a data object
 Architecture
 The structure or organization of program components and the
way in which they interact and the data structures used by the
components.
 Consists of components, connectors, and the relationship
between them
 Patterns
A design structure that solves a particular design
problem within a specific context
 It provides a description that enables a designer to
determine whether the pattern is applicable, whether
the pattern can be reused, and whether the pattern
can serve as a guide for developing similar patterns
 Modularity
 Separately named and addressable components (i.e.,
modules) that are integrated to satisfy requirements
(divide and conquer principle)
  It is the attribute of the software that Makes software
intellectually manageable so that the control paths, span
of reference, number of variables, and overall
complexity is grasped by the engineer.
 Information hiding
 Designing of modules must be such that the algorithms
and local data contained within them are inaccessible to
other modules
 This enforces access constraints to both procedural (i.e.,
implementation) detail with in a module and local data
structures used by the module.
 Functional independence
 Modules that have a "single-minded" function and an
aversion to excessive interaction with other modules
  High cohesion – a module performs only a
single task
 Low coupling – a module has the lowest amount
of connection needed with other modules
 Stepwise refinement

 Development of a program by successively

refining levels of procedure detail
 Complements abstraction, which enables a
designer to specify procedure and data and
yet suppress low-level details
 Refactoring
 A reorganization technique that simplifies the design (or
internal code structure) of a component without changing its
function or external behaviour
 Removes redundancy, unused design elements, inefficient or
unnecessary algorithms, poorly constructed or inappropriate
data structures, or any other design failures
 Design classes
 Refines the analysis classes by providing design detail that will
enable the classes to be implemented
 Creates a new set of design classes that implement a software
infrastructure to support the business solution
 Types of Design Classes

 User interface classes – define all abstractions necessary

for human-computer interaction (usually via metaphors of
real-world objects)
 Business domain classes – refined from analysis classes;
identify attributes and services (methods) that are
required to implement some element of the business
domain
 Process classes – implement business abstractions
required to fully manage the business domain classes
 Persistent classes – represent data stores
(e.g., a database) that will persist beyond the
execution of the software
 System classes – implement software
management and control functions that enable
the system to operate and communicate within
its computing environment and the outside
world
Characteristics of a Well-Formed Design
Class

 Complete and sufficient

 Contains the complete encapsulation of all attributes
and methods that exist for the class
 Contains only those methods that are sufficient to
achieve the intent of the class
 Primitiveness
 Each method of a class focuses on accomplishing one
service for the class
 High cohesion
 The class has a small, focused set of responsibilities and single-
mindedly applies attributes and methods to implement those
responsibilities
 Low coupling
 Collaboration of the class with other classes is kept to an
acceptable minimum
 Each class should have limited knowledge of other classes in
other subsystems
 DESIGN MODEL

 The design model can be viewed in two

different dimensions
 (Horizontally) The process dimension indicates
the evolution of the parts of the design model
as each design task is executed
 (Vertically) The abstraction dimension
represents the level of detail as each element
of the analysis model is transformed into the
design model and then iteratively refined
 Dimensions of the Design Model

High
Abstraction Dimension

Analysis model

Design model

Data/Class Architectural Interface Component-level Deployment-level

Low Elements Elements Elements Elements Elements

Process Dimension (Progression)

 Elements of the design model use many of the same UML
diagrams used in the analysis model
 The diagrams are refined and elaborated as part of the
design More implementation-specific detail is provided
 Emphasis is placed on

 Architectural structure and style

 Interfaces between components and the outside world
 Components that reside within the architecture
 Design model elements are not always developed in a sequential
fashion
 Preliminary architectural design sets the stage

 It is followed by interface design and component-level design,

which often occur in parallel
 The design model has the following layered
elements
 Data/class design
 Architectural design
 Interface design
 Component-level design

 Deployment-level design
 The design model was represented as a pyramid. The symbolism
of this shape is important. A pyramid is an extremely stable
object with a wide base and a low center of gravity.
 Like the pyramid, we want to create a software design that is
stable. Component-level Design

Interface Design

Architectural Design

Data/Class Design
Design Elements

 Data/class design
 Creates a model of data and objects that is represented at a
high level of abstraction
 Architectural design
 Depicts the overall layout of the software

 Interface design
 Tells how information flows into and out of the system and how
it is communicated among the components defined as part of
the architecture
 Includes the user interface, external interfaces, and internal
interfaces
 Component-level design elements
 Describes the internal detail of each software
component by way of data structure definitions,
algorithms, and interface specifications
 Deployment-level design elements
 Indicates how software functionality and subsystems
will be allocated within the physical computing
environment that will support the software
Creating an Architectural Design

Software Architecture
 Data design

 architectural styles &patterns

 Architectural design process

1.INTRODUCTION OF SOFTWARE ARCHITECTURE

Definitions
 The software architecture of a program or computing
system is the structure or structures of the system which
comprise
 The software components

 The externally visible properties of those components

 The relationships among the components

 Software architectural design represents the structure of

the data and program components that are required to
build a computer-based system
Architecture enables a software engineer
 1.Analyze the effectiveness of the design in
meeting it’s stated requirements.
 2.Reduce the risk associated with the construction

of the software.
 3.Consider architectural alternatives.
 Why is Architecture important?

Architecture allows communication between all

parties (stakeholders)
It highlights early design decisions that will have
high impact on software engineering work
It is a simple model about how the system is
structured and how it’s components work together.
2.DATA DESIGN

 Data design creates a model of data that is represented

at a high level of abstraction (the customer/user’s view
of data).
Purpose of Data Design:
 Data design translates data objects defined as part of

the analysis model into

 Data structures at the software component level

 A possible database architecture at the application

level
 It focuses on the representation of data
structures that are directly accessed by
one or more software components
 The challenge is to store and retrieve the
data in such way that useful information
can be extracted from the data
environment
Data Design Principles:

 All data structures and the operations to be

performed on each one should be identified
 A mechanism for defining the content of each

data object should be established and used to

define both data and the operations applied
to it-like UML
 Low-level data design decisions should be deferred until
late in the design process
 The representation of a data structure should be known
only to those modules that must make direct use of the
data contained within the structure
 A library of useful data structures and the operations
that may be applied to them should be developed
 A software programming language should support the
specification and realization of abstract data types
 Architectural styles and patterns
An architectural pattern is a general, reusable
solution to a commonly occurring problem in software
architecture within a given context. It is same as
Architectural style but focuses on only one aspect of
the architecture. It describes how it will handle some
aspect of it’s functionality.

An architectural style is transformation that is

imposed on the entire system.
The intent is to establish a structure for all
components of a system
 Architectural styles

in (1)data-centered architecture, the data is

centralized and accessed frequently by other
components, which modify data.
The main purpose of this style is to achieve
integrality of data.
Data-centered architecture consists of different
components that communicate through shared data
repositories.
1.Data centered Architecture
The (2)data flow architecture is applied when
input data is to be transformed through a series
of computational components into output data.

Pipes transmit the data from one component to

other component

Filter:it takes some input ,tranforms and gives

output.
2.Data flow Architecture
The (3)call and return architecture allows a
designer to achieve a program structure that is easy to
modify and scale.

Two sub styles exist within this category

1.Main program/sub program architecture
as in the figure.Like a ‘C’ program
2.Remote procedure call architecture.
The components are distributed across
multiple computers on a network.
4.Object-oriented type system

 Emphasizes the bundling of data and how to

manipulate and access data
 Keeps the internal data representation
hidden and allows access to the object only
through provided operations
 Permits inheritance and polymorphism
 5.Layered architecture
 Assigns components to layers in order to control inter-component
interaction
 Only allows a layer to communicate with its immediate
neighbor
 Assigns core functionality such as hardware interfacing or
system kernel operations to the lowest layer
 Builds each successive layer on its predecessor, hiding the lower
layer and providing services for the upper layer
 Is compromised by layer bridging that skips one or more layers
to improve runtime performance
 Use this style when the order of computation is fixed, when
interfaces are specific, and when components can make no useful
progress while awaiting the results of request to other components
ARCHITECTURAL DESIGN PROCESS

Architectural Design Steps

 Represent the system in context

 Define archetypes

 Refine the architecture into components

 Describe instantiations of the system

"A doctor can bury his mistakes, but an architect can only advise
his client to plant vines." Frank Lloyd Wright
ARCHITECTURAL DESIGN PROCESS
The software to be developed must be put
into context.i.e it should define the external
entities like other systems, devices and people
that the software interacts and the nature of
the interaction.
This can be acquired from analysis model and
requirements engineering information.
Representing the System in Context

"Super"ordinate systems

Used by
I/F I/F I/F
Uses

Target system
Produces or
Produces or consumes Peers
Actors consumes I/F I/F
Depends on

"Sub"ordinate systems
 Use an architectural context diagram (ACD) that
shows
 The identification and flow of all information
into and out of a system
 The specification of all interfaces
 Any relevant support processing from/by other
systems
 An ACD models the manner in which software
interacts with entities external to its boundaries
 An ACD identifies systems that interoperate with the target system
 Super-ordinate systems

 Use target system as part of some higher level processing

scheme
 Sub-ordinate systems

 Used by target system and provide necessary data or

processing
 Peer-level systems

 Interact on a peer-to-peer basis with target system to

produce or consume data
 Actors

 People or devices that interact with target system to produce

or consume data
Define Archetypes
 Archetypes indicate the important abstractions within the problem
domain (i.e., they model information)
 An archetype is a class or pattern that represents a core
abstraction that is critical to the design of an architecture for the
target system
 It is also an abstraction from a class of programs with a common
structure and includes class-specific design strategies and a
collection of example program designs and implementations
 Only a relatively small set of archetypes is required in order to
design even relatively complex systems
 The target system architecture is composed of these archetypes
 They represent stable elements of the architecture

 They may be instantiated in different ways based on the

behavior of the system
 They can be derived from the analysis class model

 The archetypes and their relationships can be illustrated in a UML

class diagram
Refine the Architecture into Components

 Based on the archetypes, the architectural designer refines the

software architecture into components to illustrate the overall
structure and architectural style of the system
 These components are derived from various sources
 The application domain provides application components, which
are the domain classes in the analysis model that represent
entities in the real world
 The infrastructure domain provides design components (i.e.,
design classes) that enable application components but have no
business connection
  Examples: memory management, communication, database,
and task management
 The interfaces in the ACD imply one or more specialized
components that process the data that flow across the interface
 A UML class diagram can represent the classes of the refined
architecture and their relationships
Describe Instantiations of the System

 An actual instantiation of the architecture is developed by

applying it to a specific problem
 This demonstrates that the architectural structure, style and
components are appropriate
 A UML component diagram can be used to represent this
instantiation
Performing user interface design

Background
 Interface design focuses on the following
 The design of interfaces between software
components
 The design of interfaces between the software
and other nonhuman producers and consumers
of information
 The design of the interface between a human
and the computer
 Graphical user interfaces (GUIs) have
helped to eliminate many of the most
horrific interface problems
 However, some are still difficult to learn,
hard to use, confusing, counterintuitive,
unforgiving, and frustrating
 User interface analysis and design has to
do with the study of people and how they
relate to technology
 A Spiral Process

• User interface development follows a spiral process

 Interface analysis (user, task, and environment
analysis)
 Focuses on the profile of the users who will interact
with the system
 Concentrates on users, tasks, content and work
environment
 Studies different models of system function (as
perceived from the outside)
 Delineates the human- and computer-oriented
tasks that are required to achieve system
function
 Interface design
Defines a set of interface objects and actions
(and their screen representations) that enable
a user to perform all defined tasks in a
manner that meets every usability goal
defined for the system
Interface construction
 Begins with a prototype that enables usage scenarios to be
evaluated
 Continues with development tools to complete the
construction
 Interface validation
 The ability of the interface to implement every user task
correctly, to accommodate all task variations, and to
achieve all general user requirements
The degree to which the interface is easy to
use and easy to learn
The users' acceptance of the interface as a
useful tool in their work
Golden rules
Theo Mandel [MAN97] coins three “golden rules”:
1. Place the user in control.
2. Reduce the user’s memory load.
3. Make the interface consistent.
 These golden rules actually form the basis for a set
of user interface design principles that guide this
important software design activity.
Place the User in Control

 Define interaction modes in a way that does not force a user into
unnecessary or undesired actions
 The user shall be able to enter and exit a mode with little or
no effort (e.g., spell check  edit text  spell check)
 Provide for flexible interaction
 The user shall be able to perform the same action via
keyboard commands, mouse movement, or voice recognition
 Allow user interaction to be interruptible and "undoable
 The user shall be able to easily interrupt a sequence of
actions to do something else (without losing the work that has
been done so far)
 The user shall be able to "undo" any action
 Streamline interaction as skill levels advance and
allow the interaction to be customized
 The user shall be able to use a macro mechanism to perform a
sequence of repeated interactions and to customize the interface
 Hide technical internals from the casual user
 The user shall not be required to directly use operating system, file
management, networking. etc., commands to perform any actions.
Instead, these operations shall be hidden from the user and
performed "behind the scenes" in the form of a real-world
abstraction
 Design for direct interaction with objects that appear
on the screen
 The user shall be able to manipulate objects on the screen in a
manner similar to what would occur if the object were a physical
thing (e.g., stretch a rectangle, press a button, move a slider)
Reduce the User's Memory Load
 Reduce demand on short-term memory
 The interface shall reduce the user's requirement to remember
past actions and results by providing visual cues of such actions
 Establish meaningful defaults
 The system shall provide the user with default values that make
sense to the average user but allow the user to change these
defaults
 The user shall be able to easily reset any value to its original
default value
 The visual layout of the interface should be based on a real world
metaphor
 The screen layout of the user interface shall contain well-
understood visual cues that the user can relate to real-world
actions
 Disclose information in a progressive fashion
 When interacting with a task, an object or some behavior, the
interface shall be organized hierarchically by moving the user
progressively in a step-wise fashion from an abstract concept
to a concrete action.
Make the Interface Consistent
 The interface should present and acquire information in a consistent
fashion
 All visual information shall be organized according to a design
standard that is maintained throughout all screen displays
 Input mechanisms shall be constrained to a limited set that is used
consistently throughout the application
 Mechanisms for navigating from task to task shall be consistently
defined and implemented
 Allow the user to put the current task into a meaningful context
 The interface shall provide indicators (e.g., window titles,
consistent color coding) that enable the user to know the
context of the work at hand
 The user shall be able to determine where he has come from
and what alternatives exist for a transition to a new task
Reconciling Four Different Models
 Four different models come into play when a user interface is
analyzed and designed
 User profile model – Established by a human engineer or
software engineer
 Design model – Created by a software engineer

 Implementation model – Created by the software implementers

 User's mental model – Developed by the user when interacting

with the application
 The role of the interface designer is to reconcile these differences
and derive a consistent representation of the interface
 User Profile Model

 Establishes the profile of the end-users of the system

 Based on age, gender, physical abilities, education, cultural or ethnic
background, motivation, goals, and personality
 Considers syntactic knowledge of the user
 The mechanics of interaction that are required to use the interface effectively
 Considers semantic knowledge of the user
 The underlying sense of the application; an understanding of the functions that
are performed, the meaning of input and output, and the objectives of the
system
 Categorizes users as
 Novices

 No syntactic knowledge of the system, little semantic

knowledge of the application, only general computer usage
 Knowledgeable, intermittent users

 Reasonable semantic knowledge of the system, low recall of

syntactic information to use the interface
 Knowledgeable, frequent users

 Good semantic and syntactic knowledge (i.e., power user),

look for shortcuts and abbreviated modes of operation
Design Model
 Derived from the analysis model of the requirements
 Incorporates data, architectural, interface, and procedural
representations of the software
 Constrained by information in the requirements specification that
helps define the user of the system
 Normally is incidental to other parts of the design model
 But in many cases it is as important as the other parts
Implementation Model

 Consists of the look and feel of the interface combined with all
supporting information (books, videos, help files) that describe
system syntax and semantics
 Strives to agree with the user's mental model; users then feel
comfortable with the software and use it effectively
 Serves as a translation of the design model by providing a
realization of the information contained in the user profile model
and the user’s mental model
User's Mental Model
 Often called the user's system perception
 Consists of the image of the system that users carry in their
heads
 Accuracy of the description depends upon the user’s profile
and overall familiarity with the software in the application
domain
 USER INTERFACE ANALYSIS AND DESIGN

Elements of the User Interface

 To perform user interface analysis, the practitioner needs to

study and understand four elements

 The users who will interact with the system through the
interface
 The tasks that end users must perform to do their work

 The content that is presented as part of the interface

 The work environment in which these tasks will be

conducted
 User Analysis

 The analyst strives to get the end user's

mental model and the design model to
converge by understanding
The users themselves
How these people use the system
 Information can be obtained from
 User interviews with the end users

 Sales input from the sales people who interact with

customers and users on a regular basis
 Marketing input based on a market analysis to
understand how different population segments might
use the software
 Support input from the support staff who are aware
of what works and what doesn't, what users like and
dislike, what features generate questions, and what
features are easy to use
User Analysis Questions
 Are the users trained professionals, technicians, clerical
or manufacturing workers?
 What level of formal education does the average user
have?
 Are the users capable of learning on their own from
written materials or have they expressed a desire for
classroom training?
 Are the users expert typists or are they keyboard
phobic?
 What is the age range of the user community?
 Will the users be represented predominately by one
gender?
 How are users compensated for the work they
perform or are they volunteers?
 Do users work normal office hours, or do they work
whenever the job is required?
 Is the software to be an integral part of the work
users do, or will it be used only occasionally?
 What is the primary spoken language among users?
 What are the consequences if a user
makes a mistake using the system?
 Are users experts in the subject matter that
is addressed by the system?
 Do users want to know about the
technology that sits behind the interface?
 Task Analysis and Modeling

 Task analysis strives to know and understand

 The work the user performs in specific
circumstances
 The tasks and subtasks that will be performed
as the user does the work
 The specific problem domain objects that the
user manipulates as work is performed
 The sequence of work tasks (i.e., the workflow)
 The hierarchy of tasks
 Use cases
Show how an end user performs some
specific work-related task
Enable the software engineer to extract
tasks, objects, and overall workflow of the
interaction
Helps the software engineer to identify
additional helpful features
Content Analysis
 The display content may range from character-
based reports, to graphical displays, to
multimedia information
 Display content may be

 Generated by components in other parts of

the application
 Acquired from data stored in a database that
is accessible from the application
 Transmitted from systems external to the
application in question
 The format and aesthetics of the content (as it is
displayed by the interface) needs to be
considered
 A set of questions should be answered during
content analysis
Content Analysis Guidelines

 Are various types of data assigned to consistent

locations on the screen (e.g., photos always in upper
right corner)?
 Is proper on-screen identification assigned to all
content?
 Can large reports be partitioned for ease of
understanding?
 Are mechanisms available for moving directly to
summary information for large collections of data?
 Is graphical output scaled to fit within the bounds of
the display device that is used?
 How is color used to enhance understanding?
 How are error messages and warnings presented in
order to make them quick and easy to see and
understand?
Work Environment Analysis

 Software products need to be designed to fit into the work

environment, otherwise they may be difficult or frustrating to use
 Factors to consider include
 Type of lighting

 Display size and height

 Keyboard size, height and ease of use

 Mouse type and ease of use

Surrounding noise
Space limitations for computer and/or
user
Weather or other atmospheric conditions
Temperature or pressure restrictions
Time restrictions (when, how fast, and for
how long)
 INTERFACE DESIGN STEPS
 User interface design is an iterative process, where each iteration
elaborate and refines the information developed in the preceding
step
 General steps for user interface design
 Using information developed during user
interface analysis, define user interface objects
and actions (operations)
 Define events (user actions) that will cause the
state of the user interface to change; model this
behavior
  Depict each interface state as it will actually
look to the end user
 Indicate how the user interprets the state of the
system from information provided through the
interface
 During all of these steps, the designer must

 Always follow the three golden rules of user

interfaces
 Model how the interface will be implemented
 Consider the computing environment that will be
used
Interface Objects and Actions
 Interface objects and actions are obtained from a
grammatical parse of the use cases and the software
problem statement
 Interface objects are categorized into : source, target,
and application
 A source object is dragged and dropped into a
target object such as to create a hardcopy of a
report
 An application object represents application-specific
data that are not directly manipulated as part of
screen interaction such as a list
 After identifying objects and their actions,
an interface designer performs screen
layout which involves
Graphical design and placement of icons
Definition of descriptive screen text
Specification and titling for windows
Definition of major and minor menu items
Specification of a real-world metaphor to
follow
Design Issues to Consider
 System response time
 User help facilities
 When is it available, how is it accessed, how is it
represented to the user, how is it structured, what
happens when help is exited
 Error information handling

How meaningful to the user, how descriptive of the

problem
 Menu and command labeling
Consistent, easy to learn, accessibility,
internationalization
Guidelines for Error Messages

 The message should describe the problem in plain

language that a typical user can understand
 The message should provide constructive advice

for recovering from the error

 The message should indicate any negative

consequences of the error (e.g., potentially

corrupted data files) so that the user can check to
ensure that they have not occurred (or correct
them if they have)
 The message should be accompanied by an
audible or visual cue such as a beep, momentary
flashing, or a special error color
 The message should be non-judgmental

 The message should never place blame on the

user
 USER INTERFACE EVALUATION

 Once an operational user interface

prototype has been created, it must be
evaluated to determine whether it meets
the needs of the user.
 1.The length and complexity of the
written specification of the system and its
interface provide an indication of the
amount of learning required by users of
the system.
 2. The number of user tasks specified and
the average number of actions per task
provide an indication of interaction time
and the overall efficiency of the system.
 3. The number of actions, tasks, and system states
indicated by the design model imply the memory
load on users of the system.
 4. Interface style, help facilities, and error handling
protocol provide a general indication of the
complexity of the interface and the degree to
which it will be accepted by the user.