1. Team Skill 2 Understanding Stakeholders Needs
Based on “Software Requirements Management,
A use case approach”, by Leffingwell and Widrig
Noureddine Abbadeni
King Saud University
College of Computer and Information Sciences

2. Key Points
Requirements elicitation is complicated by three very common syndromes:
The "Yes, But" syndrome ...
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.

3. The Challenge of Requirements Elicitation
Barriers to Elicitation
The "Yes, But" Syndrome … a human nature!
The "Undiscovered Ruins" Syndrome

4. The Challenge of Requirements Elicitation
The "User and the Developer" Syndrome

5. The Challenge of Requirements Elicitation
To address these syndromes we will discuss are the following techniques:
Interviews and questionnaires
Requirements workshops
Brainstorming sessions and idea reduction
Storyboards

6. The Features of a Product or System
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.

7. The Features of a Product or System
Stakeholder and User Needs
“a stakeholder need can be defined as 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.”
Features are a convenient way to describe functionality without getting bogged down in detail.
“A feature is a service the system provides to fulfill one or more stakeholder needs. ”

8. The Features of a Product or System

9. The Features of a Product or System
Attributes of Product Features
“Data elements that provide additional information about the feature.”

11. Interviews / Questionnaires

12. Interviewing 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 not a substitute for an interview!

13. Interviewing Context-Free Questions
A context-free question helps us gain an understanding of the real problem without biasing the user's input.
ask questions about the nature of the user's problem without context for a potential solution
These questions force us to listen before attempting to invent or describe a potential solution
Examples of context-free questions:
Who is the user?
Who is the customer?
Are their needs different?
Where else can a solution to this problem be found?

14. Examples of Context-free questions

15. Examples of Context-free questions

16. Solutions-Context Questions
It may be appropriate to move the questions and start explore solutions after the context-free questions have been asked and answered.
This addition of solution context may give the user new insights and perhaps even a different view of the problem.
After we ask the context-free questions, we can explore the suggested solutions.

17. Preparing for the Interview
Some tips for a successful interview:
Prepare an appropriate context-free interview, and write it down in a notebook for reference during the interview. Review the questions just prior to the interview.
Before the interview, research the background of the stakeholder and the company to be interviewed.
Don't bore the person being interviewed with questions you could have answered in advance.
On the other hand, it wouldn't hurt to briefly verify the answers with the interviewee.
Write down answers in your notebook during the interview.
Refer to the template during the interview to make certain that you're asking the right questions.

18. Interviews / Questionnaires
No substitute for an interview!
Do it first!
Do it for every new class of problem!
Do it for every new project!
The questionnaire technique has some fundamental problems from a requirements gathering perspective:
Relevant questions cannot be decided in advance.
The assumptions behind the questions bias the answers.
It is difficult to explore new domains ("What you really should be asking about is . . ."), and there is no interaction to explore domains that need to be explored.
It is difficult to follow up on unclear user responses.
Questionnaires can be used to:
Validate assumptions and gather statistical preference data.
Used first then follow-up with an interview

19. Workshops

20. Requirements Workshops
Key Points
The requirements workshop 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.

21. Accelerating the process
A properly run requirements workshop has many 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 conflicts and political issues that are interfering with project success.
The output, a preliminary system definition at the features level, is available immediately.

22. Preparing for the Workshop
Selling the Concept
Ensuring the Participation of the Right Stakeholders
Do not forget Logistics !
Providing Warm-Up Materials
Project-specific information
Out-of-the-box thinking
Choosing the Facilitator (not necessarily a team member)

23. Setting the Agenda

24. Workshop issues Problems the facilitator must cope with:
Time management:
It's difficult to get restarted after breaks and lunch.
Key stakeholders may return late
Grandstanding, domineering positions
Lack of input from stakeholders
Negative comments, petty behaviors, and turf wars
Flagging energy after lunch

25. Brainstorming

26. Brainstorming Key Points
Brainstorming involves both idea generation and idea reduction.
The most creative, innovative ideas often result 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.

27. Brainstorming benefits
This elicitation technique has a number of benefits:
It encourages participation by all parties present.
It allows participants to "piggyback" on one another's ideas.
It has high bandwidth: Many ideas can be generated in a short period of time.
The results typically indicate a number of possible solutions to whatever problem is posed.
It encourages out-of-the-box thinking, that is, thinking unlimited by normal constraints.

28. Brainstorming Rules for Brainstorming State the objective.
What features would you like to see in the product?
What services should the product provide?
What opportunities are we missing in the product or the market?
Web-Based Brainstorming

29. Idea Reduction Pruning Ideas Grouping Ideas Defining Features
Prioritizing Ideas
Voting
Categorization as "Critical, Important, Useful"

30. Storyboarding

31. Storyboarding Key Points
The purpose of storyboarding is to elicit early "Yes, But" reactions.
Storyboards can be passive, active, or interactive.
Storyboards identify the players, explain what happens to them, and describe 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.

32. Storyboarding
In practice, there are no rules, constraints, or fixed constructs, on how storyboarding can be done! It can be anything the team wants it to be. The team should feel free to use its imagination to think of creative ways to storyboard a specific application.
Storyboarding applies tools that are both inexpensive and easy to work with:
Is extremely inexpensive
Is user friendly, informal, and interactive
Provides an early review of the user interfaces of the system
Is easy to create and easy to modify
Storyboards also offer an excellent way to ease the "blank-page" syndrome.

33. Types of Storyboards
Three types of storyboards, depending on the mode of interaction with the user:
Passive storyboards tell a story to the user. They can consist of sketches, pictures, screen shots, PowerPoint presentations, or sample application outputs.
Active storyboards try to make the user see "a movie that hasn't actually been produced yet." Active storyboards are animated or automated, perhaps by an automatically sequencing slide presentation, an animation tool, a recorded computer script or simulation, or even a homemade movie. Active storyboards provide an automated description of the way the system behaves in a typical usage or operational scenario.
Interactive storyboards let the user experience the system in as realistic a manner as practical. They require participation by the user. Interactive storyboards can be simulations or mock-ups or can be advanced to the point of throwaway code. An advanced, interactive storyboard built out of throwaway code can be very close to a throwaway prototype.

34. Storyboarding vs. Prototyping

35. What Storyboards Do?
In software, storyboards are used most often to work through the details of the human-to-machine interface.
Storyboards for user-based systems deal with the three essential elements of any activity:
Who the players are
What happens to them
How it happens

36. Tools for Storyboarding
Storyboards can be as varied as the team members' imaginations will allow.
Passive-storyboarding constructs have been made out of tools as simple as paper and pencil or Post-it notes.
More advanced storyboards can be built with presentation managers such as PowerPoint.
Passive, active, and user-interactive storyboards have been built with various packages that allow fast development of user screens and output reports.
Interactive storyboards can be built with a variety of specialty software packages for interactive prototyping, and tools such as Macromedia's Director can be used to create animations and simulations.

37. Tips for Storyboarding
Storyboards help with "Yes, But" and "Undiscovered Ruins" syndromes.
Tips:
Don't invest too much in a storyboard.
If you don't change anything, you don't learn anything. Make the storyboard easy to modify. You should be able to modify a storyboard in few minutes/hours.
Don't make the storyboard too functional.
(Hint: If the application is to be implemented in Java, write the storyboard in Visual Basic.)
Whenever possible, make the storyboard interactive.
Storyboard early.
Storyboard often.
Storyboard on every project that has new or innovative content.

38. Summary Main elicitation techniques: Other techniques:
Interviewing and questionnaires
Requirements workshop (JAD)
Brainstorming and idea reduction
Storyboarding
Other techniques:
Existing Documentation
Observations