UNIT II

Software Requirement Specification

Fundamental problem of s/w engineering is the problem of scale.
In the early days of s/w development, emphasis was on coding and design and little
importance was given to s/w requirement.
As system grew more complex, the goal of entire system could not be decided
easily. Hence the need for a more rigorous requirement phase comes. Now for large
s/w system requirement analysis is most difficult and intractable activity. S/w project
is initiated by the client needs. In the beginning these needs are in the minds of
various people in the client organization. The analyst has to identify the
requirement by talking to their people and understanding their needs.

Software Requirement
IEEE defines a requirement as ::

A condition of capability needed by a user to solve a problem or achieve an

objective
A condition or capability that must be met or processed by a system to satisfy
a contract, standard, specification or other formally imposed document

In s/w requirements we are dealing with requirements of the proposed system.

SRS is a document that completely describes what the proposed s/w should do
without describing how the s/w will do it.
Basic goal of requirement phase is to produce the SRS which describes the
complete external behavior of the proposed software.
Request for change can be made even after the requirement phase is done and the
SRS is produced. Requirement changes are a fact of file for most complex system.
Changing requirements is a continuous irritant for s/w developers and frequently
leads to bitterness between client and developers. Though many changes come due
to the changing needs of clients, many of the changes request have their origin in
incorrect interpretations or specification of requirements. These errors come in SRS
largely due to requirement phase not been done thoroughly by the client and the
requirement analysis not performing the task rigorously.

Need for SRS

The origin of most s/w system is in the need of a client who either wants to
automate an existing manual system or devices a new s/w system. It is created by
developers. Finally the completed system will be used by the end user. Thus there
are three major parties interested in a new system :

Client
User
Developer

Problem is that the client usually does not understand s/w or s/w development
process and the developer often does not understand the clients problem and
application areas. This causes a communication gap between the parties involved in
the development project. Basic purpose of SRS is to bridge this communication gap.
SRS is the medium through which the client and user needs are accurately
specified. SRS is helping the client understand their own needs.
in the development project. Basic purpose of SRS is to bridge this communication
gap. SRS is the medium through which the client and user needs are accurately
specified. SRS is helping the client understand their own needs.
Main advantages of SRS

An SRS establishes the basis for agreement between the client and supplier
or what the s/w product will do.
Through SRS the client clearly describes what it expects from supplier
and developer clearly understand what capabilities to build in s/w
An SRS provides a reference for validation of final product. Without a proper
SRS, there is no way a client can determine if the s/w being delivered is what
was ordered and there is no way the developer can convince the client that
the entire requirements have been fulfilled.
High quality SRS is a prerequisite to high quality s/w. Quality of SRS has an
important effect on cost of the project.
A high quality SRS reduce the development cost.

Requirement Process
It is the sequence of activities that need to be performed in the requirement phase
and that culminate in producing a high quality document containing the SRS. The
requirement phase typically consists of 3 basic activities::

Problem or requirement analysis

Requirement specification
Requirement validation

Problem analysis starts with some general statement of need or a high level
problem statement. During analysis the problem domain and the environment are
modeled in an effort to understand the system behavior, constraints on the system,
its input and output.
In requirement specification the focus is on clearly specifying the requirements in a
document. Issues, such as representation, specification languages and tools are
addressed during this activity.
Validation focus on what has been specified in the SRS is indeed all the
requirements of the s/w and making sure that the SRS is of good quality.
Problem Analysis
Analysis issues :
Three basic approach to problem analysis::
Informal Approach-> Based on structured communication/interaction
Conceptual Modeling-> Based on approach
Prototyping
Structured Analysis:
Data flow diagram
Data dictionary
Other modeling approach
SADT
PSL/PSA: Problem Statement Language
RSL/REVS: Requirement Statement Language/Requirement Engineering Validation
System
E-R Modeling:
Prototyping::Two approaches to prototyping:

Throwaway::It is constructed with the idea that it will be discarded after

analysis is complete.
Evolutionary::It is built with the idea that it will eventually be converted into
final system.

Characteristics of SRS::

Correct

Complete
Unambiguous
Verifiable
Consistent
Ranked for importance and/or stability
Modifiable
Traceable

Components of an SRS

Functionality
Performance
Design constraints imposed on an implementation
External interfaces

Validation
Development of s/w starts with the requirement document which is also used to
determine eventually whether or not the delivered s/w system is acceptable.
Due to nature of the requirement specification phase there is a lot of room for
misunderstanding and committing error and it is quite possible that the
requirements specification does not accurately represent the client needs.
Basic goal of requirement validation activity is to ensure that the SRS reflect the
actual requirements accurately and clearly.
Following errors occur in SRS:

Omission::In these types of error, some user requirements are simple and not
included in the SRS. Omitted requirement may be related to the behavior of
the system and its performance. It directly affects the external completely of
the SRS.
Inconsistency::It can be due to contradiction with the requirement of the
client or with the environment in which the system will operate.
Incorrect Fact::When some fact recorded in the SRS is not correct,
Ambiguity::When there are some requirement that have multiple meaning,
that is, their interpretation is not required.

Software Process Models

A simple representation of s/w process presented from specific perspective

Examples of process perspective are
Workflow perspective-sequence of activities
Data flow perspective-information flow
Role/action perspective-who does what
Generic process models
Waterfall
Iterative development
Component based s/w engineering

Waterfall Model
Also referred to as Linear Sequential Model, this is the most common and classic of
life cycle models. It is very simple to understand and use. In this model, each phase
must be completed in it is entirely before the next phase can begin. At the end of
each phase, a review takes place to determine if the project is on right path and
whether or not to continue or discard the project. Unlike the general model, phases
do not overlap in a waterfall model.
This model encompasses the following activity:
System/information engineering and modeling:: S/w is always part of large system
(or business),work begins by establishing requirements for all system elements and
then allocating some subset of these requirements to s/w. This system view is
essential when s/w must interact with other elements such as h/w, people and
databases. System engineering and analysis encompass requirements gathering at
the system level with a small amount of top level design and analysis. Information
engineering encompasses requirements gathering at the strategic business level
and at the business area level.

Requirement

Design

Implementati
on and Unit
testing
Integration
and Software
Testing
Operation

Waterfall Model
S/w requirement analysis::The requirements gathering process is intensified and
focused specially on software. To understand the natures of programs to be built,
the s/w engineer (analyst) must understand the information domain for the s/w as
well as required function, behavior, performance and interface. Requirements are
for both the system and the s/w are documented and reviewed with the customer.
Design:: S/w design is actually a multistep process that focuses on four distinct
attributes of a program: data structure, s/w architecture, interface representations
and procedural (algorithmic ) details. The design translates requirements into a

representation of the s/w that can be assessed for quality before coding begins. Like
requirements, the design is documented and becomes part of s/w configuration.
Code Generation:: The design must be translated into a machine-readable form. The
code generation step performs this task. If design is performed in a detailed
manner, code generation can be accomplished mechanistically.
Testing:: Once code has been generated, program testing begins. The testing
process focuses on the logical internals of the software, ensuring that all the
statements have been tested, and on the functional externals; i.e. conducting tests
to uncover errors and ensure that defined input will produce actual results that
agree with required results.
Advantages

Simple and easy to use.

Easy to manage due to the rigidity of the model-each phase has specific
deliverables and a review process.
Phases are processed and complete one at a time
Works well for smaller projects where requirements are very well understood.

Disadvantages

Adjusting scope during the life cycle can kill a project

No working s/w is produced until late during the life cycle
High amounts of risk and uncertainty
Poor model for complex and object-oriented projects
Poor mode for long and ongoing projects
Poor model where requirements are at a moderate to high risk of changing

Prototyping Model

Customer may not specify complete requirements at beginning

Developer may be unsure of the software product he had made
Prototyping
-

Quick design (prototype) is prepared and evaluated by customer

Serves as mechanism for identifying software requirements

Problems :
that

Sometimes customer sees it as a working version and when told about

it is to be rebuilt to achieve high quality, demands that few fixes should be

applied to prototype to make it a working product.
-

Developer often makes compromises on O/S and prog. languages while

building prototype. After some time, they become familiar with these
choices and they became integral part of the system.

RAD Model

Works on 4GT
Rapid Application Development (RAD) is an incremental software development process model that
emphasises a very short development cycle.

RAD is used primarily for information systems applications, the RAD approach encompasses
the following phases:

Business modeling
The information flow among business functions is modeled in a way that answers the following
questions:
What information drives the business process?
What information is generated?
Who generates it?
Where does the information go?
Who processes it?
Data modeling
The information flow defined as part of the business modeling phase is refined into a set of data
objects that are needed to support the business. The characteristics (called attributes) of each
object are identified and the relationships between these objects are defined.
Process modeling

The data objects defined in the data-modeling phase are transformed to achieve the information
flow necessary to implement a business function. Processing descriptions are created for adding,
modifying, deleting, or retrieving a data object.
Application generation
RAD assumes the use of the RAD fourth generation techniques and tools like VB, VC++, Delphi
etc rather than creating software using conventional third generation programming languages.
The RAD works to reuse existing program components (when possible) or create reusable
components (when necessary). In all cases, automated tools are used to facilitate construction of
the software.
Testing and turnover
Since the RAD process emphasizes reuse, many of the program components have already been
tested. This minimizes the testing and development time.
If a business application can be modularized so that each major function can be completed within
the development cycle then it is a candidate for the RAD model. In this case, each team can be
assigned a model, which is then integrated to form a whole.
Problems with RAD Model
-

requires team members who are committed to rapid-fire activities

for systems that cannot be properly modularized, building the

components necessary for RAD will be problematic.
when building new applications and technical risks are high, RAD is not
appropriate.
for large but scalable projects, RAD requires sufficient human resources
to create right number of teams.

Evolutionary development Models

Concurr ent
activities

Outline
description

Specification

Initial
version

Development

Intermediate
versions

Validation

Final
version

Potential problems

Lack of process visibility

Final version/prototype is often poorly structured

Special skills (e.g., in languages for rapid prototyping) may be required

Applicability

For small or medium-size interactive systems

For parts of large systems (e.g., the user interface)

For short-lifetime systems (in case of exploratory development)

Incremental Model

Combines element of the linear sequential model and iterative nature of

prototyping.

Each linear sequence produces a increment which is deliverable.

First increment is called a core product where basic requirements are

addressed, but many supplementary features remain undelivered.

Every increment is used and evaluated by customer.

Next increment meets the additional features and functionality identified in

previous increment.

Process is repeated until a complete product is produced.

Particularly useful when staffing is unavailable for complete implementation

by the deadline.

Advantages

Useful functionality is delivered with each increment, so customers derive

value early.

Early increments act as a prototype to help elicit requirements for later

increments.

Lower risk of overall project failure

The highest priority system services tend to receive the most testing.

Develop high-risk or major functions first

Each release delivers an operational product

Customer can respond to each build

Uses divide and conquer breakdown of tasks

Lowers initial delivery cost

Initial product delivery is faster

Customers get important functionality early

Risk of changing requirements is reduced

Disadvantages

Requires good planning and design

Requires early definition of a complete and fully functional system to allow for
the definition of increments

Well-defined module interfaces are required (some will be developed long

before others)

Total cost of the complete system is not lower

Spiral Model

Objectives: functionality, performance, hardware/software interface, critical

success factors, etc.

Alternatives: build, reuse, buy, sub-contract, etc.

Constraints: cost, schedule, interface, etc.

Study alternatives relative to objectives and constraints

Identify risks (lack of experience, new technology, tight schedules, poor

process, etc.

Resolve risks (evaluate if money could be lost by continuing system

development

Typical activites:

Create a design

Review design

Develop code

Inspect code

Test product

Typical activities
o

Develop project plan

Develop configuration management plan

Develop a test plan

Develop an installation plan

Advantages

Provides early indication of insurmountable risks, without much cost

Users see the system early because of rapid prototyping tools

Critical high-risk functions are developed first

The design does not have to be perfect

Users can be closely tied to all lifecycle steps

Early and frequent feedback from users

Cumulative costs assessed frequently

Disadvantages

Time spent for evaluating risks too large for small or low-risk projects

Time spent planning, resetting objectives, doing risk analysis and

prototyping may be excessive

The model is complex

Risk assessment expertise is required

Spiral may continue indefinitely

Developers must be reassigned during non-development phase activities

May be hard to define objective, verifiable milestones that indicate

readiness to proceed through the next iteration

Task regions in spiral model :

Customer Communication

Planning

Risk Analysis

Engineering

Construction and Release

Customer Evaluation

Unlike classical process models that end when software is delivered, the
spiral model can be adapted to apply throughout the life of the computer
software.

WINWIN Spiral Model

In an ideal context, the developer simply asks the customer what is required
and the customer provides sufficient detail to proceed. Unfortunately, this rarely
happens. In reality, the customer and the developer enter into a process of
negotiation.
The best negotiation strive for a win-win situation. The customer wins by
getting the product that satisfies the majority of the customers needs and the
developer wins by working to realistic and achievable budgets and deadlines.

Activities in model :

Identify next-level stakeholders

Identify stakeholders win conditions

Reconcile win conditions and establish next-level objectives,

constraints and objectives

Evaluate process and product alternatives and resolve risks

Define next level of product and process

Validate product and process definitions

review and comment

Function Oriented Design

Design is the first step in moving from the problem domain to solution domain.
It is a bridge between requirement specification and the final solution for satisfying
the requirements
Goal of the design process is to produce a model on representation of a system,
which can be used later to build that system.
Produced model is called Design of the System
It is a blueprint or plan of a solution for the system.
A system can be considered to be a set of components with clearly defined manners
to produce some service or behavior for its environment.
In s/w system component is an s/w module. Design process for s/w system often has
two levels::

At first level, the focus is on deciding which modules are needed for the
system, the specification of these modules and how the modules should be
interconnected. It is called System Design or Top-Level design
Internal design of the modules or how the specifications of the module can be
satisfied is decided. This design level often called Detailed Design or Logic
Design

Detailed design essentially expands the system design to contain a more detailed
description of the processing logic and data structure so that the design is
sufficiently complete for coding.
Since the detailed design is an extension of system design. System design control
the major structured characteristics of system. System design has a major impact
on testability and modifiability of a system and it impacts its efficiency.
Design Methodology
It is a systematic approach to creating a design by applying a set of
techniques and guidelines. Most design methodologies focus on the system design.
Most current design methodologies essentially offer a net of guidelines that can be
used by the developer to design a system.
The input to the design phase is the specifications for the system to be designed.
The output of the top-level design phase is the architectural design or the system
design for the s/w system to be built. This can be produced with or without design
methodology.

Design can be object oriented or function oriented. In function oriented design, the
design consists of module definition, with each module supporting a functional
abstraction. In object oriented design the module in the design represent data
abstraction.
Purpose of design phase is to specify the components for this transformation
function, so that each component is also a transformation function.
Basic output of the system design phase is the definition of all the major data
structure in the system, all major modules of the system and how the modules
interact with each other.
Design Principles:
Design of a system is correct if a system built according to the design satisfy the
requirement of that system.
Goal during the design phase is to produce correct design. The goal of design phase
is to find the best possible design within the limitations imposed by the
requirements and physical and social environment in which the system will operate.
To evaluate a design, some properties and criteria need to be specified that can be
used for evaluation.
A design should clearly be verifiable, complete and traceable the two most
important properties that concern designers are efficiency and simplicity.
Efficiency of any system is concerned with the proper use of scare resources by the
system. The need for efficiency arises due to cost consideration. In computer
system, the resources that are most often considered for efficiency one processor
type and memory. An efficient system is one that consumes less processor time and
requires less memory.
Simplicity::It is the most important quality criteria for s/w system. Maintenance of
s/w is usually quite expensive. Maintainability of s/w is one of the goals. Design of a
system is one of the most important factors affecting the maintainability of system.
During maintenance, maintainer has a thorough understanding of the different
module of the system, how they are interconnected and how modifying one will
affect the other.
A simple and understandable design will go a long way in making the job of the
maintainer easier.
The principles that can be used in design are the same as those used in problem
analysis. Methods are also similar because in both analysis and design a model is
being constructed.
There are some fundamental differences:

In problem analysis, a model of problem domain is constructed, while in

design model for solution domain is created.
In problem analysis, the analyst has limited degree of freedom in selecting
the model as the problem is given and modeling has to represent it. In
design, the designer has great deal of freedom in deciding the models; the
designer is creating a model for the system that will be the basis for building
the system.
In design system depend on model, while in problem analysis the model
depends on system.
Basic aim of modeling in problem analysis is to understand while basic aim of
modeling in design is to optimize.

Role of management in s/w development

Proper management is an integral part of s/w development. A large s/w
development project involves many people working for a long period of time. A
development process typically partitions the problem of developing s/w into a set of
phases. To meet the cost, quality and schedule objectives and resources have to be
properly allocated to each activity for the project and progress of different activities
has to be monitored and corrective action taken, if needed all these activities are
parts of the project management process.
A development process does not specify following, so project management is
necessary.

How to allocate resources to the different activities in the process

Schedule for the activities
How to divide the work within the phase
How to ensure that phase is being done properly
What is the risk for project and how to migrate them

The focus of the management process is on issue like planning a project, estimating
resources and schedule and monitoring the project. For large project, a proper
management process is essential for success.
Phases of management process
The activities in the management process for a project can be grouped broadly in to
3 phases::

Planning::

Project management begins with planning, which is perhaps the single largest
responsibility of the project management. The goal of this phase is to develop a

plan for s/w development following which the objectives of the project can be met
successfully and efficiently. During planning the major activities are::

Cost estimation
Schedule and milestone determination
Project staffing
Quality control plans
Controlling and monitoring plans

In the cost and schedule estimation, the total time needed for successful completion
of the project is estimated. In addition, cost and schedule for the different activities
of the development process to be used are also estimated. A plan also provides
methods for handling change and methods for monitoring a project. Project
planning is undoubtedly the single and most important management activity and
the output of this forms the basis of monitoring and control.

Monitoring and control::

Project monitoring and control phase of the management process is the longest in
terms of duration; it encompasses most of the development process. It includes all
the activities the project, management has to perform while the development is
going on to ensure that project objectives are met and the development proceeds
according to the development plan.

Monitoring a development process requires proper information about the project;

such information is typically obtained by the management process from the
development process. The implementation of the development process model
should be such that each step in development process produces information that
the management process needs for that step i.e. development process provides the
management process needs.

Termination analysis::

Termination analysis is performed when the development process is over. The basic
reason for performing termination analysis is to provide information about the
development process. The data about the project is also needed to analyze the
process. For these reasons, the termination analysis phase is needed.
Role of Metrics and Measurement
Matrix is used for effective project management. Objective data is needed for this
s/w matrix is used. S/w metrics are quantifiable measure and that could be used to
measure different characteristics of a s/w system or the s/w development process. A
number of metrics have been proposed to quantity things like the size, complexity
and reliability of a s/w product. There are two types of metrics are used for s/w
development:

Product metrics
Process metrics

Product metrics are used to quantify characteristic of the project being developed.
Process metrics are used to quantify the characteristics of the process being used to
develop the s/w.
Intricately tied to metrics is measurement. Metrics provide the scale for quantifying
qualities, qualifying characteristics of the given s/w. An analogy in the physical
world and that centimeter is the metric of length, but to determine the length of a
given rod, one must measure it some means like measuring tape. The measurement
methods must be objective and should produce the same result independent of the
measure.
Values for some metrics can be directly measured; others might have to be deduced
by other measurement. If the metrics is not measured directly, it is called metrics
indirect. Some factors like many s/w qualifying parameters cannot be measured
directly. Metrics measures productivity, cost and resource requirement effectiveness
of quality assurance measure. For effective monitoring the management need to get
information about the project.

How far it has progressed?

How much development has taken place?
How far behind schedule it is?
The quality of the development
The decisions can be made about the project

In metrics measurement and models go together. Metrics provide a quantification of

some property. Measurement provides the actual value for the metrics and models
are needed to get the value for the metrics that cannot be measured directly.

For estimating, models are needed. A model is a relationship of the predicted

variable that other variables that can be measured i.e. if there is some metrics of
interest which cannot be measured directly, then we build models to estimate the
metrics value based on the value of some other metrics that we can measure. The
model may be determined based on empirical data or it may be analytic. Building a
model is an issue that concerns process management.

Basic Principle of Design

Problem partitioning and hierarchy: When solving a small problem, the

entire problem can be tackled at once. The complexity of large problem and
the limitation of human minds do not allow a large problem to be treated as
huge monoliths. For large problem solving basic principle is divided into
smaller pieces so that each piece can be conquered separately. For s/w
design, therefore, the goal is to divide the problem into manageably small
piece that can be solved separately. It is this restriction of being able to solve
each part separately that makes dividing into pieces a complex task that
many methodologies for the system design aim to address. Basic strategy
behind this is that if the pieces of a problem are solvable separately, the cost
of solving the entire problem is more than the sum of the cost of solving all
pieces. However, the different pieces cannot be entirely independent of each
other as they together form the system. The different pieces have to cooperate and communicate to solve the larger problem. This communication
adds complexity, which arises due to partitioning and may not have existed
in the original problem. As the number of components increase, the cost of
partitioning together with cost of this added complexity may become more
than the saving achieved by partitioning. If a module A is independent of
module B then we can modify A without introducing any unanticipated side
effects in B. Total independence of modules of one system is not possible, but
the design process should support as much independence as possible
between modules. Problem partitioning, which is essential for solving a
complex problem leads to hierarchies in design.
Abstraction: It is powerful concept and is used in all engineering disciplines.
It is total that permits a designer to consider a component at an abstract
level without worrying about the details of the implementation of the
component. It describes the external behavior of that component without
bothering with the internal details of the implementation of the component. It
describes the external behavior of the component without bothering the
internal details that produce that behavior. It is essential for problem
partitioning. Partitioning is the exercise in determining the component of
system. Their component are not isolated from each other, designer has to
specify how a component interact with other component. If the designer has
to understand the details of the other component to determine their external
behavior, the purpose of partitioning and isolating a component from other
stands defeated. To allow the designer to concentrate on one component at a
time, abstraction of other component is used. Abstraction is used for existing
component as well as component that are being designed. It plays an

important role in the maintenance phase. To modify a system, the first step is
to understand what the system does and how. Using abstraction the behavior
of the entire system can be understood. During the design process,
abstraction is used in reverse manner than in the process of understanding a
system.
There are two abstraction mechanisms for s/w systems::
Functional Abstraction:: A module is specified by the function it
performs.
Eg.->A module to compute the log of a value
can be abstractly represented by the function log. Similarly, a module
to sort an input array can be represented by the specification of
sorting. It is the basis of partitioning in function oriented approach.
When the problem is being partitioned, the overall transformation
function for the system is partitioned into smaller function that
comprises the system function.
Data Abstraction:: Operations are required from a data object,
depending on the object and the environment in which it is used.

Modularity: Real power of partitioning comes if a system is partitioned into modules

so that modules are solvable and modifiable separately. It will be even better if the
modules are also separately ` compactable. A system is considered modular if it
consists of discreet components so that each component has minimal impact on
other component.
Modularity helps in system debugging- isolating the system problem to a
component is easier if the system is modular, in system repair changing a part of
system is easy.
For modularity, each module need to support a well defined abstraction and have a
class interface through which it can interact with other module.

Top-Down and Bottom-Up Strategies

A system consists of component. It is hierarchy of components. To design such a
hierarchy there are two possible approach::

Top-Down:: It starts from highest level component of the hierarchy and

proceeds through the lower level. It starts by identifying the major
components of the system, decomposing them into lower level components
until the desired level of details is achieved. This method often results in
some form of stepwise refinement. Starting from abstract design, in each
step the design is refined to more concrete level, until a level where no more

refinement is needed is reached and the design can be implemented directly.

It is suitable only if the specification of system is clearly known.
Bottom-Up:: It starts with the lowest level component of the hierarchy and
proceeds through progressively higher level to top level components. It starts
with designing the most basic components and proceeds to higher level
components that use these lower level components. This method works with
layer of abstraction. It is more useful when a system is to be built from an
existing system.

Definition of system/software design

Design is a meaningful representation of something that is to be built.

It can be traced to a customers requirements and at the same time

assessed for quality against a set of predefined criteria for good design.

According to Stevens:Software Design is the process of inventing and

selecting programs that meet the objectives for software systems.

Input includes an understanding of the following:

Requirement

Environmental constraints

Design criteria

Output of the design effort is composed of the following:

Architecture design

Specification

Definitions

Design Objectives/Properties

Correctness :should be correct and satisfy the requirement of the system.

Verifiability: it should be verified for correctness.

Completeness: all the relevant data structure modules, external interfaces

and module interconnections are specified.

Traceability: the entire design element must be traceable to the

requirements.

Efficiency: is concerned with the proper use of scarce resources.

Simplicity: The most important criteria is the quality of software system.

Design Principles
1. Problem partitioning: large problem can be solved ,the basic principle is
time-tested principle of Divide and Conquer. It can be divided into two
categories:

Horizontal Partitioning

Vertical Partitioning

Horizontal partitioning
It defines separate branches of modular hierarchy for each major
program function.
Software that is easier to test.
Software that is easier to maintain.
Software that is easier to extend.
Propagation of fewer side effects.

Vertical partitioning

Vertical partitioning: also called factoring, suggests that control and

work should be distributed from top-down in the program me structure.

Coupling :

Coupling is a measure of interconnection among modules in a

software structure.

The coupling between two modules indicates the degree of interdependence

between them.

Highly Coupled: When the modules are highly dependent on each other
then they are called highly-coupled.

Loosely Coupled:When the modules are depend on each other but the
interconnection among them is weak.

Uncoupled:When the different modules have no interconnection among

them.

Factors affecting Coupling

The various factors affecting coupling between modules are as follows:

Interface
Type of
Type of
Complexity Connection Communicatio
n
Low

Simple
Obvious

High

Complicated To internal
Obscure
elements

Types of Coupling

To module
by name

Data
Control Hybrid

Data Coupling

Best

Stamp Coupling
Control Coupling
External Coupling
Common Coupling
Content Coupling

(Worst)

Data Coupling: Two modules are data coupled ,if they communicate using
an elementary data item that is passed as a parameter between the two.

Stamp Coupling: Two modules are stamp copled, if they communicate

using a composite data item such a record, structure, object etc.
When module passes non-global data structure or entire structure to
another module,they are said to be stamp coupled.

Control Coupling: exist between two modules, if data from one module is
used to direct the order of instruction execution in another.

 External Coupling: It occurs when module are tired to an environment

external to software.It is essential but should be limited to a small number of
modules with structure.
Common Coupling: Two modules are common coupled, if they share some
global data items.

Content Coupling: exist between two modules,if their code is shared,it

means when one module directly refer to the inner workings of another
module.

Cohesion
Cohesion is a natural extension of information hiding concept.
Cohesion I s a measure of the relative functional strength of a module.
A cohesive module performs a single task within a software procedure
,requiring little interaction with procedures being performed in other parts of
a program.
A strongly cohesive module implements functionality that is related to one
feature of the solution and requires little or no interaction with other module.
This is shown in diagram.in the next slide..
Cohesion-strength

Types of cohesion
Functional Cohesion
Sequential Cohesion
Communicational Cohesion
Procedural Cohesion
Temporal Cohesion

Best(High)

Logical Cohesion
Coincidental Cohesion

Worst (low)

Functional Cohesion:
It is said to exit if different elements of a module cooperate to achieve a
single function .
FUNCTION A Part 1
FUNCTION A Part 2
FUNCTION A Part 3

Sequential cohesion
A module is said to possess sequential cohesion, if the element of a module
form the parts of a sequence ,where the output from one element of the
sequence is input to the next.
FUNCTION

FUNCTION

FUNCTION

Communicational Cohesion:

 All the functions of the module refer to or update the same data structure.

Procedural Cohesion
All the set of function of the module are all part of a procedure in which
certain sequence of steps has to be carried out for achieving an objective.

FUNCTION A

FUNCTION B

FUNCTION C

Temporal Cohesion:

 When a module contains functions that are related by the fact that all the
functions must be executed in the same time span is said to be exhibit
temporal cohesion.
TIME

TO

TIME TO+A
TIME TO+2A

Logical cohesion
All elements of the module perform similar operation.

Coincidental Cohesion
It performs a set of task that relate to each other very loosely.
The module contains a random collection of function.

Functional Versus object-oriented approach

Functional Approach
1. The basic abstraction which are
given to the user are real world
functions
For Example:
sort,merge,track,display,etc

Object oriented Approach

1. The basic abstraction are not the
real world functions but the data
abstraction where the real world
entities are represented .
For example picture, machine, radar
system, customer, student, employee,
etc. e:

2.Functions are grouped together by

which a higher level function is
obtained.
For example: SA/SD

2.The function are grouped together on

the basis of data they operate on like in
class person,function display are made
member function to operate on its data
members .
For Example: person name, age

In this approach ,the state information is

often represented in a centralized shared
memory .

3. In this approach, the state information

is not represented in a centralized
shared memory but is implemented
/distributed among the object s of the
system.

Design Specification :

It address different aspect of design model and is completed as the designer

refines his representation of the software .

Data Design:-Which includes data structure , any external file

structures, and a cross reference that connects data objects to specific
files are all defined .

Architectural Design :-indicates how the program architecture has been

derived from any model .Structure chart are used to represent a
module hierarchy.

Interface Design:-indicates the design of external and internal program

interfaces along with a detailed design of the human/machine interface is
described.

Procedural Design:-specifies components separately addressable elements

of software such as subroutines, function or procedures in form of english
language processing narratives.

Requirements of Design Specification :

The purpose of the cross-reference is:

To establish that all requirements are satisfied by the software design.

To indicate which components are critical to the implementation of
specific requirements.
System Objective:
System Objective

Human-machine interface

Major Software requirements design

Specification and design

Constraints, limitation

External interface design

Data design

Interfaces to external/system

Data object and resultant data

Internal design rule

Structure

Processing narrative

File and database structures

Interface description

External file structure

Design language description

Logical Structure

Modules used

Access method

Data structures used

Global data

Comments

File and data cross-reference

Requirement cross-reference

Verification for design

The output of the system design phase, like the output of the other phases in
the development process , should be verified before proceedings with the
activities of the next phase .
There are two approaches to verification .
-behavior of the product to see whether the product performs as
expected .
-analyzing the product.
Monitoring and Control for Design
It specifies what are needed to meet the cost ,quality and schedule
objectives.
Monitoring obtain information from development process and exerts the
required control over it.
Diagram of Phases of project Management

They check sensors providing information about the system s environment

and take action depending on the sensors reading.

It takes action when some exceptional sensor value is detected.

Control system continuously control hardware actuators depending on the

value of associated sensors.

When a sensor detects the presence of an intruder, the system automatically

calls the local police and, using a voice synthesizer, reports the location of
the alarm.

For Example,
A burglar alarm system is to be implemented for a building. This uses several
different types of sensor. These include movement detectors in individual
rooms, window sensors on ground floor windows, which detect if a window
has been broken, and door sensors, which detects door opening on corridor
doors . There are fifty window sensors, 30 doors sensors and 200 movement
detectors in the system.

Component level design::

Also called procedural design.
It occurs after DATA, ARCHITECTURAL and INTERFACE designs have been
established.
The intent is to translate the design model into operational software
It is possible to represent the component level design using a programming
language.
Since the level of abstraction of the existing design model is relatively high
while that of operational program is low, so the translation can be challenging
and cause subtle errors that may be difficult to find and correct at later
stages of software process.
The program is hence created using design model as a guide.
Alternatively, the procedural design can be represented using some
intermediate representations (eg. graphical, tabular or text based) that can
be easily translated into source code
Work product: The procedural design for each component, represented in
graphical, tabular or text based notation is primary work product produced during
component level design
How to ensure that design is accurate?
A design walkthrough or inspection is conducted. The design is examined to
determine whether data-structures, interfaces, processing sequences and logical
conditions are correct and will produce the appropriate data or control
transformation allocated to the component during earlier design steps.

Structured Programming:
What are Constructs?

In 1960 Dijkstra proposed the use of a set of constrained logical CONSTRUCTS

from which any program can be formed.
The constructs emphasized maintenance of functional domain.
Each construct has a predictable logical structure, was entered at the top and
exited at the bottom, enabling the reader to follow the procedural flow more
easily.
Fundamental Constructs for Structural Programming
The constructs are sequence, condition and repetition
Sequence implements processing steps that are essential in the specification
of any algorithm.
Condition provides the facility for selected processing based on some logical
occurrence.
Repetition allows for looping
The structured constructs were proposed to limit the procedural design of
software to a small number of predictable operations.
The structured constructs are logical chunks that allow a reader to recognize
procedural elements of a module, rather than reading the design or code line
by line.
Understanding is enhanced when readily recognizable logical patterns are
encountered.
GRAPHICAL DESIGN NOTATION:
Graphical tools, such as the flowchart or box diagram, provide useful pictorial
patterns that readily depict procedural detail.
However, if graphical tools are misused, the wrong picture may lead to the
wrong software.
Flowchart
Sequence is represented as two processing boxes connected by a line of
control.
Condition is depicted as a decision diamond that if true, causes then-pat
processing to occur and if false, invokes else part processing.
Repetition is represented using two slightly different forms:

The do-while tests a condition and executes a loop task repetitively as

long as the condition holds true.
A repeat until executes the loop task first, then tests the condition and
repeats the task until the condition fails.
The structured constructs may be nested with in on another
Sequence

If-Then-Else

SELECTION

REPETITION

The dogmatic use of only the structured constructs can introduce inefficiency
when an escape from a set of nested loop or nested conditions is required
The designer is hence left with two options:
Procedural representation is redesigned so that the escape branch is
not required at a nested location in a flow of control
The structured constructs are violated in a controlled manner ie. A
constrained branch out of the nested flow is designed.
Option 1 is the ideal approach but option 2 can be accommodated without
violating the spirit of structured programming
Box Diagram
It evolved from a desire to develop a procedural design representation that
would not allow violation of the structured constructs.
Also called Nassi-Shneiderman charts, N-S charts or Chapin charts
Characteristics of Box Diagram
Functional domain (ie. the scope of repetition or if-then-else ) is well defined
and clearly visible as a pictorial representation
Arbitrary transfer of control is impossible

The scope of local and/or global data can be easily determined

Recursion is easy to represent
Sequence

If-Then-Else

Repetition

SELECTION

The fundamental element of the diagram is a box

To represent a sequence, two boxes are connected bottom to top
To represent if-then-else a condition box is followed by a then-part and elsepart box
Repetition is depicted with a bounding pattern that encloses the process (dowhile part or repeat-until part) to be repeated
Selection is represented using the graphical form
Like flowchart, a box diagram is layered on multiple pages as processing
elements are refined
TABULAR DESIGN NOTATION
In many s/w applications, a module may be required to evaluate a complex
combination of conditions and select appropriate actions based on these
conditions.
Decision tables provide a notation that translates actions and conditions into
tabular form
The table is difficult to misinterpret and may even be used as machine
readable input to a table driven algorithm
The decision table can be effectively used to supplement other procedural
design notation
STEPS TO DEVELOP A DECISION TABLE

List all actions that can be associated with a specific procedure (or module)
List all conditions (or decision made) during execution of the procedure
Associate specific sets of conditions with specific actions, eliminating
impossible combinations of conditions; alternatively, develop every possible
permutation of conditions
Define rules by indicating what action(s) occurs for a set of conditions
PROGRAM DESIGN LANGUAGE (PDL)
Also called structured English or pseudocode
Is a pidgin language in that it uses the vocabulary of one language (ie.
English) and the overall syntax of another (ie. a structured programming
language)
The PDL is different from a real programming language in the sense that it
uses the narrative text embedded directly within PDL structure
The PDL cannot thus be compiled (not yet)
PDL tools exist to translate PDL into a programming language skeleton
and/or a graphical representation (eg. a flowchart) of design.
These tools also produce nesting maps, a design operation index, cross
reference tables and a variety of other information
COMPARISION OF DESIGN NOTATION
Design notation should lead to a procedural representation that is easy to
understand and review.
The notation should enhance code to ability so that code becomes a natural
by-product of design
Design representation must be easily maintainable so that design always
represents the program correctly
Attributes of Design Notation
Modularity: Design notation should support the development of modular s/w
and provide a means for interface specification
Overall Simplicity: Design notations should be relatively simple to learn,
relatively easy to use and generally easy to learn

Ease of editing: The procedural design may require modification as the s/w
process proceeds. The ease with which a design representation can be edited
can help facilitate each s/w engineering task
Machine Readability: Notation that can be input directly into a computer
based development system offers significant benefits.
Maintainability: S/w maintenance is the most costly phase of the s/w life
cycle. Maintenance of the s/w configuration nearly always means
maintenance of procedural design representation.
Structural Enforcement: Design notations that enforce the use of only the
structured constructs promotes good practice.
Automatic Processing: A procedural design contains information that can
be processed to give designer new or better insights into the correctness and
quality of a design. Such insights can be enhanced with reports provided via
s/w design tools
Data Representation: The ability to represent local and global data is an
essential element of component level design. Ideally, design notation should
represent such data directly.
Logic Verification: Automatic verification of design logic is a goal that is
paramount during s/w testing. Notation that enhances the ability to verify
logic greatly improves testing adequacy.
FOURTH GENERATION TECHNIQUES: 4GT
INTRODUCTION

The term 4Gt encompasses a broad array of s/w tools that have one thing
in common.
Each tool enables the s/w engineer to specify the characteristics of s/w at
high level.
The tool then automatically generates source code based on the
developers specification.
The 4GT paradigm for s/w engineering focuses on the ability to specify s/w
using specialized language forms or a graphic notation that describes the
problem to be solved in terms that the customer can understand.

S/W ENVIRONMENT THAT SUPPORT 4GT

Non-procedural languages for database query

Report generation
Data manipulation
Screen interaction and definition

Code generation of HTML and similar languages used for web-site creation
using advanced s/w tools

MORE ABOUT 4GT

Modern 4GT environments have been extended to address most s/w

application categories
4Gt begins with a requirement gathering step
For small applications it may be possible to move directly from
requirements gathering step to implementation using a non-procedural
4GL or a model composed of graphical icons
For larger efforts it is necessary to develop a design strategy for the
system
The use of 4GT without design (for large projects) will cause the same
difficulties (poor quality, poor maintainability, poor customer acceptance)
Implementation using a 4GL enables the s/w developer to represent
desired results in a manner that leads to automatic generation of code to
create those results
To transform a 4GL implementation into a product, the developer must
conduct thorough testing, develop meaningful documentation and
perform all other solution integration activities that are required in other
s/w engineering paradigms

ADVANTAGES

The use of 4GT is a viable approach for many different application areas.
Coupled with computer-aided s/w engineering tools and code generators,
4GT offers a credible solution to many s/w problems
Data collected from companies that use 4GT indicate that the time
required to produce s/w is greatly reduced for small and intermediate
applications that the amount of design and analysis for small applications
is also reduced

DISADVANTAGE

The use of 4GT for large s/w development efforts demands as much or
more analysis, design and testing (s/w engineering activities) to achieve
substantial time savings that result from the elimination of coding

Unit-2

Questions asked in UPTU Examinations

2006-07
Attempt any 4 parts:

(a) What are the primary differences between a model oriented specification
method and a property-oriented specification method?
(b) Enumerate the different types of coupling that might exist between two
modules
(c) What do you understand by layered software design? What are advantages of
layered design?
(d) What do you mean by balancing a DFD? Illustrate your answer with a suitable
example.
(e) What is the significance of Design Reviews? Make a list of items that can be
used as a checklist for carrying out design reviews.
(f) What do you understand by term encapsulation in the context of software
design? How does data abstraction help in reducing the coupling in design
solution?

2007-08
Attempt any 4 parts:

(a) Draw data flow diagram for library management system. Clearly describe the
working of the system.
(b) Describe spiral model in detail. What are the limitations of such a model?
(c) What is software development life cycle? Discuss the generic waterfall model.
(d) List advantages of software requirement specification. Describe the desirable
characteristics of a good software requirement specification.
(e) Explain various types of coupling and define module coupling.

2008-09
Attempt any 2 parts:

(a) What do you mean by functional requirements, non-functional requirements

and domain requirements? List the above various requirements for any
hospital.
(b) Write short notes on the following:
(i)

Coupling and cohesion

(ii)

Top-down and bottom-up design

(c) Define the following:

(i)

Software architecture

(ii)

Fourth generation techniques for software design