This is Part 3 of the Requirement Gathering Blog series by Rahul Parwal where we explore more on Exploring Requirements. We’d like to thank him for sharing his expertise with the community through this information-packed piece. Check out the blog on Requirements in The Agile World for Part 2 of this series.
Here is a list of all the blogs in this series:
- Part 1: Understanding Requirements
- Part 2: Requirements in The Agile World
- Part 3: Exploring requirements
- Part 4: Testing Requirements
- Part 5: Dealing with Objections
What are some of the techniques I can learn to elicit requirements?
When eliciting requirements, here are some techniques to help you get better at it:
1. Ensure that all necessary stakeholders are involved: This helps to question assumptions, gain new perspectives, and overcome biases. Furthermore, explaining the requirements to new members can also help clarify thoughts and eliminate misunderstandings.
2. Identify & be aware of biases: One must be aware of potential biases, such as the “first love” syndrome, where a particular solution may be favored without considering other alternatives. It is also important to avoid the “I know it all” mode and pay attention to missing gaps, ambiguous words, and newly introduced elements.
3. Product Modelling: To help clarify requirements, it can be helpful to model the product through techniques such as mind mapping, sketching, or drawing and passing. It is important to take the time at the beginning to carefully consider the requirements and try to understand the perspective of different users and customers.
4. Consider user personas: Understanding the perspectives of different user personas can also help reduce ambiguity.
5. Consider alternate ways of information: There are various methods that can be used to gather information, such as context-free questions, user/client interviews, surveys, feedback from the marketing or sales team, or studying similar products.
In conclusion, eliciting requirements is a crucial part of any project and requires a comprehensive approach to ensure success. By involving all necessary stakeholders, paying attention to potential biases and ambiguities, and using a variety of methods to gather information, you can increase your chances of obtaining the requirements that are actually needed.
How can I learn the product in the absence of requirements?
In the absence of requirements, there are several ways to learn the product. Professional testers often use these methods a lot and use them to actively seek out for more information instead of just waiting for the written requirement document.
1. User Feedback: Gather feedback from actual users of the product, this will give a real-world perspective on how the product is used and what features and functionality are important to them. This could come from social media, customer support records, sales team, etc.
2. Customer Interviews: Conduct in-depth customer interviews to understand the target market, their needs and pain points, and how the product addresses them. This is also the primary way how the product team captures and stores as the stated requirements which are then given to engineering teams.
3. Analyze Competitors: Study the competitors and their products to understand the market trends and what features and functionality are currently available in the market.
4. Conduct User Research: Conduct user research by observing users as they interact with the product. This will give insights into how they use the product and what their expectations are.
5. Play with the Product: Get hands-on with the product, use it, and explore it as a user would. This will help understand the features, functionalities, and user experience.
6. Talk to Stakeholders: Talk to stakeholders such as product owners, developers, and designers to get an understanding of their vision for the product and what they are trying to achieve with it.
7. FEW HICCUPPS: These are some oracles that can help you to investigate more information about your product. Read more about them here: FEW HICCUPPS – DevelopSense
By using these methods, you can learn about the product and form a comprehensive understanding of it, even in the absence of requirements.
How can we reduce testing iterations by exploring requirements well?
To answer this question, let’s first understand the core reasons behind multiple testing rounds:
1. Side-effects of Bug Fixes, Feature Additions, etc.
2. Low-hanging bugs that could have typically been found in unit tests.
3. Design changes at the end
4. Basic issues in build
5. Unstable builds or testing environment.
6. Development on unclear or ambiguous requirements.
While exploring requirements well can certainly solve some issues, a net reduction in total testing iterations would need an end-to-end quality consciousness software development. By thoroughly exploring requirements at the beginning of the software development process, potential issues can be addressed early on, which directly leads to reducing the need for multiple testing iterations.
One way to ensure a thorough exploration of requirements is to involve testers in the ideation stage of development. Testers can help identify missing or ambiguous requirements and question assumptions, which can help avoid costly issues down the road.
Additionally, prioritizing the problem statement and purpose can help ensure that the right questions are being asked and that all important requirements are being considered. Finally, reducing ambiguity in the stated requirements can help minimize the number of testing iterations required.
How do I quantify exploration?
Quantifying exploration is a challenge as it is a qualitative and subjective aspect. However, it is important to understand that exploration goes beyond simply testing against acceptance criteria. To quantify exploration, you can follow these steps:
1. Define the scope of exploration (charter): The scope of exploration should be defined based on the goals of the project and what the stakeholders expect to achieve. This will help you determine the areas that need to be explored and the depth of exploration required.
2. Document findings (note taking) : Document all the findings from exploration, including any issues found, insights gained, and suggestions for improvement. This documentation will serve as evidence of the work done and the value-added during exploration.
3. Use a tracking tool (Ex: SBTM): Use a tracking tool to record the progress of exploration, including the areas explored, the time spent exploring, and any issues found. This will provide a clear and concise record of the exploration process. Refer to Session Based Test Management (SBTM) to understand this in depth.
4. Evaluate the outcomes (Debriefing): Evaluate the outcomes of the exploration process, including the quality of the product, the time spent exploring, and the value added to the product. This will help you determine the effectiveness of the exploration process and identify areas for improvement.
5. Feedback and improvement: Use the evaluation of the exploration process to provide feedback and make improvements to the process. This will ensure that future exploration is more effective and efficient.
By following these steps, you can quantify exploration and measure its effectiveness. Additionally, documenting the findings and evaluating the outcomes will help you communicate the value-added during exploration to stakeholders.
