1. Instructore: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department Requirement engineering Finding the Voice of the Customer

2. Instructore: Tasneem Darwish2 Outlines  Overview  Sources of Requirements  User Classes  Finding User Representatives  The Product Champion  Who Makes the Decisions?

3. Instructore: Tasneem Darwish3 Finding User Representatives  Every kind of project needs suitable user representatives to provide the voice of the customer.  The user representatives should be involved throughout the development life cycle, not just in an isolated requirements phase at the beginning.  Each user class needs to be represented.

4. Instructore: Tasneem Darwish4 Finding User Representatives  It's easiest to gain access to actual users when you're developing applications for deployment within your own company.  If you're developing commercial software, you might engage people from your current beta-testing or early- release sites to provide requirements input.  Consider setting up focus groups of current users.

5. Instructore: Tasneem Darwish5 Finding User Representatives  Be sure that the focus group represents the kinds of users whose needs should drive your product development.  Include both expert and less experienced customers.  If your focus group represents only blue-sky thinkers, you might end up with many sophisticated and technically difficult requirements that many of your target customers don't find interesting.

6. Instructore: Tasneem Darwish6 Finding User Representatives  The figure illustrates some typical communication pathways that connect the voice of the user to the ear of the developer.

7. Instructore: Tasneem Darwish7 Finding User Representatives  One study indicated that highly successful projects used more kinds of communication links and more direct links between developers and customers than did less successful projects.  The most direct communication occurs when developers can talk to appropriate users themselves.  intervening layers between the user and the developer increase the chance of miscommunication.

8. Instructore: Tasneem Darwish8 Finding User Representatives  Some of these intervening layers add value as when a skilled requirements analyst works with users to collect, evaluate, refine, and organize their input.

9. Instructore: Tasneem Darwish9 The Product Champion  Each product champion serves as the primary interface between members of a single user class and the project's requirements analyst.  the champions will be actual users, not surrogates such as:  funding sponsors,  procuring customers,  marketing staff,  user managers,  or software developers pretending to be users.

10. Instructore: Tasneem Darwish10 The Product Champion  Product champions collect requirements from other members of the user classes they represent and reconcile inconsistencies.  Requirements development is thus a shared responsibility of the analysts and selected customers, although the analyst writes the requirements documents.

11. Instructore: Tasneem Darwish11 The Product Champion  The best product champions characteristics:  have a clear vision of the new system and are enthusiastic about it.  should be effective communicators who are respected by their colleagues.  They need a thorough understanding of the application domain and the system's operating environment.  They should be hard-working for other assignments on their principal job.

12. Instructore: Tasneem Darwish12 The Product Champion  The product champion approach works best if each champion is fully empowered to make binding decisions on behalf of the user class he represents.  However, the champions must remember that they are not the sole customers.  Problems arise when the product champion don’t adequately communicate with his peers and presents only his own wishes and ideas.

13. Instructore: Tasneem Darwish13 External Product Champions  When developing commercial software, it can be difficult to find people to serve as product champions from outside your company.  If you have a close working relationship with some major corporate customers, they might welcome the opportunity to participate in requirements elicitation.  You might give external product champions economic incentives for their participation.  Consider offering them discounts on products or paying for the time they spend working with you on requirements.

14. Instructore: Tasneem Darwish14 External Product Champions  the product champion is a former or simulated user, watch out for disconnects between the champion's opinion and the current needs of real users.  Some problem domains change rapidly and some are more stable.  The medical field is evolving quickly, whereas many corporate business processes persist in similar form for years.  The essential question is whether the product champion, no matter what his background or current job, can accurately represent the needs of real users

15. Instructore: Tasneem Darwish15 Product Champion Expectations  To help the product champion approach succeed, document what you expect your champions to do.  Table 6-2, identifies some activities that product champions might perform.  Not every champion will do all of these; this table is a starting point to negotiate each champion's responsibilities

16. Instructore: Tasneem Darwish16 Multiple Product Champions  One person can rarely describe the needs for all users of an application.  The Chemical Tracking System had four major user classes, so it needed four product champions.  These champions were not assigned full-time, but each one spent several hours per week working on the project.

17. Instructore: Tasneem Darwish17 Multiple Product Champions  For The Chemical Tracking System, Three analysts worked with the four product champions to elicit, analyze, and document their requirements.  One person cannot supply all the diverse requirements for a large user class such as the hundreds of chemists at Contoso.  To help him, the product champion for the chemist user class assembled a backup team of five other chemists from other parts of the company.  These chemists represented subclasses within the broad "chemist" user class.

18. Instructore: Tasneem Darwish18 Multiple Product Champions  This hierarchical approach engaged additional users in requirements development while avoiding the expense of massive workshops or dozens of individual interviews.  No backup team was necessary when the user class was small enough that one individual could represent the group's needs

19. Instructore: Tasneem Darwish19 Selling the Product Champion Idea  Expect to encounter resistance when you propose the idea of having product champions on your projects.  "The users are too busy." "Management wants to make the decisions." "They'll slow us down." "We can't afford it." "I don't know what I'm supposed to do as a product champion.".  Separating business requirements from user requirements alleviates these discomforts.

20. Instructore: Tasneem Darwish20 Selling the Product Champion Idea  As an actual user, the product champion makes decisions at the user requirements level within the constraints that the project's business requirements impose.  The management sponsor keep the authority to make decisions that affect the product vision, project scope, schedule, and cost.  Documenting and negotiating the product champion's role and responsibilities give candidate champions a comfort level about what they're being asked to do.

21. Instructore: Tasneem Darwish21 Product Champion Traps to Avoid  The product champion model has succeeded in many environments. It works only when:  the product champion understands and signs up for his responsibilities,  has the authority to make decisions at the user requirements level,  and has the time to do the job.  Watch out for the following potential problems 1.Some managers override the decisions that a qualified and authorized product champion makes

22. Instructore: Tasneem Darwish22 Product Champion Traps to Avoid  Watch out for the following potential problems 1.Some managers override the decisions that a qualified and authorized product champion makes 2.A product champion who forgets that he is representing other customers and presents only his own requirements won't do a good job 3.A product champion who lacks a clear mental image of the new system might defer important decisions to the analyst 4.A senior user might nominate a less experienced user as champion because he doesn't have time to do the job himself

23. Instructore: Tasneem Darwish23 Who Makes the Decisions?  Decisions should be made as low in the organization's hierarchy as possible by people who are close to the issues and well informed about them.  Every group should select an appropriate decision rule (an agreed-upon way to arrive at a decision) prior to encountering their first decision

24. Instructore: Tasneem Darwish24 Who Makes the Decisions?  Following are some requirements conflicts that can arise on projects with suggested ways to handle them.  The project leaders need to determine who will decide what to do when such situations arise. 1.If individual users disagree on requirements, the product champions decide. The product champion is empowered and expected to resolve requirements conflicts that arise from those they represent. 2.If different user classes or market segments present incompatible needs, go with the needs of the most favored user class or with the market segment that will have the greatest impact on the product's business success. 3.Different corporate customers all might demand that the product be designed to satisfy their preferences. Again, use the business objectives for the project to determine which customers most strongly influence the project's success or failure. Requirements expressed by user managers sometimes conflict with those from the actual users in their departments. Although the user requirements must align with the business requirements, managers who aren't members of the user class should defer to the product champion who represents their users. When the product that the developers think they should build conflicts with what customers say they want, the customer should normally make the decision.

25. Instructore: Tasneem Darwish25 Who Makes the Decisions? 3.Different corporate customers all might demand that the product be designed to satisfy their preferences. Again, use the business objectives for the project to determine which customers most strongly influence the project's success or failure. 4.Requirements expressed by user managers sometimes conflict with those from the actual users in their departments. Although the user requirements must align with the business requirements, managers who aren't members of the user class should defer to the product champion who represents their users.

26. Instructore: Tasneem Darwish26 Who Makes the Decisions? 5.When the product that the developers think they should build conflicts with what customers say they want, the customer should normally make the decision.