Options:

Praveen Chinnappa

Strengthening the Requirements Engineering Process

Integrating a Testing Mindset for Requirements Engineers


The quality of a requirement is significantly dependent on its clarity and completeness. In many agile projects, requirements typically capture the primary intent of the software. The variations, exceptions, and intended exception behaviors are left implicit and often uncovered in development or testing phases. This results in partially complete requirements, repeated clarification cycles, and costly reworks. Testing plays a crucial role in determining the software readiness. This is linked to the quality of requirements since test cases are designed to exercise the requirements. The International Software Testing Qualification Board (ISTQB) recommends test design techniques such as boundary value analysis, decision tables, and state transitions to achieve broad scenario coverage. While test design is the primary responsibility of testers, explicitly calling out variations and exceptions reduces interpretation and increases testability. Product Owners (PO) and Business Analysts (BA) can support this activity by adopting a tester’s mindset during the Requirements Engineering (RE) process to deliver requirements that can withstand systematic testing. This mindset encourages the BAs and POs to ask questions such as: - Can this requirement be tested? - Under what conditions will the requirement fail? - What are the intended exception paths and expected behaviors? - Are variations of requirements clearly defined? This article presents practical techniques and real-world examples for implementing a tester’s mindset for the BAs/POs during requirements engineering. The comparison highlights the benefits of this mindset shift and its contribution to overall software quality. While the proposed approach is not intended to replace the responsibilities of testers, it equips BAs and POs to deliver stronger and better-defined requirements, thus contributing to the overall software quality.

Introduction

The Agile manifesto’s principle of “Working software over comprehensive documentation” is intended to enable rapid software delivery and frequent user feedback. Unfortunately, this principle is often misinterpreted to treat documentation as minimal, omitting critical details, and leading to ambiguous and incomplete user stories.

A widely accepted framework for user stories creation is the Independent, Negotiable, Valuable, Estimable, Small, and Testable (INVEST) guideline that helps to ensure the clear value and completeness of user stories. The last attribute – Testable (T) - emphasizes that the user stories must be testable to be considered complete. However, the critical question is: do BAs and POs consistently apply this dimension to all the user stories?

Vague requirements without appropriate details lead to confusion during development and testing activities. If not addressed, this often leads to defects rooted in requirements deficiencies. In some projects, critical defects remain uncovered because specific scenarios are not clarified.

This article is intended to foster a subtle but important mindset shift encouraging BAs and POs to wear a tester’s hat during the requirements engineering process. This approach can substantially improve requirements’ quality and reduce overall defects.

Requirements and Testing - Two pillars of SDLC

RE and testing activities within the Software Development Life Cycle (SDLC) are closely related to each other. The ISTQB recommends several test design techniques such as Boundary Value Analysis (BVA), use of Decision Tables (DT), and State Transition Testing (STT) to achieve systematic coverage of requirements [ISTQB18]. The effectiveness of test design techniques significantly depends on the clarity and completeness of requirements. The Boundary Value Analysis technique requires clearly defined boundary thresholds and corresponding exceptions beyond those thresholds. Similarly, decision tables need clear business rules based on varying input conditions. Even the best test design techniques cannot be applied if the requirements are ambiguous and/or incomplete.

A successful project must strike the appropriate balance between requirements and testing. This relationship emphasizes the critical role BAs and POs play during requirements engineering. By incorporating the tester’s mindset, BAs and POs can uncover multiple aspects of the requirements early in the lifecycle. This ensures that the requirements establish a strong foundation for downstream activities and drive towards high quality software deliverables. These two aspects bridge the two extremes of the SDLC and significantly drive the activities in the middle area depicted in the image below.

Figure 1: Relationship between RE and Testing

Documentation in Agile – The misunderstood principle

Agile frameworks foster value-focused, fast-paced development environments with flexibility and rapid delivery. This has allowed teams to adapt to changes quickly, eliminating long change cycles. However, one of the critical Agile principles, “working software over comprehensive documentation” [AGILE01], is often misunderstood by project teams. Many interpret this as an invitation for minimal documentation, which can lead to ambiguous and incomplete user stories.

This misinterpretation opens the door for multiple risks, from development based on assumptions to defects related to requirements deficiencies. It can also conceal critical defects, as each team member interprets the requirements differently rather than aligning to a centralized objective.

Consider a simple user story and associated Acceptance Criteria:

User Story: “As a user, I want to register an account by providing my profile details so that I can create an email address”.

Acceptance Criteria (AC):

While these ACs appear to convey the intent, several key details are missing:

These missing details lead to an inconsistent development cycle which results in high defect density, prolonged test and defect-fix cycles, and high production defects.

This outcome was not the intent of the Agile Manifesto. The principle promotes right level documentation, just enough for a user story to be developed and tested with a unified understanding across POs, BAs, developers, and testers.

This challenge should be addressed in the Requirements Engineering process. A mindset shift can expand the ability of POs and BAs to apply a multi-dimensional view of requirements, specifically the QA dimension.

Tester Mindset – A new dimension in Requirements Engineering

The Business Analysis Body of Knowledge (BABOK) emphasizes the importance of clear and unambiguous requirements [IIBA21]. The testing dimension during RE complements the BABOK principles associated with well-defined and clear requirements. The tester’s mindset in requirements engineering is not about performing testing on the requirements but rather about applying testing principles during the RE process for increased clarity. This perspective enables the BAs/POs to deliver strong requirements that are clear, precise, complete, and testable.

Early Static Testing

As emphasized in ISTQB best practices, testing activities should start as early as possible in the SDLC. In the RE process, static testing techniques can be applied to identify gaps in requirements even before development starts.

Table 1: Static Testing Techniques

The static testing techniques allow BAs/POs to identify requirement defects early in the lifecycle, avoiding costly rework.

Leveraging Test Design Techniques

ISTQB provides a wide array of test design techniques that are applied during test cases creation. BAs and POs can use these techniques during the RE process to ask critical questions to enhance the requirements. Table 2 lists major test design techniques recommended by ISTQB.

Table 2: Test Design Techniques

This enhanced view through the test design techniques allows BAs and POs to address critical scenarios beyond a simpler approach.

Final Verification Checklist

After applying the various static and test design techniques, a final checklist of questions can be used to ensure requirement readiness for downstream activities. These questions validate that the requirements cover sufficient verifiable details rather than broader user intents.

The checklist-based questions provide added assurance that the requirements are ready to be handed over to development and QA teams.

The tester’s mindset shift does not convert BAs and POs into testers. Instead, it adds a new quality dimension within RE. In addition to the traditional BA/PO activities, this mindset equips BAs and POs to use testing principles proactively to reduce clarification cycles, prevent defects, and minimize misinterpretation of requirements.

The following diagram depicts the high-level steps involved in applying a tester’s mindset during RE:

Figure 2: Tester's Mindset - Implementation Steps

Password reset case study

Consider a common password reset requirement and its transformation through the tester’s mindset.

User Story: “As a registered portal user, I want to be able to reset my password so that I can regain access to my account.”

The initial acceptance criteria associated with the user story are listed below.

Table 3: Initial Acceptance Criteria / AC

At the surface level, this user story and ACs appear to convey the primary objective and several details associated with the user story. However, some derails are still missing - open questions remain which will be discovered through systematic application of a tester’s perspective.

Step 1 Static Analysis

A semi-formal walkthrough with stakeholders uncovers the following gaps:

  1. The number of old passwords that cannot be reused is not defined.
  2. The time duration for the lockout resulting from failed reset attempts is not specified.
  3. Error message descriptions for both successful and failed attempts are not specified.

Step 2 Applying Test Design Techniques

Target Test Design Techniques appropriate for the use case.

Based on the questions uncovered in steps 1 and 2, the ACs are enhanced as follows.

Table 4: Revised Acceptance Criteria

Step 3 Final Verification Checklist

The rewritten ACs are subjected to quick evaluation by answering the final checklist questions listed in the below table.

Table 5: Final Verification Checklist

Though the original ACs appeared adequate, using the proposed approach of ensuring that BAs and POs utilize a tester’s mindset during the requirements engineering process revealed and resolved gaps. The rewritten ACs strengthen clarity, testability, and completeness, transforming moderate quality requirements to high quality requirements.

Advantages of utilizing a tester’s mindset during the requirements engineering process

Adopting a tester’s mindset during the requirements engineering process adds several benefits to the overall product quality. Each benefit can also be measured for its practical effectiveness as described in the table below.

Table 6: Tester's Mindset - Advantages

Conclusion

The agile principle “working software over comprehensive documentation” is often misinterpreted as a shortcut to documenting minimal requirements, which can result in ambiguity and missing details. The original intent of this principle is to document requirements which are complete, concise, and aligned to a common understanding.

Implementing a tester’s mindset during the requirements engineering process adds an additional quality dimension. As a result of using static reviews, test design techniques, and final verification checklists, BAs and POs can deliver stronger requirements with reduced ambiguity and reduced defect fix costs.

As demonstrated in the case studies, the quality dimension increases clarity, strengthens traceability, and reduces defect counts. Project teams can measure the effectiveness of these techniques to refine the approach. The tester dimension is not intended to replace testing activities or to equate to test driven requirements. Instead, the mindset shift adds an early investment in the RE process that significantly reduces time and cost associated with downstream defects and clarification cycles.

In summary, the tester’s mindset provides a subtle but powerful improvement in the RE process. This improvement enables use of quality assurance principles in the earliest phase of the SDLC. It serves as an additional tool to significantly enhance the overall software quality.

References