UNIT-3

Introduction
Before starting to develop a software, the exact requirements of the customer must be understood
and documented. In the past, many projects have suffered because the developers started to
implement something without determining whether they were building what the customers exactly
wanted. Starting development work without properly understanding and documenting the
requirements increases the number of iterative changes in the later life cycle phases, and thereby
alarmingly pushes up the development costs. This also sets the ground for customer dissatisfaction
and bitter customer-developer disputes and protracted legal battles. No wonder that experienced
developers consider the requirements analysis and specification to be a very important phase of
software development life cycle and undertake it with utmost care.

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. The requirements
analysis and specification phase ends when the requirements specification document has been
developed and reviewed. The requirements specification document is usually called as the software
requirements specification (SRS) document.

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 needs to be done. After understanding the precise user requirements, the
analysts analyse the requirements to weed out inconsistencies, anomalies and incompleteness. They
then proceed to write the software requirements specification (SRS) document.

FEASIBILITY STUDY

 it is the determination of whether or not a project is worth doing.

 It is normally culminate in a written & oral feasibility report.
 It is used as a basis for deciding whether to proceed, postpone or cancel the project.
TYPES OF FEASIBILITY STUDY

1. Technical 2. Operational 3. Economic 4. Social

5. Management 6. Legal 7. Time

TECHNICAL FEASIBILITY

 Concerned with specifying equipment & software that will successfully satisfy the user
requirement.
 Here configuration ,no of workstations required, speed of I/O devices are checked.
OPERATIONAL FEASIBILITY

It is mainly related to human organizational & political aspects.

1. What changes will be brought with the system ?

2. Do the existing staff members have these skills if not can they be trained in due course of time.

ECONOMIC FEASIBILITY(COST BENEFIT ANALYSIS)

The benefits and savings that are expected from a proposed software is compared with costs. If
benefits is more than cost then decision is taken otherwise further alternative in the proposed system
will have to be made.

SOCIAL FEASIBILITY

Determining whether a proposed project will be acceptable to the people or not.

MANAGEMENT FEASIBILITY

It determines whether a proposed project will be acceptable to management. If management doesn’t

accept a project or gives negligible support to it than the project is not feasible.

LEGAL FEASIBILITY

It determines whether a proposed project go against rule, known acts as well as any pending
legislation (law enacted by legislative body)

TIME FEASIBILITY

It determines whether a proposed project can be implemented fully within a stipulated time frame .
if project takes too much time it is likely to be rejected.

REQUIREMENTS GATHERING AND ANALYSIS

 The main goal of RAS(req. ana.speci) is to clearly understand the customer requirements & to
systematically organize these requirements in a specification document.
 Experienced Analysts take considerable time to understand the exact requirements of the
customer & to document them properly.
 They know without clear understanding & proper documentation of the problem, It is
impossible to develop a satisfactory solution.
This phase consists of three activities:-

 Requirement gathering or elicitation

 Analysis of gathered requirements
 Requirement specification
 1. Requirements Gathering
The primary objective of the requirement’s gathering task is to collect the requirements from the
stakeholders.

Typically 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.

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.
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.
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.
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:
a. Book is issued successfully to the member and the book issue slip is printed.
b. The book is reserved, and hence cannot be issued to the member.
c. 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.
5. Form analysis: it 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.

2. Requirements Analysis
After requirements gathering is complete, the analyst analyses the gathered requirements to form a
clear understanding of the exact customer requirements and to weed out any problems in the
gathered requirements.
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:
1. What is the problem?
2. Why is it important to solve the problem?
3. What exactly are the data input to the system and what exactly are the data output by the
system?
4. What are the possible procedures that need to be followed to solve the problem?
5. What are the likely complexities that might arise while solving the problem?
6. 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?

PROBLEMS IN REQUIREMENT ANALYSIS

The most important problems the analyst has to identify and eliminate are :-
Anomaly:-It is an ambiguity in requirement. when a requirement is anomalous several interpretations
is possible.
EXAMPLE 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 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.
Inconsistency:-The requirements become inconsistent,if any one of the requirements contradicts
another.
EXAMPLE Consider the following partial requirements that were collected from two different
stakeholders in a process control application development project.

1. The furnace should be switched-off when the temperature of the furnace rises above 500C.
2. 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.
Incompleteness:-It occurs when some of the requirements are ignored or unnoticed.
EXAMPLE 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.
Problems of Scope:- The boundary of the system is ill defined or the customers/ users specify
unnecessary technical detail that may confuse overall system objectives.
Problems of Understanding:-The customers /users are not completely sure of what is needed, have
poor understanding of the capabilities & limitations of their computing environment.
Problems of Volatility:-The requirements change over time.
Cause for the Problem
Ω Poor Communication
Ω Inadequate technique and tools
Ω A tendency to shortcut requirements analysis task
Ω A failure to consider Alternatives.
When the analyst detects these problems , he remove them by carryout further discussions with the
end users. Some problems detected easily while some require elaborate study of the problem.

3. 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.

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.
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.
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.

Why Spend Time and Resource to Develop an SRS Document

 Forms an agreement between the customers and the developers:
 Reduces future reworks:
 Provides a basis for estimating costs and schedules:
 Provides a baseline for validation and verification:
 Facilitates future extensions:

Characteristics of a Good SRS Document

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:

A good SRS document contains the following desirable qualities--

 Concise :- The SRS document should be concise, unambiguous , consistent, and complete.
 Structured :- The SRS should be well structured i.e. easy to understand and modify.
 Black Box View :- The SRS document should specify external behaviors of the system but not
implementation issues. What the system should do rather how to do. So it is called black box
specification of the system.
 Conceptual Integrity :- The document should emphasize conceptual integrity. So reader can
easily understand the contents.
 Response to Undesired Events:- The document should specify acceptable responses to
undesired events. These are called response to exceptional conditions.
 Verifiable :- All requirements of the system as documented as SRS document should be
verifiable that is it should be possible to determine whether or not requirements have been
met in an implementation.
  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.
 Modifiable: 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.

Attributes of Bad SRS Documents

Over-specification: It occurs when the analyst tries to address the “how to” aspects in the SRS
document.

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.

Important Categories of Customer Requirements

A good SRS document, should properly categorize and organise the requirements into different
sections [IEEE 830]. As per the IEEE 830 guidelines, the important categories of user requirements are
the following:

1. Functional requirements
The functional requirements capture the functionalities required by the users from the system. it is
useful to consider a software as offering a set of functions {f i} to the user. These functions can be
considered similar to a mathematical function f : I → O, meaning that a function transforms an element
(ii) in the input domain (I) to a value (oi) in the output (O).

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
requirements. The high-level functions would be split into smaller sub-requirements. Each high-level
function is an instance of use of the system (use case) by the user in some way. A high-level function
is one using which the user can get some useful piece of work done.
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.

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. Remember that there can
be many types of users of a system and their requirements from the system may be very different. So,
it is often useful to first identify the different types of users who might use the system and then try to
identify the different services expected from the software by different types of users.

EXAMPLE

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

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.

2. 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 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 throughput (transactions per
second, etc.). Some of these are:

1.Design and implementation constraints: Design and implementation constraints are an important
category of non-functional requirements describe any items or issues that will limit the options
available to the developers. 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.

2. 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.

3.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.

3. 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 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 that may be required in the future, easier
support for new devices to be supported in the future, reusability issues, etc.

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. 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.

Organisation of the SRS Document/Content of SRS document

The 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.

The important sections that an SRS document should contain as suggested by the IEEE are as follows:

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.

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.

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.

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

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.

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.

Note: for example refer to example 4.9 page 194

Techniques for Representing Complex Logic

A good SRS document should properly characterise the conditions under which different scenarios of
interaction occur. 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 interactions. and processing sequences may exist depending on the
outcome of the corresponding condition checking.

There are two main techniques available to analyse and represent complex processing logic—decision
trees and decision tables.

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:

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.

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.
 1. FORMAL SYSTEM SPECIFICATION
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
(propertyoriented approach) or as an abstract model of the system (model-oriented approach).

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.

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.

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.

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.

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.

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
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.

Advantages:- 1. Formal specification encourage rigour.

2. Formal method have a well founda mathematical basis.
3. It has well defined semantics.
Disadvantages:- 1. Difficult to learn and use
2. Not able to handle complex problems

2. AXIOMATIC SPECIFICATION
In axiomatic specification of a system, first-order logic is used to write the pre- and postconditions 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:

1. Establish the range of input values over which the function should behave correctly. Establish
the constraints on the input parameters as a predicate.
2. Specify a predicate defining the condition which must hold on the output of the function if it
behaved properly.
3. 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.
4. 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.
 3. 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.

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.

EXAMPLE 4.13 Let us specify a data type point supporting the operations create, xcoord, ycoord,
isequal; where the operations have their usual meaning.
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.

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 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.

Software Design
Design means “making a drawing, pattern or sketch of”

Software design deals with converting the customer requirements as described in the

SRS into a form (a set of documents) that is implementable using a programming language.

During the software design phase, the design document is produced, based on the customer
requirements as documented in the SRS document. the design process starts using the SRS document
and completes with the production of the design document.

Outcome of the Design Process

The following items are designed and documented during the design phase.

1. 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.
2. 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.
3. Interfaces among different 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.
4. 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.
5. 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.
Classification of 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.

1. Preliminary (or high-level) design

2. Detailed design.

In Preliminary Design we

1.Identify different modules

2.Call relationship & Interfaces among them.

The output of Preliminary design is Software Architecture .

Tree like diagrams called Structured chart, Jackson diagram or warnier- Orr diagram can be used for
high level design

In Detailed design

1. The data structure & algorithm of modules are designed The outcome is module specification
(MSPEC) document. Data structures and algorithms to be used described using MSPEC and
can be easily grasped by programmers for initiating coding.

HOW TO CHARACTERISE A GOOD SOFTWARE DESIGN?/CRITERIA FOR GOOD

SOFTWARE DESIGN
The criteria of a good software design are :-

1. Correctness:-It should correctly implement all the functionalities identified in the SRS document.

2. Efficiency:- It should be efficient enough to represent all requirements

3. Maintainability:- It can be easily change.

4. Understandability:- It should be easily understandable.

5. Use meaningful names for various design components

6.MODULARITY

The design should be modular .Software is divided into separately named components, often called
modules. It implements divide and conquer principles. 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. If different modules are independent on each other then each module can be understood
separately. It reduces the complexity of the design solution greatly. A software design with high
cohesion and low coupling among modules is the effective problem decomposition

M1

M2 M3 M4

M5

7.Clean Decomposition :- Modules should display high cohesion and low coupling

8.Neat Arrangement:-

The modules should be neatly arranged in tree like diagrams called Structured Chart.

COHESION AND COUPLING

Good module decomposition is indicated through high cohesion of the individual modules and low
coupling of the modules with each other.

Cohesion
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.
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.

Classification of Cohesion
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:

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.

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.

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(), updateinventory(), and logout() all do different thing and operate on different data.

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.

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.

Coupling
Intuitively, we can think of coupling as follows. 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.

Classification of Coupling
The coupling between two modules indicates the degree of interdependence between them.
Intuitively, if two modules. 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:

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.

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 treelike diagram known as a structure
chart.other notations such as Warnier-Orr [1977, 1981] or Jackson diagrams [1975] may also be used.

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
should not call a module that is either at a higher layer or even in the same layer. 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.

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

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
APPROACHES TO SOFTWARE DESIGN
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, functionoriented designing is a mature technology and
has a large following.

1. Function-oriented Design
The following are the salient features of the functionoriented design approach:

Top-down decomposition: A system, to start with, is viewed as a black box that provides certain
services (also known as high-level functions) to the users of the system.
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

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 of a library
automation system. Such data in procedural programs usually have global scope and are shared by
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

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 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).

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.

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:

1. 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.

2. An ADT-based design displays high cohesion and low coupling. Therefore, object

oriented designs are highly modular.

3. Since the principle of abstraction is used, it makes the design solution easily understandable and
helps to manage complexity.

Object-oriented versus function-oriented design approaches

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

 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-bookdetails, 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-employeeaddress, 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.

*********