Customer Rights and Responsibilities
Karl E. Wiegers
Software success depends on developing a collaborative partnership between software developers and their customers. Too often, though, the customer-developer relationship becomes strained or even adversarial. Problems arise partly because people donít share a clear understanding of what requirements are and who the customers are. To clarify key aspects of the customer-developer partnership, I propose a Requirements Bill of Rights for software customers and a corresponding customerís Requirements Bill of Responsibilities. And, because itís impossible to identify every requirement early in a project, the commonly usedóand sometimes abusedópractice of requirements sign-off bears further examination.
Who Is the Customer?
Anyone who derives direct or indirect benefit from a product is a customer. This includes people who request, pay for, select, specify, or use a software product, as well as those who receive 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 describe the value that the users, developing organization, or other stakeholders want to receive from the system. 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 requirements.
The next level of requirements detail comes from the customers who will actually use the product. Users can describe both the tasks they need to performóthe use casesówith the product and the productís desired quality attributes. Analysts (individuals who interact with customers to gather and document requirements) derive specific software functional requirements from the user requirements.
Unfortunately, customers often feel they donít have time to participate in requirements elicitation. Sometimes customers expect developers to figure out what the users need without a lot of discussion and documentation. Development groups sometimes exclude customers from requirements activities, believing that they already know best, will save time, or might lose control of the project by involving others. Itís not enough to use customers just to answer questions or to provide selected feedback after something is developed. Your organization must accept that the days of shoving vague requirements and pizzas under the door to the programming department are over. Proactive customers will insist on being partners in the venture.
For commercial software development, the customer and user are often the same person. Customer surrogates, such as the marketing department, attempt to determine what the actual customers will find appealing. Even for commercial software, though, you should get actual users involved in the requirements-gathering process, perhaps through focus groups or by building on your existing beta testing relationships.
The Customer-Development Partnership
Quality 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 involved know what they need to be successful, and when they understand and respect what their collaborators need to succeed. As project pressures rise, itís easy to forget that everyone shares a common objective: to build a successful product that provides business value, user satisfaction, and developer fulfillment.
Figure 1 presents a Requirements Bill of Rights for Software Customers, ten expectations that customers can place on their interactions with analysts and developers during requirements engineering. Each of these rights implies a corresponding software developerís responsibility. Figure 2 proposes ten responsibilities the customer has to the developer during the requirements process. These rights and responsibilities apply to actual user representatives for internal corporate software development. For mass-market product development, they apply more to customer surrogates, such as the marketing department.
Early in the project, customer and development representatives should review these two lists and reach a meeting of the minds. If you encounter some sticking points, negotiate to reach a clear understanding regarding your responsibilities to each other. This understanding can reduce friction later, when one party expects something the other isnít willing or able to provide. These lists arenít all-inclusive, so feel free to change them to meet your specific needs.
Figure 1. Requirements Bill of Rights for Software Customers
As a software customer, you have the right to:
Right #1: To expect analysts to speak your language. Requirements discussions should center on your business needs and tasks, using your business vocabulary (which you might have to convey to the analysts). You shouldnít have to wade through computer jargon.
Right #2: To expect analysts to learn about your business. By interacting with users while eliciting requirements, the analysts can better understand your business tasks and how the product fits into your world. This will help developers design software that truly meets your needs. Consider inviting developers or analysts to observe what you do on the job. If the new system is replacing an existing application, the developers should use the system as you do to see how it works, how it fits into your workflow, and where it can be improved.
Right #3: To expect analysts to write a software requirements specification (SRS). The analyst will sort through the customer-provided information, separating actual user needs from 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 agreement between developers and customers about the proposed product. Review these specifications to make sure they accurately and completely represent your requirements.
Right #4: To have developers explain requirements work products. The analyst might represent the requirements using various diagrams that complement the written SRS. These graphical views of the requirements express certain aspects of system behavior more clearly than words can. Although unfamiliar, the diagrams arenít difficult to understand. Analysts should explain the purpose of each diagram, describe the notations used, and demonstrate how to examine it for errors.
Right #5: To expect developers to treat you with respect. Requirements discussions can be frustrating if users and developers donít understand each other. Working together can open each groupís eyes to the problems the other faces. Customers who participate in requirements development have the right to have developers treat them with respect and to appreciate the time they are investing in project success. Similarly, demonstrate respect for the developers as they work with you toward your common objective of a successful project.
Right #6: To have analysts present ideas and alternatives for requirements and implementation. Analysts should explore ways your existing systems donít fit well with your current business processes, to make sure the new product doesnít automate ineffective or inefficient processes. Analysts who thoroughly understand the application domain can sometimes suggest improvements in your business processes. An experienced and creative analyst also adds value by proposing valuable capabilities the new software could provide that the users havenít even envisioned.
Right #7: To describe characteristics that will make the product easy and enjoyable to use. The analyst should ask you about characteristics of the software that go beyond your functional needs. These "quality attributes" make the software easier or more pleasant to use, letting you accomplish your tasks accurately and efficiently. For example, customers sometimes state that the product must be "user-friendly" or "robust" or "efficient," but these terms are both subjective and vague. The analyst should explore and document the specific characteristics that signify "user-friendly," "robust," or "efficient" to the users.
Right #8: To be presented with opportunities to adjust your requirements to permit reuse. The analyst might know of existing software components that come close to addressing some need you described. In such a case, the analyst should give you a chance to modify your requirements to allow the developers to reuse existing software. Adjusting your requirements when sensible reuse opportunities are available can save time that would otherwise be needed to build precisely what the original requirements specified.
Right #9: To be given good-faith estimates of the costs of changes. People sometimes make different choices when they know one alternative is more expensive than another. Estimates of the impact and cost of a proposed requirement change are necessary to make good business decisions about which requested changes to approve. Developers should present their best estimates of impact, cost, and trade-offs, which wonít always be what you want to hear. Developers must not inflate the estimated cost of a proposed change just because they donít want to implement it.
Right #10: To receive a system that meets your functional and quality needs. This desired project outcome is achievable only if you clearly communicate all the information that will let developers build the product that satisfies your needs, and if developers communicate options and constraints. State any assumptions or implicit expectations you might hold; otherwise, the developers probably canít address them to your satisfaction.
Figure 2. Requirements Bill of Responsibilities for Software Customers
As a software customer, you have the responsibility to:
Requirements Bill of Responsibilities for Software Customers
Responsibility #1: To educate analysts about your business. Analysts depend on you to educate them about your business concepts and terminology. The intent is not to transform analysts into domain experts, but to help them understand your problems and objectives. Donít expect analysts to have knowledge you and your peers take for granted.
Responsibility #2: To spend the time to provide and clarify requirements. You have a responsibility to invest time in workshops, interviews, and other requirements elicitation activities. Sometimes the analyst might think she understands a point you made, only to realize later that she needs further clarification. Please be patient with this iterative approach to developing and refining the requirements, as it is the nature of complex human communication and essential to software success.
Responsibility #3: To be specific and precise about requirements. Writing clear, precise requirements is hard. Itís tempting to leave the requirements vague because pinning down details is tedious and time-consuming. At some point during development, though, someone must resolve the ambiguities and imprecisions. You are most likely the best person to make those decisions; otherwise, youíre relying on the developers to guess correctly. Do your best to clarify the intent of each requirement, so the analyst can express it accurately in the SRS. If you canít be precise, agree to a process to generate the necessary precision, perhaps through some type of prototyping.
Responsibility #4: To make timely decisions. The analyst will ask you to make many choices and decisions. These decisions include resolving inconsistent requests received from multiple users and making trade-offs between conflicting quality attributes. Customers who are authorized to make such decisions must do so promptly when asked. The developers often canít proceed until you render your decision, so time spent waiting for an answer can delay progress. If customer decisions arenít forthcoming, the developers might make the decisions for you and charge ahead, which often wonít lead to the outcome you prefer.
Responsibility #5: To respect a developerís assessment of cost and feasibility. All software functions have a price and developers are in the best position to estimate those costs. Some features you would like might not be technically feasible or might be surprisingly expensive to implement. The developer can be the bearer of bad news about feasibility or cost, and you should respect that judgment. Sometimes you can rewrite requirements in a way that makes them feasible or cheaper. For example, asking for an action to take place "instantaneously" isnít feasible, but a more specific timing requirement ("within 50 milliseconds") might be achievable.
Responsibility #6: To set requirement priorities. Most projects donít have the time or resources to implement every desirable bit of functionality, so you must determine which features are essential, which are important to incorporate eventually, and which would just be nice extras. Developers usually canít determine priorities from your perspective, but they should estimate the cost and technical risk of each feature, use case, or requirement to help you make the decision.
When you prioritize, you help the developers deliver the greatest value at the lowest cost. No one likes to hear that something he or she wants canít be completed within the project bounds, but thatís just a reality. A business decision must then be made to reduce project scope based on priorities or to extend the schedule, provide additional resources, or compromise on quality.
Responsibility #7: To review requirements documents and prototypes. Having customers participate in formal and informal reviews is a valuable quality control activityóindeed, itís the only way to evaluate whether the requirements are complete, correct, and necessary.
Itís difficult to envision how the software will actually work by reading a specification. To better understand your needs and explore the best ways to satisfy them, developers often build prototypes. Your feedback on these preliminary, partial, or possible implementations helps ensure that everyone understands the requirements. Recognize, however, that a prototype is not a final product; allow developers to build fully functioning systems based on the prototype.
Responsibility #8: To promptly communicate changes to the productís requirements. Continually changing requirements pose a serious risk to the development teamís ability to deliver a high-quality product within the planned schedule. Change is inevitable, but the later in the development cycle a change is introduced, the greater its impact. Extensive requirements changes often indicate that the original requirements elicitation process wasnít adequate.
Changes can cause expensive rework and schedules can slip if new functionality is demanded after construction is well underway. Notify the analyst with whom youíre working as soon as you become aware of any change needed in the requirements. Key customers should also participate in the process of deciding whether to approve or reject change requests.
Responsibility #9: To follow the development organizationís requirements change process. To minimize the negative impact of change, all participants must follow the projectís change control process. This ensures that requested changes are not lost, the impact of each requested change is evaluated, and all proposed changes are considered in a consistent way. As a result, you can make good business decisions to incorporate certain changes into the product.
Responsibility #10: To respect the requirements engineering processes the developers use. Gathering requirements and verifying their accuracy are among the greatest challenges in software development. Although you might become frustrated with the process, itís an excellent investment that will be less painful if you understand and respect the techniques analysts use for gathering, documenting, and assuring the quality of the software requirements. Customers should be educated about the requirements process, ideally attending classes together with developers. Iíve often presented seminars to audiences that included developers, users, managers, and requirements specialists. People can collaborate more effectively when they learn together.
What About Sign-Off?
Agreeing on a new productís requirements is a critical part of the customer-developer partnership. Many organizations use the act of signing off on the requirements document to indicate customer approval. All participants in the requirements approval process need to know exactly what sign-off means.
One potential problem is the customer representative who regards signing off on the requirements as a meaningless ritual: "I was given a piece of paper that had my name printed beneath a line, so I signed on the line because otherwise the developers wouldnít start coding." This attitude can lead to future conflicts when that customer wants to change the requirements or when heís surprised by what is delivered: "Sure, I signed off on the requirements, but I didnít have time to read them all. I trusted you guysóyou let me down!"
Equally problematic is the development manager who views sign-off as a way to freeze the requirements. Whenever a change request is presented, he can point to the SRS and protest, "You signed off on these requirements, so thatís what weíre building. If you wanted something else, you should have said so."
Both of these attitudes fail to acknowledge the reality that itís impossible to know all the requirements early in the project and that requirements will undoubtedly change over time. Requirements sign-off is an appropriate action that brings closure to the requirements development process. However, the participants have to agree on precisely what theyíre saying with their signatures.
More important than the sign-off ritual is the concept of establishing a "baseline" of the requirements agreementóa snapshot at some point in time. The subtext of a signature on an SRS sign-off page should therefore read something like: "I agree that this document represents our best understanding of the requirements for the project today. Future changes to this baseline can be made through the projectís defined change process. I realize that approved changes might require us to renegotiate the projectís costs, resources, and schedule commitments."
A shared understanding of the requirements approval process should alleviate the friction that can arise as the project progresses and requirements oversights are revealed, or as marketplace and business demands evolve. Sealing the initial requirements development activities with such an explicit agreement helps you forge a continuing customer-developer partnership on the way to project success.
[This paper was originally published in Software Development, December 1999. It is reprinted (with modifications) with permission from Software Development magazine.]