Upload
arnold-ralph-reeves
View
218
Download
0
Tags:
Embed Size (px)
Citation preview
1
SYS366
Week 7, Lecture 1Introduction to Requirements Gathering: Part 2 – Determining The Stakeholders’ Needs
2
Today Stakeholders Identifying System Requirements
Functional Requirements Technical Requirements Data Requirements
Fact Finding Methods Interview Questions
3
Who is a Stakeholder?
“An individual who is materially affected by the outcome of the system or the project (s) producing the system” *
Or the people who suffer from the problem being addressed *
*Use Case Modeling by Bittner and Spence, p. 51.
4
Categories of Stakeholders
Five primary categories Users Sponsors Developers Authorities Customers
5
Users For purposes of Exercise 5 and
WP2, we are going to focus only on the User Stakeholders
6
User Stakeholders Those who actually use the system Technology Adopters
Interested in using all of the features of the system; in pushing it to the limit of its capabilities
Standard Users Not interested in using all of the
features of the system. Rather they want a system that allows them to perform their business processes simply and in the same way that they are used to performing them
7
Standard Users Those in day-to-day business
operations use and change information
Those using queries view calculated/collected information
Management use reports, statistics demand controls
Executives strategic issues
8
User Stakeholders Non-living users
Mechanical devices that the system must interact with
Other business areas Other systems
9
Review Let’s return to Exercises 2 & 4 to
be sure that you have identified all of the technology adopters, standard users, and other business areas that you must interact with
10
Today Stakeholders Identifying System Requirements
Functional Requirements Technical Requirements Data Requirements
Fact Finding Methods Interview Questions
11
Identifying Systems Requirements
Objective of the requirements capture and analysis phases is to understand business processes and develop requirements for the new system
12
Identifying System Requirements
“A requirement is a desired feature, property or behavior of a system.” *
* Unified Modeling Language
13
Identifying System Requirements
A requirement “is either derived directly from stakeholder or user needs
Orstated in a contract, standard, specification, or other formally imposed document.” *
* Use Case Modeling, by Bittner & Spence, page 5.
14
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.
15
Identifying System Requirements
“Software Requirements specify the things that the software does on behalf of the (human) user or another system.” *
* Use Case Modeling, by Bittner & Spence, page 6.
16
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
17
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
18
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?
19
Requirements GatheringScope of the System
Functional Technical DataRequirements Requirements
Requirements
20
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
21
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
22
Functional Requirements
Include: 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
23
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
24
Data Requirements Describe what information the
system is going to need or produce – really hard to separate from Functional and Technical Requirements
Include Details of the data that must be held
in the system
25
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!
26
Today Stakeholders Identifying System Requirements
Functional Requirements Technical Requirements Data Requirements
Fact Finding Methods Interview Questions
27
Fact Finding Methods Conduct interviews and discussion
with users Distribute and collect stakeholder
questionnaires Review existing reports, forms,
and procedure descriptions
28
Fact Finding Methods Observe business processes and
workflows Build prototypes Conduct JAD sessions RAD
29
Fact Finding Methods Interviews Questionnaires Review Documentation Observation Prototypes JAD sessions RAD
30
Interviews Primary technique for fact finding
and information gathering Most effective way to understand
business functions and business rules
Usually requires multiple sessions
31
Interviews 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
32
Interviews We are going to concentrate on
interview techniques; the rest of the slides explain the other methods for fact finding
33
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
34
Determine who you are going to interview
Can be standard (business) or technical (technology adopters) users Standard users provide the
functional and data requirements Technical (technology adopters)
users provide the technical and data requirements
35
Determine who you are going to interview
Can be standard (business) or technical (technology adopters) users in your business area or the other business areas that communicate with yours
36
Styles of Interviews
Structured Interview Formal style Requires significant preparation
Unstructured Interview Informal No pre-determined questions or
objectives
37
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
38
Questions Should allow you to keep on track and
avoid getting off topic during the interview 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)
39
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
40
Questioning Strategies
How canorder processing
be improved?
How can wereduce the number
of times that customersreturn items they’ve ordered?
How can we eliminate shipping the wrong products?
High-level: very general
Medium-level: moderatelyspecific
Low-level: very specific
Top Down
Bottom UP
41
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
42
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
43
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?
44
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
45
Structured Interview Conduct the interview
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
46
Interviews Now In-class exercise 5
47
Fact Finding Methods
Interviews Questionnaires Review Documentation Observation Prototypes JAD sessions RAD
48
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
49
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
50
Questionnaires Similar process to interviewing
Determine who will receive the questionnaire
Design the questionnaire Determine objective of questionnaire Design questions
Follow up questionnaire
51
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
52
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
53
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)
54
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
55
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
56
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
57
Fact Finding Methods Interviews Questionnaires Review Documentation Observation Prototypes JAD sessions RAD
58
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
59
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
60
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)
61
Fact Finding Methods
Interviews Questionnaires Review Documentation Observation Prototypes JAD sessions RAD
62
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)
63
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
64
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
65
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
66
Fact Finding Methods
Interviews Questionnaires Review Documentation Observation Prototypes JAD sessions RAD
67
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
68
Fact Finding Methods
Interviews Questionnaires Review Documentation Observation Prototypes JAD sessions RAD
69
Other Methods Joint Application Development (JAD)
A series of workshops that bring together all stakeholders (users and systems personnel)
70
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
71
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
72
Fact Finding Methods Interviews Questionnaires Review Documentation Observation Prototypes JAD sessions RAD
73
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
Example: Xtreme Programming
74
Other Methods Rapid Application Development
(RAD) Can result in:
Inconsistent GUI designs Poorly documented systems Software that is difficult to maintain