An experimental natural-language processor for generating data type specifications

Vita.It is widely recognized that a specification of a system's intended action is required before the implementation begins. This aids in understanding the concept involved, and increases the likelihood that the implemented system will perform as expected. Due to the lack of comprehensive specification tools, design specification are frequently either omitted, or are done superficially. There exists the need for such a specification tool to aid in the development of quality software. The utility of specification language is investigated. A formal algebraic notation suitable for describing data specifications is presented, and an automatic programming system, utilizing natural language inputs, is developed. The system serves to demonstrate the feasibility of generating specification using English as a discourse medium

An experimental natural-language processor for generating data type specifications

Vita.It is widely recognized that a specification of a system's intended action is required before the implementation begins. This aids in understanding the concept involved, and increases the likelihood that the implemented system will perform as expected. Due to the lack of comprehensive specification tools, design specification are frequently either omitted, or are done superficially. There exists the need for such a specification tool to aid in the development of quality software. The utility of specification language is investigated. A formal algebraic notation suitable for describing data specifications is presented, and an automatic programming system, utilizing natural language inputs, is developed. The system serves to demonstrate the feasibility of generating specification using English as a discourse medium

The Prevalence and Impact of Persistent Ambiguity in Software Requirements Specification Documents

Despite a large amount of research in methods and tools for avoiding and detecting requirements ambiguity, recent studies have indicated that requirements ambiguity seems to be resolved through multiple inspections and discussions that characterize the requirements engineering process. However, this process may not catch ambiguity types that are likely to result in subconscious disambiguation. People are likely unaware of and incapable of recognizing these ambiguity types; therefore, these types are likely to remain after multiple inspections. This kind of ambiguity is defined as persistent ambiguity and may cause expensive damage. The potential impact of persistent ambiguity was investigated. Initially, a comprehensive ambiguity model based on linguistic ambiguity and its application to requirements engineering was developed. The model was subsequently analyzed to determine the ambiguity types likely to result in subconscious disambiguation and therefore likely to persist. Three requirements specifications were inspected for instances of persistent ambiguity as defined in the model. Each chief requirements engineer verified whether the persistent ambiguities likely to have the greatest impact on each project were indeed interpreted ambiguously, and if so, what the impact was. For the three requirements specifications inspected, there is an average of one persistent ambiguity for every 15.38 pages; project one has the highest average of one persistent ambiguity for every 3.33 pages, project three has an average of one persistent ambiguity for every 31.25 pages, and project two has the lowest average of one persistent ambiguity for every 56 pages. For the three projects, none of the persistent ambiguities reviewed by each chief requirements engineer caused expensive damage because all of the requirements engineers seemed to subconsciously disambiguate the ambiguities in the same way. For the three projects analyzed and the ambiguities reviewed by each chief requirements engineer, the least expensive approach would have been to forego initially identifying persistent ambiguity in these three projects. The first main conclusion is that persistent ambiguity remained undetected by the teams of requirements engineers. The second main conclusion is that the process used by these particular requirements engineering teams for these particular projects is enough to prevent damage. The third main conclusion is that the identification of persistent ambiguity in requirements specifications is potentially an effective and efficient strategy for minimizing damage caused by ambiguity precisely because of its focus on ambiguity that remained undetected due to lack of awareness. Further study is necessary to determine what factors are involved in persistent ambiguity and its prevalence, as well as its potential impacts