The overwhelming majority of requirements specifications are written in natural languages, albeit often amplified by information in other notations, such as formulae and diagrams. Only occasionally, one finds a completely formalized SRS using very little natural language, except as commentary. Virtually every conception for a system is written in a natural language. Virtually every request for proposal is written in natural language. A recent on-line survey of businesses requiring software, conducted at Università di Trento in Italy and available at http://eprints.biblio.unitn.it/view/department/informaticas.html shows that a majority of documents available for requirements analysis are provided by the user or are obtained by interviews. Moreover,

71.8% of these documents are written in common natural language,
15.9% of these documents are written in structured natural language, and
only 5.3% of these documents are written in formalized language,

With all this natural language in use in requirements engineering, all of the difficulties of working with natural language show up, including those of

understanding the meaning
ambiguity
writing clearly

The difficulty understanding the meaning of natural language means that it is very difficult to write software that does things to requirements documents that require full understanding of natural language. An example that we have worked on is abstraction identification, searching natural language requirements documents for key abstractions.

We all know that natural language is so imprecise, so ambiguous, and so inherently so! Thus, even if the authors of an SRS are trying to avoid ambiguities, unintended ambiguities sneak up behind us in the SRS. Even if mathematics-based formal languages are used for requirements specifications, the reality is that there is no escaping natural language requirements specifications. Michael Jackson reminds us that ``Requirements engineering is where the informal meets the formal.'' Therefore, natural languages are inevitable, even if it is only for the initial conception. (Unless the client is some really weird math-type nerd who thinks in first-order predicate calculus.) Even if one moves immediately to formal languages, the inherent ambiguity of the natural language initial conception can strike as the transition is made. What the formalizer understands of the conception may be different from what the conceiver meant.

The difficulty people have in writing clearly, apart from introduction of ambiguity, affects the quality of requirements specifications. Writing skill and correct use of language are required for readable, understandable, and clear requirements specification.

The main topics of my natural language requirements engineering research are: