System Analysis & Design


Dr. Md. Rakibul Hoque
For all financial transaction

University of Dhaka

Determining System Requirements

 Learning Objectives
 Defining requirement
 Describe options for designing and conducting interviews and developing a
plan for conducting an interview to determine system requirements
 Explain the advantages and pitfalls of observing workers and analyzing
business documents to determine system requirements
 Explain how computing can provide support for requirements determination
 Participate in and help plan a Joint Application Design session
 Use prototyping during requirements determination
 Describe contemporary approaches to requirements determination
 Understand how requirements determination techniques determination
techniques apply to the development of electronic commerce applications
Analysis Phase
 Analysis Phase
 The goal of the analysis phase is to truly understand the
requirements of the new system and develop a system that
addresses them.
 The purpose of analysis is to determine what information and
information processing services are needed to support
selected objectives and functions of the organization.
 The As-Is system is the current system and may or may

not be computerized
 The To-Be system is the new system that is based on

updated requirements
 The System Proposal is the key deliverable from the

Analysis Phase
 Analysis Phase
 System analysis is the part of the systems development
life cycle in which you determine how the current
information system functions and assess what users
would like to see in a new systems.
 Analysis has two subphases
 Requirement Determination: This is primarily a

fact-finding activity.
 Requiremet Structuring: This activity creates a

thorough and clear description of current business

operations and new information processing services.
 Defining a Requirement
 Studies show that more than half of all system
failures are due to problems with requirements
 A statement of what the system must do or what
characteristic it must have
 During analysis, requirements are written from the
perspective of the businessperson
 A formal document that communicates the
requirements of a proposed system to key
stakeholders and serves as a contract for the
systems project.
 Defining a Requirement
 The process and techniques used by systems analysts to identify or
extract system problems and solution requirements from the user
community.
 Over the lifetime of the project it is very common for new requirements to
emerge and existing requirements to change.
 Studies have shown that over the life of a project as much as 50 percent
or more of the requirements will change before the system is put into
production.
 Synonyms
 Requirements definition report
 Requirements statement
 Requirements specification
 Functional specifications
 Defining a Requirement

 Two kinds of requirements:

Functional requirement – a description of
activities and services a system must
provide.
 inputs, outputs, processes, stored data
Nonfunctional requirement – a description
of other features, characteristics, and
constraints that define a satisfactory system.
 Performance, ease of learning and use,
budgets, deadlines, documentation, security,
internal auditing controls
Defining a Requirement
Vehicle Management
Defining a Requirement
Vehicle Management
 Results of Incorrect
Requirements
 The system may cost more than projected.
 The system may be delivered later than
promised.
 The system may not meet the users’
expectations and they may not to use it.
 Once in production, costs of maintaining and
enhancing system may be excessively high.
 The system may be unreliable and prone to
errors and downtime.
 Reputation of IT staff is tarnished as failure will
be perceived as a mistake by the team.
 The Process of Determining
Requirements
 Characteristics of a good systems analyst:
 Impertinence – question everything

 Impartiality – consider all issues to find the best solution

 Relax constraints – assume anything is possible and

eliminate the infeasible

 Attention to detail – every fact must fit with every other fact

 Reframing – challenge yourself to look at the organization

in new ways
 Organizational Components to
Understand
 Systems analysts need to understand:
 Business objectives that drive what and how work is done
 Information people need to do their jobs
 The data (definition, volume, size) handled in support of jobs
 Data transformation and storage (when, how, by whom)
 Data handling dependencies and sequences
 Data handling and processing rules
 Policies and guidelines that describe the nature of the

business and market and the environment it operates in

 Key events that affect data values and when they occur
 Deliverables for Requirements
Determination

Deliverables for Requirements Determination

1. Information collected from conversations with or
observations of users: interview transcripts, notes from
observation, meeting minutes
2. Existing written information business mission and
strategy statements, sample business forms and reports
and computer displays, procedure manuals, job
descriptions, training manuals, flowcharts and
documentation of existing systems, consultant reports
3. Computer-based information: results from JAD sessions,
reports of existing systems, and displays and reports
from system prototypes
 Determining Requirements

 Requirements are best determined by systems

analysts and business people together
 Techniques available to the systems analyst:
 Interviews
 Questionnaires
 Observation
 Document analysis
 Joint application development (JAD)
 Determining Requirements
(Traditional Methods of Collecting System
Requirements)

Traditional Methods of Collecting System Requirements

• Individually interview people informed about the operation
and issues of the current system and future systems needs
• Interview groups of people with diverse needs to find
synergies and contrasts among system requirements
• Observe workers at selected times to see how data are
handled and what information people need to do their jobs
• Study business documents to discover reported issues,
policies, rules, and directions as well as concrete examples of
the use of data and information in the organization
 Guidelines for Effective
Interviewing

Guidelines for Effective Interviewing

Plan the Interview
•Prepare interviewee: appointment, priming
questions
•Prepare checklist, agenda, and questions
Listen carefully and take notes (record if
permitted)
Review notes within 48 hours of interview
Seek diverse views
 Determining Requirements
(Five Basic Steps of Interviews)

 Selecting interviewees
 Designing interview questions
 Preparing for the interview
 Conducting the interview
 Post-interview follow-up
 Determining Requirements
(Interviewing Strategies)
Top-down

How
High-level: can order
Very general processing be
improved?

Medium-level: How can we reduce the

Moderately specific number of times that customers
return ordered items?

Low-level: How can we reduce the number of

Very specific errors in order processing (e.g., shipping
the wrong products)? Bottom-up
Typical Interview Guide
Determining Requirements
(Post-Interview)
 Interviewing Groups

 Drawbacks to interviewing individuals:

 Reconciling contradictions in information collected

 New interviews may require new questions

 Not an efficient process

 Group interview advantages:

 More effective use of time

 Allows synergy when groups can hear each other

 Primary disadvantage is difficulty in scheduling with multiple

people involved
 Nominal Group Technique (NGT)

 Nominal group technique (NGT) – facilitated

process that supports idea generation by groups. At
the beginning of the process, group members work
alone to generate ideas. The ideas are then pooled
under the guidance of a trained facilitator.
 End result is a listing of either problems or features
generated and prioritized by the group
 Can be used as part of a JAD effort
 Determining Requirements
(Questionnaires)

 A set of written questions used to obtain

information from individuals
 Often used for large numbers of people from
whom information and opinions are needed
 Common technique with systems intended for
use outside the organization
 Response rates vary, but typically are
significantly less than 50%
 Determining Requirements
(Questionnaire Steps)
 Selecting participants
 Using samples of the population

 Designing the questionnaire

 Careful question selection

 Administering the questionnaire

 Working to get good response rate

 Questionnaire follow-up
 Send results to participants
Trade-Offs between the Use of Open-Ended
and Closed Questions on Questionnaires
 Determining Requirements (Ways to
Capture Responses When Designing a Web)
Survey)
Name Appearance Purpose
A single line text box is shown, Used to obtain a small amount
One-line text box of text and limit the answer to a few words. Used to obtain a small amount of text
and limit the answer to a few words
Multi line text box with horizontal and vertical scroll bars shown,
Scrolling text box Used to obtain one or more paragraphs of text. Used to obtain one or more paragraphs
of text
Checkbox is shown, Used to obtain a yes-no answer left
Check box parenthesis example, Do you wish to be included on the mailing
list? Right parenthesis.
Used to obtain a yes-no answer (e.g., Do
you wish to be included on the mailing
list?)
Checked radio button, a round button with a solid dot in the
Radio button center, is shown : Used to obtain a yes-no or true-false answer. Used to obtain a yes-no or true-false
answer
Image of a dropdown button is shown : Used to obtain more
Drop-down menu consistent results Left parenthesis Respondent is able to
choose the appropriate answer from a predetermined list left
Used to obtain more consistent results
bracket example., a list of state abbreviations right bracket right
parenthesis.
(Respondent is able to choose the
appropriate answer from a
predetermined list [e.g., a list of state
abbreviations])
Push button, Image of a button labeled as Button is shown,
Push button Most often used for an action left parenthesis e.g., a respondent
pushes a button marked “Submit” or “Clear” right parenthesis.
Most often used for an action (e.g., a
respondent pushes a button marked
“Submit” or “Clear”)
 Determining Requirements
(Observation)
 Direct observation of workers:
 Observation provides insight on what organizational members actually do

 Watching users work at their jobs

 Observe actual measure of how employees interact with information

systems and how they do their jobs

 More accurate than interview

 People can change their normal behavior when they know they are

being observed
 Observation cannot be continuous, thus you are getting only a

snapshot of how they work

 Determining Requirements
(Observation: STROBE)
STRuctured OBservation of the Environment—a technique for observing the decision-
maker’s physical environment.
Observable Element Questions an Analyst Might Investigate

Office location Who has the corner office? Are the key decision makers dispersed over
separate floors?
Desk placement Does the placement of the desk encourage communication? Does the
placement demonstrate power?
Stationary equipment Does the decision maker prefer to gather and store information personally?
Is the storage area large or small?
Props Is there evidence that the decision maker uses a P C, smartphone, or tablet
computer in the office
External information sources Does the decision maker get much information from external sources such
as trade journals or the Web?
Office lighting and color Is the lighting set up to do detailed work or more appropriate for casual
communication? Are the colors warm and inviting?
Clothing worn by decision Does the decision maker show authority by wearing conservative suits?
makers Are employees required to wear uniforms?
 Determining Requirements
(Document Analysis)
 An analysis of existing documents can give you a wealth of
information:
 Problems with existing systems

 Opportunities to meet new needs with critical information

 Identify key people of current system

 Values of organization who help determine priorities

desired by different users

 Special information processing circumstances that might

not otherwise be identified

 Determining Requirements
(Document Analysis)
 Identify left out features of current software that
may lead to needed features in future systems
 Identify processing rules that must be enforced

 A written work procedure describes how a job or

task is performed
 Formal system – official way a system works as
described in organizational documentation.
 Informal system – way a system actually works
 Determining Requirements
(Document Analysis)
Four major documents analyzed when creating a new system:
1. Written work procedure
2. A form such as the invoice form

 Gives crucial information about the nature of the organization

3. A report such as cash flow statement
 Can be used to analyze to determine which data to capture

4. Documents used to describe the system and how it is used

 Examples include flowcharts, data dictionaries, user manuals

Example of a Procedure
 An Invoice Form from Microsoft
Excel

(Source: Microsoft Corporation)

Example of a Report – As
Statement of Cash Flows
 Analyzing Qualitative
Documents

 Email messages
 Memos
 Signs or posters on bulletin boards
 Corporate Web sites (note the interactivity of Web
sites)
 Policy handbooks
Analysis of Memos Provides Insight into the
Metaphors That Guide the Organization’s
Thinking
 Text Analytics
 Software that can analyze unstructured qualitative data from any source including:
 Transcripts of interviews
 Written reports
 Customers’ communication collected through email, wikis, blogs, chat rooms,
and other social networking sites
 Unstructured, qualitative, or “soft” data are generated through:
 Blogs
 Chat rooms
 Questionnaires using open-ended questions
 Online discussions conducted on the Web
 Exchanges occurring on social media
 Text Analytics

 Text analytics can realize valuable insights into

 What customers are thinking about the organization, the values
and actions of the company
 Customer or vendor motivations for beginning, maintaining,
improving, or discontinuing a relationship
 Text analytics provide insights for an organization’s members who
want to have a rapid and visual yet decidedly qualitative approach
to analyzing text data
 An important element is to design the human activities surrounding
the use of text analytics software
 Comparison of Observation and
Document Analysis
Characteristic Observation Document Analysis
Information Richness High (many channels) Low (passive) and old

Time Required Can be extensive Low to moderate

Expense Can be high Low to moderate

Chance for Follow-Up and Probing Good: probing and clarification Limited: probing possible only if original
questions can be asked during author is available
or after observation
Confidentiality Observee is known to Depends on nature of document; does not
interviewer; observee may change simply by being read
change behavior when observed
Involvement of Subject Interviewees may or may not be None, no clear commitment
involved and committed
depending on whether they
know if they are being observed
Potential Audience Limited numbers and limited Potentially biased by which documents were
time (snapshot) of each kept or because document was not created
for this purpose
 Determining Requirements
(Contemporary Methods for Collecting
System Requirements)

Contemporary Methods for Collecting System

Requirements

Bringing session users, sponsors, analysts, and others

together in a JAD session to discuss and review system
requirements

Iteratively developing system prototypes that refine the

understanding of system requirements in concrete terms by
showing working versions of system features
 Determining Requirements
(Joint Application Design)
 Joint Application Design (JAD) – structured
process in which users, managers, and analysts
work together for several days in a series of
intensive meetings to specify or review system
requirements
 Started by I BM in the late 1970s

 Primary purpose is to collect system

requirements simultaneously from key people
involved with the system
 Enables conflict resolution
 Determining Requirements
(Conditions That Support the Use
of JAD)

 Users are restless and want something new

 The organizational culture supports joint problem-solving
behaviors
 Analysts forecast an increase in the number of ideas
using JAD
 Personnel may be absent from their jobs for the length of
time required
 Determining Requirements
(Joint Application Design)
 Allows the project team, users, and management to
work together to identify requirements for the system
 Often the most useful method for collecting
information from users
 Offsite
 Comfortable surroundings
 Minimize distraction
 Key roles:
 Facilitator
 Scribe
 Determining Requirements
(Joint Application Design)
 Typical JAD participants include:
 J A D session leader – organizes and runs session

 Users – key users of the system

 Managers – managers of the work groups

 Sponsor – high level company executive

 Systems analysts – member of the systems analysis

team
 Scribe – records notes from session

 I S Staff – I S staff composed of programmers, database

analysts, I S planners, and data center personnel

Determining Requirements
(JAD Meeting Room)

JPEG Figure 5-5 Goes Here

 Determining Requirements
(The JAD Session)
 Tend to last 5 to 10 days over a three week period
 Prepare questions as with interviews
 Formal agenda and ground rules
 Facilitator activities
 Keep session on track

 Help with technical terms and jargon

 Record group input

 Help resolve issues

 Post-session follow-up
Selecting Appropriate
Techniques
 Determining Requirements
(Prototyping)
 Prototyping – iterative process of systems
development in which requirements are converted to
a working system that is continually revised through
close collaboration between an analyst and users
 Quickly converts basic requirements into working,

limited version of final information system

 Viewed and tested by the user

 Prompts user for modifications for final system

 The Prototyping Methodology

(Source: Based on Naumann, J. D. & Jenkins, A. M. (1982). Prototyping: The New Paradigm for Systems Development.
MIS Quarterly, 6(3), 29–44)
McConnell’s Evolutionary
Prototyping Model
 Determining Requirements
(Prototyping)
 Evolutionary Prototyping
 Begin by modeling part of the target system

 If successful, evolve rest of the system from

those parts
 Prototype becomes the actual production system

 Throwaway Prototyping

 Prototype is not preserved once system is built

 Quickly developed as a mockup

 Determining Requirements
(Prototyping)
 Prototyping is most useful when:
 User requirements are not clear

 Few users are involved in the system

 Designs are complex and require concrete form to

evaluate
 All want specific system requirements as
communication problems have existed in the past
 Tools and data are readily available to rapidly build a

prototype
 Determining Requirements
(Prototyping)

 Drawbacks of prototyping as a tool include:

 A tendency to avoid creating formal documentation

 Difficult to adapt to other potential users

 Built as standalones makes it difficult to adapt to other

users
 S DLC checks are often bypassed
 Requirements Analysis
Strategies

 There are 3 requirements analysis strategies

1. Business process automation
2. Business process improvement
3. Business process reengineering
 Business Process
Automation
 BPA leaves the basic way in which the
organization operates unchanged and uses
computer technology to do some of the work
 Low risk, but low payoff
 Planners in BPA projects invest significant
time in understanding the as-is system using:
 Problem analysis
 Root cause analysis
 Business Process Automation
(Problem Analysis)

 Users and managers identify problems

with the as-is system and describe how to
solve them in the to-be system
 Tends to solve problems rather than
capitalize on opportunities
 Improvements tend to be small and
incremental
 Business Process
Improvement

 BPI makes moderate changes to the way in

which the organization operates to take
advantage of new opportunities offered by
technology or to copy what competitors are
doing
 Common activities:
 Duration analysis
 Activity-based costing
 Informal benchmarking
 Business Process
Reengineering
 Business process reengineering (B P R) – search for,
and implementation of, radical change in business
processes to achieve breakthrough improvements in
products and services
 Reorganize data flow to eliminate unnecessary steps

 Achieve synergy between previously separate steps

 Become more responsive to future changes

 Can be achieved through creative application of

information technologies
 Business Process
Reengineering

 BPR changes the fundamental way in which

the organization operates
 Spends little time understanding the as-is,
because their goal is to focus on new ideas
and new ways of doing business
 Popular activities:
 Outcome analysis
 Technology analysis
 Activity elimination
 Identifying Processes to
Reengineer
 Key business processes – structured, measured set of
activities designed to produce a specific output for a
particular customer or market
 Focused on organizational outcome (e.g., products)

 Same techniques used as requirements determination

 Which activities need radical change?

 Importance of activity to delivering an outcome

 Feasibility of changing the activity

 Level of dysfunction of current activity

Selecting the Appropriate
Strategies
 Disruptive Technologies
 Information technologies must be applied to radically
improve business processes
 Induction – reasoning from the specific to the general

 Managers learn power of new technologies and

ways to innovate and alter how work is done

 Disruptive technologies – technologies that enable
breaking long-held business rules that inhibit
organizations from making radical business changes
 Long-Held Organizational Rules That
Are Being Eliminated through Disruptive
Technologies
Rule Disruptive Technology
Information can appear in only one place Distributed databases allow the sharing of
at one time. information.
Businesses must choose between Advanced telecommunications networks
centralization and decentralization. can support dynamic organizational
structure.
Managers must make all decisions. Decision-support tools can aid
nonmanagers.
Field personnel need offices where they Wireless data communication and
can receive, store, retrieve, and transmit portable computers provide a “virtual”
information. office for workers.
The best contact with a potential buyer is Interactive communication technologies
personal contact. allow complex messaging capabilities.
You have to find out where things are. Automatic identification and tracking
technology knows were things are.
Plans get revised periodically. High-performing computing can provide
real-time updating.
 Requirements Determination
Using Agile Methodologies

 Continual user involvement replaces the SDLC with

iterative analyze—design—code—test cycle
 Agile usage-centered design focuses on user roles, goals,
and tasks to achieve those goals
 The planning game is a stylized approach to development
to maximize interaction between those who use and those
who build the system
The Iterative Analysis-Design-
Code-Test Cycle
 Steps in the Agile Usage-Centered Design
Method for Requirements Determination
Steps in the Agile Usage-Centered Design Method for Requirements Determination
1. Gather a group of people, including analysts, users, programmers, and testing staff, and sequester them in a room
to collaborate on this design. Include a facilitator who knows this process.
2. Give everyone a chance to vent about the current system and to talk about the features everyone wants in the new
system. Record all of the complaints and suggestions for change on whiteboards or flip charts for everyone to see.
3. Determine what the most important user roles would be. Determine who will be using the system and what their
goals are for using the system. Write the roles on 3 × 5 cards. Sort the cards so that similar roles are close to each
other. Patton (2002) calls this a role model.
4. Determine what tasks user roles will have to complete in order to achieve their goals. Write these down on 3 × 5
cards. Order tasks by importance and then by frequency. Place the cards together based on how similar the tasks
are to each other. Patton calls this a task model.
5. Task cards will be grouped together on the table based on their similarity. Grab a stack of cards. This is called an
interaction context.
6. For each task card in the interaction context, write a description of the task directly on the task card. List the steps
that are necessary to complete the task. Keep the descriptions conversational to make them easy to read. Simplify.
7. Treat each stack as a tentative set of tasks to be supported by a single aspect of the user interface, such as a
screen, page, or dialogue, and create a paper-and-pencil prototype for that part of the interface. Show the basic
size and placement of the screen components.
8. Take on a user role and step through each task in the interaction context as modeled in the paper-and-pencil
prototype. Make sure the user role can achieve its goals by using the prototype. Refine the prototype accordingly.
 eXtreme Programming’s Planning
Game

(Sources: Top to bottom: imtmphoto/ Shutterstock; nenetus/Fotolia; rilueda/Fotolia)

 Electronic Commerce Applications:
Determining System Requirements

 Determining system requirements for Pine Valley

Furniture’s WebStore
 System layout and navigation characteristics

 WebStore and site management system

capabilities
 Customer and inventory information

 System prototype evolution

 Desired Layout and Navigation
Feature of WebStore
Desired Layout and Navigation Desired Layout and Navigation
Feature of WebStore Feature of WebStore
Layout and Design • Navigation menu and logo placement should
remain consistent throughout the entire site
(this allows users to maintain familiarity while
using the site and minimizes users who get
“lost” in the site)
• Graphics should be lightweight to allow for
quick page display
• Text should be used over graphics whenever
possible

Navigation • Any section of the store should be accessible

from any other section via the navigation
menu
• Users should always be aware of what
section they are currently in
 System Structure of the WebStore
and Site Management Systems
WebStore Site Management System
Main Page User Profile Manager
Product Line (category)
Desks
Chairs
Tables,
File Cabinets
Shopping Cart
Checkout
Account Profile
Order Status/History
Customer Comments
Company Info Order Maintenance Manager
Feedback Content (catalog Manager)
Contact Information Reports
Total Hits
Most Frequent Page Views
Users/Time of Day
Users/Day of Week
Shoppers Not Purchasing (used shopping cart—did
not checkout)
Feedback Analysis
 Customer and Inventory for
WebStore
Corporate Customer Home Office Customer Student
Customer
• Company Name • Name • Name
• Company Address • Doing Business as (company name) • School
• Company Phone • Address • Address
• Company Fax • Phone • Phone
• Company Preferred • Fax • E-Mail
Shipping Method • E-Mail
• Buyer Name
• Buyer Phone
• Buyer E-Mail

Inventory Information Inventory Information Inventory

Information
• SK U • Finished Product Size • Available Colors
• Name • Finished Product Weight • Price
• Description • Available Materials • Lead Time
 Stages of System Implementation
of WebStore
Stages of System Implementation of WebStore
Stage 1—Basic Functionality:
•Simple catalog navigation; two products per section—limited attributes set
•25 sample users
•Simulated credit card transaction
•Full shopping cart functionality
Stage 2—Look and Feel:
•Full product attribute set and media (images, video)—commonly referred to as the “product data
catalog”
•Full site layout
•Simulated integration with Purchasing Fulfillment and Customer Tracking systems
Stage 3—Staging/Preproduction:
•Full integration with Purchasing Fulfillment and Customer Tracking systems
•Full credit card processing integration
•Full product data catalog
Thank
You