Product Development & Management

The Customer–Development Partnership, Part 3

By |

I conclude this three-part series on the customer–development partnership by elaborating on the Requirements Bill of Responsibilities for Software Customers that I presented in part 1.

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

BAs depend on you to educate them about your business concepts and terminology. The intent is not to transform BAs into domain experts, but to help them understand your problems and objectives. Don’t expect BAs to grasp the nuances and implicit aspects of your business. BAs aren’t likely to be aware of knowledge that you and your peers take for granted. Unstated assumptions about this knowledge can lead to problems later on.

Responsibility #2: To spend the time to provide and clarify requirements

Customers are busy people, and those who are involved in developing requirements are often among the busiest. Nonetheless, you have a responsibility to invest time in workshops, brainstorming sessions, interviews, and other requirements-elicitation activities. Sometimes the BA 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. It is the nature of complex human communication and a key to software success. Be tolerant of what might appear to you to be dumb questions, as a good BA asks questions that get you talking and thinking.

Responsibility #3: To be specific and precise about requirements

It is tempting to leave the requirements vague and fuzzy because pinning down details is tedious and time-consuming. At some point during development, though, someone must resolve the ambiguities and imprecisions. You are the best person to make those decisions. Otherwise, you’re relying on the developers to guess correctly.

It’s fine to temporarily include TBD (to be determined) markers in the SRS to indicate that additional research, analysis, or information is needed. Sometimes, though, people use TBD because a specific requirement is difficult to resolve and no one wants to tackle it head-on. Try to clarify the intent of each requirement so the BA can express it accurately in the SRS.

Responsibility #4: To make timely decisions

Just as when a contractor builds a custom home, the BA will ask you to make many choices and decisions. These decisions include resolving inconsistent requests received from multiple customers, choosing between conflicting quality attributes, and evaluating the accuracy of information. Customers who are authorized to make such decisions must do so promptly when asked. The developers often can’t proceed with confidence until you render your decision, so time spent waiting for an answer can delay progress.

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

All software functions have a cost, and developers are in the best position to estimate those costs (although not all developers are skilled estimators). Some features that you want included might not be technically feasible or might be surprisingly expensive to implement. I learned long ago that there is little correlation between how difficult it seems like something ought to be to do in software and how hard it really is to implement. Certain requirements might demand unattainable performance in the operating environment, or they might require access to data that is simply not available to the system. 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 attainable or cheaper. For example, asking for an action to take place “instantaneously” isn’t feasible, but “within 50 milliseconds” might be achievable.

Responsibility #6: To set requirement priorities

Few projects have the time and resources to implement every desirable bit of functionality. Determining which capabilities are essential, which are useful, and which ones the customers can live without is an important part of requirements development. You have a lead role in setting those priorities, because developers can’t determine how important every requirement is to the customers. Developers should provide information about the cost and technical risk of each requirement to help determine final priorities. When you establish priorities, you help ensure that developers deliver the maximum value at the lowest cost and at the right time.

No one likes to hear that something he wants can’t be completed within the project bounds, but that’s just a reality. The project’s decision-makers will have to elect whether to reduce project scope based on priorities or to extend the schedule, provide additional funds or people, or compromise on quality.

Responsibility #7: To review requirements documents and evaluate prototypes

Peer reviews of requirements are among the most valuable software quality activities. Having customers participate in reviews is the only way to evaluate whether the requirements demonstrate the desired characteristics of being complete, correct, necessary, and so on. A review is also an opportunity for customer representatives to give the BAs feedback about how well their work is meeting the project’s needs. If you aren’t confident that the documented requirements are accurate, tell the people responsible as early as possible and provide suggestions for improvement.

Responsibility #8: To promptly communicate changes to the requirements

Continually changing requirements pose a serious risk to the development team’s ability to deliver a high-quality product on schedule. Change is inevitable and often beneficial, but the later in the development cycle a change is introduced, the greater its impact. Changes can cause expensive rework and schedules can slip if new functionality is demanded after construction is well under way. Notify the BA with whom you are working as soon as you become aware that you need to change the requirements. Incremental development approaches make it easier to incorporate changes during development than trying to perfect the requirements and cast them in concrete early on.

Responsibility #9: To follow the development organization’s change process

To minimize the negative impact of change, follow the project’s defined change control process. This ensures that requested changes are not lost, the impact of each requested change is analyzed, and all proposed changes are considered in a consistent way. As a result, the business stakeholders can make sound business decisions to incorporate certain changes at the right time.

Responsibility #10: To respect the requirements engineering processes the analysts use

Gathering and validating requirements are among the greatest challenges in software development. There is a rationale behind the approaches that the BAs use. Although you might become frustrated with the requirements activities, the time spent developing the requirements is an excellent investment. The process will be less painful if you understand and respect the techniques the BAs use for requirements development. Feel free to ask BAs to explain why they are requesting certain information or asking you to participate in some requirements-related activity.

To apply the ideas I’ve presented in this series of articles, I suggest that BAs and key customers discuss the Bill of Rights to learn whether the customers feel they are not receiving any of their rights. Discuss the Bill of Responsibilities to reach agreement as to which responsibilities the customers will accept. Modify the Bill of Rights and Bill of Responsibilities as appropriate so that all parties agree on how they will contribute to a collaborative working relationship. You’ll be glad you did.

Also read The Customer-Development Partnership, Part 1

Also read The Customer-Development Partnership, Part 2

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars.  Karl Wiegers is an independent consultant and not an employee of Jama.  He can be reached at http://www.processimpact.com.  Enjoy these free requirements management resources.

 

Latest posts by Karl Wiegers (see all)