Systems Analysis and Design

Chapter 3: Determining software requirements

Slides in this presentation contain

hyperlinks. JAWS users should be
able to get a list of links by using
INSERT+F7
Learning Objectives
3.1 Describe options for designing and conducting interviews and
developing a plan for conducting an interview to determine system
requirements

3.2 Explain the advantages and pitfalls of observing workers and analyzing
business documents to determine system requirements

3.3 Explain how computing can provide support for requirements determination

3.4 Participate in and help plan a Joint Application Design session

3.5 Use prototyping during requirements determination

3.6 Describe contemporary approaches to requirements determination

3.7 Understand how requirements determination techniques determination

techniques apply to the development of electronic commerce applications
Introduction
• Analysis has two subphases:
– Requirements determination
– Requirements structuring
System Development Life Cycle with
Analysis Phase Highlighted
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
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 noes within 48 hours of interview
Seek diverse views
Interviewing and Listening

• Open-ended questions – questions in interviews that

have no prespecified answers
• Closed-ended questions – questions in interviews that
ask those responding to choose from among a set of
specified responses
Typical
Interview
Guide
Interviewing Guidelines
• Don’t phrase a question in a way that implies a right or
wrong answer
• Listen carefully to what is being said
• Record notes within 48 hours after an interview
• Don’t set expectations about the new system unless you
know these will be deliverables
• Seek a variety of perspectives from the interviews
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
Directly Observing Users
• Direct observation of workers:
– 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
Learning Objectives
3.1 Describe options for designing and conducting interviews and developing a
plan for conducting an interview to determine system requirements

3.2 Explain the advantages and pitfalls of observing workers and analyzing
business documents to determine system requirements

3.3 Explain how computing can provide support for requirements determination

3.4 Participate in and help plan a Joint Application Design session

3.5 Use prototyping during requirements determination

3.6 Describe contemporary approaches to requirements determination

3.7 Understand how requirements determination techniques determination

techniques apply to the development of electronic commerce applications
Analyzing Procedures and Other
Documents (1 of 3)
• 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
– Identify left out features of current software that may lead to
needed features in future systems
– Identify processing rules that must be enforced
Analyzing Procedures and Other
Documents (2 of 3)
• 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

Example of a Procedure
Analyzing Procedures and Other
Documents (3 of 3)
• Four major documents analyzed when creating a new system:
1. Written work procedure
2. A form such as the invoice form on the previous slide
Gives crucial information about the nature of the organization
3. A report such as the one on the next slide
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
Report – As
Statement of
Cash Flows
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
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
Learning Objectives
3.1 Describe options for designing and conducting interviews and developing a
plan for conducting an interview to determine system requirements

3.2 Explain the advantages and pitfalls of observing workers and analyzing
business documents to determine system requirements

3.3 Explain how computing can provide support for requirements determination

3.4 Participate in and help plan a Joint Application Design session

3.5 Use prototyping during requirements determination

3.6 Describe contemporary approaches to requirements determination

3.7 Understand how requirements determination techniques determination

techniques apply to the development of electronic commerce applications
Joint Application Design (1 of 3)
• 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 IBM in the late 1970s
– Primary purpose is to collect system requirements
simultaneously from key people involved with the
system
– Enables conflict resolution
Joint Application Design (2 of 3)
• Typical JAD participants include:
– JAD 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
– IS Staff – IS staff composed of programmers, database
analysts, IS planners, and data center personnel
Joint Application Design (3 of 3)
• JAD session leader – trained individual who plans and leads
Joint Application Design sessions
• Scribe – person who makes detailed notes of the happenings at
a Joint Application Design session
• End results of a JAD:
– Documentation detailing existing system
– Features of proposed system
Illustration of the Typical Room Layout
for a JAD

(Source: Based on Wood and Silver, 1995)

Learning Objectives
3.1 Describe options for designing and conducting interviews and developing a
plan for conducting an interview to determine system requirements

3.2 Explain the advantages and pitfalls of observing workers and analyzing
business documents to determine system requirements

3.3 Explain how computing can provide support for requirements determination

3.4 Participate in and help plan a Joint Application Design session

3.5 Use prototyping during requirements determination

3.6 Describe contemporary approaches to requirements determination

3.7 Understand how requirements determination techniques determination

techniques apply to the development of electronic commerce applications
Using Prototyping During
Requirements Determination (1 of 4)
• 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
Using Prototyping During
Requirements Determination (2 of 4)
• 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
Using Prototyping During
Requirements Determination (3 of 4)
• 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
Using Prototyping During
Requirements Determination (4 of 4)
• 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
– SDLC checks are often bypassed
Learning Objectives
3.1 Describe options for designing and conducting interviews and developing a
plan for conducting an interview to determine system requirements

3.2 Explain the advantages and pitfalls of observing workers and analyzing
business documents to determine system requirements

3.3 Explain how computing can provide support for requirements determination

3.4 Participate in and help plan a Joint Application Design session

3.5 Use prototyping during requirements determination

3.6 Describe contemporary approaches to requirements determination

3.7 Understand how requirements determination techniques determination

techniques apply to the development of electronic commerce applications
Business Process Reengineering (BPR)

• Business process reengineering (BPR) – 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
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
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 at one Distributed databases allow the sharing of
time. information.
Businesses must choose between centralization Advanced telecommunications networks can
and decentralization. support dynamic organizational structure.
Managers must make all decisions. Decision-support tools can aid nonmanagers.
Field personnel need offices where they can Wireless data communication and portable
receive, store, retrieve, and transmit information. computers provide a “virtual” office for workers.
The best contact with a potential buyer is Interactive communication technologies allow
personal contact. 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 (see table 6-7)
• 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)

Learning Objectives
3.1 Describe options for designing and conducting interviews and developing a
plan for conducting an interview to determine system requirements

3.2 Explain the advantages and pitfalls of observing workers and analyzing
business documents to determine system requirements

3.3 Explain how computing can provide support for requirements determination

3.4 Participate in and help plan a Joint Application Design session

3.5 Use prototyping during requirements determination

3.6 Describe contemporary approaches to requirements determination

3.7 Understand how requirements determination techniques determination

techniques apply to the development of electronic commerce applications
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 Feature of Desired Layout and Navigation Feature of
WebStore 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
• S KU • 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
Summary (1 of 2)
• In this chapter you learned to:
– 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
Summary (2 of 2)
• In this chapter you learned to:
– 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