SYS366

Week 3, Lecture 2
Introduction to Requirements
Gathering:
Part 2 The Stakeholders Needs

Today

Stakeholders
Identifying System Requirements

Functional Requirements
Technical Requirements
Data Requirements

Fact Finding Methods

Interview Questions
WP1
2

Categories of Stakeholders

Five primary categories

Users
Sponsors
Developers
Authorities
Customers

Questions to Ask to
Determine Stakeholders:

Who will be affected by the success or

failure of the new solution?
Who are the users of the system?
Who is the economic buyer for the
system?
Who is the sponsor of the development?
*

* Use Case Modeling, by Bittner & Spence, page 63.

Questions to Ask to
Determine Stakeholders:

Who else will be affected by the outputs

that the system produces?
Who will evaluate and sign off on the
system when it is delivered and deployed?
Are there any other internal or external
users of the system whose needs must be
addressed? *

* Use Case Modeling, by Bittner & Spence, page 63.

Questions to Ask to
Determine Stakeholders:

Are there any regulatory bodies or standards

organizations to which the system must
comply?
Who will develop the system?
Who will install and maintain the new
system?
Who will support and supply training for the
new system?
Who will test and certify the new system? *
* Use Case Modeling, by Bittner & Spence, pages 63 - 64.

Questions to Ask to
Determine Stakeholders:

Who will sell and market the new

system?
Is there anyone else?
Okay, Is there anyone else? *

* Use Case Modeling, by Bittner & Spence, page 64.

Back to In-class exercise 5

Using In-class exercise 4 and the

list of business processes for your
area, update In-class exercise 5 to
include more stakeholders

Today

Stakeholders
Identifying System Requirements

Functional Requirements
Technical Requirements
Data Requirements

Fact Finding Methods

Interview Questions
WP1
9

Identifying System
Requirements

Objective of the requirements capture

and analysis phases is to understand
business processes and develop
requirements for the new system

10

11

Identifying System
Requirements

A requirement is a desired feature,

property or behavior of a system. *

* Unified Modeling Language

12

Identifying System
Requirements

A requirement is either derived directly from stakeholder or

user needs
Or
stated in a contract, standard, specification, or other formally
imposed document. *

* Use Case Modeling, by Bittner & Spence, page 5.

13

Identifying System
Requirements

Stakeholder Need:

A reflection of the business, personal

or operational problemthat must be
addressed to justify consideration,
purchase or use of the new system. *

* Use Case Modeling, by Bittner & Spence, page 72.

14

Identifying System
Requirements

Capturing stakeholder needs allows us

to understand how and to what extent
the different aspects of the problem
affect different [categories] of
stakeholders. *

* Use Case Modeling, by Bittner & Spence, page 72.

15

Identifying System
Requirements

Stakeholder needs are an

expression of the true business
requirements of the system *

* Use Case Modeling, by Bittner & Spence, page 72.

16

Stakeholders Needs

Back to In-class Exercise 5 to

identify Stakeholders needs!

17

Identifying System
Requirements

Features:

Informal statements of capabilities of

the system used often for marketing
and product-positioning purposes as a
shorthand for a set of behaviors of the
system.

Use Case Modeling, by Bittner & Spence, pages 5 - 6.

18

Identifying System
Requirements

Features:

The high-level capabilities (services

or qualities) of the system that are
necessary to deliver benefits to the
users and that help to fulfill the
stakeholders and user needs. *

* Use Case Modeling, by Bittner & Spence, page 74.

19

Identifying System
Requirements
Features can be functional or
non-functional. *

* Use Case Modeling, by Bittner & Spence, page 75.

20

Identifying System
Requirements
Features represent some area of
functionality of the system that, at this
time, is important to the users of the
system *

* Use Case Modeling, by Bittner & Spence, page 75.

21

Identifying System
Requirements
The immediate and informal nature of
features makes them a very powerful tool
when working with the stakeholders and
customers in defining what they want
from a systems release. *

* Use Case Modeling, by Bittner & Spence, page 76.

22

Identifying System
Requirements
Features provide the fundamental basis
for product definition and scope
management *

* Use Case Modeling, by Bittner & Spence, page 76.

23

Identifying System
Requirements

Software Requirements

Individual statements of conditions

and capabilities to which the system
must conform.

Use Case Modeling, by Bittner & Spence, page 5.

Page 6
24

Identifying System
Requirements

Each Software Requirement Is the specification of

an externally observable behavior of the system

Inputs to the system

Outputs from the system
The processing of the system
Attributes of the system
Attributes of the system environment

Use Case Modeling, by Bittner & Spence, page 5.

Page 6

25

Identifying System
Requirements

Software Requirements specify the

things that the software does on behalf
of the user or another system.

Use Case Modeling, by Bittner & Spence, page 5.

Page 6
26

Successful Project
Requirements

Detailed plans

Organized, methodical sequence of

tasks and activities

27

Requirements Gathering

Analyst needs to find out what the

user requires in the new system or
what the user requires to be
changed in an existing system

Gather the requirements by doing fact

finding
Document the requirements

28

Requirements Gathering

For an existing system, analyst needs

to find out:

Functionality

Some of the functionality of the existing

system will be included in the new
system (can be acquired from existing
documentation and code)

Data needs

Some of the data of the existing system

will need to be migrated into the new
system

29

Requirements Gathering

For a new system, analyst needs to find

out:

Functionality

What are the activities the system needs

to perform?
How is the user to interact with the
system?
Are other systems to interact with the
system?

Data needs

What information is needed?

30

Requirements Gathering
Scope of the System

Functional
Requirements
Requirements

Technical

Data

Requirements

31

Describe what a system does or is

expected to do
Functional
Requirements

Include:
Descriptions of the processing
which the system will be
required to carry out

32

Functional Requirements

Include:
Details of the inputs into the system
from paper forms and documents or the
interactions between people and the
system or transfers from other systems
Details of the outputs that are expected
from the system in the form of printed
documents and reports, screen displays
and transfers to other systems
33

Technical Requirements

Describe the aspects of the system

that are concerned with how well it
provides the functional requirements.
Include:

Performance criteria
Anticipated volumes of data
Security requirements (lets talk about
the Bank of Montreal!)
34

Data Requirements

Describe what information the

system is going to need or produce
really a part of Functional and
Technical Requirements
Include

Details of the data that must be held

in the system
35

Themes To Guide Investigation

What are business processes and

operations?

How should the business processes

be performed?

What are the information

requirements?
Understand the Users Needs!
36

Today

Stakeholders
Identifying System Requirements

Functional Requirements
Technical Requirements
Data Requirements

Fact Finding Methods

Interview Questions
WP1
37

Fact Finding Methods

Conduct interviews and discussion with

users
Distribute and collect stakeholder
questionnaires
Review existing reports, forms, and
procedure descriptions
Observe business processes and
workflows
Build prototypes
Conduct JAD sessions
38

Fact Finding Methods

Interviews
Questionnaires
Review Documentation
Observation
Prototypes
JAD sessions
RAD
39

Interviews

Primary technique for fact finding and

information gathering
Most effective way to understand business
functions and business rules
Usually requires multiple sessions
Usually conducted with
customers/clients/users
Clients are not always able to express their
requirements clearly it is up to the analyst
to ask the right questions to help the client
express their requirements

40

Interviews

We are going to concentrate on

interview techniques; the rest of
the slides explain the other
methods for fact finding

41

Conducting effective interviews

Determine who you are going to

interview
Know what information that
stakeholder can provide for you
Prepare for the interview
Conduct the interview
Follow up on the interview

42

Determine who you are going to

interview

Can be business or technical

stakeholders
Business stakeholders provide the
functional and data requirements
Technical stakeholders provide the
technical and data requirements

43

Determine who you are going to

interview

Stakeholders

Executives

Will provide information related to

strategic issues about the business
Need statistical and summary information

Management

Will provide a broad perspective about

the business as well as information about
the system being developed
Need statistical and summary information

44

Determine who you are going to

interview

Stakeholders

Operational staff will provide

information about how the work is
actually done

45

Prepare for the interview

Structured Interview

Formal style
Requires significant preparation

Unstructured Interview

Informal
No pre-determined questions or
objectives

46

Structured Interview

Preparing for the interview

Establish the objectives for the interview

Have a clear agenda
Prepared in advance with a list of open
and closed ended questions
Set the time and location for the
interview
Inform all participants of the objective,
time and location

47

Structured Interview

Questions

Questions should allow you to keep on track and

avoid getting off topic during the interview
Questions can be prepared from any of the
following:

Observations made when existing form and reports

may have been reviewed
Observations made when reviewing the strategic,
tactical or operational plans
Observations made when observing employees doing
current job tasks

Keep length of questions reasonable (15-20 words

or less)

48

Structured Interview

Questions

Phrase questions to avoid

misunderstandings - use simple terms
and wording
Do not ask questions that give clues to
expected answers
Avoid asking two questions in one
Do not ask questions that can raise
concerns about job security or other
negative issues

49

Structured Interview

Questioning Strategies
own
D
p
o
T

High-level: very general

Medium-level: moderately
specific

Low-level: very specific

How can
order processing
be improved?

How can we
reduce the number
of times that customers
return items theyve ordered?
How can we eliminate
shipping the wrong products?

om
Bott

UP

50

Structured Interview

Questions

Open ended questions

Encourages unstructured responses

and generates discussion
Useful when you need to understand
a larger process or to draw out
opinions or suggestions from the
person being interviewed

51

Structured Interview

Questions

Closed ended questions

Limited or restricted response a

simple definitive answer
Used to get information that is more
specific or when you need to verify
facts

52

Structured Interview

Sample interview questions

Open-ended

What do you think about the current

system?
How do you decide what type of
marketing campaigns to run?

Closed-ended

How do customers place orders?

How many orders to you receive a day?

53

Structured Interview

Conduct the interview

Dress appropriately; Arrive on time

Welcome the participants; introduce the attendees;
state the objective and agenda
Ask permission if you want to tape record the
interview
Ask questions from script
Listen closely to the interviewee and encourage them
to expand on key points
Take thorough notes
Identify and document unanswered questions
At end of interview, review outstanding questions
that require follow up
Set date and time for the next, follow-up interview

54

Today

Stakeholders
Identifying System Requirements

Fact Finding Methods

Functional Requirements
Technical Requirements
Data Requirements
Interview Questions

WP1
55

WP1

Requirements for WP1

56

Fact Finding Methods

Interviews
Questionnaires
Review Documentation
Observation
Prototypes
JAD sessions
RAD
57

Questionnaires

A document which contains a number of

questions
Can be paper form or electronic form
(email or web-based)
Allows the analyst to collect information
from a large number of people

People outside the organization (I.e.

customers)
Business users spread across a large
geographic area

58

Questionnaires

Limited and specific information

from a large number of
stakeholders
Preliminary insight
Not well suited for gathering
detailed information
Open-ended questions vs. closeended questions
59

Questionnaires

Similar process to interviewing

Determine who will receive the

questionnaire
Design the questionnaire

Determine objective of questionnaire

Design questions

Follow up questionnaire

60

Questionnaires

Determine who will receive the

questionnaire

Select a sample audience who are

representative of an entire group
Assume 30-50% return rate for paper
and email questionnaires
Assume a 5-30% return rate for webbased questionnaires
61

Questionnaires

Design the Questionnaire

Clearly state the following in the

questionnaire:
The purpose of the questionnaire
Why the respondent was selected to
receive the questionnaire
When the questionnaire is to be
returned

62

Questionnaires

Design the Questionnaire

Let the respondent know when/where

they can see the accumulated
questionnaire responses
Consider providing an inducement to
have the respondent complete the
questionnaire (I.e. a pen)

63

Questionnaires

Design the Questionnaire

Keep the questionnaire brief and user

friendly
Provide clear instructions on how to
complete the questionnaire
Arrange the questions in a logical
order; going from easy to more
complex topics
64

Questionnaires

Design the Questionnaire

Phrase questions to avoid

misunderstandings, use simple terms
and wording
Do not ask questions that give clues
to expected answers
Avoid asking two questions in one
Limit the use of open ended questions
that will be difficult to tabulate
65

Questionnaires

Design the Questionnaire

Do not ask questions that can raise

concerns about job security or other
negative issues
Include a section at the end of the
questionnaire for general comments
Test the questionnaire whenever
possible on a small test group before
finalizing it
66

Fact Finding Methods

Interviews
Questionnaires
Review Documentation
Observation
Prototypes
JAD sessions
RAD
67

Review Existing Reports, Forms,

and Procedure Descriptions

Purposes

Preliminary understanding of
processes
Guidelines / visual cues to guide
interviews

Identify business rules,

discrepancies, and redundancies
Be cautious of outdated material
68

Reviewing existing
documentation

Most beneficial to new employees or

consultants hired to work on a project
Types of documentation that is
reviewed:

Company reports
Organization charts
Policy and Procedures manuals
Job Descriptions
Documentation of existing systems

69

Reviewing existing
documentation

Allows the analyst to get an

understanding of the organization
prior to meeting with employees
Allows the analyst to prepare
questions for either interviews or
questionnaires (other fact finding
techniques)
70

Fact Finding Methods

Interviews
Questionnaires
Review Documentation
Observation
Prototypes
JAD sessions
RAD
71

Observation
An effective way to gather requirements
if obtaining complete information was
not effective through other fact finding
techniques (I.e. interviews and
questionnaires)
Or
An effective way to verify information
gathered from other fact finding sources
(such as interviews)

72

Observation

Observation can be done by having the

analyst observe the client from a
distance (without actually interrupting
the client) or by actually doing the work
of the client

73

Observation

Should be carried out for a period of

time and at different time intervals, not
just once, so that the analyst can
observe different workloads and to
ensure that what the client does is
consistent over different periods of time

74

Observation

Allows the analyst to follow an

entire process from start to finish
Can upset the client if they feel
threatened by new activity going
on around them the client may
behave differently from what they
normally do
75

Fact Finding Methods

Interviews
Questionnaires
Review Documentation
Observation
Prototypes
JAD sessions
RAD
76

Prototypes

A demonstration system

Represents a graphical user interface

Simulates system behavior for various events
Any data displayed on a GUI screen is hardcoded; not retrieved from a database

Constructed to visualize the system

Allows the customer to provide feedback
An effective way to gather requirements
for a new system
Supports JAD or RAD type sessions
77

Fact Finding Methods

Interviews
Questionnaires
Review Documentation
Observation
Prototypes
JAD sessions
RAD
78

Other Methods

Joint Application Development (JAD)

A series of workshops that bring
together all stakeholders (users and
systems personnel)

79

Other Methods

Joint Application Development (JAD)

Consists of the following types of

attendees:

Facilitator: the person who conducts the meeting

and keeps it on track (generally the analyst)
Note taker: the person who records the
information for the session
Clients/Customers/Users: the people who
communicate the requirements, take decisions
and approve the project
Developers: the people who are part of the
development team and need to gather
information

80

Other Methods

Joint Application Development

(JAD)

Takes advantage of the group

dynamics
Increased productivity
May require more than one session
One session may last a few hours,
several days or several weeks
81

Fact Finding Methods

Interviews
Questionnaires
Review Documentation
Observation
Prototypes
JAD sessions
RAD
82

Other Methods

Rapid Application Development

(RAD)
An approach to software development
where the system solution is
delivered fast
Most appropriate for systems which
are not the organizations core
business
83

Other Methods

Rapid Application Development

(RAD)

Can result in:

Inconsistent GUI designs

Poorly documented systems
Software that is difficult to maintain

84