In order to form a more perfect software solution, establish collaboration, insure team tranquility, provide for desired outcomes, promote success, and secure the blessings of excellent requirements management, software customers do ordain to have certain rights – and responsibilities.
To have true software success, requirements management expert Karl Wiegers addresses the customer-development relationship with a Requirements Bill of Rights – and corresponding Bill of Responsibilities – for Software Customers.
Software Customers Requirements Bill of Rights
Right #1: To expect analysts to speak your language. You shouldn’t have to wade through indecipherable computer jargon when talking with a Business Analyst (BA).
Right #2: To have analysts learn about your business and objectives. By interacting with you while eliciting requirements. The BA should be able to understand your business tasks and how the product fits into your world.
Right #3: To expect analysts to write a specification. The soſtware requirements specification (SRS) should be organized and written in a way that you can understand.
Right #4: To receive explanations of requirements work products. Terms like “user-friendly” or “robust” or “efficient” are too vague and subjective to help the developers. Instead, the BA should inquire about specific characteristics that mean user-friendly, robust, or efficient to you.
Right #8: To be given opportunities to adjust requirements for reuse. The BA should give you the option of modifying your requirements if needed so the developers can reuse existing software to save time and money.
Right #9: To receive good-faith estimates of the costs of changes. Developers should present realistic estimates of impacts, costs, and trade-offs. They must not inflate the estimated cost of a change just because they don’t want to implement it.
Right #10: To receive a system that meets your functional needs. Project success depends on you communicating all the information that will let developers build the right product, and on developers clearly communicating options and constraints.
Software Customer Requirements Bill of Responsibilities
Responsibility #1: To educate analysts about your business. The BA depends on you to educate him or her about your business concepts and terminology. The intent is not to transform the BA into a domain expert, but rather to help him or her understand your problems and objectives.
Responsibility #2: To spend the time to provide and clarify. You have a responsibility to invest time in workshops, brainstorming sessions, interviews, and other requirements-elicitation activities. Sometimes the BA might think he or she understands your point, only to realize later that he or she needs further clarification.
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.
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 from multiple customers, choosing between conflicting quality attributes, and evaluating the accuracy of information.
Responsibility #5: To respect a developer’s assessment of cost. 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 more attainable or cheaper.
Responsibility #6: To set requirement priorities. Few developers have the time and resources to implement every desirable bit of functionality. You have a lead role in setting those priorities because developers can’t determine how important every requirement is to every customer.
Responsibility #7: To review requirements documents. Having customers participate in reviews is the only way to evaluate whether the requirements demonstrate the desired characteristics of being complete, correct, and necessary. If you aren’t confident that the documented requirements are accurate, you should notify someone as early as possible and provide suggestions for improvement.
Responsibility #8: To promptly communicate changes. If you need to change the requirements at any time, you should notify the BA. Incremental development approaches make it easier to incorporate changes during development than trying to perfect the requirements early on.
Responsibility #9: To follow the organization’s change process. To minimize the negative impact of change, you should 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.
Responsibility #10: To respect the processes the analysts use. Although you might become frustrated with requirements activities, the time spent developing requirements is an excellent investment. The process will be less painful if you understand and respect the techniques the BA uses for requirements development.
BAs and customers should address these Bills of Rights and Responsibilities so that all parties agree on how they will contribute to a collaborative working relationship. It’s the key to a perfect union.
[cta id=”7443″]