Requirements? Tests? Please talk!

Requirements engineering and software testing, the “two ends of software development”, often are treated separately in software engineering research and practice. However, the interaction between requirements engineers and testers is critical for successful software engineering. In a column in IEEE Software, we share our thoughts on how better alignment can be reached. The column is even available as a podcast!

Elizabeth Bjarnason and I were invited to write a for the RE column in IEEE Software and decided to cover our favorite topic: the interplay between requirements engineering and software testing. We argue that testers and requirements engineers should work closely together, to align expectations on the product under development. This supports both early requirements engineering and late V&V – and most likely everything in between.

We report challenges identified in industry, including i) testers having no insight in how and when requirements are defined, ii) poor coordination of RE and testing activities (especially when requirements change), and iii) “requirements distortion” as they trickle down from requirements engineers to testers through development. Our general observation is that most problems are caused by poor communication in the development organization.

Requirements Engineering and Testing (RET) is a research area that particularly targets the coordination of RE and testing. Solutions that improve RET alignment come from a wide variety of research communities, e.g., improved processes, model-based testing, and software traceability. In the column, we present three examples of solution-oriented RET research from Lund University. First, the agile practice of using test cases as requirements. This practice reduces the need to maintain separate documents, and requirements engineers and testers rely on the same information. Second, harvesting trace links implies reusing  collected traceability information (e.g., collected for certification purposes in regulated domains) to align individual requirements and test cases. Third, reducing distances between requirements engineers and testers. One way is to make sure the two roles meet frequently, another approach is make sure the semantic distances in documents are low (i.e., requirements engineers and testers align the technical language).

RET is a critical aspect in any large software engineering project. We are part of the organizing committee of the RET workshops that have been co-organized with RE’14, ICSE’15, and REFSQ’16 – this year it will be co-organized with RE’17 in Lisbon, Portugal. Please consider submitting a paper to the 4th International Workshop on Requirements Engineering and Testing 2017! We hope to cover a wide range of issues and topics including how the requirements derivation process impacts testing decisions, how certification needs in testing impact how requirements must be formulated, and how the integration between requirements engineering and testing can be improved. Welcome to join us for a full day of RET in September!

Implications for Research

• There is considerable research available on either requirements engineering or software testing – RET research aims to focus on the interaction in between.

Implications for Practice

• RET is important in any large project, but the most appropriate solutions to tackle the challenges depend on the context.
• In projects for which agile development is feasible, the practice of using test cases as requirements can be beneficial to align RET.
• In projects with formal requirements on trace link maintenance, the tracing effort can be reused to maintain RET over time.

Elizabeth Bjarnason and Markus Borg. Aligning Requirements and Testing: Working Together toward the Same Goal, IEEE Software, 34(1), pp. 20-23, 2017. (link, preprint, podcast)

Abstract

The proper alignment of requirements engineering and testing (RET) can be key to software's success. Three practices can provide effective RET alignment: using test cases as requirements, harvesting trace links, and reducing distances between requirements engineers and testers.