Jama Company and Community News

The Customer–Development Partnership, Part 1

By |

Customers who request a new or modified information system often do not understand the importance of obtaining input from actual users of the proposed system, in addition to other internal and external stakeholders. Marketing specialists with a great product concept sometimes believe that they can adequately represent the interests of prospective buyers. However, there’s no substitute for gathering requirements directly from the people who will actually use the product.

This article, the first in a three-part series adapted from my book Software Requirements, 2nd Edition, addresses the customer-development relationship that is so critical to software project success. I propose a Requirements Bill of Rights for Software Customers and a corresponding Requirements Bill of Responsibilities for Software Customers. These lists underscore the importance of customer—and specifically user—involvement in requirements development.

Who Is the Customer?

A stakeholder is anyone who works on, is affected by, or can influence the outcome of a project. A customer is an individual or organization who derives either direct or indirect benefit from a product. Software customers include those stakeholders who request, pay for, select, specify, use, or receive the output generated by a software product. Other project stakeholders include business analysts, developers, testers, documentation writers, project managers, support staff, certifying bodies, legal staff, and marketing.

Customers at the senior management or funding sponsor level are responsible for specifying the business requirements. They provide the high-level concept for the product and the business rationale for launching the project. Business requirements describe the business objectives that the customer, company, or other stakeholders want to achieve. Business requirements establish a guiding framework for the rest of the project, and all other product features and requirements should align with satisfying them. However, business requirements do not provide sufficient detail to tell developers what to build.

The next level of requirements—user requirements—should come from people who will actually use the product, either hands-on or indirectly. These users therefore constitute another class of customer. Users can describe the tasks they need to perform with the product and the quality characteristics they expect the product to exhibit.

Customers who provide the business requirements sometimes purport to speak for the users, but usually they are too far removed from the actual user work to provide accurate user requirements. For information systems, contract, or custom application development, business requirements should come from the person with the money, while user requirements should come from the person who will press the keys and move the mouse. The various stakeholders must ensure alignment between the user and business requirements.

Unfortunately, both kinds of customers might not believe that they have the time to work with the requirements analysts who gather, analyze, and document the requirements. Sometimes customers expect the analysts or developers to figure out what users need without a lot of discussion. If only it were that easy. The days of sliding some vague requirements and a series of pizzas under the door to the programming department are long past.

The situation is somewhat different for commercial (shrink-wrap) software development, where the customer and user often are the same person. Customer surrogates, such as the marketing department or product management, might attempt to determine what customers would find appealing. Even for commercial software, though, you should engage end users in the process of developing user requirements, perhaps through focus groups or other engagement techniques. If you do not, be prepared to read magazine reviews that describe shortcomings in your product that adequate user input could have helped you avoid.

Structuring the Partnership

Excellent software products are the result of a well-executed design based on excellent requirements. High-quality requirements result from effective communication and collaboration between developers and customers—a partnership. Too often, the relationship between development and customers becomes adversarial. Managers who override user-supplied requirements to suit their own agenda can also generate friction. No one benefits in these situations.

A collaborative effort can work only when all parties involved know what they need to be successful and when they understand and respect what their collaborators need to be successful. As project pressures rise, it’s easy to forget that all stakeholders share a common objective: to build a successful software product that provides adequate business value and rewards to all stakeholders.

The Requirements Bill of Rights for Software Customers lists ten expectations that customers can legitimately hold regarding their interactions with analysts and developers during the project’s requirements engineering activities. Each of these rights implies a corresponding responsibility on the part of the software developers or analysts. Conversely, the Requirements Bill of Responsibilities for Software Customers lists ten responsibilities that the customer has to the developer during the requirements process. If you prefer, you could phrase these as a developer’s bill of rights.

These rights and responsibilities apply directly to customers when the software is being developed for internal corporate use, under contract, or for a known set of major customers. For mass-market product development, the rights and responsibilities are more applicable to customer surrogates, such as the developing organization’s marketing product management staff.

As part of project planning, the customer and development participants should review these two lists and reach a meeting of the minds. Busy customers might prefer not to become involved in requirements engineering (that is, they shy away from Responsibility #2). However, we know that lack of customer involvement greatly increases the risk of building the wrong product. Make sure the key participants in requirements development understand and accept their responsibilities. 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 that the other is not willing or able to provide.

Part 2 of this series takes a closer look at the ten customer rights when it comes to software requirements, while Part 3 explores the ten customer responsibilities. If these two lists aren’t quite right for your environment, adapt them to be more relevant. Don’t just assume that these various key project stakeholders already know how to collaborate effectively, though.

Requirements Bill of Rights for Software Customers

You have the right to:

  1. Expect analysts to speak your language.
  2. Expect analysts to learn about your business and your objectives for the system.
  3. Expect analysts to structure the information you present during requirements elicitation into a written software requirements specification.
  4. Have analysts explain all work products created from the requirements process.
  5. Expect analysts and developers to treat you with respect and to maintain a collaborative and professional attitude throughout your interactions.
  6. Have analysts and developers provide you with ideas and alternatives both for your requirements and for implementation of the product.
  7. Describe characteristics of the product that will make it easy and enjoyable to use.
  8. Be given opportunities to adjust your requirements to permit reuse of existing software components.
  9. Receive good-faith estimates of the costs, impacts, and trade-offs when you request a change in the requirements.
  10. Receive a system that meets your functional and quality needs, to the extent that those needs have been communicated to the developers and agreed on.

Requirements Bill of Responsibilities for Software Customers

You have the responsibility to:

  1. Educate analysts and developers about your business and define business jargon.
  2. Spend the time that it takes to provide requirements, clarify them, and iteratively flesh them out.
  3. Be specific and precise when providing input about the system’s requirements.
  4. Make timely decisions about requirements when requested to do so.
  5. Respect a developer’s assessment of the cost and feasibility of requirements.
  6. In collaboration with the developers, set priorities for functional requirements, system features, or use cases.
  7. Review requirements documents and evaluate prototypes.
  8. Communicate changes to the requirements as soon as you know about them.
  9. Follow the development organization’s process for requesting requirements changes.
  10. Respect the processes the analysts use for requirements engineering.

Also read The Customer-Development Partnership, Part 2

Also read The Customer-Development Partnership, Part 3

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)