GANPAT UNIVERSITY

U. V. PATEL COLLEGE OF ENGINEERING

2CEIT406
SOFTWARE ENGINEERING &
PROJECT MANAGEMENT
UNIT 2
REQUIREMENT MODELLING AND DESIGN

Prepared by: Prof. Ravi Raval (Asst. Prof in C.E Dept. , UVPCE)
Unit 2: Requirements Modeling and Design
Contents:
 Requirement Engineering – Crucial Steps
 Types of requirements
 Requirement Documentation (SRS)
 Nature of SRS
 Characteristics of a good SRS
 Structure of SRS Document
 Use case diagrams with guidelines
 Data Flow diagrams
 Software Design
 Modularity
 Function oriented Design
Unit 2: Requirements Modeling and Design
Requirement Engineering: managers, customers, end users),
where business need is defined, user
 The broad spectrum of tasks and
scenarios are described, functions
techniques that lead to an
and features are delineated, and
understanding of requirements is
project constraints are identified.
called requirements engineering.
 Others might suggest that it begins
 Requirements engineering builds a
with a broader system definition,
bridge to design and construction.
where software is but one
But where does the bridge originate?
component of the larger system
 One could argue that it begins at the domain.
feet of the project stakeholders (e.g.,
Unit 2: Requirements Modeling and Design
Requirement Engineering:  It encompasses seven distinct tasks:
 Requirements engineering provides 1) inception,
the appropriate mechanism for 2) elicitation,
understanding 3) elaboration,
 what the customer wants 4) negotiation,
 analyzing need
5) specification,
 assessing feasibility
 negotiating a reasonable solution, 6) validation, and
 specifying the solution unambiguously, 7) management
 validating the specification,
 and managing the requirements as they are
transformed into an operational system.
Unit 2: Requirements Modeling and Design
Requirement Engineering: when a business need is identified or
(1) Inception(આરંભ, શરૂઆત): How does a potential new market or service is
a software project get started? discovered.
 Is there a single event that becomes  Business mangers Stakeholders
- Do feasibility
the catalyst for a new computer-  Marketing people analysis
based system or product, OR  Product manager - Define business
 Does the need evolve over time? case
- Identify depth and
 In some cases, a casual conversation
breadth of the
is all that is needed to precipitate a market
major software engineering effort.
 But in general, most projects begin
Unit 2: Requirements Modeling and Design
Requirement Engineering:
(2) Elicitation(સ્પષ્ટતા): Ask customer
users and others what the objectives for
the product are:
 What is to be done?
 How solution fits to business?
 Problems you may encounter during
elicitation:
1) Problem of Scope: ill-defined
boundaries or unnecessary technical
details specified.
2) Problems of Understanding: When
customers/users are not sure what is
needed, have a poor understanding of
the capabilities and limitations of their
computing environment, don’t have a
full understanding of the problem
domain, have trouble communicating
needs to the system engineer, omit
information that is believed to be
“obvious,” specify requirements that
conflict with the needs of other
customers / users, or specify
requirements that are ambiguous or
untestable.
3) Problems of volatility: requirements
changes over time.
Unit 2: Requirements Modeling and Design
Requirement Engineering: limited business resources
(3) Elaboration: expand and refine the  It’s also relatively common for
information received during inception different customers or users to
and elicitation. propose conflicting requirements,
 Focuses on software function, arguing that their version is
behavior and information “essential for our special needs.”
 Develop scenarios – how the user  You need to negotiate the
will interact with the system. requirements in order to:
 Develop class diagrams  Rank requirements

(4) Negotiation: Customers/users ask  Discuss conflicts in priority

for more than can be achieved, given  Assess their cost and risk.
Unit 2: Requirements Modeling and Design
Requirement Engineering:
(5) Specification: A specification can be a written document, a set of graphical
models, a formal mathematical model, a collection of usage scenarios, a
prototype, or any combination of these.
Standard Template of SRS : suggestions
Table of Contents (Index) 4. Project scope
5. Reference
Revision History
2. Overall Description
1. Introduction
1. Product Perspective
1. Purpose
2. Product features
2. Document Conventions
3. User Classes and characteristics
3. Intended Audience and reading
Unit 2: Requirements Modeling and Design
Standard Template of SRS : 4. Communication interfaces
4. Operating environment 10. Other non-functional requirements
5. Design and implementation constraints 1. Performance requirement
6. User documents 2. Safety requirements
7. Assumptions and dependencies 3. Security requirements
8. System Features 4. Software quality attributes
1. System features 1 11. Other requirements
2. System features 2 (and so on)
9. External Interface requirements Appendix A: Glossary of terms
1. User Interfaces Appendix B: Analysis Models
2. Hardware interfaces
Appendix C: List of Issues
3. Software Interfaces
Unit 2: Requirements Modeling and Design
Requirement Engineering:  Missing info and / or inconsistencies
 Conflicting requirements / Unrealistic
(6) Validation: requirements
 All requirements stated
(7) Requirements management: is
unambiguously?
a set of activities that helps the
 All inconsistencies, omissions and error
detected / corrected?
project team to identify, control, and
track requirements and changes to
 Work product confirms the standard?
requirements anytime as the project
 Not check and verify that: proceeds.
 Errors in content / interpretation
 Areas where clarification still requires
Unit 2: Requirements Modeling and Design
Requirement Elicitation:  Get help if available currently working
model is exist.
 Also called “Requirements gathering”  Obtain input/output data formats and
 Who will do this task? → System operation process details.
Analyst  Visit customer site and carry-out
 System Analyst: The engineers who questionnary survey, task analysis,
gathers and analyse customer scenario analysis, and form analysis.
requirements and then write the
But still the questio
document are known as system analyst. n
remains…How to
 Tough task to gather requirements from gather requirements
large no. of people and document them ?
and then to understand clearly.
Unit 2: Requirements Modeling and Design
Requirement Elicitation:
How to gather requirements?
1. Study Existing documents:
 Study before visit to know the context
 Basic purpose and the stakeholders
2. Interviews: organize interviews with all multiple scenarios.
types of users:
1. Understand requirements and draft a
document.
2. Circulate it among all types of user to check
and verify their requirements.
3. Refine the document for comments and
feedback received.
Task Analysis: The users view a software
3.
as a box, that provides a set of services, A
service is “task”. Ex: “Issue a book” in
library management service.
4. Scenario analysis: A task can have
Ex. Scenarios of “Issue a book”
 Book is successfully issued. Book issue slip
is printed.
 The book is reserved. Cannot be issued.
 Member has already issued MAX books
earlier.
5. Form Analysis: Identify input and output
data form.
Unit 2: Requirements Modeling and Design
Requirement Analysis:
The main purpose of the requirements
analysis activity is to analyse the gathered
requirements to remove all ambiguities,
incompleteness, and inconsistencies from the
gathered customer requirements and to obtain
a clear understanding of the software to be
developed.
Why to analyse requirement? Or outcomes
of requirement 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?
 Unit 2: Requirements Modeling and Design
Requirement Analysis: quantification is required for such words like
“good”, “high”, “low”, “bad”
It was observed that during requirement
analysis three types of problems can be  Ex2: Learning Management System
raised and to deal with
(LMS)
1) Anomaly/Ambiguity: several
interpretations of that requirement are Stakeholder1: during the final grade
computation, if any student scores a
possible
 Ex1: Process control application
sufficiently low grade in a semester, then his
parents would need to be informed.
Stakeholder1: When the temperature
becomes high, the heater should be switched Here, It lacks any well defined criteria for
off. “sufficiently low grade”
But “high” means exactly how much? Proper
 Unit 2: Requirements Modeling and Design
Requirement Analysis:
one Ex2: Learning Management System

2) Inconsistency: Where
requirement contradicts with other. (LMS)
Stakeholder1: a student securing fail grades
in three or more subjects must repeat the
 Ex1: Process control application courses over an entire semester, and he
Stakeholder1: The furnace should be cannot credit any other courses while
switched-off when the temperature of the repeating the courses.
furnace rises above 500° C. Stakeholder2: expressed the following
Stakeholder2: When the temperature of the requirement—there is no provision for any
furnace rises above 500° C, the water shower student to repeat a semester; the student
should be switched-on and the furnace should should clear the subject by taking it as an
remain on. extra subject in any later semester.
Unit 2: Requirements Modeling and Design
Requirement Analysis:
3) Incompleteness: Some
requirements are overlooked. Or
lake of feature felt much later when
using the software.
 Ex1: Chemical plant automation
suppose one of the requirements is that if
the internal temperature of the reactor
exceeds 200° C then an alarm bell must be
sounded. However, on an examination of
all requirements, it was found that there is
no provision for resetting the alarm bell
after the temperature has been brought
down in any of the requirements.
 Ex2: Learning Management System
(LMS)
If the Grade Point Average (GPA) of a
student is less than 6 then intimate his
performance to his parents via postal
mail and email as well.
However, the feature (textbox to enter in
a registration form for ex.) where postal
address or email address should be
entered is missing.
Unit 2: Requirements Modeling and Design
Requirement Documentation (SRS):
 Users of the SRS document:  Characteristics of a good SRS
1. Users, Customers and Marketing document
personnel 1. Concise
2. Software Developers 2. Implementation-independent
3. Test Engineers (black-box view) (see next slide)
4. Project Managers 3. Traceable
5. User document writer 4. Modifiable
6. Maintenance Engineers 5. Identification of undesired events
6. Verifiable
Unit 2: Requirements Modeling and Design
Requirement Documentation (SRS):
Black box view of system performing a set of functions
Unit 2: Requirements Modeling and Design
Requirement Documentation (SRS):
 Why to spend time and resources to develop an SRS?
1) Forms an agreement between the customer and the developers
2) Reduces future reworks
3) Provides a basis for estimating cost and schedules
4) Provides a baseline for validation and verification
5) Facilitates future extensions
 Attributes of bad SRS document: try to avoid this problem while writing SRS.
1) Over-specification: to explain “what to” part don’t get started “how to” explanation.
2) Forward reference: aspect that are discuss much later in SRS document, reduces readability
3) Wishful thinking: description of aspects which would be difficult to implement.
4) Noise: irrelevant details. E.g clerk report for work between 8 to 5 in register_cust function.
Unit 2: Requirements Modeling and Design
Requirement Documentation (SRS):
 Important categories of customer requirements (types of requirements)
An SRS document should clearly document the following aspects of a software:
1) Functional requirements
2) Non-functional requirements
— Design and implementation constraints
— External interfaces required
— Other non-functional requirements
3) Goals of implementation.
 Unit 2: Requirements Modeling and Design
Requirement Documentation (SRS):
 Important categories of customer requirements
(types of requirements)
1) Functional requirements: The functional requirements
capture the functionalities required by the users from the
system.
- A software is set of offering functions {fi} to the user.
- f : I → O. meaning that a function transforms an element
(ii) in the input domain (I) to a value (oi) in the output (O).
- Each function fi of the system can be considered as
reading certain data ii, and then transforming a set of
input data (ii) to the corresponding set of output data (oi).
Unit 2: Requirements Modeling and Design
Requirement Documentation (SRS):
 Important categories of customer requirements
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.)
 Unit 2: Requirements Modeling and Design
Requirement Documentation (SRS):
 Important categories of customer b) External interfaces required:
requirements (types of requirements) Example of interfaces are:
2) Non-Functional requirements: - hardware, software and communication interfaces,
a) Design and implementation constraints: some items - user interfaces,
or issues which imposes limits on developers. - report formats, etc.
Some Examples of constraints: The description may include:
- corporate or regulatory policies that needs to be - sample screen images,
honoured; - any GUI standards or style guides that are to be
- hardware limitations; followed
- interfaces with other applications; - screen layout constraints
- specific technologies, tools, and databases to be used; - standard buttons and functions (e.g., help) that will
- specific communications protocols to be used; appear on every screen
- security considerations; - keyboard shortcuts
- design conventions or programming standards to be - error message display standards,
followed, etc. c) Other non-functional requirements: performance,
reliability, accuracy, security issues
Unit 2: Requirements Modeling and Design
Requirement Documentation (SRS):
 Important categories of customer requirements
3) Goal of Implementation:
- This section offers some general suggestions regarding software to be developed. The
develops are free to follow or unfollow those suggestions.
- A goal, in contrast to the functional and non-functional requirements, is not checked
by the customer for conformance at the time of acceptance testing.
- This section might contains information like:
- 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.
 Unit 2: Requirements Modeling and Design
Use Case Diagram:  Use case diagrams are used to visualize, specify,
 A use case diagram is a dynamic or behavior construct, and document the (intended) behavior
diagram in UML. Use case diagrams model the of the system, during requirements capture and
functionality of a system using actors and use analysis.
cases. Use cases are a set of actions, services, and  Provide a way for developers, domain experts and
functions that the system needs to perform end-users to Communicate.
 Serve as basis for testing.
 Use case diagrams contain use cases, actors, and
 Purposes of use case diagrams their relationships.
 Used to gather the requirements of a system.
 Used to get an outside view of a system.
 Identify the external and internal factors
influencing the system.
 Show the interaction among the requirements are
actors.
 Unit 2: Requirements Modeling and Design
Use Case Diagram:
 Actor: A role that a user plays with respect to the
system, including human users and other systems. e.g.,
inanimate physical objects (e.g. robot); an external
system that needs some information from the current
system.
 Use case: A set of scenarios that describing an
interaction between a user and a system, including
alternatives.

 System boundary: rectangle diagram representing the

boundary between the actors and the system.

 Association: Communication between an actor and a

use case; Represented by a solid line.
 Unit 2: Requirements Modeling and Design
Use Case Diagram: to the external entities and the interrelationships
between the actors and the system
 A use case describes a sequence of actions a system
performs to yield an observable result or value to a  Identifying use cases for a system
particular actor  What are the tasks of each actor?
 Naming convention = verb + noun (or) verb + noun-
phrase,  Will any actor create, store, change, remove, or read the
 e.g. withdraw cash information?
 A good use case should:  Will any actor need to inform the system about the
 Describe a sequence of transactions performed by a sudden, external changes?
system that produces a measurable result (goal) for a  Does any actor need to informed about certain
particular actor occurrences in the system?
 Describe the behavior expected of a system from a  What use cases will support and maintain the system?
user's perspective
 Can all functional requirements be performed by the use
 Enable the system analyst to understand and model a
cases?
system from a high-level business viewpoint
 Represent the interfaces that a system makes visible
Unit 2: Requirements Modeling and Design

Use Case Example

System name

Actor Use-case

System boundary
Association
 Unit 2: Requirements Modeling and Design
Use Case Relationship:
 INCLUDES. The includes relationship (also called uses relationship) describes the situation in which a
use case contains behavior that is common to more than one use case. In other words, the common use
case is included in the other use cases. A dotted arrow that points to the common use case indicates the
includes relationship. An example would be a use case Pay Student Fees that is included in Enroll in
Course and Arrange Housing, because in both cases students must pay their fees. This may be used by
several use cases. The arrow points toward the common use case.
 EXTENDS. The extends relationship describes the situation in which one use case possesses the
behaviour that allows the new use case to handle a variation or exception from the basic use case. For
example, the extended use case Student Health Insurance extends the basic use case Pay Student Fees.
The arrow goes from the extended to the basic use case.
 GENERALIZES. The generalizes relationship implies that one thing is more typical than the other
thing. This relationship may exist between two actors or two use cases. For example, a Part-Time Student
generalizes a Student. Similarly, some of the university employees are professors. The arrow points to
the general thing.
 Unit 2: Requirements Modeling and Design
Example:
 Unit 2: Requirements Modeling and Design
Data Flow Diagrams
 The DFD (also known as the bubble chart) is a
simple graphical formalism that can be used to
represent a system in terms of the input data to
the system, various processing carried out on
those data, and the output data generated by the
system.
 A data flow diagram (DFD) maps out the flow of
information for any process or system. It uses
defined symbols like rectangles, circles and
arrows, plus short text labels, to show data inputs,
outputs, storage points and the routes between
each destination.
External entity
 The external entities are essentially those physical
entities external to the software system which
interact with the system by inputting data to the
system or by consuming the data produced by the
system.
 An external entity such as a librarian, a library
member, etc. is represented by a rectangle.
 In addition to the human users, the external entity
symbols can be used to represent external
hardware and software such as another
application software that would interact with the
software being modelled.
 Unit 2: Requirements Modeling and Design
 Primitive symbols used for constructing DFDs Data store symbol
 A data store is represented using two parallel lines.

 It represents a logical file.

 A data store symbol can represent either a data structure

or a physical file on disk.

 Each data store is connected to a process by means of a

data flow symbol.

 The direction of the data flow arrow shows whether data

is being read from or written into a data store.

Data flow symbol  An arrow flowing in or out of a data store implicitly

 A directed arc (or an arrow) is used as a data flow symbol represents the entire data of the data store and hence
 A data flow symbol represents the data flow occurring arrows connecting to a data store need not be annotated
between two processes or between an external entity and with the name of the corresponding data items.
a process in the direction of the data flow arrow. Output symbol
 Data flow symbols are usually annotated with the  The output symbol is used when a hard copy is produced.

corresponding data names.

 Unit 2: Requirements Modeling and Design
Levels in Data Flow Diagrams (DFD)  0-level DFD
 The DFD may be used to perform a  It is also known as fundamental
system or software at any level of system model, or context diagram
abstraction. represents the entire software
 DFDs may be partitioned into levels requirement as a single bubble with
that represent increasing information input and output data denoted by
flow and functional detail. incoming and outgoing arrows.
 Levels in DFD are numbered 0, 1, 2 or
beyond.
 Here, we will see primarily three
levels in the data flow diagram, which
are: 0-level DFD, 1-level DFD, and 2-
level DFD.
 Unit 2: Requirements Modeling and Design

0-level DFD
 Unit 2: Requirements Modeling and Design

1-level DFD
 Unit 2: Requirements Modeling and Design

2-level DFD
Unit 2: Requirements Modeling and Design
 Unit 2: Requirements Modeling and Design
 Example: (RMS Calculating Software) A software system called RMS calculating software would read three
integral numbers from the user in the range of –1000 and +1000 and would determine the root mean square (RMS) of
the three input numbers and display it.
 Unit 2: Requirements Modeling and Design
Example: (Tic-Tac-Toe Computer Game): Tic-tac-toe is a computer game in which a human player and the computer
make alternate moves on a 3 × 3 square. A move consists of marking a previously unmarked square. The player who is
first to place three consecutive marks along a straight line (i.e., along a row, column, or diagonal) on the square wins.
As soon as either of the human player or the computer wins, a message congratulating the winner should be displayed.
If neither player manages to get three consecutive marks along a straight line, and all the squares on the board are filled
up, then the game is drawn. The computer always tries to win a game.
 Unit 2: Requirements Modeling and Design
What is Design?
 A meaningful representation of something to be
built
 It’s a process by which requirements are
translated into blueprint for constructing a
software blueprint gives us the holistic view
(entire view) of a software
Software design is a mechanism to transform user
requirements into some suitable form, which helps
the programmer in software coding and
implementation. It deals with representing the
client's requirement, as described in SRS (Software
Requirement Specification) document, into a form,
i.e., easily implementable using programming
 Unit 2: Requirements Modeling and Design
Software Design Process:
 Unit 2: Requirements Modeling and Design
Analysis Model -> Design Model
Co m p o n e n t -
s c e na rio - ba s e d f lo w- o rie nt e d Le v e l D e s ig n
e le me nt s e le me nt s
us e-cas es - text data flow diagrams
us e-cas e diagrams control-flow diagrams
activity diagrams proces s ing narratives
s wim lane diagrams
In t e rf a c e D e s ig n
An a ly s is Mo de l

A rc h it e c t u ra l D e s ig n
c la ss- ba se d be ha v io ra l
e le me nt s e le me nt s
clas s diagrams s tate diagrams
analys is packages s equence diagrams
CRC models D a t a / Cla s s D e s ig n
collaboration diagrams

Desig n Mo d el
 Unit 2: Requirements Modeling and Design
Design Model
 Unit 2: Requirements Modeling and Design
Characteristics
design: of a good software should be logically partitioned
into elements or subsystems
1) The Design must be implement all 7) A design should contain distinct
explicit requirement available in representations of data, architecture,
requirements interfaces, and components.
2) The Design must accommodate all 8) A design should lead to data structures
implicit requirements given by that are appropriate for the classes to be
stakeholders implemented and are drawn from
3) The design must be readable & recognizable data patterns.
understandable 9) A design should lead to components
4) The good design should provide complete that exhibit independent functional
picture of software, addressing the data, characteristics.
functional and behavioral domains 10) A design should lead to interfaces that
reduce the complexity of connections
Quality Guidelines: between components and with the
external environment.
5) A design should exhibit an architecture
that (1) has been created using 11) A design should be derived using a
recognizable architectural styles or repeatable method that is driven by
patterns, (2) is composed of components information obtained during software
that exhibit good design characteristics requirements analysis.
and (3) can be implemented in an 12) A design should be represented using a
evolutionary fashion notation that effectively communicates
6) A design should be modular; that is, the its meaning.
Unit 2: Requirements Modeling and Design
Objectives of Software Design

1) Correctness: Software design should be

correct as per requirement.
2) Completeness: The design should have
all components like data structures,
modules, and external interfaces, etc.
3) Efficiency: Resources should be used
efficiently by the program.
4) Flexibility: Able to modify on changing
needs.
5) Consistency: There should not be any
inconsistency in the design.
6) Maintainability: The design should be
so simple so that it can be easily
maintainable by other designers.
 Unit 2: Requirements Modeling and Design
Modularity:
 Modularity specifies to the division of software into separate modules which are differently named and
addressed and are integrated later on in to obtain the completely functional software. It is the only
property that allows a program to be intellectually manageable.
 The process of breaking down a software into multiple independent modules where each module is
developed separately is called Modularization

 The desirable properties of a modular

system are:
 Each module is a well-defined system that can
be used with other applications.
 Each module has single specified objectives.
 Modules can be separately compiled and saved
in the library.
 Modules should be easier to use than to build
Unit 2: Requirements Modeling and Design

Example
 Unit 2: Requirements Modeling and Design
Modularity:
Advantages
 It allows large programs to be written by several
or different people
 It encourages the creation of commonly used
routines to be placed in the library and used by
other programs.
 It simplifies the overlay procedure of loading a
large program into main storage.
 It provides more checkpoints to measure
progress.
 It provides a framework for complete testing,
more accessible to test
 It produced the well designed and more readable
program.
Disadvantages
 Execution time maybe, but not certainly,
longer
 Storage size perhaps, but is not certainly,
increased
 Compilation and loading time may be longer
 Inter-module communication problems may
be increased
 More linkage required, run-time may be
longer, more source lines must be written, and
more documentation has to be done
 Unit 2: Requirements Modeling and Design
Modularity and software cost:
 Unit 2: Requirements Modeling and Design

Coupling and Cohesion

When a software program is modularized, its tasks are divided into
several modules based on some characteristics. As we know, modules
are set of instructions put together in order to achieve some tasks. They
are though, considered as single entity but may refer to each other to
work together. There are measures by which the quality of a design of
modules and their interaction among them can be measured. These
measures are called coupling and cohesion.
 Module Coupling
In software engineering, the coupling is the degree of
interdependence between software modules. Two modules that are
tightly coupled are strongly dependent on each other.
 Module Cohesion
In computer programming, cohesion defines to the degree to which
the elements of a module belong together. Thus, cohesion measures
the strength of relationships between pieces of functionality within a
given module. For example, in highly cohesive systems,
functionality is strongly related.
 Unit 2: Requirements Modeling and Design
Coupling and Cohesion
 Module Coupling
Coupling: Coupling is the measure of the degree of
interdependence between the modules. A good
software will have low coupling.
 Module Cohesion

Cohesion is a measure of the degree to which the

elements of the module are functionally related. It is
the degree to which all elements directed towards
performing a single task are contained in the
component. Basically, cohesion is the internal glue
that keeps the module together. A good software
design will have high cohesion.
Unit 2: Requirements Modeling and Design

Types of Module Coupling

1. Data Coupling
2. Stamp Coupling
3. Control Coupling
4. External Coupling
5. Common Coupling
6. Content Coupling
 Unit 2: Requirements Modeling and Design
Types of Module Coupling
4) External Coupling: In external coupling, the modules
1) Data Coupling: If the dependency between the modules
depend on other modules, external to the software being
is based on the fact that they communicate by passing
developed or to a particular type of hardware. Ex-
only data, then the modules are said to be data coupled.
protocol, external file, device format, etc.
In data coupling, the components are independent to
5) Common Coupling: The modules have shared data
each other and communicating through data. Module
such as global data structures. The changes in global
communications don’t contain tramp data. Example-
data mean tracing back to all modules which access that
customer billing system.
data to evaluate the effect of the change. So it has got
2) Stamp Coupling In stamp coupling, the complete data
disadvantages like difficulty in reusing modules,
structure is passed from one module to another module.
reduced ability to control data accesses and reduced
3) Control Coupling: If the modules communicate by
maintainability.
passing control information, then they are said to be
6) Content Coupling: In a content coupling, one module
control coupled. It can be bad if parameters indicate
can modify the data of another module or control flow
completely different behaviour and good if parameters
is passed from one module to the other module. This is
allow factoring and reuse of functionality. Example- sort
the worst form of coupling and should be avoided.
function that takes comparison function as an argument.
 Unit 2: Requirements Modeling and Design
Types of Modules Cohesion
1. Functional cohesion
2. Sequential cohesion
3. Communicational cohesion
4. Procedural cohesion
5. Temporal cohesion
6. Logical cohesion
7. Co-incidental cohesion
 Unit 2: Requirements Modeling and Design
CGPA, print CGPA.
Types of Modules Cohesion
5) Temporal Cohesion: The elements are related by their
1) Functional Cohesion: Every essential element for a timing involved. A module connected with temporal
single computation is contained in the component. A cohesion all the tasks must be executed in the same
functional cohesion performs the task and functions. It time-span. This cohesion contains the code for
is an ideal situation. initializing all the parts of the system. Lots of different
2) Sequential Cohesion: An element outputs some data activities occur, all at initial time.
that becomes the input for other element 6) Logical Cohesion: The elements are logically related
3) Communicational Cohesion: Two elements operate and not functionally. Ex- A component reads inputs
on the same input data or contribute towards the same from tape, disk, and network. All the code for these
output data. Example- update record into the database functions is in the same component. Operations are
and send it to the printer. related, but the functions are significantly different.
4) Procedural Cohesion: Elements of procedural 7) Coincidental Cohesion: The elements are not
cohesion ensure the order of execution. Actions are related(unrelated). The elements have no conceptual
still weakly connected and unlikely to be reusable. Ex- relationship other than location in source code. It is
 Unit 2: Requirements Modeling and Design
Differentiate between Coupling and Cohesion
Coupling Cohesion
Coupling is also called Inter-Module Binding. Cohesion is also called Intra-Module Binding.
Coupling shows the relationships between Cohesion shows the relationship within the module.
modules.
Coupling shows the Cohesion shows the module's
relative independence between the modules. relative functional strength.
While creating, you should aim for low coupling, While creating you should aim for high cohesion, i.e., a
i.e., dependency among modules should be less. cohesive component/ module focuses on a single
function (i.e., single-mindedness) with little interaction
with other modules of the system.
In coupling, modules are linked to the other In cohesion, the module focuses on a single thing.
modules.
 Unit 2: Requirements Modeling and Design
A data flow diagram (DFD) maps out the flow of
Function Oriented Design 

information for any process or system. It uses

 Function Oriented design is a method to software
defined symbols like rectangles, circles and
design where the model is decomposed into a set
arrows, plus short text labels, to show data inputs,
of interacting units or modules where each unit or
outputs, storage points and the routes between
module has a clearly defined function. Thus, the
each destination.
system is designed from a functional viewpoint.
1) Data Flow Diagram
 Data-flow design is concerned with designing a
series of functional transformations that convert
system inputs into the required outputs. The
design is described as data-flow diagrams. These
diagrams show how data flows through a system
and how the output is derived from the input
through a series of functional transformations.
 Unit 2: Requirements Modeling and Design
2) Data Dictionaries different engineers of the project tend to use
 Data dictionaries are simply repositories to store different terms to refer to the same data, which
information about all data items defined in DFDs. unnecessarily causes confusion.
At the requirement stage, data dictionaries  The data dictionary provides the analyst with a
contains data items. Data dictionaries include means to determine the definition of various data
Name of the item, Aliases (Other names for structures in terms of their component elements.
items), Description / purpose, Related data items, 3) Structured Charts
Range of values, Data structure definition / form.  It is the hierarchical representation of system
 A data dictionary plays a significant role in any which partitions the system into black boxes
software development process because of the (functionality is known to users but inner details
following reasons: are unknown). Components are read from top to
 A Data dictionary provides a standard language bottom and left to right. When a module calls
for all relevant information for use by engineers another, it views the called module as black box,
working in a project. A consistent vocabulary for passing required parameters and receiving
data items is essential since, in large projects, results.
 Unit 2: Requirements Modeling and Design
 Structured Chart is a graphical  Information passed between modules
representation which shows:
 System partitions into modules
 Hierarchy of component modules
 The relation between processing
modules
 Interaction between modules

4) Pseudo-code
 Pseudo-code notations can be used in both the preliminary and detailed design phases. Using pseudo-
code, the designer describes system characteristics using short, concise, English Language phases
that are structured by keywords such as If-Then-Else, While-Do, and End.
 It use keyword and indentation. Pseudo codes are used as replacement for flow charts