Customer Rights and Responsibilities - Process …

1 Customer Rights and Responsibilities1 Karl E. WiegersProcess success depends on developing a collaborative partnership between softwaredevelopers and their customers. Too often, though, the Customer -developer relationship becomesstrained or even adversarial. Problems arise partly because people don t share a clearunderstanding of what requirements are and who the customers are. To clarify key aspects of thecustomer-developer partnership, I propose a Requirements Bill of Rights for software customersand a corresponding Customer s Requirements Bill of Responsibilities . And, because it simpossible to identify every requirement early in a project, the commonly used and sometimesabused practice of requirements sign-off bears further Is the Customer ?

2 Anyone who derives direct or indirect benefit from a product is a Customer . This includespeople who request, pay for, select, specify, or use a software product, as well as those whoreceive the product s outputs. Customers who initiate or fund a software project supply the high-level product concept and the project s business rationale. These business requirements describethe value that the users, developing organization, or other stakeholders want to receive from thesystem. Business requirements establish a guiding framework for the rest of the project;everything else that s specified as a requirement should help satisfy the business next level of requirements detail comes from the customers who will actually use theproduct.

3 Users can describe both the tasks they need to perform the use cases with theproduct and the product s desired quality attributes. Analysts (individuals who interact withcustomers to gather and document requirements) derive specific software functional requirementsfrom the user , customers often feel they don t have time to participate in requirementselicitation. Sometimes customers expect developers to figure out what the users need without alot of discussion and documentation. Development groups sometimes exclude customers fromrequirements activities, believing that they already know best, will save time, or might lose controlof the project by involving others.

4 It s not enough to use customers just to answer questions or toprovide selected feedback after something is developed. Your organization must accept that thedays of shoving vague requirements and pizzas under the door to the programming departmentare over. Proactive customers will insist on being partners in the commercial software development, the Customer and user are often the same surrogates, such as the marketing department, attempt to determine what the actualcustomers will find appealing. Even for commercial software, though, you should get actual usersinvolved in the requirements-gathering Process , perhaps through focus groups or by building onyour existing beta testing relationships.

5 1 This paper was originally published in Software Development, December 1999. It is reprinted (withmodifications) with permission from Software Development and the Software CustomerPage 2 Copyright 1999 by Karl E. WiegersThe Customer -Development PartnershipQuality software is the product of a well-executed design based on accurate requirements,which are in turn the result of effective communication and collaboration a partnership between developers and customers. Collaborative efforts only work when all parties involvedknow what they need to be successful, and when they understand and respect what theircollaborators need to succeed.

6 As project pressures rise, it s easy to forget that everyone shares acommon objective: to build a successful product that provides business value, user satisfaction,and developer 1 presents a Requirements Bill of Rights for Software Customers, ten expectationsthat customers can place on their interactions with analysts and developers during requirementsengineering. Each of these Rights implies a corresponding software developer s 2 proposes ten Responsibilities the Customer has to the developer during the requirementsprocess. These Rights and Responsibilities apply to actual user representatives for internalcorporate software development. For mass-market product development, they apply more tocustomer surrogates, such as the marketing in the project, Customer and development representatives should review these twolists and reach a meeting of the minds.

7 If you encounter some sticking points, negotiate to reach aclear understanding regarding your Responsibilities to each other. This understanding can reducefriction later, when one party expects something the other isn t willing or able to provide. Theselists aren t all-inclusive, so feel free to change them to meet your specific 1. Requirements Bill of Rights for Software CustomersAs a software Customer , you have the right to:1. Expect analysts to speak your Expect analysts to learn about your business and your objectives for the Expect analysts to structure the requirements information you present into a softwarerequirements Have developers explain requirements work Expect developers to treat you with respect and to maintain a collaborative and Have analysts present ideas and alternatives both for your requirements and Describe characteristics that will make the product easy and enjoyable to Be presented with opportunities to adjust your requirements to permit reuse of existingsoftware Be given good-faith estimates of the costs, impacts.

8 And trade-offs when you request arequirement Receive a system that meets your functional and quality needs, to the extent that those needshave been communicated to the developers and agreed and the Software CustomerPage 3 Copyright 1999 by Karl E. WiegersRequirements Bill of Rights for Software CustomersRight #1: To expect analysts to speak your language. Requirements discussions shouldcenter on your business needs and tasks, using your business vocabulary (which you might have toconvey to the analysts). You shouldn t have to wade through computer #2: To expect analysts to learn about your business. By interacting with userswhile eliciting requirements, the analysts can better understand your business tasks and how theproduct fits into your world.

9 This will help developers design software that truly meets yourneeds. Consider inviting developers or analysts to observe what you do on the job. If the newsystem is replacing an existing application, the developers should use the system as you do to seehow it works, how it fits into your workflow, and where it can be #3: To expect analysts to write a software requirements specification (SRS).The analyst will sort through the Customer -provided information, separating actual user needsfrom other items such as business requirements and rules, functional requirements, quality goals,and solution ideas. The analyst will then write a structured SRS, which constitutes an agreementbetween developers and customers about the proposed product.

10 Review these specifications tomake sure they accurately and completely represent your #4: To have developers explain requirements work products. The analyst mightrepresent the requirements using various diagrams that complement the written SRS. Thesegraphical views of the requirements express certain aspects of system behavior more clearly thanwords can. Although unfamiliar, the diagrams aren t difficult to understand. Analysts shouldexplain the purpose of each diagram, describe the notations used, and demonstrate how toexamine it for #5: To expect developers to treat you with respect. Requirements discussionscan be frustrating if users and developers don t understand each other.