Download
1 / 36
370 likes | 456 Vues
Ir. Waniwatining Astuti, M.T.I. Understanding User and Stakeholder Needs. In Team Skill 1 , we described the skills that will help you understand the problem being solved. .
E N D
Ir. Waniwatining Astuti, M.T.I Understanding User and Stakeholder Needs
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.
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. A. The Challenge of Requirements Elicitation
Objectives : To understand the barriers to requirements elicitation. The "Yes, But" Syndrome The "Undiscovered Ruins" Syndrome The "User and the Developer" Syndrome Barriers to Elicitation
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 . . . ?“ The "Yes, But" Syndrome
3. The "Yes, But" syndrome is human nature and is anintegral part of application development. • We should plan for it. 4. We can significantly reduce this syndrome byapplying techniques that get the "Buts" out early. • In so doing, we elicit the "Yes, But" response early, andwethen can begin to invest the majority of our development efforts
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 everywherecontinually struggle to determine when they aredone with requirements elicitation, that is, whenhave they found all the requirements that arematerial or when have they found at least enough? The "Undiscovered Ruins" Syndrome
Communication gap between the user and the developer. Users and developers are typically from differentworlds, may even speak different languages, andhave different backgrounds, motivations, and objectives. The "User and the Developer" Syndrome
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. B. The Features of a Product or System
To define stakeholders and user needs To define features and give examples To describe attributes of features Objectives
A stakeholder need is a reflection of the business,personal, or operational problem (or opportunity)that must be addressed in order to justifyconsideration, purchase, or use of a new system. The development team will build a better systemonly if it understands the true needs of the stakeholder. That knowledge will give the team the information itneeds to make better decisions in the definition and implementation of the system. Stakeholder and User Needs
Often, these stakeholder and user needs will bevague 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 forall the activities that follow. • Therefore, it is important to spend some significant timeand energy trying to understand them. Stakeholder and User Needs (Cont’d)
A feature is a service the system provides to fulfillone 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 bein conflict with one another • Example: "I want increased order processing rates" and "Iwant to provide a far more user-friendly” Features
Without an understanding of the need behind thefeature, then there is a real risk. Needs and Features If the feature does not solvethe real need for any reason, then the system may fail to meet the users‘ objectives even though the implementation delivered the feature they requested
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. C. INTERVIEWING
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? Context-Free Questions
After we ask the context-free questions, we can explore the suggested solutions. Solutions-Context Questions
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. The Moment of Truth: The Interview
Problemanalysis 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. Compiling the Needs Data
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. A Note on Questionnaires
Objectives To introduce requirements workshops, and to learnhow to plan and run a successfulrequirements workshop. D. Requirements Workshops
The requirements workshop is designed toencourage consensus on the requirements of the application and to gain rapid agreement on a courseof action, all in a very short time. With this technique, key stakeholders of the projectgather together for a short, intensive period, typicallyno more than one or two days. The workshop is facilitated by a team member or,betteryet, by an experienced outside facilitator andfocuses on the creation or review of the high-levelfeatures to be delivered by the new application. Requirements Workshops
It assists in building an effective team, committed to onecommon purpose: the success of this project. All stakeholders get their say; no one is left out. It creates an agreement between the stakeholders and thedevelopment 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. Benefits of Requirements Workshops
Proper preparation is the key to a successful workshop. 1. Selling the Concept It may be necessary to sell the concept inside theorganization by communicating the benefits of theworkshop approach to prospective members of the team. 2. Ensuring the Participation of the Right Stakeholders Identifying stakeholders who can contribute to theprocess and whose needs must be met in order to ensure a successful outcome. Preparing for the Workshop
3. Attending to Logistics Logistics involve everything from structuring the properinvitation 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 preparethe 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 Preparing for the Workshop (Cont’d)
5. Choosing the Facilitator • Ifpossible, 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 teambuilding 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, thatperson must not contribute to the ideas and issues at the meeting. 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, butavoid participating in the content. • Manage any facilities and logistics issues to ensure that thefocus remains on the agenda. • Make certain that all stakeholders participate and have their input heard. • Control disruptive or unproductive behavior. Preparing for the Workshop (Cont’d)
The agenda for the workshop will be based on the needs of theparticular project and the content that needs to be developed at the workshop. Setting the Agenda
Brainstorming and idea reduction: • The most important part of the workshop. • Ideally suited for the workshop setting, and it encouragesa creative and positive atmosphere and gets input from all stakeholders. Running the Workshop
Production and follow-up: • The facilitator distributes the minutes from the meetingand 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 onany 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.
