The ability to deliver high quality applications that meet business needs can be very complex. Gathering requirements is typically a ubiquitous process, and rarely are requirements connected to business outcomes. It may be relatively easy if you only have one application; however, in the increasingly federated yet integrated ecosystem, it’s far from easy. Leveraging techniques such as business capability modeling, use of mindmaps, and behavior driven development have proven to increase the quality of application delivery.
A business capability model defines what the business does at its core. Business capabilities define outcomes; hence are ideal to leverage for outlining requirements. Business capability modeling provides a foundation to decompose requirements to a deeper level to aid in defining functional and even non-functional requirements. Additionally, the ability to show capability risk in business terms has introduced an entirely new value add to business sponsors.
By using enterprise business capabilities view, the dialogue changes to focus on risk awareness and business risk ownership
Leveraging a business capability model enables a consistent methodology enabling greater traceability of requirements with focus on the more critical business outcome priorities. If decomposed to the 5th level, a stronger set of requirements linked to business outcomes becomes much clearer.
Below is an example of business capability taxonomy:
Level 1 – Domain – the broad business operation, i.e. Health Care Plan Member Management
Level 2 – Discipline that produces a measurable outcome, i.e. Enrollment
Level 3 – Activities/Operations- sub-processes organized toward achievement of a more discrete tangible outcome, i.e. enrollment pre-processing/HIPAA compliance validation
Level 4 – Function – defines the vertical processes that deliver level 3, i.e. PCP assignment
Level 5 – High-level requirement, i.e. Produce member ID Card
The process components are 1. Trace requirements to business capability, 2. Create the capability based test case, 3. Prioritize testing by risk to business capability (i.e. failure probability and business impact). By using enterprise business capabilities view, the dialogue changes to focus on risk awareness and business risk ownership.
Learning can be enhanced through visualization techniques. When it comes to defining requirements, a visual articulation of the business capability and how it plays a role in the business ecosystem comes to life through conversation. Leveraging the use of mind maps can be meaningful in sifting out additional details about an application and integration from an end to end business capability. Pictorially representing interfaces, functional and non-functional requirements, and valid definitions of equivalent data ranges (upper and lower limits) are examples of items to be included in the requirements conversation.
Additionally, use of behavior driven development (BDD) techniques further enable requirements gathering resulting in higher quality. The legacy model of test driven development (TDD) really only helps developers pass tests. By leveraging BDD, there’s a more shared understanding as to how the application should behave (specification) by using examples. The requirement is defined with context, action/event and outcomes. BDD practitioners explore, discover, define, then drive out the desired behavior of software using conversations, concrete examples and automated tests.
The unspoken implication is that the QA team needs to get engaged early in order to provide meaningful results. QA engagement to influence assignment of business impact and failure probability at the requirements and design stages can be meaningful. From a skill set perspective, the role of the quality engineer is evolving beyond the test analyst. A deeper understanding of the business, increased communication skills, along with development skills become table stakes. Use of blended roles of Business Systems Analysts and Quality Engineers can provide some increased flexibility; however, there’s still a need for dedicated automation skills to build and maintain the automated regression suite based on business capabilities.
The benefits of leveraging these transformational techniques not only enable gathering better requirements to improve quality, but also increased engagement of the business and IT teams by fostering shared understandings and trusted partnerships. Although initially the cost and time investment to build the necessary foundational automated regression suite may be higher than the typical 20 percent cost of QA, re-use as part of the continuous integration and delivery pipeline as well as fewer production defects enable reduced cost of quality.
Continuous evaluation of quality practices is vital to remain relevant. As firms are digitally transforming, quality improvement can’t be an afterthought. Leveraging strategic methodologies proactively, focusing on skills of the future, and staying nimble support increased application solution delivery quality.