Software Engineering

-Amruta Patil

This courseware material are to be used in conjunction with "Software Engineering: A practioner's Appraoch" 7/e and
are provided with permission by R.S. Pressman and associates. The course material is also havind contents copied
from internet. Changes are made wrt Pune University Syllabus
Design Engineering
UNIT-III
 Design Engineering
• Software design encompasses the set of principles, concepts, and practices that lead to the development of
a high-quality system or product.
• Design is pivotal to successful software engineering.
• The goal of design is to produce a model or representation that exhibits firmness, commodity, and delight.
• Software design sits at the technical kernel of software engineering and is applied regardless of the software
process model that is used.
• Software design is the last software engineering action within the modeling activity and sets the stage for
construction (code generation and testing).
• Each of the elements of the requirements provides information that is necessary to create the four design
models required for a complete specification of design.
The flow of information during software design is illustrated in Figure.
The data/class design:
• It transforms class models into design class realizations and the requisite data
structures required to implement the software.
• The objects and relationships defined in the CRC diagram and the detailed
data content depicted by class attributes and other notation provide the basis
for the data design action.
• Part of class design may occur in conjunction with the design of software
architecture.
• More detailed class design occurs as each software component is designed.
The architectural design:
• It defines the relationship between major structural elements of the software, the
architectural styles and design patterns that can be used to achieve the
requirements defined for the system, and the constraints that affect the way in
which architecture can be implemented.
• The architectural design representation—the framework of a computer-based
system—is derived from the requirements model.

The interface design:

• It describes how the software communicates with systems that interoperate with
it, and with humans who use it.
• An interface implies a flow of information (e.g., data and/or control) and a specific
type of behavior.
• Therefore, usage scenarios and behavioral models provide much of the information
required for interface design.
The component-level design:
• It transforms structural elements of the software architecture into a procedural
description of software components.
• Information obtained from the class-based models, flow models, and behavioral
models serve as the basis for component design
 Design Process & Quality
• An iterative process through which requirements are translated into a “blueprint” for
constructing the software
• Software Quality:
• Three characteristics/goal for the evaluation of a good design:
1. The design must implement all of the explicit requirements contained in the
requirements model, along with all of the implicit requirements desired by
stakeholders.
2. The design must be a readable, understandable guide for those who developers and
testers and subsequently support the software.
3. The design should provide a complete picture of the software, addressing the data,
functional, and behavioral domains from an implementation perspective
Quality Guidelines:
1. A design should exhibit an architecture that
(1) has been created using recognizable architectural styles or patterns,
(2) is composed of components that exhibit good design characteristics
(3) can be implemented in an evolutionary fashion, thereby facilitating implementation and testing.
2. A design should be modular - the software should be logically partitioned into elements or subsystems.
3. A design should contain distinct representations of data, architecture, interfaces, and components.
4. A design should lead to data structures that are appropriate for the classes to be implemented
5. A design should lead to components that exhibit independent functional characteristics.
6. A design should lead to interfaces that reduce the complexity of connections between components and
with the external environment.
7. A design should be derived using a repeatable method that is driven by information obtained during
software requirements analysis.
8. A design should be represented using a notation that effectively communicates its meaning.
Quality Attributes:

Hewlett-Packard developed a set of software quality attributes that has been given the
acronym FURPS –

1. 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.
2. Usability is assessed by considering human factors, overall aesthetics, consistency, and
documentation.
3. 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.
4. Performance is measured by considering processing speed, response time, resource
consumption, throughput, and efficiency.
5. Supportability combines the ability to extend the program (extensibility), adaptability,
serviceability—these three attributes represent a more common term, maintainability—and
in addition, testability, compatibility, configurability.
 Design Concepts
Software design concepts span both traditional and object-oriented software development
1. Abstraction:
A modular solution for any problem has many levels of abstraction.
a) Highest level - a solution is stated in broad terms
b) lower level - more detailed description of the solution is provided
c) lowest level - the solution is stated in a manner that can be directly implemented.
Two types:
a) Procedural abstraction: A sequence of instructions that have a specific and limited function.
Ex: Open the door
a) Data abstraction: A named collection of data that describes a data object.
Ex: Door is a data object
A set of attributes e.g. door type, swing direction, opening mechanism, weight, dimensions
2. Architecture:
Architecture is the structure or organization of program components or modules, the manner in
which these components interact, and the structure of data that are used by the components.
A set of properties that should be specified as part of an architectural design:
a) Structural properties – the components of a system (e.g., modules, objects, filters) and the
manner in which those components are packaged and interact with one another.
b) Extra-functional properties – how the design architecture achieves requirements for
performance, capacity, reliability, security, adaptability, and other system characteristics.
c) Families of related systems - the design should have the ability to reuse architectural building
blocks.

The architectural design can be represented using one or more of a number of different models
a) Structured Models - an organized collection of program components
b) Framework Models - by attempting to identify repeatable architectural design frameworks
c) Dynamic Models - the behavioral aspects of the program architecture
d) Process Models - focus on the design of the business or technical process
e) Functional Models - represent the functional hierarchy of a system
3) Patterns:
A design pattern describes a design structure that solves a particular design problem within a specific context.
The intent of each design pattern is to provide a description that enables a designer to determine
(1) whether the pattern is applicable to the current work
(2) whether the pattern can be reused (hence, saving design time), and
(3) whether the pattern can serve as a guide for developing a similar, but functionally or structurally
different pattern.

4) Separation of Concerns:
• A concern is a feature or behavior that is specified as part of the requirements model for the software.
• It suggests that any complex problem can be more easily handled if it is subdivided into pieces that can each
be solved and/or optimized independently.
• Divide-and-conquer strategy for software modularity

5) Modularity:
• Software is divided into separately named and addressable components i.e. modules, which are integrated
to satisfy problem requirements.
• Monolithic software cannot be easily grasped by a software engineer.
• Modularity reduce the cost required to build the software.
 Fig: Modularity and
the software cost

You should modularize a design so that

• development can be more easily planned
• software increments can be defined and delivered
• changes can be more easily accommodated
• testing and debugging can be conducted more efficiently
• long-term maintenance can be conducted without serious side effects.
6) Information Hiding:
• modules be “characterized by design decisions that (each) hides from all others.”
• Hiding defines and enforces access constraints to both procedural detail within a module and any local data structure
used by the module.
• most data and procedural detail are hidden from other parts of the software.

7) Functional Independence:
• Functional independence is achieved by developing modules with “singleminded” function and an “aversion” to
excessive interaction with other modules
• One should design software so that each module addresses a specific subset of requirements.
• Independent modules are easier to maintain and test.
• Independence is assessed using two qualitative criteria
a) Cohesion - an indication of the relative functional strength of a module
b) Coupling - an indication of the relative interdependence among modules
• In software design, you should strive for the lowest possible coupling.

8) Refinement:
• Refinement is a process of elaboration.
• Elaborate on the original statement, providing more and more detail as each successive refinement occurs.
• Abstraction and refinement are complementary concepts.
• Refinement helps you to reveal low-level details as design progresses
9) Aspects:
• As requirements analysis occurs, a set of “concerns” is uncovered.
• An aspect is a representation of a crosscutting concern.
• It is important to identify aspects so that the design can properly accommodate them as refinement and
modularization occur.

10) Refactoring:
• Refactoring is a reorganization technique that simplifies the design (or code) of a component without changing its
function or behavior.
• When software is refactored, the existing design is examined for redundancy

11) Object-Oriented Design Concepts:

• Design concepts such as classes and objects, inheritance, messages, and polymorphism

12) Design Classes:

Five different types of design classes, each representing a different layer of the design architecture,
• User interface classes - HCI
• Business domain
• Process classes - lower-level business abstractions
• Persistent classes
• System classes
 Design Model
• The design model can be viewed in two different dimensions
a) The process dimension - The evolution of the design model as design tasks are executed as part of the
software process
b) The abstraction dimension - The level of detail as each element of the analysis model is transformed into a
design equivalent and then refined iteratively.

1. Data Design Elements:

• The data design element produced a model of data that represent a high level of abstraction.
• This model is then more refined into more implementation specific representation which is processed by the
computer-based system.
• The structure of data is the most important part of the software design.
2. Architectural design elements
• The architecture design elements provides us overall view of the system.
• The architectural design element is generally represented as a set of interconnected
subsystem that are derived from analysis packages in the requirement model.
Ex: floor plan of a house - overall layout of the rooms; their size, shape, and relationship

3. Interface design elements

• The interface design elements for software represents the information flow within it and out
of the system.
• They communicate between the components defined as part of architecture.
Following are the important elements of the interface design:
1. The user interface
2. The external interface to the other systems, networks etc.
3. The internal interface between various components.
4) Component level diagram elements
• The component level design for software is like the set of detailed specification of each room in a
house. It depict wiring and plumbing within each room, the location of wall switches, faucets, sinks,
showers, tubs, drains, cabinets, flooring to be used, the moldings to be applied, and every other detail
associated with a room.
• The component level design for the software completely describes the internal details of each
software component.
• The processing of data structure occurs in a component and an interface which allows all the
component operations.
• In a context of object-oriented software engineering, a component shown in a UML diagram.

Fig: A UML Component diagram

5) Deployment level design elements
•The deployment level design element shows the software functionality and subsystem that allocated in
the physical computing environment which support the software.
•This means that the deployment diagram shows the computing environment but does not explicitly
indicate configuration details.

Fig: A UML deployment diagram

 Pattern-based Software Design
• A software designer begins with a requirements model
that presents an abstract representation of the system.

• The requirements model describes the problem set,

establishes the context, and identifies the system of forces
that hold sway.

• It may imply the design in an abstract manner, but the

requirements model does little to represent the design
explicitly.

• As a designer, it’s always important to keep quality

attributes in mind.

Fig: Pattern-based design in context

Thinking in Patterns:
following approach that enables a designer to think in patterns:
1. Be sure you understand the big picture.
2. Examining the big picture, extract the patterns that are present at that level of abstraction.
3. Begin your design with “big picture” patterns that establish a context or skeleton for further design
work.
4. “Work inward from the context” looking for patterns at lower levels of abstraction that contribute
to the design solution.
5. Repeat steps 1 to 4 until the complete design is fleshed out.
6. Refine the design by adapting each pattern to the specifics of the software you’re trying to build.
Design Tasks:

The following design tasks are applied when a pattern-based design philosophy is used:

1. Examine the requirements model and develop a problem hierarchy. - Work from broad problems to
smaller subproblems
2. Determine if a reliable pattern language has been developed for the problem domain- ex: home
security products, digital device monitoring problems, user interface problems, digital video
management problems etc.
3. Beginning with a broad problem, determine whether one or more architectural patterns is available
for it.
4. Examine subsystem or component-level problems and search for appropriate patterns to address
them.
5. Repeat steps 2 through 5 until all broad problems have been addressed
6. If user interface design problems have been isolated, search the many user interface design pattern
repositories for appropriate patterns
7. Regardless of its level of abstraction, if a pattern language and/or patterns repository or individual
pattern shows promise, compare the problem to be solved against the existing pattern(s) presented.
8. Be certain to refine the design as it is derived from patterns using design quality criteria as a guide.
Building a Pattern-Organizing Table:

Fig: A pattern organizing table

Common Design Mistakes:
The design should emphasize on software quality fundamentals and ensuring that the design does
address the needs expressed by the requirements model.
But the design mistakes are,
1. Not enough time has been spent to understand the underlying problem.
2. Selecting a pattern that looks right but is inappropriate for the solution required.
3. Once the wrong pattern is selected, you refuse to see your error and force-fit the pattern.
4. Sometimes a pattern is applied too literally and the required adaptations for your problem space are
not implemented.
 Architectural Design
• The architecture is not the operational software. Rather, it is a representation that enables a
software engineer to:
(1) analyze the effectiveness of the design for its stated requirements,
(2) consider architectural alternatives at a stage when making design changes is still relatively easy,
and
(3) reduce the risks associated with the construction of the software.
 Why Is Architecture Important?

• Representations of software architecture are an enabler for communication between all parties
(stakeholders) interested in the development of a computer-based system.
• The architecture highlights early design decisions that will have a profound impact on all
software engineering work that follows and, as important, on the ultimate success of the system
as an operational entity.
• Architecture “constitutes a relatively small, intellectually graspable model of how the system is
structured and how its components work together” .
 Architectural design decisions
• Architectural design is a creative process where you design a system organization that will satisfy
the functional and non-functional requirements of a system
1. Is there a generic application architecture that can act as a template for the system?
2. How will the system be distributed across a number of cores or processors?
3. What architectural patterns or styles might be used?
4. What will be the fundamental approach used to structure the system?
5. How will the structural components in the system be decomposed into subcomponents?
6. What strategy will be used to control the operation of the components in the system?
7. What architectural organization is best for delivering the non-functional requirements of the
system?
8. How will the architectural design be evaluated?
9. How should the architecture of the system be documented?
The architectural style and structure that you choose for a system is also dependent on the non-functional
requirements depending upon critical requirement.

1. Performance
2. Security
3. Safety
4. Availability
5. Maintainability

Evaluating an architectural design is difficult because the true test of an architecture is how well the system
meets its functional and non-functional requirements when it is in use.
 Architectural views
• Views or perspectives are useful when designing and documenting a system’s architecture
1. A logical view
• shows the key abstractions in the system as objects or object classes.
• relate the system requirements to entities in this logical view.
2. A process view
• how, at run-time, the system is composed of interacting processes.
• useful for making judgments about nonfunctional system characteristics such as performance and availability.
3. A development view
• how the software is decomposed for development i.e. breakdown of the software
• useful for software managers and programmers.
4. A physical view
• shows the system hardware and how software components are distributed across the processors in the
system.
• useful for systems engineers planning a system deployment.
Architectural patterns
Patterns are way of presenting,
sharing, and reusing knowledge
about software systems.
Ex: Model-View-Controller
pattern
- Used as interaction
management in many web-based
systems
1. Layered architecture
• way of achieving separation and independence. Organizes the system into layers with related functionality associated with
each layer.
• A layer provides services to the layer above it, so the lowest-level layers represent core services that are likely to be used
throughout the system.
When used
• when building new facilities on top of existing systems
• when the development is spread across several teams with each team responsibility for a layer of functionality
• When there is a requirement for multi-level security.
Advantages
• Allows replacement of entire layers so long as the interface is maintained.
• Redundant facilities (e.g., authentication) can be provided in each layer to increase the dependability
Disadvantages
• providing a clean separation between layers is often difficult and a high-level layer may have to interact directly with
lower-level layers rather than through the layer immediately below it.
• Performance can be a problem because of multiple levels of interpretation of a service request as it is processed at each
layer.
Fig: A generic layered architecture
Fig: Architecture of library system
2. Repository architecture
• All data in a system is managed in a central repository that is accessible to all system components.
• Components do not interact directly, only through the repository.
When used
• when you have a system in which large volumes of information are generated that must be stored for a long
time.
• In data-driven systems where the inclusion of data in the repository triggers an action or tool.
Advantages
• Components can be independent—they do not need to know of the existence of other components.
• Changes made by one component can be propagated to all components.
• All data can be managed consistently (e.g., backups done at the same time) as it is all in one place.
Disadvantages
• The repository is a single point of failure so problems in the repository affect the whole system.
• May be inefficiencies in organizing all communication through
• Distributing the repository across several computers may be difficult.
Fig: Repository architecture for an IDE
3. Client Server architecture
• Clients are users of these services and access servers to make use of them.
When used
• When data in a shared database has to be accessed from a range of locations.
• Because servers can be replicated, may also be used when the load on a system is variable.
Advantages
• servers can be distributed across a network.
• General functionality (e.g., a printing service) can be available to all clients and does not need to be
implemented by all services.
Disadvantages
• Each service is a single point of failure so susceptible to denial of service attacks or server failure.
• Performance may be unpredictable because it depends on the network as well as the system.
• May be management problems if servers are owned by different organizations.
Fig: A client-server architecture of film library
3. Pipe and filter architecture
• run-time organization of a system where functional transformations process their inputs and produce
outputs.
• The data flows (as in a pipe) from one component to another for processing through each component(filter)
is discrete and carries out one type of data transformation.
When used
• Commonly used in data processing applications (both batch- and transaction-based) where inputs are
processed in separate stages to generate related outputs..
Advantages
• Easy to understand and supports transformation reuse.
• Workflow style matches the structure of many business processes.
• Can be implemented as either a sequential or concurrent system.
Disadvantages
• The format for data transfer has to be agreed upon between communicating transformations.
• Each transformation must parse its input and unparse its output to the agreed form. This increases system
overhead and may mean that it is impossible to reuse functional transformations.
Fig: Pipe and filter architecture.
 Application architectures
• Application architectures encapsulate the principal characteristics of a class of systems
1. Transaction processing systems:
• A transaction is any coherent sequence of operations that satisfies a goal.
• Transaction processing (TP) systems are designed to process user requests for information from a database,
or requests to update a database.
• a library catalog, a flight timetable, or the records of patients in a hospital.
• For ex- find the times of flights from London to Paris

Fig: The Database structure of transaction processing applications

2. Information systems
• Information systems are web-based systems that are accessed through a web browser.
• The system is modeled using a layered approach where the top layer supports the user interface, and the bottom layer
is the system database.
• For ex: e-commerce systems are Internet-based resource management systems

Fig: An architecture of Information system Fig: Information resource system of

hospital management system
3. Language processing systems
• Language processing systems translate a natural or artificial language into another representation of that language.
• In software engineering, compilers translate an artificial programming language into machine code.
• Ex: Java code execution

Fig: The architecture of a language processing system

 Component level Design
• Component:
• A component is a modular building block for computer software.
• It communicate and collaborate with other components and with entities (other systems, devices, people)
1. An Object-Oriented View
• In object-oriented software engineering, a component contains a set of collaborating classes.
• Each class within a component has been fully elaborated to include all attributes and operations that are
relevant to its implementation.
• Begin with the requirements model and elaborate analysis and infrastructure classes
2. The Traditional View
• In the traditional software engineering, a component is a functional element of a program that incorporates
processing logic, the internal data structures and interface
• also called a module, resides within the software architecture and which can be in one of the role as a
control component, a problem domain component or infrastructure component
3. A Process-Related View:
• Choose components or design
patterns from the catalog and use
them to populate the architecture.
• These components have been created
with reusability in mind, a complete
description of their interface, the
function(s) they perform, and the
communication and collaboration

Fig: component-level design

 DESIGNING CLASS-BASED COMPONENTS
Basic Design Principles: (SOLID RCR)
1. The Open-Closed Principle (OCP) - A component should be open for extension but closed for
modification.
2. The Liskov Substitution Principle (LSP). - Subclasses should be substitutable for their base
classes\
3. Dependency Inversion Principle (DIP). - Depend on abstractions. Do not depend on concretions
4. The Interface Segregation Principle (ISP). Many client-specific interfaces are better than one
general purpose interface
5. The Release Reuse Equivalency Principle (REP). The granule of reuse is the granule of release
6. The Common Closure Principle (CCP). Classes that change together belong together.
7. The Common Reuse Principle (CRP). Classes that aren’t reused together should not be grouped
together
 Component-Level Design Guidelines
1. Components
• Naming conventions should be established for components that are specified as part of the
architectural model and then refined and elaborated as part of the component-level model.
2. Interface
• Interfaces provide important information about communication and Collaboration
3. Dependencies and Inheritance
• to model dependencies from left to right and inheritance from bottom (derived classes) to top
(base classes).
 Cohesion
• a component or class encapsulates only attributes and operations that are closely related to one another
and to the class or component itself
• Types of cohesion:
1. Functional
• All the elements in the module perform only the necessary activities.
• Exhibited primarily by operations.
• Ex: read transaction record, cosine angle computation, seat assignment to an airline passenger etc.
2. Layer
• Exhibited by packages, components, and classes.
• when a higher layer accesses the services of a lower layer, but lower layers do not access higher layers
3. Communicational
• All operations that access the same data are defined within one class
• usage of customer account number, finding the name of the customer, finding the loan balance of the
customer.
 Coupling
• Coupling is a qualitative measure of the degree to which classes are connected to one another.
• As classes (and components) become more interdependent, coupling increases.
• An important objective in component-level design is to keep coupling as low as is possible.
1. Content coupling - one module can modify the data of another module
2. Common coupling - a number of components all make use of a global variable
3. Control coupling - modules communicate by passing control information
4. Stamp coupling - the complete data structure is passed from one module to another module
5. Data coupling - communicate by passing only data
6. Routine call coupling - Occurs when one operation invokes another
7. Type use coupling - when component A uses a data type defined in component B
8. Inclusion or import coupling - when component A imports or includes a package or the content of
component B.
9. External coupling - when a component communicates or collaborates with infrastructure components
 Conducting component-level design
• Step 1. Identify all design classes that correspond to the problem domain.
• Step 2. Identify all design classes that correspond to the infrastructure domain.
• Step 3. Elaborate all design classes that are not acquired as reusable components.
• Step 3a. Specify message details when classes or components collaborate.
• Step 3b. Identify appropriate interfaces for each component
• Step 3c. Elaborate attributes and define data types and data structures required to implement them.
• Step 3d. Describe processing flow within each operation in detail.
• Step 4. Describe persistent data sources (databases and files) and identify the classes required to manage
them.
• Step 5. Develop and elaborate behavioral representations for a class or component.
• Step 6. Elaborate deployment diagrams to provide additional implementation detail
• Step 7. Refactor every component-level design representation and always consider alternatives.
 User Interface Design
• User interface design creates an effective communication medium between a human and a computer.
• If a product is to be successful, it must exhibit good usability— a qualitative measure of the ease and
efficiency.
• If interface mechanisms have been well designed, the user glides through the interaction using a smooth
rhythm that allows work to be accomplished effortlessly.
• if the interface is poorly conceived, the user moves in fits and starts, and the result is frustration and poor
work efficiency.
 THE GOLDEN RULES
• Theo Mandel coins three golden rules which form the basis for a set of user interface design
principles
• It guides three important aspect of software design -
1. Place the user in control.
2. Reduce the user’s memory load.
3. Make the interface consistent.
1. Place the User in Control
a) Define interaction modes in a way that does not force a user into unnecessary or undesired actions.
Ex: Spell Checker: user should be able to enter and exit the mode with little or no effort

b) Provide for flexible interaction

Ex: software might allow a user to interact via keyboard commands, mouse movement, a digitizer pen, a
multitouch screen, or voice recognition command

c) Allow user interaction to be interruptible and undoable

Ex: Even when involved in a sequence of actions, the user should be able to interrupt the sequence to do
something else

d) Streamline interaction as skill levels advance and allow the interaction to be customized.

e) Hide technical internals from the casual user.

The user should not be aware of the operating system, file management functions and other.

f) Design for direct interaction with objects that appear on the screen.
Ex: an application interface that allows a user to “stretch” an object (scale it in size) is an implementation of
direct manipulation
2. Reduce the User’s Memory Load

a) Reduce demand on short-term memory:

reduce the requirement to remember past actions, inputs, and results.

b) Establish meaningful defaults:

initial set of defaults, reset functionality etc.

c) Define shortcuts that are intuitive:

mnemonic should be tied to the action in a way that is easy to remember

d) The visual layout of the interface should be based on a real-world metaphor:

For example, a bill payment system should use a checkbook and check register metaphor to guide the
user through the bill paying process.

e) Disclose information in a progressive fashion:

Information about a task, an object, or some behavior should be presented first at a high level of
abstraction. More details should be presented after the user indicates interest with a mouse pick
3. Make the Interface Consistent

a) Allow the user to put the current task into a meaningful context

b) Maintain consistency across a family of applications.

Implement the same design rules so that consistency is maintained for all interaction

c) If past interactive models have created user expectations, do not make changes unless there is a compelling reason to
do so.
e.g., The use of ctrl-S is to save a file, so the user expects this in every application he encounters.
 Interface design models
• Four different models:
1. user model: A human engineer (or the software engineer)
2. design model: software engineer
3. mental model: end user
4. implementation model: implementers
As an interface designer, your role is to reconcile these differences and derive a consistent representation of
the interface.
• To build an effective user interface, all design should begin with an understanding of the intended users.
• Users can be categorized as
1. Novices : No syntactic knowledge of the system and little semantic knowledge
2. Knowledgeable, intermittent users: Reasonable semantic but relatively low recall of syntactic information
3. Knowledgeable, frequent users: Good semantic and syntactic knowledge
 The Process

The analysis and design process for user interfaces is

iterative and can be represented using a spiral model.

(1) Interface analysis and modeling

Information gathering and create analysis model
(2) interface design
define a set of interface objects and actions
(3) interface construction
creation of a prototype
(4) Interface validation
ability of the interface to implement every user task
correctly
 Interface design analysis
1. User Analysis:
• the user’s mental image may be vastly different from the software engineer’s design model
a) User Interviews
b) Sales input
c) Marketing input
d) Support input
2. Task Analysis and Modeling
What tasks and subtasks will be performed as the user does the work?
a) Use cases.
b) Task elaboration
c) Workflow analysis.
d) Hierarchical representation.
e) User task
3. Analysis of Display Content:

During this interface analysis step, the format and aesthetics of the content (as it is displayed by the interface)

are considered.

4. Analysis of the Work Environment:

The work influenced by the activity around them, the physical characteristics of the workplace, the type of

equipment they are using, and the work relationships they have with other people.
 Interface Design Steps
• Each user interface design step occurs a number of times, elaborating and refining information.
• Steps:
1. Applying Interface Design Steps
• Define Object and actions iteratively.
• Perform screen layout
2. User Interface Design Patterns
Ex: Entering the calendar days
3. Design Issues
• system response time
• user help facilities
• error information handling
• Menu and command labeling
4. Application accessibility
5. Internationalization
 Design Evaluation
Evaluation criteria:
1. The length and complexity of the requirements model
2. Interaction time and the overall efficiency of the
system.
3. the memory load on users of the system
4. complexity of the interface and the degree to which it
will be accepted by the user.

Fig: user interface evaluation cycle

Case Study : Web App Design /
Library Management System

62
63
64
65