1. Understanding User and Stakeholder Needs
Ir. Waniwatining Astuti, M.T.I
Understanding User and Stakeholder Needs

2. In Team Skill 1, we described the skills that will help you understand the problem being solved.
In so doing, we'll also start to gain an understanding of the potential requirements for a system that we will develop to address these needs. While we do this, we will be focusing primarily on stakeholder needs, which live at the top of the requirements pyramid.
In Team Skill 2, we provide a number of techniques the development team can use to gather and to understand the real needs of prospective users and other stakeholders.

3. A. The Challenge of Requirements Elicitation
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.

4. Barriers to Elicitation
Objectives :
To understand the barriers to requirements elicitation.
The "Yes, But" Syndrome
The "Undiscovered Ruins" Syndrome
The "User and the Developer" Syndrome

5. The "Yes, But" Syndrome
For whatever reason, we always see two immediate,
distinct, and separate reactions when the users see
the system implementation for the first time.
"Wow, this is so cool; we can really use this, what a neat job" and so on.
"Yes, but, hmmmmm, now that I see it, what about this ... ? Wouldn't it be nice if ? Whatever happened to ?“

6. 3. The "Yes, But" syndrome is human nature and is an integral part of application development.
We should plan for it.
4. We can significantly reduce this syndrome by applying techniques that get the "Buts" out early.
In so doing, we elicit the "Yes, But" response early, andwe then can begin to invest the majority of our development efforts

7. The "Undiscovered Ruins" Syndrome
In many ways, the search for requirements is like a search for undiscovered ruins.
The more you find, the more you know remain.
You never really feel as though you have found them all, and perhaps you never will.
Indeed, software development teams everywhere continually struggle to determine when they are done with requirements elicitation, that is, when have they found all the requirements that are material or when have they found at least enough?

8. The "User and the Developer" Syndrome
Communication gap between the user and the developer. Users and developers are typically from different worlds, may even speak different languages, and have different backgrounds, motivations, and objectives.

9. Reasons for this problem and some suggested solutions.

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

11. Objectives To define stakeholders and user needs
To define features and give examples
To describe attributes of features

12. Stakeholder and User Needs
A stakeholder need is 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.
The development team will build a better system only if it understands the true needs of the stakeholder.
That knowledge will give the team the information it needs to make better decisions in the definition and implementation of the system.

13. Stakeholder and User Needs (Cont’d)
Often, these stakeholder and user needs will be vague and ambiguous. For example:
"I need easier ways to understand the status of my inventory“
"I'd like to see a big increase in the productivity of sales order entry"
These statements set a most important context for all the activities that follow.
Therefore, it is important to spend some significant time and energy trying to understand them.

14. Features
A feature is a service the system provides to fulfill one or more stakeholder needs
High-level expressions of desired system behavior.
A convenient way to describe functionality without getting bogged down in detail.
Features are often not well defined and may even be in conflict with one another
Example: "I want increased order processing rates" and "I want to provide a far more user-friendly”

15. Examples of Features

16. Needs and Features
If the feature does not solve the real need for any reason, then the system may fail to meet the users‘ objectives even though the implementation delivered the feature they requested
Without an understanding of the need behind the feature, then there is a real risk.

17. Attributes of Features

19. C. 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 no substitute for an interview.

20. Context-Free Questions
A context-free question helps us gain an understanding of the real problem without biasing the user's input.
Examples of such questions include the following.
Who is the user?
Who is the customer?
Are their needs different?
Where else can a solution to this problem be found?

21. Solutions-Context Questions
After we ask the context-free questions, we can explore the suggested solutions.

22. The Moment of Truth: The Interview
Here are some tips for a successful interview :
Prepare an appropriate context-free interview, and jot 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.
Jot down answers in your notebook during the interview. (Don't attempt to capture the data electronically at this time!)
Refer to the template during the interview to make certain that you're asking the right questions.

23. Compiling the Needs Data
Problem analysis will have identified the key stakeholders and users you will need to interview to gain an understanding of the stakeholder's needs. Typically, it does not take many interviews to get a solid understanding of the larger issues. The last section of the interview form, The Analyst's Summary, is used for recording the three most important needs or problems uncovered in the interview.

24. A Note on Questionnaires
There is no substitute for an interview.
Do it first!
Do it for every new class of problem!
Do it for every new project!
Questionnaires can be used to validate assumptions and gather statistical preference data.

25. D. Requirements Workshops
Objectives To introduce requirements workshops, and to learn how to plan and run a successful requirements workshop.

26. Requirements Workshops
The requirements workshop is designed to encourage consensus on the requirements of the application and to gain rapid agreement on a course of action, all in a very short time.
With this technique, key stakeholders of the project gather together for a short, intensive period, typically no more than one or two days.
The workshop is facilitated by a team member or,better yet, by an experienced outside facilitator and focuses on the creation or review of the high-level features to be delivered by the new application.

27. Benefits of Requirements Workshops
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 creates 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 features level, is available immediately.

28. Preparing for the Workshop
Proper preparation is the key to a successful workshop.
1. Selling the Concept
It may be necessary to sell the concept inside the organization by communicating the benefits of the workshop approach to prospective members of the team.
2. Ensuring the Participation of the Right Stakeholders
Identifying stakeholders who can contribute to the process and whose needs must be met in order to ensure a successful outcome.

29. Preparing for the Workshop (Cont’d)
3. Attending to Logistics
Logistics involve everything from structuring the proper invitation to travel arrangements to the lighting in the workshop meeting room.
4. Providing Warm-Up Materials
Send materials out in advance of the workshop to prepare the attendees and also to increase productivity at the workshop session.
Two types of warm-up materials.
Project-specific information
Out-of-the-box thinking preparation
Do not send the data out too far in advance

30. Preparing for the Workshop (Cont’d)
5. Choosing the Facilitator
If possible, have a facilitator who is not a team memberrun the workshop.
The workshop could be facilitated by a team member if that person:
Has received some training in the process
Has demonstrated solid consensus-building or team building skills
Is personable and well respected by both the internal and external team members
Is strong enough to chair what could be a challenging meeting
If the workshop is to be facilitated by a team member, that person must not contribute to the ideas and issues at the meeting.

31. Preparing for the Workshop (Cont’d)
Some of the responsibilities of the facilitator include the following.
Establish a professional and objective tone for the meeting.
Start and stop the meeting on time.
Establish and enforce the "rules" for the meeting.
Introduce the goals and agenda for the meeting.
Manage the meeting and keep the team "on track.“
Facilitate a process of decision and consensus making, but avoid participating in the content.
Manage any facilities and logistics issues to ensure that the focus remains on the agenda.
Make certain that all stakeholders participate and have their input heard.
Control disruptive or unproductive behavior.

32. Setting the Agenda
The agenda for the workshop will be based on the needs of the particular project and the content that needs to be developed at the workshop.

33. Sample Agenda for the Requirements Workshop:

34. Running the Workshop Brainstorming and idea reduction:
• The most important part of the workshop.
• Ideally suited for the workshop setting, and it encourages a creative and positive atmosphere and gets input from all stakeholders.

35. Production and follow-up:
• The facilitator distributes the minutes from the meeting and records any other outputs (his job now is finished).
• The responsibility for success is again in the hands of the development team.
• The project leader has the responsibility to follow up on any open action items that were recorded at the meeting.
• The output of the meeting will be a simple list of ideas or suggested product features.
• In some cases, additional workshops with other stakeholders will be scheduled.

36. E. Brainstorming and Idea Reduction