Class: TEIT Sem: V Subject: SE

Faculty Name: Jayshree Jha Academic Year: 2022-23

Module2: - Requirement Analysis

 Software Requirements
 Functional & non-functional requirements
 User-system requirement engineering process
 Feasibility studies
 Elicitation
 validation & management
 software prototyping
 S/W documentation
 Analysis and modelling
 Requirement Elicitation
 Software requirement specification (SRS)

1.1 Software Requirements

The software requirements are description of features and functionalities of the target system.
Sommerville defines "requirement" as a specification of what should be implemented.

 Requirements specify how the target system should behave. It specifies what to do, but
not how to do. Requirements engineering refers to the process of understanding what a
customer expects from the system to be developed, and to document them in a standard
and easily readable and understandable format.

 It is necessary and important that before we start planning, design and implementation of
the software system for our client, we are clear about it's requirements. If we don't have a
clear vision of what is to be developed and what all features are expected, there would be
serious problems, and customer dissatisfaction as well.

Department of Information Technology | APSIT

  Requirements convey the expectations of users from the software product. The
requirements can be obvious or hidden, known or unknown, expected or unexpected from
client’s point of view.

1.2 Categorization of Requirements

1.2.1
Based on the target audience or subject matter, requirements can be classified into different types,
as stated below:
User requirements: They are written in natural language so that both customers can verify their
requirements have been correctly identified
System requirements: They are written involving technical terms and/or specifications, and are
meant for the development or testing teams.

1.2.2 Functional Requirements and Non-Functional Requirements

Functional Requirements
• A functional requirement defines a system or its component
• It describes the functions a software must perform.
• A function is nothing but inputs, its behavior, and outputs.
• It can be a calculation, data manipulation, business process, user interaction, or any other
specific functionality which defines what function a system is likely to perform.
• Functional requirements in software engineering help you to capture the intended behavior of
the system. This behavior may be expressed as functions, services or tasks or which system
is required

Example of Functional Requirements

• The software automatically validates customers against the ABC Contact Management
System
• The Sales system should allow users to record customers sales
• The background color for all windows in the application will be blue and have a hexadecimal
RGB color value of 0x0000FF.
• Only Managerial level employees have the right to view revenue data.
• The software system should be integrated with banking API
• The software system should pass Section 508 accessibility requirement

Department of Information Technology | APSIT

Here, are the pros/advantages of creating a typical functional requirement document-
• Helps you to check whether the application is providing all the functionalities that were
mentioned in the functional requirement of that application.
• A functional requirement document helps you to define the functionality of a system or one
of its subsystems.
• Functional requirements along with requirement analysis help identify missing requirements.
• They help clearly define the expected system service and behavior. Errors caught in the
Functional requirement gathering stage are the cheapest to fix. Support user goals, tasks, or
activities for easy project management.
• Functional requirement can be expressed in Use Case form or user story as they exhibit
externally visible functional behavior.
Non-functional requirement
These are basically the quality constraints that the system must satisfy according to the project
contract. The priority or extent to which these factors are implemented varies from one project to
other. They are also called non-behavioral requirements.
• A non-functional requirement defines the quality attribute of a software system. They
represent a set of standards used to judge the specific operation of a system. Example, how
fast does the website load?
• A non-functional requirement is essential to ensure the usability and effectiveness of the
entire software system.
• Failing to meet non-functional requirements can result in systems that fail to satisfy user
needs.
• Non-functional Requirements allows you to impose constraints or restrictions on the design
of the system across the various agile backlogs.
Non-Functional requirements basically deal with issues like:
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility

Department of Information Technology | APSIT

Examples of Non-functional requirements
Here, are some examples of non-functional requirement:
1. Users must change the initially assigned login password immediately after the first
successful login. Moreover, the initial should never be reused.
2. Employees never allowed to update their salary information. Such attempt should be
reported to the security administrator.
3. Every unsuccessful attempt by a user to access an item of data shall be recorded on an
audit trail.
4. A website should be capable enough to handle 20 million users with affecting its
performance
5. The software should be portable. So, moving from one OS to other OS does not create
any problem.
6. Privacy of information, the export of restricted technologies, intellectual property rights,
etc. should be audited.
6. Example, the site should load in 3 seconds when the number of simultaneous users are >
10000. Description of non-functional requirements is just as critical as a functional
requirement.

Benefits/pros of Non-functional requirements are:

• The non-functional requirements ensure the software system follow legal and compliance
rules.
• They ensure the reliability, availability, and performance of the software system
• They ensure good user experience and ease of operating the software.
• They help in formulating security policy of the software system.

Department of Information Technology | APSIT

Difference between Functional and Non-Functional requirements:

1.3 Requirement Engineering

The process of collecting the software requirement from the client then understand, evaluate and
document it is called as requirement engineering.
• The goal of requirement engineering is to develop and maintain sophisticated and descriptive
‘System Requirements Specification’ document.
• Requirement engineering constructs a bridge for design and construction.

1.3.1 Requirement Engineering Process: It is a four-step process, which includes –

1. Feasibility Study
2. Requirement Gathering
3. Software Requirement Specification
4. Software Requirement Validation

Department of Information Technology | APSIT

1. Feasibility Study:
• When the client approaches the organization for getting the desired product developed, it
comes up with rough idea about what all functions the software must perform and which all
features are expected from the software.
• Referencing to this information, the analysts do a detailed study about whether the desired
system and its functionality are feasible to develop.
• Feasibility study is focused towards goal of the organization. It analyses whether the
software product can be practically materialized in terms of implementation, contribution of
project to organization, cost constraints and as per values and objectives of the organization.
• It explores technical aspects of the project and product such as usability, maintainability,
productivity and integration ability.
• The output of this phase should be a feasibility study report that should contain adequate
comments and recommendations for management about whether or not the project should be
undertaken.
Types of Feasibility Study
A feasibility analysis evaluates the project’s potential for success; therefore, perceived
objectivity is an essential factor in the credibility of the study for potential investors and
lending institutions. There are five types of feasibility study—separate areas that a feasibility
study examines, described below.

1. Technical Feasibility
This assessment focuses on the technical resources available to the organization. It helps
organizations determine whether the technical resources meet capacity and whether the
technical team is capable of converting the ideas into working systems. Technical feasibility
also involves the evaluation of the hardware, software, and other technical requirements of
the proposed system. As an exaggerated example, an organization wouldn’t want to try to put
Star Trek’s transporters in their building—currently, this project is not technically feasible.

2. Economic Feasibility
This assessment typically involves a cost/ benefits analysis of the project, helping
organizations determine the viability, cost, and benefits associated with a project before
financial resources are allocated. It also serves as an independent project assessment and
enhances project credibility—helping decision-makers determine the positive economic
benefits to the organization that the proposed project will provide.

Department of Information Technology | APSIT

 3. Legal Feasibility
This assessment investigates whether any aspect of the proposed project conflicts with legal
requirements like zoning laws, data protection acts or social media laws. Let’s say an
organization wants to construct a new office building in a specific location. A feasibility study
might reveal the organization’s ideal location isn’t zoned for that type of business. That
organization has just saved considerable time and effort by learning that their project was not
feasible right from the beginning.

4. Operational Feasibility
This assessment involves undertaking a study to analyze and determine whether—and how
well—the organization’s needs can be met by completing the project. Operational feasibility
studies also examine how a project plan satisfies the requirements identified in the
requirements analysis phase of system development.

5. Scheduling Feasibility
This assessment is the most important for project success; after all, a project will fail if not
completed on time. In scheduling feasibility, an organization estimates how much time the
project will take to complete.

2. Requirement Gathering
• If the feasibility report is positive towards undertaking the project, next phase starts with
gathering requirements from the user.
• Analysts and engineers communicate with the client and end-users to know their ideas on
what the software should provide and which features they want the software to include.
3. Software Requirement Specification (SRS)
 A software requirements specification (SRS) is a detailed description of a software system to
be developed with its functional and non-functional requirements.
 The SRS is developed based the agreement between customer and contractors. It may include
the use cases of how user is going to interact with software system.
 The software requirement specification document consistent of all necessary requirements
required for project development. To develop the software system, we should have clear
understanding of Software system. To achieve this, we need to continuous communication
with customers to gather all requirements.
 SRS is a document created by system analyst after the requirements are collected from various
stakeholders.

Department of Information Technology | APSIT

 SRS defines how the intended software will interact with hardware, external interfaces, speed
of operation, response time of system, portability of software across various platforms,
maintainability, speed of recovery after crashing, Security, Quality, Limitations etc.
 The requirements received from client are written in natural language.
 It is the responsibility of system analyst to document the requirements in technical language
so that they can be comprehended and useful by the software development team.

 SRS should come up with following features:

 User Requirements are expressed in natural language.
 Technical requirements are expressed in structured language, which is used inside the
organization.
 Design description should be written in Pseudo code.
 Format of Forms and GUI screen prints.
 Conditional and mathematical notations for DFDs etc.

 Using the Software requirements specification (SRS) document on QA lead, managers creates
test plan.
 It is very important that testers must be cleared with every detail specified in this document
in order to avoid faults in test cases and its expected results.

Department of Information Technology | APSIT

  It is highly recommended to review or test SRS documents before start writing test cases and
making any plan for testing. Let’s see how to test SRS and the important point to keep in mind
while testing it.
1. Correctness of SRS should be checked
2. Ambiguity should be avoided.
3. Requirements should be complete.
4. Consistent requirements.
5. Verification of expected result.
6. Testing environment
7. Preconditions defined clearly
8. Requirements ID
9. Security and Performance criteria
10. Assumption should be avoided
11. Deletion of irrelevant requirements
12. Freeze requirements
4. Software Requirement Validation
• After requirement specifications are developed, the requirements mentioned in this
document are validated.
• User might ask for illegal, impractical solution or experts may interpret the requirements
incorrectly.
• This results in huge increase in cost if not nipped in the bud.
• Requirements can be checked against following conditions
 If they can be practically implemented
 If they are valid and as per functionality and domain of software
 If there are any ambiguities
 If they are complete
 If they can be demonstrated
Thus, a good Requirements Document is:
1. Unambiguous
2. Complete
3. Verifiable
4. Consistent
5. Modifiable
6. Traceable
7. Usable during the Operation and Maintenance Phase

Department of Information Technology | APSIT

1.3.2 Requirement Engineering Tasks: Requirement engineering consists of seven different tasks
as follow:
1. Inception 2. Elicitation 3. Elaboration 4. Negotiation 5. Specification 6. Validation 7.
Requirements Management
1. Inception
 In the inception phase we how the concept of the software has evolved. Does there was
any catalyst event that triggered the need for the software or its need has evolved over
time? Although there is no precise answer to this question the conversation starts with
these basic questions.
 In the inception phase, the business requirements are identified where first the business
need is identified, the scope of the software in the market is analysed, a rough feasibility
analysis is done and the functioning of the software is discussed. Though all these
requirements are subject to change they are enough to start a conversation between
business analysts or customers or stakeholders and the software developers.
 Inception is a task where the requirement engineering asks a set of questions to establish
a software process.
 In this task, it understands the problem and evaluates with the proper solution.
 It collaborates with the relationship between the customer and the developer.
 Developer and customer decide the overall scope and the nature of the question.

2. Elicitation
• Elicitation means to find the requirements from anybody.
• The requirements are difficult because the following problems occur in elicitation.
 Problem of scope: The customer gives the unnecessary technical detail rather
than clarity of the overall system objective.
 Problem of understanding: Poor understanding between the customer and
the developer regarding various aspect of the project like capability, limitation
of the computing environment.
 Problem of volatility: In this problem, the requirements change from time to
time and it is difficult while developing the project.

1.3.3 Requirements elicitation Activities:

Requirements elicitation includes the subsequent activities. Few of them are listed below –
 Knowledge of the overall area where the systems is applied.
 The details of the precise customer problem where the system are going to be applied must
be understood.

Department of Information Technology | APSIT

  Interaction of system with external requirements.
 Detailed investigation of user needs.
 Define the constraints for system development.

1.3.4 Requirements elicitation Methods:

There are a number of requirements elicitation methods. Few of them are listed below –
 Interviews
 Brainstorming Sessions
 Facilitated Application Specification Technique (FAST)
 Quality Function Deployment (QFD)
 Use Case Approach
The success of an elicitation technique used depends on the maturity of the analyst, developers,
users, and the customer involved.
a. Interviews: Objective of conducting an interview is to understand the customer’s
expectations from the software.

 It is impossible to interview every stakeholder hence representatives from groups are selected
based on their expertise and credibility.
 Interviews maybe be open-ended or structured.
 In open-ended interviews there is no pre-set agenda. Context free questions may be asked to
understand the problem.
 In structured interview, agenda of fairly open questions is prepared. Sometimes a proper
questionnaire is designed for the interview.

b. Brainstorming Sessions: It is a group technique

 It is intended to generate lots of new ideas hence providing a platform to share views
 A highly trained facilitator is required to handle group bias and group conflicts.
 Every idea is documented so that everyone can see it.
 Finally, a document is prepared which consists of the list of requirements and their priority
if possible.

c. Facilitated Application Specification Technique: It’s objective is to bridge the

expectation gap/difference between what the developers think they are supposed to build
and what customers think they are going to get.
 A team-oriented approach is developed for requirements gathering.
 Each attendee is asked to make a list of objects that are-
 Part of the environment that surrounds the system
 Produced by the system

Department of Information Technology | APSIT

  Used by the system
 Each participant prepares his/her list, different lists are then combined,
redundant entries are eliminated, team is divided into smaller sub-teams to
develop mini-specifications and finally a draft of specifications is written
down using all the inputs from the meeting.

d. Quality Function Deployment: In this technique customer satisfaction is of prime

concern, hence it emphasizes on the requirements which are valuable to the customer.
3 types of requirements are identified –
 Normal requirements –
In this the objective and goals of the proposed software are discussed with the customer.
Example – normal requirements for a result management system may be entry of marks,
calculation of results, et
 Expected requirements –
These requirements are so obvious that the customer need not explicitly state them.
Example – protection from unauthorized access.
 Exciting requirements –
It includes features that are beyond customer’s expectations and prove to be very
satisfying when present. Example – when unauthorized access is detected, it should
backup and shutdown all processes.
The major steps involved in this procedure are: –
 Identify all the stakeholders, e.g. Users, developers, customers etc
 List out all requirements from customer.
 A value indicating degree of importance is assigned to each requirement.
 In the end the final list of requirements is categorized as –
 It is possible to achieve
 It should be deferred and the reason for it
 It is impossible to achieve and should be dropped off

e. Use Case Approach:

This technique combines text and pictures to provide a better understanding of the
requirements.
The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give a
functional view of the system. The components of the use case design include three major
things – Actor, Use cases, use case diagram.
Actor – It is the external agent that lies outside the system but interacts with it in some way. An
actor maybe a person, machine etc. It is represented as a stick figure. Actors can be primary actors
or secondary actors.
 Primary actors – It requires assistance from the system to achieve a goal.
 Secondary actor – It is an actor from which the system needs assistance.

Department of Information Technology | APSIT

Use cases – They describe the sequence of interactions between actors and the system. They
capture who(actors) do what(interaction) with the system. A complete set of use cases specifies all
possible ways to use the system.
Use case diagram – A use case diagram graphically represents what happens when an actor
interacts with a system. It captures the functional aspect of the system.
 A stick figure is used to represent an actor.
 An oval is used to represent a use case.
 A line is used to represent a relationship between an actor and a use case.

3. Elaboration
• In this task, the information taken from user during inception and elicitation are expanded
and refined in elaboration.
• Its main task is developing pure model of software using functions, feature and constraints
of a software.
4. Negotiation
 This phase emphasizes discussion and exchanging conversation on what is needed and
what is to be eliminated.
 In the negotiation phase, negotiation is between the developer and the customer and they
dwell on how to go about the project with limited business resources.
 Customers are asked to prioritize the requirements and make guesstimates on the conflicts
that may arise along with it.
 Risks of all the requirements are taken into consideration and negotiated in a way where the
customer and developer are both satisfied with reference to the further implementation.
 In negotiation task, a software engineer decides the how will the project be achieved with
limited business resources.
 To create rough guesses of development and access the impact of the requirement on the
project cost and delivery time.
The following are discussed in the negotiation phase:
 Availability of Resources.
 Delivery Time.
 Scope of requirements.
 Project Cost.
 Estimations on development.

5. Specification
• In this task, the requirement engineer constructs a final work product.

Department of Information Technology | APSIT

 • The work product is in the form of software requirement specification.
• In this task, formalize the requirement of the proposed software such as informative,
functional and behavioural.
• The requirements are formalized in both graphical and textual formats.
This phase specifies the following:
 Written document.
 A set of models.
 A collection of use cases.
 A prototype.

The models used in this phase include ER (Entity Relationship) diagrams, DFD (Data Flow
Diagram), FDD (Function Decomposition Diagrams), and Data Dictionaries.
6. Validation: This is the sixth phase of the requirements analysis process. This phase focuses on
checking for errors and debugging. In the validation phase, the developer scans the specification
document and checks for the following:
 All the requirements have been stated and met correctly
 Errors have been debugged and corrected.
 Work product is built according to the standards.

 This requirements validation mechanism is known as the formal technical review.

 The review team that works together and validates the requirements include software
engineers, customers, users, and other stakeholders.
 Everyone in this team takes part in checking the specification by examining for any errors,
missing information, or anything that has to be added or checking for any unrealistic and
problematic errors.
 Some of the validation techniques are the following-

 Requirements reviews/inspections.
 Prototyping.
 Test-case generation.
 Automated consistency analysis.
7. Requirements Management:

 This is the last phase of the requirements analysis process. Requirements management is a set
of activities where the entire team takes part in identifying, controlling, tracking, and
establishing the requirements for the successful and smooth implementation of the project.
 In this phase, the team is responsible for managing any changes that may occur during the
project.

Department of Information Technology | APSIT

  New requirements emerge, and it is in this phase, responsibility should be taken to manage
and prioritize as to where its position is in the project and how this new change will affect the
overall system, and how to address and deal with the change.
 Based on this phase, the working model will be analysed carefully and ready to be delivered
to the customer.
1.4 Analysis Modelling

1.4.1 Definition
The development process starts with the analysis phase. This phase results in a specification
document that shows what the software will do without specifying how it will be done. The analysis
phase can use two separate approaches, depending on whether the implementation phase is done
using a procedural programming language or an object-oriented language.
1.4.2 Analysis Principles
 The information domain must be represented and understood.
 Models should be developed to give emphasis on system information, function and behaviour.
 Models should uncover and give details of all the layers of the development process.
 The function and the problem statement must be defined.
 The various analysis models are flow oriented modelling, scenario-based modelling, class
based modelling, and behavioural modelling.
1.4.3 Need
 Analysis modelling describes the operational and behavioural characteristics.
 Shows the relationship between software interface and other software elements.
 Provides the software developer the representation of the information, function, and
behaviour.
 Coverts the design into the more descriptive models like use case, ER diagram.
 Provides the customer and the developer the means to maintain the quality.
1.4.4 Objective
 Describe what the customer requires.
 Establish a basis for the creation of a software design.
 Devise a set of requirements that can be validated once the software is built.
 Analysis model bridges the gap between system level description and the overall system
functionality.

Department of Information Technology | APSIT

1.4.5 Analysis Rules of Thumb/Structure of Analysis model

 The model should focus on requirements that are visible within the problem or business
domain and be written as a relatively high level of abstraction.
 Each element of the analysis model should add to the understanding of the requirements and
provide insight into the information domain, function, and behaviour of the system.
 Delay consideration of infrastructure and other non-functional models until design.
 Minimize coupling throughout the system.
 Be certain the analysis model provides value to all stakeholders.
 Keep the model as simple as possible.
 The Figure 2 shows the structure of analysis modelling.
1.4.6 Structure/Elements of Analysis Model

Department of Information Technology | APSIT

Data Dictionary:
It is a repository that consists of a description of all data objects used or produced by the
software. It stores the collection of data present in the software. It is a very crucial element of
the analysis model. It acts as a centralized repository and also helps in modelling data objects
defined during software requirements.

Features of Data Dictionary

 Data dictionary is a set of meta-data which contains the definition and representation
of data elements.
 It gives a single point of reference of data repository of an organization. Data
dictionary lists all data elements but does not say anything about relationships between
data elements.
 A data dictionary or database dictionary is a file that defines the basic organization of
a database.
 A database dictionary contains a list of all files in the database, the number of records
in each file, and the names and types of each data field.
 Most database management systems keep the data dictionary hidden from users to
prevent them from accidentally destroying its contents
 Data dictionaries do not contain any actual data from the database, only bookkeeping
information for managing it.
 Without a data dictionary, however, a database management system cannot access
data from the database.

Department of Information Technology | APSIT

 Entity Relationship Diagram (ERD):
It depicts the relationship between data objects and is used in conducting data modelling
activities. The attributes of each object in the Entity-Relationship Diagram can be described
using Data object description. It provides the basis for activity related to data design.

Data Flow Diagram (DFD):

It depicts the functions that transform data flow and it also shows how data is transformed
when moving from input to output. It provides the additional information which is used during
the analysis of the information domain and serves as a basis for the modelling of function. It
also enables the engineer to develop models of functional and information domains at the
same time.

State Transition Diagram:

It shows various modes of behaviour (states) of the system and also shows the transitions
from one state to another state in the system. It also provides the details of how the system
behaves due to the consequences of external events. It represents the behaviour of a system
by presenting its states and the events that cause the system to change state. It also describes
what actions are taken due to the occurrence of a particular event.

Process Specification:
It stores the description of each function present in the data flow diagram. It describes the
input to a function, the algorithm that is applied for the transformation of input, and the output
that is produced. It also shows regulations and barriers imposed on the performance
characteristics that are applicable to the process and layout constraints that could influence
the way in which the process will be implemented.

Control Specification:
It stores additional information about the control aspects of the software. It is used to indicate
how the software behaves when an event occurs and which processes are invoked due to the
occurrence of the event. It also provides the details of the processes which are executed to
manage events.

Data Object Description:

It stores and provides complete knowledge about a data object present and used in the
software. It also gives us the details of attributes of the data object present in the Entity
Relationship Diagram. Hence, it incorporates all the data objects and their attributes.

1.4.6 Analysis Modelling Approach

1. Structured analysis

Department of Information Technology | APSIT

  Considers data and processes that transform data as separate entities.
 Structure analysis is a top-down approach.
 It focuses on refining the problem with the help of the functions performed on the problem
domain.
2. Object-oriented analysis
 Focuses on the definition of classes and the manner in which they collaborate to affect the
customer requirements.
 Defines the system as a set of objects which interact with each other with the services
provided.
 Analyses the problem domain and then partitions the problem with the
 help of objects.
 The concept of object, attributes, class, operation, inheritance, and polymorphism should be
known to work on object-oriented modelling.

1.4.6 Domain Analysis

Department of Information Technology | APSIT

1. Definition
 Domain Analysis is the process that identifies the relevant objects of an application domain.
 The goal of Domain Analysis is Software Reuse
 The higher is the level of the life-cycle object to reuse, the larger are the benefits coming from
its reuse, and the harder is the definition of a workable process.
2. Concept and technical application domain of the software
 Frameworks are excellent candidates for Domain Analysis: they are at a higher level than
code but average programmers can understand them.
 Umbrella activity involving the Identification, analysis, and specification of common
requirements from a specific application domain, typically for reuse in multiple projects
 Object-oriented domain analysis involves the identification, analysis, and specification of
reusable capabilities within a specific application domain in terms of common objects,
classes, subassemblies, and frameworks
3. Input and Output Structure of domain analysis
 Given Figure shows the flow of the input and the output data in the domain analysis
module.
 The main goal is to create the analysis classes and common functions.
 The input consists of the knowledge domain.
 The input is based on the technical survey, customer survey and expert advice.
 The output domain consists of using the input as the reference and developing the functional
models.

Department of Information Technology | APSIT

1.4.8 Building the Analysis Model
1.4.8.1 Data Modelling

 Data modelling is the analysis of data objects that are used in a business or other context
and the identification of the relationships among these data objects.
 Data modelling is a first step in doing object-oriented programming.
 A data model can be thought of as a diagram or flowchart that illustrates the relationships
between data.
 Data modelers often use multiple models to view the same data and ensure that all
processes, entities, relationships and data flows have been identified.

 There are several different approaches to data modelling, including:

 Conceptual Data Modelling - identifies the highest-level relationships between
different entities.
 Enterprise Data Modelling - similar to conceptual data modelling, but addresses the
unique requirements of a specific business.
 Logical Data Modelling - illustrates the specific entities, attributes and relationships
involved in a business function. Serves as the basis for the creation of the physical
data model.
 Physical Data Modelling - represents an application and database-specific
implementation of a logical data model.
1. Data objects (Entities)
 Data objects are modelled to define their attributes and relationships.
 The Figure 6 the relations between the objects and their attributes.
 Data objects are the representation of the most composite information of the system.
 Data object description incorporates the data object and all of its attributes.
 Data objects are all related to each other.

Department of Information Technology | APSIT

2. Data attributes
 Attributes define the properties of the data object as shown in Figure 3.
 Attributes are used to name the instances of the data.
 They describe the instance of the data.
 It helps to make reference to the other instance in another table.

3. Relationships
 Data objects are linked with each other in different ways. These links and connections of
data objects are known as relationships.
 The two objects person and car are linked with the relationship as person owns the car as
shown in Figure.

4. Cardinality (number of occurrences)

 Cardinality is the specification of the number of occurrences of one object that can be
related to the number of occurrences of another object.
 The cardinality is referred to as “one” or “many”, One-to-one (1:1), One-to-many (1: N),
Many-to-many (M: N).
 When one instance of object A relates to one instance of object B, its one-to-one cardinality.

5. Modality
 Modality is 1 if an occurrence of the relationship is mandatory.
 Modality is 0 if there is no explicit need for the relationship to occur or the relationship is
optional.
 Each faculty member advises many students, each student has only one advisor.
 Every faculty member may not be advisor, each student must have an advisor.

Department of Information Technology | APSIT

 Figure 7: Cardinality and Modularity
1.4.8.2 Flow Oriented Modelling
This represents how the data objects are transformed as they move through the system. The flow
modelling provides the view of the system in the graphical approach.
DFD
The Data Flow Diagram is a graphical technique that depicts information flow and the transforms
that are applied as data move from input to output.
Symbol of DFD:-

 Circle: A circle (bubble) shows a process that transforms data inputs into data outputs.
 Data Flow: A curved line shows the flow of data into or out of a process or data store.

Department of Information Technology | APSIT

 Data Store: A set of parallel lines shows a place for the collection of data items. A data store
indicates that the data is stored which can be used at a later stage or by the other processes in
a different order. The data store can have an element or group of elements.
 Source or Sink: Source or Sink is an external entity and acts as a source of system inputs or
sink of system outputs.

 Levels in Data Flow Diagrams (DFD)

The DFD may be used to perform a system or software at any level of abstraction. In fact,
DFDs may be partitioned into levels that represent increasing information flow and functional
detail. 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.

0-level DFD
A level 0 DFD, also called a fundamental system model or context diagrams represents the
entire software system as a single bubble with input and output data indicated by incoming
and outgoing arrows respectively.
Then the system is decomposed and described as a DFD with multiple bubbles. Parts
of the system represented by each of these bubbles are then decomposed and documented as
more and more detailed DFDs. This process may be repeated at as many levels as necessary
until the program at hand is well understood. It is essential to preserve the number of inputs
and outputs between levels, this concept is called levelling by DeMacro. Thus, if bubble "A"
has two inputs x 1 and x2 and one output y, then the expanded DFD, that represents "A"
should have exactly two external inputs and one external output as shown in fig:

Department of Information Technology | APSIT

 A level 1 DFD might contain five or six bubbles with interconnecting arrows; each of the
processes represented at level 1 are sub functions of the overall system depicted in the context
model.

 2-level DFD goes one step deeper into parts of 1-level DFD. It can be used to plan or record
the specific/necessary detail about the system’s functioning.

Department of Information Technology | APSIT

  Depicts how input is transformed into output as data objects move through a system.
 Functional modelling and information flow Indicates how data are transformed as they move
through the system
 Depicts the functions that transform the data flow.
 Each function description is contained in a process specification.

Examples:
Library Information System
0-LEVEL DFD

Level 1 DFD

Department of Information Technology | APSIT

Level 2 DFD

Department of Information Technology | APSIT

Rules for DFD
1. Rule 1 - Does each function have input and output?
2. Rule 2 - Does each function have all the information it needs in order to produce its output?
3. Rule 3 - If not, then what information does it need and where will it get that information from?

Department of Information Technology | APSIT