Analyzing requirement stage identifies user information needs
and new systems requirements IS dev team responsibility to ensure
the new system serve the needs of org Determining accurate user
needs and system requirement is important because the design of new
system is based on these requirements
Slide 3
Structured analysis, a dominant technique for documenting user
requirements It provides methods to analysts for analyzing,
organizing, controlling and documenting large complex IS Structured
analysis is appropriate for business IS because these systems are
predominantly data-driven systems To document IS data and data
transformation, structured analysis uses Data Flow Diagram
Slide 4
Description of system problems and solutions are written in
narrative form Graphic presentations may be used to enhance the
problem description Data flow diagram is a graphic presentation of
external entities, data movement, processing functions and data
stores necessary to support an IS DFD is popularized using
structured analysis and design approach The purpose of diagramming
is that any person would be able to understand the system by just
looking at the diagram
Slide 5
Four symbols used in DFD (Yourdon symbols): A circle Indicate
some process or transformation of data Process shows what a system
does Each process has data input and output A process name should
consist of one single phrase and should define a specific action
rather than general process The name and number appear inside the
circle A pair of parallel lines To indicate data store Process can
enter data or retrieve data from data store
Slide 6
A rectangle To indicate external entity Entity person,
department, system or org out of the system The system interacts
with these entities An arrow Indicate flow of data Arrow pointing
to a data store indicates writing or updating to data store Arrow
coming out of data store shows reading process
Slide 7
DFD are organized hierarchically There is a master DFD (context
DFD) followed by subDFD Context DFD First diagram that displays the
least amount of detail Used to identify system boundary and its
relationship to the entities Has only one process labeled with the
systems name The entities that interact with the system are shown
with their labeled data flows No data stores are shown
Slide 8
Context DFD show system in general, therefore there is a need
to explode into other DFD Intermediate DFD will show the sequence
of processes done by the system together with data stores accessed
by the processes Each process is given number depicting their
sequence of occurrence An important characteristics of all DFD:
anything represented on the previous level must also be represented
on all levels that follow All entities in context DFD must also
appear on all levels that follow
Slide 9
It is not a good idea to include all details in one DFD because
it would be too large It would be too large that it would be
difficult to understand and the DFD then no longer serve as a comm
tool This is why the context level DFD needs to explode into
intermediate DFD The processes must be numbered to show sequence in
which they are being performed The process name should define a
specific action rather than a general process
Slide 10
Data stores not shown in context DFD are drawn in intermediate
DFD When naming a data store, use specific names and avoid general
terms The DFD does not indicate which media the data are being
stored
Slide 11
What is a good DFD? The word in the process symbol in the
context DFD is the name of the system Context DFD should possess
one process symbol only Data store symbols should not appear in the
context DFD The first word in the process symbol in intermediate
DFD must begin with a verb followed by a descriptive noun
Slide 12
Processes must be numbered Label clearly all data flows,
entities, data stores and processes. No need to label data flows
from process to process but it is a good practice to do so The
arrow direction for the data flows must be correct Crossing of
lines will not be allowed. You are to duplicate entities and data
stores where necessary No incorrect connections
Slide 13
Characteristics of good diagrams Should be graphical with
supporting textual detail Should allow the system to be viewed
top-down, partitioned fashion Should have minimal redundancy
Slide 14
Two technologies offering increase in productivity of IS dev
are Computer aided software engineering (CASE) Object-oriented
development technology CASE assist IS dev team in planning,
analyzing, designing, programming and maintaining IS The principal
advantage of CASE is that it offers an integrated packages of
capabilities for several of these tasks
Slide 15
CASE provides automatic assistance for checking the consistency
and completeness of the system The availability of this info makes
it easier to introduce modifications in a consistent manner at any
time during dev or maintenance phase CASE provides good platform
for quick app dev through prototyping. It helps to dev hierarchy of
menus for the user interface and specify screens and reports all
done in consultation with the users of the system
Slide 16
Prototyping tools include report writers, query languages,
screen generators and 4GL A report writer is a nonprocedural
language for producing reports from data in a data base A query
language is a nonprocedural language for retrieving, sorting adding
and presenting data from a database a screen generator is a
software for generating and maintaining display and data entry for
screen forms A program generator is a software toll that generates
a second or third language program 4GL has both procedural and
nonprocedural features allowing programmers to write programs
faster and accurately
Slide 17
A central repository stores, analyzes, updates and reports on
the info about the system. The central repository can be used to
analyze the DFD for balance and also print a report of the DFD
Command can be issued to delete components of DFD or manipulate the
positions of the components Processes can be expanded into lower
level DFD
Slide 18
A data design tool will assist in design phase to model files
and database CASE will maintain Entity Relationship Diagram (ERD)
of the system Tools will make up the various input modes An
evaluation mode is available to check models for consistencies or
to suggest changes A reporting mode is used to produce listings and
describe the model object sets and attributes to draw ERD A
generation mode will help create database definitions from the
model
Slide 19
The user input the ERD by entering all known attributes as a
volume input ERD itself will be drawn by entering the entity and
the relationship sets and adding attributes to them The modeling
tool guides the user towards developing a model A programming tool
will assist in writing out the programs which include code
generators, program debuggers and testing modules A project mgt
tool assists in scheduling the IS project
Slide 20
CASE contribute to improving maintenance of IS The use of CASE
during early task means better documented systems in repository and
thus easy to maintain It is possible to trace a user request for an
enhancement from DFD to program coding modules and determine the
impact of changes CASE makes it possible to maintain system
specification as they are changed during maintenance
Slide 21
CASE is a complex technology requiring learning The complexity
of CASE and lack of integrated support limited the adoption CASE
tools make systems dev team better and more effective but they are
not a substitute Skills and experience cannot be automated
Slide 22
Management together with system steering committee will review
the analysis report The review is to determine if work on the
proposed system should proceed to the next phase The problems
identified and solutions to overcome will be documented in the
systems analysis report together with the diagrams used to document
the existing system You may also need to present the analysis
findings