Transcript Week 1 - Agenda

SYS366
Week 3, Lecture 2
Introduction to Requirements Gathering:
Part 2 – The Stakeholders’ Needs
1
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
3
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.
4
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.
5
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.
6
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.
7
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
8
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 problem…that 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 system’s
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.
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
Technical
Requirements
Data
Requirements
31
Functional Requirements


Describe what a system does or is
expected to do
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 (let’s 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
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 they’ve ordered?
How can we eliminate
shipping the wrong products?
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. close-ended
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 web-based
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 hard-coded;
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 organization’s 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