UKAI 2063

Accounting
Information Systems II
Lecture 5
Fact Finding Techniques

5-1
 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

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
■If you 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