February 1, 2018

SMART Requirements for Smart Testing

I want to introduce you to SMART requirements, a method for structuring software requirements that is both easy to understand by people and automatically interpretable by tools that support testing and other development tools.

There are many development models in use today that improve upon the classic waterfall approach – Agile, Test-Driven Development (TDD), Behavior-Driven Development (BDD), Rapid Application Development (RAD), the Spiral Model, Feature-Driven Development (FDD), and Rational Unified Process. The newer development models focus on smaller teams, faster delivery and delivering quality software into the hands of users more quickly. 

A common process change compared with waterfall development is the removal of the traditionally-written specification. In waterfall the requirement specification was completed before moving onto the next step. The specification provided a complete, detailed view of the requirements of the system. In Agile and other models, the traditional single requirement specification has been replaced by the incremental and iterative development of multiple smaller specifications that are much simpler in form. Creating a common standard for what these smaller specifications should look like is the idea behind SMART requirements

SMART Requirements are those sets of documentation, written in natural language, that can be automatically interpreted, tested, and validated without any human intervention. SMART requirements can be integrated into agile, and any of the modern development processes. With SMART requirements the process of writing specifications, defining tests and automating their execution would be standardized in a well-understood format that ultimately reduces the time to initially produce the documents and minimizes on-going maintenance costs.


Why is there not a quasi-perfect development model that can be applied by all companies that develop software?


Every software development team evolves its own documentation standard, influenced by many factors, such as the kind of product they are building, the standards within the organization, the development process they are using and, most importantly, what has worked for them as individuals in the past. 

The implementation of a model such as SMART that is adaptable to a broad range of development teams or types of software applications has been tried before with only limited success. 

Limited previous success has not removed the need to try again. Companies still want reduced costs, faster delivery, and higher quality, all things that SMART requirements can deliver.

How did we get here?

In terms of software production, we have witnessed a direction focused on improving processes and adapting them to the profile of each company and the type of product they develop. These investments bring about better productivity, independent of the industries they are being applied to. Even if they prove to be good in the short term, they are also perfect in the medium and long term, demonstrating enough hotspot points.

Over the past two decades, in the world of software development, we have witnessed an almost brutal conversion of development models, and the added value that investment in the development of new processes can still deliver is rather limited.

Productivity efficiency can still be achieved, but attention and effort should be directed to optimizing other components of the software product development cycle. Two of these – costly but indispensable to software development – are product specifications and quality assurance.

Paradigms such as ‘full specifications’ or ‘exhaustive testing’ have become taboo subjects. We often find situations in which the specifications in their classical approach are incomplete or ambiguous, thus interpretable to all actors involved in the development of the finished product. The heath of what the client wants, what the analyst understands, what is being implemented, and how or what is being tested has become a common problem. The later the discrepancies are observed, the more expensive they become.

Three or four elements? Interpretable. It depends on perspective.

Interpretative specifications generate interference in communication and introduce performance discordance across all actors involved in the development process.

The picture above is a classic example of apparently precise but actual ambiguous and incomplete specifications.

A significant percentage of resources at the project level are allocated, on the one hand, to the definition of specifications at a generally accepted level to start development and, on the other hand, to testing and validating the application to be delivered to final customers.

An investment that is increasingly present and accepted by IT investors is the one in testing automation. If the ‘SMART Testing’ paradigm has been spoken of in the literature on software testing and validation, why not advance this ‘SMART’ concept and specifications and, moreover, adopt a connection in a direct relationship between specification definition and automated testing, i.e., SMART Requirements?

Arguments and Reasoning

A unique, automated interface used both to define and validate specifications and automate product testing that can automatically “understand,” test and validate sets of specifications that come directly from the customer (or requirement engineer, project owner, etc.) is one of the ways we can shorten delivery times. The specifications would still be written in a natural, non-technical language but would implement a set of clear rules that will be syntactically and logically validated at the automation interface. The same interface will generate automated test scripts, accurately reflecting the specification requirements and validating the software by executing tests on developed modules.

This flow, executed without the need for human intervention, would have a significant impact on reducing software production time. It would reduce the time required to write the specifications, and would, on the other hand, eliminate the discordance between those who define or modify specifications and the rest of the actors involved in the production process.

Define the Specifications with Keywords

A solution used in the design of automated tests using keywords is the model “Precondition – Action – Result” or “Given – When – Then” (GWT). This solution can be extended and applied directly to the specification phase, facilitating the creation of automated tests that will strictly reflect the requirements imposed by these specifications.

We consider the following as an example of the different approach to defining specifications:

  • Classic approach – When the user visits the application, the login page is displayed. Once authenticated, the user is directed to the home page.
  • GWT approach – via SMART Requirements
    • Given – the access app
    • When – the login page displayed and the login button clicked
    • Then – the home page displayed
    • Given, When, Then, And – logical operators used by the automation interface to define the specifications and automated tests derived from them

The access application, the login page, click the login button, the home page displayed – are the keywords being used, on one hand for writing the specifications, and on the other for defining the automated tests? These keywords match and implement the automated scripts necessary to create tests that will verify and validate the actions described in the specifications.

In this way, the specifications become test cases or vice versa.

The advantage of having correctly defined specifications and executable tests automatically derived from them is one that deserves an initial investment in an interface of this kind. And the fact that there are already communities and software packages that address these issues (e.g. Cucumber) makes the effort to implement this solution profitable and the return on the initial investment can be reached quickly.

Moreover, this interface could be used not only to implement functional and nonfunctional automated black-box tests but also to generate white box tests or to create complex test scenarios based on both product specifications and user experience with the product.

All actors involved in product testing, including user acceptance or beta-testing phases, can create their tests using the SMART Requirements model, thus adding value to the general regression suite of the final product.


Clear specifications and quality assurance are two artifacts that are part of the software development lifecycle where compromises should never be made.

In the classical approach, finalizing the specifications was a costly process that slowed development and extended the delivery time of the product to the end customers. Another expensive aspect of the classic approach is the excessive rework generated by changes in specifications that required, as a direct consequence, the modification of related tests, whether automated or manual.

By introducing specific frameworks to implement SMART Requirements, we have the opportunity to re-generate test scripts so that they adequately reflect any changes to the specifications. Automatic. No additional costs. No compromises.

Spread the Word

If you liked what you read in this post, please help us spread the word about it via the Click to Tweet feature below or the social sharing icons at the bottom of the post.

[bctt tweet=”Why use SMART requirements for Smart Testing? You’ll deliver higher quality code to production more reliably and for cheaper. Read more in this blog post from Narcis Oancea. ” username=”3PillarGlobal”]

This post was originally published in the 64th edition of Today Software Magazine.