This document provides an overview of software analysis and design. It discusses requirements gathering and analysis, the software requirements specification document, the design process, concepts of cohesion and coupling, data modeling, data flow diagrams, scenario based modeling, and architectural design decisions. The document is intended as a curriculum for diploma students in computer/IT engineering based on textbooks on software engineering. It covers topics such as the system analyst role, requirements elicitation techniques, requirements analysis to identify anomalies, characteristics of a good requirements specification, classification of customer requirements, the design process, design methodologies, and classifications of cohesion and coupling.

1. Software
Analysis & Design
by:
Dr. Bharat V. Chawda
Computer Engineering Department,
BBIT, VVNagar, Gujarat, India
1

2. Overview
 Requirements Gathering & Analysis
 SW Requirements Specification (SRS)
 Design Process
 Cohesion & Coupling
 Data Modeling Concepts
 Data Flow Diagrams
 Scenario Based Modeling
 Architectural Design Decisions
(As per GTU Curriculum – Diploma in Computer/IT Engineering)
Based on Books:
1. Fundamentals of Software Engineering – by Rajib Mall
2. Software Engineering: A Practitioner’s Approach – by Roger Pressman
2

3. Reqr: Analysis n Specification (i)
 Why Required?
 Improper Requirements -
 Increase number of iterative changes required
during life cycle phases
 Push up development effort, time and cost
 Sets ground for customer dissatisfaction
 May result in customer-developer disputes and
legal battles
3

4. Reqr: Analysis n Specification (ii)
 Goals
 Clearly understand the customer requirements
 Systematically organize requirements into a
specific document
 SRS: Software Requirements Specification
 “Document:
 Specifies systematically all the customer req;
 Serves as a contract document bet customer &
devl organization”
 Final outcome of Req. Analysis n Spec. phase
4

5. System Analyst
 “The engineers who –
 Gather & analyze customer requirements, and,
 Then write requirements specification doc.”
 Roles & Responsibilities:
 Collect data related to SW to be developed, Analyze it
 Find out what exactly needs to be done
 Remove anomalies: Ambiguities, Inconsistencies,
Incompleteness
 Write SRS; Review SRS with project team & customers
 Ensure that it is unambiguous, consistent, complete, and
understandable
5

6. Reqr: Analysis n Specification (iii)
 Main Activities:
 Requirements Gathering & Analysis
 Requirements Specification
6

7. Reqr Gathering/Elicitation (i)
 Looks very simple; but in practice, very difficult
to gather all the necessary info from a large no.
of people and documents
 Two Situations:
 Working model available; like as manual sys
 Easy to obtain i/p & o/p data formats
 Easy to obtain details of the operational procedures
 Working model not available; like as developing
new system
 Requires much more imagination and creativity
7

8. R G/E : Ways/Steps (i)
 Studying the existing documents
 Interview
 Task Analysis
 Scenario Analysis
 Form Analysis
8

9. R G/E : Ways/Steps (i)
 Studying the existing documents
 Studying existing docs: relevant to issues such as :
Context, Basic purpose, Stakeholders etc…
 Interview
 Different methods of interviews are available
 Different users – Require different features from SW
 Example: Library Management System: Students/Staff,
Librarian, Accountant
 Delphi Technique:
 Consolidate Reqs – Reviewed by users – Feedbacks – Refine
 Continue until users agree on a set of requirements
9

10. R G/E : Ways/Steps (ii)
 Task Analysis
 For users: SW = Black box: provides a set of tasks
 For each task: Formulate steps: necessary to provide
services
 Example: Issue book in library management system
 Authenticate Student, Check limit, Check book
availability, Enter book issue details, Print slip
10

11. R G/E : Ways/Steps (iii)
 Scenario Analysis
 A task can have >1 scenario of operation
 Under different situation: Different behavior
 Example: Issue book in library management system
 Book issued successfully
 No book available
 Student reached its limit
 For each scenario: system response and exact
conditions are determined
 Form Analysis
 Determine:
 I/P data to the system; O/P data from the system
11

12. Requirements Analysis: Concept
 Main Purpose
 Analyze collected information to obtain a clear
understanding of the product to be developed, and
 Remove anomalies – ambiguities, inconsistencies,
incompleteness
 Questions to be understood clearly by a system
analyst:
 What is the problem / feature?
 Why to solve it / Why to provide it?
 What: Data input and output? What: Procedures?
 What: Complexities? What: Interfaces?
12

13. Reqr Analysis: Anomalies (i)
 Ambiguity
 Single requirement can have several
interpretations.
 Ambiguous words: high-low; good-bad
 Ex: If student’s attendance is low, warn them.
13

14. Reqr Analysis: Anomalies (ii)
 Inconsistency
 Two requirements contradicts each other, or
 Single requirement can have different
descriptions by different end users
 If student’s attendance is below 70%, inform
parents.
 1. If student’s attendance is below 70%, inform
parents through email.
 2. If student’s attendance is below 70%, inform
parents through SMS.
14

15. Reqr Analysis: Anomalies (iii)
 Incompleteness
 In set of Requirements: some requirements are
overlooked
 Caused by:
 Inability of customer: to visualize system: to be
developed
 To anticipate all the features that would be
required
 If student’s attendance is below 70%, inform
parents through email  but in database, email
id of parents is not available.
15

16. SRS: Concept
 Software Requirement Specification
 Def:
 “Document:
 Specifies systematically all the customer req;
 Serves as a contract document between
customer & development organization”
 Tough?
 Writing SRS document is the toughest among all
documents produced during SDLC.
 Why?
16

17. Writing SRS: Tough. Why? (i)
 SRS: Expected to cater needs of a wide variety
of audience.
 Different People/Users  Diff purposes from SRS
 Categories of users who refer SRS document:
 Users and Customers
 Software Developers
 Test Engineers
 User Documentation Writers
 Maintenance Engineers
 Project Managers
 Marketing Personnel
17

18. Writing SRS: Tough. Why? (ii)
 Users and Customers:
 To ensure: system will meet their requirements
 Software Developers:
 To ensure: they are developing exactly what is required
by the customer
 Test Engineers:
 Reqm should be understandable from functionality point
of view; So that working of SW can be validated.
 Need clear description of: Functionality + I/P + O/P
18

19. Writing SRS: Tough. Why? (iii)
 User Documentation Writers
 To ensure: they understand the features of the product
properly to write users’ manuals
 Maintenance Engineers
 Understand Design & Code; To accommodate Changes
 Project Managers
 To ensure: they can estimate cost; Get info to plan proj
 Marketing Personnel
 Need to understand req. that they can explain to cust.
19

20. Characteristics: Good SRS (i)
 Concise
 Structured
 Black Box View
 Traceable
 Response to Undesired Events
 Verifiable
20

21. Characteristics: Good SRS (ii)
 Concise
 SRS : Concise + Unambiguous + Consistent + Complete
 No verbose, No irrelevant details: Reduce readability,
Increase error possibilities
 Structured
 SRS : Well Structured  Easy: Understand, Modify
 Black Box View
 Should specify: What to do; not how to do
 What to do: External behavior of the system
 How to do: Internal Implementation
 Ex: “Search Book” in a library management system
21

22. Characteristics: Good SRS (iii)
 Traceable
 SRS: should be able to trace specific requirement to –
 Design element, Code segment, Test case, & vice versa
 Response to Undesired Events
 SRS: should characterize acceptable responses to
undesired events (exceptional conditions)
 Verifiable
 Requirements specified in SRS should be verifiable
 Determine: whether or not req. have been met in implm
 Verifiable Req: Book Search: I/P: book name; O/P:
location, if available
 Non verifiable Req: System should be user friendly
22

23. Customer Req: Classification (i)
 Three Aspects of a System:
 Functional Requirements
 Non-functional Requirements
 Goals of the Implementation
23

24. Customer Req: Classification (ii)
 Functional Requirements
 Specify functionalities : Required by users : From
System
 System is considered as : to perform a set of functions
(fi)
 Can be expressed as Mathematical Fun; f : I  O
 Transforms: Set of input data  Corresponding set of
output data
 Ex: Book-name  Search Book  Book details +
location
24

25. Customer Req: Classification (iii)
 Non-Functional Requirements
 Specify Characteristics of a System
 Can’t be expressed as Mathematical Function
 Four Types:
 External Interface Req: GUI, Interface with external HW, SW
 Performance Req: Throughput, Timing, No. of concurrent user,
Result accuracy
 Constraints: Like as use specific DBMS
 SW System Attributes: Maintainability, Reliability, Usability,
Portability
 Failure in these req: Can be considered as System
Failure; Makes the system unacceptable by Customer
25

26. Customer Req: Classification (iv)
 Goals of Implementation
 Specify general suggestions regarding development
 Issues:
 Reusability
 New devices to be supported in future
 Revisions to the system functionalities that may be required in
the future
 Desirable; But, not tested by customer for acceptance
26

27. Functional Requirements
 How to Identify?
 From informal problem description document, or,
conceptual understanding of the problem
 Identify different types of users
 Identify different services required by these users
 High level functions are split into smaller sub-
requirements (sub-functions)
27

28. Functional Requirements
 High level functions of a system are not exactly
similar to Mathematical functions. Why?
 They may involve series of interactions
 They can have more than one scenario
 It is always not possible to determine all input and
output data precisely. Why?
 If working model not available  not possible
 If working model available: No single set  Input may
be in stages at different execution points
28

29. Design Process
 “Activities carried out during the design phase :
Design Process”
 Transforms : SRS Document  Design Document
29

30. Outcome of a Design Process (i)
 Different Modules Required
 Control Relationship among Modules
 Interfaces among Modules
 Data structures of the Individual Modules
 Algorithms required to imp. Individual Modules
30

31. Outcome of a Design Process (ii)
 Different Modules Required
 Each module: Collections of Functions + Data
 Accomplish well defined task
 Should be named properly according to the task
 Control Relationship among Modules
 Arises due to function calls between modules
 Should be identified in the design document
 Interfaces among Modules
 Identifies exact data exchanged bet modules in function
calls
31

32. Outcome of a Design Process (iii)
 Data structures of the Individual Modules
 Data used by functions to accomplish task;
 Also shared, if required;
 Need to be designed and documented
 Algorithms required to imp. Individual Modules
 Algorithms required to perform activities of modules
need to be designed and documented
 Accuracy of results, space & time complexity should be
considered
32

33. Design Activities: Classification
 Design Process:
 Not a single step process
 Involves series of steps in an iterative manner – called
design activities
 Main Two Categories:
 High Level Design / Preliminary Design
 Detailed Design
33

34. Design Activities: High Level
 Activities
 Decompose Problem into a set of Modules
 Identify Control Relationships among Modules
 Identify Interfaces among Modules
 Outcome: Program Structure, or, SW Architecture
 Modules should be:
 Functionally Independent, High Cohesive, Low Coupled,
and Arranged in Hierarchy
 Representation:
 Structure Chart : for Procedural Design
 UML (Unified Modeling Language) : for Object O Design
34

35. Design Activities: Detailed
 Activities
 Design Data structure required for the Module
 Design Algorithm required for the module
 Representation:
 MSPEC (Module Specification)
35

36. Design Methodologies
 Classification
 Procedural Design
 Object Oriented Design
36

37. Cohesion
 Def:
 “Measure of co-operation : different functions
of a module : to achieve single objective”
 High Cohesion:
 Functions perform tasks related to each other,
and co-operate
 Low Cohesion:
 Functions perform tasks different from each
other, and don’t co-operate
 Should be high as much as possible
37

38. Cohesion: Classification (i)
 CoLo TePro CoSeFu
 Coincidental Cohesion
 Logical Cohesion
 Temporal Cohesion
 Procedural Cohesion
 Communicational Cohesion
 Sequential Cohesion
 Functional Cohesion
38

39. Cohesion: Classification (i)
 CoLo TePro CoSeFu
 Coincidental Cohesion
 Logical Cohesion
 Temporal Cohesion
 Procedural Cohesion
 Communicational Cohesion
 Sequential Cohesion
 Functional Cohesion
39
Low
High

40. Cohesion: Classification (ii)
 Coincidental Cohesion
 Functions perform tasks that don’t relate to each other
 Ex: Insert book, Update customer, Prepare order
 Logical Cohesion
 Functions perform similar operations
 Ex: Error handling, I/P data, O/P data, Print reports
 Temporal Cohesion
 Functions are executed in the same time span
 Ex: Computer Booting: Initialize memory, Initialize
devices, load Operating System
40

41. Cohesion: Classification (iii)
 Procedural Cohesion
 Functions are executed one after another; but have
different purposes;
 Also, may operate on different data
 Ex: Login, Get items to be reordered, Prepare order,
Place order, Logout
 Communicational Cohesion
 Functions refer to or update same data structure
 Ex: Manage-Books: Add book, Update book, Del book
41

42. Cohesion: Classification (iv)
 Sequential Cohesion
 Functions are executed in sequence; Output of one
function is used as input to second function, and so on
 Ex: Get reorder item list, Prepare order, Place order
 Functional Cohesion
 Functions co-operate to complete single task
 Ex: Manage Purchase: Get reorder item list, Prepare
order, Place order, Enter supplier bill data, Update stock
42

43. Coupling
 Def:
 “Measure of degree of interconnection /
interdependence between two modules”
 High Coupling:
 2 Modules interact through: Shared data, Passing large
chunk of data
 Low Coupling:
 2 Modules interact through: No data (No interaction),
 Through: only a few primitive data items (i.e. limited
interaction)
 Should be low as much as possible
43

44. Coupling: Classification (i)
 Types:
 Data
 Stamp
 Control
 Common
 Content
44
Low
High

45. Coupling: Classification (ii)
 Data: Two modules are data coupled, if –
 They communicate using primitive data items: int, char
 This data should be problem related, and, not used for
control purpose
 Stamp: Two modules are stamp coupled, if –
 They communicate using composite data items: record,
structure
45

46. Coupling: Classification (iii)
 Control: Two modules are control coupled, if –
 Data from one module is used to direct the order of
instruction execution in another module
 Ex: flag set in one module and tested in another module
 Common: Two modules are common coupled, if –
 They share some global data items
 Content: Two modules are content coupled, if –
 They share code
 Ex: Jump from one module into the code of another
module
46

47. Functional Independence
 Def:
 “A module that has high cohesion and low coupling
with other modules is called functionally independent
module.”
 Advantages:
 Error Isolation
 Scope of Reuse
 Understandability
47

48. To be continued…
48