Ch1.

Introduction to Systems Analysis & Design

9:20 SA

1. Systems Development Life Cycle

a. Planning
b. Analysis
c. Design
d. Implementation
2. System Development Methodologies
a. Structure Design
▪ Waterfall Development
• Linear, in sequence
▪ Parallel Development
b. Application Development
▪ Iterative Development
▪ System Prototyping
c. Agile Development
3. Object-Oriented Systems Analysis & Design
○ Unified Modeling Language
4. Project Team Roles & Skills
a. Skills
i. Technical
• Understands the technical environment, technical
foundation, and technical solution
ii. Business
• Understands how IT can be applied to business
situations
• Example: You don't know how bank staff works when
you deposit money to your account
iii. Analytical
• Problem solver
iv. Interpersonal
• Communication skills
v. Management
• Manages people
• Manages pressure & risks
vi. Ethical
• Be fair, honest, and ethical to others
b. Roles
i. Business Analyst
ii. Systems Analyst
iii. Infrastructure Analyst
iv. Change Management Analyst
v. Project Manager

Information Systems Analysis and Design Trang 1

Ch2. Project Initiation & Requirement
Determination
9:38 SA

1. Project Initiation
○ When you see an opportunity to improve business
○ Example: Your education management system has lots of
shortcomings
○ Feasibility analysis is used to aid in the decision of whether or not
to proceed with the project
○ Project sponsor: key person who proposes and invests on the
development or adoption of new technology
2. Project Identification
a. Business Needs
▪ Requirements within a business unit, coming from
recommendations or business opportunities
▪ Examples
• Supporting a new marketing campaign
• Reaching a new type of customers
• Improving interactions with suppliers
▪ Education management
• View scores
• Register courses
• Set up classrooms (for staff)
▪ Might come from "pains" in business
b. Business Value
▪ Determined by weighing the cost against the benefits
i. Tangible Value
• Quantifiable
• Measurable
• Examples
○ 500 000 dollars saved
○ Doubles the number of customers
ii. Intangible Value
• Suspected to give tangible benefits
• Not measurable
• Examples
○ Improved customer service
○ Increases competitiveness against other companies
c. System Request
▪ Document that describes the business reasons for building a
system and the value the system is expected to provide
▪ Given to the project sponsor afterwards for more information
and the final decision (accept or reject?)
▪ Elements
• Project name
• Project sponsor
• Business needs
• Functionality
• Business requirements
• Expected business value
• Special issues/constraints

Information Systems Analysis and Design Trang 2

 • Special issues/constraints
3. Feasibility Analysis
a. Technical Feasibility
▪ Answers: Can we build it?
▪ Risks that influence the successful completion of a project
• Familiarity with application
○ Knowledge of business domain
○ Do you know how an ATM works?
○ If you don't know, the banking project might easily
fail
• Familiarity with technology
○ Extension of existing firm technologies
○ Your whole company uses Windows, but your
project uses Linux?
• Project size
○ Small or large?
○ Number of people
▪ Too many people involved makes the project
complex
○ Number of features
○ Amount of time
▪ A 5-year project might not be good
• Compatibility
○ Ability to integrate the system with the existing
technology
b. Economic Feasibility
▪ Answers: Should we build it?
▪ Risks
• Development costs
• Annual operational costs
• Annual benefits
• Intangible benefits & costs
▪ Steps
1. Identifying Costs & Benefits
○ Development costs (one-time costs)
▪ Dev team salaries
▪ Consultant fees
○ Operational costs (ongoing costs)
▪ Software upgrading & licensing
▪ Hardware repairs & upgrades
○ Tangible benefits
▪ Increased sales
▪ Reduced costs
○ Intangible benefits
▪ Increased brand recognition
▪ High quality products
2. Assigning Values to Costs & Benefits
○ Analysts assign specific monetary values (dollar) to
costs & benefits
○ Example: Improved customer service: $70K
▪ Based on reduced costs for customer complaint

Information Systems Analysis and Design Trang 3

 ▪ Based on reduced costs for customer complaint
phone calls
3. Determining Cash Flow
○ Showing cash flow over time
○ How much money will you get after one year?
4. Determining Net Present Value
○ Net present value: compares the present value with
the future cash flow
○ Example: Now you have $1, after depositing for
savings for 1 year, you should have $1.5
○ Calculate the change of value of one dollar through
years
5. Determining Return on Investment
○ Return on investment: amount of money you get (in
return) for the money you spend
○ High ROI results when benefits outweigh costs
significantly
6. Determining Break-Even Point
○ When the benefits equal to the costs
○ Determines how long the system creates true
values for you
○ The greater the time it takes to break even, the
riskier the project!
7. Graphing the Break-Even Point
○ Graph the annual costs and benefits on a line graph
○ Break-even point is the intersection of the 2 lines
c. Organizational Feasibility
▪ Answers: If we build it, will they come?
▪ Stakeholder analysis considers
• Project champions
○ Make a presentation about the objectives and
proposed benefits of the project
○ Create a prototype of the system
• Organizational management
○ Make a presentation
○ Market the benefits using memo or newsletters
• System users
○ Assign roles
○ Assign tasks with deadlines
○ Ask for feedback regularly
4. Project Selection
○ Committee's role
▪ Decides to approve, decline, or table the project until
additional information is available
▪ Weighs many factors and makes trade-offs before the final
decision
5. Requirement Determination
○ Analysis phase
▪ Breaking a whole into parts with the intent of understanding
the nature, functions, and interrelationships of the parts
▪ 3 steps
• Understanding the existing situation (the as-is system)

Information Systems Analysis and Design Trang 4

 • Understanding the existing situation (the as-is system)
• Identifying improvements
• Defining requirements for the new system
▪ Final deliverables of the phase: system proposal
• Presented to the approval committee in the form of a
system walk-through to explain the system in moderate
detail
○ Performed to
▪ Transform the system request's high-level statement of
business requirements
▪ Into a more detailed and precise list of what the new system
must do
• To provide the needed value to the business
○ What is a requirement?
▪ A statement of what the system must do or what
characteristic it must have
○ Types of requirements
▪ Business
• What the business needs
▪ System
• How the system should be built
▪ User
• What the users need to do
▪ Functional
• What processes the system should perform (Process-
Oriented)
• What information it should contain (Information-
Oriented)
▪ Non-functional
• Characteristics the system should have
• Operational
○ Physical & technical environment
• Performance
○ Speed
○ Capacity
○ Reliability
• Security
○ Who is authorized to access to the system
• Cultural & Political
○ Legal requirements
○ Identifying requirements (exercise)
▪ FR: 4 (info), 5 (proc), 6 (info, semi non-func), 8 (info), 10
(proc)
▪ NonFR: 1 (op), 2 (cul), 3 (sec), 7 (perf), 9 (cul, semi-func)
6. Requirement Gathering/Elicitation Techniques
○ Requirements Elicitation in Practice
▪ Important side effects of the process of determining
requirements include building trust
○ Interviews
▪ Common
▪ Usually involves 2 people
▪ Selecting interviewees

Information Systems Analysis and Design Trang 5

▪ Selecting interviewees
• Who is interviewed
• When to interview
• Purpose of interviewing
• Different levels
○ Managers
○ Users
○ Other key stakeholders
▪ Designing interview questions
• Question types
○ Closed-ended
▪ Demanding explicit information
○ Open-ended
▪ What do you think?
▪ You don't know the exact answer!
○ Probing questions
▪ You don't understand the information clearly
▪ Giving more specific information
• Unstructured vs. Structured Interviews
○ Unstructured
▪ Broad
▪ Rough
▪ General
▪ Primarily open-ended questions
○ Structured
▪ Very specific
▪ Primarily closed-ended questions
• Top-down vs. Bottom-up
○ Top-down: from general (high-level) to specific (low-
level)
▪ More common
○ Bottom-up: from specific to general
▪ Complicated problems that the interviewer
can't comprehend
▪ Preparing for the interview
• Prepare a general interview plan
• Confirm areas of knowledge
• Set priorities in case of time shortage
• Prepare the interviewee
○ Schedule
○ Reason for interviewing
○ Areas of discussion
▪ Conducting the interview
• Appear to be professional & unbiased
• Record all information
○ Record audio with permission!
• Understand the issues discussed
○ Keep asking until you fully understand
• Separate facts from opinions
• Give interviewee time to ask questions, and briefly what
will happen next

Information Systems Analysis and Design Trang 6

 will happen next
○ Don't ask continually!
▪ Post-interview follow-up
• Analysts write an interview report
○ Includes interview notes
○ Sent to interviewee to read and inform clarification
or updates
○ Joint Application Development (JAD)
▪ Similar to a meeting/seminar
▪ Multiple individuals working together
▪ Allows the project team, users, and managers to work
together to identify requirements for the system
▪ Reduces scope creep by 50%
• Scope creep: straying from the scope
▪ Structured process
• 10 thru 20 users meet under the instruction of a
facilitator who is skilled in JAD techniques
▪ Selecting participants
• Managers
• Users
○ Only some of them!
• Project team
• Same basic way as selecting interviewees
• Facilitator
○ Expert in JAD & e-JAD techniques
▪ Electronic JAD: conducted with the assistance
of electronic devices
○ Normally the facilitator is an external consultant
▪ Not in the organization!
▪ Designing & preparing JAD sessions
• Takes from half a day to several weeks
• Success depends upon plan carefulness
• Primarily designed to collect specific information from
users
• Important to prepare analysts and participants
▪ Conducting
• Follow formal agenda and ground rules
• JAD facilitator's functions
○ Keep the session on track, following the agenda
○ Help the group understand the technical terms &
jargons
○ Record group's input on a public display area (e.g.
blackboard, projected screen)
○ Must remain neutral at all times and help the group
thru the process
▪ He must not give any opinions!
▪ Man-in-the-middle
▪ Post-JAD follow-up
• Post-session report is prepared and published among
session attendees
• Should be completed within one or two weeks after the
session

Information Systems Analysis and Design Trang 7

 session
○ Questionnaires / Survey
▪ Set of written questions used to obtain information from
individuals
▪ Selecting participants
• Using a sample of people who are representative of the
entire group
• If the sample is too large, synthesis takes more time!
▪ Designing questions
• Following good practice guidelines
○ Begin with non-threatening and interesting
questions
○ Group items coherently & logically
○ Don't put important items in the end
○ Avoid abbreviations
○ Avoid biased or suggestive items
○ Number questions
○ Pre-test
○ Provide anonymity to respondents
▪ Administering the questionnaire
• Improving the response rates
○ Remind to complete the survey
• Normally you get very low response rates!
▪ Questionnaire follow-up
• Developing a report
○ Document Analysis
▪ Used to understand the as-is (current) system
▪ Formal system
• What the organization actually uses
• Forms, reports, organization chats, policies
▪ Informal system
• Reveals what to be changed
• Differs from formal system
○ Observation
▪ Watching processes being performed
▪ Powerful tool to gain insight into the as-is system, and to
check validity
▪ You tend have extremely careful behaviors when being
watched
○ Selecting appropriate techniques
▪ You should combine multiple techniques!
▪ Type of info
▪ Depth of info
▪ Breadth of info
▪ Integration of info
▪ User involvement
▪ Cost

Information Systems Analysis and Design Trang 8

Ch3. Functional Modeling Using Use-Case
Diagrams
09:44

1. Introduction
○ A use case illustrates the activities that are performed by users
of a system
○ Use cases are logical models: they describe the activities of a
system without specifying how the activities are implemented
▪ Just specify what the system has
▪ No specific processes
○ 2 components
▪ Use case diagram
▪ Use case description
○ 2 approaches
▪ Text approach: create description; from it, create diagram
▪ Create diagram, then create description, and revise the
diagram if needed
▪ The result is the same after both approaches
○ Use-Case Diagram Syntax
▪ Actor
□ Tác nhân
□ Not a specific user
□ A role that a user can play while interacting with the
system
 Man symbol
□ Also represents another system in which the current
system interacts
 <<actor>>
□ Represents the principal elements in the environment in
which the system operates
□ Provides input to the system, receives output from the
system, or both
 Surveillance
 Barcode reader
□ Sometimes plays a specialized role of a more general
type of actor
 General: Patient
 Uses a line with hollow triangle pointing the general
actor
 Specialized, Inherits, Extends: New patient
□ How to determine actors?
 Who will use the main functions of the system?
 Who works with the system daily?
 Who administers and keeps the system working
continuously?
 Which hardware devices are managed by system?
◊ Barcode reader is
◊ Screen is not, just a means
 Which other systems do the system interact with?
◊ Might interact with a financial system
 Who or what is interested in the returned results?
▪ Use Case (oval)

Information Systems Analysis and Design Trang 9

 ▪ Use Case (oval)
□ Primary driver for all UML diagramming techniques
 Presenting the use-case functionality in a different
way or purpose
□ Communicates what the system does at a high level
□ Captures typical interaction of the system with users
 External, functional, view of the system from the
perspective of the user
□ Describes ONLY one function in which users interact
with the system
□ Scenario
 A use case may contain several paths that a user
can take while interacting
◊ When searching for a book, a user may search
by title or author
 Each possible execution path is referred as a
scenario
 Used extensively in behavioral modeling
□ Each use case is associated with only one role that users
have in the system
□ Multiple users play the same role
□ Depicted by an oval
□ Labeled with a descriptive gerund
□ How to determine use-cases? For each actor, answer
some questions
□ Have all use-cases been found?
▪ System Boundary (rectangle)
▪ Association Relationship (line)
□ Quan hệ kết hợp cho biết tác nhân nào tham gia vào ca
sử dụng nào
 Khởi phát
 Trao đổi thông tin
 Nhận kết quả
□ Bạn đọc — Mượn sách
▪ Include Relationship
□ Quan hệ bao gồm <<include>> biểu diễn một ca sử
dụng chứa hành vi định nghĩa trong một ca sử dụng
khác
□ Biểu diễn phần chung hành vi của nhiều ca sử dụng
□ Thủ thư — Quản lí mượn sách –<<include>>—> Kiểm
tra thẻ
▪ Extend Relationship
□ Quan hệ mở rộng khi một use case tuỳ ý mở rộng chức
năng cho use case khác cũng cấp
□ Mô hình hoá một vài chức năng dùng chung, sử dụng lại
giữa 2 hay nhiều use case
□ Mượn sách từ thư viện thành viên –<<extend>>—> Xử
lí mượn sách <—<<extend>>– Xử lí từ chối mượn sách
▪ Generalization Relationship
□ Use case A có quan hệ tổng quát hoá với B nếu B là một
trường hợp chi tiết của A
 A: tổng quát
 B: chuyên biệt
□ Mũi tên đầu rỗng từ con tới cha
2. Use-Case Description

Information Systems Analysis and Design Trang 10

2. Use-Case Description
○ Describes use cases defined in the use case diagram
▪ What the user can do
▪ How the system responds
○ Elements
▪ Use case name
▪ ID
▪ Importance level
▪ Primary actor
□ May contain multiple actors, but there must be at least
one
▪ Use case type
□ Overview or Detail
□ Essential or Real
□ Overview
 Enable the analyst & users to agree on a high level
overview of the requirements
□ Detail
 Contains all the information needed
□ Essential
□ Real
 Describes a specific set of steps
▪ Stakeholders & interests
▪ Brief description
▪ Trigger
□ Specifies the even that gets the use case started
□ Precedes the first step
□ External trigger
 Customer placing an order
 Fire alarm ringing
□ Temporal trigger
 Book being overdue
▪ Relationships

Information Systems Analysis and Design Trang 11