CHAPTER 3.

1 :
CONDUCT PRELIMINARY
ANALYSIS
DFC3043 SYSTEM ANALYSIS AND DESIGN
Learning Outcomes
3.1 Conduct Preliminary analysis
3.1.1 Identify the system requirements
3.1.2 Explain the techniques used in fact finding
3.1.3 Use the appropriate fact-finding technique
3.1.4 Analyze the gathered information based on the technique used
3.1.5 List and describe system requirements, including outputs, inputs, processes, performance and controls
3.1.6 (FDD) to model business functions and processes
3.1.7 Describe the Unified Modeling Language (UML) and examples of UML diagrams
3.1.8 Develop effective documentation methods to use during systems development.
System Analysis
The overall objective of the systems analysis phase is to
understand the proposed project, ensure that it will
support business requirements, and build a solid
foundation for system development. In this phase, you use
models and other documentation tools to visualize and
describe the proposed system.
Systems Analysis Activities
Data and process modeling
Object Modeling
Development Strategies
System requirements document
CHAPTER 3.1.1
IDENTIFY THE SYSTEM REQUIREMENTS
3.1.1 Identify the system requirements
A system requirement is a characteristic or feature that must be included in an information
system to satisfy business requirements and be acceptable to users.
System requirements serve as benchmarks to measure the overall acceptability of the
finished system.

Input Output Process

Performance Control
System Requirements Checklist
Outputs
Eg:
The Web site must report online volume statistics every four
hours, and hourly during peak periods
The inventory system must produce a daily report showing the
part number, description, quantity on hand, quantity allocated,
quantity available, and unit cost of all sorted by part number

6
System Requirements Checklist
Inputs
Eg: Manufacturing employees must swipe their ID cards into
online data collection terminals that record attendance.
This will be translate into labor costs and calculate production
efficiency analysis.
The department head must enter overtime hours on a separate screen

7
System Requirements Checklist
Processes
Eg:
The student records system must calculate the GPA at the end of
each semester
As the final step in year-end processing, the payroll system must
update employee salaries, bonuses, and benefits and produce tax
data required.

8
System Requirements Checklist
Performance
Eg:
The system must support 25 users online simultaneously
Response time must not exceed four seconds

9
System Requirements Checklist
Controls / Security
The system must provide logon security at the operating system
level and at the application level
WIFI password
Log in counter. For example max 3 attempts.
How long password need to change. Example.. every 1 quarter of the
year
An employee record must be added, changed, or deleted only by a
member of the human resources department / or system
administrator.

10
CHAPTER 3.1.2 & 3.1.3
EXPLAIN THE TECHNIQUES USED IN FACT FINDING.
USE THE APPROPRIATE FACT FINDING TECHNIQUE.
Who, What, Where, When, How, and Why?

From whom Quality of Analyst

Analyst will obtain some
information from people who
will be using the system , the
end users.
The analyst must have
knowledge and be experienced
in the business area which he
or she is gathering information
about.

What to gather
The analysis phase involves gathering a
considerable amount of information.
Information may include : the business rules
and the various processes involved in a
particular system under investigation.
#1 - Interviews
Step 1: Determine the People to
Interview
Informal structures

Step 2: Establish Objectives for the

Interview
Determine the general areas to be discussed
List the facts you want to gather

13
#1 -Interviews
Step 3: Develop Interview Questions
Creating a standard list of interview questions helps to keep you
on track and avoid unnecessary tangents
Avoid leading questions
Leading question example: Was the system launch on of July 2015?
Open-ended questions
Example using What, Why, How
What do you think about Why we need to improve
Closed-ended questions
Normally the answer is either Yes or No

14
#1 -Interviews
Step 4: Prepare for the Interview
Careful preparation is essential because an interview is an
important meeting and not just a casual chat
Limit the interview to no more than one hour
Send a list of topics ( so that he/she is prepared)
Ask the interviewee to have samples available

15
#1 -Interviews
Step 5: Conduct the Interview
Develop a specific plan for the meeting
Begin by introducing yourself, describing the project, and
explaining your interview objectives
Engaged listening
Allow the person enough time to think about the question
After an interview, you should summarize the session and seek a
confirmation

16
#1 - Interviews
Step 6: Document the Interview
Note taking should be kept to a minimum
After conducting the interview, you must record the information
quickly
After the interview, send memo to the interviewee expressing
your appreciation
Note date, time, location, purpose of the interview, and the main
points you discussed so the interviewee has a written summary
and can offer additions or corrections

17
Interviews
Step 7: Evaluate the Interview
double check statement vs actual
In addition to recording the facts obtained in an interview, try to
identify any possible biases
Unsuccessful Interviews
No matter how well you prepare for interviews, some are not
successful

18
Other Fact-Finding Techniques
#2 -Document Review
#3 -Observation
Seeing the system in action gives you
additional perspective and a better
understanding of the system procedures
Plan your observations in advance
Hawthorne Effect

19
Other Fact-Finding Techniques
#4 - Questionnaires and Surveys
When designing a questionnaire, the most important rule of all is to
make sure that your questions collect the right data in a form that
you can use to further your fact-finding
Fill-in form

20
Other Fact-Finding Techniques
#5 -Sampling
Systematic sample
For example, if you wanted to select a random group of 1,000 end products from a
50,000 end products using systematic sampling, you would simply select every 50th end
products, since 50,000/1,000 = 50.
Stratified sample
Example:
total collage graduates in US in year 2015 is 1.7M.
Strata sample is conducted based on sampling size with
Percentage same as the population breakdown by ethnics

Random sample ( eg: soap factory: empty boxes detection solutions story)
Main objective of a sample is to ensure that it represents the overall population
accurately
21
Other Fact-Finding Techniques
#6- Research
Can include the Internet, IT
magazines, and books to obtain
background information, technical
material, and news about industry
trends and developments
Site visit

22
CHAPTER 3.1.6
(FDD) TO MODEL BUSINESS FUNCTIONS AND PROCESSESS
What is Functional Decomposition
Diagram?
FDD is a top-down representation of a function or process.
Decomposition is the process of breaking complex entities into smaller sub-parts, and then
breaking those smaller parts down even more, until the complex entity has been broken
down into more discreet components with a more understandable structure.
Function Decomposition
the decomposition of
functions and processes
corresponds to the levelling
of DFDs
1.0 2.0 3.0

1.1 1.2

1.2.1 1.2.2
FDD example
The following are simple examples of each documentation type using the idea of a functional
breakdown of the drive-thru window of a typical fast food restaurant.
Advantages and Disadvantage of FDD
Functional Decomposition is an intuitive process is internally focused (what are we currently
for most people and is readily understood by the
customer.
Helps to discover duplicate or overlapping
activities.
Breaks complex systems into relatively separate
components, which can help with scope,
development, and planning.
doing versus what should we be doing)
It can be easy to define too much detail.
There is no way to be sure that every necessary
component has been captured and properly
related.
It is very easy to conflate a functional diagram
with an organizational diagram (especially for
stakeholders). This can make it easy to overlook
interdependencies where there may be high
levels of coupling to functions that were not
diagramed on other organizational units, or
where multiple organizational units are involved
in the function that was diagrammed.
Exercise
CLO2. Produce the key deliverables of System Development Life Cycle (SDLC) activities. (P4, C3, PLO2, PLO1)

Analyse the given short case and draw a Functional Decomposition Diagram (FDD) based on the case.

Nadia who is UTHM IT Diploma students, currently attending the internship

programs for five months in a computer services and sales shop in Penang.
Her main task in the shop is to manage the inventory and sale system. The
system records all the products and sales services information and provide
monthly and annually profit reports. In addition, the system helps the owner to
identify stocks and inventory available.
CHAPTER 3.1
3.1.7 DESCRIBE THE UNIFIED MODELING LANGUAGE
(UML) AND EXAMPLES OF UML DIAGRAMS
What Is UML?
The Unified Modelling Language (UML) is a widely used method of visualizing and
documenting software systems design.
UML uses object-oriented design concepts but it is independent of any specific programming
language.
UML provides various graphical tools (Use case diagram and sequence diagram)
System analyst can utilize UML to represent the information system from a users viewpoint.
Use case diagram
Use case diagrams are used to gather the requirements of a system including internal and
external influences. These requirements are mostly design requirements. Hence, when a
system is analysed to gather its functionalities, use cases are prepared and actors are
identified.
When the initial task is complete, use case diagrams are modelled to present the outside view.
In brief, the purposes of use case diagrams can be said to be as follows
i. Used to gather the requirements of a system.
ii. Used to get an outside view of a system.
iii. Identify the external and internal factors influencing the system.
iv. Show the interaction among the requirements are actors.
How to Draw a Use Case Diagram?
When we are planning to draw a use case diagram, we should have the following items
identified.
i. Functionalities to be represented as use case
ii. Actors
iii. Relationships among the use cases and actors.
How to Draw a Use Case Diagram?
After identifying the above items, we have to use the following guidelines to draw an efficient
use case diagram
i. The name of a use case is very important. The name should be chosen in such a way so
that it can identify the functionalities performed.
ii. Give a suitable name for actors.
iii. Show relationships and dependencies clearly in the diagram.
iv. Do not try to include all types of relationships, as the main purpose of the diagram is to
identify the requirements.
v. Use notes whenever required to clarify some important points.
How to Draw a Use Case Diagram?
Following is a sample use case diagram
representing the order management system.
Hence, if we look into the diagram then we will
find three use cases (Order, SpecialOrder, and
NormalOrder) and one actor which is the
customer.
The SpecialOrder and NormalOrder use cases
are extended from Order use case. Hence, they
have extended relationship.
Another important point is to identify the
system boundary, which is shown in the picture.
The actor Customer lies outside the system as it
is an external user of the system.