Chapter 2 System Analysis

In IT, systems analysis can include looking at end-user implementation of a

software package or product; looking in-depth at source code to define the
methodologies used in building software; or taking feasibility studies and other types
of research to support the use and production of a software product, among other
things.

Systems analysis professionals are often called upon to look critically at systems, and
redesign or recommend changes as necessary. Inside and outside of the business
world, systems analysts help to evaluate whether a system is viable or efficient within
the context of its overall architecture, and help to uncover the options available to the
employing business or other party.

Systems analysts are different than systems administrators, who maintain systems day
to day, and their roles generally involve a top-level view of a system to determine its
overall effectiveness according to its design.

2.1 Feasibility Study

As the name implies, a feasibility study is an analysis of the viability of an

idea. The feasibility study focuses on helping answer the essential question of “should
we proceed with the proposed project idea?” All activities of the study are directed
toward helping answer this question.

Feasibility studies can be used in many ways but primarily focus on proposed business
ventures. Farmers and others with a business idea should conduct a feasibility study to
determine the viability of their idea before proceeding with the development of a
business. Determining early that a business idea will not work saves time, money and
heartache later.

Digital Class Room 8

Chapter 2 System Analysis

2.2 Existing System: Data gathering

As for as concerned to project its defined as the system which presently we are using
and the proposed system is the new techniques implemented to the existing project if
any mistake was happened.Information you gather can come from a range of sources.
Likewise, there are a variety of techniques to use when gathering primary data. Listed
below are some of the most common data collection techniques.

2.2.1 Questionnaires

 Questions should be focused, clear, and encourage open-ended responses.

 Responses can be analyzed with quantitative methods by assigning numerical

values to Liker-type scales.

 Results are generally easier (than qualitative techniques) to analyze.

 Pretest/Posttest can be compared and analyzed.

2.2.2 Observations

 Responses can be analyzed with quantitative methods by assigning numerical

values to Likert-type scales

 Results are generally easier (than qualitative techniques) to analyze

 Allows for the study of the dynamics of a situation, frequency counts of target
behaviors, or other behaviors as indicated by needs of the evaluation.

 Good source for providing additional information about a particular group can
use video to provide documentation.

 Can produce qualitative (e.g., narrative data) and quantitative data (e.g.,
frequency counts, mean length of interactions, and instructional time).

2.2.3Interviews

 Interviews can be conducted in person or over the telephone.

 Interviews can be done formally (structured), semi-structured, or informally.

Digital Class Room 9

Chapter 2 System Analysis

 Questions should be focused, clear, and encourage open-ended responses.

 Interviews are mainly qualitative in nature.

2.2 Existing System: Data Analysis

Analysisofdata is a process of inspecting, cleansing, transforming, and

modeling data with the goal of discovering useful information, suggesting
conclusions, and supporting decision-making. Data analysis has multiple facets and
approaches, encompassing diverse techniques under a variety of names, in different
business, science, and social science domains.

Data mining is a particular data analysis technique that focuses on modeling and
knowledge discovery for predictive rather than purely descriptive purposes. Business
intelligence covers data analysis that relies heavily on aggregation, focusing on
business information. In statistical applications, some people divide data analysis into
descriptive statistics, exploratory data analysis (EDA), and confirmatory data analysis
(CDA). EDA focuses on discovering new features in the data and CDA on confirming
or falsifying existing hypotheses. Predictive analytics focuses on application of
statistical models for predictive forecasting or classification, while text analytics
applies statistical, linguistic, and structural techniques to extract and classify
information from textual sources, a species of unstructured data. All are varieties of
data analysis.

Data integration is a precursor to data analysis, and data analysis is closely linked to
data visualization and data dissemination. The term data analysis is sometimes used as
a synonym for data modeling.

2.2.1 Data Flow Diagrams (DFDs)

A data flow diagram (DFD) is a graphical representation of the "flow" of data

through an information system, modeling its process aspects. A DFD is often used as a
preliminary step to create an overview of the system, which can later be elaborated.
DFDs can also be used for the visualization of data processing (structured design).

Digital Class Room 10

Chapter 2 System Analysis

A DFD shows what kind of information will be input to and output from the system,
where the data will come from and go to, and where the data will be stored. It does not
show information about the timing of process or information about whether processes
will operate in sequence or in parallel.

Data flow diagrams are also known as bubble charts. DFD is a designing tool used in
the top-down approach to Systems Design. This context-level DFD is next "exploded",
to produce a Level 1 DFD that shows some of the detail of the system being modeled.
The Level 1 DFD shows how the system is divided into sub-systems (processes), each
of which deals with one or more of the data flows to or from an external agent, and
which together provide all of the functionality of the system as a whole. It also
identifies internal data stores that must be present in order for the system to do its job,
and shows the flow of data between the various parts of the system.

Data flow diagrams are one of the three essential perspectives of the structured-
systems analysis and design method SSADM. The sponsor of a project and the end
users will need to be briefed and consulted throughout all stages of a system's
evolution. With a data flow diagram, users are able to visualize how the system will
operate, what the system will accomplish, and how the system will be implemented.
The old system's dataflow diagrams can be drawn up and compared with the new
system's data flow diagrams to draw comparisons to implement a more efficient
system. Data flow diagrams can be used to provide the end user with a physical idea of
where the data they input ultimately has an effect upon the structure of the whole
system from order to dispatch to report. How any system is developed can be
determined through a data flow diagram model. In the course of developing a set of
leveled data flow diagrams the analyst/designer is forced to address how the system
may be decomposed into component sub-systems, and to identify the transaction data
in the data model. Data flow diagrams can be used in both Analysis and Design phase
of the SDLC. The DFD is describes as follows:

Digital Class Room 11

Chapter 2 System Analysis

1. DFD for Admin Panel

It is a data flow diagram for admin level 1.

Data Flow Diagram for Admin Level1

Add info

Records Add Teacher Profile Profile Record

Get info

Get data Add data Get Info Add Data

Add Data
Get Info Assign
Remove
Get Data Course
Course Add data
Admin
Authenticate Get info Add payment
Add info Get info
Level Add data
Get payment

Course Record
Add Data Get Data
Add Data Get Data

Record
Add New Course Login

Get info Links

Get data Add data

Record
Course Record

Figure 2-1: DFD for Admin Panel

This is a data flow diagram of admin panel. DFD describe admin works that will be
performed. Admin will be add course, remove course, add new course, and login
process.

2. DFD for Teacher Panel

Digital Class Room 12

Chapter 2 System Analysis

It is a data flow diagram for teacher level 1.

Data Flow Diagram for Teacher Level1

Add info

Records Upload Assignment Assignment Record

Get info

Get data Add data Get Info Add Data

Add Data
Get Info
Alert Student
Add Student Get Data
Add data
Teacher
Upload Get info Add payment
Add info Get info
Lecture Add data
Get payment

Record
Add Data Get Data
Add Data Get Data

Assignment
Record Upload Upload Marks
Attendance Sheet

Get info Links

Get data Add data

Attendance Record
Record

Figure 2-1: DFD for Teacher Panel

This is data flow diagram of teacher panel. Teacher will be upload assignment, upload
mark sheet, upload attendance and also upload lectures.

3. DFD for Student Panel

It is a data flow diagram for student level 1.

Digital Class Room 13

Chapter 2 System Analysis

Data Flow Diagram for Student Level1

Add info
Download
Records Assignment Record
Assignment Get info

Get data Add data Get Info Add Data

Add Data
Get Info
Download Select Subject
Lecture Get Data
Add data
Student
Download Add info Get info
Get info Add payment
Attendance
Sheet Add data
Get payment

Subject Record
Add Data Get Data
Add Data Get Data

Attendance
Record Download
Material Login
Resourse

Get info Links

Get data Add data

Record
Material Record

Figure 2-3: DFD for Student Panel

This is data flow diagram for student panel. Student will be login, download lectures,
download attendance sheet and also download assignment.

2.2.2 Requirements Engineering

Digital Class Room 14

Chapter 2 System Analysis

Requirements engineering (RE) refers to the process of defining,

documenting and maintaining requirements to the sub-fields of systems engineering
and software engineering concerned with this process.

The first use of the term requirements engineering was probably in 1979 in a TRW
technical report but did not come into general use until the 1990s with the publication
of an IEEE Computer Society tutorial and the establishment of a conference series on
requirements engineering that has evolved into the current International Requirements
Engineering Conference.

In the waterfall model, requirements engineering is presented as the first phase of the
development process. Later software development methods, including the Rational
Unified Process (RUP), extreme programming (XP) and Scrum assume that
requirements engineering continues through the lifetime of a system.

Requirements engineering activities

The activities involved in requirements engineering vary widely, depending on the

type of system being developed and the specific practices of the organization(s)
involved. These may include:

1. Requirements inception or requirements elicitation.

2. Requirements identification - identifying new requirements.

3. Requirements analysis and negotiation - checking requirements and resolving

stakeholder conflicts.

4. Requirements specification (e.g., software requirements specification; SRS)

documenting the requirements in a requirements document.

5. Systems modeling - deriving models of the system, often using a notation such as
the Unified Modeling Language (UML) or the Lifecycle Modeling Language
(LML).

Digital Class Room 15

Chapter 2 System Analysis

6. Requirements validation - checking that the documented requirements and models

are consistent and meet stakeholder needs.

7. Requirements management - managing changes to the requirements as the system

is developed and put into use.

These are sometimes presented as chronological stages although, in practice, there is

considerable interleaving of these activities.

2.2.3 Deliverables

Deliverable is a term used in project management to describe a tangible or

intangible product or service produced as a result of the project that is intended to be
delivered to a customer (either internal or external). A deliverable could be a report, a
document, a software product, a server upgrade or any other building block of an
overall project.

A deliverable may be composed of multiple smaller deliverables. It may be either an

outcome to be achieved (as in "The Corporation says that becoming profitable this
year is a deliverable.") or an output to be provided (as in "The deliverable for the
completed project consists of a special-purpose electronic device and its controlling
software.").

A deliverable differs from a project milestone in that a milestone is a measurement of

progress toward an output, whereas the deliverable is the result of the process. For a
typical project, a milestone might be the completion of a product design, while the
deliverable might be the technical diagram or detailed design report of the product.

A deliverable is more than just a project document in that a project document is

typically part of a project deliverable. A project deliverable may contain a number of
documents and physical things.

Digital Class Room 16

Chapter 2 System Analysis

In technical projects, deliverables can be further classified as hardware, software, or

design documents. In contracted efforts, deliverable may refer to an item specifically
required by contract documents, such as an item on a Contract Data Requirements List
or mentioned in the statement of work (SoW).

A deliverable is something (hard or soft) that can be ready to dispatch to the site or the
client as a partial item of the supply foreseen in the contract, e.g. when the project has
started some part of the design (when settled), can be anticipated to the sub-supplier
who has therefore the possibility of starting his purchase activity of raw material, even
if many other parameters are not yet designed by the designer.

In this way many time-savings are possible, shortening greatly the whole project final
supply term. This designing activity can be represented in the drawings with a "cloud"
around a not yet designed part and means: "this part (size or other characteristics) will
be studied later". The part settled can be "delivered" to the interested parties.
Deliverables are including the following:

 Software Requirement Specification

 Software Methodology and Work Plan

 Software Design

 Coding

 Testing

 Viva and voice

Digital Class Room 17