1 sys366 week 7, lecture 1 introduction to requirements gathering: part 2 – determining the...

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