SYSTEMS PRESENTATION to help you in design

College of Information Technology
United Arab Emirates University

 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

 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
Chapter Objectives (Cont.)

4
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)

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

 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

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

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
9
Needs
Features
Software
requirements
Problem
domain
Solution
domain

 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
RequirementManagementroad map (2)

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
Verify
Integration
Test
Retirement
Design
Verify
Software Requirements
Specifications
Implementation
Test
Design Document
Software Units
Operation
Software Systems
and manuals
13
A return in the development process was only
possible to an immediate previous phase

Iterative and Incremental Approach
 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
Time

18
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

19
Joint Application Development (Cont.)
FIGURE 4-3 Typical JAD participants and roles

20
FIGURE 4-4 Typical agenda for a JAD session

21
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

22
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

23
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

24
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

25
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

26
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

27
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

28
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

29
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

30
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

31
Modeling Tools and Techniques (Cont.)
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
 Top-down
representation
of a function
or process
 Similar to an
organization
chart

32
 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

33
 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

34
 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

35
 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

36
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

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

38
FURPS+ Requirements Acronym (2)

39
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

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

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

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

44
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

45
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:
• Research
• Workshops
• Brainstorming
• Storyboarding
• role playing
• prototyping,
• Interviews
• document review
• Observation
• surveys and
questionnaires
• Sampling

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

48
FIGURE 4-17 Sample questions during requirements modeling as the focus
shifts from the current system to the proposed system

 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

50
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

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

52
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

53
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

54
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

• 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

Other Fact-Finding Techniques (Cont.)
56
 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?

57
 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

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

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
Documentation

 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
Preview of Logical Modeling

61
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

• 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
Chapter Summary (Cont.)

SYSTEMS PRESENTATION to help you in design

Recommended

Recommended

More Related Content

Similar to SYSTEMS PRESENTATION to help you in design

Similar to SYSTEMS PRESENTATION to help you in design (20)

Recently uploaded

Recently uploaded (20)

SYSTEMS PRESENTATION to help you in design