ITCO 603: System Analysis Modeling and Design

Requirements Modeling

College of Information Technology

United Arab Emirates University
 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 (chapter 4)
Data and Process Modeling (chapter 5)
Object Modeling (chapter 6)
Development Strategies (chapter 7)

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,
transactions and events
FIGURE 4-2 The systems analysis phase consists of Development Strategies
requirements modeling, data and process modeling, object
modeling, and consideration of development Software trends, development
strategies. Notice that the systems analysis tasks are
interactive, even though the waterfall model generally alternatives, outsourcing, etc.
depicts sequential development

5
 Systems Analysis Phase Overview (Cont.)

A requirement is a software capability needed by

the user to solve a problem to achieve an objective

Examples:
The user shall be able to search either all of the initial set
of databases or select a subset from it
The system shall provide appropriate viewers for the user
to read documents in the document store
The system shall respond to search query within 0.03 ms
The language of development shall be Java

6
 Systems Analysis Phase Overview (Cont.)

System Analysis Skills

Strong analytical skills
Interpersonal skills

Team-Based Techniques: JAD, RAD, and Agile Methods

The Objective 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
7
 Requirements Management
A systematic approach to elicitation, organizing, and documenting the requirements of a system and a
process that establishes and maintains agreement between the customer and the project team on the
changing requirements of the system
Requirement Management Road Map

Problem
domain
Needs
Features
Software Solution
requirements domain

9
 Requirement Management road map (2)

Problem Domain (the home of the system users)

and Stakeholder needs (what the users need from
the system)
System Features: a system service that fulfill
one or more user needs
the car will have power windows.
the system has to be web-based.
Software Requirements (more specific )

10
 System feature Vs. SW Requirement
A feature tends to be a “higher-level” objective than a
requirement – and is usually more focused on business
needs rather than implementation.
Example: Let’s say you’re designing an online bookstore
to compete with Amazon
Feature-1: click ordering
Related requirements to this feature:
 User shall be able to activate 1-click ordering within his account
 User shall be able to deactivate 1-click ordering within his account

 User shall be able to order books with just 1 click

 User shall be able to “Undo” his 1-click order for a period of 30

minutes from the time he placed such an order

 System Analysis Overview
SA is part of the SDLC or Development Process
Many Processes have been introduced
Waterfall model
V-Model
Rapid Prototype
Spiral model
Agile methods

12
 The Waterfall Model
Requirements/
Specifications
Software Requirements A return in the development process was only
Verify Specifications possible to an immediate previous phase

Design
Design Document
Verify

Implementation

Test Software Units

Integration

Test Software Systems

and manuals

Operation
Operation

Retirement
Retirement
13
V-Model
Rapid Prototype
Spiral Model

Start

16
 Iterative and Incremental Approach

Time

 Iteration: Sequence of activities with an established plan and evaluation criteria

resulting in executable of some type
 In iterative mode:
 Activities are organized as workflows
 Workflow is a logically related set of activities
 Joint Application Development
Brings users into the development process as active
participants
User Involvement (formally or informally) creates a
successful system
JAD is used whenever group input and interaction are
desired
JAD Participants and Roles
Project leader and one or more members
Participants insulated from distractions of day-to-day
operations

18
 Joint Application Development (Cont.)

FIGURE 4-3 Typical JAD participants and roles

19
 Joint Application Development (Cont.)

FIGURE 4-4 Typical agenda for a JAD session 20

 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

21
 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

22
 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
23
 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

24
 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

25
 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

26
 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

27
 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
28
 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

29
 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

30
 Modeling Tools and Techniques (Cont.)

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

31
 Modeling Tools and Techniques (Cont.)

 Business Process
Modeling
Business process
model (BPM)
Business process
modeling notation
(BPMN)

FIGURE 4-9 Using the Visible Analyst CASE tool, an

analyst can create a business process diagram. The overall
diagram is called a pool, and the two separate customer
areas are called swim lanes
32
 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

33
 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
34
 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
35
 What Are Requirements?
System Requirements =
Functional requirements
Non-functional requirements
Functional Requirements– the activities,
functions, services,.. the system must perform
Business uses, functions the users carry out
Non-Functional Requirements- judges the
operation of the system
Constraints and performance goals

36
 FURPS+ Requirements Acronym
Functional requirements
Usability requirements
Reliability requirements
Performance requirements
Security requirements
+ even more categories…

37
FURPS+ Requirements Acronym (2)

38
 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

39
 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

40
 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

41
 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
42
 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

43
 Future Growth, Costs, and Benefits
In addition to the system requirements, systems analysts
must consider
Scalability
 To determine how a system will handle future growth and
demands
Total cost of ownership
 includes all future operational and support costs.
 Important when evaluating several alternatives
 Problem: indirect costs tends to be underestimated

44
 Fact Finding
 Fact-Finding: collecting information
◦ First, you must identify the information you need
◦ Develop a fact-finding plan
 How to ask questions? What kind of questions?
 Traditional Techniques:

• Interviews • Research
• document review • Workshops
• Observation • Brainstorming
• surveys and • Storyboarding
questionnaires • role playing
• Sampling • prototyping,

45
 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?
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?

46
 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?

47
 Fact Finding (Cont.)

FIGURE 4-17 Sample questions during requirements modeling as the focus

shifts from the current system to the proposed system

48
 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

49
 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

50
 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
 How is this task performed?
 Close ended questions limit the response - used to verify facts
 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?

51
 Interviews (Cont.)

Step 4: Prepare for the interview

Duration: no more than one hour
Confirm: time, place, length, and topics via e-mail
Ask the interviewee to have samples available
Step 5: Conduct the interview
Distribute Agenda
Begin by introducing yourself, describing the project, and
explaining your interview objectives
Engaged listening
Allow the person enough time
At the end, Summarize the session and seek a confirmation

52
 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

53
 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

54
 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

55
 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?
56
 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

57
 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

58
 Documentation
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

59
 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

60
 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

61
 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

62