Text Layout

1
Text Layout

• Introduction (1-4_
• Team Skill 1 Analyzing the problem (5-7)
• Team Skill 2 Understanding User and Stakeholder
  Needs (8-13)
• Team Skill 3 Defining the System (14-17)
• Team Skill 4 Managing Scope (18-19)
• Team Skill 5 Refining the System Definition (
  20-24)
• Team Skill 6 Building the Right System (25-31)

2

• The Challenge of Requirements Elicitation
• Chapter 8

3
Barriers to Elicitation Yes, But Syndrome

• When showing a new system to a user, the reaction
  is often, This is so cool, But, now that I see
  it, what about?
• Users reactions are simply human nature, they
  havent seen your system before and didnt
  understand what you described earlier
• This is an integral part of application
  development and we should plan for it
• Get the Buts out early, elicit the Yes, But
  response early, and then invest majority of
  development efforts in software that has already
  passed this test

4
Barriers to Elicitation Undiscovered Ruins
Syndrome

• The search for requirements is like the search
  for undiscovered ruins
• The more you find, the more you know remain
• Unknown unknowns
• Nonuser stakeholders are often holders of
  otherwise undiscovered requirements
• For an iterative or spiral lifecycle, take the
  approach of We have discovered enough for now
  well find the rest later

5
Barriers to Elicitation User and the
Developer Syndrome

• Communications gap between the user and the
  developer

6
Key Points

• Requirements elicitation is complicated by three
  endemic syndromes
• The Yes, But syndrome stems from human nature
  and the users inability to experience the
  software as they might a physical device
• Searching for requirements is like searching for
  Undiscovered Ruins the more you find, the more
  you know remain
• The User and the Developer syndrome reflects
  the profound differences between these two,
  making communication difficult

7

• The Features of a Product or System
• Chapter 9

8
Stakeholder and User Needs

• Definition a reflection of the business,
  personal, or operational problem (or opportunity)
  that must be addressed in order to justify
  consideration, purchase, or use of a new system
• Examples
• I need easier ways to understand the status of my
  inventory
• Id like to see a big increase in the
  productivity of sales order entry

9
Problem Domain Solution Domain
Needs in user terms
Problem Domain
Features a service provided by the system that
fulfills a need
Software requirements more specific
Solution Domain
10
Features

• Definition a service the system provides to
  fulfill one or more stakeholder needs
• Sometimes in talking to users, they will discuss
  features not needs and can be hard to distinguish
  between them
• Features are a convenient way to describe the
  functionality without getting bogged down in
  detail
• Features are at a high level of abstraction

11
Examples of Features
12
Managing Complexity

• Limit features to somewhere between 25-99 to
  avoid getting in the details
• Add attributes to the features to track
  additional information
• Example attributes
• Name or Unique identifier
• Sponsor
• History data
• Allocated from
• Traced to
• Priority

13
Key Points

• The development team must play a more active role
  in eliciting the requirements for the system
• Product or system features are high-level
  expressions of desired system behavior
• System features should be limited to 25-99, with
  fewer than 50 preferred
• Attributes provide additional information about a
  feature

14

• Interviewing
• Chapter 10

15
Interviewing

• A simple, direct technique that can be used in
  virtually every situation
• Goal make sure that the biases and
  predisposition of the interviewer do not
  interfere with the free exchange of information
• Sociology teaches us that it is extremely
  difficult to truly understand others because each
  of us is biased by our own conceptual filter

16
Questions

• Context-Free Questions
• Questions asking about the nature of the problem
  without context
• Context-free questions force us to listen before
  attempting to invent or describe a potential
  solution
• Helps us learn about the user
• Examples
• Who is the user?
• Who is the customer?
• Are their needs different?
• Where else can a solution to this problem be
  found?
• Solutions-Context Questions
• After context-free questions, then move to
  exploring the solution
• Template on page 104 of text

17
The Interview

• Tips for a successful interview
• Prepare an appropriate context-free interview
• If appropriate, prepare solution-context
  questions
• Before the interview, research the background of
  the stakeholder, try to eliminate questions
• Record the answers
• Refer to the template to be sure you covered all
  the material
• Allow the stakeholder to go off course, you may
  gain additional information
• End interview with a summary key user needs
  discovered
• Record the top needs after each interview and
  record how many stakeholders mentioned that need
• Never do a questionnaire too impersonal

18
HOLIS Case Study

• 15 interviews identified about 20 needs
• Homeowners perspective
• Flexible and modifiable lighting control for
  entire house
• Futureproof (As technology changes, Id like
  compatibility with new technologies that might
  emerge.)
• Attractive, unobtrusive, ergonomic
• Fully independent and programmable or
  reconfigurable switches for each room in the
  house
• Additional security and peace of mind
• Intuitive operations
• A reasonable system cost, with low switch costs
• Easy and inexpensive to fix
• Flexible switch configuration (from 1 to 7 button
  per switch
• Out of sight, out of mind
• 100 reliability

19
HOLIS Case Study

• Homeowners perspective (cont.)
• Vacation security settings
• Ability to create scenes, such as special
  housewide lighting settings for a party
• No increase in electrical or fire hazards in the
  home
• Ability, after a power failure, to restore the
  lights the way they were
• Programmable by the homeowner, using an existing
  PC
• Dimmers wherever the homeowner wants them
• Programmable by the homeowner, without using a PC
• Programmable by somebody else, so the homeowner
  doesnt have to do it
• Ability to turn on some lights manually if the
  systems fails
• Interfaces to the home security system
• Interfaces to other home automation (HVAC,
  audio/video, etc.)

20
HOLIS Case Study

• Distributors perspective
• A competitive product offering
• Some strong product differentiation
• An easy way to train salespeople
• Ability to demonstrate the system in the shop
• High gross margins

21
Key Points

• Interviewing is a simple and direct technique
  that can be used in most circumstances
• Context-free questions can help achieve bias-free
  interviews
• It may be appropriate to search for undiscovered
  requirements by exploring solutions
• Convergence on some common needs will initiate a
  requirements repository for use during the
  project
• A questionnaire is no substitute for an interview

22

• Requirements Workshop
• Chapter 11

23
Requirements Workshop

• Key stakeholders of the project gather together
  for a short, intensive period
• Benefits
• It assists in building an effective team,
  committed to one common purpose the success of
  this project
• All stakeholders get their say no one is left
  out
• It forges an agreement between the stakeholders
  and the development team as to what the
  application must do
• It can expose and resolve political issues that
  are interfering with project success
• The output, a preliminary system definition at
  the feature level, is available immediately

24
Preparing for the Workshop

• Selling the concept
• Ensuring participation of the right stakeholders
• Use the initial list from the problem analysis
  steps
• Attending to Logistics
• Send a proper invitation and ensure travel is
  easy
• Providing warm-up materials
• Project specific information
• Out-of-the-box thinking articles
• Choosing the facilitator
• Prefer and outsider
• Facilitator can not contribute to ideas and
  issues
• Set the agenda

25
Problems and Solutions in Requirements Workshop
26
Key Points

• Te requirements workshops may be the most
  powerful technique for eliciting requirements
• It gathers all key stakeholders together for a
  short but intensely focused period
• The use of an outside facilitator experienced in
  requirements management can help ensure the
  success of the workshop
• Brainstorming is the most important part of the
  workshop

27

• Brainstorming and Idea Reduction
• Chapter 12

28
Live Brainstorming

• Stakeholders gather in one room with an objective
• Rules
• Do not allow criticism or debate
• Let your imagination soar
• Generate as many ideas as possible
• Mutate and combine ideas
• Write down ideas and say them out loud to
  encourage piggybacking of ideas
• Encourage participation with Great Idea rewards

29
Idea Reduction

• Pruning ideas
• Eliminating those that all agree are not worth
  further investigation
• Grouping ideas
• Name groups of similar ideas
• Defining features
• Write a short description of each feature
• Prioritizing ideas
• Cumulative Voting The hundred dollar test
• Each person gets 100 dollars to spend on each
  feature
• Only works once as voters will be biased the
  second time
• Critical, important, useful categorization
• Each voter gets same number of votes as features
  and one third are critical, one third are
  important and one third are useful
• Facilitator multiplies critical votes by 9,
  important votes by 3

30
Case Study HOLIS Attendees at a Requirements
Workshop
31
Analysis of Results

• Built-in security appeared high on the priority
  list
• Competitive differentiator
• Became a defining feature
• Internationalized user interface
• International distributor said with out this
  feature, it would not be introduced in Europe
• Features by priority on page 130

32
Key Points

• Brainstorming involves both idea generation and
  idea reduction
• The most creative, innovative ideas often results
  from combining multiple, seemingly unrelated
  ideas
• Various voting techniques may be used to
  prioritize the ideas created
• Although live brainstorming is preferred,
  Web-based brainstorming may be a viable
  alternative in some situations

33

• Storyboarding
• Chapter 13

34
Storyboarding

• Purpose Gain an early reaction from the users on
  the concepts proposed for the application
• Inexpensive
• User friendly, informal and interactive
• Provides an early review of user interfaces
• Easy to create and easy to modify

35
Types of Storyboarding

• Passive
• Sketches, pictures, screen shots, etc.
• Analyst plays role of system and walks the user
  through the story board
• Active
• A movie that hasnt actually been produced yet
• Animated and automated
• Provides an automated description of the way the
  system behaves in a typical usage
• Interactive
• Lets the user experience the system in as
  realistic a manner as practical
• Requires participation by the user
• Can be close to a throwaway prototype

36
Storyboards

• Tools
• Macromedias Director or Cinemation from Vividus
  Corp.
• Tips
• Dont invest too much
• Make it easy to modify
• Dont make it too functional
• Make it interactive if possible

37
Key Points

• The purpose of storyboarding is to elicit Yes,
  but reactions
• Storyboards can be passive, active, or
  interactive
• Storyboards identify the players, explain what
  happens to them, and describes how it happens
• Make the storyboard sketchy, easy to modify, and
  not shippable
• Storyboard early and often on each project with
  new or innovative content