Chapter 5

Analyzing the System

 Review
 A System is a collection of interrelated components that work
together to achieve some common objective and System Analysis is
the specification of what the system is required to do.
 A Feasibility Study is conducted to find out whether the proposed
system are:
 Possible – to build it with the given technology and resources

 Affordable – given the time and cost constraints of the

organization
 Acceptable – for use by the eventual users of the system

 The different aspects related to Feasibility Study are: Need Analysis,

Economic Feasibility, Technical Feasibility, Legal Feasibility, and
Evaluation of Alternatives.

Software Engineering Principles / Chapter 5 / 2 of 20

 Review Contd…
 Project Proposal is the document that is prepared from the feasibility
report, which outlines the characteristics of a system and gives first-cut
calendar schedule.
 Once the problem is analyzed and the essentials understood, the
requirements must be specified in the Requirement Specification
Document.
 Requirements Gathering involves conducting a preliminary meeting with
the client to understand and analyze his needs.
 A software model must be capable of modeling the information that
software transforms, its functions and behaviors.
 OOA helps to create a precise and concise model of the problem in terms
of real world objects.
 Structured Analysis is a set of techniques and graphical tools that allow us
to develop system specifications that are easily understandable by the
user.

Software Engineering Principles / Chapter 5 / 3 of 20

 Review Contd…
 A dataflow diagram is a pictorial representation of a system’s functions.
Functions form part of various processes that are executed for a system.
 Two components of the Essential Model are:
 Environmental Model

 Behavioral Model

 Project sizing refers to estimating the size and complexity of a project.

 Effort estimation refers to estimation of the amount of human effort
required to do the project.
 The project size can be measured by using the Program Complexity
Method.
 The most commonly used measure of source code program length is the
number of lines of code.
 Function Points measure size in terms of the amount of functionality in a
system.
 COCOMO can be used to estimate the development effort involved in a
project.
Software Engineering Principles / Chapter 5 / 4 of 20
 Objectives
 Describe system elements

 Discuss Data Modelling

 Explain the concepts of cardinality and modality

 Examine Entity relationship diagrams

 Discuss function modelling using DFDs

 Describe Control Flow Model

 Describe the data dictionary

Software Engineering Principles / Chapter 5 / 5 of 20
 System Engineering
 System engineering is analyzing, designing and organizing a
variety of elements into a product, service or technology.

 When the system engineering deals with:

 a business enterprise, it is called information engineering

 a product to be built, it is called product engineering

Software Engineering Principles / Chapter 5 / 6 of 20

 System Engineering Contd…
Busin ess or Source: “Software
Pro duct domain Engineering” - Roger
domain of interest
World view Pressman

Domain view
system element

Element view

Detailed view
Software Engineering Principles / Chapter 5 / 7 of 20
 System Engineering Contd…
 Two approaches to system engineering:
 Top-down approach

 Bottom-up approach

Software Engineering Principles / Chapter 5 / 8 of 20

System Engineering Contd…
Factory Automation
System Source: “Software
Engineering” - Roger
Pressman

Manufacturing Inventory Information

System System System

Material
Movement Manufacturing cells
System

NC Data
Robots
Machine Entry
Devices
Software Engineering Principles / Chapter 5 / 9 of 20
 Data Modeling
 Data modeling identifies:
 Primary data objects of the system

 Composition of each data object

 Attributes that describe the object

Software Engineering Principles / Chapter 5 / 10 of 20

 Cardinality
Definition:
 Cardinality is the specification of the number of occurrences of
one object that can be related to the number of occurrences of
another object. Cardinality is usually expressed in terms of ‘one’
or ‘many’ combinations. - George Tillmann

Software Engineering Principles / Chapter 5 / 11 of 20

 Types of cardinality
 One-to-one

 One-to-many

 Many-to-many

Software Engineering Principles / Chapter 5 / 12 of 20

 Modality

Definition:
 Modality of a relationship is zero if there is no explicit need for
the relationship to occur or the relationship is optional. Modality
is 1 if an occurrence of the relationship is mandatory.

Software Engineering Principles / Chapter 5 / 13 of 20

 Entity Relationship Diagram
(ERD)
 Definition: An ERD is a graphical representation of the
relationship between objects
 Originally proposed by Peter Chan

 ER diagrams use:
 Rectangles to represent data objects

 Labeled line connecting objects to represent a relationship

 Number of special symbols to indicate cardinality and

modality

Software Engineering Principles / Chapter 5 / 14 of 20

 Data Flow Diagrams (DFD)
 Definition: A data flow diagram represents the movement of data
within the system.

 A DFD uses:
 Bubbles to represent functions

 Arrows to represent the data flows

• Arrows pointing towards the bubbles to represent input

values
• Arrows pointing away from the bubble to represent output

values
 Open boxes to represent data stores

 I/O boxes to represent data input and output during human-

computer interaction

Software Engineering Principles / Chapter 5 / 15 of 20

 Control Flow
 Control Flow Diagram (CFD) contains the same processes as the
DFD but shows more control flow instead of data flow.

 The control processes are represented using a notational

reference to a control specification (CSPEC).

 CSPEC represents the behavior of the system using:

 State Transition Diagram (STD), which provides a sequential

specification of behavior
 Process Activation Table (PAT), which is a combinatorial

specification of behavior

Software Engineering Principles / Chapter 5 / 16 of 20

 Data Dictionary
Definition:
 Data dictionary is an organized listing of all data elements that
are relevant to the system with precise and rigorous definitions
so that the user and the system analyst will have a common
understanding of inputs, outputs, components of stores and
intermediate calculations.

Software Engineering Principles / Chapter 5 / 17 of 20

 Contents of a Data Dictionary
 Data dictionary commonly contains:
 Name

 Alias

 Where used/how used

 Content description

 Supplementary information

 Data dictionary may also contain:

 Data element definitions

 Table definitions

 ER models

Software Engineering Principles / Chapter 5 / 18 of 20

 Summary
 A data model is a formal representation, which hides uninteresting details,
highlights important facts, and gives a better understanding of the system
to be built.
 A representation of information that has a number of different properties or
attributes and that can be understood by software, is called a data object.
 Attributes define the properties of a data object and may serve one of the
following purposes:
 To name an instance of the data object

 To describe the instance

 To make references to another instance in another table

 Relationships are verbs used to indicate actions between any two data
objects in the system.
 Cardinality defines the maximum number of object-relationships that can
participate in an association or relationship.

Software Engineering Principles / Chapter 5 / 19 of 20

 Summary Contd…
 The modality of a relationship is zero if there is no explicit need for the
relationship to occur or the relationship is optional. The modality is one
if an occurrence of the relationship is mandatory.
 An Entity-Relationship diagram identifies a number of components such
as data objects, attributes, relationships and various type-indicators.
The main objective of the ERD is to represent data objects and their
relationships.
 Data flow diagrams are typically used to represent a system or
software at any level of abstraction.
 Data flow diagrams provide mechanisms for function modeling as well
as information flow modeling.
 A Control Flow Diagram contains the same processes as the DFD but
shows more control flow instead of data flow.
 A data dictionary is a centralized collection of definitions of all the data
flowing to or from data stores and/or processes.

Software Engineering Principles / Chapter 5 / 20 of 20