Author: Adriana Beal
Participants who complete Crafting Better Requirements may have very different educational and professional backgrounds, but they all have one thing in common: they leave the course with a unique set of strategies to successfully communicate requirements to the various audiences of their requirements documents.
Let’s look at the improvements a few selected course participants have made. It may be that in reading their stories, you find your most common mistake and can benefit from their feedback as well.
Issue #1: Using “User”
Take Tina*, for example. In her first attempt to capture functional and non-functional requirements for an online web store, she did a great job creating precise requirements, but repeatedly made the mistake of using the generic term “user” to refer to very different types of users of the web store application. All her requirements started with, “The user will be able to…” While for business stakeholders this may not be a problem (since they implicitly know what actors are expected to have access to specific functions in the system), for the development team this could be a source of misunderstandings that might delay the delivery of a usable solution. With the feedback provided during the course, Tina was able to quickly improve the way she was capturing requirements, starting to use specific actors to identify who would be able to perform each function described (“the customer can add products to cart”, “the webstore manager can run daily reports of online orders”, and so on).
Issue #2: Vague Requirements
Bob*, on the other hand, already had the habit of identifying the correct actors, but was used to writing vague requirements that elicited lots of questions from the development team. For example, as part of the requirements for a keyword-based search, he would write, “Search engine should return search results fast to customer.” But what does “fast” mean? The business could be thinking that it means returning results in less than 2 seconds, while the development team is assuming 10 seconds or less (because it would already be a challenge to retrieve the results in this amount of time using the existing IT infrastructure). QA would not have enough information to create test cases in order to ensure this requirement had been fulfilled. Once this weakness was identified, Bob was able to train himself to look at his requirements from the viewpoint of the people who would need to implement and test them (rather than just from the perspective of the stakeholders who will benefit from the solution, and thus know what the expectations are). By always asking, “How would I test if this requirement is correctly implemented?”, he was able to increase the level of detail of his specifications and substantially reduce the number of questions he got from the development team to clarify requirements.
Issue #3: Poor Organization
Jane* was always trying to get her manager and colleagues to look at her requirements to find areas for improvement before she shared her specifications with technical and business stakeholders. However, her manager wasn’t trained in requirements documentation, and the other BAs on her team didn’t have time for more than a cursory look at her documents, so the feedback she’d get was insufficient to surface the problems with her specifications. Only during the final review would the stakeholders give their full attention to her requirements, and ask questions that required Jane to go back and make a series of updates in the documentation before getting the necessary approvals.
During the course, Crafting Better Requirements, Jane finally had a chance to receive in-depth feedback for her requirements statements, and identify the flaws in the way she was documenting them. She learned some useful strategies, such as grouping requirements by functional area and user type to make it easier to spot missing requirements. Using her new set of strategies, she was able to decrease the number of review sessions required to get sign-off for her requirements documents.
* Names have been changed for privacy.
How to Leverage Feedback for Improvement
In these and other success stories collected over the years since the launch of Crafting Better Requirements, the main benefit the participants received from the course is the ability to focus on their own specific weaknesses, rather than follow a predefined curriculum. Based on the identified areas of improvement, some participants will spend most of the time practicing writing requirements statements to make them more concise and less ambiguous, while others may dedicate more cycles to creating diagrams to augment their requirements using visual representation, or learning how to create more effective acceptance criteria for their user stories. Instead of standardized teaching, they are able to experience customized learning based on individual feedback and personalized instruction and assignments which, in the words of a participant, “drastically reduced my learning curve.”
As a result of the customized feedback provided throughout the course, and the opportunity to use deliberate practice to overcome their individual weaknesses, these business analysts not only acquired new valuable skills, but also increased the value they provide to their organizations. The benefits for the companies these BAs work for include shorter requirements cycle time, less back and forth with developers to clarify requirements after sign-off, and fewer change requests submitted during user acceptance testing due to incomplete or incorrect requirements.
