UKAI 2063

Accounting
Information Systems II
Lecture 5
Fact Finding Techniques
 Lecture 5 Outline
■Requirements discovery & fact-finding techniques

■Interview,document review, observation, surveys,

and questionnaires, sampling, and research

5-2
Source: http://www.umsl.edu/~sauter/analysis/random_analysis_thoughts.html5 - 3
“Every project succeeds or fails on the quality of its
requirements. They set the scope of all subsequent
work and tell the project team what the users want.
Without good requirements, projects fail, are late,
come in over budget, or produce systems that are
never used” (Alexander and Stevens, 2002).

“Requirement issues should be fixed early, before

committing to a design, because problems
caused by poor requirements tend to be deeply
embedded in the design and are difficult to
remedy afterwards” (Alexander and Stevens,
2002).
5-4
 Phase Description
 Systems analysis is the second of five phases
in the systems development life cycle (SDLC)
 Will use requirements modeling, data and
process modeling, and object modeling
techniques to represent the new system
 Will consider various development strategies
for the new system, and plan for the transition
to systems design tasks

5-5
 Systems Analysis Phase
Overview
 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
 You use models and other documentation tools
to visualize and describe the proposed system

5-6
Systems Analysis Phase
Overview
 Systems Analysis
Activities
 Requirements
modeling
 Outputs
 Inputs

 Processes

 Performance

 Security

5-7
 Systems Analysis Phase
Overview
 Systems Analysis Activities
 Data and process modeling
 Object Modeling

 Development Strategies
 System requirements document

5-8
 Systems Analysis Phase
Overview
 Systems Analysis Skills
 Analytical skills
 Interpersonal skills

 Team-Oriented Methods and Techniques

 Joint application development (JAD)
 Rapid application development (RAD)

 Agile methods

5-9
What is a requirement?
A requirement is a condition or capability that must
be met or possessed by a system or system component
to satisfy a contract, standard, specification, or other
formally imposed documents.

A well-formed requirement is a statement of system

functionality (a capability) that must be met or
possessed by a system to satisfy a customer’s need or to
achieve a customer’s objective, and that is qualified by
measurable conditions and bounded by constraints.

There are broadly two types of requirements.

5 - 10
Types of requirements
■Functional requirements.

■Non-functional requirements.

5 - 11
Functional requirements
■ A requirement that specifies an action that a
system must be able to perform, without
considering physical constraints; a requirement
that specifies input/output behavior of a system.

■The important point to note is that: WHAT is

wanted is specified, and not HOW it will be
delivered.

5 - 12
Functional requirements - some examples
■Ifyou are buying a vehicle for a business, your
functional requirement might be:
■The vehicle should be able to take a load from a warehouse
to a shop.

■Similarly for a computer system you define what the

system is to do, e.g.
■The system should store all the details of a customer’s
order.

5 - 13
Non-functional requirements
■ A requirement that specifies system properties, such
as environmental and implementation constraints,
performance, platform dependencies, maintainability,
extensibility, and reliability.

■These are the restrictions or constraints to be placed

on the system and how to build it. Their purpose is to
restrict the number of solutions that will meet a set of
requirements.

5 - 14
Non-functional requirements - some examples
■The vehicle example, without any constraints, might
result in solutions being offered for everything from a
large truck to a sports car. To restrict the types of
solutions you might include these constraints, e.g.
■It must take a load of at least one ton.

■The load area must be covered.

■The load area must have a height of at least 10 feet.

5 - 15
■For the customer records example these might be:
■Information should be made available and be stored in a
maximum of 3 seconds.

■The system should be available from 9am to 5 pm Monday

to Friday.

■The system should be able to hold a 100,000 customer

records initially.

■The system should be able to add 10,000 records a year for

10 years.

■A record should be fully available on the system for at

least 7 years.
5 - 16
Categories of non-functional requirements
■Performance requirements: a requirement that
specifies performance characteristics that a system or system
component must possess.

■External interface requirements: a requirement that

specifies hardware, software, or database elements with which
a system or system component must interface or that sets forth
constraints on formats, timing, or other factors caused by such
an interface.

Source: Parviainen, Tihinen and Solingen (2005)

5 - 17
■Design constraints: a requirement that affects or
constrains the design of a system or system component, for
example, language requirements, physical hardware
requirements, software development standards, and software
quality assurance standards.

■Quality attributes: a requirement that specifies the

degree to which a system possesses attributes that affect
quality, for example, correctness, reliability, maintainability,
portability.

Source: Parviainen, Tihinen and Solingen (2005)

5 - 18
Results of incorrect requirements
■ The system may cost more than projected.
■ The system may be delivered later than promised.
■ The system may not meet the users’ expectations
and that dissatisfaction may cause them not to use
it.
■ Once in production, the costs of maintaining and
enhancing the system may be excessively high.
■ The system may be unreliable and prone to errors
and downtime.
■ The reputation of the IT staff on the team is
tarnished because any failure, regardless of who is
at fault, will be perceived as a mistake by the team.
5 - 19
 Joint Application Development
 User Involvement
 Users have a vital stake in an information system
and they should participate fully
 Successful systems must be user-oriented, and
users need to be involved
 One popular strategy for user involvement is a
JAD team approach

20
5 - 20
 Joint Application Development
 JAD Participants and Roles

21
5 - 21
 Joint Application Development
 JAD Advantages and Disadvantages
 More expensive and can be cumbersome if the
group is too large relative to the size of the project
 Allows key users to participate effectively

 When properly used, JAD can result in a more

accurate statement of system requirements, a better
understanding of common goals, and a stronger
commitment to the success of the new system

22
5 - 22
Rapid Application Development
 RAD Phases and Activities

23
5 - 23
Rapid Application Development

24
5 - 24
Rapid Application Development
 RAD Advantages and Disadvantages
 Systems can be developed more quickly with
significant cost savings
 RAD stresses the mechanics of the system itself
and does not emphasize the company’s strategic
business needs
 Might allow less time to develop quality,
consistency, and design standards

25
5 - 25
Agile Methods

26
5 - 26
 Agile Methods
 Agile Method Advantages and Disadvantages
 Are very flexible and efficient in dealing with
change
 Frequent deliverables constantly validate the
project and reduce risk
 Team members need a high level of technical and
interpersonal skills
 May be subject to significant change in scope

27
5 - 27
Modeling Tools and Techniques
 CASE Tools
 Functional Decomposition Diagrams
 Data Flow Diagrams
 Unified Modeling Language

28
5 - 28
 System Requirements Checklist
 Outputs
 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

29
5 - 29
 System Requirements Checklist
 Inputs
 Manufacturing employees must swipe their ID
cards into online data collection terminals that
record labor costs and calculate production
efficiency
 The department head must enter overtime hours on
a separate screen

30
5 - 30
 System Requirements Checklist
 Processes
 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 by the IRS

31
5 - 31
 System Requirements Checklist
 Performance
 The system must support 25 users online
simultaneously
 Response time must not exceed four seconds

32
5 - 32
 System Requirements Checklist
 Controls
 The system must provide logon security at the
operating system level and at the application level
 An employee record must be added, changed, or
deleted only by a member of the human resources
department

33
5 - 33
 Future Growth, Costs, and
Benefits
 Scalability 可扩展性
 A scalable system offers a better return on the
initial investment 可扩展的系统可提供更好的
初始投资回报
 To evaluate scalability, you need information
about projected future volume for all outputs,
inputs, and processes 要评估可伸缩性，您需要
有关所有输出，输入和过程的预计未来量的信
息

34
5 - 34
 Future Growth, Costs, and
Benefits
• Total Cost of Ownership
– Total cost of ownership
(TCO) is especially
important if the
development team is
evaluating several
alternatives
– One problem is that cost
estimates tend to
understate indirect costs
– Rapid Economic
Justification (REJ)

35
5 - 35
 Fact-Finding
 Fact-Finding Overview
 First, you must identify the information you need
 Develop a fact-finding plan

 Who, What, Where, When, How, and Why?

 Difference between asking what is being done and
what could or should be done

36
5 - 36
 Interviews
 Step 1: Determine the People to
Interview
 Step 2: Establish Objectives for
the Interview
 Step 3: Develop Interview
Questions
 Step 4: Prepare for the Interview
 Step 5: Conduct the Interview
 Step 6: Document the Interview
 Step 7: Evaluate the Interview

 Unsuccessful Interviews
37
5 - 37
 Other Fact-Finding Techniques
• Document Review
• 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

38
5 - 38
Other Fact-Finding Techniques
 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

39
5 - 39
 Other Fact-Finding Techniques
 Sampling
 Systematic sample
 Stratified sample

 Random sample

 Main objective of a sample is to ensure that it

represents the overall population accurately

40
5 - 40
 Other Fact-Finding Techniques
 Research
 Can include the Internet,
IT magazines, and books
to obtain background
information, technical
material, and news about
industry trends and
developments
 Site visit

41
5 - 41
 Other Fact-Finding Techniques
 Interviews versus Questionnaires
 Interview is more familiar and personal
 Questionnaire gives many people the opportunity
to provide input and suggestions
 Brainstorming

 Structured brainstorming

 Unstructured brainstorming

42
5 - 42
A fact-finding strategy
Learn all you can from existing documents, forms,
reports, and files.

If appropriate, observe the system in action.

Given all the facts that you've already collected, design

and distribute questionnaires to clear up things you don't
fully understand.

5 - 43
 Documentation
 The Need for Recording the Facts
 Record information as soon as you obtain it
 Use the simplest recording method

 Record your findings in such a way that they can

be understood by someone else
 Organize your documentation so related material is
located easily

44
5 - 44
Documentation
 Software Tools
 CASE Tools
 Productivity Software
 Graphics modeling
software
 Personal information
managers
 Wireless communication
devices

45
5 - 45
 Preview of Logical Modeling
 At the conclusion of requirements modeling,
systems developers should have a clear
understanding of business processes and
system requirements
 The next step is to construct a logical model of
the system
 IT professionals have differing views about
systems development methodologies, and no
universally accepted approach exists

46
5 - 46
 Acknowledgements
This PowerPoint presentation contains
materials complied from various sources.
Credits are hereby given to their respective
owners. Please refer to the reading list for
details.

Reminder
The lecture slides serve only as a quick
learning guide. Students are required to refer
to the main textbook for detailed elaboration.

5 - 47