Development of a Requirements Classification Scheme for Automated Support of Software Development

Authors

  • Dolly Samson

DOI:

https://doi.org/10.7152/acro.v1i1.12474

Abstract

Computer hardware technology has advanced to the point where it is feasible to develop software systems that exceed one million lines of code. Software engineering, the discipline concerned with developing these systems, typically includes the following phases in the software development cycle: requirements phase, design phase, implementation phase, test phase and the installation and checkout phase [IEEE, 1983]. This paper is concerned with a classification scheme to support knowledge-based analysis of software requirements. Because requirements in these large systems can become quite numerous and complex, it is a very difficult task to analyze them in order to identify potential problems, i.e., problems that may arise in later phases, such as incompleteness, conflict, ambiguity, and absence of testability. Current software productivity tools such as CASE (Computer-Aided Software Engineering), executable requirements languages, prototyping tools, and test harnesses provide much assistance in later phases of software development, but not much for the requirements phase. It is well-known in software engineering that the most costly and profound software errors are likely to occur at the requirements definition phase, early in the software development cycle. The productivity tools mentioned earlier either work from code which has been developed for the system. or work with user requirements statements which have been translated into a restricted, formal language. There are several problems with translating user requirements into a formal language very early in the project First, it is difficult for the user to understand requirements as they have been translated and interpreted by the systems analyst. Second, the systems analyst may have made wrong assumptions or interpretations in the process of translation. Finally, formal languages do not have any provision for ambiguity, and early in the requirements phase, ambiguities may exist, to be worked out as more is learned about the system.

Downloads

Published

1990-10-06