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

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.

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

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

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

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.

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. ”

The Features of a Product or System

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

Interviews / Questionnaires

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!

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?

Examples of Context-free questions

Examples of Context-free questions

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.

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.

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

Workshops

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.

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.

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)

Setting the Agenda

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

Brainstorming

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.

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.

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

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

Storyboarding

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.

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.

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.

Storyboarding vs. Prototyping

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

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.

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.

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