Course Code- (CA-422T) Subject: Software Engineering

Unit 2: Software Requirement Engineering

1. The broad spectrum of tasks and techniques that lead to an understanding of

requirements is called requirements engineering.
2. From a software process perspective, requirements engineering is a major
software engineering action that begins during the communication activity
and continues into the modelling activity.
3. It must be adapted to the needs of the process, the project, the product, and
the people doing the work.
4. Requirements engineering provides the appropriate mechanism for
understanding what the customer wants, analysing need, assessing
feasibility, negotiating a reasonable solution, specifying the solution
unambiguously, validating the specification, and managing the requirements
as they are transformed into an operational system.
5. Requirements engineering is the process of identifying, eliciting, analysing,
specifying, validating, and managing the needs and expectations of
stakeholders for a software system.

Steps in Requirements Engineering Process:

The requirements engineering process is an iterative process that involves several
steps, including:

1. Requirements Elicitation
This is the process of gathering information about the needs and
expectations of stakeholders for the software system. This step involves
interviews, surveys, focus groups, and other techniques to gather
information from stakeholders.
2. Requirements Analysis
This step involves analysing the information gathered in the requirements
elicitation step to identify the high-level goals and objectives of the software
system. It also involves identifying any constraints or limitations that may
affect the development of the software system.
 3. Requirements Specification
This step involves documenting the requirements identified in the analysis
step in a clear, consistent, and unambiguous manner. This step also involves
prioritising and grouping the requirements into manageable chunks.
4. Requirements Validation
This step involves checking that the requirements are complete, consistent,
and accurate. It also involves checking that the requirements are testable and
that they meet the needs and expectations of stakeholders.
5. Requirements Management
This step involves managing the requirements throughout the software
development life cycle, including tracking and controlling changes, and
ensuring that the requirements are still valid and relevant.
Requirement Engineering:
The Requirements Engineering process is a critical step in the software
development life cycle as it helps to ensure that the software system being
developed meets the needs and expectations of stakeholders, and that it is
developed on time, within budget, and to the required quality.
Requirement Engineering is the process of defining, documenting and maintaining
the requirements. It is a process of gathering and defining services provided by the
system. It is the disciplined application of proven principle , methods ,tools and
notations to describe a proposed system’s intended behaviour and its associated
constraints.
Tools Involved in Requirement Engineering
1. Observation report
2. Questionnaire ( survey, poll)
3. Use cases
4. User stories
5. Requirement workshop
6. Mind mapping
7. Role playing
8. Prototyping
Traditional Methods for Requirement Determination:
1. Collection of information is at the core of systems analysis. Information
requirement determination (IRD) is frequently and convincingly presented
 as the most critical phase of information system (IS) development, and many
IS failures have been attributed to incomplete and inaccurate information
requirements.
2. System analysts must collect the information about the current system and
how users would like to improve their performance with the new
information system.
3. Accurately understanding the users’ requirements will help the system
developing team deliver a proper system to the end users in a limited time
and limited budget.
1. Interviewing
Interviewing is one of the primary ways to gather information about an information
system. A good system analyst must be good at interviewing and no project can be
conducted without interviewing. There are many ways to arrange an effective
interview and no one is superior to others. However, experience analysts
commonly accept some following best practices for an effective interview:
● Prepare the interview carefully, including appointment, priming question,
checklist, agenda, and questions.
● Listen carefully and take note during the interview (tape record if possible)
● Review notes within 48 hours after interview
● Be neutral
● Seek diverse views
2. Questionnaires
Questionnaires have the advantage of gathering information from many people in a
relatively short time and of being less biassed in the interpretation of their results.
Choosing right questionnaires respondents and designing effective questionnaires
are the critical issues in this information collection method. People usually only
use a part of functions of a system, so they are always just familiar with a part of
the system functions or processes. In most situations, one copy of questionnaires
obviously cannot fit all the users. To conduct an effective survey, the analyst
should group the users properly and design different questionnaires for different
groups. Moreover, the ability to build good questionnaires is a skill that improves
with practice and experience. When designing questionnaires, the analyst should
concern the following issues at least:
● The ambiguity of questions.
● Consistency of respondents’ answers.
 ● What kind of question should be applied, open-ended or close-ended?
● What is the proper length of the questionnaires?
3. Directly observing users
People are not always very reliable informants, even when they try to be reliable
and tell what they think is the truth. People often do not have a completely accurate
appreciation of what they do or how they do it. This is especially true concerning
infrequent events, issues from the past, or issues for which people have
considerable passion. Since people can not always be trusted to reliably interpret
and report their own actions, analysts can supplement and corroborate what people
say by watching what they do or by obtaining relatively objective measures of how
people behave in work situations. However, observation can cause people to
change their normal operation behaviour. It will make the gathered information
biassed.
4. Analysing procedures and other documents.
By examining existing system and organisational documentation, system analysts
can find out details about the current system and the organisation these systems
support. In documents, analysts can find information, such as problems with
existing systems, opportunities to meet new needs if only certain information or
information processing were available, organisational direction that can influence
information system requirements, and the reason why current systems are designed
as they are, etc.
However, when analysing those official documentations, analysts should pay
attention to the difference between the systems described on the official
documentations and the practical systems in the real world. For the reason of
inadequacies of formal procedures, individual work habits and preferences,
resistance to control, and other factors, the difference between so-called formal
system and informal system universally exists.
Modern Methods for Requirement Determination:
1. Joint Application Design (JAD):
● JAD is a facilitated, team-based approach for defining the requirements for
new or modified information systems.
● JAD was started at IBM in the late 1970s. The main idea behind JAD is to
bring together the key users, managers, and system analysts involved in the
analysis of a current system.
 ● The primary purpose of using JAD in the analysis phase is to collect system
requirements simultaneously from the key people involved with the system.
● The result is an intense and structured, but highly effective, process. Having
all the key people together in one place at one time allows analysts to see
where there are areas of agreement and where there are conflicts.
The typical participants in a JAD are:
1. JAD session leader, end users, business managers, sponsor, system analysts,
scribe, etc.
2. The JAD team is a group of six to sixteen individuals who all have a stake in
designing a high quality system.
3. Approximately two thirds of the group members are functional experts the
other one third are systems professionals.
4. JAD sessions are usually conducted in a location other than the place where
the people involved normally work, and are usually held in special purpose
rooms where participants sit around horseshoe-shaped tables.
5. Involving so many different kinds of people in one workshop makes how to
effectively and efficiently organise the JAD session a big challenge.
6. When a JAD is completed, the final result is a set of documents that detail
the workings of the current system related to study of a replacement system.
7. These requirements definition documents generally include business activity
model and definitions, data model and definition, data input and output
requirements.
8. It may also include interface requirements, screen and report layouts, ad hoc
query specifications, menus, and security requirements.
9. When used at a later point in the system development life cycle, a JAD
session can also be used to refine a system prototype, develop new job
profiles for system users, or develop an implementation plan.
10.However, to exploit the full potential of JAD, the groupware tools should be
applied in JAD workshop sessions.
11.The use of groupware tools to support the joint Application Development
technique increases the value of this technique dramatically.
12.When groupware tools are used in an automated JAD workshop, they greatly
facilitate the generation, analysis, and documentation of information.
13. This is particularly valuable for JAD workshops conducted to define and
build consensus on the requirements for new systems.
 2. Prototyping:
● Prototyping is a means of exploring ideas before you invest in them. Most
system developers believe that the benefits from early usability data are at
least ten times greater than those from late usability data.
● Prototyping allows system analysts to quickly show users the basic
requirement into a working version of the desired information system.
● After viewing and testing the prototype, the users usually adjust existing
requirements to new ones.
● The goal with using prototyping to support requirement determination is to
develop concrete specification for the ultimate system, not to build the
ultimate system from prototyping.
● Prototyping is most useful for requirements determination when user
requirements are not clear or well understood, one or a few users and other
stakeholders are involved with the system, possible designs are complex and
require concrete form to fully evaluate, communication problems have
existed in the past between users and analysts, and Tools and data are readily
available to rapidly build working systems, etc.
● When adopting prototyping, analysts should be concerned about the
potential problems about this requirements determination method, such as
informal documentation, ignored subtle but important requirements, etc.
Table 1 concludes these characters of previously discussed six requirements
determination methods.

Characteristic Interviews Questionnaires Observation Document JAD Prototyping

analysis

Information High Medium to low High Low (passive) High Medium to

Richness and old High

Time Required Can be Low to Can be Low to Dedicated Moderate and

extensive moderate extensive moderate period of can be
time of all extensive
kinds of
involved
people.
Expense Can be high Moderate Can be high Low to High High
moderate

Chance for Good Limited Good Limited Good Good

Follow-up and
probing

Confidentiality Interviewee Respondent can Observee is Depends on All the Usually know
is known to be unknown known to nature of people each other
interviewer interviewer document know each
other

Involvement of Interviewee Respondent is Interviewees None, no clear All kinds Users are
Subject is involved passive, no may or may commitment of people involved and
and clear not be are committed
committed commitment involved and involved
committed and
depending committed
on whether
they know if
they are
being
observed

Potential Limited Can be quite Limited Potentially Potentially Limited

Audience numbers, but large, but lack numbers and biassed by biassed numbers; it is
complete of response limited time which because difficult to
responses from some can of each documents the diffuse or
from those bias results were kept or subordinat adapt to other
interviewed because or potential users
document not intentional
created for this ly doesn't
purpose want to
directly
point out
his
superior’s
errors.
Process Modelling: Process modelling is the graphical representation of business
processes or workflows. Like a flow chart, individual steps of the process are
drawn out so there is an end-to-end overview of the tasks in the process within the
context of the business environment.
A process model allows visualisation of business processes so organisations can
better understand their internal business procedures so that they can be managed
and made more efficient. This is usually an agile exercise for continuous
improvement.
Process modelling is a vital component of process automation, as a process model
needs to be created first to define tasks and optimise the workflow before it is
automated.
Process Modelling using DFD:
What is Process Modeling
1. Process modeling is the mechanism of classifying the processes of the same
nature together into a model.
2. A process model is a description of a process at the type level. It is possible
to use the same process model to develop multiple applications.
3. Generally, a process model describes how things are done.
4. For example, business process modeling is a type of process modeling.
5. It describes the processes of an organisation to support analyzing and to
automate. Usually, a business analyst performs business process modeling.
6. It helps to improve the quality of the products, reduce costs, labors and
materials.
7. Overall, process modeling provides a number of advantages.
8. Process modeling tracks what happens during a process. It concerns
improvements to increase performance.
9. Furthermore, it denotes the designed processes and how they should work.
10.Process modeling also helps to establish rules and guidelines to increase
performance. Additionally, it focuses on data to extract for reporting tasks.
What is DFD(Data Flow Diagram)?
DFD is the abbreviation for Data Flow Diagram. The flow of data of a system or a
process is represented by DFD. It also gives insight into the inputs and outputs of
each entity and the process itself. DFD does not have control flow and no loops or
decision rules are present. Specific operations depending on the type of data can be
explained by a flowchart. It is a graphical tool, useful for communicating with
users, managers and other personnel. It is useful for analyzing existing as well as
proposed systems.
It provides an overview of:
● What data is system processes.
● What transformations are performed.
● What data is stored.
● What results are produced , etc.
Data Flow Diagrams can be represented in several ways. The DFD belongs to
structured-analysis modeling tools. Data Flow diagrams are very popular because
they help us to visualize the major steps and data involved in software-system
processes.
Characteristics of DFD:
● DFDs are commonly used during problem analysis.
● DFDs are quite general and are not limited to problem analysis for software
requirements specification.
● DFDs are very useful in understanding a system and can be effectively used
during analysis.
● It views a system as a function that transforms the inputs into desired
outputs.
● The DFD aims to capture the transformations that take place within a system
to the input data so that eventually the output data is produced.
● The processes are shown by named circles and data flows are represented by
named arrows entering or leaving the bubbles.
● A rectangle represents a source or sink and it is a net originator or consumer
of data. A source sink is typically outside the main system of study.
Components of DFD:
The Data Flow Diagram has 4 components:
● Process: Input to output transformation in a system takes place because of
process function. The symbols of a process are rectangular with rounded
corners, oval, rectangle or a circle. The process is named a short sentence, in
one word or a phrase to express its essence
● Data Flow: Data flow describes the information transferring between
different parts of the systems. The arrow symbol is the symbol of data flow.
 A relatable name should be given to the flow to determine the information
which is being moved. Data flow also represents material along with
information that is being moved. Material shifts are modeled in systems that
are not merely informative. A given flow should only transfer a single type
of information. The direction of flow is represented by the arrow which can
also be bi-directional.
● Warehouse: The data is stored in the warehouse for later use. Two
horizontal lines represent the symbol of the store. The warehouse is simply
not restricted to being a data file rather it can be anything like a folder with
documents, an optical disc, a filing cabinet. The data warehouse can be
viewed independent of its implementation. When the data flows from the
warehouse it is considered as data reading and when data flows to the
warehouse it is called data entry or data updating.
● Terminator: The Terminator is an external entity that stands outside of the
system and communicates with the system. It can be, for example,
organizations like banks, groups of people like customers or different
departments of the same organization, which is not a part of the model
system and is an external entity. Modeled systems also communicate with
terminators.

Rules for creating DFD:

 1. The name of the entity should be easy and understandable without any extra
assistance(like comments).
2. The processes should be numbered or put in an ordered list to be referred to
easily.
3. The DFD should maintain consistency across all the DFD levels.
4. A single DFD can have a maximum of nine processes and a minimum of
three processes.
Symbols Used in DFD:
1. Square Box: A square box defines the source or destination of the system. It
is also called an entity. It is represented by a rectangle.
2. Arrow or Line: An arrow identifies the data flow i.e. it gives information to
the data that is in motion.
3. Circle or bubble chart: It represents a process that gives us information. It
is also called a processing box.
4. Open Rectangle: An open rectangle is a data store. This data is stored either
temporarily or permanently.
Levels of DFD:
DFD uses hierarchy to maintain transparency thus multi level DFD’s can be
created. Levels of DFD are as follows:
● 0-level DFD: It represents the entire system as a single bubble and provides
an overall picture of the system.
● 1-level DFD: It represents the main functions of the system and how they
interact with each other.
● 2-level DFD: It represents the processes within each function of the system
and how they interact with each other.
● 3-level DFD: It represents the data flow within each process and how the
data is transformed and stored.
Advantages of DFD:
1. It helps us to understand the functioning and the limits of a system.
2. It is a graphical representation which is very easy to understand as it helps
visualize contents.
3. Data Flow Diagram represents a detailed and well explained diagram of
system components.
4. It is used as part of the system documentation file.
 5. Data Flow Diagrams can be understood by both technical or nontechnical
people because they are very easy to understand.
Disadvantages of DFD:
1. At times DFD can confuse the programmers regarding the system.
2. Data Flow Diagrams take a long time to be generated, and many times due
to these reasons analysts are denied permission to work on it.
What is Data Modeling:
● Data modeling is the process of creating a data model for an information
system. It is also called database modeling because data modeling helps to
implement the database.
● Generally, data modeling involves defining and analyzing the data
requirements to support the business process and to generate the actual
database. Therefore, data modeling involves professional data modelers and
users of the information system.
● Mainly, there are three types of data models.
● The conceptual data model describes the initial requirements with the
business stakeholders. It includes important entities and their relationships.
However, it does not include any details of attributes and primary keys.
● The logical data model describes data more than the conceptual data model.
It includes the details of attributes, primary keys, and foreign keys and also
involves normalization.
● Finally, the physical data model helps to build the actual database.
● Furthermore, there are two other types of data modeling.
● First, strategic data modeling defines an overall architecture of the
information systems.
● The other type is data modeling during system analysis. It creates logical
data models as part of the development of new databases.
● Besides, data modeling provides multiple advantages. It helps to manage
data as a resource and helps to integrate information systems and to design
warehouses. Moreover, managers, analysts, engineers and testers can use
them to understand how data is related to each other.
Introduction of ER Model:
● The Entity Relational Model is a model for identifying entities to be
represented in the database and representation of how those entities are
 related. The ER data model specifies an enterprise schema that represents
the overall logical structure of a database graphically.
● The Entity Relationship Diagram explains the relationship among the
entities present in the database. ER models are used to model real-world
objects like a person, a car, or a company and the relation between these
real-world objects. In short, the ER Diagram is the structural format of the
database.
Why Use ER Diagrams In DBMS?
1. ER diagrams are used to represent the E-R model in a database, which
makes them easy to be converted into relations (tables).
2. ER diagrams provide the purpose of real-world modeling of objects which
makes them intently useful.
3. ER diagrams require no technical knowledge and no hardware support.
4. These diagrams are very easy to understand and easy to create even for a
naive user.
5. It gives a standard solution for visualizing the data logically.
Symbols Used in ER Model:
ER Model is used to model the logical view of the system from a data perspective
which consists of these symbols:
● Rectangles: Rectangles represent Entities in the ER Model.
● Ellipses: Ellipses represent Attributes in the ER Model.
● Diamond: Diamonds represent Relationships among Entities.
● Lines: Lines represent attributes to entities and entity sets with other
relationship types.
● Double Ellipse: Double Ellipses represent Multi-Valued Attributes.
● Double Rectangle: Double Rectangle represents a Weak Entity.
Components of ER Diagram:
ER Model consists of Entities, Attributes, and Relationships among Entities in a
Database System.

Entity:
An Entity may be an object with a physical existence – a particular person, car,
house, or employee – or it may be an object with a conceptual existence – a
company, a job, or a university course.
Entity Set: An Entity is an object of Entity Type and a set of all entities is called an
entity set. For Example, E1 is an entity having Entity Type Student and the set of
all students is called Entity Set. In ER diagram, Entity Type is represented as:

1. Strong Entity
A Strong Entity is a type of entity that has a key Attribute. Strong Entity does not
depend on other entities in the Schema. It has a primary key that helps in
identifying it uniquely, and it is represented by a rectangle. These are called Strong
Entity Types.
2. Weak Entity
An Entity type has a key attribute that uniquely identifies each entity in the entity
set. But some entity type exists for which key attributes can’t be defined. These are
called Weak Entity types.
For Example, A company may store the information of dependents (Parents,
Children, Spouse) of an Employee. But the dependents don’t exist without the
employee. So Dependent will be a Weak Entity Type and Employee will be
Identifying Entity type for Dependent, which means it is Strong Entity Type.
A weak entity type is represented by a Double Rectangle. The participation of
weak entity types is always total. The relationship between the weak entity type
and its identifying strong entity type is called identifying relationship and it is
represented by a double diamond.
Attributes:
Attributes are the properties that define the entity type. For example, Roll_No,
Name, DOB, Age, Address, and Mobile_No are the attributes that define entity
type Student. In the ER diagram, the attribute is represented by an oval.

1. Key Attribute:
The attribute which uniquely identifies each entity in the entity set is called the key
attribute. For example, Roll_No will be unique for each student. In the ER
diagram, the key attribute is represented by an oval with underlying lines.

2. Composite Attribute:
An attribute composed of many other attributes is called a composite attribute. For
example, the Address attribute of the student Entity type consists of Street, City,
State, and Country. In the ER diagram, the composite attribute is represented by an
oval consisting of ovals.
3. Multivalued Attribute:
An attribute consisting of more than one value for a given entity. For example,
Phone_No (can be more than one for a given student). In the ER diagram, a
multivalued attribute is represented by a double oval.

4. Derived Attribute:
An attribute that can be derived from other attributes of the entity type is known as
a derived attribute. e.g.; Age (can be derived from DOB). In the ER diagram, the
derived attribute is represented by a dashed oval.

The Complete Entity Type Student with its Attributes can be represented as:
Relationship Type and Relationship Set:
A Relationship Type represents the association between entity types. For example,
‘Enrolled in’ is a relationship type that exists between entity type Student and
Course. In the ER diagram, the relationship type is represented by a diamond and
connects the entities with lines.

A set of relationships of the same type is known as a relationship set. The

following relationship set depicts S1 as enrolled in C2, S2 as enrolled in C1, and
S3 as registered in C3.
Degree of a Relationship Set:
The number of different entity sets participating in a relationship set is called the
degree of a relationship set.
1. Unary Relationship: When there is only ONE entity set participating in a
relation, the relationship is called a unary relationship. For example, one person is
married to only one person.

2. Binary Relationship: When there are TWO entities participating in a

relationship, the relationship is called a binary relationship. For example, a Student
is enrolled in a Course.

3. n-ary Relationship: When there are n entities set participating in a relation, the
relationship is called an n-ary relationship.
Cardinality:
The number of times an entity of an entity set participates in a relationship set is
known as cardinality. Cardinality can be of different types:
1. One-to-One: When each entity in each entity set can take part only once in the
relationship, the cardinality is one-to-one. Let us assume that a male can marry one
female and a female can marry one male. So the relationship will be one-to-one.
The total number of tables that can be used in this is 2.

Using Sets, it can be represented as:

2. One-to-Many: In one-to-many mapping as well where each entity can be

related to more than one relationship and the total number of tables that can be
used in this is 2. Let us assume that one surgeon department can accommodate
many doctors. So the Cardinality will be 1 to M. It means one department has
many Doctors.
The total number of tables that can be used is 3.
Using sets, one-to-many cardinality can be represented as:

3. Many-to-One: When entities in one entity set can take part only once in the
relationship set and entities in other entity sets can take part more than once in the
relationship set, cardinality is many to one. Let us assume that a student can take
only one course but one course can be taken by many students. So the cardinality
will be n to 1. It means that for one course there can be n students but for one
student, there will be only one course.
The total number of tables that can be used in this is 3.

Using Sets, it can be represented as:

In this case, each student is taking only 1 course but 1 course has been taken by
many students.
4. Many-to-Many: When entities in all entity sets can take part more than once in
the relationship cardinality is many to many. Let us assume that a student can take
more than one course and one course can be taken by many students. So the
relationship will be many to many.
The total number of tables that can be used in this is 3.

Using Sets, it can be represented as:

Participation Constraint:
Participation Constraint is applied to the entity participating in the relationship set.
1. Total Participation – Each entity in the entity set must participate in the
relationship. If each student must enroll in a course, the participation of students
will be total. Total participation is shown by a double line in the ER diagram.
2. Partial Participation – The entity in the entity set may or may NOT participate
in the relationship. If some courses are not enrolled by any of the students, the
participation in the course will be partial.
The diagram depicts the ‘Enrolled in’ relationship set with Student Entity set
having total participation and Course Entity set having partial participation.

Using Set, it can be represented as,

Every student in the Student Entity set participates in a relationship but there exists
a course C4 that is not taking part in the relationship.
How to Draw an ER Diagram?
1. The very first step is Identifying all the Entities, and placing them in a
Rectangle, and labeling them accordingly.
2. The next step is to identify the relationship between them and pace them
accordingly using the Diamond, and make sure that, Relationships are not
connected to each other.
3. Attach attributes to the entities properly.
4. Remove redundant entities and relationships.
5. Add proper colors to highlight the data present in the database.
Programming Practices:
Programming refers to the method of creating a sequence of instructions to enable
the computer to perform a task. It is done by developing logic and then writing
instructions in a programming language. A program can be written using various
programming practices available. A programming practice refers to the way of
writing a program and is used along with coding style guidelines. Some of the
commonly used programming practices include top-down programming,
bottom-up programming, structured programming, and information hiding.
Top-down Programming:
● Top-down programming focuses on the use of modules. It is therefore also
known as modular programming.
● The program is broken up into small modules so that it is easy to trace a
particular segment of code in the software program.
● The modules at the top level are those that perform general tasks and
proceed to other modules to perform a particular task.
● Each module is based on the functionality of its functions and procedures. In
this approach, programming begins from the top level of hierarchy and
progresses towards the lower levels.
● The implementation of modules starts with the main module. After the
implementation of the main module, the subordinate modules are
implemented and the process follows in this way.
● In top-down programming, there is a risk of implementing data structures as
the modules are dependent on each other and they have to share one or more
functions and procedures.
 ● In this way, the functions and procedures are globally visible. In addition to
modules, the top-down programming uses sequences and the nested levels of
commands.
Bottom-up Programming:
● Bottom-up programming refers to the style of programming where an
application is constructed with the description of modules.
● The description begins at the bottom of the hierarchy of modules and
progresses through higher levels until it reaches the top.
● Bottom-up programming is just the opposite of top-down programming.
Here, the program modules are more general and reusable than top-down
programming.
● It is easier to construct functions in a bottom-up manner. This is because
bottom-up programming requires a way of passing complicated arguments
between functions.
● It takes the form of constructing abstract data types in languages such as
C++ or Java, which can be used to implement an entire class of applications
and not only the one that is to be written.
● It therefore becomes easier to add new features in a bottom-up approach
than in a top-down programming approach.
Structured Programming:
● Structured programming is concerned with the structures used in a computer
program. Generally, structures of computer programs comprise decisions,
sequences, and loops.
● The decision structures are used for conditional execution of statements (for
example, ‘if statement). The sequence structures are used for the
sequentially executed statements.
● The loop structures are used for performing some repetitive tasks in the
program.
● Structured programming forces a logical structure in the program to be
written in an efficient and understandable manner.
● The purpose of structured programming is to make the software code easy to
modify when required. Some languages such as Ada, Pascal, and dBase are
designed with features that implement the logical program structure in the
software code. Primarily, the structured programming focuses on reducing
the following statements from the program.
 1. ‘GOTO’ statements.
2. ‘Break’ or ‘Continue’ outside the loops.
3. Multiple exit points to a function, procedure, or subroutine. For
example, multiple ‘Return’ statements should not be used.
4. Multiple entry points to a function, procedure, or a subroutine.
● Structured programming generally makes use of top-down design because
program structure is divided into separate subsections.
● A defined function or set of similar functions is kept separately. Due to this
separation of functions, they are easily loaded in the memory.
● In addition, these functions can be reused in one or more programs. Each
module is tested individually.
● After testing, they are integrated with other modules to achieve an overall
program structure.
● Note that a key characteristic of a structured statement is the presence of a
single entry and single exit point.
● This characteristic implies that during execution, a structured statement
starts from one defined point and terminates at another defined point.
Information Hiding:
● Information hiding focuses on hiding the non-essential details of functions
and code in a program so that they are inaccessible to other components of
the software.
● A software developer applies information hiding in software design and
coding to hide unnecessary details from the rest of the program. The
objective of information hiding is to minimize complexities among different
modules of the software.
● Note that complexities arise when one program or module in software is
dependent on several other programs and modules.
● Information hiding is implemented with the help of interfaces. An interface
is a medium of interaction for software components that are using the
properties of the software modules containing data.
● The implementation of interfaces depends on the syntax and process.
Examples of interface include constants, data types, types of procedures, and
so on. Interfaces protect other parts of programs when a software design is
changed.
 ● Generally, the interfaces act as a foundation to modular programming
(top-down programming) and object-oriented programming. In
object-oriented programming, the interface of an object comprises a set of
methods, which are used to interact with the objects of the software
programs.
● Using information hiding, a single program is divided into several modules.
These modules are independent of each other and can be used
interchangeably in other software programs.
● To understand the concept of information hiding, let us consider an example
of a program written for ‘cars’. The program can be organized in several
ways.
● One is to arrange modules without using information hiding. In this case, the
modules can be created as ‘front part’, ‘middle part’, and ‘rear part’.
● On the other hand, creating modules using information hiding includes
specifying names of modules such as ‘engine’ and ‘steering’.
● In comparison, it is found that modules created without using information
hiding affect other modules.
● This is because when a module is modified, it affects the data, which does
not require modification.
● However, if modules are created using information hiding, then modules are
concerned only with specific segments of the program and not the whole
program or other parts of the program.
● In our example, this statement means that the module ‘engine’ does not have
any effect on the module ‘steering’.
Paired Programming:
Pair programming is a development technique in which two programmers work
together at a single workstation. Person who writes code is called a driver and a
person who observes and navigates each line of the code is called navigator. They
may switch their role frequently. Sometimes pair programming is also known as
pairing. Pairing Variations : There are three pairing variations –
1. Newbie-newbie pairing can sometimes give a great result. Because it is
better than one solo newbie. But generally, this pair is rarely practiced.
2. Expert–newbie pairing gives significant results. In this pairing, a newbie can
learn many things from an expert, and the expert gets a chance to share his
knowledge with the newbie.
 3. Expert–expert pairing is a good choice for higher productivity as both of
them would be expert, so they can work very efficiently.
Advantages of Pair Programming :
1. Two brains are always better than one – If a driver encounters a problem
with code, there will be two of them who’ll solve the problem. When the
driver is writing code, the navigator can think about a solution to the
problem.
2. Detection of coding mistakes becomes easier – Navigator is observing each
and every line of code written by the driver, so mistakes or errors can be
detected easily.
3. Mutual learning – Both of them can share their knowledge with each other
and can learn many new things together.
4. Team develops better communication skills – Both of them share knowledge
and work together for many hours a day and constantly share information
with each other so this can help in developing better communication skills,
especially when one of the members is a newbie and the other is an expert.
Disadvantages of Pair Programming :
1. Team Fit – High-intensity communication of pair programming is not a good
fit for every developer. Sometimes, drivers are supposed to speak loud as
they write code. Some people may not agree on the idea of sitting, literally
shoulder-to-shoulder, with a colleague for eight hours a day. Some
experienced developers are more productive in solo rather than in pair
programming.
2. Newbie-newbie pairing problem – Newbie–newbie pairing can produce
results better than two newbies working independently, although this
practice is generally avoided because it is harder for newbies to develop
good habits without a proper role model.