Requirements Elicitation

1
Requirements Elicitation

• Section Two
• Version 1.0
• Mordad 1383

2
???? ??????

• ????? Elicitation ?? ????? ??? ?? ????? ??????
  ?????? ??????
• ????? ?????? ? ?????? Elicitation
• ????? ????????? ????? ????? Elicitation
• ???? ??? ????? ?????? ??? ?????? ?????? ???
  ??????? ??????? ? ?????? ????? ????? ?????? ?
  ?????? ?? ?????
• ????? ???????? ???? ??????? ?? ????? Elicitation
• ????? ??????? ? ???????? ??????????? ???? ??????
  ????? ?????

3
?????? ??????

• ??? ????? ???? ???? ???? ???? ???? ?? ??? ????
  ??? ???? ??????? ?? ??? ???? ????? ? ????? ?
  ?????? ??? ??? ?? ???? ???? ????? ?? ???? ???? ??
  ?????? ?? ???? ???????. ???? ????? ???? ???
  ?????? ?????? ?? ????? ????? ???? ???? ????
  ??????? ???? ????.
• ?????? ???????? ?? ?? ???? ?? ???? ??? ???? ????
  ?? ????? ???? ?? ?????
• ???? ??????? ????? ?????
• ?????? ?? ?? ?? ?? ??????? ?? ????? ???? ?? ????
  ?????
• ??????????? ?? ?? ????? ?????? ???? ????? ?????
  ????? ?????
• ????????? ???? ??????? ??? ????? ?????? ????? ??
  ????? ?????
• ????????? ?? ?? ????? ??????? ?? ????? ? ???
  ???? ???? ???? ???? ???? ?? ???? ??????? ???? ??
  ?????? ?????
• ?????????? ?? ???? ?? ?????? ?? ?? ?? ???????
  ???? ???? ???? ????? ?????

4
??????? ???? ( ?????????5 -11)

• ?????? ????????? ??? ???? ?? ????? ?????????
  ?????? ???? ???? ??????? ?? ????? ?? ??????.
• ?????? ?????? ???? ???? ?????? ? ????? ???? ??
  ????? ?? ?????.
• ?????? ?????? ?????? ?????? ??????? ???? ????
  ??????? ????? ? ?????? ??? ????? ???? ??????
  ????? ?? ????.

5
Components of requirements elicitation
What
6
Elicitation activities
How

• Application domain understanding
• Application domain knowledge is knowledge of the
  general area where the system is applied.
• Problem understanding
• The details of the specific customer problem
  where the system will be applied must be
  understood.
• Business understanding
• You must understand how systems interact and
  contribute to overall business goals.
• Understanding the needs and constraints of system
  stakeholders
• You must understand, in detail, the specific
  needs of people who require system support in
  their work.

7
The requirements elicitation process
How
8
Elicitation stages
How

• Objective setting
• general goals of the business,
• an outline description of the problem to be
  solved,
• why the system is necessary
• the constraints on the system.
• Background knowledge acquisition
• information about the organisation where the
  system is to be installed
• the application domain of the system and
  information about existing systems
• Knowledge organisation
• The large amount of knowledge which has been
  collected in the previous stage must be organised
  and collated.
• Stakeholder requirements collection
• System stakeholders are consulted to discover
  their requirements

9
Exercise

• What is the relationship between process stages
  and elicitation activities?

10
Requirements analysis and negotiation
How
11
Elicitation, analysis and negotiation
How
12
??????? ???? ( ????????? 13-15)

• ????????? ??? ??? ?? ????? ??? ????? ????? ??
  ????? ??? ?? ????????? ???? ???? ??????? ?????
  ?? ??????
• ?? ???? ?? ????? ??? ???? ?? ????? ????? ?? ????
  ??? ?????? ? ?????? ???? ?? ???? ?????? ????
  ????? ???? ?? ????.
• ?????? ????? ??? ?????? ? ???????? ?? ?? ???
  ????? ??????? ????? ????? ???? ?? ????? ????? ??
  ?????.

13
Elicitation activities
How

• Application domain understanding
• Problem understanding
• Business understanding
• Understanding stakeholders needs

14
Application Domain Understanding
What

• The process by which a software engineer learns
  about the domain to better understand the
  problem
• The domain is the general field of business or
  technology in which the clients will use the
  software
• A domain expert is a person who has a deep
  knowledge of the domain
• Benefits of performing domain analysis
• Faster development
• Better system
• Anticipation of extensions

15
Domain Analysis Outputs
What

• Business Vocabulary
• General knowledge about the domain
• Customers and users
• Environment
• Tasks and procedures currently performed
• Competing software
• Similarities to other domains

16
??????? ???? ( ????????? 17-23)

• ?????? ????????? ??? ??? ?? ????? ??? ???? ??
  ????? ??? ?? ????????? ???? ???? ??????? ?????
  ?? ??????.
• ?? ??? ?????? ?? ??????? ????? ?? ???? ??????
  ????? ?? ?? ??? ?? ?????? ????? ?????? ????? ??
  ?????? ?????? ?? ?? ?????? ????? ??? ?????? ?????
  ???? ?? ?? ? ?????? ????? ??????? ?? ??? ??????
  ??? ???? ?? ????.

17
Elicitation activities
How

• Application domain understanding
• Problem understanding
• Business understanding
• Understanding stakeholders needs

18
Gain Agreement on Problems
How

• What is the problem?
• We technologists tend to rush headlong into
  solution providing - rather than taking time to
  truly understand the problem
• Suggestion Write it down, see if you can get
  everyone to agree on it
• What is the problem, really?
• Searching for root causes - or the problem
  behind the problem - often leads to a clearer
  understanding of the real problem

19
Problem Understanding
What

• A problem can be expressed as
• A difficulty the users or customers are facing,
• Or as an opportunity that will result in some
  benefit such as improved productivity or sales.
• The solution to the problem normally will entail
  developing software
• A good problem statement is short and succinct

20
Analyzing the Problem Overview
Why
21
Why Is Analyzing the Problem Important?
Why

• To avoid the Yes, , but .
• Yes, it meets the requirements, but it
  doesnt solve my problem.
• Problem analysis time is on top of the pyramid
• It pays big dividends if you do it up front
• Analysis work is transferable
• Problem Statement
• Subject is customer
• I need to
• Requirement Statement
• Subject is system
• The system provides

22
Definition of a Problem
What

• A problem can be defined as the difference
  between

Problem
things as perceived
things as desired
and
Gause Weinberg, 1989
23
Problems
What

• Problems are undesirable situations that prevent
  the organization from fully achieving its
  purpose, goals, and/or objectives.
• Opportunities are chances to improve the
  organization even in the absence of specific
  problems.
• Directives are new requirements that are imposed
  by management, government, or some external
  influence.

24
??????? ???? ( ????????? 25-30)

• ?????? ????????? ??? ??? ?? ????? ??????? ?
  ???????? ????? ?????? ????? ?? ????? ?? ??????.
• Pieces ?? ????? ????? ???? ??????? ?? ?????
  ?????? ? ????? ????????? ?? ????? ?? ???.
• ????? ??? ? ????? ?? ????? ????? ???? ?????
  ??????? ? Fish bone Diagram ?? ?????
  ????? ?? ????? ?? ?????.
• ?????? ????? ????? ???? ???? ????? ?????? ? ?????
  ?? ?? ????? ? Pareto Diagram ?? ????? ????? ????
  ??????? ????? ?? ????.

25
The PIECES Problem-Solving Framework
What

• P the need to improve performance
• I the need to improve information (and data)
• E the need to improve economics, control
  costs, or increase profits
• C the need to improve control or security
• E the need to improve efficiency of people
  and processes
• S the need to improve service to customers,
  suppliers, partners, employees, etc.

26
Problem Statement
How
27
Ishikawa Diagram
What

• The Ishikawa diagram is a graphical tool used to
  identify, explore, and depict problems and the
  causes and effects of those problems.
• It is often referred to as a cause-and-effect
  diagram or a fishbone diagram.

28
Cause-and-Effect Analysis
What

• Cause-and-effect analysis is a technique in
  which problems are studied to determine their
  causes and effects.
• In practice, effects can be symptomatic of more
  deeply rooted or basic problems which, in turn,
  must be analyzed for causes and effects until
  such a time as the causes and effects do not
  yield symptoms of other problems.
• List contributing causes to the identified
  problem.
• Keep asking Why? (expand each rib). How much
  does each contribute?

29
What Is the Problem Being Solved?
How
Fishbone Diagram One Method for Root-Cause
Analysis in Solving our Sample Problem
Our Customers Stated Problem
Too Much Litter
Environmental Impact
Too Hard to Recycle Now
We NeedRecyclingMachines Here
Limited Natural Resources
Impact on Unborn Children
People Can Make Money
30
Focus on the Largest Contributors
How
Pareto Diagram
Contribution
Rank in order and use the 80-20 Rule to focus on
the top contributing causes to address the
greatest portion of the problem.
31
??????? ???? ( ????????? 32-37)

• ?? ??? ???? ????? ????? ?? ?????? ??????????
  ?????? ? ????? ???? ?? ?????? ????? ?? ????? ? ??
  ????? ??????? ????? ???? ????? ???? ?? ?????.
• ???????? ?????????? ???????? ????? ? ???????? ???
  ? ?????? ?? ????? ?? ??? ???? ???? ????? ? ?????
  ???? ????? ??? ???.

32
Elicitation activities
How

• Application domain understanding
• Problem understanding
• Business understanding
• Understanding stakeholders needs

33
System Improvement Objectives
What

• An objective is a measure of success. It is
  something that you expect to achieve, if given
  sufficient resources.
• Reduce the number of uncollectible customer
  accounts by 50 percent within the next year.
• Increase by 25 percent the number of loan
  applications that can be processed during an
  eight-hour shift.
• Decrease by 50 percent the time required to
  reschedule a production lot when a workstation
  malfunctions.
• A constraint is something that will limit your
  flexibility in defining a solution to your
  objectives. Essentially, constraints cannot be
  changed.

34
Identify Constraints
What
Political
Economic
Environmental
Technical
Feasibility
System
35
Cause-and-Effect / System Improvement Objectives
How
PROBLEMS, OPPORTUNITIES, OBJECTIVES, AND
CONSTRAINTS MATRIX
36
Analysis checks
How

• Necessity checking
• The need for the requirement is analysed. In some
  cases, requirements may be proposed which dont
  contribute to the business goals of the
  organisation or to the specific problem to be
  addressed by the system.
• Consistency and completeness checking
• The requirements are cross-checked for
  consistency and completeness.
• Consistency means that no requirements should be
  contradictory
• completeness means that no services or
  constraints which are needed have been missed
  out.
• Feasibility checking
• The requirements are checked to ensure that they
  are feasible in the context of the budget and
  schedule available for the system development.

37
Requirements negotiation
How

• Requirements discussion
• Requirements which have been highlighted as
  problematical are discussed and the stakeholders
  involved present their views about the
  requirements.
• Requirements prioritisation
• Disputed requirements are prioritised to identify
  critical requirements and to help the decision
  making process.
• Requirements agreement
• Solutions to the requirements problems are
  identified and a compromise set of requirements
  are agreed. Generally, this will involve making
  changes to some of the requirements.

38
??????? ???? ( ????????? 39-44)

• ?? ???? ?? ????? ??????? ????? ?? ????? ???????
  ??? ?? ????????? ??? ??????? ?????? ???? ????
  ??????? ??????? ?? ????.
• ????? ?????? ????????? ?? ??? ??????? ????? ( ?
  ???? ??????? ) ?? ??? ?????? ??????? ?? ???.
• ??????? ????? ?? ????? ( ???? ?????? ?? ?? ??????
  ????? ?????? ???? ?? ???? ???? ???)? ????????
  ????? ??????? ?? ?? ?? ?? ?????? ????? ??????
  ????? ?? ???? ? ???? ????? ??? ?????? ????? ??
  ????.

39
Elicitation activities
How

• Application domain understanding
• Problem understanding
• Business understanding
• Understanding stakeholders needs

40
Understanding Stakeholder Needs - Overview
What
I need
Problem Space
Problem
Needs
Solution Space
Features
Software Requirements
41
What Are Sources for Our Requirements?
What
Requirement Specs Business PlansPersonal
Goals Business Models
Partners
Customer
Analyst
Domain ExpertsIndustry AnalystsSite
Visits Competitive info.
Bug ReportsChange Requests
Problem Domain
Users
42
What Are The Characteristics of Our Customers?
What
Technology AdoptionProfile
35
30
25
20
of Target Domain Customers
15
10
5
0
Time
(the lifecycle of the technology)

• INNOVATORS
• Technical Influence
• No Money
• Discontinuous innovation
• Company specific

• EARLY ADOPTERS
• Have money
• Strong Influence
• Specific features

• EARLY MAJORITY
• Pragmatists
• Mission critical systems
• Reliability
• Whole product solutions

• LATE MAJORITY
• Conservatives
• Price sensitive
• Simplify
• Commodity
• Demanding

• LAGGARDS
• Skeptics
• Price

Moore, 1991
43
What Problems Might Be Encountered?
How

• Stakeholders know what they want but may not be
  able to articulate it.
• Stakeholders may not know what they want.
• Stakeholders think they know what they want until
  you give them what they said they wanted.
• Analysts think they understand user problems
  better than users.
• Everybody believes everybody else is politically
  motivated.

44
What Does This Process Look Like?
How
Ad hoc requirements
Requirements Spec
Rejected
Reworked Spec
Rejected
Reworked again
Customer
Development
Approved !
45
??????? ???? ( ????????? 46-123)

• ?? ??? ???? ???????? ??? ???? ???? ???? ???? ???
  ????? ??????? ????? ????? ?? ?????. ?? ?? ?? ???
  ??????? ? ???????? ???? ??????? ?? ????? ????? ?
  ????? ?? ??? ????? ?????? ???? ??????? ?? ?? ??
  ?? ??????? ? ???????? ? ???????? ???? ???? ?? ??
  ?? ???? ?? ????? ??? ???? ?? ????.

46
Elicitation techniques
What

• Specific techniques which may be used to collect
  knowledge about system requirements
• This knowledge must be structured
• Partitioning - aggregating related knowledge
• Abstraction - recognising generalities
• Projection - organising according to perspective
• Elicitation problems
• Not enough time for elicitation
• Inadequate preparation by engineers
• Stakeholders are unconvinced of the need for a
  new system

47
Techniques for Eliciting Stakeholder Needs
What

• Document study
• Research and Site Visits
• Observation
• Work Sampling
• Interviews
• Questionnaires
• Prototyping
• Join Requirement Planning
• Brainstorming Idea Reduction
• Use Cases
• Role Playing
• Business Modeling
• Reviewing Customer Requirement Specifications

48
Document Study

• Developing a good feel for the system by studying
  existing documentation, forms, and files.
• A good analyst always gets facts first from
  existing documentation.
• Organization chart (The first document the
  analyst should seek out)

49
Documents that should be studied

• Documents that describe the problem
• Documents that describe the business functions

50
Documents that Describe the Problem

• Interoffice memoranda, studies, memos,
  suggestions, customer complaints, and reports
  that document the problem area.
• Accounting records, performance reviews, work
  measurements reviews and operating reports.
• Past and Present Information systems project
  requests.

51
Documentation of previous system studies

• Various types of flowcharts and diagrams
• Project dictionaries
• Design documentation
• Program documentation
• Computer operations manuals
• Training manuals

52
Documents that describe the business function

• The companys mission statement and strategic
  plan
• Formal objectives for the organization subunits
• Policy manuals that may place constraints
• Quality Manuals (ISO 9001,)
• Standard Operating Procedures, job outlines, or
  task instructions
• Completed forms
• Samples of manual and computerized databases
• Samples of manual and computerized screens and
  reports

53
Research and Site Visits

• Thoroughly research the problem domain.
• Contact or perform site visits at companies that
  have experienced similar problems.
• Reference books
• Professional journals
• Internet

54
Observation
How

• Observation is a fact-finding technique wherein
  the systems analyst either participates in or
  watches a person perform activities to learn
  about the system.
• Advantages?
• Disadvantages?

55
Advantages

• Highly reliable.
• Used to check the validity of data obtained
  directly from individuals.
• Exactly Identifying tasks that have been missed
  or inaccurately described.
• Relatively inexpensive (less employee release
  time and copying)
• Doing work measurement

56
Disadvantages

• People perform work differently when observed
• The work may not involve the level of difficulty
  or volume during that time period
• The tasks observed are subject to various
  interruptions

57
Observation Guidelines
What

• Determine the who, what, where, when, why, and
  how of the observation.
• Obtain permission from appropriate supervisors or
  managers.
• Inform those who will be observed of the purpose
  of the observation.
• Keep a low profile.
• Take notes during or immediately following the
  observation.
• Review observation notes with appropriate
  individuals.
• Don't interrupt the individuals at work.
• Don't focus heavily on trivial activities.
• Don't make assumptions.

58
Techniques for Eliciting Stakeholder Needs
What

• Document study
• Research and Site Visits
• Observation
• Work Sampling
• Interviews
• Questionnaires
• Prototyping
• Join Requirement Planning
• Brainstorming Idea Reduction
• Use Cases
• Role Playing
• Business Modeling
• Reviewing Customer Requirement Specifications

59
Work Sampling
What

• Work sampling is a fact-finding technique that
  involves a large number of observations taken at
  random intervals.
• Sampling is the process of collecting a
  representative sample of documents, forms, and
  records.
• Determining the sample size
• Sample Size 0.25 x (Certainty factor/Acceptable
  error)2
• For a 90 certainty
• Sample Size 0.25(1.645/0.10)2 68

60
Sampling Techniques
How

• Randomization is a sampling technique
  characterized as having no predetermined pattern
  or plan for selecting sample data.
• Stratification is a systematic sampling
  technique that attempts to reduce the variance of
  the estimates by spreading out the samplingfor
  example, choosing documents or records by
  formulaand by avoiding very high or low
  estimates.

61
Techniques for Eliciting Stakeholder Needs
What

• Document study
• Observation
• Work Sampling
• Interviews
• Questionnaires
• Prototyping
• Join Requirement Planning
• Brainstorming Idea Reduction
• Use Cases
• Role Playing
• Business Modeling
• Reviewing Customer Requirement Specifications

62
Interviews
What

• A direct technique that can be used in both
  problem analysis and requirements elicitation
• Designed to gain an understanding of real
  problems and potential solutions from the
  perspectives of the users, customers, and other
  stakeholders

63
Types of Interviews
What

• Unstructured interviews are conducted with only
  a general goal or subject in mind and with few,
  if any, specific questions. The interviewer
  counts on the interviewee to provide a framework
  and direct the conversation.
• In structured interviews the interviewer has a
  specific set of questions to ask of the
  interviewee.

64
Types of Interview Questions
What

• Open-ended questions allow the interviewee to
  respond in any way that seems appropriate.
• Closed-ended questions restrict answers to
  either specific choices or short, direct
  responses.

65
Interview Questions
What

• Types of Questions to Avoid
• Loaded questions
• Leading questions
• Biased questions
• Interview Question Guidelines
• Use clear and concise language.
• Dont include your opinion as part of the
  question.
• Avoid long or complex questions.
• Avoid threatening questions.
• Dont use you when you mean a group of people.

66
The Context-Free Question
What

• The context-free question is a high-level,
  abstract question that can be posed early in a
  project to obtain information about global
  properties of the users problem and potential
  solutions.
• Context-free questions
• Are always appropriate
• Help you understand stakeholder perspectives
• Are not biased with solutions knowledge

67
The Context-Free User Questions
What

• Roles
• Who is the customer?
• Who is the user?
• Are their needs different?
• What are their backgrounds, capabilities,
  environments?
• Use as input when defining actors for Use Cases

68
Context-Free Process Questions
What

• Problems
• What is the problem?
• What is the reason for wanting to solve this
  problem?
• Are there other reasons for wanting to solve this
  problem?
• What is the value of a successful solution?
• How do you solve the problem now?
• What is the trade-off between time and value?
• Where else can the solution to this problem be
  found?

69
Context-Free Product Questions
What

• Product
• What problem does this product solve?
• What business problems could this product create?
• What hazards could exist for the user?
• What environment will the product encounter?
• What are your expectations for usability?
• What are your expectations for reliability?
• What performance/precision is required?

70
Context-Free Meta-questions
What

• Interview
• Am I asking too many questions?
• Do my questions seem relevant?
• Are you the right person to answer these
  questions?
• Are your answers requirements?
• Can I ask more questions later?
• Would you be willing to participate in a
  requirements review?
• Is there anything else I should be asking you?

Gause Weinberg, 1989
71
Interviews Non-Context-Free Examples
What

• Leading questions
• You need a larger screen, dont you?
• Self answering questions
• Are fifty items about right?
• Controlling statements
• Can we get back to my questions?
• Too long-too complex
• I have a three part question, ...

What are better questions to ask?
72
Interviews Warning
What

• Don't ask people to describe things they dont
  usually describe.
• Assumes that users can describe complex
  activities
• Example tying your shoelace
• In general, people can do many things they cannot
  describe
• Empirical evidence - poor correlation
• Ask open-ended questions
• Avoid questions that begin with Why?
• Can provoke a defensive posture
• Dont expect simple answers
• Dont rush the interviewee for answers Listen,
  listen, listen!

73
Procedure to Conduct an Interview
How

1. Select Interviewees
2. Prepare for the Interview
3. An interview guide is a checklist of specific
   questions the interviewer will ask the
   interviewee.
4. Conduct the Interview
5. Follow Up on the Interview

74
Sample Interview Guide
How
Interviewee Jeff Bentley, Accounts Receivable
Manager Date Tuesday, March, 23, 2000 Time 130
P.M. Place Room 223, Admin. Bldg. Subject Curren
t Credit-Checking Policy

• Time Interviewer Interviewee
• Allocated Question of Objective Response
• 1 to 2 min. Objective
• Open the interview
• Introduce Ourselves
• Thank Mr. Bentley for his valuable time
• State the purpose of the interview--to obtain an
  understanding of the existing credit-checking
  policies
• 5 min. Question 1
• What conditions determine whether a customers
  order is approvedfor credit?
• Follow-up
• 5 min. Question 2
• What are the possible decisions or actions that
  might be taken once these conditions have been
  evaluated?
• Follow-up

(continued)
75
Sample Interview Guide (concluded)
How

• 1 min. Question 4
• After a new order is approved for credit and
  placed in the file containing orders that can be
  filled, a customer might request that a
  modification be made to the order. Would the
  order have to go through credit approval again if
  the new total order cost exceeds the original
  cost?
• Follow-up
• 1 min. Question 5
• Who are the individuals that perform the credit
  checks?
• Follow-up
• 1 to 3 mins. Question 6
• May I have permission to talk to those
  individuals to learn specifically how they carry
  out the credit-checking process?
• Follow-up
• 1 min. Objective
• Conclude the interview
• Thank Mr. Bentley for his cooperation and assure
  him that he will be receiving a copy of what
  transpired duringthe interview
• 21 minutes Time allotted for base questions and
  objectives.
• 9 minutes Time allotted for follow-up questions
  and redirection

76
Advantage

• Opportunity to motivate the interviewee to
  respond freely and openly to questions.
• Probe for more feedback
• Adapt or reword questions for each individual
• Observing interviewee nonverbal communication

77
Disadvantage

• Very time consuming
• Success of interviews is highly dependent on the
  systems analyst human relation skills.
• Interviewing may be impractical due to location
  of interviewees.

78
Techniques for Eliciting Stakeholder Needs
What

• Document study
• Observation
• Work Sampling
• Interviews
• Questionnaires
• Prototyping
• Join Requirement Planning
• Brainstorming Idea Reduction
• Use Cases
• Role Playing
• Business Modeling
• Reviewing Customer Requirement Specifications

79
Questionnaires
What

• Questionnaires are special-purpose documents
  that allow the analyst to collect information and
  opinions from respondents.
• Advantages?
• Disadvantages?

80
Types of Questionnaires
What

• Free-format questionnaires offer the respondent
  greater area in the answer.
• A question is asked, and the respondent records
  the answer in the space provided after the
  question.
• Fixed-format questionnaires contain questions
  that require selection of predefined responses
  from individuals.

81
Types of Fixed-Format Questions
What

• Multiple-choice questions
• Rating questions (stating an opinion)
• Ranking questions (ranked in order of preference
  or experience)

82
Questionnaire Procedure
How

1. Determine what facts and opinions must be
   collected and from whom you should get them.
2. Based on the needed facts and opinions, determine
   whether free- or fixed-format questions will
   produce the best answers.
3. Write the questions.
4. Test the questions on a small sample of
   respondents.
5. Duplicate and distribute the questionnaire.

83
Techniques for Eliciting Stakeholder Needs
What

• Document study
• Observation
• Work Sampling
• Interviews
• Questionnaires
• Prototyping
• Join Requirement Planning
• Requirements Workshop
• Brainstorming Idea Reduction
• Use Cases
• Role Playing
• Business Modeling
• Reviewing Customer Requirement Specifications

84
Advantage

• Can be answered quickly.
• Inexpensive means for gathering data from a large
  number of individual
• Maintain anonymity
• Responses can be tabulated and analysed

85
Disadvantage

• Number of respondents is often too low
• Theres no guarantee that an individual will
  answer or expand on all questions.
• Inflexible. No opportunity to obtain voluntary
  information or reword questions.
• Its not possible to observe respondent body
  language.
• No immediate opportunity to clarify a vague or
  incomplete answer
• Difficult to prepare

86
Prototyping
What

• A prototype is an initial version of a system
  which may be used for experimentation
• Prototypes are valuable for requirements
  elicitation because users can experiment with the
  system and point out its strengths and
  weaknesses. They have something concrete to
  criticise
• Rapid development of prototypes is essential so
  that they are available early in the elicitation
  process

87
Types of prototyping
What

• Throw-away prototyping
• To elicit requirements
• Use for the requirements which cause most
  difficulties to customers and which are the
  hardest to understand.
• Evolutionary prototyping
• intended to deliver a workable system quickly to
  the customer.
• Use for well-understood requirements and which
  can deliver useful end-user functionality.
• After extensive use poorly understood
  requirements should be implemented.

88
Prototyping costs and problems
What

• Training costs - prototype development may
  require the use of special purpose tools
• Development costs - depend on the type of
  prototype being developed
• Extended development schedules - developing a
  prototype may extend the schedule although the
  prototyping time may be recovered because rework
  is avoided
• Incompleteness - it may not be possible to
  prototype critical system requirements

89
Techniques for Eliciting Stakeholder Needs
What

• Document study
• Observation
• Work Sampling
• Interviews
• Questionnaires
• Prototyping
• Join Requirement Planning
• Brainstorming Idea Reduction
• Use Cases
• Role Playing
• Business Modeling
• Reviewing Customer Requirement Specifications

90
Joint Requirements Planning
What

• Joint requirements planning (JRP) is a process
  whereby highly structured group meetings are
  conducted for the purpose of analyzing problems
  and defining requirements.
• JRP is a subset of a more comprehensive joint
  application development (JAD) technique that
  encompasses the entire systems development
  process.

91
Requirements Workshops
How

• Accelerate the Elicitation Process
• Gathers all stakeholders together for an
  intensive, focused period
• Facilitator runs the meeting
• Everyone gets their say
• Results immediately available
• Provide a framework for applying the other
  elicitation techniques we will be discussing

92
Benefits of JRP
Why

• JRP actively involves users and management in the
  development project (encouraging them to take
  ownership in the project)
• JRP reduces the amount of time required to
  develop systems
• When JRP incorporates prototyping as a means for
  confirming requirements and obtaining design
  approvals, the benefits of prototyping are
  realized

93
JRP Participants
What

• Sponsor
• Facilitator
• Users and Managers
• Scribes
• IT Staff

94
Workshops Planning and Executing
How

• Sell the workshop
• Establish team
• Handle logistics
• Issue warm-up material
• Prepare agenda

• Facilitate
• Keep on track
• Record findings
• Summarize conclusions

• Synthesize findings
• Condense info

• Present to customer
• Determine next steps

95
Typical room layout for JRP session
How
96
Guidelines for Conducting a JRP Session
How

• Do not unreasonably change the list of questions
• Stay on schedule
• Ensure that the secretary is able to take notes
• Avoid the use of technical words and phrases
• Apply conflict resolution skills
• Allow for breaks
• Encourage group opinion
• Encourage user and management participation
  without allowing individuals to dominate the
  session

97
Workshops Tricks of the Trade
How
98
Techniques for Eliciting Stakeholder Needs
What

• Document study
• Observation
• Work Sampling
• Interviews
• Questionnaires
• Prototyping
• Join Requirement Planning
• Brainstorming Idea Reduction
• Use Cases
• Role Playing
• Business Modeling
• Reviewing Customer Requirement Specifications

99
Brainstorming
What

• Brainstorming is a technique for generating ideas
  during group meetings.
• Participants are encouraged to generate as many
  ideas as possible
• in a short period of time
• without any analysis until all the ideas have
  been exhausted.

100
Rules of Brainstorming
How

• Clearly state the objective of the session
• Generate as many ideas as possible
• Let your imagination soar
• Do not allow criticism or debate
• prune and combine ideas

101
Brainstorming Exercise
How

• 1. Prepare
• Stack of Post-Its for each participant
• Large markers for all
• 2. Gather Ideas
• Write it down
• Shout it out
• Facilitator posts on board
• 3. Prune Ideas
• Combine like ideas
• Eliminate outrageous ideas
• 4. Organize Ideas
• Move the cards around
• Could organize by FURPS

102
Brainstorming Idea Reduction
How

• Discard redundant and outrageous ideas
• Store needs more development ideas
• Mix ideas
• Prioritize those that remain
• Vote
• Single vote
• Cumulative voting
• By features
• Apply evaluation criteria
• Non-weighted
• Weighted

103
Brainstorming Guidelines
How

• Isolate the appropriate people in a place that
  will be free from distractions and interruptions
• Make sure that everyone understands the purpose
  of the meeting
• Appoint one person to record ideas
• Remind everyone of the brainstorming rules
• Within a specified time period, team members call
  out their ideas as quickly as they can think of
  them
• After the group has run out of ideas and all
  ideas have been recorded, then and only then
  should the ideas be analyzed and evaluated
• Refine, combine, and improve the ideas that were
  generated earlier

104
Techniques for Eliciting Stakeholder Needs
What

• Document study
• Observation
• Work Sampling
• Interviews
• Questionnaires
• Prototyping
• Join Requirement Planning
• Brainstorming Idea Reduction
• Use Cases
• Role Playing
• Business Modeling
• Reviewing Customer Requirement Specifications

105
How Can a Use-Case Model Elicit Needs?
How

• Discuss with customer what the system will do
• Identify who will interact with the system
• Identify what interfaces the system should have
• Help verify that no requirements are missing
• Verify that developers understand requirements

Use-Case Model
106
What Is a Use Case?
What
A use case defines a sequence of
actions performed by a system that yields an
observable result of value to an actor

• A use case describes a set (class) of possible
  executions of the system
• A specific execution (instance) of a use case is
  a scenario
• Work on the class level to identify and describe
  the use case
• Set of atomic activities, decisions, and
  requests
• May be performed fully or not at all
• Started by actor

107
What Is a Use Case?
What
108
Define System Boundaries and Functions
What
A Simple Phone System

• A model of what the system does and who it does
  it for

109
Useful Questions in Identifying Use Cases
How

• What are the primary tasks the actor wants the
  system to perform?
• Will the actor create, store, change, remove, or
  read data in the system?
• Will the actor need to inform the system about
  sudden, external changes?
• Does the actor need to be informed about certain
  occurrences in the system?
• Will the actor perform a system startup or
  termination?

110
A Use-Case Model Diagram
What
A Recycling Machine

• A model of what the system is supposed to do (use
  cases), and the system's surroundings (actors).

111
Techniques for Eliciting Stakeholder Needs
What

• Document study
• Observation
• Work Sampling
• Interviews
• Questionnaires
• Prototyping
• Join Requirement Planning
• Brainstorming Idea Reduction
• Use Cases
• Role Playing
• Business Modeling
• Reviewing Customer Requirement Specifications

112
Role Playing
How

• Tools and Techniques
• Scripted walkthroughs
• Scenario analysis
• Class Responsibility Collaboration (CRC) Cards
• Have the analyst play the role of user or
  customer to gain real insights into the problem
  domain
• Have the customer play the role of a user to
  understand the problems they may face

113
Techniques for Eliciting Stakeholder Needs
What

• Document study
• Observation
• Work Sampling
• Interviews
• Questionnaires
• Prototyping
• Join Requirement Planning
• Brainstorming Idea Reduction
• Use Cases
• Role Playing
• Business Modeling
• Reviewing Customer Requirement Specifications

114
Business Modeling
Why

• Modeling, understanding, and improving a
  business.
• A business model provides a static view of the
  structure of the organization and a dynamic view
  of the processes within the organization.
• We need to model the business to localize
  problems or identify opportunities for
  improvements.

115
Why Business Modeling?
Why

• To understand current problems in the target
  organization and identify improvement
  potentials. 
• To assess the impact of organizational change.
• To ensure that customers, end users, developers,
  and other parties have a common understanding of
  the organization.
• To derive the software system requirements needed
  to support the target organization.
• To understand how a to-be-deployed software
  system fits into the organization.

116
Business Modeling Discipline

• Assess the current organization and develop a
  vision of the new organization.
• Defines the processes, roles, and
  responsibilities of that organization

117
Business Modeling Artifacts in RUP

• The RUP provides a process for business modeling.
  
• The Unified Modeling Language (UML) can be
  effectively applied to modeling both software and
  a business.
• Business Modeling Artifacts
• Business use-case model
• Business-analysis model.

118
Business Modeling Scenarios

• Organization Chart Building a simple map of the
  organization and its processes to get a better
  understanding of what the requirements are on the
  application.
• Domain Modeling
• One Business Many Systems
• Generic Business Model
• Generic Business Model
• Revamp

119
Business Modeling Workflow in RUP
120
Business Models Provide Input to Systems
What

• What should business models show?
• Business Processes
• Organizational structure
• Roles and responsibilities

• Products
• Deliveries
• Events

121
Techniques for Eliciting Stakeholder Needs
What

• Document study
• Observation
• Work Sampling
• Interviews
• Questionnaires
• Prototyping
• Join Requirement Planning
• Brainstorming Idea Reduction
• Use Cases
• Role Playing
• Business Modeling
• Reviewing Customer Requirement Specifications

122
Reviewing Customer Requirement Specs
How

• How to identify requirements
• In general, ignore
• Introductions
• General system descriptions
• Glossary of terms
• Other explanatory information
• Find application behaviors or behavioral
  attributes and select and label uniquely
• Keep a list of all identified issues and
  assumptions -- verify with the customer or user
• If you dont know if something is a requirement,
  ask the customer!

123
Exercise

• Which techniques should be used for which
  Applications? Why and Why not?

Technique Application Observation Interview Prototyping
Web Based App.
New Systems
Extension for current applications
.
124
??????? ???? ( ????????? 125-126)

• ?? ?? ????? ???????? ????? ????? ???? ?????
  ??????? ????? ? ???? ???????? ???? ????? ??? ????
  ???? ??? ???? ???? ?? ?????????? ???? ?? ?????
  ??????? ?? ??? ??????? ? ?????? ???? ???? ????
  ???? ????.
• ??????? ???? ????? ??????? ??????? ? ????????
  ??????? ????? ?? ????? ????????? ???? ???? ?????
  ???? ????? ?? ????.
• ???? ?? ??? ??? ????? ? ?????? ?????? ????? ??
  ???? ?? ??? ???????? ??????? ? ????? ?????? ??
  ?????? ????? ??? ?? ???? ??? ???? ?????? ?? ????
  ?? ???????? ??? ?? ???? ???.

125
Eliciting Needs Which Tools to Use?
What

• Requirements Workshop
• Brainstorming
• Use Cases
• Interviews
• Questionnaires
• Role Playing
• Business Modeling
• Requirement Reviews

Hi
Catch Up
Mature
Customer/User Experience
Fuzzy problem
Selling/Teaching
Low
Low
Developer Experience
Hi
Which of these tools might you use for each
quadrant of the graph?
Adapted from Alan Davis
126
A Fact-Finding Strategy
What

1. Learn all you can from existing documents, forms,
   reports, and files
2. If appropriate, observe the system in action
3. Given all the facts that you've already
   collected, design and distribute questionnaires
   to clear up things you don't fully understand
4. Conduct your interviews (or group work sessions)
5. (Optional). Build discovery prototypes for any
   functional requirements that are not understood
   or if requirements need to be validated
6. Follow up

127
???? ?? ??????

• ?? ????? ???? ???? ??? ??????? ?? ?? ?????? ????
  ???? ??? ???? ?? ???? ???? ? ???? ???? ???? ????.
  
• ???? ???? ????? ? ???????? ???? ???????? ?????
  ???????? ???? ??????? ?? ?? ?? ?? ??????? ? ?????
  ????????? ?????? ???? ?? ????? ????? ??? ????
  ????? ???? ?????.
• ????? ??????? ????? ?????
• ?????? ?? ?? ?? ?? ??????? ?? ????? ???? ?? ????
  ?????
• ??????????? ?? ?? ????? ?????? ???? ????? ?????
  ????? ?????
• ????????? ???? ??????? ??? ????? ?????? ????? ??
  ????? ?????
• ????????? ?? ?? ????? ??????? ?? ????? ? ???
  ???? ???? ???? ???? ???? ?? ???? ??????? ???? ??
  ?????? ?????
• ?????????? ?? ???? ?? ?????? ?? ?? ?? ???????
  ???? ???? ???? ????? ?????

128
What Are Sources for Our Requirements?
Requirement Specs Business PlansPersonal
Goals Business Models
Partners
Customer
Analyst
Domain ExpertsIndustry AnalystsSite
Visits Competitive info.
Bug ReportsChange Requests
Problem Domain
Users
129
???? ?? ??????

• ?? ????? ???? ???? ??? ??????? ?? ?? ?????? ????
  ???? ??? ???? ?? ???? ???? ? ???? ???? ???? ????.
  
• ???? ???? ????? ? ???????? ???? ???????? ?????
  ???????? ???? ??????? ?? ?? ?? ?? ??????? ? ?????
  ????????? ?????? ???? ?? ????? ????? ??? ????
  ????? ???? ?????.
• ????? ??????? ????? ?????
• ?????? ?? ?? ?? ?? ??????? ?? ????? ???? ?? ????
  ?????
• ??????????? ?? ?? ????? ?????? ???? ????? ?????
  ????? ?????
• ????????? ???? ??????? ??? ????? ?????? ????? ??
  ????? ?????
• ????????? ?? ?? ????? ??????? ?? ????? ? ???
  ???? ???? ???? ???? ???? ?? ???? ??????? ???? ??
  ?????? ?????
• ?????????? ?? ???? ?? ?????? ?? ?? ?? ???????
  ???? ???? ???? ????? ?????

130
Elicitation activities

• Application domain understanding
• Problem understanding
• Business understanding
• Understanding stakeholders needs

131
???? ?? ??????

• ?? ????? ???? ???? ??? ??????? ?? ?? ?????? ????
  ???? ??? ???? ?? ???? ???? ? ???? ???? ???? ????.
  
• ???? ???? ????? ? ???????? ???? ???????? ?????
  ???????? ???? ??????? ?? ?? ?? ?? ??????? ? ?????
  ????????? ?????? ???? ?? ????? ????? ??? ????
  ????? ???? ?????.
• ????? ??????? ????? ?????
• ?????? ?? ?? ?? ?? ??????? ?? ????? ???? ?? ????
  ?????
• ??????????? ?? ?? ????? ?????? ???? ????? ?????
  ????? ?????
• ????????? ???? ??????? ??? ????? ?????? ????? ??
  ????? ?????
• ????????? ?? ?? ????? ??????? ?? ????? ? ???
  ???? ???? ???? ???? ???? ?? ???? ??????? ???? ??
  ?????? ?????
• ?????????? ?? ???? ?? ?????? ?? ?? ?? ???????
  ???? ???? ???? ????? ?????

132
Identify Constraints
Political
Economic
Environmental
Technical
Feasibility
System
133
???? ?? ??????

• ?? ????? ???? ???? ??? ??????? ?? ?? ?????? ????
  ???? ??? ???? ?? ???? ???? ? ???? ???? ???? ????.
  
• ???? ???? ????? ? ???????? ???? ???????? ?????
  ???????? ???? ??????? ?? ?? ?? ?? ??????? ? ?????
  ????????? ?????? ???? ?? ????? ????? ??? ????
  ????? ???? ?????.
• ????? ??????? ????? ?????
• ?????? ?? ?? ?? ?? ??????? ?? ????? ???? ?? ????
  ?????
• ??????????? ?? ?? ????? ?????? ???? ????? ?????
  ????? ?????
• ????????? ???? ??????? ??? ????? ?????? ????? ??
  ????? ?????
• ????????? ?? ?? ????? ??????? ?? ????? ? ???
  ???? ???? ???? ???? ???? ?? ???? ??????? ???? ??
  ?????? ?????
• ?????????? ?? ???? ?? ?????? ?? ?? ?? ???????
  ???? ???? ???? ????? ?????

134
The PIECES Problem-Solving Framework

• P the need to improve performance
• I the need to improve information (and data)
• E the need to improve economics, control
  costs, or increase profits
• C the need to improve control or security
• E the need to improve efficiency of people
  and processes
• S the need to improve service to customers,
  suppliers, partners, employees, etc.

135
Cause-and-Effect Analysis

• Cause-and-effect analysis is a technique in
  which problems are studied to determine their
  causes and effects.
• In practice, effects can be symptomatic of more
  deeply rooted or basic problems which, in turn,
  must be analyzed for causes and effects until
  such a time as the causes and effects do not
  yield symptoms of other problems.
• List contributing causes to the identified
  problem.
• Keep asking Why? (expand each rib). How much
  does each contribute?

136
???? ?? ??????

• ?? ????? ???? ???? ??? ??????? ?? ?? ?????? ????
  ???? ??? ???? ?? ???? ???? ? ???? ???? ???? ????.
  
• ???? ???? ????? ? ???????? ???? ???????? ?????
  ???????? ???? ??????? ?? ?? ?? ?? ??????? ? ?????
  ????????? ?????? ???? ?? ????? ????? ??? ????
  ????? ???? ?????.
• ????? ??????? ????? ?????
• ?????? ?? ?? ?? ?? ??????? ?? ????? ???? ?? ????
  ?????
• ??????????? ?? ?? ????? ?????? ???? ????? ?????
  ????? ?????
• ????????? ???? ??????? ??? ????? ?????? ????? ??
  ????? ?????
• ????????? ?? ?? ????? ??????? ?? ????? ? ???
  ???? ???? ???? ???? ???? ?? ???? ??????? ???? ??
  ?????? ?????
• ?????????? ?? ???? ?? ?????? ?? ?? ?? ???????
  ???? ???? ???? ????? ?????

137
Techniques for Eliciting Stakeholder Needs

• Document study
• Observation
• Work Sampling
• Interviews
• Questionnaires
• Prototyping
• Join Requirement Planning
• Brainstorming Idea Reduction
• Use Cases
• Role Playing
• Business Modeling
• Reviewing Customer Requirement Specifications

138
???? ?? ??????

• ?? ????? ???? ???? ??? ??????? ?? ?? ?????? ????
  ???? ??? ???? ?? ???? ???? ? ???? ???? ???? ????.
  
• ???? ???? ????? ? ???????? ???? ???????? ?????
  ???????? ???? ??????? ?? ?? ?? ?? ??????? ? ?????
  ????????? ?????? ???? ?? ????? ????? ??? ????
  ????? ???? ?????.
• ????? ??????? ????? ?????
• ?????? ?? ?? ?? ?? ??????? ?? ????? ???? ?? ????
  ?????
• ??????????? ?? ?? ????? ?????? ???? ????? ?????
  ????? ?????
• ????????? ???? ??????? ??? ????? ?????? ????? ??
  ????? ?????
• ????????? ?? ?? ????? ??????? ?? ????? ? ???
  ???? ???? ???? ???? ???? ?? ???? ??????? ???? ??
  ?????? ?????
• ?????????? ?? ???? ?? ?????? ?? ?? ?? ???????
  ???? ???? ???? ????? ?????

139
Eliciting Needs Which Tools to Use?

• Requirements Workshop
• Brainstorming
• Use Cases
• Interviews
• Questionnaires
• Role Playing
• Business Modeling
• Requirement Reviews

Hi
Catch Up
Mature
Customer/User Experience
Fuzzy problem
Selling/Teaching
Low
Low
Developer Experience
Hi
Which of these tools might you use for each
quadrant of the graph?
Adapted from Alan Davis