A competition to find the Best Modeling Notation for Requirements Engineering was held as part of the RE’09 Conference. As you all know, there is a huge number of different notations/approaches for modeling stakeholders’ requirements such as: plain text specifications, structured text templates, goal-oriented requirement approaches (e.g. using the i* notation ), User Requirements Notation or the UML.

That’s the reason why Orlena Gotel AND Jane Huang planned a competition where “Teams of modelers will be challenged to illustrate the power and flexibility of their favorite approach for requirements modeling, while conference participants will act as the ultimate judges as they vote approaches off the panel round-by-round” . All teams will be given the same initial problem description and asked to express their understanding of the problem using their modeling approach.

It’s time now to know the outcome of the competition. Xavier Franch , leader of the GESSI research group has been kind enough to write a summary of the competition for us:


A vibrant competition was held for determining the top model requirements engineering notation. In the first round, the several teams presented in one slide-three minutes a model for a problem statement given in advance, an imaginary new version for the New York Fire Engine Dispatch System. The applausometer determined that the four finalists were natural language, rich images, URN and the i* framework. Subsequent rounds incorporated new requirements from two stakeholders that just showed up in the room (two frustrated Shakesperian actors, brilliant Don Gause and Brian Berenbach). To make a long story short, natural language and rich images won ex-aequo the contest. Given the informal and in fact comedy-like nature of the panel, it makes no sense to try to conclude anything. However, it is true that for the two semi-formal notations that passed the first round, adapting on the fly the model to the new requirements was tough due to the difficulty of presenting the resulting
model in an attractive form for the audience and the need to use a flip-chart in the room instead of some supporting modeling tool.

Attendees did reward the intuitive understanding of the new models in the two informal notations, and basically, this was the main criterion to decide. The reasoning capability of the other two more formal notations didn’t have a chance to be explored. To sum up, it was a funny exercise but the award is still to be decided.

Of course, the results are not conclusive but I think Xavier has a good point when says that people liked the more informal notations because they were easier to understand and to adapt to changing requirements and that the power of more “formal” notations lies on its capacity to be analyzed (e.g. to check their completeness and other quality properties) and processed (e.g. to derive preliminary versions of lower-level views of the system), which was not part of the competition so people could not see if the additional investment required to express requirements using more formal notations pays off.

 

Want to build better software faster?

Want to build better software faster?

Read about the latest trends on software modeling and low-code development

You have Successfully Subscribed!

Pin It on Pinterest

Share This