Abstract

Keywords: early development artefacts; requirements reuse; requirements elicitation; software specification; word-processing.

Workshop Goals: To identify different classes of early life-cycle artefacts; to look into the methods of their effective use, their capture, storage and retrieval, formalisation, refinement and ultimately their reuse; to recommend the commercial tools available for the processing of such early life-cycle products.

Working Groups: Reuse of the Earliest Life-Cycle Artefacts; Domain Engineering Tools; Object Technology, Architectures, and Domain Analysis.

1. Background

2. Position

2.1. Reuse of Early Software Artefacts

* analysis of existing software in search for reusable artefacts (their identification in legacy software, understanding and generalisation of their properties);

* organisation of reusable artefacts into a reuse library (by providing methods of their classification, storage, search and retrieval); and,

* synthesis of new software out of reusable artefacts (through the selection and adaptation of retrieved artefacts and their integration into new software products).

This reuse process is equally applicable to code, designs and specifications. In this paper, we investigate reuse of informal requirements documents, the most unwieldy development products constructed at the earliest stages of software development.

2.2. Problems with Early Reuse

* problems with human communication, due to its volume and complexity, terminological differences, ambiguities through the use of natural language, lack of structure and rigour;

* problems with tracking the origins of software artefacts, due to the complexity and frequency of software revisions, premature formalisation of software requirements, loss of the original forms of artefact specification; and,

* problems with early development processes, due to inadequately defined business processes, organisational procedures and poorly understood relationships between the people involved, their responsibilities and the tasks performed.

The above-mentioned problems and complexities, find their source in the very nature of the pre-specification form of software documents, i.e. the media used to record them, their loose structure and inaccurate notation.

* Media. Initial software documents come in the form which promotes human communication, this includes free text, graphics, images, video and animation, speech, sound, and other sign systems [17]. Such documents are rarely in a computer-readable form, hardly ever yielding to further automation, formalisation and integration.

* Organisation. Documents produced at early stages of software development frequently lack formal structure and logical organisation. This is primarily because they result from meetings, email discussions, interviews, or legacy documents [19].

* Notation. Early software artefacts are commonly recorded in natural language being the primary form of communication between project stakeholders. As the result, early artefacts, such as informal requirements texts, suffer from redundancy, omission, over-specification, contradiction, ambiguity, unresolved references or wishful thinking [16].

2.3. Benefits of Early Reuse

* improvement in the quality of requirements specifications [12];

* better utilisation of available resources [13];

* inducement to systematic reuse across the entire software life-cycle [9, 15];

* developmental assistance early in the life-cycle [14]; and

* easier reuse of the subsequent life-cycle products [18].

2.4. Problems Still to be Resolved

* Can we process early software artefacts more effectively than it is currently possible?

* Can we equip reusers of such artefacts with the computer-aided tools?

* Do early reuse processes differ from those employed in the reuse of code and specifications?

To answer these questions, we will conduct a small thought experiment, comparing three different approaches to reusing three types of software artefacts (Cf. Table 1), i.e. informal requirements (using a modern word processor, such as Microsoft Word or Word Perfect), formal specifications (with Larch LSL and LP) and program code (using GNU C++).

2.5. Early Reuse vs. Late Reuse

Analysis. Analysis of code and specification artefacts in the existing documents can be assisted with syntax editors (such as Emacs), syntax checkers (e.g. LSL) and compilers (e.g. G++). Such tools usually produce annotated listings, symbol maps and tag lists which facilitate better understanding of text. In the case of plain-English requirements documents, the onus is on the author of an artefact to manually index, classify and table the contents of such documents for later processing. In all cases, comments and annotation of texts can significantly clarify the intention of their authors. The three environments offer the tools for static verification of code, specifications and English text. Irrespective of the artefact nature, the process of document validation must rely on the external source of information, unsupported by any of the tools. Specification proofs and program execution will merely improve the process. C++ and LSL offer special constructs allowing easy artefact generalisation and the subsequent specialisation (class and trait hierarchies). Although generalisation concepts do not exist as part of the requirements text syntax, they can be approximated by the use of word processing masters, templates, outlines and forms.

Organisation. The methods of artefacts storage and retrieval depend on the methods of artefact representation. Plain files and full-text databases are equally applicable to all kinds of text. Fine grain representation of C++ and LSL components can be facilitated with data dictionaries. None of the tools, however, directly supports such mechanisms. On the other hand, word processing document collections can be effectively searched for user-defined property values and keywords. Code and class browsing capabilities, as available in C++ programming environments (e.g. via Emacs tags), may be compared with hypertext facilities for browsing of free text. Information retrieval, natural language processing and signature matching could further improve manipulation of textual artefacts, unfortunately, they are not available in any of the discussed support environments.

Synthesis. New artefacts can be constructed of reusable document components with cut-and-paste, insertion or embedding of reusable components. Hypertext links in requirements text provide the ability to reference reusable artefact components, not unlike code referencing by function calls and variable typing. Parametrised references are also possible in the text structured into outlines, templates and forms. Macro-like expansion of references to reusable texts can be achieved with print-merge, property fields and glossaries. Class specialisation and instantiation is not available in commonly used word processors. However, the effect similar to reuse by class specialisation and instantiation can be achieved in requirements texts by filling in word processing templates and forms. Forward references may be organised with hyper-links to as yet unspecified requirements, assumptions in LSL traits or virtual classes and overloading in C++.

Table 1 - Reuse of requirements, specifications and code
- direct support, - no direct support or the process is manual, ? - under investigation

3. Summary and Conclusions

Unfortunately, due to the shortage of space we could not provide an extensive example of effective utilisation of a word processor in requirements gathering, analysis, refinement and reuse.

Despite many advantages, word processing software also suffers from some disadvantages which could only be eliminated with the use of a custom-built requirements processor, e.g. RARE IDIOM [8]. In contrast to ordinary text processing software, requirements reuse environments display abilities :- to handle large collections of requirements documents, to engage in active interaction with the user, to assess artefacts reusability, to derive and use the semantic representation of individual requirements, to be more effective in document analysis, to assess document integrity and completeness, to assist requirements engineers in requirements refinement and formalisation, etc.

Another interesting implication of our thought experiment is the potential of applying identical or similar techniques to other types of early life-cycle documents, e.g. tender documents, management plans or feasibility studies. All such documents are commonly expressed in plain natural language text, they are informal and loosely structured. At the same time, similarly to requirements documents, these early texts have a tremendous impact on the subsequent project development. We, hence, plan to undertake further investigations into the possibility to provide active assistance in the development of other types of early life-cycle products.

References

[2] M. G. Christel and K. C. Kang, "Issues in Requirements Elicitation," Software Engineering Institute, Carnegie Mellon University CMU/SEI-92-TR-12, 1992.

[3] CMU/SEI, "Requirement Engineering and Analysis," Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania CMU/SEI-91-TR-30, 1991.

[4] J. L. Cybulski, "Introduction to software reuse," The University of Melbourne, Department of Information Systems, Melbourne, Research Report 96/4, June 1996.

[5] J. L. Cybulski, "Reuse in the eye of its beholder: cognitive factors in software reuse," presented at OzCHI'96, Hamilton, New Zealand, 1996.

[6] J. L. Cybulski, "Reusing requirements specifications: review of methods and techniques," presented at 1st Australian Requirements Engineering Workshop, Melbourne, 1996.

[7] J. L. Cybulski and K. Reed, "A hypertext-based software engineering environment," in IEEE Software, vol. 9, 1992, pp. 62-68.

[8] J. L. Cybulski and K. Reed, "Reuse-assisted requirements engineering: the very idea," Amdahl Australian Intelligent Tools Programme, Bundoora, Vic, Australia, Technical Report December 1996.

[9] W. Frakes and S. Isoda, "Success factors of systematic reuse," in IEEE Software, 1994, pp. 15-19.

[10] P. Freeman, "Reusable software engineering: concepts and research directions," in Tutorial on Software Design Techniques, P. Freeman and A. I. Wasserman, Eds., 4 ed. Los Angeles, California: IEEE Computer Society Press, 1983, pp. 63-76.

[11] O. C. Z. Gotel and A. C. W. Finkelstein, "An analysis of the requirements traceability problem," presented at The First International Conference on Requirements Engineering, Colorado Springs, Colorado, 1994.

[12] W. L. Johnson and D. R. Harris, "Sharing and reuse of requirements knowledge," presented at 6th Annual Knowledge-Based Software Engineering Conference, Syracuse, New York, USA, 1991.

[13] K. C. Kang, S. Cohen, R. Holibaugh, J. Perry, and A. S. Peterson, "A Reuse-Based Software Development Methodology," Software Engineering Institute CMU/SEI-92-SR-4, 1992.

[14] N. Maiden and A. Sutcliffe, "The abuse or re-use: why cognitive aspects of software re-usability are important," in Software Re-use, Ultecht 1989, L. Dusink and P. Hall, Eds. London, U.K.: Springer-Verlag, 1989, pp. 109-113.

[15] Y. Matsumoto, "Some experiences in promoting reusable software: presentation in higher abstract levels," in Software Reusability: Concepts and Models, vol. 2, T. J. Biggerstaff and A. J. Perlis, Eds. New York, New York: ACM Addison Wesley Publishing Company, 1989, pp. 157-185.

[16] B. Meyer, "On formalism in specifications," in IEEE Software, 1985, pp. 6-26.

[17] S. J. Morris and A. C. W. Finkelstein, "Development of Multiple Media Documents," Imperial College, Department of Computing, Technical Report 1994.

[18] J. Poulin, "Integrated support for software reuse in computer-aided software engineering (CASE)," ACM SIGSOFT Software Engineering Notes, vol. 18, pp. 75-82, 1993.

[19] D. P. Wood, M. G. Christel, and S. M. Stevens, "A multimedia approach to requirements capture and modeling," presented at The First International Conference on Requirements Engineering, Colorado Springs, Colorado, 1994.