Chapter Five
System Analysis
Systems analysis is a process of collecting factual data, understand the processes involved,
identifying problems and recommending feasible suggestions for improving the system
functioning. This involves studying the business processes, gathering operational data,
understand the information flow, finding out bottlenecks and evolving solutions for overcoming
the weaknesses of the system so as to achieve the organizational goals. System Analysis also
includes subdividing of complex process involving the entire system, identification of data store
and manual processes.
• (Who uses system, what will it do, where and when will the system be used?)
• The major objectives of systems analysis is to find answers for each business process,
such as (Who uses system, what will it do, where and when will the system be used?)
Determining System Requirement
Requirements determination involves studying the existing system and gathering details to find
out what are the requirements, how it works, and where improvements should be made.
Requirements determination involves studying the existing system and gathering details to find
out what are the requirements, how it works, and where improvements should be made.
Requirement is a statement of what the system must do or a characteristic it must have. It will
later evolve into a technical description of how the system will be implemented. Requirements
are best determined by systems analysts and business people together. Requirements are best
determined by systems analysts and business people together.
Types
Functional: relates to a process or data and
Non-functional: relates to performance or usability
Techniques for identifying requirements
Interviews, questionnaires and/or observation
Joint application development (JAD)
Document analysis
Interviews
Most popular technique—if you need to know something, just ask
Process:
Select people to interview & create a schedule
Design interview questions (Open-ended, closed-ended, & probing types of
questions)
Prepare for the interview (Unstructured vs. structured interview organized in a
logical order)
Conduct the interview (Top-down vs. bottom-up)
Follow-up after the interview
Question Types
Joint Application Development (JAD)
JAD sessions are usually held in special-purpose rooms. These rooms are typically equipped
with whiteboards (possibly electronic, with a printer to make copies of what is written on the
board and others.
Meetings can be held electronically and anonymously
Reduces problems in group settings
Can be held remotely
Sessions require careful planning to be successful
Users may need to bring documents or user manuals
Ground rules should be established
The following is a list of typical JAD participants:
JAD session leader: The JAD leader organizes and runs the JAD- facilitator of the
meeting
Users: The key users of the system under consideration are vital participants in a JAD
Managers: Managers of the work groups who use the system in question provide insight
into new organizational directions, motivations for and organizational impacts of
systems, and support for requirements determined during the JAD.
Sponsor: As a major undertaking, because of its expense, a JAD must be sponsored by
someone at a relatively high level in the company such as a vice president or chief
executive officer.
Systems analysts: Members of the systems analysis team attend the JAD, although their
actual participation may be limited. Analysts are there to learn from users and managers,
not to run or dominate the process.
Scribe: The scribe takes notes during the JAD sessions, usually on a personal computer
or laptop.
IS staff: Besides systems analysts, other IS staff, such as programmers, database
analysts, IS planners, and data-center personnel, may attend the session. Their purpose is
to learn from the discussion and possibly to contribute their ideas on the technical
feasibility of proposed ideas or on the technical limitations of current systems.
Meeting session in a JAD
Questionnaires
A set of written questions used to obtain information from individuals
May be paper based or electronic (e.g., web based)
Common uses:
Large numbers of people
Need both information and opinions
When designing for use outside the organization (customers, vendors, etc.)
Typical response rates: < 50% (paper); < 30% (Web)
Questionnaire Steps
Select the participants
Identify the population
Use representative samples for large populations
Designing the questionnaire
Careful question selection
Remove ambiguities
Administering the questionnaire
Working to get good response rate
Offer an incentive (e.g., a free pen)
Questionnaire follow-up
Send results to participants
Send a thank-you
Good Questionnaire Design
Begin with non-threatening and interesting questions
Group items into logically coherent sections
No important items at the very end
Do not crowd a page with too many items
Avoid abbreviations
Avoid biased or suggestive items or terms
Number questions to avoid confusion
Pretest to identify confusing questions
Document Analysis
Review technical documents when available
Review typical user documents:
Forms
Reports
Policy manuals
Look for user additions to forms
Look for unused form elements
Observation
Users/managers often don’t remember everything they do
Checks validity of information gathered in other ways
Behaviors may change when people are watched
Workers tend to be very careful when watched
Keep a low profile
Try not to interrupt or influence workers
Be careful not to ignore periodic activities
Weekly … Monthly … Annually
Prototyping
Prototyping is a means of exploring ideas before you invest in them. Most system developers
believe that the benefits from early usability data are at least ten times greater than those from
late usability data. Prototyping allow system analysts quickly show users the basic requirement
into a working version of the desired information system. After viewing and testing the
prototype, the users usually adjust existing requirements to new ones. The goal with using
prototyping to support requirement determination is to develop concrete specification for the
ultimate system, not to build the ultimate system from prototyping.
Requirements Structuring
Requirements structuring is the process to use some kind of systematical and standard, well-
structured methods to model the real world. Traditionally, we use data flow diagram for process
modeling, decision table or decision tree for logic modeling, and Entity-relationship diagram for
conceptual data modeling. The process model is a core diagram in structured analysis and design.
Also called a data flow diagram (DFD), it shows the flow of information through a system. Each
process transforms inputs into outputs. Flow lines represent data flowing between nodes
including processes, external entities and data stores. The logic model is a beneficial evaluation
tool that facilitates effective program planning, implementation, and evaluation. For example,
Logic modeling using decision tree is a sequence of queries or tests that are done adaptively, so
the outcome of the previous tests can influence the test is performed next. Conceptual modeling
in ERD models the business objects that should exist in a system and the relationships between
them.
Data flow diagram (DFD) is a graphical tool that allows analysts (and users) to depict the flow
of data in an information system. DFD 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.
In a DFD, there are only four symbols that represent the same things: data flows, data stores,
processes, and source/sinks (or external entities). A data flow can be best understood as data in
motion, moving from one place in a system to another. A data store is data as rest, which may
take the form of many different physical representations. A process is the work or actions
performed on data so that they are transformed, stored, or distributed. Source/sink is the origin or
destination of data, sometimes referred to as external entities.
DFD Symbols
Process: Manual or computerized work or actions performed on data (inside the system)
so that they are transformed, stored or distributed.
Data store: Place where data is kept(Manual or computerized).Data at rest (inside the
system).
• File folder, computer-based file.
Source/sink: Environmental element(i,e., external entities/agents) that is origin or
destination of data (outside the system)
• An organizational unit, person, information system.
Data flow: Data that travels together (i.e., a report, a form, a fax). Arrows depicting
movement of data, labeled with a meaningful name for the data in motion (customer
order).
Data Flow Diagramming Rules
Data Flow Rules
Data flow from a process to a data store means update (insert, delete or change).
Data flow from a data store to a process means retrieve or use.
Data flow labels should be noun phrases.
DFD Levels
Context DFD
• Overview of the organizational system
Level-0 DFD
• Analyst must determine which processes are represented by the single process in
the process diagram
• Representation of system’s major processes at high level of abstraction
Level-1 DFD
• Results from decomposition of Level 0 diagram
Level-n DFD
• Results from decomposition of Level n-1 diagram
Level-0 DFD shows the system’s major processes, data flows, and data stores at a high level of
abstraction.
In process 1.0, order is processed, four streams of data result.
Level-n DFD is the result of n nested decompositions from a process on a level-0 diagram
Level 2 diagram showing the decomposition of Process 4.3 from the level-1 diagram for Process 4.0
Second, logic Modeling involves representing the internal structure and functionality of the
processes represented on data flow diagrams. In the analysis phase, logic modeling will be
complete and reasonably detailed, but it will also be generic in that it will not reflect the structure
or syntax of a particular programming language. There are three traditional tools for logic
modeling: structure English, decision tables and decision trees.
Structured English is modified form of the English language used to specify the logic of
information system processes. It is use of the English language to describe the steps of an
algorithm in clear, unambiguous statements that can be read from start to [Link] there is
no single standard, structured English typically relies on action verbs and noun phrases and
contains no adjectives or adverbs. It Uses and capitalize accepted keywords such as IF, THEN,
ELSE, DO, DO WHILE, DO UNTIL, and PERFORM.
Example
Decision Structure Only IF a condition is true,
Complete the following statements; otherwise, jump to the ELSE
IF Condition A is True THEN implement Action A
ELSE implement Action B ENDIF
A Decision Table is a table that shows the relationship between inputs and rules, cases, and test
conditions. Decision table is a matrix representation of the logic of a decision, which specifies
the possible conditions for decision and the resulting actions. Usually, there are there parts in a
decision table: the condition stubs, the action stubs, and the rules. A decision tree is a graphical
technique that depicts a decision or choice situation as a connected series of nodes and branches.
Decision trees have two main components: decision points and actions. Nodes represent decision
points, while actions are represented by oval.
Example 1 − How to Create a Login Screen Decision Base Table
Let's make a login screen with a decision table. A login screen with E-mail and Password Input
boxes.
The condition is simple-The user will be routed to the homepage if they give the right username
and password. An error warning will appear if any of the inputs are incorrect.
Conditions Rule 1 Rule 2 Rule 3 Rule 4
Username (T/F) F T F T
Password (T/F) F F T T
Output (E/H) E E E H
Legend
T - Make sure your login and password are correct.
F - Incorrect login or password
E - An error message appears.
H - The home screen appears.
Interpretation
Case 1 − Both the username and password were incorrect. An error message is displayed
to the user.
Case 2 − The username and password were both right, however, the password was
incorrect. An error message is displayed to the user.
Case 3 − Although the username was incorrect, the password was accurate. An error
message is displayed to the user.
Case 4 − The user's username and password were both accurate, and the user went to the
homepage.
We may generate two situations when converting this to a test case.
Enter the right username and password and click Login; the intended consequence is that
the user will be sent to the homepage.
And one from the situation below.
If the user types in the erroneous username and password and then clicks Login, the user
should receive an error message.
When you provide the proper username and incorrect password and click Login, the user
should see an error message.
If the user types the erroneous username and password and then clicks Login, the user
should receive an error message.
A decision tree is a very specific type of probability tree that enables you to make a decision
about some kind of process. For example, you might want to choose between manufacturing item
A or item B, or investing in choice 1, choice 2, or choice 3.
Entity-relationship (E-R) diagramming is the most common format for data modeling. E-R data model is
a detailed, logical representation of the data for organization or for a business area. An Entity
Relationship Diagram (ER Diagram) pictorially explains the relationship between entities to be stored in a
database. Fundamentally, the ER Diagram is a structural design of the database. It acts as a framework
created with specialized symbols for the purpose of defining the relationship between the database
entities. ER diagram is created based on three principal components: entities, attributes, and relationships.
An entity is a person, place, object event, or concept in the user environment about which the
organization wishes to maintain data. Each entity type has a set of attributes associated with it. An
attribute is a property or characteristic of an entity that is of interest to the organization. Relationships are
the glue that holds together the various components of an E-R model. A relationship is an association
between the instances of one or more entity types that is of interest to the organization.
ER-Diagram Symbols and their Representations
ER-Diagram Symbols and Notations
Sales Model ER-Diagram