Requirements Analysis and Specification   171

CHAPTER

4
REQUIREMENTS ANALYSIS
AND SPECIFICATION

CHAPTER OUTLINE
®® Requirements Gathering and Analysis
®® Software Requirements Specification
(SRS)
®® Formal System Specification
®® Axiomatic Specification
®® Algebraic Specification
®® Executable Specification and 4GL

Ours is a world where people don't know what they want and
yet are willing to go through hell to get it.
—Don Marquis
172   Fundamentals of Software Engineering

A
ll plan-driven life cycle models prescribe that before
LEARNING OBJECTIVES starting to develop a software, the exact requirements
®® Requirements gathering of the customer must be understood and documented.
and analysis techniques In the past, many projects have suffered because the developers
®® Requirements started to implement something without determining whether
specification using IEEE they were building what the customers exactly wanted. Starting
830 template development work without properly understanding and
®® Representation of documenting the requirements increases the number of iterative
complex logic changes in the later life cycle phases, and thereby alarmingly
®® Formal system pushes up the development
specification costs. This also sets the ground Experienced developers
for customer dissatisfaction take considerable time
and bitter customer-developer to understand the exact
disputes and protracted legal requirements of the customer
battles. No wonder that and to meticulously document
experienced d e ve l o p e r s those. They know that
consider the requirements without a clear understanding
analysis and specification to be of the problem and proper
a very important phase of documentation of the same,
software development life cycle it is impossible to develop a
and undertake it with utmost satisfactory solution.
care.
For any type of software development project, availability of
a good quality requirements document has been acknowledged
to be a key factor in the successful completion of the project.
A good requirements document not only helps to form a clear
understanding of various features required from the software,
but also serves as the basis for various activities carried out
during later life cycle phases. When software is developed
in a contract mode for some other organisation (that is, an
outsourced project), the crucial role played by documentation
of the precise requirements cannot be overstated. Even when
an organisation develops a generic software product, the
situation is not very different since some personnel from the
organisation’s own marketing department act as the customer.
Therefore, for all types of software development projects, proper
formulation of requirements and their effective documentation
is vital. However, for very small software service projects,
the agile methods advocate incremental development of the
requirements.

An overview of requirements analysis and

specification phase
The requirements analysis and specification phase starts after
the feasibility study stage is complete and the project has been
found to be financially viable and technically feasible.
 Requirements Analysis and Specification   173

The requirements analysis and specification phase

The goal of the requirements
ends when the requirements specification document has
analysis and specification phase
been developed and reviewed. The requirements
is to clearly understand the
specification document is usually called as the software
customer requirements and
requirements specification (SRS) document. The goal of the
to systematically organise
requirements analysis and specification phase can be
the requirements into a
stated in a nutshell as follows.
document called the Software
Who carries out requirements analysis and Requirements Specification
specification? (SRS) document.
Requirements analysis and specification activity is
usually carried out by a few experienced members of the development team and it
normally requires them to spend some time at the customer site. The engineers who
gather and analyse customer requirements and then write the requirements specification
document are known as system analysts in the software industry parlance. System analysts
collect data pertaining to the product to be developed and
analyse the collected data to conceptualise what exactly
The SRS document is the final
needs to be done. After understanding the precise user
outcome of the requirements
requirements, the analysts analyse the requirements to
analysis and specification phase.
weed out inconsistencies, anomalies and incompleteness.
They then proceed to write the software requirements
specification (SRS) document.

How is the SRS document validated?

Once the SRS document is ready, it is first reviewed internally by the project team to
ensure that it accurately captures all the user requirements, and that it is understandable,
consistent, unambiguous, and complete. The SRS document is then given to the customer
for review. After the customer has reviewed the SRS document and agrees to it, it forms
the basis for all future development activities and also serves as a contract document
between the customer and the development organisation.

What are the main activities carried out during requirements analysis and
specification phase?
Requirements analysis and specification phase mainly involves carrying out the following
two important activities:
„„ Requirements gathering and analysis
„„ Requirements specification
In the next section, we will discuss the requirements gathering and analysis activity
and in the subsequent section we will discuss the requirements specification activity.

4.1 REQUIREMENTS GATHERING AND ANALYSIS

The complete set of requirements are almost never available in the form of a single
document from the customer. In fact, it would be unrealistic to expect the customers
to produce a comprehensive document containing a precise description of what they
174   Fundamentals of Software Engineering

want. Further, the complete requirements are rarely obtainable from any single customer
representative. Therefore, the requirements have to be systematically gathered by the
analyst from several sources in bits and pieces. These gathered requirements need to be
analysed to remove several types of problems that frequently occur in the requirements
that have been gathered piecemeal from different sources.
We can conceptually divide the requirements gathering and analysis activity into two
separate tasks:
„„ Requirements gathering
„„ Requirements analysis
We discuss these two tasks in the following subsections.

4.1.1 Requirements Gathering

Requirements gathering activity is also popularly known as requirements elicitation. The
primary objective of the requirements gathering task is to collect the requirements from
the stakeholders.
Requirements gathering may sound like a simple task. A stakeholder is a source
However, in practice it is very difficult to gather all the of the requirements and is
necessary information from a large number of stakeholders usually a person, or a group
and from information scattered across several pieces of persons who either directly
of documents. Gathering requirements turns out to be or indirectly is concerned with
especially challenging if there is no working model of the the software.
software being developed.
Suppose a customer wants to automate some activity in his organisation that is
currently being carried out manually. In this case, a working model of the system (that
is, a manual system) exists. Availability of a working model is usually of great help
in requirements gathering. For example, if the project involves automating the existing
accounting activities of an organisation, then the task of the system analyst becomes a
lot easier as he can immediately obtain the input and output forms and the details of the
operational procedures. In this context, consider that it is required to develop a software
to automate the book-keeping activities involved in the operation of a certain office. In this
case, the analyst would have to study the input and output forms and then understand how
the outputs are produced from the input data. However, if a project involves developing
something new for which no working model exists, then the requirements gathering activity
becomes all the more difficult. In the absence of a working system, much more imagination
and creativity is required on the part of the system analyst.
Typically even before visiting the customer site, requirements gathering activity is
started by studying the existing documents to collect all possible information about the
system to be developed. During visit to the customer site, the analysts normally interview
the end-users and customer representatives,1 carry out requirements gathering activities
such as questionnaire surveys, task analysis, scenario analysis, and form analysis.
Given that many customers are not computer savvy, they describe their requirements
very vaguely. Good analysts share their experience and expertise with the customer and
1
 ote that the customer and the users of a software may, in general, be different. For example, the
N
customer may be an organisation and the users may be a few select employees of the organisation.
 Requirements Analysis and Specification   175

give his suggestions to define certain functionalities more comprehensively, make the
functionalities more general and more complete. In the following, we briefly discuss the
important ways in which an experienced analyst gathers requirements:
1. Studying existing documentation: The analyst usually studies all the available
documents regarding the system to be developed before visiting the customer site.
Customers usually provide statement of purpose (SoP) document to the analyst. Typically
these documents might discuss issues such as the context in which the software is required,
the basic purpose, the stakeholders, and the broad category of features required.
2. Interview: Typically, there are many different categories of users of a software. Each
category of users typically requires a different set of features from the software. Therefore,
it is important for the analyst to first identify the different categories of users and then
determine the requirements of each. For example, the different categories of users of a library
automation software could be the library members, the librarians, and the accountants.
The library members would like to use the software to query availability of books and
issue and return books. The librarians might like to use the software to determine books
that are overdue, create member accounts, delete member accounts, etc. The accounts
personnel might use the software to invoke functionalities concerning financial aspects
such as the total fee collected from the members, book procurement expenditures, staff
salary expenditures, etc.
To systematise this method of requirements gathering, the Delphi technique can be
followed. In this technique, the analyst consolidates the requirements as understood by
him in a document and then circulates it for the comments of the various categories of
users. Based on their feedback, he refines his document. This procedure is repeated till the
different users agree on the set of requirements.
3. Task analysis: The users usually have a black-box view of a software and consider the
software as something that provides a set of services (functionalities). A service supported
by a software is also called a task. We can therefore say that the software performs various
tasks of the users. In this context, the analyst tries to identify and understand the different
tasks to be performed by the software. For each identified task, the analyst tries to formulate
the different steps necessary to realise the required functionality in consultation with the
users. For example, consider the issue book task. The steps may be—authenticate user,
check the number of books issued to the customer and
determine if the maximum number of books that this Task analysis helps the analyst
member can borrow has been reached, check whether the to understand the nitty-gritty
book has been reserved, post the book issue details in the of various user tasks and
member’s record, and finally print out a book issue slip to represent each task as a
that can be presented by the member at the security hierarchy of subtasks.
counter to take the book out of the library premises.
4. Scenario analysis: A task can have many scenarios of operation. The different scenarios
of a task may take place when the task is invoked under different situations. For different
scenarios of a task, the behaviour of the software can be different. For example, the possible
scenarios for the book issue task of a library automation software may be:
„„ Book is issued successfully to the member and the book issue slip is printed.
„„ The book is reserved, and hence cannot be issued to the member.
176   Fundamentals of Software Engineering

„„ The maximum number of books that can be issued to the member is already reached,
and no more books can be issued to the member.
For various identified tasks, the possible scenarios of execution are identified and
the details of each scenario is identified in consultation with the users. For each of the
identified scenarios, details regarding system response, the exact conditions under which
the scenario occurs, etc. are determined in consultation with the user.
5. Form analysis: Form analysis is an important and effective requirements gathering
activity that is undertaken by the analyst, when the project involves automating an
existing manual system. During the operation of a manual system, normally several
forms are required to be filled up by the stakeholders, and in turn they receive several
notifications (usually manually filled forms). In form analysis, the exiting forms and the
formats of the notifications produced are analysed to determine the data input to the
system and the data that are output from the system. For the different sets of data
input to the system, how the input data would be used by the system to produce the
corresponding output data is determined from the users.

CASE STUDY 4.1

Requirements gathering for office automation at the CSE department
The academic, inventory, and financial information at the CSE (Computer Science and Engineering)
department of a certain institute was being carried out manually by two office clerks, a store keeper,
and two attendants. The department has a student strength of 500 and a teacher strength of 30. The
head of the department (HoD) wants to automate the office work. Considering the low budget that
he has at his disposal, he entrusted the work to a team of student volunteers.
For requirements gathering, a member of the team who was responsible for requirements analysis
and specification (analyst) was first briefed by the HoD about the specific activities to be automated.
The HoD mentioned that three main aspects of the office work needs to be automated—stores-related
activities, student grading activities, and student leave management activities. It was necessary for the
analyst to meet the other categories of users. The HoD introduced the analyst (a student) to the office
staff. The analyst first discussed with the two clerks regarding their specific responsibilities (tasks) that
were required to be automated. For each task, they asked the clerks to brief them about the steps
through which these are carried out. The analyst also enquired about the various scenarios that might
arise for each task. The analyst collected all types of forms that were being used by the student and
the staff of the department to submit various requests and to register various types of information with
the office (e.g., student course registration, course grading) or requests for some specific service (e.g.,
issue of items from store). He also collected samples of various types of documents (outputs) the clerks
were preparing. Some of these had specific printed forms that the clerks filled up manually, and others
were entered using a spreadsheet, and then printed out on a laser printer. For each output form, the
analyst consulted the clerks regarding how these different entries are generated from the input data.
The analyst met the storekeeper and enquired about the material issue procedures, store ledger
entry procedures, and the procedures for raising indents on various vendors. He also collected copies
of all the relevant forms that were being used by the storekeeper. The analyst also interviewed the
student and faculty representatives. Since it was needed to automate the existing activities of a working
office, the analyst could without much difficulty obtain the exact formats of the input data, output
data, and the precise description of the existing office procedures.
 Requirements Analysis and Specification   177

4.1.2 Requirements Analysis

After requirements gathering is complete, the analyst The main purpose of the
analyses the gathered requirements to form a clear requirements analysis activity
understanding of the exact customer requirements and to is to analyse the gathered
weed out any problems in the gathered requirements. It requirements to remove all
is natural to expect that the data collected from various ambiguities, incompleteness,
stakeholders to contain several contradictions, ambiguities, and inconsistencies from
and incompleteness, since each stakeholder typically the gathered customer
has only a partial and incomplete view of the software. requirements and to obtain
Therefore, it is necessary to identify all the problems a clear understanding of the
in the requirements and resolve them through further software to be developed.
discussions with the customer.
For carrying out requirements analysis effectively, the
analyst first needs to develop a clear grasp of the problem. The following basic questions
pertaining to the project should be clearly understood by the analyst before carrying out
analysis:
„„ What is the problem?
„„ Why is it important to solve the problem?
„„ What exactly are the data input to the system and what exactly are the data output
by the system?
„„ What are the possible procedures that need to be followed to solve the problem?
„„ What are the likely complexities that might arise while solving the problem?
„„ If there are external software or hardware with which the developed software has
to interface, then what should be the data interchange formats with the external
systems?
After the analyst has understood the exact customer
requirements, he proceeds to identify and resolve During requirements analysis,
the various problems that he detects in the gathered the analyst needs to identify
requirements. and resolve three main types of
Let us examine these different types of requirements problems in the requirements:
problems in detail.
®® Anomaly
Anomaly: It is an anomaly is an ambiguity in a ®® Inconsistency
requirement. When a requirement is anomalous, several ®® Incompleteness
interpretations of that requirement are possible. Any
anomaly in any of the requirements can lead to the
development of an incorrect system, since an anomalous requirement can be interpreted
in the several ways during development. The following are two examples of anomalous
requirements:

EXAMPLE 4.1 While gathering the requirements for a process control application, the
following requirement was expressed by a certain stakeholder: When the temperature
becomes high, the heater should be switched off. Please note that words such as “high”,
“low”, “good”, “bad”, etc. are indications of ambiguous requirements as these lack
178   Fundamentals of Software Engineering

quantification and can be subjectively interpreted. If the threshold above which the
temperature can be considered to be high is not specified, then it may get interpreted
differently by different developers.

EXAMPLE 4.2 In the case study 4.1, suppose one office clerk described the following
requirement: during the final grade computation, if any student scores a sufficiently
low grade in a semester, then his parents would need to be informed. This is clearly an
ambiguous requirement as it lacks any well defined criterion as to what can be considered
as a “sufficiently low grade”.
Inconsistency: Two requirements are said to be inconsistent, if one of the requirements
contradicts the other. The following are two examples of inconsistent requirements:

EXAMPLE 4.3 Consider the following partial requirements that were collected from two
different stakeholders in a process control application development project.
„„ The furnace should be switched-off when the temperature of the furnace rises above
500C.
„„ When the temperature of the furnace rises above 500C, the water shower should
be switched- on and the furnace should remain on.
The requirements expressed by the two stakeholders are clearly inconsistent.

EXAMPLE 4.4 In the case study 4.1, suppose one of the clerks gave the following
requirement—a student securing fail grades in three or more subjects must repeat the
courses over an entire semester, and he cannot credit any other courses while repeating the
courses. Suppose another clerk expressed the following requirement—there is no provision
for any student to repeat a semester; the student should clear the subject by taking it as
an extra subject in any later semester.
There is a clear inconsistency between the requirements given by the two stakeholders.
Incompleteness: An incomplete set of requirements is one in which some requirements
have been overlooked. The lack of these features would be felt by the customer much later,
possibly while using the software. Often, incompleteness is caused by the inability of the
customer to visualise the system that is to be developed and to anticipate all the features
that would be required. An experienced analyst can detect most of these missing features
and suggest them to the customer for his consideration and approval for incorporation in
the requirements. The following are two examples of incomplete requirements:

EXAMPLE 4.5 Suppose for the case study 4.1, one of the clerks expressed the following—
If a student secures a grade point average (GPA) of less than 6, then the parents of the
student must be intimated about the regrettable performance through a (postal) letter as
well as through e-mail.
However, on an examination of all requirements, it was found that there is no provision
by which either the postal or e-mail address of the parents of the students can be entered
into the system. The feature that would allow entering the e-mail ids and postal addresses
of the parents of the students was missing, thereby making the requirements incomplete.

EXAMPLE 4.6 In a chemical plant automation software, suppose one of the requirements
is that if the internal temperature of the reactor exceeds 200C then an alarm bell must be
 Requirements Analysis and Specification   179

sounded. However, on an examination of all requirements, it was found that there is no

provision for resetting the alarm bell after the temperature has been brought down in any
of the requirements. This is clearly an incomplete requirement.

Can an analyst detect all the problems existing in the gathered requirements?
Many of the inconsistencies, anomalies, and incompleteness are detected effortlessly, while
some others require a focused study of the specific requirements. A few problems in the
requirements can, however, be very subtle and escape even the most experienced eyes.
Many of these subtle anomalies and inconsistencies can be detected, if the requirements are
specified and analysed using a formal method. Once a system has been formally specified,
it can be systematically (and even automatically) analysed to remove all problems from
the specification. We will discuss the basic concepts of formal system specification in
Section 4.3. Though the use of formal techniques is not widespread, the current practice
is to formally specify only the safety-critical2 parts of a system.

4.2 SOFTWARE REQUIREMENTS SPECIFICATION (SRS)

After the analyst has gathered all the required information regarding the software to be
developed, and has removed all incompleteness, inconsistencies, and anomalies from the
specification, he starts to systematically organise the requirements in the form of an SRS
document. The SRS document usually contains all the user requirements in a structured
though an informal form.
Among all the documents produced during a software development life cycle, SRS
document is probably the most important document and is the toughest to write. One
reason for this difficulty is that the SRS document is expected to cater to the needs of a
wide variety of audience. In the following subsection, we discuss the different categories
of users of an SRS document and their needs from it.

4.2.1 Users of SRS Document

Usually a large number of different people need the SRS document for very different
purposes. Some of the important categories of users of the SRS document and their needs
for use are as follows:
Users, customers, and marketing personnel: These stakeholders need to refer to the SRS
document to ensure that the system as described in the document will meet their needs.
Remember that the customer may not be the user of the software, but may be some one
employed or designated by the user. For generic products, the marketing personnel need
to understand the requirements that they can explain to the customers.
Software developers: The software developers refer to the SRS document to make sure
that they are developing exactly what is required by the customer.
Test engineers: The test engineers use the SRS document to understand the functionalities,
and based on this write the test cases to validate its working. They need that the required

2
A safety-critical system is one whose improper working can result in financial loss, loss of property,
or life.
180   Fundamentals of Software Engineering

functionality should be clearly described, and the input and output data should have been
identified precisely.
User documentation writers: The user documentation writers need to read the SRS
document to ensure that they understand the features of the product well enough to be
able to write the users’ manuals.
Project managers: The project managers refer to the SRS document to ensure that they
can estimate the cost of the project easily by referring to the SRS document and that it
contains all the information required to plan the project.
Maintenance engineers: The SRS document helps the maintenance engineers to understand
the functionalities supported by the system. A clear knowledge of the functionalities
can help them to understand the design and code. Also, a proper understanding of the
functionalities supported enables them to determine the specific modifications to the
system’s functionalities would be needed for a specific purpose.
Many software engineers in a project consider the SRS document to be a reference
document. However, it is often more appropriate to think of the SRS document as the
documentation of a contract between the development team and the customer. In fact,
the SRS document can be used to resolve any disagreements between the developers
and the customers that may arise in the future. The SRS document can even be used as
a legal document to settle disputes between the customers and the developers in a court
of law. Once the customer agrees to the SRS document, the development team proceeds
to develop the software and ensure that it conforms to all the requirements mentioned in
the SRS document.

4.2.2 Why Spend Time and Resource to Develop an SRS Document?

A well-formulated SRS document finds a variety of usage other than the primary intended
usage as a basis for starting the software development work. In the following subsection,
we identify the important uses of a well-formulated SRS document:
Forms an agreement between the customers and the developers: A good SRS document
sets the stage for the customers to form their expectation about the software and the
developers about what is expected from the software.
Reduces future reworks: The process of preparation of the SRS document forces
the stakeholders to rigorously think about all of the requirements before design and
development get underway. This reduces later redesign, recoding, and retesting. Careful
review of the SRS document can reveal omissions, misunderstandings, and inconsistencies
early in the development cycle.
Provides a basis for estimating costs and schedules: Project managers usually estimate
the size of the software from an analysis of the SRS document. Based on this estimate
they make other estimations such as the effort required to develop the software and the
total cost of development. The SRS document also serves as a basis for price negotiations
with the customer. The project manager also uses the SRS document for work scheduling.
 Requirements Analysis and Specification   181

Provides a baseline for validation and verification: The SRS document provides a
baseline against which compliance of the developed software can be checked. It is also
used by the test engineers to create the test plan.
Facilitates future extensions: The SRS document usually serves as a basis for planning
future enhancements.
Before we discuss about how to write an SRS document, we first discuss the
characteristics of a good SRS document and the pitfalls that one must consciously avoid
while writing an SRS document.

4.2.3 Characteristics of a Good SRS Document

The skill of writing a good SRS document usually comes from the experience gained from
writing SRS documents for many projects. However, the analyst should be aware of the
desirable qualities that every good SRS document should possess. IEEE Recommended
Practice for Software Requirements Specifications [IEEE, 1998] describes the content and
qualities of a good software requirements specification (SRS). Some of the identified
desirable qualities of an SRS document are the following:
„„ Concise: The SRS document should be concise and at the same time unambiguous,
consistent, and complete. Verbose and irrelevant descriptions reduce readability and
also increase the possibilities of errors in the document.
„„ Implementation-independent: The SRS should be free of design and implementation
decisions unless those decisions reflect actual requirements. It should only specify
what the system should do and refrain from stating
how to do these. This means that the SRS document The SRS document should
should specify the externally visible behaviour of describe the system (to be
the system and not discuss the implementation developed) as a black box,
issues. This view with which a requirement and should specify only the
specification is written, has been shown in externally visible behaviour of
Figure 4.1. Observe that in Figure 4.1, the SRS the system. For this reason,
document describes the output produced for the the SRS document is also called
different types of input and a description of the the black-box specification of
processing required to produce the output from the the software being developed.
input (shown in ellipses) and the internal working
of the software is not discussed at all.
Traceable: It should be possible to trace a specific requirement to the design elements
that implement it and vice versa. Similarly, it should be possible to trace a requirement
to the code segments that implement it and the test cases that test this requirement and
vice versa. Traceability is also important to verify the results of a phase with respect to
the previous phase and to analyse the impact of changing a requirement on the design
elements and the code.
Modifiable: Customers frequently change the requirements during the software
development due to a variety of reasons. Therefore, in practice the SRS document undergoes
several revisions during software development. Also, an SRS document is often modified
after the project completes to accommodate future enhancements and evolution. To cope up
182   Fundamentals of Software Engineering

FIGURE 4.1 The black-box view of a system as performing a set of functions.

with the requirements changes, the SRS document should be easily modifiable. For this, an
SRS document should be well-structured. A well-structured document is easy to understand
and modify. Having the description of a requirement scattered across many places in
the SRS document may not be wrong—but it tends to make the requirement difficult to
understand and also any modification to the requirement would become difficult as it
would require changes to be made at large number of places in the document.
Identification of response to undesired events: The SRS document should discuss the
system responses to various undesired events and exceptional conditions that may arise.
Verifiable: All requirements of the system as documented in the SRS document should be
verifiable. This means that it should be possible to design test cases based on the description
of the functionality as to whether or not requirements have been met in an implementation.
A requirement such as “the system should be user friendly” is not verifiable. On the other
hand, the requirement—“When the name of a book is entered, the software should display
whether the book is available for issue or it has been loaned out” is verifiable. Any feature
of the required system that is not verifiable should be listed separately in the goals of the
implementation section of the SRS document.

4.2.4 Attributes of Bad SRS Documents

SRS documents written by novices frequently suffer from a variety of problems. As discussed
earlier, the most damaging problems are incompleteness, ambiguity, and contradictions.
There are many other types of problems that a specification document might suffer from.
By knowing these problems, one can try to avoid them while writing an SRS document.
Some of the important categories of problems that many SRS documents suffer from are
as follows:
Over-specification: It occurs when the analyst tries to address the “how to” aspects in
the SRS document. For example, in the library automation problem, one should not specify
whether the library membership records need to be stored indexed on the member’s first
 Requirements Analysis and Specification   183

name or on the library member’s identification (ID) number. Over-specification restricts the
freedom of the designers in arriving at a good design solution.
Forward references: One should not refer to aspects that are discussed much later in
the SRS document. Forward referencing seriously reduces readability of the specification.
Wishful thinking: This type of problems concern description of aspects which would be
difficult to implement.
Noise: The term noise refers to presence of material not directly relevant to the software
development process. For example, in the register customer function, suppose the analyst
writes that customer registration department is manned by clerks who report for work
between 8 am and 5 pm, 7 days a week. This information can be called noise as it would
hardly be of any use to the software developers and would unnecessarily clutter the SRS
document, diverting the attention from the crucial points.
Several other “sins” of SRS documents can be listed and used to guard against writing
a bad SRS document and is also used as a checklist to review an SRS document.

4.2.5 Important Categories of Customer Requirements

A good SRS document, should properly categorize
and organise the requirements into different sections An SRS document should
[IEEE 830]. As per the IEEE 830 guidelines, the important clearly document the following
categories of user requirements are the following: aspects of a software:
In the following subsections, we briefly describe the ®® Functional requirements
different categories of requirements. ®® Non-functional
requirements
Functional requirements – Design and implementation
The functional requirements capture the functionalities constraints
required by the users from the system. We have already – External interfaces
pointed out in Chapter 2 that it is useful to consider a required
software as offering a set of functions {fi} to the user. These – Other non-functional
functions can be considered similar to a mathematical requirements
function f : I → O, meaning that a function transforms an ®® Goals of implementation.
element (ii) in the input domain (I) to a value (oi) in the
output (O). This functional view of a system is shown schematically in Figure 4.1. Each
function fi of the system can be considered as reading certain data ii, and then transforming a
set of input data (ii) to the corresponding set of output data (oi). The functional requirements
of the system should clearly describe each functionality that the system would support
along with the corresponding input and output data set. Considering that the functional
requirements are a crucial part of the SRS document, we discuss functional requirements
in more detail in Section 4.2.6. Section 4.2.7 discusses how the functional requirements can
be identified from a problem description. Finally, Section 4.2.8 discusses how the functional
requirements can be documented effectively.

Non-functional requirements
The non-functional requirements are non-negotiable obligations that must be supported by
the software. The non-functional requirements capture those requirements of the customer
184   Fundamentals of Software Engineering

that cannot be expressed as functions (i.e., accepting input data and producing output
data). Non-functional requirements usually address aspects concerning external interfaces,
user interfaces, maintainability, portability, usability,
maximum number of concurrent users, timing, and The IEEE 830 standard
throughput (transactions per second, etc.). The non- recommends that out of
functional requirements can be critical in the sense that the various non-functional
any failure by the developed software to achieve some requirements, the external
minimum defined level in these requirements can be interfaces, and the design and
considered as a failure and make the software unacceptable implementation constraints
by the customer. should be documented in
In the following subsections, we discuss the different two different sections. The
categories of non-functional requirements that are remaining non-functional
described under three different sections: requirements should be
Design and implementation constraints: Design and documented later in a section
implementation constraints are an important category of and these should include the
non-functional requirements describe any items or issues performance and security
that will limit the options available to the developers. requirements.
Some of the example constraints can be—corporate or
regulatory policies that needs to be honoured; hardware limitations; interfaces with other
applications; specific technologies, tools, and databases to be used; specific communications
protocols to be used; security considerations; design conventions or programming standards
to be followed, etc. Consider an example of a constraint that can be included in this
section—Oracle DBMS needs to be used as this would facilitate easy interfacing with other
applications that are already operational in the organisation.
External interfaces required: Examples of external interfaces are—hardware, software and
communication interfaces, user interfaces, report formats, etc. To specify the user interfaces,
each interface between the software and the users must be described. The description may
include sample screen images, any GUI standards or style guides that are to be followed,
screen layout constraints, standard buttons and functions (e.g., help) that will appear on
every screen, keyboard shortcuts, error message display standards, and so on. One example
of a user interface requirement of a software can be that it should be usable by factory
shop floor workers who may not even have a high school degree. The details of the user
interface design such as screen designs, menu structure, navigation diagram, etc. should
be documented in a separate user interface specification document.
Other non-functional requirements: This section contains a description of non- functional
requirements that neither are design constraints and nor are external interface requirements.
An important example is a performance requirement such as the number of transactions
completed per unit time. Besides performance requirements, the other non-functional
requirements to be described in this section may include reliability issues, accuracy of
results, and security issues.

Goals of implementation
The ‘goals of implementation’ part of the SRS document offers some general suggestions
regarding the software to be developed. These are not binding on the developers, and they
 Requirements Analysis and Specification   185

may take these suggestions into account if possible. For example, the developers may use
these suggestions while choosing among different design solutions.
The goals of implementation section might document
issues such as easier revisions to the system functionalities A goal, in contrast to the
that may be required in the future, easier support for new functional and non-functional
devices to be supported in the future, reusability issues, etc. requirements, is not checked by
These are the items which the developers might keep in their the customer for conformance
mind during development so that the developed system at the time of acceptance
may meet some aspects that are not required immediately. testing.
It is useful to remember that anything that would be tested
by the user and the acceptance of the system would depend on the outcome of this task,
is usually considered as a requirement to be fulfilled by the system and not a goal and
vice versa.

How to classify the different types of requirements?

We should be clear regarding the aspects of the system requirement that are to be
documented as the functional requirement, the ones to be documented as non-functional
requirement, and the ones to be documented as the goals of implementation. Aspects
which can be expressed as transformation of some input data to some output data (i.e., the
functions of the system) should be documented as the functional requirement. Any other
requirements whose compliance by the developed system can be verified by inspecting
the system are documented as non- functional requirements. Aspects whose compliance
by the developed system need not be verified but are merely included as suggestions to
the developers are documented as goals of the implementation.
The difference between non-functional requirements and guidelines is the following.
Non-functional requirements would be tested for compliance, before the developed product
is accepted by the customer whereas guideline, on the other hand, are customer request
that are desirable to be done, but would not be tested during product acceptance.
Functional requirements form the basis for most design and test methodologies.
Therefore, unless the functional requirements are properly identified and documented,
the design and testing activities cannot be carried out satisfactorily. We discuss how to
document the functional requirements in the next section.

4.2.6 Functional Requirements

In order to document the functional requirements of a system, it is necessary to first
learn to identify the high-level functions of the systems
by reading the informal documentation of the gathered A high-level function is one
requirements. The high-level functions would be split into using which the user can get
smaller subrequirements. Each high-level function is an some useful piece of work
instance of use of the system (use case) by the user in done.
some way.
However, the above is not a very accurate definition of a high-level function. For
example, how useful must a piece of work be performed by the system for it to be called
‘a useful piece of work’? Can the printing of the statements of the ATM transaction during
186   Fundamentals of Software Engineering

withdrawal of money from an ATM be called a useful piece of work? Printing of ATM
transaction should not be considered a high-level requirement, because the user does
not specifically request for this activity. The receipt gets printed automatically as part of
the withdraw money function. Usually, the user invokes (requests) the services of each
high-level requirement. It may therefore be possible to treat print receipt as part of the
withdraw money function rather than treating it as a high-level function. It is therefore
required that for some of the high-level functions, we might have to debate whether we
wish to consider it as a high-level function or not. However, it would become possible
to identify most of the high-level functions without much difficulty after practising the
solution to a few exercise problems.
Each high-level requirement typically involves accepting some data from the user
through a user interface, transforming it to the required response, and then displaying
the system response in proper format. For example, in a library automation software, a
high-level functional requirement might be search-book. This function involves accepting
a book name or a set of key words from the user, running a matching algorithm on the
book list, and finally outputting the matched books. The generated system response can
be in several forms, e.g., display on the terminal, a print out, some data transferred to
the other systems, etc. However, in degenerate cases, a high-level requirement may not
involve any data input to the system or production of displayable results. For example,
it may involve switch on a light, or starting a motor in an embedded application.

Are high-level functions of a system similar to mathematical functions?

We all know that a mathematical function transforms input data to output data. A high-
level function transforms certain input data to output data. However, except for very
simple high- level functions, a function rarely reads all its
required data in one go and rarely outputs all the results
For any given high-level
in one shot. In fact, a high-level function usually involves
function, there can be
a series of interactions between the system and one or
different interaction sequences
more users. An example of the interactions that may
or scenarios due to users
occur in a single high-level requirement has been shown
selecting different options or
in Figure 4.2. In Figure 4.2, the user inputs have been
entering different data items.
represented by rectangles and the response produced by
the system by circles. Observe that the rectangles and
circles alternate in the execution of a single high-level function of the system, indicating
a series of requests from the user and the corresponding responses from the system.
Typically, there is some initial data input by the user. After accepting this, the system
may display some response (called system action). Based on this, the user may input
further data, and so on.
In Figure 4.2, the different scenarios occur depending on the amount entered for
withdrawal. The different scenarios are essentially different behaviour exhibited by the
system for the same high-level function. Typically, each user input and the corresponding
system action may be considered as a sub-requirement of a high-level requirement. Thus,
each high-level requirement can consist of several sub-requirements.
 Requirements Analysis and Specification   187

FIGURE 4.2 User and system interactions in high-level functional requirement.

Is it possible to determine all input and output data precisely?

In a requirements specification document, it is desirable to define the precise data input
to the system and the precise data output by the system. Sometimes, the exact data items
may be very difficult to identify. This is especially the case, when no working model of the
system to be developed exists. In such cases, the data in a high-level requirement should
be described using high-level terms and it may be very difficult to identify the exact
components of this data accurately. Another aspect that must be kept in mind is that the
data might be input to the system in stages at different points in execution. For example,
consider the withdraw-cash function of an automated teller machine (ATM) of Figure 4.2.
Since during the course of execution of the withdraw-cash function, the user would have
to input the type of account, the amount to be withdrawn, it is very difficult to form a
single high-level name that would accurately describe both the input data. However, the
input data for the subfunctions can be more accurately described.
188   Fundamentals of Software Engineering

4.2.7 How to Identify the Functional Requirements?

The high-level functional requirements often need to be identified either from an
informal problem description document or from a
conceptual understanding of the problem. Each high-level requirement
Remember that there can be many types of users of characterises a way of system
a system and their requirements from the system may be usage (service invocation) by
very different. So, it is often useful to first identify the some user to perform some
different types of users who might use the system and meaningful piece of work.
then try to identify the different services expected from
the software by different types of users.
The decision regarding which functionality of the system can be taken to be a
high-level functional requirement and the one that can be considered as part of another
function (that is, a subfunction) leaves scope for some subjectivity. For example, consider
the issue-book function in a Library Automation System. Suppose, when a user invokes
the issue-book function, the system would require the user to enter the details of
each book to be issued. Should the entry of the book details be considered as a high-
level function, or as only a part of the issue-book function? Many times, the choice
is obvious. But, sometimes it requires making non-trivial decisions.

4.2.8 How to Document the Functional Requirements?

Once all the high-level functional requirements have been identified and the requirements
problems have been eliminated, these are documented. A function can be documented by
identifying the state at which the data is to be input to the system, its input data domain,
the output data domain, and the type of processing to be carried on the input data to
obtain the output data. We now illustrate the specification of the functional requirements
through two examples. Let us first try to document the withdraw-cash function of
an automated teller machine (ATM) system in the following. The withdraw-cash is a high-
level requirement. It has several sub-requirements corresponding to the different user
interactions. These user interaction sequences may vary from one invocation from another
depending on some conditions. These different interaction sequences capture the different
scenarios. To accurately describe a functional requirement, we must document all the
different scenarios that may occur.

EXAMPLE 4.7 Withdraw cash from ATM

R.1: Withdraw cash
Description: The withdraw-cash function first determines the type of account that the
user has and the account number from which the user wishes to withdraw cash. It
checks the balance to determine whether the requested amount is available in the
account. If enough balance is available, it outputs the required cash, otherwise it
generates an error message.
R.1.1: Select withdraw amount option
Input: “Withdraw amount” option selected
Output: User prompted to enter the account type
 Requirements Analysis and Specification   189

R.1.2: Select account type

Input: User selects option from any one of the following—savings/checking/deposit.
Output: Prompt to enter amount
R.1.3: Get required amount
Input: Amount to be withdrawn in integer values greater than 100 and less than 10,000 in
multiples of 100.
Output: The requested cash and printed transaction statement.
Processing: The amount is debited from the user’s account if sufficient balance is available,
otherwise an error message displayed.

EXAMPLE 4.8 Search book availability in library

R.1: Search book
Description Once the user selects the search option, he would be asked to enter the keywords.
The system would search the book in the book list based on the key words entered. After
making the search, the system should output the details of all books whose title or author
name match any of the key words entered. The book details to be displayed include: title,
author name, publisher name, year of publication, ISBN number, catalog number, and the
location in the library.
R.1.1: Select search option
Input: “Search” option
Output: User prompted to enter the key words
R.1.2: Search and display
Input: Key words
Output: Details of all books whose title or author name matches any of the key words
entered by the user. The book details displayed would include—title of the book, author
name, ISBN number, catalog number, year of publication, number of copies available, and
the location in the library.
Processing: Search the book list based on the key words:
R.2: Renew book
Description: When the “renew” option is selected, the user is asked to enter his membership
number and password. After password validation, the list of the books borrowed by him
are displayed. The user can renew any of his borrowed books by indicating them. A
requested book cannot be renewed if it is reserved by another user. In this case, an error
message would be displayed.
R.2.1: Select renew option
State: The user has logged in and the main menu has been displayed.
Input: “Renew” option selection.
Output: Prompt message to the user to enter his membership number and password.
R.2.2: Login
State: The renew option has been selected.
Input: Membership number and password.
190   Fundamentals of Software Engineering

Output: List of the books borrowed by the user is displayed, and user is prompted to select
the books to be renewed, if the password is valid. If the password is invalid, the user is
asked to re-enter the password.
Processing: Password validation, search the books issued to the user from the borrower’s
list and display.
Next function: R.2.3 if password is valid and R.2.2 if password is invalid.
R.2.3: Renew selected books
Input: User choice for books to be renewed out of the books borrowed by him.
Output: Confirmation of the books successfully renewed and apology message for the books
that could not be renewed.
Processing: Check if anyone has reserved any of the requested books. Renew the books
selected by the user in the borrower’s list, if no one has reserved those books.
In order to properly identify the high-level requirements, a lot of common sense and
the ability to visualise various scenarios that might arise in the operation of a function
are required. Please note that when any of the aspects of a requirement, such as the state,
processing description, next function to be executed, etc. are obvious, we have omitted it.
We have to make a trade-off between cluttering the document with trivial details versus
missing out some important descriptions.
Specification of large software: If there are large number of functional requirements
(much larger than seen), should they just be written in a long numbered list of requirements?
A better way to organise the functional requirements in this case would be to split the
requirements into sections of related requirements. For example, the functional requirements
of an academic institute automation software can be split into sections such as accounts,
academics, inventory, publications, etc. When there are too many functional requirements,
these should be properly arranged into sections. For example the following can be sections
in the trade house automation software:
„„ Customer management
„„ Account management
„„ Purchase management
„„ Vendor management
„„ Inventory management
Level of details in specification: Even for experienced analysts, a common dilemma is in
specifying too little or specifying too much. In practice, we would have to specify only the
important input/output interactions in a functionality along with the processing required
to generate the output from the input. However, if the interaction sequence is specified in
too much detail, then it becomes an unnecessary constraint on the developers and restricts
their choice in solution. On the other hand, if the interaction sequence is not sufficiently
detailed, it may lead to ambiguities and result in improper implementation.

4.2.9 Traceability
Traceability means that it would be possible to identify (trace) the specific design component
which implements a given requirement, the code part that corresponds to a given design
 Requirements Analysis and Specification   191

component, and test cases that test a given requirement. Thus, any given code component
can be traced to the corresponding design component, and a design component can be
traced to a specific requirement that it implements and vice versa. Traceability analysis is
an important concept and is frequently used during software development. For example,
by doing a traceability analysis, we can tell whether all the requirements have been
satisfactorily addressed in all phases. It can also be used to assess the impact of a
requirements change. That is, traceability makes it easy to identify which parts of the
design and code would be affected, when certain requirement change occurs. It can also
be used to study the impact of a bug that is known to exist in a code part on various
requirements, etc.
To achieve traceability, it is necessary that each functional requirement should be
numbered uniquely and consistently. Proper numbering of the requirements makes it
possible for different documents to uniquely refer to specific requirements. An example
scheme of numbering the functional requirements is shown in Examples 4.7 and 4.8, where
the functional requirements have been numbered R.1, R.2, etc. and the subrequirements
for the requirement R.1 have been numbered R.1.1, R.1.2, etc.

4.2.10 Organisation of the SRS Document

In this section, we discuss the organisation of an SRS document as prescribed by the
IEEE 830 standard [IEEE 830]. Please note that IEEE 830 standard has been intended
to serve only as a guideline for organizing a requirements specification document into
sections and allows the flexibility of tailoring it, as may be required for specific projects.
Depending on the type of project being handled, some sections can be omitted, introduced,
or interchanged as may be considered prudent by the analyst. However, organisation of
the SRS document to a large extent depends on the preferences of the system analyst
himself, and he is often guided in this by the policies and standards being followed by the
development company. Also, the organisation of the document and the issues discussed
in it to a large extent depend on the type of the product being developed. However,
irrespective of the company’s principles and product type, the three basic issues that any
SRS document should discuss are—functional requirements, non-functional requirements,
and guidelines for system implementation.
The introduction section should describe the context in which the system is being
developed, and provide an overall description of the system, and the environmental
characteristics. The introduction section may include the hardware that the system will run
on, the devices that the system will interact with and the user skill-levels. Description of
the user skill-level is important, since the command language design and the presentation
styles of the various documents depend to a large extent on the types of the users it is
targeted for. For example, if the skill-levels of the users is “novice”, it would mean that the
user interface has to be very simple and rugged, whereas if the user-level is “advanced”,
several short cut techniques and advanced features may be provided in the user interface.
It is desirable to describe the formats for the input commands, input data, output
reports, and if necessary the modes of interaction. We have already discussed how the
contents of the Sections on the functional requirements, the non-functional requirements,
and the goals of implementation should be written. In the following subsections, we outline
the important sections that an SRS document should contain as suggested by the IEEE
192   Fundamentals of Software Engineering

830 standard, for each section of the document, we also briefly discuss the aspects that
should be discussed in it.

Introduction
Purpose: This section should describe where the software would be deployed and how
the software would be used.
Project scope: This section should briefly describe the overall context within which the
software is being developed. For example, the parts of a problem that are being automated
and the parts that would need to be automated during future evolution of the software.
Environmental characteristics: This section should briefly outline the environment
(hardware and other software) with which the software will interact.

Overall description of organisation of SRS document

Product perspective: This section needs to briefly state as to whether the software is
intended to be a replacement for a certain existing system, or it is a new software. If the
software being developed would be used as a component of a larger system, a simple
schematic diagram can be given to show the major components of the overall system,
subsystem interconnections, and external interfaces can be helpful.
Product features: This section should summarize the major ways in which the software
would be used. Details should be provided in Section 3 of the document. So, only a brief
summary should be presented here.
User classes: Various user classes that are expected to use this software are identified and
described here. The different classes of users are identified by the types of functionalities
that they are expected to invoke, or their levels of expertise in using computers.
Operating environment: This section should discuss in some detail the hardware platform
on which the software would run, the operating system, and other application software
with which the developed software would interact.
Design and implementation constraints: In this section, the different constraints on the
design and implementation are discussed. These might include—corporate or regulatory
policies; hardware limitations (timing requirements, memory requirements); interfaces
to other applications; specific technologies, tools, and databases to be used; specific
programming language to be used; specific communication protocols to be used; security
considerations; design conventions or programming standards.
User documentation: This section should list out the types of user documentation, such
as user manuals, on-line help, and trouble-shooting manuals that will be delivered to the
customer along with the software.

Functional requirements
This section can classify the functionalities either based on the specific functionalities
invoked by different users, or the functionalities that are available in different modes, etc.,
depending what may be appropriate.
 Requirements Analysis and Specification   193

1. User class 1
(a) Functional requirement 1.1
(b) Functional requirement 1.2
2. User class 2
(a) Functional requirement 2.1
(b) Functional requirement 2.2

External interface requirements

User interfaces: This section should describe a high-level description of various interfaces
and various principles to be followed. The user interface description may include sample
screen images, any GUI standards or style guides that are to be followed, screen layout
constraints, standard push buttons (e.g., help) that will appear on every screen, keyboard
shortcuts, error message display standards, etc. The details of the user interface design
should be documented in a separate user interface specification document.
Hardware interfaces: This section should describe the interface between the software
and the hardware components of the system. This section may include the description of
the supported device types, the nature of the data and control interactions between the
software and the hardware, and the communication protocols to be used.
Software interfaces: This section should describe the connections between this software
and other specific software components, including databases, operating systems, tools,
libraries, and integrated commercial components, etc. Identify the data items that would
be input to the software and the data that would be output should be identified and the
purpose of each should be described.
Communications interfaces: This section should describe the requirements associated
with any type of communications required by the software, such as e-mail, web access,
network server communications protocols, etc. This section should define any pertinent
message formatting to be used. It should also identify any communication standards that
will be used, such as TCP sockets, FTP, HTTP, or SHTTP. Specify any communication
security or encryption issues that may be relevant, and also the data transfer rates, and
synchronisation mechanisms.

Other non-functional requirements for organisation of SRS document

This section should describe the non-functional requirements other than the design and
implementation constraints and the external interface requirements that have been described
in Sections 2 and 4 respectively.
Performance requirements: Aspects such as number of transaction to be completed
per second should be specified here. Some performance requirements may be specific to
individual functional requirements or features. These should also be specified here.
Safety requirements: Those requirements that are concerned with possible loss or damage
that could result from the use of the software are specified here. For example, recovery
after power failure, handling software and hardware failures, etc. may be documented here.
194   Fundamentals of Software Engineering

Security requirements: This section should specify any requirements regarding security
or privacy requirements on data used or created by the software. Any user identity
authentication requirements should be described here. It should also refer to any external
policies or regulations concerning the security issues. Define any security or privacy
certifications that must be satisfied.
For software that have distinct modes of operation, in the functional requirements
section, the different modes of operation can be listed and in each mode the specific
functionalities that are available for invocation can be organised as follows.

Functional requirements
1. Operation mode 1
(a) Functional requirement 1.1
(b) Functional requirement 1.2
2. Operation mode 2
(a) Functional requirement 2.1
(b) Functional requirement 2.2
Specification of the behaviour may not be necessary for all systems. It is usually
necessary for those systems in which the system behaviour depends on the state in which
the system is, and the system transits among a set of states depending on some prespecified
conditions and events. The behaviour of a system can be specified using either the finite
state machine (FSM) formalism or any other alternate formalisms. The FSMs can used to
specify the possible states (modes) of the system and the transition among these states due
to occurrence of events.

EXAMPLE 4.9 (Personal library software): It is proposed to develop a software that

would be used by individuals to manage their personal collection of books. The following is
an informal description of the requirements of this software as worked out by the marketing
department. Develop the functional and non-functional requirements for the software.
A person can have up to a few hundreds of books. The details of all the books such
as name of the book, year of publication, date of purchase, price, and publisher would be
entered by the owner. A book should be assigned a unique serial number by the computer.
This number would be written by the owner using a pen on the inside page of the book.
Only a registered friend can be lent a book. While registering a friend, the following
data would have to be supplied—name of the friend, his address, land line number, and
mobile number. Whenever a book issue request is given, the name of the friend to whom
the book is to be issued and the unique id of the book is entered. At this, the various
books outstanding against the borrower along with the date borrowed are displayed for
information of the owner. If the owner wishes to go ahead with the issue of the book,
then the date of issue, the title of the book, and the unique identification number of the
book are stored. When a friend returns a book, the date of return is stored and the book
is removed from his borrowing list. Upon query, the software should display the name,
address, and telephone numbers of each friend against whom books are outstanding along
with the titles of the outstanding books and the date on which those were issued. The
software should allow the owner to update the details of a friend such as his address,
phone, telephone number, etc. It should be possible for the owner to delete all the data
pertaining to a friend who is no more active in using the library. The records should be
 Requirements Analysis and Specification   195

stored using a free (public domain) data base management system. The software should
run on both Windows and UNIX machines.
Whenever the owner of the library software borrows a book from his friends, would
enter the details regarding the title of the book, and the date borrowed and the friend
from whom he borrowed it. Similarly, the return details of books would be entered. The
software should be able to display all the books borrowed from various friends upon
request by the owner.
It should be possible for anyone to query about the availability of a particular book
through a web browser from any location. The owner should be able to query the total
number of books in the personal library, and the total amount he has invested in his library.
It should also be possible for him to view the number of books borrowed and returned by
any (or all) friend(s) over any specified time.

Functional requirements
The software needs to support three categories of functionalities as described below:
1. Manage own books
1.1 Register book
Description: To register a book in the personal library, the details of a book, such as name,
year of publication, date of purchase, price and publisher are entered. This is stored in the
database and a unique serial number is generated.
Input: Book details
Output: Unique serial number

R.1.2: Issue book

Description: A friend can be issued book only if he is registered. The various books
outstanding against him along with the date borrowed are first displayed.
R.1.2.1: Display outstanding books
Description: First a friend’s name and the serial number of the book to be issued are entered.
Then the books outstanding against the friend should be displayed.
Input: Friend name
Output: List of outstanding books along with the date on which each was borrowed.

R.1.2.2: Confirm issue book

If the owner confirms, then the book should be issued to him and the relevant records
should be updated.
Input: Owner confirmation for book issue.
Output: Confirmation of book issue.
R.1.3: Query outstanding books
Description: Details of friends who have books outstanding against their name is displayed.
Input: User selection
Output: The display includes the name, address and telephone numbers of each friend
against whom books are outstanding along with the titles of the outstanding books and
the date on which those were issued.
196   Fundamentals of Software Engineering

R.1.4: Query book

Description: Any user should be able to query a particular book from anywhere using a
web browser.
Input: Name of the book.
Output: Availability of the book and whether the book is issued out.
R.1.5: Return book
Description: Upon return of a book by a friend, the date of return is stored and the book
is removed from the borrowing list of the concerned friend.
Input: Name of the book.
Output: Confirmation message.

2. Manage friend details

R.2.1: Register friend
Description: A friend must be registered before he can be issued books. After the registration
data is entered correctly, the data should be stored and a confirmation message should
be displayed.
Input: Friend details including name of the friend, address, land line number and mobile
number.
Output: Confirmation of registration status.
R.2.2: Update friend details
Description: When a friend’s registration information changes, the same must be updated
in the computer.
R.2.2.1: Display current details
Input: Friend name.
Output: Currently stored details.
R2.2.2: Update friend details
Input: Changes needed.
Output: Updated details with confirmation of the changes.

R.3.3: Delete a friend record

Description: Delete records of inactive members.
Input: Friend name.
Output: Confirmation message.

3. Manage borrowed books

R.3.1: Register borrowed books
Description: The books borrowed by the user of the personal library are registered.
Input: Title of the book and the date borrowed.
Output: Confirmation of the registration status.
 Requirements Analysis and Specification   197

R.3.2: Deregister borrowed books

Description: A borrowed book is deregistered when it is returned.
Input: Book name.
Output: Confirmation of deregistration.

R.3.3: Display borrowed books

Description: The data about the books borrowed by the owner are displayed.
Input: User selection.
Output: List of books borrowed from other friends.

4. Manage statistics
R.4.1: Display book count
Description: The total number of books in the personal library should be displayed.
Input: User selection.
Output: Count of books.

R.4.2: Display amount invested

Description: The total amount invested in the personal library is displayed.
Input: User selection.
Output: Total amount invested.

R.4.3: Display number of transactions Description: The total numbers of books issued
and returned over a specific period by one (or all) friend(s) is displayed.
Input: Start of period and end of period.
Output: Total number of books issued and total number of books returned.

Non-functional requirements
N.1: Database: A data base management system that is available free of cost in the public
domain should be used.
N.2: Platform: Both Windows and UNIX versions of the software need to be developed.
N.3: Web-support: It should be possible to invoke the query book functionality from any
place by using a web browser.
Observation: Since there are many functional requirements, the requirements have been
organised into four sections: Manage own books, manage friends, manage borrowed books,
and manage statistics. Now each section has less than 7 functional requirements. This
would not only enhance the readability of the document, but would also help in design.

4.2.11 Techniques for Representing Complex Logic

A good SRS document should properly characterise the conditions under which different
scenarios of interaction occur (see Section 4.2.5). That is, a high-level function might involve
different steps to be undertaken as a consequence of some decisions made after each step.
Sometimes the conditions can be complex and numerous and several alternative interaction
198   Fundamentals of Software Engineering

and processing sequences may exist depending on the outcome of the corresponding
condition checking. A simple text description in such cases can be difficult to comprehend
and analyse. In such situations, a decision tree or a decision table can be used to represent
the logic and the processing involved. Also, when the decision making in a functional
requirement has been represented as a decision table, it becomes easy to automatically or
at least manually design test cases for it. However, use of decision trees or tables would
be superfluous in cases where the number of alternatives are few, or the decision logic is
straightforward. In such cases, a simple text description would suffice.
There are two main techniques available to analyse and represent complex processing
logic—decision trees and decision tables. Once the decision-making logic is captured
in the form of trees or tables, the test cases to validate these logic can be automatically
obtained. It should, however, be noted that decision trees and decision tables have much
broader applicability than just specifying complex processing logic in an SRS document.
For instance, decision trees and decision tables find applications in information theory and
switching theory.

Decision tree
A decision tree gives a graphic view of the processing logic involved in decision making
and the corresponding actions taken. Decision tables specify which variables are to be
tested, and based on this what actions are to be taken depending upon the outcome of the
decision-making logic, and the order in which decision making is performed.
The edges of a decision tree represent conditions and the leaf nodes represent the
actions to be performed depending on the outcome of testing the conditions. Instead of
discussing how to draw a decision tree for a given processing logic, we shall explain
through a simple example how to represent the processing logic in the form of a decision
tree.

EXAMPLE 4.10 A library membership management software (LMS) should support the
following three options—new member, renewal, and cancel membership. When the new
member option is selected, the software should ask the member’s name, address, and phone
number. If proper information is entered, the software should create a membership record
for the new member and print a bill for the annual membership charge and the security
deposit payable. If the renewal option is chosen, the LMS should ask the member’s name
and his membership number and check whether he is a valid member. If the member details
entered are valid, then the membership expiry date in the membership record should be
updated and the annual membership charge payable by the member should be printed. If
the membership details entered are invalid, an error message should be displayed. If the
cancel membership option is selected and the name of a valid member is entered, then the
membership is cancelled, a choke for the balance amount due to the member is printed
and his membership record is deleted. The decision tree representation for this problem
is shown in Figure 4.3.
Observe from Figure 4.3 that the internal nodes represent conditions, the edges of
the tree correspond to the outcome of the corresponding conditions. The leaf nodes
represent the actions to be performed by the system. In the decision tree of Figure 4.3,
first the user selection is checked. Based on whether the selection is valid, either further
 Requirements Analysis and Specification   199

condition checking is undertaken or an error message is displayed. Observe that the order
of condition checking is explicitly represented.

FIGURE 4.3 Decision Tree for LMS.

Decision table
A decision table shows the decision-making logic and the corresponding actions taken in
a tabular or a matrix form. The upper rows of the table specify the variables or conditions
to be evaluated and the lower rows specify the actions to be taken when an evaluation test
is satisfied. A column in the table is called a rule. A rule implies that if a certain condition
combination is true, then the corresponding action is executed. The decision table for the
LMS problem of Example 4.10 is as shown in Table 4.1.
TABLE 4.1 Decision Table for the LMS Problem
Conditions
Valid selection NO YES YES YES
New member - YES NO NO
Renewal - NO YES NO
Cancellation - NO NO YES
Actions
Display error message ×
Ask member’s name, etc. ×
Build customer record ×
Generate bill × ×
Ask membership details × ×
Update expiry date ×
Print cheque ×
Delete record ×

Decision table versus decision tree

Even though both decision tables and decision trees can be used to represent complex
program logic, they can be distinguishable on the following three considerations:
200   Fundamentals of Software Engineering

Readability: Decision trees are easier to read and understand when the number of
conditions are small. On the other hand, a decision table causes the analyst to look at
every possible combination of conditions which he might otherwise omit.
Explicit representation of the order of decision making: In contrast to the decision trees,
the order of decision making is abstracted out in decision tables. A situation where decision
tree is more useful is when multilevel decision making is required. Decision trees can more
intuitively represent multilevel decision making hierarchically, whereas decision tables can
only represent a single decision to select the appropriate action for execution.
Representing complex decision logic: Decision trees become very complex to understand
when the number of conditions and actions increase. It may even be to draw the tree
on a single page. When very large number of decisions are involved, the decision table
representation may be preferred.

4.3 FORMAL SYSTEM SPECIFICATION

In recent years, formal techniques3 have emerged as a central issue in software engineering.
This is not accidental; the importance of precise specification, modelling, and verification
is recognised to be important in most engineering disciplines. Formal methods provide us
with tools to precisely describe a system and show that a system is correctly implemented.
We say a system is correctly implemented when it satisfies its given specification. The
specification of a system can be given either as a list of its desirable properties (property-
oriented approach) or as an abstract model of the system (model-oriented approach). These
two approaches are discussed here. Before discussing representative examples of these two
types of formal specification techniques, we first discuss a few basic concepts in formal
specification. We will first highlight some important concepts in formal methods, and
examine the merits and demerits of using formal techniques.

4.3.1 What is a Formal Technique?

A formal technique is a mathematical method to specify a hardware and/or software
system, verify whether a specification is realisable, verify that an implementation satisfies
its specification, prove properties of a system without necessarily running the system, etc.
The mathematical basis of a formal method is provided by its specification language. More
precisely, a formal specification language consists of two sets—syn and sem, and a relation
sat between them. The set syn is called the syntactic domain, the set sem is called the semantic
domain, and the relation sat is called the satisfaction relation. For a given specification syn,
and model of the system sem, if sat (syn, sem), then syn is said to be the specification of sem,
and sem is said to be the specificand of syn.
The generally accepted paradigm for system development is through a hierarchy of
abstractions. Each stage in this hierarchy is an implementation of its preceding stage and
a specification of the succeeding stage. The different stages in this system development
activity are requirements specification, functional design, architectural design, detailed
design, coding, implementation, etc. In general, formal techniques can be used at every

3
Sections 4.3–4.5 can be omitted in a first level course on software engineering.
 Requirements Analysis and Specification   201

stage of the system development activity to verify that the output of one stage conforms
to the output of the previous stage.

Syntactic domains
The syntactic domain of a formal specification language consists of an alphabet of symbols
and a set of formation rules to construct well-formed formulas from the alphabet. The
well-formed formulas are used to specify a system.

Semantic domains
Formal techniques can have considerably different semantic domains. Abstract data type
specification languages are used to specify algebras, theories, and programs. Programming
languages are used to specify functions from input to output values. Concurrent and
distributed system specification languages are used to specify state sequences, event
sequences, state-transition sequences, synchronisation trees, partial orders, state machines,
etc.

Satisfaction relation
Given the model of a system, it is important to determine whether an element of the
semantic domain satisfies the specifications. This satisfaction is determined by using a
homomorphism known as semantic abstraction function. The semantic abstraction function
maps the elements of the semantic domain into equivalent classes. There can be different
specifications describing different aspects of a system model, possibly using different
specification languages. Some of these specifications describe the system’s behaviour and
the others describe the system’s structure. Consequently, two broad classes of semantic
abstraction functions are defined—those that preserve a system’s behaviour and those that
preserve a system’s structure.

Model versus property-oriented methods

Formal methods are usually classified into two broad categories—the so-called model-
oriented and the property-oriented approaches. In a model-oriented style, one defines a
system’s behaviour directly by constructing a model of the system in terms of mathematical
structures such as tuples, relations, functions, sets, sequences, etc. In the property-oriented
style, the system’s behaviour is defined indirectly by stating its properties, usually in the
form of a set of axioms that the system must satisfy. Let us consider a simple producer/
consumer example. In a property-oriented style, we would probably start by listing the
properties of the system like—the consumer can start consuming only after the producer
has produced an item, the producer starts to produce an item only after the consumer has
consumed the last item, etc. Two examples of property-oriented specification styles are
axiomatic specification and algebraic specification.
In a model-oriented style, we would start by defining the basic operations, p (produce)
and c (consume). Then we can state that S1 + p ⇒ S, S + c ⇒ S1. Thus model-oriented
approaches essentially specify a program by writing another, presumably simpler program.
A few notable examples of popular model-oriented specification techniques are Z, CSP,
CCS, etc.
It is alleged that property-oriented approaches are more suitable for requirements
specification, and that the model-oriented approaches are more suited to system design
202   Fundamentals of Software Engineering

specification. The reason for this distinction is the fact that property-oriented approaches
specify a system behaviour not by what they say of the system but by what they do
not say of the system. Thus, property-oriented specifications permit a large number of
possible implementations. Furthermore, property-oriented approaches specify a system by
a conjunction of axioms, thereby making it easier to alter/augment specifications at a later
stage. On the other hand, model-oriented methods do not support logical conjunctions and
disjunctions, and thus even minor changes to a specification may lead to overhauling an
entire specification. Since the initial customer requirements undergo several changes as the
development proceeds, the property-oriented style is generally preferred for requirements
specification. Later in this chapter, we have discussed two property-oriented specification
techniques.

4.3.2 Operational Semantics

Informally, the operational semantics of a formal method is the way computations are
represented. There are different types of operational semantics according to what is meant
by a single run of the system and how the runs are grouped together to describe the
behaviour of the system. In the following subsection we discuss some of the commonly
used operational semantics.
Linear semantics: In this approach, a run of a system is described by a sequence (possibly
infinite) of events or states. The concurrent activities of the system are represented by
non-deterministic interleavings of the atomic actions. For example, a concurrent activity
a|| b is represented by the set of sequential activities a; b and b; a. This is a simple but
rather unnatural representation of concurrency. The behaviour of a system in this model
consists of the set of all its runs. To make this model more realistic, usually justice and
fairness restrictions are imposed on computations to exclude the unwanted interleavings.
Branching semantics: In this approach, the behaviour of a system is represented by
a directed graph. The nodes of the graph represent the possible states in the evolution
of a system. The descendants of each node of the graph represent the states which can
be generated by any of the atomic actions enabled at that state. Although this semantic
model distinguishes the branching points in a computation, still it represents concurrency
by interleaving.
Maximally parallel semantics: In this approach, all the concurrent actions enabled at any
state are assumed to be taken together. This is again not a natural model of concurrency
since it implicitly assumes the availability of all the required computational resources.
Partial order semantics: Under this view, the semantics ascribed to a system is a structure
of states satisfying a partial order relation among the states (events). The partial order
represents a precedence ordering among events, and constrains some events to occur only after
some other events have occurred; while the occurrence of other events (called concurrent
events) is considered to be incomparable. This fact identifies concurrency as a phenomenon
not translatable to any interleaved representation.

Merits and limitations of formal methods

In addition to facilitating precise formulation of specifications, formal methods possess
several positive features, some of which are discussed as follows:
 Requirements Analysis and Specification   203

„„ Formal specifications encourage rigour. It is often the case that the very process
of construction of a rigorous specification is more important than the formal
specification itself. The construction of a rigorous specification clarifies several
aspects of system behaviour that are not obvious in an informal specification. It is
widely acknowledged that it is cost-effective to spend more efforts at the specification
stage, otherwise, many flaws would go unnoticed only to be detected at the later
stages of software development that would lead to iterative changes to occur in the
development life cycle. According to an estimate, for large and complex systems
like distributed real-time systems 80 per cent of project costs and most of the cost
overruns result from the iterative changes required in a system development process
due to inappropriate formulation of requirements specification. Thus, the additional
effort required to construct a rigorous specification is well worth the trouble.
„„ Formal methods usually have a well-founded mathematical basis. Thus, formal
specifications are not only more precise, but also mathematically sound and can
be used to reason about the properties of a specification and to rigorously prove
that an implementation satisfies its specifications. Informal specifications may be
useful in understanding a system and its documentation, but they cannot serve as
a basis of verification. Even carefully written specifications are prone to error, and
experience has shown that unverified specifications are comparable in reliability to
unverified programs.
„„ Formal methods have well-defined semantics. Therefore, ambiguity in specifications
is automatically avoided when one formally specifies a system.
„„ The mathematical basis of the formal methods makes it possible for automating the
analysis of specifications. For example, a tableau-based technique has been used
to automatically check the consistency of specifications. Also, automatic theorem
proving techniques can be used to verify that an implementation satisfies its
specifications. The possibility of automatic verification is one of the most important
advantages of formal methods.
„„ Formal specifications can be executed to obtain immediate feedback on the features
of the specified system. This concept of executable specifications is related to rapid
prototyping. Informally, a prototype is a “toy” working model of a system that
can provide immediate feedback on the behaviour of the specified system, and is
especially useful in checking the completeness of specifications.
It is clear that formal methods provide mathematically sound frameworks within which
large, complex systems can be specified, developed and verified in a systematic rather than
in an ad hoc manner. However, formal methods suffer from several shortcomings, some
of which are as following:
„„ Formal methods are difficult to learn and use.
„„ The basic incompleteness results of first-order logic suggest that it is impossible to
check absolute correctness of systems using theorem proving techniques.
„„ Formal techniques are not able to handle complex problems. This shortcoming results
from the fact that, even moderately complicated problems blow up the complexity of
formal specification and their analysis. Also, a large unstructured set of mathematical
formulas is difficult to comprehend.
204   Fundamentals of Software Engineering

It has been pointed out by several researchers that formal specifications neither
replace nor make the informal descriptions obsolete but complement them. In fact, the
comprehensibility of formal specifications is greatly enhanced when the specifications are
accompanied by an informal description. What is suggested is the use of formal techniques
as a broad guideline for the use of the informal techniques. An interesting example of
such an approach is reported by Jones in 1980 [Jones, 1980]. In this approach, the use of
a formal method identifies the necessary verification steps that need to be carried out, but
it is legitimate to apply informal reasoning in presentation of correctness arguments and
transformations. Any doubt or query relating to an informal argument is to be resolved
by formal proofs.
In the following two sections, we discuss the axiomatic and algebraic specification styles.
Both these techniques can be classified as the property-oriented specification techniques.

4.4 AXIOMATIC SPECIFICATION

In axiomatic specification of a system, first-order logic is used to write the pre- and post-
conditions to specify the operations of the system in the form of axioms. The pre-conditions
basically capture the conditions that must be satisfied before an operation can successfully
be invoked. In essence, the pre-conditions capture the requirements on the input parameters
of a function. The post-conditions are the conditions that must be satisfied when a function
completes execution for the function to be considered to have executed successfully. Thus,
the post-conditions are essentially constraints on the results produced for the function
execution to be considered successful.

How to develop an axiomatic specifications?

The following are the sequence of steps that can be followed to systematically develop the
axiomatic specifications of a function:
„„ Establish the range of input values over which the function should behave correctly.
Establish the constraints on the input parameters as a predicate.
„„ Specify a predicate defining the condition which must hold on the output of the
function if it behaved properly.
„„ Establish the changes made to the function’s input parameters after execution of the
function. Pure mathematical functions do not change their input and therefore this
type of assertion is not necessary for pure functions.
„„ Combine all of the above into pre- and post-conditions of the function.
We now illustrate how simple abstract data types can be algebraically specified through
two simple examples.

EXAMPLE 4.11 Specify the pre- and post-conditions of a function that takes a real
number as argument and returns half the input value if the input is less than or equal to
100, or else returns double the value.
f(x : real) : real
pre : x  R
post : {(x £ 100) ∧ (f (x) = x/2)} ∨ {(x > 100) ∧ (f (x) = 2 ∗ x)}
 Requirements Analysis and Specification   205

EXAMPLE 4.12 Axiomatically specify a function named search which takes an integer
array and an integer key value as its arguments and returns the index in the array where
the key value is present.
search(X : intArray, key : integer) : integer
pre : ∃i ∈ [Xfirst...Xlast], X[i] = key
post : {(X′[search(X, key)] = key) ∧ (X = X′)}
Please note that we have followed the convention that if a function changes any of its
input parameters, and if that parameter is named X, then we refer to it after the function
completes execution as X’. One practical application of the axiomatic specification is in
program documentation. Engineers developing code for a function specify the function by
noting down the pre- and post-conditions of the function in the function header. Another
application of the axiomatic specifications is in proving program properties by composing
the pre- and post-conditions of a number of functions.

4.5 ALGEBRAIC SPECIFICATION

In the algebraic specification technique, an object class or type is specified in terms of
relationships existing between the operations defined on that type. It was first brought into
prominence by Guttag [1980, 1985] in specification of abstract data types. Various notations
of algebraic specifications have evolved, including those based on OBJ and Larch languages.
Essentially, algebraic specifications define a system as a heterogeneous algebra. A
heterogeneous algebra is a collection of different sets on which several operations are
defined. Traditional algebras are homogeneous. A homogeneous algebra consists of a single
set and several operations defined in this set; e.g., {I, +, -, *, /}. In contrast, alphabetic strings
S together with operations of concatenation and length {S, I, con, len}, is not a homogeneous
algebra, since the range of the length operation is the set of integers.
Each set of symbols in a heterogeneous algebra is called a sort of the algebra. To
define a heterogeneous algebra, besides defining the sorts, we need to specify the involved
operations, their signatures, and their domains and ranges. Using algebraic specification,
we define the meaning of a set of interface procedures by using equations. An algebraic
specification is usually presented in four sections.
Types section: In this section, the sorts (or the data types) being used is specified.
Exception section: This section gives the names of the exceptional conditions that might
occur when different operations are carried out. These exception conditions are used in
the later sections of an algebraic specification.
Syntax section: This section defines the signatures of the interface procedures. The
collection of sets that form input domain of an operator and the sort where the output is
produced are called the signature of the operator. For example, PUSH takes a stack and an
element as its input and returns a new stack that has been created.
Equations section: This section gives a set of rewrite rules (or equations) defining the
meaning of the interface procedures in terms of each other. In general, this section is
allowed to contain conditional expressions.
206   Fundamentals of Software Engineering

By convention each equation is implicitly universally quantified over all possible

values of the variables. This means that the equation holds for all possible values of the
variable. Names not mentioned in the syntax section such r or e are variables. The first
step in defining an algebraic specification is to identify the set of required operations.
After having identified the required operators, it is helpful to classify them as either
basic constructor operators, extra constructor operators, basic inspector operators, or extra
inspection operators. The definition of these categories of operators is as follows:
Basic construction operators: These operators are used to create or modify entities of a
type. The basic construction operators are essential to generate all possible element of the
type being specified. For example, ‘create’ and ‘append’ are basic construction operators
in Example 4.13.
Extra construction operators: These are the construction operators other than the basic
construction operators. For example, the operator ‘remove’ in Example 4.13 is an extra
construction operator, because even without using ‘remove’ it is possible to generate all
values of the type being specified.
Basic inspection operators: These operators evaluate attributes of a type without modifying
them, e.g., eval, get, etc. Let S be the set of operators whose range is not the data type being
specified—these are the inspection operators. The set of the basic operators S1 is a subset
of S, such that each operator from S-S1 can be expressed in terms of the operators from S1.
Extra inspection operators: These are the inspection operators that are not basic inspectors.
A simple way to determine whether an operator is a constructor (basic or extra) or an
inspector (basic or extra) is to check the syntax expression for the operator. If the type being
specified appears on the right hand side of the expression then it is a constructor, otherwise
it is an inspection operator. For example, in Example 4.13, create is a constructor because
point appears on the right hand side of the expression and point is the data type being
specified. But, xcoord is an inspection operator since it does not modify the point type.
A good rule of thumb while writing an algebraic specification, is to first establish
which are the constructor (basic and extra) and inspection operators (basic and extra). Then
write down an axiom for composition of each basic construction operator over each basic
inspection operator and extra constructor operator. Also, write down an axiom for each
of the extra inspector in terms of any of the basic inspectors. Thus, if there are m1 basic
constructors, m2 extra constructors, n1 basic inspectors, and n2 extra inspectors, we should
have m1 × (m2 + n1) + n2 axioms. However, it should be clearly noted that these m1 ×
(m2 + n1) + n2 axioms are the minimum required and many more axioms may be needed
to make the specification complete. Using a complete set of rewrite rules, it is possible to
simplify an arbitrary sequence of operations on the interface procedures.
While developing the rewrite rules, different persons can come up with different sets of
equations. However, while developing the equations one has to be careful that the equations
should be able to handle all meaningful composition of operators, and they should have the
unique termination and finite termination properties. These two properties of the rewrite
rules are discussed later in this section.

EXAMPLE 4.13 Let us specify a data type point supporting the operations create, xcoord,
ycoord, isequal; where the operations have their usual meaning.
 Requirements Analysis and Specification   207

Types:

defines point
uses   boolean,   integer
Syntax:
1. create : integer × integer → point
2. xcoord : point → integer
3. ycoord : point → integer
4. isequal : point × point → boolean
Equations:
1. xcoord(create(x, y)) = x
2. ycoord(create(x, y)) = y
3. isequal(create(x1, y1), create(x2, y2)) = ((x1 = x2)and(y1 = y2))
In this example, we have only one basic constructor (create), and three basic inspectors
(xcoord, ycoord, and isequal). Therefore, we have only 3 equations.
The rewrite rules let you determine the meaning of any sequence of calls on the point
type. Consider the following expression: isequal (create (xcoord (create(2, 3)), 5),create (ycoord
(create(2, 3)), 5)). By applying the rewrite rule 1, you can simplify the given expression as
isequal (create (2, 5), create (ycoord (create(2, 3)), 5)). By using rewrite rule 2, you can further
simplify this as isequal (create (2, 5), create (3, 5)). This is false by rewrite rule 3.

Properties of algebraic specifications

Three important properties that every algebraic specification should possess are:
Completeness: This property ensures that using the equations, it should be possible
to reduce any arbitrary sequence of operations on the interface procedures. When the
equations are not complete, at some step during the reduction process, we might not be
able to reduce the expression arrived at that step by using any of the equations. There is
no simple procedure to ensure that an algebraic specification is complete.
Finite termination property: This property essentially addresses the following question: Do
applications of the rewrite rules to arbitrary expressions involving the interface procedures
always terminate? For arbitrary algebraic equations, convergence (finite termination) is
undecidable. But, if the right hand side of each rewrite rule has fewer terms than the left,
then the rewrite process must terminate.
Unique termination property: This property indicates whether application of rewrite
rules in different orders always result in the same answer. Essentially, to determine this
property, the answer to the following question needs to be checked—Can all possible
sequence of choices in application of the rewrite rules to an arbitrary expression involving
the interface procedures always give the same answer? Checking the unique termination
property is a very difficult problem.

EXAMPLE 4.14 Let us specify a FIFO queue supporting the operations create, append,
remove, first, and isempty; where the operations have their usual meaning.
Types:
defines queue
uses   boolean,   element
208   Fundamentals of Software Engineering
Exception:
underflow, novalue

Syntax:
1. create : f → queue
2. append : queue × element → queue
3. remove : queue → queue + {underflow}
4. first : queue → element + {novalue}
5. isempty : queue → boolean
Equations:
1. isempty(create()) = true
2. isempty(append(q, e)) = false
3. first(create()) = novalue
4. first(append(q, e)) = if isempty(q) then e else first(q)
5. remove(create()) = underflow
6. remove(append(q, e)) = if isempty(q) then create() else append(remove(q), e)
In this example, we have two basic construction operators (create and append). We
have one extra construction operator (remove). We have considered remove to be an extra
construction operator because all values of the queue can be realised, even without having
the remove operator. We have two basic inspectors (first and isempty). Therefore, we
have 2 × 3 = 6 equations.

4.5.1 Auxiliary Functions

Sometimes while specifying a system, one needs to introduce extra functions not part of
the system to define the meaning of some interface procedures. These are called auxiliary
functions. In the following, we discuss an example where it becomes necessary to use an
auxiliary function to be able to specify a system.

EXAMPLE 4.15 Let us specify a bounded FIFO queue having a maximum size of
MaxSize and supporting the operations create, append, remove, first, and isempty; where
the operations have their usual meaning.
Types:
defines queue
uses boolean, element, integer

Exception:
underflow, novalue, overflow

Syntax:
1. create : f → queue
2. append : queue × element → queue + {overflow}
3. size : queue → integer
4. remove : queue → queue + {underflow}
5. first : queue → element + {novalue}
6. isempty : queue → boolean
 Requirements Analysis and Specification   209

Equations:
1. first(create()) = novalue
2. first(append(q,e)) = if size(q)= MaxSize then overflow else if isempty(q) then e else first(q)
3. remove(create()) = underflow
4. remove(append(q, e)) = if isempty(q) then create() else

if size(q) = MaxSize then overflow else append(remove(q), e)
5. size(create()) = 0
6. size(append(q, e)) = if size(q) = MaxSize then overflow else size(q) + 1
7. isempty(q) = if (size(q) = 0) then true else false
In this example, we have used the auxiliary function size to enable us to specify that
during appending an element, overflow might occur if the queue size exceeds MaxSize.
However, after we have introduced the auxiliary function size, we find that the operator
isempty can no longer be considered as a basic inspector because isempty can be expressed
in terms of size. Therefore, we have removed the axioms for the operator isempty used
in Example 4.15, and have instead used an axiom to express isempty in terms of size.
We have added two axioms to express size in terms of the basic construction operators
(create and append).

4.5.2 Structured Specification

Developing algebraic specifications is time consuming. Therefore efforts have been made
to devise ways to ease the task of developing algebraic specifications. The following are
some of the techniques that have successfully been used to reduce the effort in writing
the specifications.
Incremental specification: The idea behind incremental specification is to first develop
the specifications of the simple types and then specify more complex types by using the
specifications of the simple types.
Specification instantiation: This involves taking an existing specification which has been
developed using a generic parameter and instantiating it with some other sort.

Pros and Cons of algebraic specifications

Algebraic specifications have a strong mathematical basis and can be viewed as heterogeneous
algebra. Therefore, they are unambiguous and precise. Using an algebraic specification,
the effect of any arbitrary sequence of operations involving the interface procedures can
automatically be analysed. A major shortcoming of algebraic specifications is that they
cannot deal with side effects. Therefore, algebraic specifications are difficult to integrate
with typical programming languages. Also, algebraic specifications are hard to understand.

4.6 EXECUTABLE SPECIFICATION AND 4GL

When the specification of a system is expressed formally or is described by using a
programming language, then it becomes possible to directly execute the specification
without having to design and write code for implementation. However, executable
210   Fundamentals of Software Engineering

specifications are usually slow and inefficient, 4GLs4 (4th Generation Languages) are
examples of executable specification languages. 4GLs are successful because there is a lot
of large granularity commonality across data processing applications which have been
identified and mapped to program code. 4GLs get their power from software reuse, where
the common abstractions have been identified and parameterized. Careful experiments
have shown that rewriting 4GL programs in 3GLs results in up to 50 per cent lower memory
usage and also the program execution time can reduce up to tenfolds.

SUMMARY
„„ Substantial time and effort must be spent in developing a good quality SRS document
before starting the design activity. Any improper specification turns out to be very
expensive adversely affects all subsequent phases of development.
„„ The requirements analysis and specification phase consists of two important
activities—requirements gathering and analysis, and requirements specification.
„„ The aim of requirements analysis is to clearly understand the exact user requirements
and to remove any inconsistencies, anomalies, and incompleteness in these
requirements.
„„ During the requirements specification activity, the requirements are systematically
organised into an SRS document.
„„ Formally specifying the requirements has many advantages. But, a major shortcoming
of the formal specification techniques is that they are hard to use. However, it
is possible that formal techniques will become more usable in future with the
development of suitable front-ends. We discussed the axiomatic and algebraic
techniques as example formal specification techniques to give an idea of some of
the issues involved in formal specification.

EXERCISES
MULTIPLE CHOICE QUESTIONS
For each of the following questions only one of the options is correct. Choose the correct
option:
1. Who among the following is a stakeholder in a software development project?
(a) A shareholder of the organisation developing the software
(b) Anyone who is interested in the software
(c) Anyone who is a source of requirements for the software
(d) Anyone who might be affected by the software

4
P
 rogramming languages are generally classified into four generations. The first generation (1GL)
programming languages consist of machine language programs. The second generation (2GL)
started when the assembly language was introduced. All procedural languages are classified as
3GLs. In procedural languages, in order to solve a problem, you would have to precisely write
down “how” the required result can be obtained. This requires writing the exact procedures or
the algorithmic steps that need to be followed to arrive at the result. In contrast, using a 4GL only
the “what” parts have to be specified.
 Requirements Analysis and Specification   211

2. A software requirements specification (SRS) document should avoid discussing which

one of the following:
(a) Functional requirements
(b) Non-functional requirements
(c) Design specification
(d) Constraints on the implementation
3. Which one of the following is not a goal of requirements analysis?
(a) Weed out ambiguities in the requirements
(b) Weed out inconsistencies in the requirements
(c) Weed out non-functional requirements
(d) Weed out incompleteness in the requirements
4. Consider the following requirement for a word processor software: “The software
should provide facility to import an existing image available as a jpeg file into the
document being created.” Which one of the following types of requirements is this?
(a) Functional requirement
(b) Non-functional requirement
(c) Constraint on the implementation
(d) Goal of implementation
5. Which one of the following assertions is FALSE about functional requirements?
(a) A functional requirement is also called a behavioral requirement
(b) A functional requirement may consist of several scenarios of operation
(c) A functional requirement is a statement of how a software product must map
program inputs to program outputs
(d) Some of the functional requirements specify the system performance
6. Consider the following partial description of the IIT security software. “A camera at
the main gate should detect an incoming vehicle, and the gate should be opened for
registered vehicles.” Which one of the following types of requirements is this?
(a) Functional requirement
(b) Non-functional requirement
(c) Design requirement
(d) Design constraint
7. Consider the following partial requirement for a software: “A web browser should be
used as the front end.” It can be considered to be which one of the following types
of requirements:
(a) Functional requirement
(b) Non-functional requirement
(c) Constraint
(d) External interface

TRUE OR FALSE
State whether the following statements are TRUE or FALSE. Give reasons for your answer.
1. Applications developed using 4GLs would normally be more efficient and run faster
compared to applications developed using 3GL.
212   Fundamentals of Software Engineering

2. A formal specification cannot be ambiguous.

3. A formal specification cannot be incomplete.
4. A formal specification cannot be inconsistent.
5. The system test plan can be prepared immediately after the completion of the
requirements specification phase.
6. The SRS document is a formal specification of a system.
7. User interface issues of a system are usually its functional requirements.
8. The SRS document is written using the customer’s terminology of various data and
procedures in the problem, rather than the development team’s terminology.
9. A precise specification cannot be incomplete.
10. If a requirement specification is precise, then it would automatically imply that it
is an unambiguous requirements specification.

REVIEW QUESTIONS
1. What is the difference between requirements analysis and specification? What are the
important activities that are carried out during requirements analysis and specification
phase? What is the final outcome of the requirements analysis and specification phase?
2. What are the goals of the requirements analysis and specification phase? How are
the requirements analysis and specification activities carried out and who carries out
these activities?
3. Discuss the important ways in which a good SRS document can be useful to various
stakeholders.
4. What is the difference between the functional and the non-functional requirements
of a system? Identify at least two functional requirements of a bank automated teller
machine (ATM) system. Also identify one non-functional requirement for an ATM
system.
5. What are the four types of non-functional requirements that have been suggested
by IEEE 830 standards document? Give one example of each of these categories of
requirements.
6. What do you understand by requirements gathering? Name and explain the different
requirements gathering techniques that are normally deployed by an analyst.
7. What are the different types of requirements problems that an analyst usually
anticipates and rectifies in the gathered requirements before starting to write the
SRS document? Give at least one example of each type of requirements problems.
8. Explain the likely consequences of starting a large project development effort without
accurately understanding and documenting the customer requirements.
9. Suppose you have been appointed as the analyst for a large software development
project. Discuss the aspects of the software product you would document in the
software requirements specification (SRS) document? What would be the organisation
of your SRS document? How would you validate your SRS document?
 Requirements Analysis and Specification   213

10. Make a checklist of various types of errors that might exist in an SRS document, so
that this checklist can be used to review an SRS document.
11. Write down the important users of the SRS document for a project, the specific ways
in which they use the document, and their specific expectations from the document,
if any.
12. What do you understand by the problems of over specification, forward reference,
and noise in an SRS document? Explain each of these with suitable examples.
13. What is the difference between functional and non-functional requirements? Give one
example of each type of requirement for a library automation software.
14. List five desirable characteristics of a good software requirements specification (SRS)
document.
15. Suppose you are trying to gather the requirements for a software that needs to be
developed to automate the book-keeping activities of a supermarket. Identify the
main tasks that you would undertake as the analyst to satisfactorily gather the
requirements.
16. How are the abstraction and decomposition principles used in the development of a
good software requirements specification?
17. Suppose the analyst of a large product development effort has prepared the SRS
document in the form of a narrative essay of the system to be developed. Based on
this document, the product development activity gets underway. Explain the problems
that such a requirements specification document may create while developing the
software.
18. Discuss the relative advantages of formal and informal requirements specifications.
19. Why is the SRS document also known as the black-box specification of a system?
20. Who are the different category of users of the SRS document? In what ways is the
SRS document useful to them?
21. Give an example of an inconsistent functional requirement. Explain why you think
that the requirement is inconsistent.
22. What do you understand by traceability in the context of software requirements
specification? How is traceability achieved? Identify at least two important benefits
of having traceability among development artifacts.
23. (a) What are the important differences between a model-oriented specification method
and a property-oriented specification method?
(b) Compare the relative advantages of property-oriented specification methods over
model-oriented specification methods.
(c) Name at least one representative popular property-oriented specification technique,
and one representative model-oriented specification technique.
24. Consider the following requirement for a software to be developed for controlling
a chemical plant. The chemical plant has a number of emergency conditions. When
any of the emergency conditions occurs, some prespecified actions should be taken.
The different emergency conditions and the corresponding actions that need to be
taken are as follows:
214   Fundamentals of Software Engineering

(a) If the temperature of the chemical plant exceeds T1°C, then the water shower
should be turned ON and the heater should be turned OFF.
(b) If the temperature of the chemical tank falls below T2°C, then the heater should
be turned ON and the water shower should be turned OFF.
(c) If the pressure of the chemical plant is above P1, then the valve v1 should be
OPENED.
(d) If the chemical concentration of the tank rises above M , and the temperature of
the tank is more than T3°C, then the water shower should be turned ON.
(e) If the pressure rises above P3 and the temperature rises above T1°C, then the
water shower should be turned ON, valves v1 and v2 are OPENED and the alarm
bells sounded.
Write the requirements of this chemical plant software in the form of a decision
table.
25. Draw a decision tree to represent the processing logic of the chemical plant controller
described in question 24.
26. Represent the decision making involved in the operation of the following wash-
machine by means of a decision table:
The machine waits for the start switch to be pressed. After the user presses the
start switch, the machine fills the wash tub with either hot or cold water depending
upon the setting of the HotWash switch. The water filling continues until the high
level is sensed. The machine starts the agitation motor and continues agitating the
wash tub until either the preset timer expires or the user presses the stop switch.
After the agitation stops, the machine waits for the user to press the startDrying
switch. After the user presses the   startDrying switch, the machine starts the hot air
blower and continues blowing hot air into the drying chamber until either the user
presses the stop switch or the preset timer expires.
27. Represent the processing logic of the following problem in the form of a decision
table: A Library Membership Automation System needs to support three functions:
add new-member, renew-membership, cancel-membership. If the user requests
for any function other than these three, then an error message is flashed. When
an add new-member request is made, a new member record is created and a bill
for the annual membership fee for the new member is generated. If a membership
renewal request is made, then the expiry date of the concerned membership record is
updated and a bill towards the annual membership fee is generated. If a membership
cancellation request is made, then the concerned membership record is deleted and
a cheque for the balance amount due to the member is printed.
28. What do you understand by pre- and post-conditions of a function? Write the pre-
and post-conditions to axiomatically specify the following functions:
(a) A function takes two floating point numbers representing the sides of a rectangle
as input and returns the area of the corresponding rectangle as output.
(b) A function accepts three integers in the range of –100 and +100 and determines
the largest of the three integers.
(c) A function takes an array of integers as input and finds the minimum value.
 Requirements Analysis and Specification   215

(d) A function named square-array creates a 10 element array where each all elements
of the array, the value of any array element is square of its index.
(e) A function sort takes an integer array as its argument and sorts the input array
in ascending order.
29. Using the algebraic specification method, formally specify a string supporting the
following operations:
„„ append: append a given string to another string
„„ add: add a character to a string
„„ create: create a new null string
„„ isequal: checks whether two strings are equal or not
„„ isempty: checks whether the string is null
30. Using the algebraic specification method, formally specify an array of generic type
elem. Assume that array supports the following operations:
„„ create: takes the array bounds as parameters and initializes the values of the array
to undefined.
„„ assign: creates a new array, where a particular element has been assigned a value.
„„ eval: reveals the value of a specified element.
„„ first: returns the first bound of the array.
„„ last: returns the last bound of the array.
31. What do you understand by an executable specification language? How is it different
from a traditional procedural programming language? Give an example of an
executable specification language.
32. What is a fourth generation programming technique? What are its advantages and
disadvantages vis-a-vis a third generation technique?
33. What are auxiliary functions in algebraic specifications? Why are these needed?
34. What do you understand by incremental development of algebraic specifications?
What is the advantage of incremental development of algebraic specifications?
35. (a) 
Algebraically specify an abstract data type that stores a set of elements and
supports the following operations. Assume that the ADT element has already
been specified and you can use it:
„„ new: creates a null set.
„„ add: takes a set and an element and returns the set with the additional elements
stored.
„„ size: takes a set as argument and returns the number of elements in the set.
„„ remove: takes a set and an element as its argument and returns the set with
the element removed.
„„ contains: takes a set and an element as its argument and returns the Boolean
value true if the element belongs to the set and returns false if the element
does not belong to the set.
„„ equals: takes two sets as arguments and returns true if they contain identical
elements and returns false otherwise.
216   Fundamentals of Software Engineering

(b) Using the specification you have developed for the ADT set, reduce the following
expression by applying the rewrite rules: equals (add(5, (add(6, new()), add(6,
(add(5, new()))). Show the details of every reduction.
36. Algebraically specify a data type Point, that supports the following operations:
create, xcoord, ycoord, move, movex, movey. The informal meanings of
these operations are the following—create takes two integers as its arguments and
creates an instance of point type that has the two integers as its x and y coordinate
values respectively, xcoord and ycoord return the x and y-coordinates of a given
point, move takes a point and two integer values as its argument and sets the x and
y-coordinates of point to the specified values, movex takes a point and an integer
value as its argument and sets the x-coordinate of the point to the given integer
value. Similarly, movey takes a point and an integer value and sets the y-coordinate
of point to the given integer value.
Reduce the following expression, clearly showing each step and mentioning the
reduction rule used.
xcoord(movex(create(20,100), ycoord(create(10,50)))
37. Write a formal algebraic specification of the sort symbol-table whose operations are
informally defined as follows:
„„ create: bring a symbol table into existence.
„„ enter: enter a symbol table and its type into the table.
„„ lookup: return the type associated with a name in the table.
„„ delete: remove a name, type pair from the table, given a name as a parameter.
„„ replace: replace the type associated with a given name with the type specified as
its parameter.
The enter operation fails if the name is already present in the table. The lookup,
delete, and replace operations fail if the name is not available in the table.
38. Algebraically specify the data type queue which supports the following operations:
„„ create: creates an empty queue.
„„ append: takes a queue and an item as its arguments and returns a queue with the
item added at the end of the queue.
„„ remove: takes a queue as its argument and returns a queue with the first element
of the original queue removed.
„„ inspect: takes a queue as its argument and returns the value of the first item in
the queue.
„„ isempty: takes a queue as its argument and returns true if the queue contains no
elements, and returns false if it contains one or more elements.
You can assume that the data type item has previously been specified and that you
can reuse this specification.
39. Define the finite termination and unique termination properties of algebraic
specifications. Why is it necessary for an algebraic specification to satisfy these
properties?
40. If the prototyping model is being used in a development effort, is it necessary to
develop a requirements specification document?
 Requirements Analysis and Specification   217

41. Express the decision making involved in the following withdraw cash function of a
bank ATM using a decision table.
To withdraw cash, first a valid customer identification is required. For this, the
customer is prompted to insert his ATM card in the card checking machine. If his
card is found to be invalid, the card is ejected out along with an appropriate message
displayed. If the card is verified to be a valid card, the customer is prompted to type
his password. If the password is invalid, an error message is shown and the customer
is prompted to enter his password again. If the customer enters incorrect password
consecutively for three times, then his card is seized and he is asked to contact the
bank manager. On the other hand, if the customer enters his password correctly,
then he is considered to have validly identified himself and is prompted to enter the
amount he needs to withdraw. If he enters an amount that is not a multiple of `100, he
is prompted to enter the amount again. After he enters an amount that is a multiple
of `100, the cash is dispensed if sufficient amount is available in his account and his
card is ejected; otherwise his card is ejected out without any cash being dispensed
along with a message display regarding insufficient fund position in his account.
42. Identify the functional and non-functional requirements in the following problem
description and document them.
A cosmopolitan clock software is to be developed that displays up to 6 clocks with the
names of the city and their local times. The clocks should be aesthetically designed.
The software should allow the user to change name of any city and change the time
readings of any clock by typing c (for configure) on any clock. The user should also be
able to toggle between a digital clock and an analog clock display by typing either d
(for digital) or a (for analog) on a clock display. After the stand-alone implementation
works, a web-version should be developed that can be downloaded on a browser as
an applet and run. The clock should use only the idle cycles on the computer it runs.
43. What do you understand by inconsistencies, anomalies, and incompletenesses in an
SRS document? Identify the inconsistencies, anomalies, and incompletenesses in the
following requirements of an academic activity automation software of an educational
institute:
“The semester performance of each student is computed as the average academic
performance for the semester. The guardians of all students having poor performance
record in the semester are mailed a letter informing about the poor performance of the
ward and intimating that repetition of poor performance in the subsequent semester
can lead to expulsion. The extracurricular activities of a student are also graded and
taken into consideration for determination of the semester performance.”
44. Identify any inconsistencies, anomalies, and incompleteness that are present in the
following requirements that were gathered by interviewing the clerks of the CSE
department for developing an academic automation software (AAS): “The CGPA of
each student is computed as the average performance for the semester. The parents
of all students having poor performance are mailed a letter informing about the poor
performance of their ward and with a request to convey a warning to the student
that the poor performance should not be repeated.”
218   Fundamentals of Software Engineering

45. Represent the decision making involved in the following functional requirement of
a library automation system: Issue Item: An item when submitted at the counter
along with the library identity card, first it is determined if the member has exceeded
his quota. If he has exceeded his quota, then no items can be issued to him. If the
requested item is a journal, then it is issued for two days only. If it is a book, then
it is checked whether it is a reference book. Reference books cannot be issued out. If
it is not a reference book, it is determined if anyone has reserved it. Reserved books
cannot be issued out. If the book issue request of the member meets all the mentioned
criteria, then the book is issued to the member for one month, appropriate entry is
made in the member’s account and an issue slip is printed.
46. Suppose you wish to develop a word processing software that would have features
similar to Microsoft Word. Develop the SRS document for this word processing
software.
47. Identify at least three important reasons as to why the customer requirements may
change after the requirements phase is complete and the SRS document has been
signed off.
48. Suppose you are entrusted with the work of gathering the requirements for the hostel
automation software that you have undertaken for an academic institute. Briefly
discuss how you would carry out the requirements gathering and analysis activities.
 Software Design   219

CHAPTER

5
SOFTWARE DESIGN

CHAPTER OUTLINE
®® Overview of the Design Process
®® How to Characterise a Good Software
Design?
®® Cohesion and Coupling
®® Layered Arrangement of Modules
®® Approaches to Software Design

Design can be simple. That’s why it’s so complicated.

—Paul Rand
220   Fundamentals of Software Engineering

D
uring the software design phase, the design document
LEARNING OBJECTIVES is produced, based on the customer requirements as
®® High-level versus detailed documented in the SRS document.
design This view of a design
®® Characteristics of a good process has been shown The activities carried out
design schematically in Figure 5.1. As during the design phase (called
®® Determination of the levels shown in Figure 5.1, the design as design process) transform the
of cohesion and coupling process starts using the SRS SRS document into the design
of a module document and completes with document.
®® Procedural versus object- the production of the design
oriented design document. The design document produced at the end of the
design phase should be implementable using a programming
language in the subsequent (coding) phase.

FIGURE 5.1 The design process.

5.1 OVERVIEW OF THE DESIGN PROCESS

The design process essentially transforms the SRS document into
a design document. In the following sections and subsections,
we will discuss a few important issues associated with the
design process.

5.1.1 Outcome of the Design Process

The following items are designed and documented during the
design phase.
Different modules required: The different modules in the
solution should be identified. Each module is a collection
of functions and the data shared by these functions. Each
module should accomplish some well-defined task out of the
overall responsibility of the software. Each module should be
named according to the task it performs. For example, in an
academic automation software, the module consisting of the
functions and data necessary to accomplish the task of
registration of the students should be named handle student
registration.
 Software Design   221

Control relationships among modules: A control relationship between two modules

essentially arises due to function calls across the two modules. The control relationships
existing among various modules should be identified in the design document.
Interfaces among diffrent modules: The interfaces between two modules identifies the
exact data items that are exchanged between the two modules when one module invokes
a function of the other module.
Data structures of the individual modules: Each module normally stores some data that
the functions of the module need to share to accomplish the overall responsibility of the
module. Suitable data structures for storing and managing the data of a module need to
be properly designed and documented.
Algorithms required to implement the individual modules: Each function in a module
usually performs some processing activity. The algorithms required to accomplish the
processing activities of various modules need to be carefully designed and documented
with due considerations given to the accuracy of the results, space and time complexities.
Starting with the SRS document (as shown in Figure 5.1), the design documents are
produced through iterations over a series of steps that we are going to discuss in this
chapter and the subsequent three chapters. The design documents are reviewed by the
members of the development team to ensure that the design solution conforms to the
requirements specification.

5.1.2 Classification of Design Activities

A good software design is seldom realised by using a single step procedure, rather it
requires iterating over a series of steps called the design activities. Let us first classify the
design activities before discussing them in detail. Depending on the order in which various
design activities are performed, we can broadly classify them into two important stages.
„„ Preliminary (or high-level) design, and
„„ Detailed design.
The meaning and scope of these two stages can vary Through high-level design,
considerably from one design methodology to another. a problem is decomposed
However, for the traditional function-oriented design into a set of modules. The
approach, it is possible to define the objectives of the control relationships among
high-level design as follows: the modules are identified,
The outcome of high-level design is called the program and also the interfaces among
structure or the software architecture. High-level design is a various modules are identified.
crucial step in the overall design of a software. When the
high-level design is complete, the problem should have been decomposed into many small
functionally independent modules that are cohesive, have low coupling among themselves,
and are arranged in a hierarchy. Many different types of notations have been used to
represent a high-level design. A notation that is widely being used for procedural
development is a tree-like diagram called the structure chart. Another popular design
representation techniques called UML that is being used to document object-oriented
design, involves developing several types of diagrams to document the object-oriented
design of a systems. Though other notations such as Jackson diagram [1975] or
222   Fundamentals of Software Engineering

Warnier-Orr [1977, 1981] diagram are available to document a software design, we confine
our attention in this text to structure charts and UML diagrams only.
Once the high-level design is complete, detailed design
is undertaken. During detailed design each
The outcome of the detailed design stage is usually module is examined carefully
documented in the form of a module specification (MSPEC) to design its data structures
document. After the high-level design is complete, the and the algorithms.
problem would have been decomposed into small modules,
and the data structures and algorithms to be used described using MSPEC and can be easily
grasped by programmers for initiating coding. In this text, we do not discuss MSPECs and
confine our attention to high-level design only.

5.1.3 Classification of Design Methodologies

The design activities vary considerably based on the specific design methodology being
used. A large number of software design methodologies are available. We can roughly
classify these methodologies into procedural and object-oriented approaches. These two
approaches are two fundamentally different design paradigms. In this chapter, we shall
discuss the important characteristics of these two fundamental design approaches. Over
the next three chapters, we shall study these two approaches in detail.

Do design techniques result in unique solutions?

Even while using the same design methodology, different designers usually arrive at very
different design solutions. The reason is that a design technique often requires the designer
to make many subjective decisions and work out compromises to contradictory objectives.
As a result, it is possible that even the same designer can work out many different solutions
to the same problem. Therefore, obtaining a good design would involve trying out several
alternatives (or candidate solutions) and picking out the best one. However, a fundamental
question that arises at this point is—how to distinguish superior design solution from an
inferior one? Unless we know what a good software design is and how to distinguish
a superior design solution from an inferior one, we can not possibly design one. We
investigate this issue in the next section.
The goal of any analysis
Analysis versus design technique is to elaborate
Analysis and design activities differ in goal and scope. the customer requirements
The analysis results are generic and does not consider through careful thinking and
implementation or the issues associated with specific at the same time consciously
platforms. The analysis model is usually documented using avoiding making any decisions
some graphical formalism. In case of the function-oriented regarding the exact way the
approach that we are going to discuss, the analysis model system is to be implemented.
would be documented using data flow diagrams (DFDs),
whereas the design would be documented using structure chart. On the other hand, for
object-oriented approach, both the design model and the analysis model will be documented
using unified modelling language (UML). The analysis model would normally be very difficult
to implement using a programming language.
 Software Design   223

The design model is obtained from the analysis model through transformations over a
series of steps. In contrast to the analysis model, the design model reflects several decisions
taken regarding the exact way system is to be implemented. The design model should be
detailed enough to be easily implementable using a programming language.

5.2 HOW TO CHARACTERISE A GOOD SOFTWARE DESIGN?

Coming up with an accurate characterisation of a good software design that would
hold across diverse problem domains is certainly not easy. In fact, the definition of a
“good” software design can vary depending on the exact application being designed. For
example, “memory size used up by a program” may be an important way to characterize
a good solution for embedded software development—since embedded applications
are often required to work under severely limited memory sizes due to cost, space, or
power consumption considerations. For embedded applications, factors such as design
comprehensibility may take a back seat while judging the goodness of design. Thus
for embedded applications, one may sacrifice design comprehensibility to achieve code
compactness. Similarly, it is not usually true that a criterion that is crucial for some
application, needs to be almost completely ignored for another application. It is therefore
clear that the criteria used to judge a design solution can vary widely across different
types of applications. Not only do the criteria used to judge a design solution depend on
the exact application being designed, but to make the matter worse, there is no general
agreement among software engineers and researchers on the exact criteria to use for
judging a design even for a specific category of application. However, most researchers
and software engineers agree on a few desirable characteristics that every good software
design for general applications must possess. These characteristics are listed below:
Correctness: A good design should first of all be correct. That is, it should correctly
implement all the functionalities of the system.
Understandability: A good design should be easily understandable. Unless a design
solution is easily understandable, it would be difficult to implement and maintain it.
Efficiency: A good design solution should adequately address resource, time, and cost
optimisation issues.
Maintainability: A good design should be easy to change. This is an important requirement,
since change requests usually keep coming from the customer even after product release.

5.2.1 Understandability of a Design: A Major Concern

While performing the design of a certain problem, assume
that we have arrived at a large number of design solutions Given that we are choosing
and need to choose the best one. Obviously all incorrect from only correct design
designs have to be discarded first. Out of the correct design solutions, understandability of
solutions, how can we identify the best one? a design solution is possibly
Recollect from our discussions in Chapter 1 that a the most important issue to
good design should help overcome the human cognitive be considered while judging
limitations that arise due to limited short-term memory. A the goodness of a design.
large problem overwhelms the human mind, and a poor
224   Fundamentals of Software Engineering

design would make the matter worse. Unless a design solution is easily understandable,
it could lead to an implementation having a large number of defects and at the same time
tremendously pushing up the development costs. Therefore, a good design solution should
be simple and easily understandable. A design that is easy to understand is also easy to
develop and maintain. A complex design would lead to severely increased life cycle costs.
Unless a design is easily understandable, it would require tremendous effort to implement,
test, debug, and maintain it. We had already pointed out in Chapter 2 that about 60 per
cent of the total effort in the life cycle of a typical product is spent on maintenance. If the
software is not easy to understand, not only would it lead to increased development costs,
the effort required to maintain the product would also increase manifold. Besides, a design
solution that is difficult to understand would lead to a program that is full of bugs and is
unreliable. Recollect that we had already discussed in Chapter 1 that understandability of a
design solution can be enhanced through clever applications of the principles of abstraction
and decomposition.

An understandable design is modular and layered

How can the understandability of two different designs be compared, so that we can pick
the better one? To be able to compare the understandability of two design solutions, we
should at least have an understanding of the general features that an easily understandable
design should possess. A design solution should have the following characteristics to be
easily understandable:
„„ It should assign consistent and meaningful names to various design components.
„„ It should make use of the principles of decomposition and abstraction in good
measures to simplify the design.
We had discussed the essential concepts behind the principles of abstraction and
decomposition principles in Chapter 1. But, how can the abstraction and decomposition
principles are used in arriving at a design solution? These two principles are exploited by
design methodologies to make a design modular and layered. (Though there are also a
few other forms in which the abstraction and decomposition principles can be used in the
design solution, we discuss those later). We can now define the characteristics of an easily
understandable design as follows: A design solution is understandable, if it is modular and
the modules are arranged in distinct layers.
We now elaborate the concepts of modularity and A design solution should be
layering of modules: modular and layered to be
understandable.
Modularity
A modular design is an effective decomposition of a problem. It is a basic characteristic
of any good design solution. A modular design, in simple words, implies that the problem
has been decomposed into a set of modules that have only limited interactions with each
other. Decomposition of a problem into modules facilitates taking advantage of the divide
and conquer principle. If different modules have either no interactions or little interactions
with each other, then each module can be understood separately. This reduces the perceived
complexity of the design solution greatly. To understand why this is so, remember that it
may be very difficult to break a bunch of sticks which have been tied together, but very
easy to break the sticks individually.
 Software Design   225

It is not difficult to argue that modularity is an important characteristic of a good

design solution. But, even with this, how can we compare the modularity of two alternate
design solutions? From an inspection of the module structure, it is at least possible to
intuitively form an idea as to which design is more modular. For example, consider two
alternate design solutions to a problem that are represented in Figure 5.2, in which the
modules M1, M2, etc. have been drawn as rectangles. The invocation of a module by another
module has been shown as an arrow. It can easily be seen
that the design solution of Figure 5.2(a) would be easier A design solution is said to be
to understand since the interactions among the different highly modular, if the different
modules is low. But, can we quantitatively measure the modules in the solution have
modularity of a design solution? Unless we are able to high cohesion and their inter-
quantitatively measure the modularity of a design solution, module couplings are low.
it will be hard to say which design solution is more
modular than another. Unfortunately, there are no quantitative metrics available yet to
directly measure the modularity of a design. However, we can quantitatively characterise
the modularity of a design solution based on the cohesion and coupling existing in the
design.
A software design with high cohesion and low coupling among modules is the effective
problem decomposition we discussed in Chapter 1. Such a design would lead to increased
productivity during program development by bringing down the perceived problem
complexity.

FIGURE 5.2 Two design solutions to the same problem.

Based on this classification, we would be able to easily judge the cohesion and coupling
existing in a design solution. From a knowledge of the cohesion and coupling in a design,
we can form our own opinion about the modularity of the design solution. We shall define
the concepts of cohesion and coupling and the various classes of cohesion and coupling
in Section 5.3. Let us now discuss the other important characteristic of a good design
solution—layered design.
226   Fundamentals of Software Engineering

Layered design
A layered design is one in which when the call relations among different modules are
represented graphically, it would result in a tree-like diagram with clear layering. In a
layered design solution, the modules are arranged in a hierarchy of layers. A module can
only invoke functions of the modules in the layer immediately below it. The higher layer
modules can be considered to be similar to managers that
invoke (order) the lower layer modules to get certain tasks
A layered design can make
done. A layered design can be considered to be implementing
the design solution easily
control abstraction, since a module at a lower layer is
understandable, since to
unaware of (about how to call) the higher layer modules.
understand the working of a
When a failure is detected while executing a module,
module, one would at best
it is obvious that the modules below it can possibly be the
have to understand how
source of the error. This greatly simplifies debugging since
the immediately lower layer
one would need to concentrate only on a few modules
modules work without having
to detect the error. We shall elaborate these concepts
to worry about the functioning
governing layered design of modules in Section 5.4.
of the upper layer modules.

5.3 COHESION AND COUPLING

We have so far discussed that effective problem decomposition is an important characteristic
of a good design. Good module decomposition is indicated through high cohesion of the
individual modules and low coupling of the modules with
each other. Let us now define what is meant by cohesion Cohesion is a measure of the
and coupling. functional strength of a module,
In this section, we first elaborate the concepts of whereas the coupling between
cohesion and coupling. Subsequently, we discuss the two modules is a measure of
classification of cohesion and coupling. the degree of interaction (or
interdependence) between the
Coupling: Intuitively, we can think of coupling as follows.
two modules.
Two modules are said to be highly coupled, if either of the
following two situations arise:
„„ If the function calls between two modules involve passing large chunks of shared
data, the modules are tightly coupled.
„„ If the interactions occur through some shared data, then also we say that they are
highly coupled.
If two modules either do not interact with each other at all or at best interact by passing
no data or only a few primitive data items, they are said to have low coupling.
Cohesion: To understand cohesion, let us first understand an analogy. Suppose you
listened to a talk by some speaker. You would call the speech to be cohesive, if all the
sentences of the speech played some role in giving the talk a single and focused theme.
Now, we can extend this to a module in a design solution. When the functions of the
module co-operate with each other for performing a single objective, then the module has
good cohesion. If the functions of the module do very different things and do not co-operate
with each other to perform a single piece of work, then the module has very poor cohesion.
 Software Design   227

Functional independence
By the term functional independence, we mean that a module performs a single task and
needs very little interaction with other modules.
Functional independence is a key to any good design
A module that is highly cohesive
primarily due to the following advantages it offers:
and also has low coupling with
Error isolation: Whenever an error exists in a module, other modules is said to be
functional independence reduces the chances of the error functionally independent of the
propagating to the other modules. The reason behind this is other modules.
that if a module is functionally independent, its interaction
with other modules is low. Therefore, an error existing in the module is very unlikely to
affect the functioning of other modules.
Further, once a failure is detected, error isolation makes it very easy to locate the
error. On the other hand, when a module is not functionally independent, once a failure
is detected in a functionality provided by the module, the error can be potentially in any
of the large number of modules and propagated to the functioning of the module.
Scope of reuse: Reuse of a module for the development of other applications becomes
easier. The reasons for this is as follows. A functionally independent module performs some
well-defined and precise task and the interfaces of the module with other modules are
very few and simple. A functionally independent module can therefore be easily taken out
and reused in a different program. On the other hand, if a module interacts with several
other modules or the functions of a module perform very different tasks, then it would be
difficult to reuse it. This is especially so, if the module accesses the data (or code) internal
to other modules.
Understandability: When modules are functionally independent, complexity of the design
is greatly reduced. This is because of the fact that different modules can be understood in
isolation, since the modules are independent of each other. We have already pointed out
in Section 5.2 that understandability is a major advantage of a modular design. Besides the
three we have listed here, there are many other advantages of a modular design as well.
We shall not list those here, and leave it as an assignment to the reader to identify them.

5.3.1 Classification of Cohesiveness

Cohesiveness of a module is the degree to which the different functions of the module
co-operate to work towards a single objective. The different modules of a design can possess
different degrees of freedom. However, the different classes of cohesion that modules
can possess are depicted in Figure 5.3. The cohesiveness increases from coincidental to
functional cohesion. That is, coincidental is the worst type of cohesion and functional is
the best cohesion possible. These different classes of cohesion are elaborated below.

FIGURE 5.3 Classification of cohesion.

228   Fundamentals of Software Engineering

Coincidental cohesion: A module is said to have coincidental cohesion, if it performs

a set of tasks that relate to each other very loosely, if at all. In this case, we can say that
the module contains a random collection of functions. It is likely that the functions have
been placed in the module out of pure coincidence rather than through some thought or
design. The designs made by novice programmers often possess this category of cohesion,
since they often bundle functions to modules rather arbitrarily. An example of a module
with coincidental cohesion has been shown in Figure 5.4(a). Observe that the different
functions of the module carry out very different and unrelated activities starting from
issuing of library books to creating library member records on one hand, and handling
librarian leave request on the other.

FIGURE 5.4 Examples of cohesion.

Logical cohesion: A module is said to be logically cohesive, if all elements of the module
perform similar operations, such as error handling, data input, data output, etc. As an
example of logical cohesion, consider a module that contains a set of print functions to
generate various types of output reports such as grade sheets, salary slips, annual reports,
etc.
Temporal cohesion: When a module contains functions that are related by the fact that
these functions are executed in the same time span, then the module is said to possess
temporal cohesion. As an example, consider the following situation. When a computer is
booted, several functions need to be performed. These include initialisation of memory and
devices, loading the operating system, etc. When a single module performs all these tasks,
then the module can be said to exhibit temporal cohesion. Other examples of modules
having temporal cohesion are the following. Similarly, a module would exhibit temporal
cohesion, if it comprises functions for performing initialisation, or start-up, or shut-down
of some process.
Procedural cohesion: A module is said to possess procedural cohesion, if the set of
functions of the module are executed one after the other, though these functions may
work towards entirely different purposes and operate on very different data. Consider
the activities associated with order processing in a trading house. The functions login(),
place-order(), check-order(), print-bill(), place-order-on-vendor(), update-
inventory(), and logout() all do different thing and operate on different data. However,
 Software Design   229

they are normally executed one after the other during typical order processing by a sales
clerk.
Communicational cohesion: A module is said to have communicational cohesion, if all
functions of the module refer to or update the same data structure. As an example of
procedural cohesion, consider a module named student in which the different functions
in the module such as admitStudent, enterMarks, printGradeSheet, etc. access and
manipulate data stored in an array named studentRecords defined within the module.
Sequential cohesion: A module is said to possess sequential cohesion, if the different
functions of the module execute in a sequence, and the output from one function is input
to the next in the sequence. As an example consider the following situation. In an on-line
store consider that after a customer requests for some item, it is first determined if the item
is in stock. In this case, if the functions create-order(), check-item-availability(),
place-order-on-vendor() are placed in a single module, then the module would exhibit
sequential cohesion. Observe that the function create-order() creates an order that is
processed by the function check-item-availability() (whether the items are available
in the required quantities in the inventory) is input to place-order-on-vendor().
Functional cohesion: A module is said to possess functional cohesion, if different functions
of the module co-operate to complete a single task. For example, a module containing all
the functions required to manage employees’ pay-roll displays functional cohesion. In this
case, all the functions of the module (e.g., computeOvertime(), computeWorkHours(),
computeDeductions(), etc.) work together to generate the payslips of the employees.
Another example of a module possessing functional cohesion has been shown in
Figure 5.4(b). In this example, the functions issue-book(), return-book(), query-book(),
and find-borrower(), together manage all activities concerned with book lending. When a
module possesses functional cohesion, then we should be able to describe what the module
does using only one simple sentence. For example, for the module of Figure 5.4(a), we can
describe the overall responsibility of the module by saying “It manages the book lending
procedure of the library.”
A simple way to determine the cohesiveness of any given module is as follows. First
examine what do the functions of the module perform. Then, try to write down a sentence
to describe the overall work performed by the module. If you need a compound sentence
to describe the functionality of the module, then it has sequential or communicational
cohesion. If you need words such as “first”, “next”, “after”, “then”, etc., then it possesses
sequential or temporal cohesion. If it needs words such as “initialise”, “setup”, “shut
down”, etc., to define its functionality, then it has temporal cohesion.
We can now make the following observation. A cohesive module is one in which the
functions interact among themselves heavily to achieve a single goal. As a result, if any
of these functions is removed to a different module, the coupling would increase as the
functions would now interact across two different modules.

5.3.2 Classification of Coupling The degree of coupling

The coupling between two modules indicates the degree of between two modules depends
interdependence between them. Intuitively, if two modules on their interface complexity.
230   Fundamentals of Software Engineering

interchange large amounts of data, then they are highly interdependent or coupled. We
can alternately state this concept as follows.
The interface complexity is determined based on the number of parameters and the
complexity of the parameters that are interchanged while one module invokes the functions
of the other module.
Let us now classify the different types of coupling that can exist between two modules.
Between any two interacting modules, any of the following five different types of coupling
can exist. These different types of coupling, in increasing order of their severities have also
been shown in Figure 5.5.

FIGURE 5.5 Classification of coupling.

Data coupling: Two modules are data coupled, if they communicate using an elementary
data item that is passed as a parameter between the two, e.g. an integer, a float, a character,
etc. This data item should be problem related and not used for control purposes.
Stamp coupling: Two modules are stamp coupled, if they communicate using a composite
data item such as a record in PASCAL or a structure in C.
Control coupling: Control coupling exists between two modules, if data from one module
is used to direct the order of instruction execution in another. An example of control
coupling is a flag set in one module and tested in another module.
Common coupling: Two modules are common coupled, if they share some global data
items.
Content coupling: Content coupling exists between two modules, if they share code. That
is, a jump from one module into the code of another module can occur. Modern high-level
programming languages such as C do not support such jumps across modules.
The different types of coupling are shown schematically in Figure 5.5. The degree
of coupling increases from data coupling to content coupling. High coupling among
modules not only makes a design solution difficult to understand and maintain, but it
also increases development effort and also makes it very difficult to get these modules
developed independently by different team members.

5.4 LAYERED ARRANGEMENT OF MODULES

The control hierarchy represents the organisation of program components in terms of their
call relationships. Thus we can say that the control hierarchy of a design is determined
by the order in which different modules call each other. Many different types of notations
have been used to represent the control hierarchy. The most common notation is a tree-
like diagram known as a structure chart which we shall study in some detail in Chapter 6.
 Software Design   231

However, other notations such as Warnier-Orr [1977, 1981] or Jackson diagrams [1975] may
also be used. Since, Warnier-Orr and Jackson’s notations are not widely used nowadays,
we shall discuss only structure charts in this text.
In a layered design solution, the modules are arranged into several layers based on
their call relationships. A module is allowed to call only
the modules that are at a lower layer. That is, a module An important characteristic
should not call a module that is either at a higher layer or feature of a good design
even in the same layer. Figure 5.6(a) shows a layered solution is layering of the
design, whereas Figure 5.6(b) shows a design that is not modules. A layered design
layered. Observe that the design solution shown in achieves control abstraction
Figure 5.6(b), is actually not layered since all the modules and is easier to understand
can be considered to be in the same layer. In the following, and debug.
we state the significance of a layered design and
subsequently we explain it.
In a layered design, the top-most module in the hierarchy can be considered as
a manager that only invokes the services of the lower level module to discharge its
responsibility. The modules at the intermediate layers offer services to their higher layer by
invoking the services of the lower layer modules and also by doing some work themselves
to a limited extent. The modules at the lowest layer are the worker modules. These do not
invoke services of any module and entirely carry out their responsibilities by themselves.
Understanding a layered design is easier since to understand one module, one would
have to at best consider the modules at the lower layers (that is, the modules whose
services it invokes). Besides, in a layered design errors are isolated, since an error in one
module can affect only the higher layer modules. As a result, in case of any failure of
a module, only the modules at the lower levels need to be investigated for the possible
error. Thus, debugging time reduces significantly in a layered design. On the other hand,
if the different modules call each other arbitrarily, then this situation would correspond
to modules arranged in a single layer. Locating an error would be both difficult and time
consuming. This is because, once a failure is observed, the cause of failure (i.e. error) can
potentially be in any module, and all modules would have to be investigated for the error.
In the following, we discuss some important concepts and terminologies associated with
a layered design:
Superordinate and subordinate modules: In a control hierarchy, a module that controls
another module is said to be superordinate to it. Conversely, a module controlled by another
module is said to be subordinate to the controller.
Visibility: A module B is said to be visible to another module A, if A directly calls B.
Thus, only the immediately lower layer modules are said to be visible to a module.
Control abstraction: In a layered design, a module should only invoke the functions of
the modules that are in the layer immediately below it. In other words, the modules at the
higher layers, should not be visible (that is, abstracted out) to the modules at the lower
layers. This is referred to as control abstraction.
Depth and width: Depth and width of a control hierarchy provide an indication of
the number of layers and the overall span of control respectively. For the design of
Figure 5.6(a), the depth is 3 and width is also 3.
232   Fundamentals of Software Engineering

Fan-out: Fan-out is a measure of the number of modules that are directly controlled by
a given module. In Figure 5.6(a), the fan-out of the module M1 is 3. A design in which
the modules have very high fan-out numbers is not a good design. The reason for this is
that a very high fan-out is an indication that the module lacks cohesion. A module having
a large fan-out (greater than 7) is likely to implement several different functions and not
just a single cohesive function.
Fan-in: Fan-in indicates the number of modules that directly invoke a given module. High
fan-in represents code reuse and is in general, desirable in a good design. In Figure 5.6(a),
the fan-in of the module M1 is 0, that of M2 is 1, and that of M5 is 2.

FIGURE 5.6 Examples of good and poor control abstraction.

5.5 APPROACHES TO SOFTWARE DESIGN

There are two fundamentally different approaches to software design that are in use
today—function-oriented design, and object-oriented design. Though these two design
approaches are radically different, they are complementary rather than competing
techniques. The object-oriented approach is a relatively newer technology and is still
evolving. For development of large programs, the object-oriented approach is becoming
increasingly popular due to certain advantages that it offers. On the other hand, function-
oriented designing is a mature technology and has a large following. Salient features of
these two approaches are discussed in subsections 5.5.1 and 5.5.2 respectively.

5.5.1 Function-oriented Design

The following are the salient features of the function- In top-down decomposition,
oriented design approach: starting at a high-level view
Top-down decomposition: A system, to start with, is of the system, each high-level
viewed as a black box that provides certain services (also function is successively refined
known as high-level functions) to the users of the system. into more detailed functions.
 Software Design   233

For example, consider a function create-new-library member which essentially creates

the record for a new member, assigns a unique membership number to him, and prints
a bill towards his membership charge. This high-level function may be refined into the
following subfunctions:
„„ assign-membership-number
„„ create-member-record
„„ print-bill

Each of these subfunctions may be split into more detailed subfunctions and so on.
Centralised system state: The system state can be defined as the values of certain data
items that determine the response of the system to a user action or external event. For
example, the set of books (i.e. whether borrowed by
different users or available for issue) determines the state The system state is centralised
of a library automation system. Such data in procedural and shared among different
programs usually have global scope and are shared by functions.
many modules.
For example, in the library management system, several functions such as the following
share data such as member-records for reference and updation:
„„ create-new-member
„„ delete-member
„„ update-member-record

A large number of function-oriented design approaches have been proposed in the

past. A few of the well-established function-oriented design approaches are as following:
„„ Structured design by Constantine and Yourdon [1979]
„„ Jackson’s structured design by Jackson [1975]
„„ Warnier-Orr methodology [1977, 1981]
„„ Step-wise refinement by Wirth [1971]
„„ Hatley and Pirbhai’s Methodology [1987]

5.5.2 Object-oriented Design

In the object-oriented design (OOD) approach, a system is viewed as being made up of a
collection of objects (i.e., entities). Each object is associated with a set of functions that are
called its methods. Each object contains its own data and is responsible for managing it. The
data internal to an object cannot be accessed directly by other objects and only through
invocation of the methods of the object. The system state is decentralised since there is
no globally shared data in the system and data is stored in each object. For example, in a
library automation software, each library member may be a separate object with its own
data and functions to operate on the stored data. The methods defined for one object cannot
directly refer to or change the data of other objects.
The object-oriented design paradigm makes extensive use of the principles of abstraction
and decomposition as explained below. Objects decompose a system into functionally
independent modules. Objects can also be considered as instances of abstract data types
(ADTs). The ADT concept did not originate from the object-oriented approach. In fact, ADT
concept was extensively used in the ADA programming language introduced in the 1970s.
ADT is an important concept that forms an important pillar of object-orientation. Let us
234   Fundamentals of Software Engineering

now discuss the important concepts behind an ADT. There are, in fact, three important
concepts associated with an ADT—data abstraction, data structure, data type. We discuss
these in the following subsection:
Data abstraction: The principle of data abstraction implies that how data is exactly stored
is abstracted away. This means that any entity external to the object (that is, an instance
of an ADT) would have no knowledge about how data is exactly stored, organised, and
manipulated inside the object. The entities external to the object can access the data internal
to an object only by calling certain well-defined methods supported by the object. Consider
an ADT such as a stack. The data of a stack object may internally be stored in an array, a
linearly linked list, or a bidirectional linked list. The external entities have no knowledge
of this and can access data of a stack object only through the supported operations such
as push and pop.
Data structure: A data structure is constructed from a collection of primitive data items.
Just as a civil engineer builds a large civil engineering structure using primitive building
materials such as bricks, iron rods, and cement; a programmer can construct a data
structure as an organised collection of primitive data items such as integer, floating point
numbers, characters, etc.
Data type: A type is a programming language terminology that refers to anything that
can be instantiated. For example, int, float, char, etc., are the basic data types supported
by C programming language. Thus, we can say that ADTs are user defined data types.
In object-orientation, classes are ADTs. But, what is the advantage of developing an
application using ADTs? Let us examine the three main advantages of using ADTs in
programs:
„„ The data of objects are encapsulated within the methods. The encapsulation principle
is also known as data hiding. The encapsulation principle requires that data can be
accessed and manipulated only through the methods supported by the object and
not directly. This localises the errors. The reason for this is as follows. No program
element is allowed to change a data, except through invocation of one of the methods.
So, any error can easily be traced to the code segment changing the value. That is,
the method that changes a data item, making it erroneous can be easily identified.
„„ An ADT-based design displays high cohesion and low coupling. Therefore, object-
oriented designs are highly modular.
„„ Since the principle of abstraction is used, it makes the design solution easily
understandable and helps to manage complexity.
Similar objects constitute a class. In other words, each object is a member of some
class. Classes may inherit features from a super class. Conceptually, objects communicate
by message passing. Objects have their own internal data. Thus an object may exist in
different states depending the values of the internal data. In different states, an object may
behave differently. We shall elaborate these concepts in Chapter 7 and subsequently we
discuss an object-oriented design methodology in Chapter 8.

Object-oriented versus function-oriented design approaches

The following are some of the important differences between the function-oriented and
object-oriented design:
 Software Design   235

„„ Unlike function-oriented design methods in OOD, the basic abstraction is not the
services available to the users of the system such as issue-book, display-book-
details, find-issued-books, etc., but real-world entities such as member, book,
book-register, etc. For example in OOD, an employee pay-roll software is not
developed by designing functions such as update-employee-record, get-employee-
address, etc., but by designing objects such as employees, departments, etc.
„„ In OOD, state information exists in the form of data distributed among several
objects of the system. In contrast, in a procedural design, the state information
is available in a centralised shared data store. For example, while developing an
employee pay-roll system, the employee data such as the names of the employees,
their code numbers, basic salaries, etc., are usually implemented as global data in a
traditional programming system; whereas in an object-oriented design, these data are
distributed among different employee objects of the system. Objects communicate by
message passing. Therefore, one object may discover the state information of another
object by sending a message to it. Of course, somewhere or other the real-world
functions must be implemented.
„„ Function-oriented techniques group functions together if, as a group, they constitute
a higher level function. On the other hand, object-oriented techniques group functions
together on the basis of the data they operate on.
To illustrate the differences between the object-oriented and the function-oriented
design approaches, let us consider an example—that of an automated fire-alarm system
for a large building.

Automated fire-alarm system—customer requirements

The owner of a large multi-storied building wants to have a computerised fire alarm system
designed, developed, and installed in his building. Smoke detectors and fire alarms would
be placed in each room of the building. The fire alarm system would monitor the status of
these smoke detectors. Whenever a fire condition is reported by any of the smoke detectors,
the fire alarm system should determine the location at which the fire has been sensed and
then sound the alarms only in the neighbouring locations. The fire alarm system should
also flash an alarm message on the computer console. Fire fighting personnel would man
the console round the clock. After a fire condition has been successfully handled, the fire
alarm system should support resetting the alarms by the fire fighting personnel.
Function-oriented approach: In this approach, the different high-level functions are first
identified, and then the data structures are designed.
/* Global data (system state) accessible by various functions */
BOOL detector_status[MAX_ROOMS];
int detector_locs[MAX_ROOMS];
BOOL alarm-status[MAX_ROOMS]; /* alarm activated when status is set */
int alarm_locs[MAX_ROOMS]; /* room number where alarm is located */
int neighbour-alarms[MAX-ROOMS][10]; /* each detector has at most */
/* 10 neighbouring alarm locations */
int sprinkler[MAX_ROOMS];

The functions which operate on the system state are:

interrogate_detectors();
get_detector_location();
236   Fundamentals of Software Engineering
determine_neighbour_alarm();
determine_neighbour_sprinkler();
ring_alarm();
activate_sprinkler();
reset_alarm();
reset_sprinkler();
report_fire_location();

Object-oriented approach: In the object-oriented approach, the different classes of objects

are identified. Subsequently, the methods and data for each object are identified. Finally,
an appropriate number of instances of each class is created.
class detector
attributes: status, location, neighbours
operations: create, sense-status, get-location, find-neighbours
class alarm
attributes: location, status
operations: create, ring-alarm, get_location, reset-alarm
class sprinkler
attributes: location, status
operations: create, activate-sprinkler, get_location, reset-sprinkler

We can now compare the function-oriented and the object-oriented approaches based on
the two examples discussed above, and easily observe the following main differences:
„„ In a function-oriented program, the system state (data) is centralised and several
functions access and modify this central data. In case of an object-oriented program,
the state information (data) is distributed among various objects.
„„ In the object-oriented design, data is private in different objects and these are not
available to the other objects for direct access and modification.
„„ The basic unit of designing an object-oriented program is objects, whereas it is
functions and modules in procedural designing. Objects appear as nouns in the
problem description; whereas functions appear as verbs.
At this point, we must emphasise that it is not necessary that an object-oriented design
be implemented by using an object-oriented language only. However, an object-oriented
language such as C++ and Java support the definition of all the basic mechanisms of class,
inheritance, objects, methods, etc. and also support all key object-oriented concepts that
we have just discussed. Thus, an object-oriented language facilitates the implementation of
an OOD. However, an OOD can as well be implemented using a conventional procedural
languages—though it may require more effort to implement an OOD using a procedural
language as compared to the effort required for implementing the same design using an
object-oriented language. In fact, the older C++ compilers were essentially pre-processors
that translated C++ code into C code.
Even though object-oriented and function-oriented techniques are remarkably different
approaches to software design, yet one does not replace the other; but they complement
each other in some sense. For example, usually one applies the top-down function oriented
techniques to design the internal methods of a class, once the classes are identified. In this
case, though outwardly the system appears to have been developed in an object-oriented
fashion, but inside each class there may be a small hierarchy of functions designed in a
top-down manner.
 Software Design   237

SUMMARY
„„ A software design is typically carried out through two stages—high-level design,
and detailed design. During high-level design, the important components (modules)
of the system and their interactions are identified. During detailed design, the
algorithms and data structures are identified.
„„ We discussed that there is no unique design solution to any problem and one needs
to choose the best solution among a set of candidate solutions. To be able to achieve
this, we identified the factors based on which a superior design can be distinguished
from a inferior design.
„„ We discussed that understandability of a design is a major criterion determining
the goodness of a design. We characterised the understandability of design in
terms of satisfactory usage of decomposition and abstraction principles. Later, we
characterised these in terms of cohesion, coupling, layering, control abstraction,
fan-in, fan-out, etc.
„„ We identified two fundamentally different approaches to software design—function-
oriented design and object-oriented design. We discussed the essential philosophy
governing these two approaches and argued that these two approaches to software
design are not really competing approaches but complementary approaches.

EXERCISES

MULTIPLE CHOICE QUESTIONS

Choose the correct option:
1. The extent of data interchange between two modules is called:
(a) Coupling
(b) Cohesion
(c) Structure
(d) Union
2. Which of the following types of cohesion can be considered as the strongest cohesion?
(a) Logical
(b) Coincidental
(c) Temporal
(d) Functional
3. The modules in a good software design should have which of the following
characteristics:
(a) High cohesion, low coupling
(b) Low cohesion, high coupling
(c) Low cohesion, low coupling
(d) High cohesion, high coupling
238   Fundamentals of Software Engineering

TRUE OR FALSE
State whether the following statements are TRUE or FALSE. Give reasons for your answer.
1. The essence of any good function-oriented design technique is to map the functions
performing similar activities into a module.
2. Traditional procedural design is carried out top-down whereas object-oriented design
is normally carried out bottom-up.
3. Common coupling is the worst type of coupling between two modules.
4. Temporal cohesion is the worst type of cohesion that a module can have.
5. The extent to which two modules depend on each other determines the cohesion of
the two modules.

REVIEW QUESTIONS
1. Do you agree with the following assertion? A design solution that is difficult to under-
stand would lead to increased development and maintenance cost. Give reasonings
for your answer.
2. What do you mean by the terms cohesion and coupling in the context of software
design? How are these concepts useful in arriving at a good design of a system?
3. What do you mean by a modular design? How can you determine whether a given
design is modular or not?
4. Enumerate the different types of cohesion that a module in a design might exhibit.
Give examples of each.
5. Enumerate the different types of coupling that might exist between two modules.
Give examples of each.
6. Is it true that whenever you increase the cohesion of your design, coupling in the
design would automatically decrease? Justify your answer by using suitable examples.
7. What according to you are the characteristics of a good software design?
8. What do you understand by the term functional independence in the context of
software design? What are the advantages of functional independence? How can
functional independence in a software design be achieved?
9. Explain how the principles of abstraction and decomposition are used to arrive at a
good design.
10. What do you understand by information hiding in the context of software design?
Explain why a design approach based on the information hiding principle is likely
to lead to a reusable and maintainable design. Illustrate your answer with a suitable
example.
11. In the context of software development, distinguish between analysis and design with
respect to intention, methodology, and the documentation technique used.
12. Compare relative advantages of the object-oriented and function-oriented approaches
to software design.
 Software Design   239

13. Name a few well-established function-oriented software design techniques.

14. Explain the important causes of and remedies for high coupling between two software
modules.
15. What problems are likely to arise if two modules have high coupling?
16. What problems are likely to occur if a module has low cohesion?
17. Distinguish between high-level and detailed designs. What documents should be
produced on completion of high-level and detailed designs respectively?
18. What is meant by the term cohesion in the context of software design? Is it true that
in a good design, the modules should have low cohesion? Why?
19. What is meant by the term coupling in the context of software design? Is it true that
in a good design, the modules should have low coupling? Why?
20. What do you mean by modular design? What are the different factors that affect the
modularity of a design? How can you assess the modularity of a design? What are
the advantages of a modular design?
21. How would you improve a software design that displays very low cohesion and
high coupling?
22. Explain how the overall cohesion and coupling of a design would be impacted if all
modules of the design are merged into a single module.
23. Explain what do you understand by the terms decomposition and abstraction in
the context of software design. How are these two principles used in arriving good
procedural designs?
24. What is an ADT? What advantages accrue when a software design technique is based
on ADTs? Explain why the object paradigm is said to be based on ADTs.
25. By using suitable examples explain the following terms associated with an abstract
data type (ADT)—data abstraction, data structure, data type.
26. What do you understand by the term top-down decomposition in the context of
function-oriented design? Explain your answer using a suitable example.
27. What do you understand by a layered software design? What are the advantages of
a layered design? Explain your answer by using suitable examples.
28. What is the principal difference between the software design methodologies based on
functional abstraction and those based on data abstraction? Name at least one popular
design technique based on each of these two software design paradigms.
29. What are the main advantages of using an object-oriented approach to software design
over a function-oriented approach?
30. Point out three important differences between the function oriented and the object-
oriented approaches to software design. Corroborate your answer through suitable
examples.
31. Identify the criteria that you would use to decide which one of two alternate function-
oriented design solutions to a problem is superior.
32. Explain the main differences between architectural design, high-level-design, and
detailed design of a software system.
240   Fundamentals of Software Engineering

CHAPTER

6
FUNCTION-ORIENTED
SOFTWARE DESIGN

CHAPTER OUTLINE
®® Overview of SA/SD Methodology
®® Structured Analysis
®® Developing the DFD Model of a
System
®® Structured Design
®® Detailed Design
®® Design Review

The belief that complex systems require armies of designers

and programmers is wrong. A system that is not understood
in its entirety, or at least to a significant degree of detail by a
single individual, should probably not be built.
—Niklaus Wirth
 Function-Oriented Software Design   241

F
unction-oriented design techniques were proposed nearly
LEARNING OBJECTIVES four decades ago. These techniques are at the present time
®® Basic concepts in still very popular and are currently being used in many
structured analysis and software development projects. These techniques, to start with,
structured design view a system as a black-box that provides a set of services to
®® Development of the DFD the users of the software. These services provided by a software
model of a system (e.g., issue book, serach book, etc., for a Library
®® Transformation of DFD Automation Software to its
model into a structure users are also known as the The term top-down decomposi-
chart model high-level functions supported tion is often used to denote the
by the software. During the successive decomposition of a
design process, these high- set of high-level functions into
level functions are successively more detailed functions.
decomposed into more detailed
functions.
After top-down decomposition has been carried out, the
different identified functions are mapped to modules and a
module structure is created. This module structure would
possess all the characteristics of a good design identified in
the last chapter.
In this text, we shall not focus on any specific design
methodology. Instead, we shall discuss a methodology that has
the essential features of several important function-oriented
design methodologies. Such an approach shall enable us to
easily assimilate any specific design methodology in the future
whenever the need arises. Learning a specific methodology
may become necessary for you later, since different software
development houses follow different methodologies. After all,
the different procedural design techniques can be considered as
sister techniques that have only minor differences with respect
to the methodology and notations. We shall call the design
technique discussed in this text as structured analysis/structured
design (SA/SD) methodology. This technique draws heavily from
the design methodologies proposed by the following authors:
„ DeMarco and Yourdon [1978]
„ Constantine and Yourdon [1979]
„ Gane and Sarson [1979]
„ Hatley and Pirbhai [1987]
The SA/SD technique can be used to perform the high-
level design of a software. The details of SA/SD technique are
discussed further.

6.1 OVERVIEW OF SA/SD METHODOLOGY

As the name itself implies, SA/SD methodology involves
carrying out two distinct activities:
242   Fundamentals of Software Engineering

„ Structured analysis (SA)

„ Structured design (SD)
The roles of structured analysis (SA) and structured design (SD) have been shown
schematically in Figure 6.1. Observe the following from the figure:
„ During structured analysis, the SRS document is transformed into a data flow diagram
(DFD) model.
„ During structured design, the DFD model is transformed into a structure chart.

FIGURE 6.1 Structured analysis and structured design methodology.

As shown in Figure 6.1, the structured analysis activity transforms the SRS document
into a graphic model called the DFD model. During structured analysis, functional
decomposition of the system is achieved. That is, each function that the system needs to
perform is analysed and hierarchically decomposed into more detailed functions. On the
other hand, during structured design, all functions identified during structured analysis are
mapped to a module structure. This module structure is also called the high-level design or
the software architecture for the given problem. This is represented using a structure chart.
The high-level design stage is normally followed by a detailed design stage. During
the detailed design stage, the algorithms and data structures for the individual modules
are designed. The detailed design can directly be
implemented as a working system using a conventional It is important to understand
programming language. that the purpose of struc-
The results of structured analysis can therefore, be tured analysis is to capture
easily understood by the user. In fact, the different functions the detailed structure of the
and data in structured analysis are named using the user’s system as perceived by the
terminology. The user can therefore even review the results user, whereas the purpose of
of the structured analysis to ensure that it captures all his structured design is to define
requirements. the structure of the solution
In the following section, we first discuss how to that is suitable for implemen-
carry out structured analysis to construct the DFD model. tation in some programming
Subsequently, we discuss how the DFD model can be language.
transformed into structured design.
 Function-Oriented Software Design   243

6.2 STRUCTURED ANALYSIS

We have already mentioned that during structured analysis, the major processing tasks
(high-level functions) of the system are analysed, and the data flow among these
processing tasks are represented graphically. Significant contributions to the development
of the structured analysis techniques have been made by Gane and Sarson [1979], and
DeMarco and Yourdon [1978]. The structured analysis technique is based on the following
underlying principles:
„ Top-down decomposition approach.
„ Application of divide and conquer principle. Through this each high-level function
is independently decomposed into detailed functions.
„ Graphical representation of the analysis results using data flow diagrams (DFDs).
DFD representation of a problem, as we shall see shortly, is very easy to construct.
Though extremely simple, it is a very powerful tool to tackle the complexity of industry
standard problems.
Please note that a DFD model only represents the data flow aspects and does not
show the sequence of execution of the different functions and the conditions based on
which a function may or may not be executed. In fact, it completely ignores aspects
such as control flow, the specific algorithms used by the functions, etc. In the DFD
terminology, each function is called a process or a bubble. It is useful to consider each
function as a processing station (or process) that consumes some input data and produces
some output data.
DFD is an elegant modelling technique that can
be used not only to represent the results of structured A DFD is a hierarchical graph-
analysis of a software problem, but also useful for several ical model of a system that
other applications such as showing the flow of documents shows the different process-
or items in an organisation. Recall that in Chapter 1 ing activities or functions that
we had given an example (see Figure 1.10) to illustrate the system performs and the
how a DFD can be used to represent the processing data interchange among those
activities and flow of material in an automated car functions.
assembling plant. We now elaborate how a DFD model
can be constructed.

6.2.1 Data Flow Diagrams (DFDs)

The DFD (also known as the bubble chart) is a simple graphical formalism that can be
used to represent a system in terms of the input data to the system, various processing
carried out on those data, and the output data generated by the system. The main reason
why the DFD technique is so popular is probably because of the fact that DFD is a very
simple formalism—it is simple to understand and use. A DFD model uses a very limited
number of primitive symbols (shown in Figure 6.2) to represent the functions performed
by a system and the data flow among these functions.
Starting with a set of high-level functions that a system performs, a DFD model
represents the subfunctions performed by the functions using a hierarchy of diagrams.
We had pointed out while discussing the principle of abstraction in Section 1.3.2 that any
hierarchical representation is an effective means to tackle complexity. Human mind is such
244   Fundamentals of Software Engineering

that it can easily understand any hierarchical model of a system—because in a hierarchical

model, starting with a very abstract model of a system, various details of the system are
slowly introduced through different levels of the hierarchy. The DFD technique is also
based on a very simple set of intuitive concepts and rules. We now elaborate the different
concepts associated with building a DFD model of a system.

Primitive symbols used for constructing DFDs

There are essentially five different types of symbols used for constructing DFDs. These
primitive symbols are depicted in Figure 6.2. The meaning of these symbols are explained
as follows:

FIGURE 6.2 Symbols used for designing DFDs.

Function symbol: A function is represented using a circle. This symbol is called a process
or a bubble. Bubbles are annotated with the names of the corresponding functions (see
Figure 6.3).
External entity symbol: An external entity such as a librarian, a library member, etc.
is represented by a rectangle. The external entities are essentially those physical entities
external to the software system which interact with the system by inputting data to the
system or by consuming the data produced by the system. In addition to the human users,
the external entity symbols can be used to represent external hardware and software such
as another application software that would interact with the software being modelled.
Data flow symbol: A directed arc (or an arrow) is used as a data flow symbol. A data
flow symbol represents the data flow occurring between two processes or between an
external entity and a process in the direction of the data flow arrow. Data flow symbols
are usually annotated with the corresponding data names. For example the DFD in
Figure 6.3(a) shows three data flows—the data item number flowing from the process read-
number to validate-number, data-item flowing into read-number, and valid-number
flowing out of validate-number.
Data store symbol: A data store is represented using two parallel lines. It represents a
logical file. That is, a data store symbol can represent either a data structure or a physical
file on disk. Each data store is connected to a process by means of a data flow symbol. The
direction of the data flow arrow shows whether data is being read from or written into
a data store. An arrow flowing in or out of a data store implicitly represents the entire
 Function-Oriented Software Design   245

data of the data store and hence arrows connecting to a data store need not be annotated
with the name of the corresponding data items. As an example of a data store, number is
a data store in Figure 6.3(b).
Output symbol: The output symbol is as shown in Figure 6.2. The output symbol is used
when a hard copy is produced.
The notations that we are following in this text are closer to the Yourdon’s notations
than to the other notations. You may sometimes find notations in other books that are
slightly different than those discussed here. For example, the data store may look like a
box with one end open. That is because, they may be following notations such as those
of Gane and Sarson [1979].

Important concepts associated with constructing DFD models

Before we discuss how to construct the DFD model of a system, let us discuss some
important concepts associated with DFDs:

Synchronous and asynchronous operations

If two bubbles are directly connected by a data flow arrow, then they are synchronous.
This means that they operate at the same speed. An example of such an arrangement is
shown in Figure 6.3(a). Here, the validate-number bubble can start processing only after
the read-number bubble has supplied data to it; and the read-number bubble has to wait
until the validate-number bubble has consumed its data.
However, if two bubbles are connected through a data store, as in Figure 6.3(b) then
the speed of operation of the bubbles are independent. This statement can be explained
using the following reasoning. The data produced by a producer bubble gets stored in the
data store. It is therefore possible that the producer bubble stores several pieces of data
items, even before the consumer bubble consumes any of them.

FIGURE 6.3 Synchronous and asynchronous data flow.

Data dictionary A data dictionary lists the

Every DFD model of a system must be accompanied by a purpose of all data items and
data dictionary. A data dictionary lists all data items that the definition of all composite
appear in a DFD model. The data items listed include all data items in terms of their
data flows and the contents of all data stores appearing component data items.
on all the DFDs in a DFD model. Please remember that
246   Fundamentals of Software Engineering

the DFD model of a system typically consists of several DFDs, viz., level 0 DFD, level 1
DFD, level 2 DFDs, etc., as shown in Figure 6.4 discussed in new subsection. However, a
single data dictionary should capture all the data appearing in all the DFDs constituting
the DFD model of a system.
For example, a data dictionary entry may represent that the data grossPay consists of
the components regularPay and overtimePay.
grossPay = regularPay + overtimePay
For the smallest units of data items, the data dictionary simply lists their name and their
type. Composite data items are expressed in terms of the component data items using
certain operators. The operators using which a composite data item can be expressed in
terms of its component data items are discussed subsequently.
The dictionary plays a very important role in any software development process,
especially for the following reasons:
„ A data dictionary provides a standard terminology for all relevant data for use by
the developers working in a project. A consistent vocabulary for data items is very
important, since in large projects different developers of the project have a tendency
to use different terms to refer to the same data, which unnecessarily causes confusion.
„ The data dictionary helps the developers to determine the definition of different data
structures in terms of their component elements while implementing the design.
„ The data dictionary helps to perform impact analysis. That is, it is possible to
determine the effect of some data on various processing activities and vice versa.
Such impact analysis is especially useful when one wants to check the impact of
changing an input value type, or a bug in some functionality, etc.
For large systems, the data dictionary can become extremely complex and voluminous.
Even moderate-sized projects can have thousands of entries in the data dictionary. It
becomes extremely difficult to maintain a voluminous dictionary manually. Computer-aided
software engineering (CASE) tools come handy to overcome this problem. Most CASE tools
usually capture the data items appearing in a DFD as the DFD is drawn, and automatically
generate the data dictionary. As a result, the designers do not have to spend almost any
effort in creating the data dictionary. These CASE tools also support some query language
facility to query about the definition and usage of data items. For example, queries may
be formulated to determine which data item affects which processes, or a process affects
which data items, or the definition and usage of specific data items, etc. Query handling is
facilitated by storing the data dictionary in a relational database management system (RDBMS).

Data definition
Composite data items can be defined in terms of primitive data items using the following
data definition operators.
+ : denotes composition of two data items, e.g. a+b represents data a and b.
[,,] : represents selection, i.e. any one of the data items listed inside the square bracket
can occur. For example, [a,b] represents either a occurs or b occurs.
() :  the contents inside the bracket represent optional data which may or may not
appear.
 Function-Oriented Software Design   247

a+(b) represents either a or a+ b occurs.

{} : represents iterative data definition, e.g. {name}5 represents five name data. {name}*
represents zero or more instances of name data.
= : represents equivalence, e.g. a=b+c means that a is a composite data item comprising
of both b and c.
/**/ : Anything appearing within /* and */ is considered as comment.

6.3 DEVELOPING THE DFD MODEL OF A SYSTEM

A DFD model of a system graphically represents how each input data is transformed to
its corresponding output data through a hierarchy of DFDs.
The DFD model of a system is constructed by using
a hierarchy of DFDs (see Figure 6.4). The top level DFD The DFD model of a problem
is called the level 0 DFD or the context diagram. This is consists of many DFDs and a
the most abstract (simplest) representation of the system single data dictionary.
(highest level). It is the easiest to draw and understand.
At each successive lower level DFDs, more and more details are gradually introduced. To
develop a higher-level DFD model, processes are decomposed into their subprocesses and
the data flow among these subprocesses are identified.
To develop the data flow model of a system, first the most abstract representation
(highest level) of the problem is to be worked out. Subsequently, the lower level DFDs are
developed. Level 0 and Level 1 consist of only one DFD each. Level 2 may contain up to
7 separate DFDs, and level 3 up to 49 DFDs, and so on. However, there is only a single
data dictionary for the entire DFD model. All the data names appearing in all DFDs are
populated in the data dictionary and the data dictionary contains the definitions of all the
data items.

6.3.1 Context Diagram

The context diagram is the most abstract (highest level) data flow representation of a
system. It represents the entire system as a single bubble. The bubble in the context diagram
is annotated with the name of the software system being developed (usually a noun). This
is the only bubble in a DFD model, where a noun is used
for naming the bubble. The bubbles at all other levels
The context diagram establishes
are annotated with verbs according to the main function
the context in which the
performed by the bubble. This is expected since the
system operates; that is, who
purpose of the context diagram is to capture the context of
are the users, what data do
the system rather than its functionality. As an example of a
they input to the system, and
context diagram, consider the context diagram a software
what data they receive from
developed to automate the book keeping activities of a
the system.
supermarket (see Figure 6.10). The context diagram has
been labelled as ‘Supermarket software’.
The name context diagram of the level 0 DFD is justified because it represents the
context in which the system would exist; that is, the external entities who would interact
with the system and the specific data items that they would be supplying the system and
248   Fundamentals of Software Engineering

FIGURE 6.4 DFD model of a system consists of a hierarchy of DFDs and a single data
dictionary.

the data items they would be receiving from the system. The various external entities
with which the system interacts and the data flow occurring between the system and the
external entities are represented. The data input to the system and the data output from the
system are represented as incoming and outgoing arrows. These data flow arrows should
be annotated with the corresponding data names.
To develop the context diagram of the system, we have to analyse the SRS document
to identify the different types of users who would be using the system and the kinds of
data they would be inputting to the system and the data they would be receiving from
the system. Here, the term users of the system also includes any external systems which
supply data to or receive data from the system.
 Function-Oriented Software Design   249

6.3.2 Level 1 DFD

The level 1 DFD usually contains three to seven bubbles. That is, the system is represented
as performing three to seven important functions. To develop the level 1 DFD, examine the
high-level functional requirements in the SRS document. If there are three to seven high-
level functional requirements, then each of these can be directly represented as a bubble
in the level 1 DFD. Next, examine the input data to these functions and the data output
by these functions as documented in the SRS document and represent them appropriately
in the diagram.
What if a system has more than seven high-level requirements identified in the SRS
document? In this case, some of the related requirements have to be combined and
represented as a single bubble in the level 1 DFD. These can be split appropriately in the
lower DFD levels. If a system has less than three high-level functional requirements, then
some of the high-level requirements need to be split into their subfunctions so that we have
roughly about five to seven bubbles represented on the diagram. We illustrate construction
of level 1 DFDs in Examples 6.1 to 6.4.

Decomposition
Each bubble in the DFD represents a function performed by the system. The bubbles are
decomposed into subfunctions at the successive levels of the DFD model. Decomposition
of a bubble is also known as factoring or exploding a bubble. Each bubble at any level of
DFD is usually decomposed to anything three to seven bubbles. A few bubbles at any level
make that level superfluous. For example, if a bubble is decomposed to just one bubble or
two bubbles, then this decomposition becomes trivial and redundant. On the other hand,
too many bubbles (i.e. more than seven bubbles) at any level of a DFD makes the DFD
model hard to understand. Decomposition of a bubble should be carried on until a level
is reached at which the function of the bubble can be described using a simple algorithm.
We can now describe how to go about developing the DFD model of a system more
systematically.
1. Construction of context diagram: Examine the SRS document to determine:
„ Different high-level functions that the system needs to perform.
„ Data input to every high-level function.
„ Data output from every high-level function.
„ Interactions (data flow) among the identified high-level functions.
Represent these aspects of the high-level functions in a diagrammatic form. This would
form the top-level data flow diagram (DFD), usually called the DFD 0.
2. Construction of level 1 diagram: Examine the high-level functions described in
the SRS document. If there are three to seven high-level requirements in the SRS
document, then represent each of the high-level function in the form of a bubble.
If there are more than seven bubbles, then some of them have to be combined. If
there are less than three bubbles, then some of these have to be split.
3. Construction of lower-level diagrams: Decompose each high-level function into
its constituent subfunctions through the following set of activities:
250   Fundamentals of Software Engineering

„ Identify the different subfunctions of the high-level function.

„ Identify the data input to each of these subfunctions.
„ Identify the data output from each of these subfunctions.
„ Identify the interactions (data flow) among these subfunctions.
Represent these aspects in a diagrammatic form using a DFD.
Recursively repeat Step 3 for each subfunction until a subfunction can be represented
by using a simple algorithm.

Numbering of bubbles
It is necessary to number the different bubbles occurring in the DFD. These numbers help
in uniquely identifying any bubble in the DFD from its bubble number. The bubble at the
context level is usually assigned the number 0 to indicate that it is the 0 level DFD. Bubbles
at level 1 are numbered, 0.1, 0.2, 0.3, etc. When a bubble numbered x is decomposed, its
children bubble are numbered x.1, x.2, x.3, etc. In this numbering scheme, by looking at
the number of a bubble we can unambiguously determine its level, its ancestors, and its
successors.

Balancing DFDs
The DFD model of a system usually consists of many DFDs that are organised in a hierarchy.
In this context, a DFD is required to be balanced with respect to the corresponding bubble
of the parent DFD.
We illustrate the concept of balancing a DFD in
The data that flow into or out
Figure 6.5. In the level 1 DFD, data items d1 and d3 flow
of a bubble must match the
out of the bubble 0.1 and the data item d2 flows into the
data flow at the next level of
bubble 0.1 (shown by the dotted circle). In the next level,
DFD. This is known as balanc-
bubble 0.1 is decomposed into three DFDs (0.1.1, 0.1.2,
ing a DFD.
0.1.3). The decomposition is balanced, as d1 and d3 flow
out of the level 2 diagram and d2 flows in. Please note that
dangling arrows (d1, d2, d3) represent the data flows into or out of a diagram.

How far to decompose?

A bubble should not be decomposed any further once a bubble is found to represent a
simple set of instructions. For simple problems, decomposition up to level 1 should suffice.
However, large industry standard problems may need decomposition up to level 3 or level
4. Rarely, if ever, decomposition beyond level 4 is needed.

Commonly made errors while constructing a DFD model

Although DFDs are simple to understand and draw, students and practitioners alike
encounter similar types of problems while modelling software problems using DFDs. While
learning from experience is a powerful thing, it is an expensive pedagogical technique in
the business world. It is therefore useful to understand the different types of mistakes that
beginners usually make while constructing the DFD model of systems, so that you can
consciously try to avoid them. The errors are as follows:
„ Many beginners commit the mistake of drawing more than one bubble in the context
diagram. Context diagram should depict the system as a single bubble.
 Function-Oriented Software Design   251

FIGURE 6.5 An example showing balanced decomposition.

„ Many beginners create DFD models in which external entities appearing at all levels
of DFDs. All external entities interacting with the system should be represented only
in the context diagram. The external entities should not appear in the DFDs at any
other level.
252   Fundamentals of Software Engineering

„ It is a common oversight to have either too few or too many bubbles in a DFD. Only
three to seven bubbles per diagram should be allowed. This also means that each
bubble in a DFD should be decomposed three to seven bubbles in the next level.
„ Many beginners leave the DFDs at the different
levels of a DFD model unbalanced. It is important to realise that
„ A common mistake committed by many beginners a DFD represents only data
while developing a DFD model is attempting to flow, and it does not represent
represent control information in a DFD. any control information.
The following are some illustrative mistakes of trying
to represent control aspects such as:

ILLUSTRATION 1 A book can be searched in the library catalog by inputting its name.
If the book is available in the library, then the details of the book are displayed. If the
book is not listed in the catalog, then an error message is generated. While developing
the DFD model for this simple problem, many beginners commit the mistake of drawing
an arrow (as shown in Figure 6.6) to indicate that the error function is invoked after the
search book. But, this is a control information and should not be shown on the DFD.

FIGURE 6.6 It is incorrect to show control information on a DFD.

ILLUSTRATION 2 Another type of error occurs when one tries to represent when
or in what order difierent functions (processes) are invoked. A DFD similarly should not
represent the conditions under which different functions are invoked.
ILLUSTRATION 3 If a bubble A invokes either the bubble B or the bubble C
depending upon some conditions, we need only to represent the data that flows between
bubbles A and B or bubbles A and C and not the conditions depending on which the
two modules are invoked.
„ A data flow arrow should not connect two data stores or even a data store with an
external entity. Thus, data cannot flow from a data store to another data store or
to an external entity without any intervening processing. As a result, a data store
should be connected only to bubbles through data flow arrows.
 Function-Oriented Software Design   253

„ All the functionalities of the system must be captured by the DFD model. No
function of the system specified in the SRS document of the system should be
overlooked.
„ Only those functions of the system specified in the SRS document should be
represented. That is, the designer should not assume functionality of the system
not specified by the SRS document and then try to represent them in the DFD.
„ Incomplete data dictionary and data dictionary showing incorrect composition of
data items are other frequently committed mistakes.
„ The data and function names must be intuitive. Some students and even practicing
developers use meaningless symbolic data names such as a,b,c, etc. Such names
hinder understanding the DFD model.
„ Novices usually clutter their DFDs with too many data flow arrow. It becomes
difficult to understand a DFD if any bubble is associated with more than seven
data flows. When there are too many data flowing in or out of a DFD, it is better
to combine these data items into a high-level data item. Figure 6.7 shows an
example concerning how a DFD can be simplified by combining several data
flows into a single high-level data flow.

FIGURE 6.7 Illustration of how to avoid data cluttering.

We now illustrate the structured analysis technique through a few examples.

EXAMPLE 6.1 (RMS Calculating Software) A software system called RMS calculating
software would read three integral numbers from the user in the range of –1000 and
+1000 and would determine the root mean square (RMS) of the three input numbers and
display it.
254   Fundamentals of Software Engineering

In this example, the context diagram is simple to draw. The system accepts
three integers from the user and returns the result to him. This has been shown in
Figure 6.8(a). To draw the level 1 DFD, from a cursory analysis of the problem description,
we can see that there are four basic functions that the system needs to perform—accept
the input numbers from the user, validate the numbers, calculate the root mean square of
the input numbers and, then display the result. After representing these four functions in
Figure 6.8(b), we observe that the calculation of root mean square essentially consists of
the functions—calculate the squares of the input numbers, calculate the mean, and finally
calculate the root. This decomposition is shown in the level 2 DFD in Figure 6.8(c).

FIGURE 6.8 Context diagram, level 1, and level 2 DFDs for Example 6.1.
 Function-Oriented Software Design   255

Data dictionary for the DFD model of Example 6.1

data-items: {integer}3
rms: float
valid-data:data-items
a: integer
b: integer
c: integer
asq: integer
bsq: integer
csq: integer
msq: integer

Example 6.1 is an almost trivial example and is only meant to illustrate the basic
methodology. Now, let us perform the structured analysis for a more complex problem.

EXAMPLE 6.2 (Tic-Tac-Toe Computer Game) Tic-tac-toe is a computer game in which

a human player and the computer make alternate moves on a 3 × 3 square. A move consists
of marking a previously unmarked square. The player who is first to place three consecutive
marks along a straight line (i.e., along a row, column, or diagonal) on the square wins. As
soon as either of the human player or the computer wins, a message congratulating the
winner should be displayed. If neither player manages to get three consecutive marks along
a straight line and all the squares on the board are filled up, then the game is drawn. The
computer always tries to win a game.
The context diagram and the level 1 DFD are shown in Figure 6.9.

Data dictionary for the DFD model of Example 6.2

move: integer /* number between 1 to 9 */
display: game+result
game: board
board: {integer}9
result: [“computer won”, “human won”, “drawn”]

EXAMPLE       6.3 (Supermarket Prize Scheme) A super market needs to develop a soft-
ware that would help it to automate a scheme that it plans to introduce to encourage
regular customers. In this scheme, a customer would have first register by supplying his/
her residence address, telephone number, and the driving license number. Each customer
who registers for this scheme is assigned a unique customer number (CN) by the computer.
A customer can present his CN to the checkout staff when he makes any purchase. In this
case, the value of his purchase is credited against his CN. At the end of each year, the
supermarket intends to award surprise gifts to 10 customers who make the highest total
purchase over the year. Also, it intends to award a 22 caret gold coin to every customer
whose purchase exceeded `10,000. The entries against the CN are reset on the last day of
every year after the prize winners’ lists are generated.
The context diagram for the supermarket prize scheme problem of Example 6.3 is
shown in Figure 6.10. The level 1 DFD in Figure 6.11. The level 2 DFD in Figure 6.12.
256   Fundamentals of Software Engineering

FIGURE 6.9 Context diagram and level 1 DFDs for Example 6.2.

Data dictionary for the DFD model of Example 6.3

address: name+house#+street#+city+pin
sales-details: {item+amount}* + CN
CN: integer
customer-data: {address+CN}*
sales-info: {sales-details}*
winner-list: surprise-gift-winner-list + gold-coin-winner-list
 Function-Oriented Software Design   257

FIGURE 6.10 Context diagram for Example 6.3.

surprise-gift-winner-list: {address+CN}*
gold-coin-winner-list: {address+CN}*
gen-winner-command: command
total-sales: {CN+integer}*
Observations: The following observations can be made from the Example 6.3.
1. The fact that the customer is issued a manually prepared customer identity card
or that the customer hands over the identity card each time he makes a purchase
has not been shown in the DFD. This is because these are item transfers occurring
outside the computer.
2. The data generate-winner-list in a way represents control information (that
is, command to the software) and no real data. We have included it in the DFD
because it simplifies the structured design process as we shall realize after we
practise solving a few problems. We could have also as well done without the
generate-winner-list data, but this could have a bit complicated the design.
3. Observe in Figure 6.11 that we have two separate stores for the customer data and
sales data. Should we have combined them into a single data store? The answer
is—No, we should not. If we had combined them into a single data store, the
structured design that would be carried out based on this model would become
complicated. Customer data and sales data have very different characteristics. For
example, customer data once created, does not change. On the other hand, the
sales data changes frequently and also the sales data is reset at the end of a year,
whereas the customer data is not.
258   Fundamentals of Software Engineering

FIGURE 6.11 Level 1 diagram for Example 6.3.

FIGURE 6.12 Level 2 diagram for Example 6.3.

 Function-Oriented Software Design   259

EXAMPLE 6.4 [Trading-house Automation System (TAS)] A trading house wants us

to develop a computerized system that would automate various book-keeping activities
associated with its business. The following are the salient features of the system to be
developed:
„ The trading house has a set of regular customers. The customers place orders
with it for various kinds of commodities. The trading house maintains the names
and addresses of its regular customers. Each of these regular customers should
be assigned a unique customer identification number (CIN) by the computer. The
customers quote their CIN on every order they place.
„ Once order is placed, as per current practice, the accounts department of the trading
house first checks the credit-worthiness of the customer. The credit-worthiness of
the customer is determined by analysing the history of his payments to different
bills sent to him in the past. After automation, this task has be done by the
computer.
„ If a customer is not credit-worthy, his orders are not processed any further and an
appropriate order rejection message is generated for the customer.
„ If a customer is credit-worthy, the items that he has ordered are checked against
the list of items that the trading house deals with. The items in the order which the
trading house does not deal with, are not processed any further and an appropriate
apology message for the customer for these items is generated.
„ The items in the customer’s order that the trading house deals with are checked for
availability in the inventory. If the items are available in the inventory in desired
quantity, then:
– A bill is with the forwarding address of the customer is printed.
A material issue slip is printed. The customer can produce this material issue
– 
slip at the store house and take delivery of the items.
– Inventory data is adjusted to reflect the sale to the customer.
„ If any of the ordered items are not available in the inventory in sufficient quantity
to satisfy the order, then these out-of-stock items along with the quantity ordered
by the customer and the CIN are stored in a “pending-order” file for further
processing to be carried out when the purchase department issues the “generate
indent” command.
„ The purchase department should be allowed to periodically issue commands to
generate indents. When a command to generate indents is issued, the system
should examine the “pending-order” file to determine the orders that are pending
and determine the total quantity required for each of the items. It should find out
the addresses of the vendors who supply these items by examining a file containing
vendor details and then should print out indents to these vendors.
„ The system should also answer managerial queries regarding the statistics of
different items sold over any given period of time and the corresponding quantity
sold and the price realised.
The context diagram for the trading house automation problem is shown in
Figure 6.13. The level 1 DFD in Figure 6.14.
260   Fundamentals of Software Engineering

FIGURE 6.13 Context diagram for Example 6.4.

FIGURE 6.14 Level 1 DFD for Example 6.4.

Data dictionary for the DFD model of Example 6.4

response: [bill + material-issue-slip, reject-msg,apology-msg]
query: period /* query from manager regarding sales statistics*/
period: [date+date,month,year,day]
 Function-Oriented Software Design   261

date: year + month + day

year: integer
month: integer
day: integer
customer-id: integer
order: customer-id + {items + quantity}* + order#
accepted-order: order /* ordered items available in inventory */
reject-msg: order + message /* rejection message */
pending-orders: customer-id + order# + {items+quantity}*
customer-address: name+house#+street#+city+pin
name: string
house#: string
street#: string
city: string
pin: integer
customer-id: integer
customer-file: {customer-address}* + customer-id
bill: {item + quantity + price}* + total-amount + customer-address + order#
material-issue-slip: message + item + quantity + customer-address
message: string
statistics: {item + quantity + price }*
sales-statistics: {statistics}* + date
quantity: integer
order#: integer /* unique order number generated by the program */
price: integer
total-amount: integer
generate-indent: command
indent: {item+quantity}* + vendor-address
indents: {indent}*
vendor-address: customer-address
vendor-list: {vendor-address}*
item-file: {item}*
item: string
indent-request: command
Observations: The following observations can be made from Example 6.4.
1. In a DFD, if two data stores deal with different
types of data, e.g. one type of data is invariant with If two types of data always
time whereas another varies with time, (e.g. vendor get updated at the same time,
address, and inventory data) it is a good idea to they should be stored in a
represent them as separate data stores. single data store. Otherwise,
The inventory data changes each time supply separate data stores should be
arrives and the inventory is updated or an item is used for them.
sold, whereas the vendor data remains unchanged.
2. If we are developing the DFD model of a process which is already being manually
carried out, then the names of the registers being maintained in the manual process
would appear as data stores in the DFD model. For example, if TAS is currently
262   Fundamentals of Software Engineering

being manually carried out, then normally there would registers corresponding to
accepted orders, pending orders, vendor list, etc.
3. We can observe that DFDs enable a software developer to develop the data domain
and functional domain model of the system at the same time. As the DFD is
refined into greater levels of detail, the analyst performs an implicit functional
decomposition. At the same time, the DFD refinement automatically results in
refinement of corresponding data items.
4. The data that are maintained in physical registers in manual processing, become
data stores in the DFD representation. Therefore, to determine which data should
be represented as a data store, it is useful to try to imagine whether a set of data
items would be maintained in a register in a manual system.

EXAMPLE 6.5 (Personal Library Software) Structured analysis for the personal library
software is shown in Figure 6.15, Figure 6.16 and Figure 6.17.

FIGURE 6.15 Context diagram for Example 6.5.

The level 1 DFD is shown in Figure 6.16.
The level 2 DFD for the manage OwnBook bubble is shown in Figure 6.17.

FIGURE 6.16 Level 1 DFD for Example 6.5.

 Function-Oriented Software Design   263

FIGURE 6.17 Level 2 DFD for Example 6.5.

Data dictionary for the DFD model of Example 6.5

input-data: friend-reg-data + own-book-data + stat-request + borrowed-book-data
response: friend-reg-conf-msg + own-book-response + stat-response +
borrowed-book-response
own-book-data: query-details + own-book-details + query-outstanding-books-option +
return-own-book-details + reg-own-book-data
own-book-response: query-book-response + issue-book-msg + friend-details + return-book-
msg + serial#.
borrowed-book-data: borrowed-book-details + book-return-details + display-books-option
borrowed-book-response: reg-msg + unreg-msg + borrowed-books-list
friend-reg-data: name + address + landline# + mobile#
own-book-details: friend-reg-data + book-title + data-of-issue
return-own-book-details: book-title + date-of-return
friend-details: name + address + landline# + mobile# + book-list
borrowed-book-details: book-title + borrow-date
serial#: integer
Observation: Observe that since there are more than seven functional requirements for
the personal library software, related requirements have been combined to have only five
bubbles in the level 1 diagram. Only level 2 DFD has been shown, since the other DFDs
are trivial and need not be drawn.
264   Fundamentals of Software Engineering

Shortcomings of the DFD model

DFD models suffer from several shortcomings. The important shortcomings of DFD models
are the following:
„ Imprecise DFDs leave ample scope to be imprecise. In the DFD model, we judge
the function performed by a bubble from its label. However, a short label may not
capture the entire functionality of a bubble. For example, a bubble named find-
book-position has only intuitive meaning and does not specify several things, e.g.
what happens when some input information is missing or is incorrect. Further, the
find-book-position bubble may not convey anything regarding what happens when
the required book is missing.
„ Not-well defined control aspects are not defined by a DFD. For instance, the order in
which inputs are consumed and outputs are produced by a bubble is not specified.
A DFD model does not specify the order in which the different bubbles are executed.
Representation of such aspects is very important for modelling real-time systems.
„ Decomposition: The method of carrying out decomposition to arrive at the successive
levels and the ultimate level to which decomposition is carried out are highly
subjective and depend on the choice and judgment of the analyst. Due to this reason,
even for the same problem, several alternative DFD representations are possible.
Further, many times it is not possible to say which DFD representation is superior
or preferable to another one.
„ Improper data flow diagram: The data flow diagramming technique does not provide
any specific guidance as to how exactly to decompose a given function into its
subfunctions and we have to use subjective judgment to carry out decomposition.

6.3.3 Extending DFD Technique to make it Applicable to

Real-time Systems
In a real-time system, some of the high-level functions are associated with deadlines.
Therefore, a function must not only produce correct results but also should produce
them by some prespecified time. For real-time systems, execution time is an important
consideration for arriving at a correct design. Therefore, explicit representation of control
and event flow aspects are essential. One of the widely accepted techniques for extending
the DFD technique to real-time system analysis is the Ward and Mellor technique [1985].
In the Ward and Mellor notation, a type of process that handles only control flows is
introduced. These processes representing control processing are denoted using dashed
bubbles. Control flows are shown using dashed lines/arrows.
Unlike Ward and Mellor, Hatley and Pirbhai [1987] show the dashed and solid
representations on separate diagrams. To be able to separate the data processing and
the control processing aspects, a control flow diagram (CFD) is defined. This reduces the
complexity of the diagrams. In order to link the data processing and control processing
diagrams, a notational reference (solid bar) to a control specification is used. The CSPEC
describes the following:
„ The effect of an external event or control signal.
„ The processes that are invoked as a consequence of an event.
 Function-Oriented Software Design   265

Control specifications represents the behaviour of the system in two different ways:
„ It contains a state transition diagram (STD). The STD is a sequential specification of
behaviour.
„ It contains a program activation table (PAT). The PAT is a combinatorial specification
of behaviour. PAT represents invocation sequence of bubbles in a DFD.

6.4 STRUCTURED DESIGN

The aim of structured design is to transform the results of the structured analysis (that
is, the DFD model) into a structure chart. A structure chart represents the software
architecture. The various modules making up the system, the module dependency (i.e.,
which module calls which other modules), and the parameters that are passed among the
different modules. The structure chart representation can be easily implemented using
some programming language. Since the main focus in a structure chart representation is
on module structure of a software and the interaction among the different modules, the
procedural aspects (e.g., how a particular functionality is achieved) are not represented.
The basic building blocks using which structure charts are designed are as following:
Rectangular boxes: A rectangular box represents a module. Usually, every rectangular
box is annotated with the name of the module it represents.
Module invocation arrows: An arrow connecting two modules implies that during
program execution control is passed from one module to the other in the direction of the
connecting arrow. However, just by looking at the structure chart, we cannot say whether a
modules calls another module just once or many times. Also, just by looking at the structure
chart, we cannot tell the order in which the different modules are invoked.
Data flow arrows: These are small arrows appearing alongside the module invocation
arrows. The data flow arrows are annotated with the corresponding data name. Data flow
arrows represent the fact that the named data passes from one module to the other in the
direction of the arrow.
Library modules: A library module is usually represented by a rectangle with double
edges. Libraries comprise the frequently called modules. Usually, when a module is invoked
by many other modules, it is made into a library module.
Selection: The diamond symbol represents the fact that one module of several modules
connected with the diamond symbol is invoked depending on the outcome of the condition
attached with the diamond symbol.
Repetition: A loop around the control flow arrows denotes that the respective modules
are invoked repeatedly.
In any structure chart, there should be one and only one module at the top, called the
root. There should be at most one control relationship between any two modules in the
structure chart. This means that if module A invokes module B, module B cannot invoke
module A. The main reason behind this restriction is that we can consider the different
modules of a structure chart to be arranged in layers or levels. The principle of abstraction
does not allow lower-level modules to be aware of the existence of the high-level modules.
266   Fundamentals of Software Engineering

However, it is possible for two higher-level modules to invoke the same lower-level module.
An example of a properly layered design and another of a poorly layered design are shown
in Figure 6.18.

FIGURE 6.18 Examples of properly and poorly layered designs.

Flow chart versus structure chart

We are all familiar with the flow chart representation of a program. Flow chart is a
convenient technique to represent the flow of control in a program. A structure chart differs
from a flow chart in three principal ways:
„ It is usually difficult to identify the different modules of a program from its flow
chart representation.
„ Data interchange among different modules is not represented in a flow chart.
„ Sequential ordering of tasks that is inherent to a flow chart is suppressed in a
structure chart.

6.4.1 Transformation of a DFD Model into Structure Chart

Systematic techniques are available to transform the DFD representation of a problem
into a module structure represented by as a structure chart. Structured design provides
two strategies to guide transformation of a DFD into a
structure chart: Normally, one would start with
the level 1 DFD, transform it
„ Transform analysis
into module representation
„ Transaction analysis using either the transform or
At each level of transformation, it is important to transaction analysis and then
first determine whether the transform or the transaction proceed toward the lower
analysis is applicable to a particular DFD. level DFDs.
 Function-Oriented Software Design   267

Whether to apply transform or transaction processing?

Given a specific DFD of a model, how does one decide whether to apply transform
analysis or transaction analysis? For this, one would have to examine the data input to the
diagram. The data input to the diagram can be easily spotted because they are represented
by dangling arrows. If all the data flow into the diagram are processed in similar ways
(i.e., if all the input data flow arrows are incident on the same bubble in the DFD) then
transform analysis is applicable. Otherwise, transaction analysis is applicable. Normally,
transform analysis is applicable only to very simple processing.
Please recollect that the bubbles are decomposed until it represents a very simple
processing that can be implemented using only a few lines of code. Therefore, transform
analysis is normally applicable at the lower levels of a DFD model. Each different way in
which data is processed corresponds to a separate transaction. Each transaction corresponds
to a functionality that lets a user perform a meaningful piece of work using the software.

Transform analysis
Transform analysis identifies the primary functional components (modules) and the input
and output data for these components. The first step in transform analysis is to divide the
DFD into three types of parts:
„ Input.
„ Processing.
„ Output.
The input portion in the DFD includes processes that transform input data from
physical (e.g., character from terminal) to logical form (e.g., internal tables, lists, etc.). Each
input portion is called an afferent branch.
The output portion of a DFD transforms output data from logical form to physical
form. Each output portion is called an efferent branch. The remaining portion of a DFD is
called central transform.
In the next step of transform analysis, the structure chart is derived by drawing one
functional component each for the central transform, the afferent and efferent branches.
These are drawn below a root module, which would invoke these modules.
Identifying the input and output parts requires experience and skill. One possible
approach is to trace the input data until a bubble is found whose output data cannot be
deduced from its inputs alone. Processes which validate input are not central transforms.
Processes which sort input or filter data from it are central tansforms. The first level of
structure chart is produced by representing each input and output unit as a box and each
central transform as a single box.
In the third step of transform analysis, the structure chart is refined by adding
subfunctions required by each of the high-level functional components. Many levels of
functional components may be added. This process of breaking functional components into
subcomponents is called factoring. Factoring includes adding read and write modules, error-
handling modules, initialisation and termination process, identifying consumer modules
etc. The factoring process is continued until all bubbles in the DFD are represented in the
structure chart.
268   Fundamentals of Software Engineering

PROBLEM 6.1 Draw the structure chart for the RMS software of Example 6.1.
Solution: By observing the level 1 DFD of Figure 6.8, we can identify validate-input as
the afferent branch and write-output as the efferent branch. The remaining (i.e., compute-
rms) as the central transform. By applying the step 2 and step 3 of transform analysis, we
get the structure chart shown in Figure 6.19.

FIGURE 6.19 Structure chart for Problem 6.1.

PROBLEM 6.2 Draw the structure chart for the tic-tac-toe software of Example 6.2.
Solution: The structure chart for the Tic-tac-toe software is shown in Figure 6.20. Observe
that the check-game-status bubble, though produces some outputs, is not really responsible
for converting logical data to physical data. On the other hand, it carries out the processing
involving checking game status. That is the main reason, why we have considered it as a
central transform and not as an efferent type of module.

FIGURE 6.20 Structure chart for Problem 6.2.

 Function-Oriented Software Design   269

Transaction analysis
Transaction analysis is an alternative to transform analysis and is useful while designing
transaction processing programs. A transaction allows the user to perform some specific
type of work by using the software. For example, ‘issue book’, ‘return book’, ‘query book’,
etc., are transactions.
As in transform analysis, first all data entering into the DFD need to be identified. In
a transaction-driven system, different data items may pass through different computation
paths through the DFD. This is in contrast to a transform centered system where each
data item entering the DFD goes through the same processing steps. Each different way
in which input data is processed is a transaction. A simple way to identify a transaction
is the following. Check the input data. The number of bubbles on which the input data to
the DFD are incident defines the number of transactions. However, some transactions may
not require any input data. These transactions can be identified based on the experience
gained from solving a large number of examples.
For each identified transaction, trace the input data to the output. All the traversed
bubbles belong to the transaction. These bubbles should be mapped to the same module
on the structure chart. In the structure chart, draw a root module and below this module
draw each identified transaction as a module. Every transaction carries a tag identifying
its type. Transaction analysis uses this tag to divide the system into transaction modules
and a transaction-center module.

PROBLEM 6.3 Draw the structure chart for the Supermarket Prize Scheme software of
Example 6.3.
Solution: The structure chart for the Supermarket Prize Scheme software is shown in
Figure 6.21.

FIGURE 6.21 Structure chart for Problem 6.3.

270   Fundamentals of Software Engineering

PROBLEM 6.4 Draw the structure chart for the trade-house automation system (TAS)
software of Example 6.4.
Solution: The structure chart for the trade-house automation system (TAS) software of
Example 6.4 is shown in Figure 6.22.
By observing the level 1 DFD of Figure 6.14, we can see that the data input to the
diagram are handled by different bubbles and therefore transaction analysis is applicable to
this DFD. Input data to this DFD are handled in three different ways (accept-order, accept-
indent-request, and handle-query), we have three different transactions corresponding to
these as shown in Figure 6.22.

FIGURE 6.22 Structure chart for Problem 6.4.

Word of caution
We should view transform and transaction analyses as guidelines, rather than rules. We
should apply these guidelines in the context of the problem and handle the pathogenic
cases carefully.

PROBLEM 6.5 Draw the structure chart for the personal library software of Example 6.5.
Solution: The structure chart for the personal library software is shown in Figure 6.23.

6.5 DETAILED DESIGN

During detailed design the pseudo code description of the processing and the different data
structures are designed for the different modules of the structure chart. These are usually
described in the form of module specifications (MSPEC). MSPEC is usually written using
structured English. The MSPEC for the non-leaf modules describe the different conditions
under which the responsibilities are delegated to the lower-level modules. The MSPEC for
the leaf-level modules should describe in algorithmic form how the primitive processing
steps are carried out. To develop the MSPEC of a module, it is usually necessary to refer
to the DFD model and the SRS document to determine the functionality of the module.
 Function-Oriented Software Design   271

FIGURE 6.23 Structure chart for Problem 6.5.

6.6 DESIGN REVIEW

After a design is complete, the design is required to be reviewed. The review team usually
consists of members with design, implementation, testing, and maintenance perspectives,
who may or may not be the members of the development team. Normally, members of
the team who would code the design, and test the code, the analysts, and the maintainers
attend the review meeting. The review team checks the design documents especially for
the following aspects:
Traceability: Whether each bubble of the DFD can be traced to some module in the
structure chart and vice versa. They check whether each functional requirement in the SRS
document can be traced to some bubble in the DFD model and vice versa.
Correctness: Whether all the algorithms and data structures of the detailed design are
correct.
Maintainability: Whether the design can be easily maintained in future.
Implementation: Whether the design can be easily and efficiently be implemented.
After the points raised by the reviewers is addressed by the designers, the design
document becomes ready for implementation.

SUMMARY
„ In this chapter, we discussed a sample function-oriented software design methodology
called structured analysis/structured design (SA/SD) which incorporates features of
some important design methodologies.
„ Methodologies like SA/SD give us a recipe for developing a good design according
to the different goodness criteria we had discussed in Chapter 5.
272   Fundamentals of Software Engineering

„ item SA/SD consists of two important parts—structured analysis and structured

design.
„ The goal of structured analysis is to perform a functional decomposition of the
system. Results of structured analysis is represented using data flow diagrams (DFDs).
The DFD representation is difficult to implement using a traditional programming
language. The DFD representation can be systematically be transformed to structure
chart representation. The structure chart representation can be easily implemented
using a conventional programming language.
„ During structured design, the DFD representation obtained during structured
analysis is transformed into a structure chart representation.
„ Several CASE tools are available to support the software design process carried out
using the important function-oriented design methodologies. In addition to laying
out the DFDs, structure charts, maintaining the data dictionary, and helping in
traceability analysis, these CASE tools can also perform some elementary consistency
checking, e.g., they can usually check whether a DFD is balanced or not.

EXERCISES

MULTIPLE CHOICE QUESTIONS

For each of the following questions, only one of the options is correct. Choose the correct
option:
1. A data flow diagram represents:
(a) The conditions based on which a data may be processed
(b) The order in which different activities are carried out
(c) The transformation of data through processing stations
(d) The order in which various functions of a program are invoked
2. A DFD depicts which of the following:
(a) Flow of data
(b) Flow of control
(c) Flow of statements
(d) None of the above
3. Which of the following statements is not true of data flow diagrams (DFDs)?
(a) Hierarchical diagram.
(b) Represent code structure
(c) Do not represent decisions and control flows
(d) Represent functional decomposition
4. In a procedural design approach, during the detailed design stage, which of the
following is undertaken?
(a) Module structure is designed
(b) Data flow representation is developed
(c) Data structures and algorithms for the individual modules are developed
(d) Structure chart is developed