2/15/2022

Applied Systems Analysis

Topic 3

Determining System
Requirements

Learning Objectives

• Introduction to Systems Development

• Requirements

• Requirements Determination

• Traditional Methods of Collecting System Requirements

• Contemporary Methods of Collecting System Requirements

2
 2/15/2022

Systems Analyst

• The organizational role most responsible for the analysis

and design of information systems (Valacich and George 2021)

• The systems analyst plays a key role in the SDLC,

analyzing the business situation, identifying opportunities
for improvements, and designing an information system to
implement the improvements (Dennis et al 2021)

Developing Information Systems and the

Systems Development Life Cycle
• Systems development methodology
– A standard process followed in an organization to
conduct all the steps necessary to analyze, design,
implement, and maintain information systems

• The systems development life cycle (SDLC)

– The traditional methodology used to develop, maintain,
and replace information systems
▪ Features several phases that mark the progress of
the systems analysis and design efforts

4
 2/15/2022

Systems Development Life Cycle

The information systems development life cycle (SDLC)

• A circular process, with the end of the useful life leading to

the start of another

• At any given phase the project can return to a previous

phase when needed

• Can be an iterative process

Systems Development Life Cycle

Valacich and George 2021

6
 2/15/2022

Systems Development Life Cycle

Dennis et al. 2022

System Development Life Cycle with

Analysis Phase Highlighted

8
 2/15/2022

Requirements

Requirements Determination

• Requirement's determination is performed to transform

the system request’s high-level statement of business
requirements into a more detailed, precise list of what the
new system must do

• This detailed list of requirements is supported, confirmed,

and clarified by the other activities of the analysis phase

10
 2/15/2022

What is a Requirement?

• A requirement is a statement of what the system must do

or what characteristics it needs to have

• Types of requirements:
• What the business needs (business requirements)
• What the users need to do (user requirements)
• What the software should do (functional requirements)
• Characteristics the system should have (nonfunctional
requirements)
• How the system should be built (system requirements)

11

Business Requirement
• In the systems request, there are statements that
describe the reasons for proposing the systems
development project

• These statements reflect the business requirements that

this system will fulfill

• When the systems development project is complete,

success will be measured by evaluating whether the stated
business requirements have been achieved
– Therefore, they provide the overall direction for the project

12
 2/15/2022

User Requirements
• What the user needs to do to complete a needed job or
task

• Focus on user tasks that are integral to business

operations

• Understanding user tasks helps reveal ways that the new

system can support those tasks

13

Functional Requirements
• A process the system should perform as a part of
supporting a user task, or

• Information the system should provide as the user

performs a task

• Specify the support the system will provide to the user in

fulfilling his/her work tasks

14
 2/15/2022

More On Functional Requirements

15

Sample Functional Requirements

16
 2/15/2022

Non Functional Requirements

• Nonfunctional requirements are
– the quality attributes,
– design, and implementation constraints, and
– external interfaces which a product must have

• This requirement category includes important behavioural properties

that the system must have

• Behavioral properties the system must have

– Operational – physical and technical operating environment
– Performance – speed, capacity, and reliability needs
– Security – access restrictions, needed safeguards
– Cultural and political – issues that will affect the final system

17

More On Non Functional Requirements

•

18
 2/15/2022

More On Non Functional Requirements

19

Sample Non Functional Requirements

20
 2/15/2022

Requirements Determination

21

The Process of Determining Requirements

• Both business and IT perspectives are needed to

determine requirements during the analysis phase

– Systems analysts may not understand the true

business needs of the users

– The business users may not be aware of promising

new technologies

• The analyst must also consider how best to elicit the

requirements from the stakeholders

22
 2/15/2022

The Process of Determining Requirements

• There are a variety of elicitation techniques that can be

used to acquire information

• The evolution of the requirements definition must be

carefully managed

• Keeping the requirements list tight and focused is a key to

project success

23

The Requirements Definition Statement

• Sometimes, requirements are prioritized on the

requirements definition statement

• The most obvious purpose of the requirements definition is

to provide a clear statement of what the new system
should do

• A critically important purpose of the requirements definition

is to define the scope of the system

24
 2/15/2022

The Requirements Definition Statement

• The requirements definition statement is a straightforward

text report that simply lists the functional and nonfunctional
requirements in an outline format

– Usually just called the requirements definition

• Requirements are typically identified by numbering

25

Requirements Elicitation Techniques

• An analyst knows that there is a problem to be solved and

therefore must look for clues that uncover the solution

• Unfortunately, the clues are not always obvious, so the

analyst needs to notice details, talk with witnesses, and
follow leads

• The best analysts will thoroughly search for requirements

using a variety of techniques and make sure that the current
business processes and the needs for the new system are
well understood before moving into design

26
 2/15/2022

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

27

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

28
 2/15/2022

Organizational Components to
Understand
• Systems analysts need to understand:
– 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

29

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

30
 2/15/2022

Traditional Methods of Collecting

System Requirements

31

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

32
 2/15/2022

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

33

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

34
 2/15/2022

Typical
Interview
Guide

35

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

36
 2/15/2022

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

37

Nominal Group Technique (N G T)

• 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

38
 2/15/2022

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 behaviour when they know they are
being observed

– Observation cannot be continuous; thus you are getting only a

snapshot of how they work

39

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

40
 2/15/2022

Analyzing Procedures and Other

Documents (2 of 3)
– 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

41

Example
of a
Procedure

42
 2/15/2022

An Invoice Form from Microsoft Excel

43

Analyzing Procedures and Other

Documents (3 of 3)
• Four major documents analyzed when creating a new system:
1. Written work procedure (see figure 6-3)
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

44
 2/15/2022

Example of a
Report – As
Statement of
Cash Flows

45

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

46
 2/15/2022

Contemporary Methods of Collecting

System Requirements

47

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

48
 2/15/2022

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

49

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 – programmers, database analysts, IS planners, etc

50
 2/15/2022

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

51

Illustration of the Typical Room Layout for

aJAD

52
 2/15/2022

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

53

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)

54
 2/15/2022

McConnell’s Evolutionary Prototyping

Model

Figure 6-8:

55

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

56
 2/15/2022

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

57

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

– S D L C checks are often bypassed

58
 2/15/2022

Business Process Reengineering (B P R)

• 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

59

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

60
 2/15/2022

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

61

Long-Held Organizational Rules That Are Being

Eliminated through Disruptive Technologies

Rule Disruptive Technology

Information can appear in only one place at Distributed databases allow the sharing of
one time. information.
Businesses must choose between Advanced telecommunications networks can
centralization and decentralization. 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 portable
can receive, store, retrieve, and transmit computers provide a “virtual” office for
information. 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.

62
 2/15/2022

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

63

The Iterative Analysis-Design-Code-Test Cycle

64
 2/15/2022

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.

65

Steps in the Agile Usage-Centered Design

Method for Requirements Determination
Steps in the Agile Usage-Centered Design Method for Requirements
Determination

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.

66
 2/15/2022

eXtreme Programming’s Planning Game

67

Summary (1 of 2)
• In this topic you learned to:
– Overview of the SDLC

– Functional and Non-Functional Requirements

– 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

68
 2/15/2022

Summary (2 of 2)
– 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

69