I conclude this three-part series on the customer\u2013development partnership by elaborating on the Requirements Bill of Responsibilities for Software Customers that I presented in part 1.<\/p>\n
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\u2019t expect BAs to grasp the nuances and implicit aspects of your business. BAs aren\u2019t 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.<\/p>\n
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.<\/p>\n
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\u2019re relying on the developers to guess correctly.<\/p>\n
It\u2019s 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.<\/p>\n
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\u2019t proceed with confidence until you render your decision, so time spent waiting for an answer can delay progress.<\/p>\n
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.<\/p>\n
Sometimes you can rewrite requirements in a way that makes them attainable or cheaper. For example, asking for an action to take place \u201cinstantaneously\u201d isn\u2019t feasible, but \u201cwithin 50 milliseconds\u201d might be achievable.<\/p>\n
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\u2019t 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.<\/p>\n
No one likes to hear that something he wants can\u2019t be completed within the project bounds, but that\u2019s just a reality. The project\u2019s 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.<\/p>\n
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\u2019s needs. If you aren\u2019t confident that the documented requirements are accurate, tell the people responsible as early as possible and provide suggestions for improvement.<\/p>\n
Continually changing requirements pose a serious risk to the development team\u2019s 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.<\/p>\n
To minimize the negative impact of change, follow the project\u2019s 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.<\/p>\n
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.<\/p>\n
To apply the ideas I\u2019ve 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\u2019ll be glad you did.<\/p>\n
Also read\u00a0The Customer-Development Partnership, Part 1<\/a><\/p>\n Also read\u00a0The Customer-Development Partnership, Part 2<\/a><\/p>\n 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.\u00a0 Karl Wiegers is an independent consultant and not an employee of Jama. \u00a0He can be reached at\u00a0<\/i>http:\/\/www.processimpact.com<\/a><\/i>.\u00a0 Enjoy these free\u00a0<\/i>requirements management resources<\/a><\/i>.<\/i><\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" I conclude this three-part series on the customer\u2013development 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 […]<\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[72],"tags":[51],"industry":[],"class_list":["post-3447","post","type-post","status-publish","format-standard","hentry","category-product-development-and-management","tag-business-requirements"],"acf":[],"yoast_head":"\n