ISE (Diploma 4 th

Computer Engineering)

Unit : 2
Software
Requirement
Analysis and
Design
 CO (Course Outcome)
&
UOs (Unit Outcomes)
CO (b)
Prepare software analysis and design using SRS, DFD and
object oriented UML diagrams.
UOs
2a. Identify Software requirements for the given problem
2b. Prepare SRS from the requirement analysis
2c. Represent the specified problem in the given design
notation – DFD
2d. Draw the relevant UML diagrams for the given
problem
2
 2.1 Requirement Gathering & Analysis
• As per IEEE the definition of requirement is  A condition or
capability needed by a user to solve a problem or achieve an
objective.
• Requirements are the description of features and
functionalities of the target system.
• Requirements of customer play an important role.
• Requirements convey the expectation of users.
• Done by system analysis.
• Requirement Gathering and Analysis is  “Collecting all the
information from the customer and then analyze the collected
information to remove all ambiguities and inconsistencies from
customer perception.”
3
 2.1 Requirement Gathering & Analysis
• It is the discovery phase of software development.
• Two sub processes  Requirement gathering and Requirement
analysis.
 Requirement Gathering:
• Collecting requirements from the stakeholders.
• First part of any software product development.
• Requirements gathering is the process of understanding
what you are trying to build and why you are building it.
• Goal  to collect all related information from the customer
regarding the product to be developed.
• This is done to clearly understand the customer requirements
so that incompleteness and inconsistencies are removed.
4
 2.1 Requirement Gathering & Analysis
• Activity of market research (for competitive analysis) is done at this
time.
• It involves interviewing the end-users and studying the existing
documents to collect all possible information.
• Different requirement gathering activities:
– Interview with end users or customers
– Survey / Questionnaire
– Brainstorming
– Observation
– Interface analysis
– Task analysis
– Form analysis
– Group discussion
– Prototyping
5
– Analyse existing documents
 2.1 Requirement Gathering & Analysis
 Requirement Analysis:
• Requirement analysis is the process of evaluating, interpreting,
and refining the requirements gathered during the
requirement gathering process to ensure they are clear,
complete, accurate, and feasible.
• Goal  to clearly understand the exact requirements of the
customers.
• IEEE defines requirement analysis as (1) the process of studying
user needs and (2) The process of studying and refining system
hardware or software requirements.
• Identify possible solutions to problems, and clarify details of
opportunities.
6
 2.1 Requirement Gathering & Analysis
• Requirement analysis involves:
– Eliciting requirements (requirements ને છુટી પાડવી)
– Analyzing requirements (છુટી પડેલી requirements નું
analysis કરવું)
– Requirements recording or storing (બધીજ જરૂરી
requirements ને record કરવી)
• Performed by system analyst.
• For that, analyst has to identify and eliminate the problems of
anomalies, inconsistencies and incompleteness. Anomaly is the
ambiguity in the requirement, Inconsistency contradicts the
requirements, and Incompleteness may overlook some
requirements.
7
 2.1 Requirement Gathering & Analysis
• Discussion with end users is performed.
• Finally, make sure that requirements should be specific,
measurable, timely, achievable and realistic.
• Output of this activity is  Software Requirement Specification
(SRS).
 Requirement gathering and requirement analysis &
specification activities collectively called ‘Requirement
Engineering’.

8
 2.2 Software Requirement Specification (SRS)

• It is the output of requirement gathering and analysis activity.

• Created by system analyst.
• It is a detailed description of the software that is to be developed.
• It describes ‘what’ the proposed system should do without
describing ‘how’ the software will do (what part, not how).
• Working as a reference document.
• SRS is actually a contract between developer and end user.
• The SRS translates the ideas of the customers (input) into the formal
documents (output).
• The SRS document is known as black-box specification.

9
 2.2 Software Requirement Specification (SRS)
 Important of SRS (Features of SRS)
• SRS provides foundation for design work.
• It enhances communication between customer and developer.
• Developers can get the idea what exactly the customer wants.
• It enables project planning and helps in verification and validation
process.
• Reduces the development cost and time efforts.
• We can get the partial satisfaction of the end user for the final
product.
• SRS is also useful during the maintenance phase.

10
 2.2 Software Requirement Specification (SRS)
 Users of SRS
 Customers and end users
 Project managers
 Designers and programmers
 Testers
 Maintenance teams
 Trainers
 Characteristics of a good SRS

Concise Structured Verifiable Portable

Complete Conceptual Adaptable Unambiguous

integrity
Consistent Black box view Maintainable Traceable
11
 2.2 Software Requirement Specification (SRS)
 Examples of bad SRS (Characteristics of bad SRS)
 Over specification (try to address ‘how’)
 Forward references (aspects that to be referred late)
 Wishful thinking (contents that are difficult to implement)

• The SRS documents that contain incompleteness, ambiguity

and contradictions are considered as bad SRS documents.
 Types of requirements in SRS
– Customer requirements
– Functional requirements
– Non-functional requirements

12
 2.2 Software Requirement Specification (SRS)

 Customer requirements
• It represent the needs, expectations, and desires of the end-
users, customers or stakeholders who will be using the
software product.
• Motivate customers to buy a product or service.
• The SRS document should accurately capture all customer
requirements, which are typically gathered through various
methods, such as interviews, surveys, focus groups, and market
research.
• The requirements should be clear, unambiguous, specific,
measurable, and traceable to ensure that the software meets
the customer's expectations.
• Requirements should be prioritized to ensure that the most
critical requirements are addressed first.
13
 2.2 Software Requirement Specification (SRS)
 How to identify customer’s requirements
 Conduct interviews
 Analyse existing system
 Conduct workshops
 Have customer feedback
 Analyze competitors
• All the customer requirements should be written in SRS with
clear and concise approach.

14
 2.2 Software Requirement Specification (SRS)

 Functional requirements
• It describes the functionalities or services that the system is
expected to provide.
• It forms the core of requirement documents.
• It also describe how the system should behave in different
scenarios.
• Key goal  to capture the behaviour of software in terms of
functions and technology.
• It is the list of actual services which a system will provide.
• Described as a set of inputs, process and a set of outputs.
• Functional requirements may be calculations, data
manipulations and processing, technical details or other
specific functionalities that define what a system is supposed
to do. 15
 2.2 Software Requirement Specification (SRS)
 How to identify functional requirements
• From following factors:
 From informal problem description or from conceptual
understanding of the system
 From user perspective
 Find out higher level function requirements
 How to document functional requirements
• Specified by different scenarios
• Specify the input data domain, processing and output data
domain
• Document the functionalities supported by the system

16
 2.2 Software Requirement Specification (SRS)
 Example: operations at ATM
Functional requirements of ATM system (likely)
• Withdraw cash
• Fast cash
• Deposit cash When you design
SRS, all the
• Check balance
functional
• Print mini statement requirements must
• Change pin number start with a ‘verb’.

• Generate PIN
• Transfer money etc.

17
 2.2 Software Requirement Specification (SRS)
Sample SRS for one of the requirements of ATM system.
R1: Withdraw cash
• R 1.1: enter the card
Input: ATM card
Output: user prompted to enter PIN showing the display with various
operations
• R 1.2: enter PIN
Input: valid PIN
Output: showing the display with various operations
• R 1.3: select operation type
Input: select proper option (withdraw amount option)
Output: user prompted to enter the account type
• R 1.4: select account type
Input: user option (for example: saving account or current account)
Output: user prompted to enter amount
• R 1.5: get required amount
Input: amount to be withdrawn 18
Output: requested cash and printed transaction
 2.2 Software Requirement Specification (SRS)

 Non Functional requirements

• Non-functional requirements are the constraints or restrictions on
the design of the system.
• It is called quality attributes.
• It describes the characteristics of the system that can’t be
expressed functionally.
• Some non-functional requirements are:

19
2.2 Software Requirement Specification (SRS)

20
 2.2 Software Requirement Specification (SRS)
 Difference between functional and non-functional
requirements.
Functional requirements Non-functional requirements
- These describe what the system - These describe how the system
should do. should behave.
- These describe features, - They describe various quality
functionality and usage of the factors, attributes which affect the
system. system’s functionality.
- Describe the actions with which - Describe the experience of the
the work is concerned. user while doing the work.
- Characterized by verbs. - Characterized by adjectives.
- Ex: business requirements, SRS - Ex: portability, quality, reliability,
etc. robustness, efficiency etc.

21
 2.4 Software Design
• It is a mechanism to transform user requirements into some suitable
form, which helps the programmer in software coding and
implementation.
• It is affecting the quality of the software product.
• It starts after requirement gathering and analysis.

 Levels of software design:

 Architectural design
• System can be viewed in terms of sub-systems, modules and
relationship between these modules.
• It defines the framework of the system.
 High level design:
• Problem is decomposed in set of modules.
• Represented using structure chart and different UML diagrams
22
 2.4 Software Design
 Detailed design
• It deals with implementation part.
• In it, each module is examined carefully to design data structure and
algorithms.
 Characteristics of good software design:
- Correctness - Usability
- Completeness - Maintainability
- Modularity - Efficiency
- Scalability - Testability
- Robustness - Readability
- Flexibility - Performance

23
 2.4 Software Design
 Analysis vs Design
Analysis Design
- It carried out before design. - It carried out after analysis.
- It is a kind of examination of the - It is finding the solution of the
problem. problem.
- It concerned with ‘what’ part of - It concerned with ‘how’ part of the
the software development. software development.
- It deals with data collection. - It deals with detailed design
specification.
- Output is  Software Requirement - Output is  Design documents
Specification (SRS) with technical specifications.
- Analysis typically involves - Designing involves architecture
requirement gathering, use case design, user interface design,
analysis, requirement detailed design, component design
24
specification, domain analysis etc. etc.
 2.5 Cohesion and Coupling
• Concept of modularity
• Due to modularity:
o Easy to understand the system.
o System maintenance is easy.
o Provide reusability.
• Cohesion and coupling are two modularization criteria that are often
used together.
• ‘high cohesion and low coupling’ is a primary need of any software
development.

25
 Cohesion
 Cohesion is  a measure of functional strength of a module.
 It refers to what a module can do internally. So it is called inter-
module binding.
 Cohesion keeps the internal modules together, and represents the
functional strength.
 It represents how tightly bound the internal elements of a module
are to one another.
 Cohesion has significant impact on the quality, maintainability,
reliability of the software product.
 Classification of cohesion

26
 Cohesion
⨠ Coincidental cohesion
 Lowest cohesion.
 Coincidental cohesion occurs when there are no meaningful
relationships between the elements.
 it performs a set of tasks in a module that relate to each other very
loosely or not relate to each other.
 It is also called random or unplanned cohesion.
 For example, suppose we are working on a module that calculates
the area and perimeter of a shape in a geometry application, the
module performing tasks of 1. Retrieving the color of the shape, 2.
Check the shape (concave or convex) and print message.
 Here both the tasks are unrelated to each other, and do not share any
common information or data structure.

27
 Cohesion
⨠ Logical cohesion
 A module is said to be logically cohesive if there is some logical
relationships between the elements of a module, and the elements
perform functions that fall into same logical class.
 For example: the tasks of error handling, input and output of data.

⨠ Temporal cohesion
 In it, elements are related in time and they are executed together.

- A module is in temporal cohesion when a module contains functions

that must be executed in the same time span.
• Example: modules that perform activities like initialization, clean-up,
and start-up, shut down are usually having temporal cohesion.

28
 Cohesion
⨠ Procedural cohesion
 A module has procedural cohesion when it contains elements that
belong to specific procedural unit.
 A module is said to have procedural cohesion, if the set of the
modules are all part of a procedure (algorithm) in which certain
sequence of steps are carried out to achieve an objective.

- For example, we are working on a module that calculates the total

cost of a customer's order in an e-commerce application. The module
performs the tasks of collect customer order details, calculate the
cost of each item, calculate the total cost of the order and apply
applicable discount.
• In this case, the tasks performed by the module are all related to the
same procedure.
29
 Cohesion
⨠ Communicational cohesion
 A module is said to have communicational cohesion, if all functions of
the module refer to or update the same data structure, for example
the set of functions defined on an array or a stack.
 Also, two elements operate on the same input data or contribute
towards the same output data.
 These modules may perform more than one functions together.
 For example, user authentication module in web application, doing
the tasks of verifying user’s credential, retrieving user information
and logging user activity. All the tasks are related to user
authentication and focus on same data structure and same output
data.

30
 Cohesion
⨠ Sequential cohesion
 When the output of one element in a module forms the input to
another, we get sequential cohesion.
 For example, suppose you are working on a module that reads a file,
processes the data, and then writes the results to another file. The
module performs three tasks in sequence: reading, performing and
writing. These tasks are arranged in a specific sequence with the
output of one task serving as input to another task. This module is said
to be in sequential cohesion.
⨠ Functional cohesion
 Functional cohesion is the strongest cohesion. And it is very good for
any software development.
 In it, all the elements of the module are related to perform a single
task. All elements are achieving a single goal of a module.
 Functions like: reading transaction records, compute square root, sort
the array are examples of these modules. 31
 Coupling
 Coupling between two modules is  a measure of the degree of
interdependence or interaction between these two modules.
• Coupling refers to the number of connections between ‘calling’ and a
‘called’ module. There must be at least one connection between them.
• It refers to the strengths of relationship between modules in a
system.
• As modules become more interdependent, the coupling increases.
And loose coupling minimize interdependency that is better for any
system development.
• If two modules interchange large amount of data, then they are highly
interdependent or we can say they are highly coupled.
 High coupling between modules make the system difficult to
understand and increase the development efforts. So low (OR loose)
coupling is the best.
 Classification of cohesion 32
 Coupling
 Classification of cohesion

⨠ Data coupling
• It is lowest coupling and best for the software development.
• Two modules are data coupled, if they communicate using an
elementary data item that is passed as a parameter between these
two.
• One module passes data to another module and the second module
uses that data to perform its function.
• For example  an int, a char, a float etc.
33
 Coupling
⨠ Stamp coupling
• Two modules are stamp coupled when modules are connected based
on a common data structure.
• Stamp coupling enables the programmer to pass an entire data
structure from one module to another.
• For example, a database application where different modules interact
with the same data tables.
⨠ Control coupling
• Control coupling exists between two modules, if data from one module
is used to direct the order of instructions execution in another module.
• In other term, one module controls the flow of execution of another
module by passing it control information.
• For example, in a file secure system, security module controls the
execution of file accessing module by passing the control information
based on the user’s authentication.
34
 Coupling
⨠ Common coupling
• Two modules are common coupled, if they share data through some
global data items. It means two or more modules are communicating
using common global data.
• Common coupling can be problematic in software engineering
because it can increase the complexity of the code and make it more
difficult to maintain and test.
- It can also make the software more prone to errors and bugs.
• For example, if the user interface module stores the user input in a
shared data structure and the data processing module reads from the
same data structure to perform calculations, then the two modules
have common coupling.

35
 Coupling
⨠ Content coupling
• It is the highest coupling and creates more problems in software
development.
• It is worst coupling for any software development.
• This creates strong dependency between modules. And increase the
complexity of the modules.
- Content coupling exists between two modules, if they share code, e.g.
a branch from one module into another module.
• It is also known as ‘pathological coupling’.

36
 Cohesion and Coupling
⨠ Difference between Cohesion and Coupling
Cohesion Coupling
- Cohesion is the indication of the - Coupling is the indication of the
relationship within module. relationships between modules.
- Cohesion shows the module’s - Coupling shows the
relative functional strength. relative interdependence among the
modules.
- Cohesion is a degree (quality) to which a - Coupling is a degree to which a
component / module focuses on component / module is connected to
the single thing. the other modules.
- While designing you should go for high - While designing you should go for low
cohesion. coupling
i.e. a cohesive component/ module focus i.e. dependency between modules should
on a single task with little interaction be less.
with other modules of the system.
- Cohesion is the kind of natural extension - Making private fields, private methods
of data hiding for example, class having and non-public classes provides loose
all members visible with a package coupling.
having default visibility.
37
- Cohesion is Intra-Module Concept. - Coupling is Inter -Module Concept
 Function Oriented Software Design

• That focuses on decomposing software systems into smaller,

more manageable functions. So that the testing, development
and maintenance will be easier.
• It is carried out in top down approach
• Function-oriented design is commonly used in procedural
programming languages.

38
 2.6 Data Flow Diagram (DFD)
• Also known as bubble chart or data flow graph.
• DFDs are very useful in understanding the system and can be
effectively used during analysis.
• DFD is a graphical representation of how data moves through a
system.
• The purpose of a DFD is to provide a visual representation of
the system's data flow that is easily understood by both
technical and non-technical stakeholders.
• It views a system as a function that transforms the inputs into
desired outputs.
• The system is represented in terms of the input data to the
system, various processing carried out on these data, and the
output data generated by the system.
• Functional model can be represented using DFD.
39
 2.6 Data Flow Diagram (DFD)
• Primitive symbols used in construction of DFD

40
 2.6 Data Flow Diagram (DFD)
 Process (function)
• Represented by circle or bubble.
• Circles are annotated with names of the corresponding
functions.
• Transforms inputs into outputs.
• The process is named using a single word that describes what
the system does functionally, generally using ‘verb’.
 External entity
• It is represented by a rectangle.
• Entities are external to the system which interacts by inputting
data to the system or by consuming data produced by the
system.
• It can also define source (originator) or destination
(terminator) of the system. 41
 2.6 Data Flow Diagram (DFD)
 Data flow
• Represented by an arc or by an arrow.
• It used to describe the movement of the data.
• It represents the data flow occurring between two processes,
or between an external entity and a process. It passes data
from one part of the system to another part.
• Generally, name of the corresponding data is in ‘noun’ form.
 Data store
• Represented by two parallel lines.
• It is generally a logical file or database where the data is stored.
 Output
• Used when a hardcopy is produced.
• Represented by a rectangle cut either a side. 42
 2.6 Data Flow Diagram (DFD)
 Developing DFD
• DFD starts with the most abstract level of the system (lowest
level) and at each higher level, more details are introduced.
 To develop higher level DFDs, processes are decomposed into
their sub functions.
• The abstract representation of the problem is also called
context diagram.
 Context Diagram (0 Level DFD)
• It is top level DFD.
• Most abstract view of the system.
• It is representing simplified view of targeted system.
• Entire system is represented as a single bubble (process).
43
 2.6 Data Flow Diagram (DFD)
 Level 1 DFD
• It is more detailed version of context diagram.
• It is representing higher level functional requirements.
• Generally 3 to 7 processes are shown in level 1 DFD.
 Further decomposition
• It is also known as factoring or exploding a bubble.
• Successive versions of DFD give more detailed description of
the system.
 Balancing DFD

44
 2.6 Data Flow Diagram (DFD)
 Guidelines while drawing DFD
• A process must have at least one input and one output data flow.
• No control information (IF-THEN-ELSE).
• Data flows must be named.
• No detailed description in context level.
• No more than one bubble in context level.
• Name of data flow  Noun and process  Verb
• A data store must always be connected with a process. A data store
cannot be connected to another data store or to an external entity.
• All the functionalities of the system specified in SRS must be
captured by the DFD model.
• Data flows from entities must flow into processes, and data flows to
entities must come from processes.
45
 2.6 Data Flow Diagram (DFD)
 Example (Average calculator)

46
 2.6 Data Flow Diagram (DFD)
 Another example (ATM system)

47
2.6 Data Flow Diagram (DFD)

48
 2.6 Data Flow Diagram (DFD)
 Advantages of DFD
• Very simple to understand and easy to use.
• Used foe documentation.
• Provide detailed description.
• Provide clear understanding.
• It explains logic of the system.
• Less number of symbols.
• Provides structured analysis.
 Disadvantages of DFD
• No control information.
• Difficult to represent real time systems.
• Different symbols in different notations.
49
Thank
ou…
Y