Comprehension, Use Cases and Requirements.

This is the latest version of this eprint.

Abstract

Within requirements engineering it is generally accepted that in writing specifications (or indeed any requirements phase document), one attempts to produce an artefact which will be simple to comprehend for the user. That is, whether the document is intended for customers to validate requirements, or engineers to understand what the design must deliver, comprehension is an important goal for the author. Indeed, advice on producing ‘readable’ or ‘understandable’ documents is often included in courses on requirements engineering. However, few researchers, particularly within the software engineering domain, have attempted either to define or to understand the nature of comprehension and it’s implications for guidance on the production of quality requirements. In contrast, this paper examines thoroughly the nature of textual comprehension, drawing heavily from research in discourse process, and suggests some implications for requirements (and other) software documentation. In essence, we find that the guidance on writing requirements, often prevalent within software engineering, may be based upon assumptions which are an oversimplification of the nature of comprehension. Furthermore, that these assumptions may lead to rules which detract from the quality of the requirements document and, thus, the understanding gained by the reader. Finally the paper suggests lessons learned which may be useful in formulating future guidance for the production of requirements documentation.

Available Versions of this Item

• Comprehension, Use Cases and Requirements. (deposited 04 Aug 2009 17:13)
  • Comprehension, Use Cases and Requirements. (deposited 03 Oct 2009 13:14) [Currently Displayed]