SYS366

1
SYS366

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

2
Agenda

• Stakeholders
• Identifying System Requirements
• Functional Requirements
• Technical Requirements
• Data Requirements
• Fact Finding Methods
• Interview Questions
• WP1

3
Categories of Stakeholders

• Five primary categories
• Users
• Sponsors
• Developers
• Authorities
• Customers

4
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.

5
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.

6
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.

7
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.

8
Agenda

• 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
Identifying System Requirements

• A requirement is a desired feature, property or
  behavior of a system.
• Unified Modeling Language

11
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.

12
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.

13
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.

14
Identifying System Requirements

• Stakeholder needs are an expression of the true
  business requirements of the system
• Use Case Modeling, by Bittner Spence, page
  72.

15
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.

16
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.

17
Identifying System Requirements

• Features can be functional or
• non-functional.
• Use Case Modeling, by Bittner Spence, page
  75.

18
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.

19
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.

20
Identifying System Requirements

• Features provide the fundamental basis for
  product definition and scope management
• Use Case Modeling, by Bittner Spence, page
  76.

21
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

22
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

23
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

24
Successful Project Requirements

• Detailed plans
• Organized, methodical sequence of tasks and
  activities

25
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

26
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

27
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?

28
Requirements Gathering

• Scope of the System
• Functional Technical Data
• Requirements Requirements
  Requirements

29
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

30
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

31
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!)

32
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

33
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!
34
Agenda

• Stakeholders
• Identifying System Requirements
• Functional Requirements
• Technical Requirements
• Data Requirements
• Fact Finding Methods
• Interview Questions
• WP1

35
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

36
Fact Finding Methods

• Interviews
• Questionnaires
• Review Documentation
• Observation
• Prototypes
• JAD sessions
• RAD

37
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

38
Interviews

• We are going to concentrate on interview
  techniques the rest of the slides explain the
  other methods for fact finding

39
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

40
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

41
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

42
Determine who you are going to interview

• Stakeholders
• Operational staff will provide information about
  how the work is actually done

43
Prepare for the interview

• Structured Interview
• Formal style
• Requires significant preparation
• Unstructured Interview
• Informal
• No pre-determined questions or objectives

44
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

45
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)

46
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

47
Structured Interview

• Questioning Strategies

Top Down
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?
High-level very general
Medium-level moderately specific
Bottom UP
Low-level very specific
48
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

49
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

50
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?

51
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

52
Agenda

• Stakeholders
• Identifying System Requirements
• Functional Requirements
• Technical Requirements
• Data Requirements
• Fact Finding Methods
• Interview Questions
• WP1

53
WP1

• Requirements for WP1

54
Fact Finding Methods

• Interviews
• Questionnaires
• Review Documentation
• Observation
• Prototypes
• JAD sessions
• RAD

55
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

56
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

57
Questionnaires

• Similar process to interviewing
• Determine who will receive the questionnaire
• Design the questionnaire
• Determine objective of questionnaire
• Design questions
• Follow up questionnaire

58
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

59
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

60
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)

61
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

62
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

63
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

64
Fact Finding Methods

• Interviews
• Questionnaires
• Review Documentation
• Observation
• Prototypes
• JAD sessions
• RAD

65
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

66
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

67
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)

68
Fact Finding Methods

• Interviews
• Questionnaires
• Review Documentation
• Observation
• Prototypes
• JAD sessions
• RAD

69
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)

70
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

71
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

72
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

73
Fact Finding Methods

• Interviews
• Questionnaires
• Review Documentation
• Observation
• Prototypes
• JAD sessions
• RAD

74
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

75
Fact Finding Methods

• Interviews
• Questionnaires
• Review Documentation
• Observation
• Prototypes
• JAD sessions
• RAD

76
Other Methods

• Joint Application Development (JAD)
• A series of workshops that bring together all
  stakeholders (users and systems personnel)

77
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

78
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

79
Fact Finding Methods

• Interviews
• Questionnaires
• Review Documentation
• Observation
• Prototypes
• JAD sessions
• RAD

80
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

81
Other Methods

• Rapid Application Development (RAD)
• Can result in
• Inconsistent GUI designs
• Poorly documented systems
• Software that is difficult to maintain