The Customer–Development Partnership, Part 2

Jama Company and Community News

The Customer–Development Partnership, Part 2

By |

The Customer–Development Partnership, Part 2

The first article in this three-part series proposed a Requirements Bill of Rights for Software Customers. In this article, I elaborate on the implications of these rights. In my experience, people who collaborate on project activities rarely take the time up front to discuss the nature of that collaboration. They don’t lay the groundwork for success by exploring just how they can work together effectively toward a common goal. Discussing these rights—or rights like them that better fit your environment—can go a long way toward forging that teamwork. The “you” in each of these rights is the user.

Right #1: To expect analysts to speak your language

Requirements discussions should center on your business needs, tasks, and objectives, using your business vocabulary, which you might have to convey to the business analyst through a glossary. You shouldn’t have to wade through indecipherable computer jargon when talking with a BA.

Right #2: To have analysts learn about your business and objectives

By interacting with users while eliciting requirements, the BAs can better understand your business tasks and how the product fits into your world. This will help developers design a system that satisfies your expectations. Consider inviting developers and BAs to observe what you and your colleagues do on the job. If the system being built is replacing an existing application, the BAs or developers should use the current system as you use it. This will help them see how the current application fits into your work flow and where it can be improved.

Right #3: To expect analysts to write a software requirements specification

The BA will sort through all the information that you and other customers provide to distinguish use cases from business requirements, business rules, functional requirements, quality goals, solution ideas, and other information. The ultimate deliverable from this analysis is a software requirements specification (SRS), which is the detailed agreement between developers and customers on the functions, qualities, and constraints of the product to be built. The SRS might be a single document created early in the project. Alternatively, it might take the form of a series of smaller documents (or other representations) that are created incrementally during the project’s life.

The SRS should be organized and written in a way that you can understand. Your review of these written specifications helps to ensure that they accurately and completely represent your requirements. However, the SRS is not a substitute for ongoing verbal communication among the users, BAs, developers, and other project stakeholders.

Right #4: To receive explanations of requirements work products

The BA might represent the requirements using various diagrams—analysis models—that complement the textual SRS. These alternative views of the requirements are valuable because sometimes graphics are a clearer medium for expressing some aspects of system behavior, such as work flow. Diagrams typically also represent information at a higher level of abstraction than does a detailed specification. This allows you to step back from the trees and get the big picture of the forest as a whole. Although these diagrams might be unfamiliar, the notations used aren’t difficult to understand. Ask the BA to explain the purpose of each diagram and other requirements development work product, what the notations mean, and how to examine the diagrams for errors.

Right #5: To expect analysts and developers to treat you with respect

Requirements discussions can be frustrating if customers and developers don’t understand each other. Working together can open the eyes of both groups to the problems faced by the other. Customers who participate in the requirements development process have the right to expect BAs and developers to treat them with respect and to appreciate the time you’re investing in project success. Similarly, you and your fellow users should demonstrate respect for the development team members as they collaborate with you toward your mutual objective of a successful project.

Right #6: To hear ideas and alternatives for requirements and their implementation

BAs should explore ways that your existing systems don’t fit well with your business processes to make sure the new system doesn’t automate ineffective or obsolete processes. BAs who thoroughly understand the business domain can sometimes suggest improvements in your business processes. A creative BA also adds value by proposing ways that new software could provide capabilities that customers haven’t even envisioned.

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

You can expect BAs to ask you about characteristics of the software that go beyond the user’s functional needs. These characteristics—quality attributes—make the software easier or more pleasant to use, which lets users accomplish their tasks more efficiently. Users sometimes request that the product be “user-friendly” or “robust” or “efficient,” but such terms are too vague and subjective to help the developers. Instead, the BAs should inquire about specific characteristics that mean user-friendly, robust, or efficient to you.

Right #8: To be given opportunities to adjust requirements to permit reuse

Requirements are often flexible. The BA might know of existing software components that come close to addressing some need you described. In such a case, the BA should give you the option of modifying your requirements so the developers can reuse some existing software. Adjusting your requirements when sensible reuse opportunities are available can save time and money. Some requirements flexibility is essential if you want to incorporate commercial off-the-shelf components into your product, as they will rarely have precisely the characteristics you desire.

Right #9: To receive good-faith estimates of the costs of changes

People make different choices in life when they know that one alternative is more expensive than another is. Estimates of the impact and cost of a proposed change in the requirements help stakeholders make good business decisions about which requested changes to approve. You have the right to expect developers to present realistic estimates of impact, cost, and trade-offs. Developers must not inflate the estimated cost of a change just because they don’t want to implement it. Remember, though, that estimates are not precise predictions of the future, but rather our best forecast based on our experience and the information available at any given time.

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

Every stakeholder should share a desire for this project outcome. It can happen only if you clearly communicate all the information that will let developers build the right product and if developers clearly communicate options and constraints. Be sure to state any assumptions or expectations that have not been explicitly discussed. Otherwise, the developers probably can’t address them to your satisfaction.

Also read The Customer-Development Partnership, Part 1

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.

 

Karl Wiegers
Latest posts by Karl Wiegers (see all)