System Analysis &

Design
Suresh Khadka
MICT, LLB, PGDCA, Scholar M.Phil. in ICT at
NOU
Profession Certification: MCSA, MCSE, RHCSA,
RHCE,CCNA
 Suresh K Khadka
MICT, LLB, PGDCA, Scholar M.Phil. in
ICT at NOU
Profession Certification: MCSA, MCSE, RHCSA,
RHCE,CCNA
Email:[email protected]
Ph:9840064993, 9857844993
Ministry of Federal Affairs &
General Administration
Freelancer Web Developer
 SYSTEM
A System is an orderly grouping of
interdependent Components linked
together according to a plan to achieve a
specific objective.
 SYSTEM
• A System is an orderly grouping of interdependent Components linked
together according to a plan to achieve a specific objective.
 A system must be designed to achieve a predetermined objective.
 Interrelationships and interdependence must exist among the
components.
 The objectives of the organization as a whole have a higher priority than
the objectives of its subsystems.
• A System may be defined as orderly grouping of interdependent
components linked together according to a plan to achieve a
specific goal. Each component is a part of total system and it has
to do its own share of work for the system to achieve the desired
goal.

Information system
• An information system (IS) is an arrangement of people, data, process,
and information technology that interact to collect, process, store and
provide us output the information needed to support an organization.
 Basic Implications
• A System must be designed to achieved a predetermined
objective.
• Interrelationships & Interdependence must exist among the
components.
• The Objectives of the organization as whole have a higher
priority than the objectives of its subsystems
 Examples of System

• Transportation System
• Telephone System
• Accounting System
• Production System
• Computer System
• Business System
• Hotel Management System
• Banking System
Element / Component of System

• Inputs
• Process
• Output
• Control
• Feedback
• Environment
 Characteristics Of System

• Organization
• Interaction
• Interdependence
• Integration
• Central Objective
1. Organization:
It implies structure and order. It is the arrangement of components that helps to
achieve objectives.
2. Interaction:
It refers to the manner in which each component functions with other components
of the system.
3. Interdependence:
It means that parts of the organization or computer system depend on one another.
They are coordinated and linked together according to a plan. One subsystem
depends on the output of another subsystem for proper functioning.
4. Integration:
It refers to the holism of systems. It is concerned with how a system is tied together.
5. Central Objective:
A system should have a central objective. Objectives may be real or stated.
Although a stated objective may be the real objective, it is not uncommon for an
organization to state one objective and operate to achieve another. The important
point is that users must know the central objective of a computer application early
in the analysis for a successful design and conversion.
 Important Terms Systems
• Purpose
Reason for its existence and the reference point for measuring its success.

• Boundary
what is inside the system and what is outside.

• Environment
everything pertinent to the System that is outside of its boundaries.

• Inputs
physical objects and information that cross the boundary to enter it from its environment.

• Outputs
physical objects and information that go from the system into its environment.
 System Approach
Its the approach of building information systems
The increase complexity of business
• The Technological Revolution
• Research & development
• Product changes
• The Information Explosion
The Increased Complexity of Management
• Information Feedback System
• Decision Making
• Management Science
• The Electronic Computer
 Types of System:
• Formal & Informal
• Physical & Abstract
• Close & Open
• Manual or Automatic
• Conceptual & Empirical
• Natural & Manufactured
• Social, People-Machine & Machine
• Adaptive & Non- Adoptive
• Deterministic & Probabilistic
• Permanent & Temporary
• Stationary & Non-Stationary
• Subsystems & Super System
Formal & Informal
A Formal System is one that is planned in advance and is
used according to schedule. Example is to conduct a scheduled
meeting at the end of every month in which agenda of the
meeting has already been defined well in advance.
An Informal System is the system that is not described by
procedures. It is not used. According to a schedule. It works on
as need basis. For example, Sales order processing system
through telephone calls.
Physical & Abstract
Physical Systems are tangible entities that may be static or
dynamic.
Computer Systems, Vehicles, Buildings etc. are examples of
physical systems.
Abstract systems are conceptual entities. These are not
Physical Entities They may be formula ,representation or model
of System Example: Design
Close & Open System
Open System is a system within its environment. It receives
input from environment and provides output to environment.
Example: Any real life system, Information System,
Organization etc.
Closed System: It is isolated from environment influences. It
operates on factors within the System itself. It is also defined as
a System that includes a feedback loop, a control element and
feedback performance standard.
Manual or Automatic
Manual and Automated systems: The system, which does not
require human intervention is called Automated system. In this
system, the whole process is automatic.
Example: Traffic control system for metropolitan cities.
The system, which requires human intervention, is called a Manual
System.
Example: Face to face information centre at places like Railway
stations etc.
 Real Life Business Subsystems

A Subsystem is a component of a System, even though it can also be

considered as a system in its own right. Consider a manufacturing firm. It
consists of five subsystems namely, Product design, Production, Sales, Delivery
and Service.
There are two types of Real Time systems. They are :
Hard Real Time Systems which guarantee that critical tasks are completed
on time.
Soft Real Time Systems which are less restrictive type of real time systems
where a critical real time task gets priority over other tasks, and retains the
priority until it completes them. Systems that control scientific experiments,
medical imaging systems, industrial control systems and some display systems
are real time systems.
DISTRIBUTED SYSTEMS
A Distributed System in which the Data, Process, and Interface component of
information System are distributed to multiple locations in a computer network.
Accordingly, the processing workload required to support these components is
also distributed across multiple computers on the network.
Feature / Advantage
• Resource sharing
• Computation speedup
• Reliability
• Communication.
The five Layers of Distributed System architecture are:
• Presentation Layer is the actual user interface. The inputs
are received by this layer and the outputs are presented by
this layer.
• Presentation Logic layer includes processing required to
establish user interface. Example: Editing input data,
formatting output data.
• Application Logic Layer includes all the logic and processing
required to support the actual business application and rules
Example: Calculations.
• Data Manipulation Layer includes all the command and logic
required to store and retrieve data to and from the database.
• Data Layer is actual stored data in the database.
Various Approaches for development
of Information Systems
DEVELOPMENT OF A SUCCESSFUL
SYSTEM
SDLC
 Various approaches are available for
development of Information Systems:
• Model Driven: It emphasizes the drawing of pictorial system models to
document and validate both existing and/or proposed systems. Ultimately,
the system model becomes the blueprint for designing and constructing an
improved system.
• Accelerated approach: A prototyping approach emphasizes the
construction of model of a system. Designing and building a scaled-down but
functional version of the desired system is known as Prototyping. A
prototype is a working system that is developed to test ideas and
assumptions about the new system.
• Joint Application Development: It is defined as a structured approach in
which users, managers, and analysts work together for several days in a
series of intensive meetings to specify or review system requirements. In
this approach, requirements are identified and design details are finalized.
 VARIOUS APPROACHES FOR
DEVELOPMENT OF INFORMATION
SYSTEMS
• Structured Analysis and Design Approach,
• Prototype Application Development
• Joint Application Development.
• RAD (Rapid Application Development)
• Water Fall
• Spiral Model
 Structured Analysis and Design
Approach
• The first model driven approach is Structured Analysis and Design
approach.
• The goal of structured system analysis and design is to reduce
maintenance time and effort. Modeling is the act of drawing one or
more graphical representations of a System.
• Model driven development techniques emphasize the drawing of
models to help visualize and analyze problems, define business
requirements and design Information systems.
1. Structured Analysis
• Preliminary Investigation
• Problem Analysis
• Requirement Analysis
• Decision Analysis.
2. Structured Design
It utilizes graphic description (Output of system analysis) and focuses on
development of software specifications.
Principles Of Structured Design:
• Modularity and partitioning: Each system should consist of a hierarchy of
modules. Lower level modules are generally smaller in scope and size compared
to higher level modules. They serve to partition processes into separate
functions.
• Coupling: Modules should be loosely coupled. It means that modules should
have little dependence on other modules in a system.
• Cohesion: Modules should be highly cohesive. It means that modules should
carry out a single processing function.
• Span of control: Modules should interact with and manage the functions of a
limited number of lower level modules. It means that the number of called
modules should be limited (in a calling module).
• Size of Module: The number of instructions contained in a module should be
limited so that module size is generally small.
• Shared use of Functions: Functions should not be duplicated in separate
modules may be shared. It means that functions can be written in a single
module and it can be invoked by any other module when needed.
 Prototyping
• Prototyping is an iterative process of system development in
which requirements are converted to a working system that is
continually revised through close work between an analyst
and users
• A prototyping approach emphasizes the construction model of
a system. Designing and building a scaled-down but
functional version of a desired system is the process known
as Prototyping.
The steps of Prototyping process
• Identify the user’s known information requirements
and features needed in the system.
• Develop a working prototype.
• Revise the prototype based on feedback received
from customer
• Repeat these steps as needed to achieve a
satisfactory system.
 Joint Application Development.
• It is defined as a structured approach in which users,
managers, and analysts work together for several days in a
series of intensive meetings to specify or review system
requirements. The important feature of JAD is joint
requirements planning, which is a process whereby highly
structured group meetings are conducted to analyze
problems and define requirements.
• JAD was developed by Chunk Morris of IBM Raleigh and Tony
Crawford of IBM Toronto in the late 1970's
The typical participants in a JAD are listed
below:
JAD session leader: The JAD leader organizes and runs the JAD. This person is trained in group
man
(1) Users: The key users of the system under consideration are vital participants in a JAD. They
are the only ones who have a clear understanding of what it means to use the system on a
daily basis.
(2) Managers: The role of managers during JAD is to approve project objectives, establish
project priorities, approve schedules and costs and approve identified training needs and
implementation plans.
(3) Sponsors: A JAD must be sponsored by someone at a relatively high level in the company
i.e. the person from top management. If the sponsor attends any session, it is usually at the
very beginning or at the end.
(4) Systems Analysts: Members of the systems analysis team attend the JAD session
although their actual participation may be limited. Analysts are there to learn from customers
and managers, but not to run or dominate the process.
(5) Scribe: The scribe takes down the notes during the JAD sessions. This is usually done on a
personal computer or a laptop. Notes may be taken using a word processor. Diagrams may
directly be entered into a CASE tool.
(6) IS staff like systems analysts, other IS staff such as programmers, database analysts, IS
planners and data center personnel may attend to learn from the discussions and possibly to
contribute their ideas on the technical feasibility of proposed ideas or on technical limitations of
current systems. agreement and facilitation as well as system analysis.
The following are the various benefits of Joint
Application Development:
• actively involves users and management in project
development,
• reduces the amount of time required to develop a system,
and
• incorporates prototyping as a means for confirming
requirements and obtaining design approvals.
 Waterfall Model
• The Waterfall Model was the first Process Model to be introduced.
It is also referred to as a linear-sequential life cycle model. It
is very simple to understand and use. In a waterfall model, each
phase must be completed before the next phase can begin and
there is no overlapping in the phases.
The sequential phases in Waterfall model are −
• Requirement Gathering and analysis − All possible requirements of the
system to be developed are captured in this phase and documented in a
requirement specification document.
• System Design − The requirement specifications from first phase are studied in
this phase and the system design is prepared. This system design helps in
specifying hardware and system requirements and helps in defining the overall
system architecture.
• Implementation − With inputs from the system design, the system is first
developed in small programs called units, which are integrated in the next phase.
Each unit is developed and tested for its functionality, which is referred to as Unit
Testing.
• Integration and Testing − All the units developed in the implementation phase
are integrated into a system after testing of each unit. Post integration the entire
system is tested for any faults and failures.
• Deployment of system − Once the functional and non-functional testing is
done; the product is deployed in the customer environment or released into the
market.
• Maintenance − There are some issues which come up in the client environment.
To fix those issues, patches are released. Also to enhance the product some better
versions are released. Maintenance is done to deliver these changes in the
customer environment.
 Waterfall Model - Application

• Requirements are very well documented, clear and fixed.

• Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are available to
support the product.
• The project is short.
 RAD (Rapid Application
• The RAD (RapidDevelopment)
Application Development) model is
based on prototyping and iterative development with no
specific planning involved. The process of writing the software
itself involves the planning required for developing the
product.
• Rapid application development is a software development
methodology that uses minimal planning in favor of rapid
prototyping. A prototype is a working model that is
functionally equivalent to a component of the product
 RAD Model - Application

• RAD should be used only when a system can be modularized to

be delivered in an incremental manner.
• It should be used if there is a high availability of designers for
modeling.
• It should be used only if the budget permits use of automated
code generating tools.
• RAD SDLC model should be chosen only if domain experts are
available with relevant business knowledge.
• Should be used where the requirements change during the
project and working prototypes are to be presented to
customer in small iterations of 2-3 months.
 Spiral Model
• The spiral model combines the idea of iterative development
with the systematic, controlled aspects of the waterfall
model. This Spiral model is a combination of iterative
development process model and sequential linear
development model i.e. the waterfall model with a very high
emphasis on risk analysis. It allows incremental releases of
the product or incremental refinement through each iteration
around the spiral.
 Spiral Model Application

• When there is a budget constraint and risk evaluation is important.

• For medium to high-risk projects.
• Long-term project commitment because of potential changes to
economic priorities as the requirements change with time.
• Customer is not sure of their requirements which is usually the
case.
• Requirements are complex and need evaluation to get clarity.
• New product line which should be released in phases to get
enough customer feedback.
• Significant changes are expected in the product during the
development cycle.
-List the fundamental principles of S/W
Development Life Cycle?

-What are the characteristics of a good information

system?

-What is the difference between information

requirements determination and specification?
 Next Class
SYSTEMS ANALYST – A
PROFESSION
 Introduction System Analyst
• The work of a systems analyst who designs an information
system is the same as an architect of a house. Three groups of
people are involved in developing information systems for
organizations. They are managers, users of the systems and
computer programmers who implement systems. The systems
analyst coordinates the efforts of all these groups to effectively
develop and operate computer based information systems.
• Systems analysts develop information systems. For this task,
they must know about concepts of systems. They must be
involved in all the phases of system development life cycle i.e.
from preliminary investigation to implementation. Success of
development depends on skills and the dedication of Systems
analysts.
 Needs of System Analysist
•A computerized system enables an organization to provide
accurate information and respond faster to the queries,
events etc. If a business needs computerized information
system, a Systems Analyst is required for analysis and design
of that system.
• Informationsystems evolved from the need to improve the
use of computer resources for the information processing
needs of business application. Customer defines the business
problems to be solved by the computer.
• computer programmers and information technologists do not
fully understand the business applications they are trying to
computerize or support. A communication gap has always
existed between those who need computer based business
solutions and those who understand information technology.
Systems analyst bridges this gap.
 System Users
• System users are defined as the people who use information systems or who
are affected by the information system on a regular basis i.e. capturing,
validating, entering, responding to, storing and exchanging data and
information apart from others. System users are concerned with business
requirements.
There are two main classes of system users:
• Internal Users are employees of the business for which an information
system is built. Examples are clerical and service staff, technical and
professional staff, supervisors, middle level managers and executive
managers.
• External Users: Modern information systems are now reaching beyond the
boundaries of the traditional business to include customers and other
businesses as system users. In business-to-business information systems,
each business becomes an external user of the other business’s information
systems. For example, in the case of direct purchasing of product through the
Internet, customer becomes an external user of the retailer’s order
processing information systems.
 SYSTEM ANALYSTS IN VARIOUS
FUNCTIONAL AREAS
Systems Analyst in Traditional Business:
In the traditional business, information services are centralized for the entire organization or for
a specific location. In this organization, the staff of information services report directly to the
chief executive officer (CEO). The highest-ranking officer is sometimes called a chief
information officer (CIO) and the rest of information services are organized according to the
following functions or areas:
• System Development
• Data Administration
• Telecommunications
• End-user Computing
• Computer Operations
Systems Analyst in Modern Business
Many medium-to-large information services units for the modern business have reorganized to
be decentralized with a focus on empowerment and dynamic teams. In modern business,
systems analyst may be reassigned to different projects at time to time.
In modern business, two new trends are used for software development: outsourcing and
consulting. Outsourcing is the act of contracting an outside vendor to assume responsibility for
one or more IT functions or services. Consulting is the act of contracting with an outside vendor
to assume responsibility for or participate in one or more IT projects.
 Roles & Duties of SA
Roles of SA
• The success of an information system development is based
on the role of Systems analyst. Among several roles, some
important roles are:
Change Agent:
Investigator and Monitor:
Architect
Psychologist
Motivator
Intermediary
 Duties of SA

• The duty of a systems analyst is to coordinate the efforts of all

groups to effectively develop and operate computer based
information systems. The duties of a systems analyst are following
Defining Requirements
Prioritizing Requirements by Consensus
Analysis and Evaluation
Solving Problems
Drawing up Functional Specifications
Designing Systems
Evaluating Systems
 Qualification of SA

• A systems analyst must fulfil the following requirements:

Working knowledge of information technology
 Computer programming experience and expertise
 General business knowledge
 Problem solving skills
Communication skills
 Interpersonal skills
 Flexibility and adaptability
 Thorough knowledge of analysis and design methodologies.
 In summary, the skills of SA that are
required classified into the following:
1. Analytical skills
• System study, Organizational knowledge, Problem identification, Problem analysis and
problem solving.
2. Technical skills
• Microcomputers, workstations, minicomputers, Programming languages, Operating
systems, both for PC’s and networks, Database and File management systems, Data
communication standards and software for local and wide area networks, System
development tools and environments (such as forms & report generators and graphical
user interface design tools), Decision support systems and data analysis tools.
3. Management skills
• Resource management, Project management , Risk management, Change
management.
4. Interpersonal & Communication skills.
• Communication skills , Working alone as well as in a team , Facilitating groups,
Managing expectations.
Thank You
 Question

• Are excellent programmers necessarily excellent systems

analysts? Justify your answer
• List at least eight tasks performed by systems analysts.
• List at least six attributes of a systems analyst.
• Why should a systems analyst be able to communicate well?
Introduction to Documentation of
Systems
 Why Documentation ?

• Documentation is needed because it is

• a means for transfer of knowledge and details about description
of the system
• to communicate among different teams of the software project;
• to help corporate audits and other requirements of the
organization;
• to meet regulatory demand;
• needed for IT infrastructure management and maintenance; and
• needed for migration to a new software platform.
 Documentation
• Documentation is a process to help users of software and
other people to use and interact with system.
• Effective and accurate documentation is very necessary for
the success of any system.
• Documentation becomes part of each step of system
development through out the process of system development
even before the documentation starts officially.
• The ISO standard ISO/IEC 12207:1995 describes
documentation “as a supporting activity to record information
produced by a system development life cycle process.”
 Objective of Creating Document

• understand the concept of documentation;

• understand the importance of documentation;
• learn about various documents and process of documentation;
• understand application of various standards of documentation
processes;
• differentiate between various documentation processes;
• know relation between the documentation and quality of
software;
• understand the good practices for documentation process.
 The Process of Documentation

1. Collection of source material:

2. Documentation Plan
3. Review of Plan
4. Creation of Document
5. Testing of Document
6. Maintain Document
various stages of the process of
documentation.
Types of Documentation

• System Requirements Specification (SRS)

• System Design Specification
• Test Design Document
• User Manual
 System Requirements Specification
(SRS)
• A software requirements specification (SRS) is a description of a
software system to be developed.
• It is modeled after business requirements specification), also
known as a stakeholder requirements specification.
• The software requirements specification lays out functional and
non-functional requirements, and it may include a set of use
cases that describe user interactions that the software must
provide to the user for perfect interaction.
 Characteristics (SRS)
1. All the requirements must be stated unambiguously
2. It should be complete.
3. The requirements should be realistic and achievable with
current technology.
4. It must be verifiable and consistent.
5. It should be modifiable
6. It should be traceable to other requirements and related
documents
7. SRS should not only addresses the explicit requirement but
also implicit requirements that may come up during the
maintenance phase of the software
 System Design Specification
• The system design specification documents all as to how the
requirements of the system are to be implemented. It
consists of the final steps of describing the system in detail
before the coding starts.
The system design specification is developed in a two
stage process:
• In the first step, design specification generally describes the
overall architecture of the system at a higher level.
• The second step provides the technical details of low-level
design, which will guide the implementer. It describes exactly
what the software must perform to meet the requirements of
the system.
• Tools for describing design
Data dictionary
• Database schema
• E-R model
• Security model (User Access Rights)
• Trade-off matrix
• Decision table
• Timing diagram
• State machine diagram
• Object Interaction Diagram
• Flow chart
• Inheritance Diagram
• Aggregation Diagram
• Structure Chart
• Pseudocode
 Test Design Document
• Test Design Document is document describing
the testing process. It describes a list of inputs for given
software that will provide a set of expected outputs.
• Test Design Document provides valuable input for the
maintenance phase.
The following IEEE standards describe the standard
practices on software test and documentation:
• 1. 829-1998 IEEE Standard for Software Test Documentation
• 2. 1008-1987 (R1993) IEEE Standard for Software Unit Testing
• 3. 1012-1998 IEEE Standard for Software Verification and
Validation
 Typical content of Test Design
Document:
1. Introduction
• 2. Test Plan
 • 3. Verification Testing

4. Validation Testing
 User Manual
• The User Manual contains all essential information for
the user to make full use of the information system.
User manual includes a description of the system functions and
capabilities, contingencies and alternate modes of operation, and
step-by-step procedures for system access and use.
Types of User Manual:
• Introductory manual: How to get started with the system?
• Functional description: Describes functionality of the system.
• Reference manual: Details about the system facility.
• System administrator guide: How to operate and maintain the
system?
• Installation document: How to install the system?
 DIFFERENT STANDARDS FOR
DOCUMENTATION

• The Documentation Standard defines various aspects of

documentation such as style, format, and the document
revision/change process of these documents.
• The International Standards, ISO/IEC 12207 – Software life
cycle process, describes documentation as one of the
supporting parallel process of software development process.
• 1. ISO/IEC 18019: Guidelines for the design and preparation of
user documentation for application software This standard describes
how to establish what information users need, how to determine the
way in which that information should be presented to the users, and
then how to prepare the information and make it available. It covers
both on-line and printed documentation. It describes standard
format and style to be adopted for documentation. It gives
principles and recommended practices for documentation.
• 2. ISO/IEC 15910: Software user documentation process This
standard specifies the minimum process for creating user
documentation for software that has a user interface, including
printed documentation (e.g., user manuals), on-line documentation,
help text and on-line documentation systems.
• 3. IEEE 1063: Software user Documentation It provides minimum
requirement for structure, information content and format for user
documentation. It does not describe the process to be adopted for
documentation. It is applicable for both printed and on-line
documentation.
Modular and Structured Design
 Design Principles

• Design principles are necessary for efficient software design.

Top down and bottom up strategies help implement these
principles and achieve the objectives.
• The top down approach starts from the highest-level module
of the hierarchy and proceeds through to lower level. On the
contrary, bottom up approach starts with lower level
modules and proceeds through higher levels to the top-level
module.
Top Down Design
 Bottom Up Design

• In bottom up strategy, we start from the bottom and move

upwards towards the top of the software.
• This approach leads to a style of design where we decide the
process of combining modules to provide larger ones, to combine
these to provide even larger ones and so on till we arrive at one
big module.
STRUCTURE CHARTS
Structure Element
 Coupling

• The dependency levels between modules should be minimum. This

automatically leads to the design of modules that don’t communicate
frequently with each other.
• The communication between modules should be through parameters. Of
course, Boolean variables or flags can be used for the purpose of
communication. This is called coupling.
• Types of Coupling:
1. Data Coupling
2. Stamp Coupling
3. Control Coupling
4.Common Coupling
 Cohesion
• Cohesion Describes how system functions are coed in to
modules. A structure chart with a high cohesion has modules
that represent well-defined system functions, on by each
module. it is desirable to have structure charts with high
cohesion.
 LOGICAL AND PHYSICAL DESIGN
• Logical Design is the phase of system development life
cycle in which system analyst and user develops concrete
understanding of the operation of the system. Figure 7.1
depicts various steps involved in the logical design. It
includes the following steps:
• designing forms (hard copy and computer displays) and reports, which
describe how data will appear to users in system inputs and outputs;
• designing interfaces and dialogues, which describe the pattern of
interaction between users and software; and
• designing logical databases, which describe a standard structure for
the database of a system that is easy to implement in a variety of
database technologies.
 Form Design
• Common GUI controls for Inputs
• Text Box
• Radio Button
• Check Box
• List Box
• Dropdown List
• Reports Design

• Types of outputs
• Internal outputs
• External outputs:

• Implementation methods for outputs

• Tabular output:
• Zoned output
• Screen output:
• Graphic output
 Physical Design

• Designing physical files and databases — describes how

data will be stored and accessed in secondary computer
memory and how the quality of data will be ensured.
• Designing system and program structure — describes the
various programs and program modules that correspond to data
flow diagrams and other documentation developed in earlier
phases of lifecycle.
• Designing distributed processing strategies — describes
how your system will make data and processing available to
users on computer networks within the capabilities of existing
computer networks.
 PROCESS MODELING

• Process modeling involves graphically representing the

functions or processes, which capture, manipulate, store and
distribute data between a system and its environment and
between components within a system. A common form of a
process model is data flow diagram. It represents the system
overview.
• Data Flow Diagrams
A DFD can be categorized in the following
forms:
• Context diagram: An overview of an organizational system
that shows the system boundaries, external entities that interact
with the system and the major information flows between the
entities and the system. In this diagram, a single process
represents the whole system.
• First level DFD: A data flow diagram that represents a system’s
major processes, data flows, and data stores at a high level of
detail.
• Functional decomposition diagram: Functional decomposition
is an iterative process of breaking the description of a system
down into finer and finer detail which create a set of charts in
which one process on a given chart is explained in greater detail
on another chart. In this diagram, sub-processes of first level
DFD are explained in detail.
 The following are various
components of a Data Flow
Diagram:

• Process
• Data Flow
• Source or sink of data
• Data store
DRAW DFD
 DATA MODELING
It is a technique for organizing and documenting a
system’s data. Data modeling is sometimes called
database modeling because a data model is
eventually implemented as database. It is also
some times called information modeling. The tool
for data modeling is entity relationship diagram
 ER Diagram
It depicts data in terms of entities and relationships described
by the data. Martin gives the following notations for the
components of ERD.
1. Entities: An entity is something about which the business
needs to store data. An entity is a class of persons, places,
objects, events or concepts about which we need to capture
and store data. An entity instance is a single occurrence of an
entity. The notation is given below:
2. Attribute: An attribute is a descriptive property or
characteristic of an entity. Synonyms include element, property
and field. A compound attribute is one that actually consists of
other attributes. It is also known as a composite attribute. An
attribute “Address” is the example of compound attribute as
shown in the following illustration.

3. Relationships: A relationship is a natural business

association that exists between one or more entities. The
relationship may represent an event that links the entities.
The following are some important terms related to ER
diagrams:
Cardinality defines the minimum and maximum number of
occurrences of one entity that may be related to a single
occurrence of the other entity. Because all relationships are
bidirectional, cardinality must be defined in both directions for
every relationship. Figure 7.4 depicts various types of cardinality.
Degree: The degree of a relationship is the number of entities
that participate in the relationship.
Recursive relationship: A relationship that exists between
different instances of the same entity is called recursive
relationship. depicts recursive relationship between the
instances of the Course entity.
 DATA DICTIONARY
• A Data Dictionary consists of data about data. The major
elements of data dictionary are data flows, data stores and
processes. The data dictionary stores details and descriptions of
these elements. It does not consist of actual data in the
database.
• Analysts use data dictionaries for the following reasons:
• 1. To manage the detail in large systems.
• 2. To communicate a common meaning for all system elements.
• 3. To document the features of the system.
• 4. To facilitate analysis of the details in order to evaluate
characteristics and determine changes that should be made to
the system.
• 5. To locate errors and omissions in the system.
 Decision Tables

• Decision Table is very useful for specifying complex policies

and decision-making rules.
• The following are various components of a Decision table:
• Condition stubs: This portion of table describes the
conditions or factors that will affect the decision or policy
making of the organisation.
• Action stubs: This portion describes the possible policy
actions or decisions in the form of statements.
• Rule: Rules describe which actions are to be taken under a
specific combination of conditions.
 Decision Trees

• Decision tree is a diagram that represents conditions and

actions sequentially, and thus shows which conditions to
consider first, and so on. It is also a method of showing the
relationship each condition and permissible subsequent
actions. The diagram resembles branches on a tree.
Thank You