Module II

Software Requirements Analysis and Design

Module-2
1
S/w Requirements and Design
 Requirement Analysis and
Specification
• The requirement analysis and
specification is the sequence of
activities that need to be performed in
the requirements phase and that result
in producing a high-quality document
containing the SRS.

Module-2
2
S/w Requirements and Design
Requirement Analysis and Specification

• Requirements analysis and specification

phase mainly involves carrying out the
following two important activities:

1. Requirements gathering and analysis

2. Requirements specification

Module-2
3
S/w Requirements and Design
1. Requirement Gathering And Analysis

• The requirements have to be gathered by the analyst

from several sources in bits and pieces.

• These gathered requirements need to be analysed to

remove several types of problems that frequently
occur in the requirements that have been gathered
piecemeal from different sources.

Module-2
4
S/w Requirements and Design
 Requirements Gathering

• The primary objective of the requirements

gathering task is to collect the requirements
from the stakeholders.
• A stakeholder is a source of the requirements
and is usually a person, or a group of persons
who either directly or indirectly are concerned
with the software.

Module-2
5
S/w Requirements and Design
 Requirements Gathering

• It is very difficult to gather all the necessary

information from a large number of
stakeholders and from information scattered
across several pieces of documents.
• The important ways in which an experienced
analyst gathers requirements like studying
existing documentation, interview etc
• Example: req-gathering.docx

Module-2
6
S/w Requirements and Design
 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 find out any
problems in the gathered requirements

Module-2
7
S/w Requirements and Design
 Requirements Analysis
• During requirements analysis, the analyst needs to
identify and resolve three main types of problems in
the requirements:
• Anomaly - ambiguity in a requirement
• Inconsistency - Two requirements are said to be
inconsistent, if one of the requirements contradicts
the other .
• Incompleteness - An incomplete set of requirements is
one in which some requirements have been
overlooked.
Module-2
8
S/w Requirements and Design
 2. Requirements Specification
• 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 organize
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.
Module-2
9
S/w Requirements and Design
 Requirements Specification
SRS Validation
• Once the SRS document is ready, it is first reviewed
internally by the project team to ensure that it
accurately captures all the user requirements, and
that it is understandable, consistent, unambiguous,
and complete.
• The SRS document is then given to the customer for
review. After the customer has reviewed the SRS
document and agrees to it, it forms the basis for all
future development activities
Module-2
10
S/w Requirements and Design
 Characteristics of an SRS

• What should be the characteristics of a good SRS?

1. Correctness
2. Complete
3. Unambiguous
4. Verifiability
5. Consistent
6. Ranked for importance or stability

Module-2
11
S/w Requirements and Design
 Characteristics of an SRS
1. Correctness
– Each requirement accurately represents some
desired feature in the final system.
2. Completeness
– All desired features/characteristics should be
specified
– Completeness is hardest to satisfy.
– Completeness and correctness strongly related.
3. Unambiguous
– Each requirement has exactly one meaning.
– It is important as natural languages often used to
write requirements.
Module-2
12
S/w Requirements and Design
 Characteristics of an SRS
4. Verifiability
– There must exist a cost effective way of checking if
software satisfies requirements.
5. Consistent
– Two requirements don’t contradict each other.
6. Ranked for importance/stability
– Needed for prioritizing in construction
– To reduce risks due to changing requirements

Module-2
13
S/w Requirements and Design
 Components of an SRS

• Requirements in an SRS document is categorized

into two -
1. Functional requirements
2. Non functional requirements
 Performance requirements
 Design constraints
 External interfaces

Module-2
14
S/w Requirements and Design
 Functional Requirements
• Functional requirements specify the
expected behaviour of the system.

• The functional requirements capture the

functionalities required by the users from
the system

• Each function in the system produce

outputs from the given inputs.
Module-2
15
S/w Requirements and Design
Functional Requirements

Module-2
16
S/w Requirements and Design
Examples :
Q1) Identify functional requirement in ATM
transaction during withdrawal of money
from an ATM.
function- With draw cash
(input: card no, PIN)
(output: cash)
optional function- Print the receipt

Module-2
17
S/w Requirements and Design
• 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 followings— 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.

Module-2
18
S/w Requirements and Design
Q2) Identify functional requirement in a library automation
software be

Functions:
1. Add a new book.
2. Delete an existing book.
3. Update an existing book details.
4. Search a book.

Module-2
19
S/w Requirements and Design
 Non functional Requirements
1. Performance Requirements
• The performance requirements in of an SRS
specifies constraints to increase the
performance of the software system.

• There are two types of performance

requirements based on constraints on
execution behaviour of software :
1. Static
2. Dynamic.
Module-2
20
S/w Requirements and Design
 1. Static Performance Requirements
• Static requirements are requirements that do not
impose constraint on the execution behaviour of
the software
• Eg:
• number of terminals to be supported
• number of simultaneous users to be supported, and the
number of files that the software has to process and their
sizes.
• These are also called capacity requirements of
the system.
Module-2
21
S/w Requirements and Design
2. Dynamic Performance Requirements
• Dynamic requirements specify constraints on the
execution behavior of the system.
• Eg: These typically include response time and
throughput constraints on the system.
• Response time is the expected time for the
completion of an operation under specified
circumstances.
• Throughput is the expected number of
operations that can be performed in a unit time.
Module-2
22
S/w Requirements and Design
 2. Design Constraints
• They are factors in the client environment
that restrict the options available to the
developers.
• Eg:
– Standard compliance and compatibility with other
systems (compatibility with operating system)
– Hardware Limitations
– Reliability, fault tolerance, backup requirement.
– Security

Module-2
23
S/w Requirements and Design
 3. External Interface
• All interactions of the software with people, hardware,
and other software.

• Examples of external interfaces are— hardware, software

and communication interfaces, user interfaces, report
formats, etc.

• A preliminary user manual should be created with all user

commands, screen formats, an explanation of how the
system will appear to the user, and feedback and error
messages
Module-2
24
S/w Requirements and Design
 Structure of an SRS
The standardization of the SRS was done by IEEE.

• Introduction
– Purpose , the basic objective of the system
– Scope of what the system is to do , not to do
– Overview
• Overall description
– Product perspective
– Product functions
– User characteristics
– Assumptions
– Constraints
Module-2
25
S/w Requirements and Design
 Structure of an SRS
• Specific requirements
– External interfaces
– Functional requirements
– Performance requirements
– Design constraints
• Acceptable criteria
– desirable to specify this up front.

Module-2
26
S/w Requirements and Design
 Software Design
• The activities carried out during the design
phase (called as design process ) transform the
SRS document into the design document.

Module-2
27
S/w Requirements and Design
 Classification of Design Activities
The design activity is classified into three levels or
stages.
1. Architectural Design - The architectural design is the highest
abstract version of the system. It identifies the software as a
system with many software components interacting with each
other.
2. High-level (Preliminary )Design- High-level design focuses on
how the system along with all of its components can be
implemented in forms of modules. The outcome of high-level
design is called the program structure or the software
architecture.
3. Detailed Design- Detailed design defines logical structure of
each module and their interfaces to communicate with other
modules.

Module-2
28
S/w Requirements and Design
 Characteristics of a good Software Design
1. Correctness: A good design should first of all be correct. That is,
it should correctly implement all the functionalities of the
system.
2. Understandability: A good design should be easily
understandable. Unless a design solution is easily
understandable, it would be difficult to implement and maintain
it.
3. Efficiency: A good design solution should adequately address
resource, time, and cost optimisation issues.
4. Maintainability: A good design should be easy to change. This is
an important requirement, since change requests usually keep
coming from the customer even after product release.
Module-2
29
S/w Requirements and Design
 Design Concepts

1. Modularization

• Modularization is a technique to divide a

problem into several independent
modules.

• Each module is expected to carrying out

task independently.

Module-2
30
S/w Requirements and Design
 1. Modularization

Modular and Poor Modularity and

hierarchical design hierarchy

Module-2
31
S/w Requirements and Design
 2. Coupling
• Coupling is a measure that defines the
level of inter-dependability among
modules of a software.

Module-2
32
S/w Requirements and Design
 2. Coupling
• It tells at what level the modules interfere and
interact with each other.

• The lower the coupling, the better the

software.

Module-2
33
S/w Requirements and Design
 Coupling
• High coupling means that two modules are
too interrelated, which can make maintaining
the system very difficult.
• Low coupling means that changes in one
module never or rarely make change in the
other module.

Module-2
34
S/w Requirements and Design
Five levels of coupling
Coupling
rate
High

Low

Module-2
35
S/w Requirements and Design
 Content coupling
When a module can directly access or
modify or refer to the content of another
module, it is called content level coupling.

Eg. a jump from one module into the code of

another module can occur .

M2
M1

Module-2
36
S/w Requirements and Design
 Common coupling
When multiple modules have read and
write access to some global data, it is called
common or global coupling.

Module-2
37
S/w Requirements and Design
Module-2
38
S/w Requirements and Design
 Control coupling
Two modules are called control-coupled if one
of them decides the function of the other
module or changes its flow of execution.
Control coupling exists between two modules, if
data from one module is used to direct the
order of instruction execution in another
module.
An example of control coupling is a flag set in
one module and tested in another module.
Module-2
39
S/w Requirements and Design
 Stamp coupling
Two modules are stamp coupled, if they
communicate using a composite data item.

Eg: a data item like structure in C.

Module-2
40
S/w Requirements and Design
 Data coupling
Two modules are data coupled, if they
communicate using an elementary data item
that is passed as a parameter between the
two modules

Eg. an integer or a character or floating point

number.

Module-2
41
S/w Requirements and Design
Data coupling

Module-2
42
S/w Requirements and Design
 3. Cohesion
• Cohesion is a measure that defines the degree
of intra-dependability within elements of a
module

• High cohesion is the goal of good design.

Module-2
43
S/w Requirements and Design
 3. Cohesion
• Cohesion and coupling are interrelated

• Greater cohesion of modules, lower coupling

between module.

Module-2
44
S/w Requirements and Design
In the above diagram, overlapping functions represent a high
cohesion, hence 'module 1' and 'module 3' will be termed
as 'highly cohesive' modules in contrast with 'module 2'
which has less cohesive elements.

Module-2
45
S/w Requirements and Design
Levels (Types) of Cohesion

Module-2
46
S/w Requirements and Design
 Co-incidental cohesion
• It is unplanned and random cohesion,
which might be the result of breaking the
program into smaller modules for the sake of
modularization.

• Eg: consider a module carry out different

and unrelated activities like issuing of library
books, creating library member records,
librarian leave request.
Module-2
47
S/w Requirements and Design
 Logical cohesion
When logically categorized elements are
put together into a module, it is called logical
cohesion.

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

Module-2
48
S/w Requirements and Design
 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.

Eg: Consider a module performs tasks like

initialisation of memory and devices, loading the
operating system, etc.(When a computer is
booted, these functions need to be performed)
Module-2
49
S/w Requirements and Design
 Procedural cohesion
• When elements of module are grouped
together, which are executed sequentially in
order to perform a task, it is called procedural
cohesion.
• Eg: Consider the activities associated with
order processing in a trading house. A module
perform functions like login(), place-order(),
check-order(), printbill(), place-order-on-
vendor(), update-inventory(), and logout()
Module-2
50
S/w Requirements and Design
 Communicational cohesion
When elements of module are grouped
together, which are executed sequentially and
work on same data (information), it is called
communicational cohesion.
Eg: 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.

Module-2
51
S/w Requirements and Design
 Sequential cohesion
• When elements of module are grouped
such that the output of one element serves as
input to another and so on, it is called
sequential cohesion.

Module-2
52
S/w Requirements and Design
 Functional cohesion
• A module is said to possess functional
cohesion, if different functions of the module
co-operate to complete a single task.

• Eg: Consider a module containing all the

functions required to manage employees’ pay-
roll displays functional cohesion.

Module-2
53
S/w Requirements and Design
 Differentiate between Coupling and Cohesion

Coupling Cohesion

1. Coupling is also called Inter- 1. Cohesion is also called Intra-Module

Module Binding. Binding.
2. Coupling shows the relationships 2. Cohesion shows the relationship within
between modules. the module.
3. Coupling shows the
relative independence between 3. Cohesion shows the module's
the modules. relative functional strength.
4. While creating a design , you
should aim for low coupling.
4. While creating a design ,you should aim
5. In coupling, modules are linked
for high cohesion,
to the other modules.
5. In cohesion, the module focuses on a
single task.

Module-2
54
S/w Requirements and Design
Coupling and Cohesion

Module-2
55
S/w Requirements and Design
 Design Approaches
There are two approaches used for software
design.

1. Function Oriented Design (FOD)

2. Object Oriented Design (OOD)

Module-2
56
S/w Requirements and Design
 Function Oriented Design (FOD)

• In function-oriented design, the system is comprised

of many smaller sub-systems known as functions.
• These functions are capable of performing significant
task in the system.
• The system is considered as top view of all functions.
• Function oriented design inherits some properties of
structured design where divide and conquer
methodology is used.

Module-2
57
S/w Requirements and Design
 FOD Design Tools
1. Structure Charts
• Every program has a structure
• Structure Chart - graphic representation of
structure
• SC represents modules and interconnections
• Each module is represented by a box
• If A invokes B, an arrow is drawn from A to B
• Arrows are labeled by data items
• Different types of modules in a SC
• Input, output, transform and coordinate modules
• A module may be a composite
Module-2
58
S/w Requirements and Design
SC of a Average Program

Module-2
59
S/w Requirements and Design
 2. Data flow diagrams
• Data flow diagrams (also called data flow graphs)
are commonly used during problem analysis.
• A DFD shows flow of data through the system
– Data flow diagram is a graphical representation
of data flow in an information system.
– It is capable of showing incoming data flow,
outgoing data flow and stored data.
– DFD is not a flowchart.

Module-2
60
S/w Requirements and Design
DFD Components

Module-2
61
S/w Requirements and Design
 Example:

Module-2
62
S/w Requirements and Design
• Entities - Entities are source and destination of
information data. Entities are represented by
rectangles with their respective names.
• Process - Activities and action taken on the data
are represented by Circle.
• Data Storage - There are two variants of data
storage - it can either be represented as a rectangle
with absence of both smaller sides or as an open-
sided rectangle with only one side missing.
• Data Flow - Movement of data is shown by pointed
arrows.

Module-2
63
S/w Requirements and Design
2. Object Oriented Design (OOD)
– Objects - All entities involved in the solution design
are known as objects. For example, person, banks,
company and customers are treated as objects.
Every entity has some attributes associated to it and
has some methods to perform on the attributes.
– Classes - A class is a generalized description of an
object. An object is an instance of a class. Class
defines all the attributes, which an object can have
and methods, which defines the functionality of the
object.

Module-2
64
S/w Requirements and Design
 – Encapsulation - In OOD, the attributes (data variables)
and methods (operation on the data) are bundled
together is called encapsulation. Encapsulation not only
bundles important information of an object together,
but also restricts access of the data and methods from
the outside world. This is called information hiding.
•  
– Inheritance - OOD allows similar classes to stack up in
hierarchical manner where the lower or sub-classes can
import, implement and re-use allowed variables and
methods from their immediate super classes. This
property of OOD is known as inheritance. This makes it
easier to define specific class and to create generalized
classes from specific ones.

Module-2
65
S/w Requirements and Design
– Polymorphism - OOD languages provide a mechanism
where methods performing similar tasks but vary in
arguments, can be assigned same name. This is called
polymorphism, which allows a single interface
performing tasks for different types. Depending upon
how the function is invoked, respective portion of the
code gets executed.

Module-2
66
S/w Requirements and Design
 OOD Tools
1. Unified Modeling Language (UML)

• UML is a graphical notation useful for OO analysis

and design
• Allows representing various aspects of the system
• Various notations are used to build different models
for the system.
• Class Diagrams is a diagram in UML

Module-2
67
S/w Requirements and Design
 Class Diagrams
• Classes are the basic building blocks of an OO system
as classes are the implementation units also
• Class diagram is the central piece in an OO design. It
specifies
– Classes in the system
– Association between classes
– Subtype, supertype relationship

Module-2
68
S/w Requirements and Design
 Class Diagram…
• Class itself represented as a box with name,
attributes, and methods
• There are conventions for naming
• If a class is an interface, this can be specified
by <<interface>> stereotype
• Properties of attr/methods can be specified by
tags between { }

Module-2
69
S/w Requirements and Design
Class – example

Module-2
70
S/w Requirements and Design
 Metrics
• Basic purpose to provide a quantitative evaluation of
the design (so the final product can be better)

Module-2
71
S/w Requirements and Design
 Metrics in FOD
1. Network Metrics
• Focus on structure chart; a good SC is considered as
one with each module having one caller (reduces
coupling)
• The more the SC deviates from a tree, the more
impure it is
Graph impurity = n – e – 1
n – nodes, e- edges in the graph
• Impurity of 0 means tree; as this no increases, the
impurity increases

Module-2
72
S/w Requirements and Design
 2. Information Flow Metrics
• Complexity of a module is viewed as depending on
intra-module complexity
• Intramodule estimated by module size and the
information flowing
– Size in LOC (line of code)
– Inflow – info flowing in the module
– Outflow – info flowing out of the module
• Dc = size * (inflow * outflow)2

Module-2
73
S/w Requirements and Design
 Metrics for OOD
1. Weighted methods per class
– Complexity of a class depends on no of classes and
their complexity
– Suppose complexity of methods is c1, c2..; by
some functional complexity metric

WMC = Σ ci
– Large WMC might mean that the class is more
fault-prone

Module-2
74
S/w Requirements and Design
2. Depth of Inheritance Tree

– DIT of C is depth from the root class

– Length of the path from root to C
– DIT is significant in predicting fault proneness

Module-2
75
S/w Requirements and Design
3. Coupling between classes (CBC)

– No of classes to which this class is coupled

– Two classes are coupled if methods of one use
methods or attr of other
– Can be determined from code

Module-2
76
S/w Requirements and Design
 Metrics…
4. Response for a class (RFC)

– The total no of methods that can be invoked from

this class
– Captures the strength of connections

Module-2
77
S/w Requirements and Design
 Software Architecture

• The software architecture is the structure or

structures of the software system
– software elements
– externally visible properties of those elements
– relationships.

Module-2
78
S/w Requirements and Design
 Elements

• A software architecture is defined by a

configuration of architectural elements—
• Components – Eg: instruction to load data
from secondary storage
• Connectors – mechanism for communication.
• Data - information that is transferred from a
component, or received by a component

Module-2
79
S/w Requirements and Design
 component
• A component is an abstract unit of software instructions and
internal state that provides a transformation of data via its
interface.
• Example transformations include loading into memory from
secondary storage, performing some calculation, translating to
a different format, encapsulation with other data, etc. The
behavior of each component is part of the architecture insofar
as that behavior can be observed or discerned from the point
of view of another component. In other words, a component is
defined by its interface and the services it provides to other
components, rather than by its implementation behind the
interface.
Module-2
80
S/w Requirements and Design
 connector
• A connector is an abstract mechanism that mediates communication,
coordination, or cooperation among components. Examples include
shared representations, remote procedure calls, message-passing
protocols, and data streams.

• Connectors enable communication between components by

transferring data elements from one interface to another without
changing the data. Internally, a connector may consist of a subsystem
of components that transform the data for transfer, perform the
transfer, and then reverse the transformation for delivery. However,
the external behavioral abstraction captured by the architecture
ignores those details. In contrast, a component may, but not always
will, transform data from the external perspective.
Module-2
81
S/w Requirements and Design
 Datum (data)
• A datum is an element of information that is transferred from a
component, or received by a component, via a connector.
• Examples include byte-sequences, messages, marshalled
parameters, and serialized objects, but do not include
information that is permanently resident or hidden within a
component.
• From the architectural perspective, a "file" is a transformation
that a file system component might make from a "file name"
datum received on its interface to a sequence of bytes recorded
within an internally hidden storage system. Components can
also generate data, as in the case of a software encapsulation of
a clock or sensor.
Module-2
82
S/w Requirements and Design
 configuration
• A configuration is the structure of
architectural relationships among
components, connectors, and data during a
period of system run-time.

Module-2
83
S/w Requirements and Design
 Role of software architecture

1. Understanding and communication

– By showing a system at a high level and hiding
complexity of parts, architecture description
facilitates communication
– To get a common understanding between the diff
stakeholders (users, clients, architect, designer,…)
– For negotiation and agreement
– Architecture description can also aid in
understanding of existing systems

Module-2
84
S/w Requirements and Design
2. Reuse
– A method of reuse is to compose systems from
parts and reuse existing parts
– This model is facilitated by reusing components at
a high level providing complete services
– To reuse existing components, architecture must
be chosen such that these components fit
together with other components
– Hence, decision about using existing components
is made at arch design time

Module-2
85
S/w Requirements and Design
3. Construction and evolution
– Some structures in arch description will be used to
guide system development
– Partitioning at arch level can also be used for work
allocation to teams as parts are relatively
independent
– During software evolution, architecture helps
decide what needs to be changed to incorporate
the new changes/features
– Architecture can help decide what is the impact of
changes to existing components on others
Module-2
86
S/w Requirements and Design
4 Analysis
– If properties like performance, reliability can be
determined from design, alternatives can be
considered during design to reach the desired
performance levels
– Software architecture opens such possibilities for
software (other engg disciplines usually can do this)
– E.g. reliability and performance of a system can be
predicted from its arch, if estimates for parameters
like load etc is provided
– Will require precise description of arch, as well as
properties of the elements in the description

Module-2
87
S/w Requirements and Design
 Architectural Views
• There are different views of a software system.
• A view consists of elements and relationships
between them, and describes a structure.
• Commonly used architectural views are three types
1. Module
2. Component and Connector
3. Allocation

Module-2
88
S/w Requirements and Design
 Types of Architectural Views
1. Module view
– A system is a collection of elements or code
units.
– Eg: elements are modules, eg. Class, package,
function, procedure, etc
– Relationship between them is code based, e.g.
part of, depends on, calls, generalization-
specialization, etc

Module-2
89
S/w Requirements and Design
 Types of Architectural Views
2. Component and Connector (C&C)
– Elements are run time entities called components
– I.e. a component is a unit that has identity in
executing sys, e.g. objects, processes, .exe, .dll
– Connectors provide means of interaction between
components, e.g. pipes, shared memory, sockets

Module-2
90
S/w Requirements and Design
 Types of Architectural Views
3. Allocation view
– Focuses on how software units are allocated to
resources like hardware, file system, people etc
– It specifies relationship between software
elements and execution units in the environment
– Expose structural properties like which process
runs on which processor, which file resides where
etc

Module-2
91
S/w Requirements and Design
Module-2
92
S/w Requirements and Design
 Detailed Design
• High Level Design does not specify module logic;
this is done during detailed design
• During detailed design the pseudo code description
of the processing and the different data structures
are designed for the different modules of the
structure chart.
• These are usually described in the form of module
specifications (MSPEC).
• MSPEC is usually written using structured English.

Module-2
93
S/w Requirements and Design