Forging a Collaborative Customer–Development Partnership

Excellent software products are based on excellent requirements. Excellent requirements result from effective collaboration between developers and customers, and in particular, actual users: a partnership. A collaborative effort can work only when all parties involved understand what both they and their collaborators need to be successful. The business analyst (BA) typically is the point person who has to forge this collaborative partnership.

The Requirements Bill of Rights for Software Customers in Figure 1 lists ten expectations that customers can hold regarding their interactions with the BA and development team regarding the project’s requirements activities. The word “you” in the rights and responsibilities refers to a customer for a software development project.

Because the flip side of a right is a responsibility, Figure 2 lists ten responsibilities that the customer has to BAs and developers during the requirements process. You could also view these as a developer’s bill of rights.

?During project startup, the customer and development participants should review these two lists and negotiate to reach a meeting of the minds. If these lists aren’t exactly right for your organization, modify them to suit your culture. Make sure the key participants in requirements development understand and accept their responsibilities. This understanding can reduce friction later when one party expects something that the other is not willing or able to provide.

Requirements Bill of Rights for Software Customers

Following are ten rights that customers can expect when it comes to requirements issues.

Right #1: To expect BAs to speak your language

Requirements discussions should center on your business needs and tasks, using business vocabulary. A glossary is an effective way to convey business terminology to other team members.

Right #2: To expect BAs to learn about your business and your objectives

By interacting with you to elicit requirements, the BAs can better understand your business tasks and how the system fits into your world. This will help developers create a solution that meets your needs. Inviting BAs and developers to observe how you work will show them how the solution fits into and improves your workflow.

Right #3: To expect BAs to record requirements in appropriate forms

The BA will sort through the information stakeholders provide and ask follow-up questions to distinguish user requirements from business rules, functionality, quality goals, and other items. The deliverable from this analysis is a set of requirements stored in appropriate forms, such as a software requirements specification document or a requirements management tool, and various diagrams. These requirements constitute the agreement about the solution’s functions, qualities, and constraints. Requirements should be written and organized in a way that you find easy to understand.

Right #4: To receive explanations of requirements practices and deliverables

A BA employs various practices to make requirements development effective and efficient and to represent requirements knowledge. The BA should explain their recommended practices and explain what information goes into each deliverable. If the BA creates some unfamiliar diagrams to complement textual requirements, they should explain the purpose of each diagram, what the symbols mean, and how to examine the diagram for errors.

Right #5: To change your requirements

You have the right to make changes in the requirements as the business evolves, stakeholders provide more input, or you think more carefully about what you need. However, change always has a price. Sometimes adding a new function demands trade-offs with other functions or with the development schedule. An important part of the BA’s responsibility is to assess and communicate change impacts. The participants should agree on a simple but effective process for handling changes.

Right #6: To expect an environment of mutual respect

Requirements discussions can sometimes become frustrating, or even adversarial. Customers who participate in requirements development have the right to expect BAs and developers to treat them with respect and to appreciate the time they are investing in the project’s success. Similarly, customers should demonstrate respect for the development team as everyone collaborates toward their mutual objective of a successful project.

Right #7: To hear ideas and alternatives for your requirements and their solution

Let the BA know about ways that your existing systems don’t fit well with your business processes to make sure a new solution doesn’t simply automate ineffective or obsolete processes. That is, avoid “repaving the cow paths.” A BA can often suggest improvements in business processes and new solution capabilities that customers haven’t envisioned.

Right #8: To describe characteristics that will make the product easy to use

BAs will ask about characteristics of the software that go beyond its functionality: its quality attributes. These attributes make the software easier, more efficient, or more enjoyable to use. For instance, users sometimes ask that the solution be user-friendly or robust. Those terms are too subjective to help the developers. Instead, the BA should explore the specific characteristics that mean user-friendly or robust to you.

Right #9: To hear about ways to adjust requirements to accelerate development through reuse

If the BA knows of existing software components or requirements that come close to addressing some need you presented, they might suggest ways to modify your requirements so developers can reuse those assets. Adjusting your requirements when sensible reuse opportunities are available saves time and money.

Right #10: To receive a system that meets your functional needs and quality expectations

This is the ultimate customer right. However, it can happen only if customer representatives clearly communicate all the information that will let developers build the right solution, if developers communicate options and constraints to you, and if the stakeholders reach an agreement. Customers sometimes don’t articulate points that they believe are common knowledge. However, validating a shared understanding across the project team is just as important as expressing something new.

Requirements Bill of Responsibilities for Software Customers

The counterpart to a right is a responsibility. Here are ten responsibilities that customer representatives have when it comes to defining and managing the requirements for their projects.

Responsibility #1: To educate BAs and developers about your business

The development team depends on you to educate them about your business activities and jargon. BAs might not be aware of knowledge that you take for granted. Unstated assumptions about such knowledge can lead to problems later.

Responsibility #2: To dedicate the time that it takes to provide and clarify requirements

Like everyone, customers are busy people. Nonetheless, you need to dedicate time to workshops, interviews, and other requirements elicitation and validation activities. Please be patient with the iterative and incremental approach to developing and refining the requirements. It’s the nature of complex human communication and a key to success.

Responsibility #3: To be specific and precise when providing input about requirements

It’s tempting to leave the requirements vague and fuzzy because pinning down details is tedious and time-consuming. At some point, though, someone must resolve the ambiguities and imprecisions. You’re the best person to make those decisions. Otherwise, you’re relying on the BA or developers to guess correctly. Clarify the intent of each requirement so that the BA can express it accurately and define a good solution.

Responsibility #4: To make timely decisions about requirements when asked

The BA will ask you to make many requirements decisions: resolving conflicting requests from multiple customers, choosing between incompatible quality attributes, setting priorities, and more. Customers who are empowered to make such decisions must do so promptly when asked. Developers can’t proceed with confidence until someone makes those decisions.

Responsibility #5: To respect a developer’s assessment of the cost and feasibility of requirements

All software functions have a cost. Some features might not be technically feasible or would be prohibitively expensive. The developer can be the bearer of bad news about feasibility or cost. You should respect that judgment, even if it means you might not get something you asked for in exactly the form you envisioned.

Responsibility #6: To set realistic requirement priorities in collaboration with developers

Customers must work with the BA to set requirement priorities, which helps the team deliver the maximum value at the lowest cost and at the right time. Respect the development team’s judgment as to how much of the requested functionality they can fit into each development cycle. Simply making every requirement high priority is neither realistic nor collaborative.

Responsibility #7: To review requirements and evaluate prototypes

Having customers participate in reviews is the only way to confirm that the requirements are complete, correct, and necessary. The BA should make requirements available for review in manageable chunks throughout requirements elicitation and during development cycles.

To better understand your needs and explore the best ways to satisfy them, software teams sometimes build prototypes of the intended product. Your feedback on these preliminary, partial, or exploratory implementations provides valuable information to the developers.

Responsibility #8: To establish acceptance criteria

One customer responsibility is to define acceptance criteria conditions the product must satisfy to be judged acceptable. Such criteria include acceptance tests, which assess whether the solution lets users perform certain operations correctly. Agile projects rely heavily on acceptance tests, rather than written requirements, to flesh out the details of user stories.

Responsibility #9: To promptly communicate changes to the requirements

Change is inevitable and often valuable, but the later in a development cycle that a change is introduced, the greater its impact. Notify the BA as soon as you learn that you need to change a requirement. To minimize the negative impact of changes, follow the project’s defined change control process. This ensures that the right stakeholders can make informed business decisions to incorporate appropriate changes at the right time.

Responsibility #10: To respect the requirements development process

Eliciting and specifying requirements are big challenges. There’s a rationale behind the BA’s approach to requirements development. Feel free to ask BAs to explain why they’re requesting certain information or asking you to participate in a particular requirements-related activity.

A mutual understanding of, and respect for, each other’s approaches and needs goes a long way toward establishing an effective collaboration. Agreeing on each party’s rights and responsibilities to each other lays the foundation for a successful engagement.

==============

Karl Wiegers is the Principal Consultant at Process Impact. He’s the author of numerous books, including Software Requirements (co-authored with Joy Beatty and from which this article is adapted), More About Software Requirements, Software Development Pearls , and The Thoughtless Design of Everyday Things . Karl’s most recent book is Software Requirements Essentials with Candase Hokanson.