Background
In 2016, one of our colleagues, PhD candidate Vard Antinyan, has developed a tool for assessing the quality of requirements.

In short, the tool helps software designers and business analysis to capture requirements that are:

  • Ambiguous
  • Hard to implement
  • Hard to test
  • Too complex

The tool is based on a formula developed together with the Software Center companies and has been successfully implemented in two companies. It has also become a mandatory practice of one of the companies, being implemented in their requirements analysis tool.

Interview with the author, Vard Antinyan:

Question: Can you tell more about what is Rendex?

Vard Antinyan: Rendex is a method that permits automatically identifying poorly specified requirements “just in time” of writing the requirements. The method is an integral part of the practitioners’ working environment, so that the administrative time of its application is virtually zero.

Q: What is the industrial problem that is solved by Rendex?

VA: In large software development companies the regularly incoming requirements are thousands. The problem is that it is not possible to assert that these requirements are accurately specified and understandable. Manually reviewing these requirements is a tiresome and time-consuming task. Not reviewing the requirements is not an option either, because it can trigger late design modifications with higher development cost. Therefore, there is a need for automated reviews, such reviews that could permit practitioners improving requirements as early as the requirements are written.

Q: How did you come up with the idea of Rendex?

VA: First, I needed measures in order to automatically assess the understandability of requirements. But there weren’t such measures. So I decided to create ones. As it turned out it wasn’t straightforward to create such measures, because it is difficult to measure natural language text. So I asked experienced software engineers to send me a group of requirements which, according to their experience, are not understandable. I also asked them to send me another group of requirements that are clearly understandable. Then I compared these two groups and tried to find out what language features make the first group not understandable and the second group clearly understandable. After a meticulous examination I could find that there are certain simple language features that have significant impact on understandability of a requirement. The good news was that it was possible to measure such features accurately. I can bring an example: Try to make a general sentence (about anything you wish) that contains more than three grammatical conjunctions, and then articulate that sentence to a friend of yours. Ask her if she understood the meaning of your sentence. I assure you that she will start pondering about it and asking clarifying questions. It is as easy as it gets, just counting the number of conjunctions can indicate how clear your sentence is. We articulate vague and complex sentences in our conversations in daily life, because we can afford it. But if software engineers do so in writing requirements the consequences can be serious.

Q: Why do you think it is so useful for industry?

VA: It can save hundreds of hours from practitioners precious time. It can prevent emerging problems that are due to poorly specified requirements. It can instill the idea of building quality into the product rather than conducting detached quality assurance activities. Of course all of this promises are only related to requirements, but the same mindset can be applied in other areas of development.

Q: If you were to give an advice for others on how to get their results successfully applied in industrial context, what would it be?

VA: There is little likelihood that any new result can be successfully used in an industrial context in one attempt. And the researchers need to recognize the importance this. When we, researchers, develop a method, we do not count for the unknown parameters that can intervene the application of that method in industry. Then we may get surprised that the method didn’t work as expected or that the practitioners weren’t enthusiastic about the method. There can be several reasons for these:

  1. The administrative time that is spent on applying the method can be more costly than the benefits from the method. Therefore, the researchers should pursue automation and integration of the method within the application environment.
  2. The method may not consider the specifics of the application environment. Then, the method should be calibrated with close collaboration of practitioners. Action research methodology can be useful here.
  3. Pure problem identification and presentation to the companies can be appreciated, because it has therapeutic effect on practitioners: someone from outside understands their problem! But sheer problem identification cannot lead to resilient research in the companies in a longer term, because such research lead to stagnation. For example, we can still see scientific papers rediscovering such problems as “late requirement changes”, already discovered many times in the past. Oppositely, the focus on how to minimize the negative effect of “late requirements changes” is much harder problem, but it can lead to rewarding results in a longer term. Therefore, researchers should focus rather on solutions than mere problem identifications.

Links:

You can read more about the Rendex tool here: http://www.sciencedirect.com/science/article/pii/S0164121217301000

You can read more about Vard’s PhD thesis here: http://web.student.chalmers.se/~vard/