Learning Unit 2

Systems Analysis
Chapters 2-5
Investigating System
Requirements
Theme 1:
Chapter 2
 Learning Objectives
• LO1: Describe the activities of systems analysis;
• LO:2 Explain the difference between functional and non-functional
requirements;
• LO3: Identify and Understand different kinds of stakeholders and
contributions to requirements definition;
• LO4: Describe the role of models and UML in systems analysis.
• LO5: Develop UML activity diagrams to model activity workflows;
 Overview
• Chapter 1 introduced the system development lifecycle (SDLC) and demonstrated
its use for a small project
• This chapter expands the SDLC processes to cover a wider range of concepts, tools
and techniques
• Core process 3: Discover and understand the details of the problem or need—is the
main focus of systems analysis
• A larger Ridgeline Mountain Outfitters (RMO) project is introduced that will be
used throughout the text to illustrate analysis and design
 Ridgeline Mountain Outfitters (RMO)

• RMO has an elaborate set of information systems that support operations

and management
• Customer expectations, modern technological capabilities, and
competitive pressures led RMO to believe it is time to upgrade support
for sales and marketing
• A new Consolidated Sales and Marketing System was proposed
• This is a major project that grew out of the R MO strategic planning
process
5
 RMO Information Systems Strategic Plan
• Technology architecture— the set of computing hardware,
network hardware and topology, and system software employed
by the organization
• Application architecture—the information systems that supports
the organization (information systems, subsystems, and
supporting technology)

6
 RMO Existing Application Architecture

• Supply Chain Management (SCM)

• 5 years old; Java/Oracle
• Tradeshow system will interface with SCM
• Phone/Mail Order System
• 12 years old; Visual Studio/MS SQL
• Reached capacity; minimal integration
• Retail Store System
• Older package solution; minimal integration
• Customer Support System (CSS)
• Web based system; evolved over the years, minimal integration
7
Proposed Application Architecture: Integrate SCM and New CSMS

8
 New Consolidated Sales and Marketing System (C SMS)

• Will have 4 subsystems:-

• Sales Subsystem
• Integrates online, phone, and retail stores. Offers online catalog searching,
purchasing items and paying for them online.
• Order Fulfillment Subsystem
• Perform tasks of shipping items, Tracking shipments by customers, rate
products and services

9
 New Consolidated Sales and Marketing
System (CSMS)
• Customer Account Subsystem
• Provides services that enhance the customer experience. Shopping history,
linkups, “mountain bucks” rewards.
• Marketing Subsystem
• Mainly for employees to set up the information and services for customers.
Promotional packages, partner relationships, more complete merchandise
information and reporting
 Systems Analysis Activities

• The New Consolidated Sales and Marketing System (CSMS) will require
discovering and understanding extensive and complex business processes and
business rules.
• The SDLC indicates the project starts with identifying the problem, obtaining
approval, and planning the project (as seen in Chapter 1)
• To get to the heart of systems analysis, this text skips right to analysis activities
generally and the specifically for the RMO CSMS project (Core Process
#3/systems analysis)
• Discover and understand details.
• Project planning and project management are covered in detail later in the text 11
 SYSTEMS ANALYSIS
ACTIVITIES

• Gather detailed
information.
• Define requirements.
• Prioritize requirements.
• Develop user-interface
dialogs.
• Evaluate requirements with
users.
 Systems Analysis Activities
• Gather Detailed Information
• Interviews, questionnaires, documents, observing business processes, researching vendors, comments and
suggestions

• Define Requirements
• Modeling functional requirements and non-functional requirements
• Prioritize Requirements
• Essential, important, vs. nice to have
• Develop User-Interface Dialogs
• Flow of interaction between user and system
• Evaluate Requirements with Users
• User involvement, feedback, adapt to changes 13
 SYSTEMS ANALYSIS ACTIVITIES

Gather Detailed Information

• Systems Analysts obtain information from people
who will be using the system, either by interviewing
them or by watching them work.
• In short, analysts need to talk to nearly everyone
who will use the new system or has used similar
systems, and they must read nearly everything
available about the existing system.
• The analyst must become an expert in the business
area the system will support.
 Information Gathering Techniques

• Interviewing users and other stakeholders

• Distributing and collecting questionnaires
• Reviewing inputs, outputs, and documentation
• Observing and documenting business procedures
• Researching vendor solutions
• Collecting active user comments and suggestions
15
 Interviewing Users and Other Stakeholders

• Prepare detailed questions

• Meet with individuals or groups of users
• Obtain and discuss answers to the questions
• Document the answers
• Follow up as needed in future meetings or interviews

16
 Themes for Information Gathering Questions
Theme Questions to users

What are the business operations and processes? What do you do?

How do you do it?

How should those operations be performed? What steps do you follow?
How could they be done differently?

What information do you use?

What information is needed to perform those
What inputs do you use?
operations?
What outputs do you produce?

17
 Preparing for the Interview

Before
• Establish the objective for the interview.
• Determine correct user(s) to be involved.
• Determine project team members to participate.
• Build a list of questions and issues to be discussed.
• Review related documents and materials.
• Set the time and location.
• Inform all participants of objective, time, and locations.
18
 Preparing for the Interview
During

• Arrive on time.
• Look for exception and error conditions.
• Probe for details.
• Take thorough notes.
• Identify and document unanswered items or open questions.
 Preparing for the Interview
After
• Review notes for accuracy, completeness, and understanding.
• Transfer information to appropriate models and documents.
• Identify areas needing further clarification.
• Thank the participants.
• Follow up on open and unanswered questions.
 Interview Session Agenda
Discussion and Interview Agenda
Setting
Objective of Interview
Determine processing rules for sales commission rates

Date, Time, and Location

April 21, 2016, at 9:00 a.m. in William McDougal’s office

User Participants (names and titles/positions)

William McDougal, vice president of marketing and sales, and several of his staff

Project Team Participants

Mary Ellen Green and Jim Williams
21
 Interview Session Agenda

Interview/Discussion
1. Who is eligible for sales commissions?
2. What is the basis for commissions? What rates are paid?
3. How is commission for returns handled?
4. Are there special incentives? Contests? Programs based on time?
5. Is there a variable scale for commissions? Are there quotas?
6. What are the exceptions?

22
 Interview Session Agenda
Follow-Up
Important decisions or answers to questions
See attached write-up on commission policies

Open items not resolved with assignments for solution

See Item numbers 2 and 3 on open items list

Date and time of next meeting or follow-up session

April 28, 2016, at 9:00 a.m.
 Keeping an Open Items List
Date Target end Responsible
ID Issue title User contact Comments
identified date project person

Partial Jason Ship partials or wait for

1 6-12-2016 7-15-2016 Jim Williams
shipments Nadold full shipment?

Returns and William Are commissions

2 7-01-2016 9-01-2016 Jim Williams
commissions McDougal recouped on returns?

How to handle
Extra William
3 7-01-2016 8-01-2016 Mary Ellen Green commissions on special
commissions McDougal
promotions?

24
Distribute and
Collect
Questionnaires

25
Review Inputs, Outputs, and Procedures

26
 Additional Techniques

• Observe and Document Business Processes

• Watch and learn
• Document with Activity diagram (next section)
• Research Vendor Solutions
• See what others have done for similar situations
• White papers, vendor literature, competitors
• Collect Active User Comments and Suggestions
• Feedback on models and tests
• Users know it when they see it
27
 SYSTEMS ANALYSIS ACTIVITIES
Define Requirements
• Systems Analysts uses the information gathered from
users and documents to define the requirements.
• Defining the requirements is not just a matter of
writing down facts and figures, instead the analyst
creates models to record requirements, reviews the
models with users and others, and refines and
expands the models to reflect new or updated
information.
• In previous learning unit you learned about
requirements models such as use case diagrams,
activity diagrams, and domain model class diagrams.
 SYSTEMS ANALYSIS ACTIVITIES
Functional and Non-Functional
Requirements
• Functional requirements are the
activities that the system must perform.
• Non-functional requirements are
characteristics of the system other than
those activities that it must support or
perform.
• FURPS is the framework used to identify
non-functional requirements. FURPS is
an acronym for functional, usability,
reliability, performance, and security
requirements.
 What Are Requirements?

• System Requirements =) The activities a system must perform or

support and the constraints that the system must meet
• Functional Requirements– the activities the system must perform
• Business uses, functions the users carry out
• Non-Functional Requirements– other system characteristics
• Constraints and performance goals

30
 Additional Requirements Categories

• Design constraints – Specific restrictions for hardware and software

• Implementation requirements-Specific languages, tools, protocols, etc.
• Interface requirements-Interface links to other systems
• Physical requirements-Physical facilities and equipment constraints
• Supportability requirements-Automatic updates and enhancement methods

31
SYSTEMS ANALYSIS ACTIVITIES

Prioritize Requirements
• Once the requirements have been well
understood and agreed to, it is important
to establish which requirements are most
crucial for the system.
• Sometimes users request additional
system functions that are more desirable
but not essential.
SYSTEMS ANALYSIS ACTIVITIES
Develop User-Interface Dialogs
• If you’re building a new system, users will
be pretty sure of the form they want based
on the requirements.
• Sometimes, certain tasks become
automated by the new system and
sometimes the new system creates
additional tasks.
• To most users the interface is all that
matters, thus creating interface dialogs is a
powerful method of eliciting and
documenting requirements.
• User-interface dialogs can be documented
using even written dialog and interaction
diagrams
SYSTEMS ANALYSIS ACTIVITIES

Stakeholders
• Stakeholders are all the people who have an
interest in the successful implementation of
the system.
• Depending on the nature and scope of the
system, this can be a small group, a large
group, a diverse group.
• Stakeholders of an accounting system were
made up of bookkeepers, accountants,
managers and executives, customers,
suppliers, auditors, investors and the IRS.
SYSTEMS ANALYSIS ACTIVITIES
Stakeholders
• Internal Stakeholders are those within the
organization who interact with the system or
have a significant interest in its operation or
success.
• External Stakeholders are those outside of
the organizations control and influence –
although this distinction can be fuzzy such as
when an organizations strategic partners
interact directly with internal systems.
• Operational Stakeholders are those who
regularly interact with the system in the
course of their jobs or lives.
• Executive stakeholders– persons who don’t
directly interact, but use the information or
have financial interest
 Evaluate requirements with users and documenting the
requirements

• Analysts usually use an iterative process in which they elicit user input to model
requirements, return to the user for additional input or validation, and then work alone to
incorporate the new input and refine the models
• Prototypes of user interfaces can be used
• Models and Modeling
• Model– a representation of some aspect of the system being built
• Types of Models
• Textual model– something written down, described
• Graphical models– diagram, schematic
• Mathematical models– formulas, statistics, algorithms
36
 SYSTEMS ANALYSIS ACTIVITIES

Models and UML

• Modeling is an important aspect of systems
analysis and design.
• Analysts build models to describe system
requirements and use those models to
communicate with users and designers.
• Reasons for modelling:
• Learn from the modelling process
• Reducing complexity by abstraction
• Remembering all the details
• Communicating with a variety of users and
stakeholders
• Documenting what was done for future
 Documenting Workflows with Activity Diagrams

• Workflow– sequence of processing steps that completely handles one

business transaction or customer request
• Activity Diagram– describes user (or system) activities, the person
who does each activity, and the sequential flow of these activities
• Useful for showing a graphical model of a workflow
• A UML diagram

38
SYSTEMS
ANALYSIS
ACTIVITIES

Documenting
workflows with Activity
Diagrams
• Activity Diagram
symbols
 SYSTEMS
ANALYSIS
ACTIVITIES
Documenting workflows
with Activity Diagrams
• A workflow is the
sequence of work steps
that complete one
business transaction or
customer request.
• Single path in image
 SYSTEMS
ANALYSIS
ACTIVITIES
Documenting workflows
with Activity Diagrams
• Activity diagram with
concurrent paths
 Summary (1 of 4)

• Systems analysis activates correspond to the core S DLC process

Discover and understand details
• System projects originate from the information system strategic
plan, which contains an technology architecture plan and an
application architecture plan
• The RMO CSMS Project will be used throughout the text as an
example of analysis and design
42
 Summary (2 of 4)

• Systems analysis involves defining system requirements– functional and non-

functional
• Analysis activities include
• Gather detailed information
• Define requirements
• Prioritize requirements
• Develop user-interface dialogs
• Evaluate requirements with users

• FURPS+ is the acronym for functional, usability, reliability, performance, and security
requirements 43
 Summary (3 of 4)

• Stakeholders are the people who have an interest in the success of

the project
• There are internal vs. external stakeholders and operational vs.
executive stakeholders
• Information gathering techniques used to collect information
about the project are:-
• Interviews, questionnaires, reviewing documents, observing business processes,
researching vendors, comments and suggestions
44
 Summary (4 of 4)

• The UML Activity Diagram is used to document (model) workflows

after collecting information
• Models and modeling are used to explore and document
requirements
• Unified Modeling Language (UML) is the standard set of notations
and terminology for information systems models

45