Systems Analysis and

Design 10th Edition

Chapter 4
Requirements Modeling
Chapter Objectives
 Describe systems analysis phase activities
 Explain joint application development (JAD),

rapid application development (RAD), and

agile methods
 Use a functional decomposition diagram

(FDD) to model business functions and

processes
 Describe the Unified Modeling Language

(UML) and examples of UML diagrams

2
Chapter Objectives (Cont.)

 List and describe system requirements, including

outputs, inputs, processes, performance, and
controls
 Explain the concept of scalability
 Use fact-finding techniques, including interviews,
documentation review, observation,
questionnaires, sampling, and research
 Define total cost of ownership (TCO)
 Conduct a successful interview
 Develop effective documentation methods to use
during systems development

3
 Systems Analysis Phase Overview
 Systems Analysis Phase Overview
◦ Understand the proposed project
◦ Ensure that it supports business requirements
◦ Build a solid foundation for system development
 Systems Analysis Activities
◦ Requirements Modeling
◦ Data and Process Modeling
◦ Object Modeling
◦ Development Strategies

4
 Systems Analysis Phase Overview
(Cont.)

 Requirements Modeling
◦ Fact-finding to describe the current
system
◦ Requirements for new system
 Data and Process Modeling
◦ Graphically represent system data
and processes
 Object Modeling
◦ Create objects to represent things,
FIGURE 4-2 The systems analysis phase consists of transactions and events
requirements modeling, data and process modeling,
object modeling, and consideration of development
strategies. Notice that the systems analysis tasks are
 Development Strategies
interactive, even though the waterfall model generally
depicts sequential development
◦ Software trends, development
alternatives, outsourcing, etc.

5
Systems Analysis Phase Overview
(Cont.)

 Systems Analysis Skills

◦ Strong analytical skills
◦ Interpersonal skills
 Team-Based Techniques: JAD, RAD, and Agile
Methods
◦ Object is to deliver the best possible system at the lowest
possible cost in the shortest possible time
◦ Joint application development brings users into the design
process
◦ Rapid application development uses a condensed version
of the system development life cycle
◦ Agile methods stress intense interaction between
developers and users

6
 Joint Application Development
 Brings users into the development process as
active participants
 User Involvement (formally or informally) created a

successful system
 JAD Participants and Roles

◦ Project leader and one or more members

◦ Participants insulated from distractions of day-to-day
operations

7
Joint Application Development
(Cont.)

FIGURE 4-3 Typical JAD participants and roles

8
Joint Application Development
(Cont.)

FIGURE 4-4 Typical agenda for a JAD session

9
Joint Application Development
(Cont.)

JAD Disadvantages
 JAD is more expensive than traditional

methods
 Can be cumbersome if group is too large

JAD Advantages
 JAD allows key users to participate effectively
 Users more likely to feel a sense of ownership
 Produces a more accurate statement of

system requirements

10
 Rapid Application Development
 Uses a group approach like JAD
 JAD produces a requirements model, RAD produces

a new system
 Complete methodology

◦ Four-phase life cycle that parallels the traditional SDLC

◦ Reduces cost and development time
◦ Increases the probability of success
◦ Relies on prototyping and user involvement
◦ Prototypes modified based on user input

11
Rapid Application Development
(Cont.)

RAD
Phases
and
Activities

FIGURE 4-5 The four phases of the RAD

model are requirements planning, user
design, construction, and cutover. Notice the
continuous interaction between the user
design and construction phases

12
Rapid Application Development
(Cont.)

 Requirements Planning
◦ Team agrees on business needs, project scope,
constraints, and system requirements
◦ Management authorization to continue is obtained
 User Design
◦ Users interact with analysts to develop models and
prototypes
◦ A combination of JAD and CASE tools are used
◦ Users understand, modify, and approve a working
model

13
Rapid Application Development
(Cont.)

 Construction
◦ Program and application development
◦ Users can suggest changes as screens or reports are
developed
 Cutover
◦ Includes data conversion, testing, changeover to the
new system, and user training

14
Rapid Application Development
(Cont.)

 RAD Objectives
◦ Cut development time and expenses by involving users in
every phase of systems development
◦ Allow the development team to make necessary
modifications quickly, as the design evolves
 RAD Advantages
◦ Systems developed more quickly with significant cost
savings
 RAD Disadvantages
◦ Does not emphasize strategic business needs (system might
work well in short term but miss long-term objectives)
◦ Less time to develop quality, consistency, and design
standards

15
 Agile Methods
 Agile methods attempt to develop a system
incrementally, by building a series of prototypes
and constantly adjusting them to user
requirements
 Developers revise, extend, and merge earlier

versions into the final product

 Emphasizes continuous feedback, and each

incremental step is affected by what was learned in

the prior steps

16
Agile Methods (Cont.)

FIGURE 4-6 Agilian supports various modeling tools, such as

the Unified Modeling Language, use cases, and business
process modeling, among others 17
 Agile Methods (Cont.)

 Scrum
◦ A rugby term
◦ Pigs include the
product owner,
the facilitator, and
the development
team
◦ Chickens include
users, other FIGURE 4-7 In a rugby scrum, team members prepare to
stakeholders, and lunge at each other to achieve their objectives
managers
◦ Scrum sessions have specific guidelines that
emphasize time blocks, interaction, and team-
based activities that result in deliverable software

18
 Agile Methods (Cont.)

 Agile Method Advantages and

Disadvantages
◦ 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

19
 Modeling Tools and Techniques
 Involves graphical methods and nontechnical
language that represent the system at various
stages of development
 Can use various tools
 Functional Decomposition Diagrams

◦ Functional decomposition diagram (FDD)

◦ Model business functions and show how they are
organized into lower-level processes

20
Modeling Tools and Techniques
(Cont.)

 Functional Decomposition
Diagrams
◦ Top-down
representation
of a function
or process
◦ Similar to an
organization
chart
FIGURE 4-8 This Visible Analyst FDD shows a library system
with five top-level functions. The Library Operations
function includes two additional levels of processes and sub
processes

21
Modeling Tools and Techniques
(Cont.)

 Business Process
Modeling
◦ Business process
model (BPM)
◦ Business process
modeling notation
(BPMN)
◦ Pool FIGURE 4-9 Using the Visible Analyst CASE tool, an
◦ Swim lanes analyst can create a business process diagram. The
overall diagram is called a pool, and the two separate
customer areas are called swim lanes

22
Modeling Tools and Techniques
(Cont.)

 Data Flow
Diagrams
◦ Data flow diagram
(DFD)
◦ show how the system
stores, processes,
and transforms data
◦ Additional levels of
information and
detail are depicted in
other, related DFDs

FIGURE 4-10 This Visible Analyst DFD shows how books

are added and removed in a library system
23
Modeling Tools and Techniques
(Cont.)

 Use Case
Diagrams
◦ Interaction between
users and the
system

FIGURE 4-12 This table documents the credit card

validation use case shown in Figure 4-11

FIGURE 4-11 This Visible Analyst use case diagram

shows a sales system, where the actor is a customer
and the use case is a credit card validation
24
Modeling Tools and Techniques
(Cont.)

 Sequence
Diagrams
◦ Shows the timing
of interactions
between objects
as they occur

FIGURE 4-14 This Visible Analyst sequence diagram

shows a credit card validation process

25
System Requirements Checklist
 Output Examples
◦ 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
◦ The contact management system must generate a
daily reminder list for all sales reps
◦ The purchasing system must provide suppliers with
up-to-date specifications

26
System Requirements Checklist
(Cont.)

 Input Examples
◦ 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
◦ Student grades must be entered on machine-scannable forms
prepared by the instructor
◦ Each input form must include date, time, product code,
customer number, and quantity
◦ Data entry screens must be uniform, except for background
color, which can be changed by the user
◦ A data entry person at the medical group must input patient
services into the billing system

27
System Requirements Checklist
(Cont.)

Process Examples
◦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
◦The warehouse distribution system must analyze daily orders
and create a routing pattern for delivery trucks that maximizes
efficiency and reduces unnecessary mileage
◦The human resources system must interface properly with the
existing payroll system
◦The equipment rental system must not execute new rental
transactions for customers who have overdue accounts
◦The prescription system must automatically generate an
insurance claim form

28
System Requirements Checklist
(Cont.)

 Performance Examples
◦ The system must support 25 users online simultaneously
◦ Response time must not exceed four seconds
◦ The system must be operational seven days a week, 365
days a year
◦ The accounts receivable system must prepare customer
statements by the third business day of the following
month
◦ The student records system must produce class lists
within five hours after the end of registration
◦ The online inventory control system must flag all low-
stock items within one hour after the quantity falls below
a predetermined minimum

29
System Requirements Checklist
(Cont.)
 Control Examples
◦ 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
◦ The system must maintain separate levels of security
for users and the system administrator
◦ All transactions must have audit trails
◦ The manager of the sales department must approve
orders that exceed a customer’s credit limit
◦ The system must create an error log file that
includes the error type, description, and time

30
Future Growth, Costs, and Benefits
 Scalability
◦ A system’s ability to handle increased business
volume and transactions in the future
◦ 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

31
 Future Growth, Costs, and Benefits
(Cont.)

• 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 FIGURE 4-15 HP urges viewers to Take
the TCO Challenge. Interested viewers
– Rapid Economic Justification can download a step-by-step TCO
analysis that HP created
(REJ)

32
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

33
 Fact Finding (Cont.)

 Typical questions to ask

◦ What business functions are supported by the current
system?
◦ What strategic objectives and business requirements
must be supported by the new system?
◦ What are the benefits and TCO of the proposed
system?
◦ What transactions will the system process?
◦ What information do users and managers need from
the system?
◦ Must the new system interface with legacy systems?

34
 Fact Finding (Cont.)

 Typical questions to ask

◦ What procedures could be eliminated by business
process reengineering?
◦ What security issues exist?
◦ What risks are acceptable?
◦ What budget and timetable constraints will affect
system development?

35
 Fact Finding (Cont.)

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

◦ Who performs each of the procedures within the system? Why? Are the
correct people performing the activity? Could other people perform the
tasks more effectively?
◦ What is being done? What procedures are being followed? Why is that
process necessary? Often, procedures are followed for many years and
no one knows why. You should question why a procedure is being
followed at all
◦ Where are operations being performed? Why? Where could they be
performed? Could they be performed more efficiently elsewhere?
◦ When is a procedure performed? Why is it being performed at this time?
Is this the best time?
◦ How is a procedure performed? Why is it performed in that manner?
Could it be performed better, more efficiently, or less expensively in
some other manner?

36
Fact Finding (Cont.)

FIGURE 4-17 Sample questions during requirements modeling as the

focus shifts from the current system to the proposed system

37
 Fact Finding (Cont.)

 The Zachman
Framework
◦ Zachman Framework
for Enterprise
Architecture
◦ Helps managers and
users understand
the model and
assures that overall
business goals
translate into
successful IT FIGURE 4-18 Visible Analyst uses the Zachman Framework
for Enterprise Architecture. The Zachman concept presents
projects traditional fact-finding questions in a systems development
context

38
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

39
Interviews (Cont.)

 Step 1: Determine the people to interview

◦ Select the right people and ask the right questions
◦ Don’t rely on just an organization chart
◦ Decide on group and/or individual interviews
 Step 2. Establish objectives for the interview
◦ Determine the areas to be discussed
◦ List the facts you need to gather
◦ Upper management provides the big picture
◦ Users can give you specific details

40
Interviews (Cont.)

 Step 3. Develop interview questions

 Decide what to ask and how to phrase the question
 The same question to different people - for comparison
 Open ended questions encourage spontaneous and unstructured responses
 What are users saying about the new system?
 How is this task performed?
 Close ended questions limit the response - used to verify facts
 How many personal computers do you have in this department?
 Do you review the reports before they are sent out?
 Range of response questions limit the response – uses a scale
 On a scale of 1 to 10, with 1 the lowest and 10 the highest, how
effective was your training?
 How would you rate the severity of the problem: low, medium, or
high?

41
Interviews (Cont.)

 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
◦ Verify time, place, length, and topics via e-mail
◦ Ask the interviewee to have samples available

42
Interviews (Cont.)

FIGURE 4-20 Sample message to a department

head about interviews
43
Interviews (Cont.)

FIGURE 4-21 Sample message to confirm an

interview 44
Interviews (Cont.)

 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

45
Interviews (Cont.)

 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

46
Interviews (Cont.)

 Step 7. Evaluate the interview

◦ 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
◦ Misunderstanding or personality conflict could
affect the interview negatively, or the interviewee
might be afraid that the new system will eliminate
or change his or her job

47
Other Fact-Finding Techniques
• Document Review
• Review old and current forms and documentation
• Observation
– Seeing the system in action gives you additional
perspective and a better understanding of the
system procedures
– Plan your observations in advance
– Consider the Hawthorne Effect Study
 Productivity seemed to improve whenever workers knew
they were being observed

48
Other Fact-Finding Techniques
(Cont.)

 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

FIGURE 4-23 Online version of a sample questionnaire. Does

it follow the suggested guidelines?
49
Other Fact-Finding Techniques
(Cont.)

 Keep the questionnaire brief and user-friendly

 Provide clear instructions that will answer all anticipated questions
 Arrange the questions in a logical order, going from simple to
more complex topics
 Phrase questions to avoid misunderstandings; use simple terms
and wording
 Try not to lead the response or use questions that give clues to
expected answers
 Limit the use of open-ended questions that are difficult to tabulate
 Limit the use of questions that can raise concerns about job
security or other negative issues
 Include a section at the end of the questionnaire for general
comments
 Test the questionnaire whenever possible on a small test group
before finalizing it and distributing to a large group

50
Other Fact-Finding Techniques
(Cont.)

 Sampling
◦ Systematic sample
 Select every tenth customer for review
◦ Stratified sample
 Select five customers from each of four postal codes
◦ Random sample
 Any 20 customers
◦ Main objective of a sample is to ensure that it represents the
overall population accurately

51
Other Fact-Finding Techniques
(Cont.)

 Research
◦ Can include the Internet, IT magazines, and books to obtain
background information, technical material, and news about
industry trends and developments
◦ Site visit

52
Other Fact-Finding Techniques
(Cont.)

 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

53
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

54
Documentation (Cont.)

 Software Tools
◦ CASE Tools
◦ Productivity
Software
 Word processing
 Spreadsheets
 Database
management
 Presentation
graphics, and FIGURE 4-27 This histogram displays the results
collaborative from Question 2 in the questionnaire shown in
software programs Figure 4-23 on page 156.
 Histogram

55
Documentation (Cont.)

 Graphic
Modeling
Software
◦ Produces charts
and diagrams
◦ MS Visio popular

FIGURE 4-28 This Visio drawing uses drag-and-drop

shapes to represent a business process
56
Information Management Software
 Personal data management software
◦ Microsoft Outlook
 A personal calendar
 A to-do list with priorities and ability to check off
completed items
◦ Microsoft OneNote
 Handles many different types of input, including text,
handwritten notes, images, audio and video recordings,
Web links
 OneNote is included in most versions of the Office

57
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

58
 Chapter Summary
 The systems analysis phase includes three
activities: requirements modeling, data and
process modeling, and consideration of
development strategies
 The main objective is to understand the

proposed project, ensure that it will support

business requirements, and build a solid
foundation for the systems design phase
 Popular team-based approaches include JAD,

RAD, and agile methods

59
Chapter Summary (Cont.)

• The fact-finding process includes

interviewing, document review, observation,
questionnaires, sampling, and research
• Systems analysts should carefully record and
document factual information as it is
collected, and various software tools can help
an analyst visualize and describe an
information system

60