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
<a href="http://eprints.biblio.unitn.it/view/department/informaticas.html">
http://eprints.biblio.unitn.it/view/department/informaticas.html</a>
shows that a majority of documents available for requirements analysis
are provided by the user or are obtained by interviews. Moreover,
<ul>
<li>    71.8% of these documents are written in common natural
language,
<li>    15.9% of these documents are written in structured natural
language, and
<li>    only 5.3% of these documents are written in formalized
language,
</ul>
With all this natural language in use in requirements engineering, all of
the difficulties of working with natural language show up, including those
of
<ul>
<li>	understanding the meaning
<li>	ambiguity
<li>	writing clearly
</ul>

<p>
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.

<p>
We all know that natural language is <cite>so</cite> 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.
<a href="http://dspace.dial.pipex.com/jacksonma/">
Michael Jackson</a>
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.

<p>
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.


<p>
The main topics of my natural language requirements engineering research
are:
<ul>
<li>  <a href="reqs.id.html"> Abstraction Identification</a>
<li>  <a href="ambiguity.res.html">
              	Ambiguity in Natural Language Requirements
	Specifications</a>
<li>  <a href="dangerous.all.res.html">
	The Dangerous ``All'' in Natural Language Requirements
	Specifications</a>
</ul>