A Sea of Description Languages

From natural language to formal specification languages, almost all kind of languages have been proposed to be used for the description of requirements. However, the use of natural language is unavoidable, even if the problem can be specified formally, and the team believes that it is worth the effort, it is necessary to use natural language to communicate with end users.

To deal with the vagueness of natural language techniques have been proposed to write clearly and concisely by using short sentences, avoiding redundancy, using simple words, etc. Structured natural language approaches, like the Volere Template, enriches natural language with a structure that enforces some of the qualities of a requirements specification. These templates define the elements that a particular kind of requirement should have and provide check lists to enforce completeness. Additionally, to support traceability, they provide elements to describe dependences between requirements, the identification of the source of requirements, and the modules that implement them.

The structured natural languages have an implicit model which permits some level of checking of the requirement descriptions’ qualities. However, this verification is informal and human error-prone. Formal requirements specification languages make this model explicit to support the automatic verification of the requirement specifications’ qualities, like their consistency, which means that there are no two requirements which cannot be simultaneously implemented by a system.

In the middle of the spectrum between the use of natural and formal languages for requirements specification we can find semi-formal languages and notations, like UML, which allow descriptions that are closer to the implementation context. For instance, UML may be adequate if the system is going to be implement according to the object-oriented paradigm. UML intends to provide seamless a set of languages which cover from structured natural language, like for instance a use case description, to behavioral models, like for instance a statechart diagram, where the latter can be use for implementation or simulation. Some Model-driven engineering approaches extend UML to support executable descriptions and avoid the need of double validation, of the requirements specification and of the final software artefact.

Agile methods propose specification-by-example, where the requirements are described in terms of test-cases. By using specification-by-example the requirements have the verifiability quality, but they cannot be easily reviewed by other stakeholders than developers. Besides test-cases execution, reviews, formal verification and prototyping are the techniques used for requirements validation.

Which requirements specification languages to use and how formal they can be depends on the stakeholders ability to understands formal models and how sound should be the requirement descriptions. Critical systems, where the loss associated with failures is high, need a rigours verification of the quality of the requirements descriptions, which results in more costly systems which will take longer to develop.