Design Program Logic

LO1 Select the Program Design Approach

1.1 Obtaining Design Documentation and Requirement for the Program
Clarification
1.1.1 Pseudo code
Pseudocode is an informal high-level description of the operating principle of a computer
program or other algorithm.
Pseudocode
• English-like representation of a program
• It could be viewed as the outline of a program
• It can‟t be compiled or executed.
• The focus is on solving the problem, not worrying about the specifics of a programming
language.
It uses the structural conventions of a programming language, but is intended for human reading
rather than machine reading. Pseudocode typically omits details that are not essential for human
understanding of the algorithm, such as variable declarations, system-specific code and some
subroutines. The programming language is augmented with natural language description details,
where convenient, or with compact mathematical notation. The purpose of using pseudocode is
that it is easier for people to understand than conventional programming language code,
and that it is an efficient and environment-independent description of the key principles of
an algorithm. It is commonly used in textbooks and scientific publications that are documenting
various algorithms, and also in planning of computer program development, for sketching out the
structure of the program before the actual coding takes place.

Pseudo Code with SEQUENCE

When we write programs, we assume that the computer executes the program starting at the
beginning and working its way to the end.
We call this sequence
SEQUENCE is a linear progression where one task is performed sequentially after another.
In pseudo code it look like this
Statement 1; For example, for making a cup of tea:
Statement 2; Organize everything together;
Statement 3; Plug in kettle;
Statement 4; Put teabag in cup;
Statement 5; Put water into kettle;
Wait for bottle to boil;
Add water to cup;
Remove teabag with spoon/fork/;
Add milk and /or sugar;
Serve;

BY: - WPTC AND SATELLITE INSTITUTE Page 1

 Design Program Logic
Pseudo Code with LOOP
What if we need to tell the computer to keep doing something until some condition occurs?
Let‟s say we wish to indicate that you need to keep filling the kettle with water until it is full.
We call this a loop.
WHILE is a loop (repetition) with a simple conditional test at its beginning
Or, in general Example, above
While (<condition>) Organize everything together;
Do <Statements>; Plug in kettle;
Endwhile; Put teabag in cup;
As we could state this as: While (Kettle is not full)
While (Kettle is not full) Do keep filling Kettle;
Do keep filling Kettle; EndWhile;
EndWhile; Wait for bottle to boil;
Add water to cup;
Remove teabag with spoon/fork/;
Add milk and /or sugar;
Serve;
Pseudo Code with SELECTION
What if we want to make a choice, for example, do we want add sugar or not to the tea?
We call this selection.
IF-THEN-ELSE is a decision (selection) in which a choice is made between two alternative
courses of action.
Or, in general: While (Kettle is not full)
If (<condition>) Do keep filling Kettle;
Then <Statement>; EndWhile;
Else <Statement>; Wait for bottle to boil;
EndIf; Add water to cup;
So, we could state this as: Remove teabag with spoon/fork/;
If (Sugar is required) Add milk;
Then add Sugar; If (Sugar is required)
Else don’t add sugar; Then add Sugar;
EndIf; Else do nothing;
Example, Above: EndIf;
Organize everything together; Serve;
Plug in kettle;
Put teabag in cup;

BY: - WPTC AND SATELLITE INSTITUTE Page 2

 Design Program Logic
1.1.2 Flowcharts
A flow chart is a graphical or symbolic representation of a process. Each step in the process is
represented by a different symbol and contains a short description of the process step. The flow chart
symbols are linked together with arrows showing the process flow direction.
• Pictorial representation of a program
• Can be created with pencil and paper, Microsoft Word, PowerPoint, Visio (a copy of this is in
the back of the Farrell book), etc.
• For this class, all flowcharts must be done in Visio

Six basic flowchart shapes

Lozenge/terminal symbol -Indicates the beginning or end of a program

Input/output symbol- Represents information coming into a program or going out of a

program

Processing symbol- Shows calculations that a program must do

Diamond symbol represents decision- that a program must make

The circle is for connecting parts of the flowchart to other parts. This is especially useful if the
flowchart covers more than one page

Flow lines connect the shapes within a flowchart

The three basic control structures
1. Sequence

BY: - WPTC AND SATELLITE INSTITUTE Page 3

 Design Program Logic
2. Selection Selection (2)

3. Repetition

Example 1 Add three numbers

A program is required to read three numbers, add them together and print their total.
Pseudo code
Add_three_numbers
Read number1, number2, number3
Total = number1 + number2 + number3
Print total
END
Defining diagram
Input Processing Output
Number1 Read three numbers total
Number2 Add number together
Number3 Print total number

BY: - WPTC AND SATELLITE INSTITUTE Page 4

 Design Program Logic

Example 2 Getting out of bed in the morning

The following flow chart example presents a very simple flow chart for the process of getting out of bed
in the morning.

BY: - WPTC AND SATELLITE INSTITUTE Page 5

 Design Program Logic
Example:- Find average temperature
A program is required to prompt the terminal operator for the maximum and minimum temperature
readings on a particular day, accept those readings as integers, and calculate and display to the screen
the average temperature, calculated by (maximum temperature + minimum temperature)/2.

Defining diagram
Input Processing Output
Max_temp Prompt for temperatures Avg_temp
Min_temp Get temperatures
Calculate average temperature
Display average temperature

Pseudo code
Find average_temperature
Prompt operator for max_temp, min_temp
Get max_temp, min_temp
Avg_temp= (max_Temp + min_temp)/2
Output avg_temp to the screen
END
Flow Chart

Start

Get max_temp,
min_temp

Calculate Average
Temprature

Print Average
Temprature.

End

BY: - WPTC AND SATELLITE INSTITUTE Page 6

 Design Program Logic
1.14 DFD’s
Data Flow Diagram (DFD)
The Data Flow Diagram (DFD) is a graphical representation of the flow of data through an information
system.
A structured analysis technique that employs a set of visual representations of the data that moves
through the organization, the paths through which the data moves, and the processes that produce, use,
and transform data. It enables you to represent the processes in your information system from the
viewpoint of data. The DFD lets you visualize how the system operates, what the system accomplishes
and how it will be implemented, when it is refined with further specification.

Data flow diagrams are used by systems analysts to design information-processing systems but also as a
way to model whole organizations.
Why Data Flow Diagrams?
• Can diagram the organization or the system
• Can diagram the current or proposed situation
• Can facilitate analysis or design
• Provides a good bridge from analysis to design
• Facilitates communication with the user at all stages
Types of DFDs
• Current - how data flows now
• Proposed - how we‟d like it to flow
• Logical - the “essence” of a process (i.e. implementation-independent and describe the system,
rather than how activities are accomplished.)
• Physical - the implementation of a process (i.e. are implementation-dependent and describe the
actual entities (devices, department, people, etc.) involved in the current system.)
• Partitioned physical - system architecture or high-level design

Levels of Details
Context Diagram- Shows just the inputs and outputs of the system
Level 0 Diagram- Decomposes the process into the major subprocesses and identifies what data flows
between them
Child diagrams- Increasing levels of detail (i.e. Level 1, Level 2 etc)
Primitive diagrams- Lowest level of decomposition
Four Basic Symbols

Process

Data Flow

Data Store

Source/Sink (External Entity)

BY: - WPTC AND SATELLITE INSTITUTE Page 7

 Design Program Logic

Process

1.0
Grade Detail Produce Grade Report
Grade
Report

Work or actions performed on data (inside the system)


Labels should be verb phrases
Receives input data and produces output
Rule 1: Process
 Can have more than one outgoing data flow or more than one incoming data flow

1.0 Graded Work

Submitted work Grade Student Grade
Student
Work

3.0
Hours Worked Calculated Gross Pay
Gross
Pay Rate Pay

BY: - WPTC AND SATELLITE INSTITUTE Page 8

 Design Program Logic
Rule 2: Process
 Can connect to any other symbol (including another process symbol)

1.0 2.0

Verify Assemble Inventory Change

Order Order Accepted Order Order

Data Flow Deposit

 Is a path for data to move from one part to another
 Arrows depicting movement of data
 Can represent flow between process and data store by two separate arrows

Data Store
D1 Students

 Is used in a DFD to represent data that the system stores

 Labels should be noun phrases

Rule: Data Store

 Must have at least one incoming and one outgoing data flow

Customer Payment

Daily Payment

BY: - WPTC AND SATELLITE INSTITUTE Page 9

 Design Program Logic
Source/Sink (External Entity)
1.0
Order

CUSTOMER Invoice
Verify
Order
 External entity that is origin or destination of data (outside the system)
 Labels should be noun phrases
 Source –Entity that supplies data to the system
 Sink –Entity that receives data from the system

Context Level Diagram

• Just one process
• All sources and sinks that provide data to or receive data from the process
• Major data flows between the process and all sources/sinks
• Shows all the outside entities that receive information from or contribute information to the
system
• No data stores
Example: - Course Registration: Context level Diagram

Level 0 Diagram
• Process is “exploded”
• Sources, sinks, and data flows repeated from context diagram
• Process broken down into subprocesses, numbered sequentially
• Lower-level data flows and data stores added

BY: - WPTC AND SATELLITE INSTITUTE Page 10

 Design Program Logic

1.1.5 Hierarchy Input Process Output Diagram (HIPO)

• Is a hierarchy chart that graphically represents the program‟s control the s functions (or
processes) performed by each module on the system.

BY: - WPTC AND SATELLITE INSTITUTE Page 11

 Design Program Logic
Hierarchy Input Process Output Diagram (HIPO)

1.1.6 Data Structure

Data structure diagram (DSD) is intended for description of conceptual models of data (concepts and
connections between them) in the graphic format for more obviousness. Data structure diagram includes
entities description, connections between them and obligatory conditions and requirements which
connect them.

Data structure diagram is a subspecies of the “entity-relationship” diagram type (ERD).

Entities in data structure diagrams are presented in the form of rectangles or rounded rectangles, and
connections between them in the form of arrows. The description of an entity is usually placed inside the
rectangle, which denotes the entity. The text description of the entity requirements connecting entities is
placed near the line which denotes the connection between entities. The description of connection types
between entities (one-to-one, one-to-many, etc.) can be different in different notations and differs with
the arrow type on the line of connection between entities. The most famous are notations of DeMarco,
Jackson and Yourdon.
BY: - WPTC AND SATELLITE INSTITUTE Page 12
 Design Program Logic

DSD also used for hierarchical presentation of the complicated entity. Such data structure diagram is
usually created in the result of entity decomposition to the set level of detailed elaboration and presented
as a tree.

The difference of the data structure diagram from the “entity- relationship” diagram is that DSD more
completely defines connections and relations between elements of entities whereas ERD defines
connections between entities.

BY: - WPTC AND SATELLITE INSTITUTE Page 13

 Design Program Logic
1.1.7 RAD
What is RAD model- advantages, disadvantages and when to use it?
RAD model is Rapid Application Development model. It is a type of incremental model. In RAD model
the components or functions are developed in parallel as if they were mini projects. The developments
are time boxed, delivered and then assembled into a working prototype. This can quickly give the
customer something to see and use and to provide feedback regarding the delivery and their
requirements.
Diagram of RAD-Model:

The phases in the rapid application development (RAD) model are:

Business modeling: The information flow is identified between various business functions.
Data modeling: Information gathered from business modeling is used to define data objects that are
needed for the business.
Process modeling: Data objects defined in data modeling are converted to achieve the business
information flow to achieve some specific business objective. Description are identified and created for
CRUD of data objects.

BY: - WPTC AND SATELLITE INSTITUTE Page 14

 Design Program Logic
Application generation: Automated tools are used to convert process models into code and the actual
system.
Testing and turnover: Test new components and all the interfaces.
Advantages of the RAD model:
• Reduced development time.
• Increases reusability of components
• Greater customer satisfaction
• Encourages customer feedback
• Faster delivery time
• simple and better quality
Disadvantages of RAD model:
• Depends on strong team and individual performances for identifying business requirements.
• Only system that can be modularized can be built using RAD
• Requires highly skilled developers/designers.
• It is not appropriate when technical risk is high
• High dependency on modeling skills
• Inapplicable to cheaper projects as cost of modeling and automated code generation is very high.
When to use RAD model:
• RAD should be used when there is a need to create a system that can be modularized in 2-3
months of time.
• It should be used if there‟s high availability of designers for modeling and the budget is high
enough to afford their cost along with the cost of automated code generating tools.
• RAD SDLC model should be chosen only if resources with high business knowledge are
available and there is a need to produce the system in a short span of time (2-3 months).

1.1.8 Prototyping
What is Prototype model- advantages, disadvantages and when to use it?
This prototype is developed based on the currently known requirements. By using this prototype, the
client can get an “actual feel” of the system, since the interactions with prototype can enable the client to
better understand the requirements of the desired system. Prototyping is an attractive idea for
complicated and large systems for which there is no manual process or existing system to help
determining the requirements. The prototypes are usually not complete systems and many of the details
are not built in the prototype. The goal is to provide a system with overall functionality.

BY: - WPTC AND SATELLITE INSTITUTE Page 15

 Design Program Logic
Diagram of Prototype model:

Advantages of Prototype model:

• Users are actively involved in the development
• Errors can be detected much earlier.
• Quicker user feedback is available leading to better solutions.
• Missing functionality can be identified easily
• Confusing or difficult functions can be identified
Disadvantages of Prototype model:
• It‟s a slow in process
• It‟s not complete model
• It is time consuming model
• It should be developed or built on company‟s cost
When to use Prototype model:
• Prototype model should be used when the desired system needs to have a lot of interaction with
the end users.
• Typically, online systems, web interfaces have a very high amount of interaction with end users,
are best suited for Prototype model. It might take a while for a system to be built that allows ease
of use and needs minimal training for the end user.
• Prototyping ensures that the end users constantly work with the system and provide a feedback
which is incorporated in the prototype to result in a useable system. They are excellent for
designing good human computer interface systems.

1.1.9 Case Tools

CASE (computer-aided software engineering) tools have been widely in use since the 1990's. They are
specialized, computerized tools that aid in the design, development and maintenance of software. The
term CASE was originally coined by software company, Nastec Corporation of Southfield, Michigan in
1982 with their original integrated graphics and text editor GraphiText.

Many different definitions of CASE tools exist, below are just a few of those:
Galin - CASE tools are computerized software development tools that support the developer when
performing one or more phases of the software life cycle and/or support software maintenance.

Wikipedia - The scientific application of a set of tools and methods to a piece of software which results
in high-quality, defect free and maintainable software products.

Carnegie-Mellon - The use of computer-based support in the software development process.

BY: - WPTC AND SATELLITE INSTITUTE Page 16

 Design Program Logic
Types of CASE tools
Classic CASE tools - established software development support tools (e.g. interactive debuggers,
compilers, etc.)
Real CASE tools - can be separated into three different categories, depending on where in the
development process they are most involved in:
• Upper - support analysis and design phases
• Lower - support coding phase
• Integrated - also known as I-CASE support analysis, design and coding phases
Upper and lower CASE tools are named as such because of where the phases they support are in the
Waterfall Model (see below)

Why use CASE tools?

CASE tools offer:
• Savings in resources required for software development - with less
• Quicker development phase (i.e. shorter time to market)
• Reduction of generation of defects
• Easier identification of defects during development
• Savings in maintenance resources required
• Greater standardization of software systems and therefore increased reuse possibilities
• Reduction of effort needed on development

BY: - WPTC AND SATELLITE INSTITUTE Page 17

 Design Program Logic
LO2 Document the Program Logic or Design
2.1 Documenting Program Scope and Limits
The larger the project, the more important it becomes to use CASE tools in the software's development.
The standardization provided by using CASE tools allows many developers to work on one project
without spending time working out what certain sections of code does, it also enables easier debugging
which becomes more important with a project that involves a large amount or complex coding as
software such as this is more likely to have errors.

The purpose of a scope and limitations statement is to provide an outline of what your project will
address and what it won’t address. What you turn in will include the following:

 a description of the project (what technology you are addressing and the rationale for choosing that
technology),
 an explanation of what kind of data you will collect, the methods you will use (interviews, library
research, observation, etc.), and how much of each kind of data you will collect,
 an explanation of how you are approaching the challenge of making something „better‟ (making it
less expensive, easier to use, available to a more diverse population, more environmentally friendly,
etc.),
 A proposal about how you will test your initial design suggestions. Remember the design guidelines
provided during Unit 1, and address these as you outline your approach, and
 A timeline with major tasks to be accomplished for the project and which team member will take a
leadership role and responsibility for the task.

While the actual write-up you hand in may be as short as one page, I expect a significant level of detail
in your descriptions of your approach, and I also expect that the paper will reflect a considerable amount
of thought and the contributions of each group member. Keep in mind that my expectation is that three
or four people will be contributing content to this statement, and the work should reflect that level of
collective effort.

BY: - WPTC AND SATELLITE INSTITUTE Page 18

 Design Program Logic
2.2 Program Design Logic Document Contents

TABLEOFCONTENTS

1. INTRODUCTION 2
11. Purpose 2
12. Scope 2
13. Overview 2
14. ReferencMaterial 2
15. DefinitionsandAcronyms 2

2. SYSTEMOVERVIEW 2

3. SYSTEMARCHITECTURE 2
31. ArchitecturalDesign 2
32. DecompositionDescription 3
33. DesignRationale 3

4. DATADESIGN 3
41. DataDescripton 3
42. DataDictionary 3

5. COMPONENTDESIGN 3

6. HUMANINTERFACEDESIGN 4
61. OverviewofUserInterface 4
62. ScreenImages 4
63. ScreenObjectsandActions 4

7. REQUIREMENTSMATRIX 4

8. APPENDICES 4

BY: - WPTC AND SATELLITE INSTITUTE Page 19

 Design Program Logic
1. INTRODUCTION
1.1 Purpose
Identify the purpose of this SDD and its intended audience. (e.g. “This software design document
describes the architecture and system design of XX. ….”).

1.2 Scope
Provide a description and scope of the software and explain the goals, objectives and benefits of your
project. This will provide the basis for the brief description of your product.

1.3 Overview
Provide an overview of this document and its organization.

1.4 Reference Material

This section is optional.
List any documents, if any, which were used as sources of information for the test plan.

1.5 Definitions and Acronyms

This section is optional.
Provide definitions of all terms, acronyms, and abbreviations that might exist to properly interpret the
SDD. These definitions should be items used in the SDD that are most likely not known to the audience.

2. SYSTEM OVERVIEW
Give a general description of the functionality, context and design of your project. Provide any
background information if necessary.

3. SYSTEM ARCHITECTURE
3.1 Architectural Design
Develop a modular program structure and explain the relationships between the modules to achieve the
complete functionality of the system. This is a high level overview of how responsibilities of the system
were partitioned and then assigned to subsystems. Identify each high level subsystem and the roles or
responsibilities assigned to it. Describe how these subsystems collaborate with each other in order to
achieve the desired functionality. Don‟t go into too much detail about the individual subsystems. The
main purpose is to gain a general understanding of how and why the system was decomposed, and how
the individual parts work together. Provide a diagram showing the major subsystems and data
repositories and their interconnections. Describe the diagram if required.

3.2 Decomposition Description

Provide a decomposition of the subsystems in the architectural design. Supplement with text as needed.
You may choose to give a functional description or an object oriented description. For a functional
description, put top level data flow diagram (DFD) and structural decomposition diagrams. For an OO
description, put subsystem model, object diagrams, generalization hierarchy diagram(s) (if any),
aggregation hierarchy diagram(s) (if any), interface specifications, and sequence diagrams here.

3.3 Design Rationale

Discuss the rationales for selecting the architecture described in 3.1 including critical issues and
trade/offs that were considered. You may discuss other architectures that were considered, provided that
you explain why you didn‟t choose them.

BY: - WPTC AND SATELLITE INSTITUTE Page 20

 Design Program Logic
4. DATA DESIGN
4.1 Data Description
Explain how the information domain of your system is transformed into data structures. Describe how
the major data or system entities are stored, processed and organized. List any databases or data storage
items.

4.2 Data Dictionary

Alphabetically list the system entities or major data along with their types and descriptions. If you
provided a functional description in Section 3.2, list all the functions and function parameters. If you
provided an OO description, list the objects and its attributes, methods and method parameters.

5. COMPONENT DESIGN
In this section, we take a closer look at what each component does in a more systematic way. If you
provide a function listed in 3.2 in procedural description language (PDL) or pseudocode. If you gave an
OO description, summarize each object member function for all the objects listed in 3.2 in PDL or
pseudocode. Describe any local data when necessary.

6. HUMAN INTERFACE DESIGN

6.1 Overview of User Interface
Describe the functionality of the system from the user‟s perspective. Explain how the user will be able to
use your system to complete all the expected features and the feedback information that will be
displayed for the user.

6.2 Screen Images

Display screenshots showing the interface from the user‟s perspective. These can be hand drawn or you
can use an automated drawing tool. Just make them as accurate as possible. (Graph paper works well.)

6.3 Screen Objects and Actions

A discussion of screen objects and actions associated with those objects.

7. REQUIREMENTS MATRIX
Provide a cross reference that traces components and data structures to the requirements in your SRS
document. Use a tabular format to show which system components satisfy each of the functional
requirements from the SRS. Refer to the functional requirements by the numbers/codes that you gave
them in the SRS.

8. APPENDICES
This section is optional.
Appendices may be included, either directly or by reference, to provide supporting details that could aid
in the understanding of the Software Design Document.

BY: - WPTC AND SATELLITE INSTITUTE Page 21

 Design Program Logic
LO3 Validate the design
3.1 Checking Program Flow, States or Conditions
Verification and Validation
Software verification provides objective evidence that the design outputs of a particular phase of the
software development life cycle meet all of the specified requirements for that phase. Software
verification looks for consistency, completeness, and correctness of the software and its supporting
documentation, as it is being developed, and provides support for a subsequent conclusion that
software is validated. Software testing is one of many verification activities intended to confirm that
software development output meets its input requirements. Other verification activities include various
static and dynamic analyses, code and document inspections, walkthroughs, and other techniques.

Software validation is a part of the design validation for a finished device, but is not separately
defined in the Quality System regulation. For purposes of this guidance, FDA considers software
validation to be "confirmation by examination and provision of objective evidence that software
specifications conform to user needs and intended uses, and that the particular requirements
implemented through software can be consistently fulfilled." In practice, software validation
activities may occur both during, as well as at the end of the software development life cycle to ensure
that all requirements have been fulfilled. Since software is usually part of a larger hardware system,
the validation of software typically include evidences that all software requirements have been
implemented correctly and completely and are traceable to system requirements. A conclusion that
software is validated is highly dependent upon comprehensive software testing, inspections,
analyses, and other verification tasks performed at each stage of the software development life
cycle. Testing of device software functionality in a simulated use environment, and user site testing are
typically included as components of an overall design validation program for a software automated
device.

Software verification and validation are difficult because a developer cannot test forever, and it is hard
to know how much evidence is enough. In large measure, software validation is a matter of developing
a "level of confidence" that the device meets all requirements and user expectations for the software
automated functions and features of the device. Measures such as defects found in specifications
documents, estimates of defects remaining, testing coverage, and other techniques are all used to
develop an acceptable level of confidence before shipping the product. The level of confidence, and
therefore the level of software validation, verification, and testing effort needed, will vary depending
upon the safety risk (hazard) posed by the automated functions of the device.

3.2 Gaining Feedback or Input

The great leadership guru Ken Blanchard likes to say that “Feedback is the breakfast of champions.”
He is right; getting high-quality feedback from customers can make a phenomenal difference to a
company‟s bottom line. Yet so, few business owners actually seek feedback on their performance.
Maybe it is because they are too busy serving their customers, or perhaps it is because they are scared
of what their clients might say when asked. Regardless, not asking for feedback is a crazy mistake.
Good customer feedback can help to do a number of things, including:
• Improve products.
• Alter pricing structure.
• Retain customers for longer.
• Increase referrals
• Identify high- and low-achieving staff.

BY: - WPTC AND SATELLITE INSTITUTE Page 22

 Design Program Logic
1. Ask new customers why they chose your service brand. This can be hard to do as many
customers will feel uncomfortable speaking with a company representative directly. For this reason, it
is important to establish a comfortable rapport so that customers feel they may speak openly and
honestly. An alternative is to hire a consultant to perform this survey as a third party may uncover
sensitive information more readily.

2. Ask current and past customers what differentiates your service brand from others. Another
approach is to ask a customer what thought or image first comes to mind when they consider your
company. Then the first thought or image when considering a competitor‟s brand. There is no right or
wrong answers. Take each answer at face value and recognize that the stated differences will be very
instructive in terms of how your brand is being perceived by your target audience. Any misalignments
uncovered with regard to your branding message and audience perception can then be readily
addressed.

3. Who are your repeat customers? Look for areas of commonality among your repeat customers.
This is an important clue to how your brand is perceived in the marketplace. For example, do your
customers seem to fall within a certain age or demographic group? Contact these repeat patrons to
understand what drives their customer loyalty.
4. Is your business obtaining referrals? If your brand is perceived accurately by customers, then
word-of-mouth is a great source of new business. What customers say about your company‟s brand
speaks louder than any promotional message.

5. Contact customers who chose a competitor. Assume a friendly tone and stress that your call is not
sales-oriented. You simply wish to follow up on why they didn‟t choose your firm. Again, a consultant
performing this survey may obtain more detailed information during a conversation with a company
employee.

6. Is your brand an integral part of your core values? Both Starbucks and Union Square align their
service branding strategy with company values. Company core values are just that: they are the rock
upon which your firm is built and, as such, unchanging. Building your service brand on core values
ensures message consistency and facilitates the development strong and attractive of a brand image in
the minds of your audience.
Spending time understanding the perception of your service brand is a highly valuable exercise. It
ensures that your firm is reaching its intended audience and aligning customer expectations with
service delivery.

Continually seeking feedback through a variety of sources can help you identify trends, gain
competitive advantages, and cut costs. Failure to seek feedback can cost you customers. And
remember, you can't make a profit if you're not satisfying your customers

BY: - WPTC AND SATELLITE INSTITUTE Page 23