In this article by Sujoy Acharya, author of Mockito Essentials, you will learn about the BDD concepts and BDD examples. You will also learn about how BDD can help you minimize project failure risks.

(For more resources related to this topic, see here.)

This section of the article deals with the software development strategies, drawbacks, and conquering the shortcomings of traditional approaches. The following strategies are applied to deliver software products to customers:

• Top-down or waterfall approach
• Bottom-up approach

We’ll cover these two approaches in the following sections.

The following key people/roles/stakeholders are involved in software development:

• Customers: They explore the concept and identify the high-level goal of the system, such as automating the expense claim process
• Analysts: They analyze the requirements, work with the customer to understand the system, and build the system requirement specifications
• Designers/architects: They visualize the system, design the baseline architecture, identify the components, interact and handle the nonfunctional requirements, such as scalability and availability
• Developers: They construct the system from the design and specification documents
• Testers: They design test cases and verify the implementation
• Operational folks: They install the software as per the customer’s environment
• Maintenance team: They handle bugs and monitor the system’s health
• Managers: They act as facilitators and keep track of the progress and schedule

Exploring the top-down strategy

In the top-down strategy, analysts analyze the requirements and hand over the use cases / functional specifications to the designers and architects for designing the system. The architects/designers design the baseline architecture, identify the system components and interactions, and then pass the design over to the developers for implementation. The testers then verify the implementation (might report bugs for fixing), and finally, the software is deployed to the customer’s environment.

The following diagram depicts the top-down flow from requirement engineering to maintenance:

The biggest drawback of this approach is the cost of rework. For instance, if the development team finds that a requirement is not feasible, they consult the design or analysis team. Then the architects or analysts look at the issue and rework the analysis or design. This approach has a cascading effect; the cost of rework is very high. Customers rarely know what they want before they see the system in action. Building everything all at once is a quick way to cause your requirements to change. Even without the difference in cost of requirement changes, you’ll have fewer changes if you write the requirements later in the process, when you have a partially working product that the customer can see and everybody has more information about how the product will work.

Exploring the bottom-up strategy

In the bottom-up strategy, the requirement is broken into small chunks and each chunk is designed, developed, and unit tested separately, and finally, the chunks are integrated. The individual base elements of the system are first specified in great detail. These elements are then linked together to form larger subsystems, which in turn are linked until a complete top-level system is formed. Each subsystem is developed in isolation from the other subsystems, so integration is very important in the bottom-up approach. If integration fails, the cost and effort of building the subsystems gets jeopardized. Suppose you are building a healthcare system with three subsystems, namely, patient management, receivable management, and the claims module. If the patient module cannot talk to the claims module, the system fails. The effort of building the patient management and claims management subsystems is just wasted. Agile development methodology would suggest building the functionality feature by feature across subsystems, that is, building a very basic patient management and claims management subsystem to make the functionality work initially, and then adding more to both simultaneously, to support each new feature that is required.

Finding the gaps

In real-life projects, the following is the percentage of feature usage:

• 60 percent of features are never used
• 30 percent of features are occasionally used
• 10 percent of features are frequently used

However, in the top-down approach, the analyst pays attention and brainstorms to create system requirements for all the features. In the top-down approach, time is spent to build a system where 90 percent of features are either not used or occasionally used. Instead, we can identify the high-value features and start building the features instead of paying attention to the low priority features, by using the bottom-up approach.

In the bottom-up approach, subsystems are built in isolation from each other, and this causes integration problems. If we prioritize the requirements and start with the highest priority feature, design the feature, build it, unit test it, integrate it, and then show a demo to the stakeholders (customers, analysts, product managers, and so on), we can easily identify the gaps and reduce the risk of rework. We can then pick the next feature and follow the steps (designing, coding, testing, and getting feedback from the customers), and finally integrate the feature with the existing system. This reduces the integration issues of the bottom-up approach.

The following figure represents the approach. Each feature is analyzed, designed, coded, tested, and integrated separately. An example of a requirement could be login failure error messages appear red and in bold, while a feature could be incorrect logins are rejected. Typically, it should be a little larger and a useful standalone bit of functionality, rather than a specific single requirement for that functionality.

Another problem associated with software development is communication; each stakeholder has a different vocabulary and this causes issues for common understanding.

The following are the best practices to minimize software delivery risks:

• Focus on high-value, frequently used features.
• Build a common vocabulary for the stakeholders; a domain-specific language that anybody can understand.
• No more big-fat upfront designing. Evolve the design with the requirements, iteratively.
• Code to satisfy the current requirement. Don’t code for a future requirement, which may or may not be delivered. Follow the YAGNI (You Aren’t Going to Need It) principle.
• Build test the safety net for each requirement.
• Integrate the code with the system and rerun the regression test.
• Get feedback from the stakeholders and make immediate changes.

BDD suggests the preceding best approaches.

Summary

This article covered and taught you about the BDD concepts and BDD examples.

Resources for Article:

Further resources on this subject:

• Important features of Mockito [article]
• Progressive Mockito [article]
• Getting Started with Mockito [article]