- Email: [email protected]
Case tool support for requirements capture and analysis
North-Holland
Microprocessing and Microprogrammlng 30 (1990) 281-288
281
CASE T O O L SUPPORT F O R R E Q U I R E M E N T S CAPTURE AND ANALYSIS
I. McChesney, D. Glass & J.G. Hughes Department of Information Systems, Institute of Informatics, University of Ulster, Jordanstown, BT37 0QB, N. Ireland. This paper assesses the support given to the requirements capture and analysis (RCA) phase of the development lifecycle by existing microcomputer based CASE (Computer Aided Software Engineering) tools. A framework is outlined within which a range of CASE tool features are presented, and benefits and criticisms of the existing technology are highlighted. Future directions for the next generation of CASE tools are suggested, with emphasis on how key features from RCA specific tools, artificial intelligence and object-oriented modelling can address existing weaknesses in automated support for RCA.
1. I N T R O D U C T I O N Approaches to developing information systems can be described by means of various lifecycle models, from the traditional monolithic lifecycle [1, 2], to more recent approaches such as prototyping [3, 4] and evolutionary delivery [5, 6]. The most predominant of these is the Waterfall lifecycle model, a typical representation of which is given in Figure 1. The stages in this representation are: • • •
planning requirements capture and analysis design
•
implementation.
• construction
In both the traditional and contemporary approaches to information system development it is widely recognised that requirements capture and analysis (RCA) is the critical stage of the lifecycle [7-11]. Errors can cost up to 100 times less to correct if they are identified at the RCA stage of development compared with the cost of correction at construction or implementation [12]. To this end various structured modelling techniques (eg. dataflows diagrams, entity modelling) have been devised to assist the systems analyst in deriving complete, correct and consistent requirements specifications. Many of these techniques have gained acceptance in the computing industry in the form of information system development methodologies such as Structured Analysis [13, 14], Jackson System Design [15], SSADM [16, 17], Information Engineering [18], and CORE [19]. While the successful uptake of these methodologies has been limited [20], their acceptance has been improved by the emergence in recent years of Computer Aided Software Engineering (CASE) tools to provide automated support for systems development. There is a great diversity of CASE tools available on the market, running on a range of hardware platforms. However, the market leaders are primarily microcomputer based, utilising the powerful capabilities of '286' and '386' based machines. This paper will assess the support given to the RCA phase of the development lifecycle by existing microcomputer based CASE tools, and suggest future
directions for the next generation of these tools. Our comments are based primarily on CASE tools for developing business information systems. With substantial overlap in the nature of the RCA process in business and real-time applications, and with many structured development techniques common to both domains, we suggest our comments are applicable to CASE tool support for real-time system development. Exceptions are those areas where the nature of the business and real-t/me system requirements may differ significantly (e.g. where formal methods are necessary for specification): in such cases the tools and techniques discussed here would not be applicable.
Plannin~g Reai4i~m&en~ na~°,~ q C---)
Constructi~ C-') Implementation Figure 1.
Waterfall life-cycle model
2. TYPES OF TOOL In this paper, a distinction will be made between tools specifically designed for RCA and the more widely used lifecycle CASE tools. RCA specific tools typically represent requirements by means of text based structured languages, and in recent years, have used knowledge based techniques for application domain verification, consistency checking and integrity
L McChesney et aL / CASE tool support for RCA
282
preservation. The key features of Artificial Intelligence which play an important role in this area are symbolic processing, knowledge-based techniques, object-oriented modelling and natural language interfaces. The aim is to enhance such tools to allow for the intelligent generation of requirements models through data and text analysis. This research therefore builds on a combination of techniques from the areas of conceptual modelling and natural language processing. Examples of RCA specific tools are PSL/PSA [21], SREM [22], Analyst Assist [11], and The Requirements Apprentice [23]. While such tools will not be addressed in our discussion we will suggest how some of their features may be included in future CASE tools. CASE tools typically represent requirements by means of graphical notation based on structured techniques for requirements modelling. RCA techniques commonly supported by CASE tools include entity-relationship diagrams [24], dataflow diagrams [ 13], prototyping, entity-life histories [16], structure charts [13], state transition diagrams [25], and action diagrams [26]. In general the level of support given is that of passive conceptual modelling i.e. the tools have no built in mechanisms to make use of application domain knowledge. Nevertheless, a comprehensive range of 'passive' techniques are available to model the process, data, temporal, and external design perspectives of an information system. Examples of microcomputer based lifecycle CASE tools are Auto-Mate Plus [27], Excelerator [28], Information Engineering Workbench (IEW) [29], Speedbuilder [30], ASSET [31], and Teamwork [32].
Tool 3
! Tool 2
I
• • • • • 3.1
text documentation support for RCA support for RCA techniques use of an application development repository consistency and completeness analysis computable requirements specifications, Text Documentation Support for RCA
At the simplest level CASE tools can assist in RCA by providing simple text documentation facilities, or by interfacing to the range of general word processing packages available. However, various IS development methodologies define structured documents for use in RCA and their accompanying CASE tools often provide parallel facilities for this. Auto-Mate Plus supports a structured document known as the Problem/Requirements List, formalised in methodologies such as SSADM. This document allows the analyst to record in a structured manner user requirements, and keep track of proposed/agreed solutions to these requirements. Standard audit fields are also provided to record document author, date, reference number, and requirement priority.
I
Tool 1
I
I
Spectrum of Sophistication
Documentation Repository Computable Support Requirements RCA Techniques Consistency/Specificati°ns Support Completeness Analysis
Figure 2.
3.2
RCA support in commercially available CASE tools
Support for RCA Techniques
The majority of RCA techniques make use of graphical notations for conceptual modelling. Such graphical notations tend to be documentation intensive, compounded by the fact that RCA itself is a highly iterative process. For this reason, it has been necessary for CASE tools to provide automated support in the form of graphical editors not only for RCA techniques but many others used in systems development. Features of these editors are:
3. S P E C T R U M O F S O P H I S T I C A T I O N To illustrate the RCA support provided by commercially available CASE tools an informal framework has been devised within which they may be presented. Our purpose in developing this framework is not to conduct a comparative evaluation of PC-based CASE tools, but to provide a context for presenting the diversity of features available. The framework can be thought of in terms of a "spectrum of sophistication" ranging from simple text documentation through to code generation from requirements specifications (Figure 2). The specific functions we have identified for discussion are:
I
• • • •
use ofamouse menu of preset of icons ability to add, modify, delete, move, and scale annotation of diagrams.
While notation and style may vary according to both technique and CASE tool being used, functionality is essentially the same across tools. 3.3
Use of an Application Development Repository
For every requirements object further detailed requirements information can be supplied to a data dictionary or application development repository. For example, in entity-relationship diagrams further detailed requirements information on entities and relationships may be supplied (eg. number of records, volatility, attributes, description). Similarly for dataflow diagrams we can further define processes, data stores, dataflows, and external agents. Such a repository is a feature of many CASE tools, allowing the collection of information not only from the requirements definition stage but all stages of the development lifecycle. We suggest that the sophistication of a CASE tool is determined by the comprehensiveness of its repository, and the degree to which RCA techniques are integram:l with this repository [33]. Figure 3 illustrates the range of integration available across three representative CASE tools: Auto-Mate Plus, Excelerator, and IEW.
I. McChesney et al. / CASE tool support for RCA
Input~l
Zira~ialcseditor ~ Data
Input "I
• ~ t a Ke[~osttory
~nitiates Auto-MatePlus Input
[ ~ Graphics t editor I Input_ Repository
I
"
Excelerator
IEW Figure
3.
Input
•1 editorGraphicsl ] "
Input
1
Repository
Integration of RCA techniques with development repository
3 . 3 . 1 Integration of RCA Techniques with Repository Three types of integration of RCA techniques with repository can be identified: loose coupling, optional coupling and tight coupling. Loose coupling, as implemented in Auto-Mate Plus, is where the graphics editors and the repository operate independently. Requirements models developed using the graphics editors are downloaded "manually" into the repository by the tool user and additional requirements details supplied directly to the repository. The downloading operation involves a validation process which checks for syntactical errors in the requirements model. If an error exists the model must be revised and reloaded - in this way the integrity of the development repository is maintained. Optional coupling allows the repository to be accessed from the graphics editor when developing requirements models without being subject to on-line validation checks. Integration of this type is implemented in Excelerator where the tool user may choose to create diagrams without entries being made in the repository, or a requirements object may be 'described' (i.e. loaded to the repository) as soon as it is added to the diagram. The validation of requirements models is performed as a separate operation, in which inconsistencies in the repository are reported. However, such an approach does not ensure the integrity of the repository as the checks are performed after the objects have been loaded. Tight coupling, as in tools such as IEW, imposes rigourous validation of requirements models during their development. In IEW an object is added to the repository as soon as it is created in a diagram. Additionally, any modifications made to an object are immediately propagated via the repository to all other instances of the object. For example, the redefinition of an attribute in a view of a system data model is reflected in all other instances of the attribute in other views and in the global data model.
283
Many of the benefits to be gained from CASE tools depend on the quality of the underlying development repository and the ability to integrate tightly with the RCA techniques employed (see section Consistency and Completeness Analysis). However, disadvantages become evident during the RCA phase of the lffecycle if tight coupling is compulsory for the tool user. Loose and optional coupling allow the development of first cut requirements models without the burden of imposed syntax rules. Such a feature is desirable during the initial stages of requirements modelling when information is being elicitated from the end user and the requirements iteratively refined. It can be frustrating to have to contend with rigourous description of requirements when rigourous understanding has not yet been achieved. If PC-based CASE tools are to be useful in RCA we suggest that "optional tight coupling' should be available, i.e. the ability to 'switch off rigourous validation for the purposes of first cut diagramming. 3 . 3 . 2 Architectures for Application Development Repositories The diversity of microcomputer based CASE tools available has resulted in a corresponding diversity of architectures for development repositories. While most CASE products provide import/export facilities to enable the transfer of repository information to third party products, the lack of standards in this area results in a complex transfer process [34, 35] which essentially locks an organisation into a particular CASE product or vendor. The lack of repository standards has been a limiting factor in the uptake of CASE, and has resulted in widespread activity by various standards bodies to devise a suitable standard definition (for example [36-39]) to the degree that standardisation of the standards will be necessary. A significant development in this respect has been the announcement by IBM of its strategic AD/Cycle (Application Development Cycle) [40], incorporating a Common Repository for the storing and sharing of application development information throughout the lifecycle. There are obvious implications for PC-based CASE tools - to survive they must conform to the emerging standards for application development. Additionally, with a standard repository in place we may see the commercial availability of more specialised tools for the purpose of requirements capture and analysis with interfacing to other lower CASE tools via the standard repository.
3 . 3 . 3 Meta-models Microcomputer based CASE tools provide immediate productivity benefits through the documentation support they provide for structured RCA techniques. In addition, the development repository gives the basis for improved system quality by providing one central dictionary for development information. The critical feature of such repositories is that development information (requirements models, requirements specifications, program and data designs, etc) is organised in a structured manner, with the relationships and interaction between objects explicitly defined by a metamodel of development information (see Figure 4). As indicated, the lack of a standard for repositories has resulted in a variety of meta-models available. Setting aside the resultant limitations of information transfer between tools, some of the models which exist are sophisticated and comprehensive in nature. The IEW repository (known as the Encyclopaedia) is based on a meta-model in excess of 150
L McChesney et aL / CASE tool support for RCA
284
object types, with over 200 relationships or 'associations' available between these types. With information organised in such a manner and subject to various rules as specified in an accompanying IS development methodology, requirements definitions and their subsequent system design models can be rigourously analysed for consistency and completeness.
I
Business Activity
executes through [Busi .... [ Activity Involves Entity Type
Entity Type
/
I [
/ through is used ~ / through \ / characterised ~ ' x
/ \
(ii) Cross Referencing Many cross referencing mechanisms can be established to ensure that different perspectives of the information system are developed in a consistent manner. In most CASE tools these mechanisms are predefmed and cater for the most commonly required permutations. At the requirements stage process/entity cross references are typically provided: a process is cross referenced to every data entity it reads or updates, and every entity is cross referenced to each of its read/update processes. Many other cross references are available entity/attribute, process/event, data store/data flow. Excelerator is one of the few PC-based CASE tools which provides a more flexible, open ended mechanism for object cross referencing. The approach adopted here is to provide a structured query language and report generator front end to the repository, allowing the tool user to extract virtually any cross reference combination between objects.
Business [ Event li d ]through I ....
I
! I I IBusinessEvent [ I Attribute I I IInvolves I I I ] l Entity Type I ,'xecutes is involved\ [ hrou2h through \ i~ used is involved~ I mrough through Activity Event Involves Involves Attribute Attribute
In addition to ensuring consistency, the ability to cross reference also supports change control functions throughout the development process. When the user requirement for a particular object or view changes, the knock on effect of such a change can be assessed in terms of the other objects which will be affected.
"
Figure
3.4
4.
View of a typical development repository meta-model
The availability of automated consistency and completeness analyses is a major factor in improving the productivity and quality of information systems development. However, without the use of knowledge based techniques and application domain knowledge, it remains the responsibility of the tool user to take action on any inconsistencies identified.
Consistency and Completeness Analysis
PC-based CASE tools typically provide a set of analyses which may be performed and reviewed by means of various reports. The range of analyses can be considered under two categories: diagram verification and cross referencing.
O) Diagram Verification Depending on the RCA technique being used various checks can be performed on the resultant diagrams. For example, dataflow diagrams can be checked for : data connectivity: determines that each data flow is connected to valid sources and destinations across all levels of the datafiow diagram. • data conservation analysis: checks that data as defined in dataflows is not leaking into or out of the system. • isolated objects: identifies objects defined to the repository but not used in any particular view or context. Basic conformance to naming and referencing conventions is also enforced, particularly by CASE tools designed to support a particular methodology. For example, Auto-Mate Plus ensures that any reference numbers used to identify objects conform to SSADM standards. In addition to syntax checking operations, such analyses may be used on completion of a requirements modelling exercise to check the model for incomplete items such as undefined data flows, attributes, and screen fields.
3.5
Computable Requirements Specifications
For a period of time programmer workbenches have been available enabling mainframe program design, construction and testing to be performed on microcomputers, and then porting the program suite ready for implementation to the target mainframe. PC-based application generators have taken this a step further enabling automatic code generation from screen designs, file definitions and detailed process logic/4GL type languages. With a suitably rigourous and tightly integrated development repository for collecting all application development information, (including requirements definitions), it is possible to produce complete and consistent requirements specifications and generate compilable source code for the target environment [41, 29]. This approach has been identified as having considerable benefits for the quality of software development and in redressing the excessively high maintenance overheads which contribute to the application development backlog [26]. PC-based CASE tools are now available which support computable requirements specifications. The converging technologies which have enabled such tools to be viable are rigourous specification techniques, relational database, expert systems, and low cost extended memory facilities for desktop microcomputers. The essential features of such a CASE tool can be illustrated by the Information Engineering Workbench.
I. McChesney et al. / CASE tool support for RCA
285 l
1
QL (DML)J
Planning
Analysis ata Structure Design J
m
elainframe
Design
Jm
Figure 5. System development from computable requirements specifications in IEW
Con sta'uction
Using the development repository to ensure consistency, the process and data perspectives of the system can be developed concurrently (Figure 5). The steps involved are outlined below.
l
Repository Manager
Figure 6.
For the process perspective: requirements axe modelled primarily using dataflow diagrams. These are refined to a sufficient level of detail until for each activity "business rules" can be specified in Action Diagrams. the relationships of the identified business procedures are then modelled by Structure Charts and defined further through more detailed Action Diagrams. the Action Diagrams are then translated to COBOL code and SQL(DML) for IBM DB2 database systems.
•
Architecture of IEW
4. BENEFITS AND C R I T I C I S M S PC-based CASE tools are no longer simply documentation aids for software development, nor are they restricted to disjoint solutions for various phases of the development lifecycle. However, the power and sophistication now available is still largely unproven, and many major issues remain to be addressed. Before identifying these, we will summarise the main points we have made so far in terms of the major benefits and criticisms of existing tools. 4.1
For the data perspective:
l Repository Manager
Benefits
a) Modern information system development methodolo-
requirements are modelled using entity-relationship diagrams and refined to complete entity-relationship-attribute models, with precise attribute definitions and relationship cardinalities.
gies carry with them the overhead of excessive and volatile documentation. CASE tools provide the essential documentation support necessary to make these methodologies viable.
the data model is translated to a relational database model [42], and relation data structures generated from the attribute definitions.
b) The use of an application development repository for
from the relational database model, full SQL(DDL) is generated.
Human intervention is necessary at various stages to supply, for example, environment specific parameters. However, IEW still automates the definition of the IBM environment features, eg. VSAM definitions, MVS Job Control Language, CICS/IMS/DC protocols. The architecture of such CASE tools is a critical feature for the support of computable requirements specifications. IEW provides a seamless repository across all stages of the development lifecycle, such that a COBOL procedure can be automatically traced back to its originating user requirement, and vice versa; (see Figure 6).
requirements completeness checking, as provided in CASE tools, will help systems developers identify errors earlier in the lifecycle, and gain the subsequent savings by reducing the occurrence of errors in the later stages of system development.
c) The lower end (design, construction) stages of the development lifecycle have advanced through various stages of automation such as high-level language compilers, fourth generation languages, and code generators. Each of these advances in software development technology have enabled automation to progress one step back up the fife,cycle - a phenomena referred to as the salmon effect [2]. Lifecycle CASE tools have seen the salmon effect reach the stages of requirements specification and system design, to the extent that computable requirements specifications are realisable (See Figure 7). Such advances may see the framework for software development radically change, resulting in a two stage process: requirements specification followed by testing [2].
L McChesney et aL / CASE too/support for RCA
286
Plannint~~g
~utomated Techniques
Construction~ CD Implementation Figure7. TheSalmonEffect 4.2
developments involving a plurality of systems analysts with concurrent access to the application development repository. Stand-alone CASE tools impose an unrealistic mode of working in such projects: requirements models, etc. developed in isolation have to be resolved manually or in 'batch' mode at periodic intervals if consistency is to be maintained. With the increasing availablity and reliability of PC LANs, multi-user CASE tools are emerging to support on-line consistency checking and preservation of repository integrity across a number of systems analysts working on the same system development.
e) As a final criticism, we observe that the printing facilities of PC-based CASE tools have not always matched the versatility of their other features. The reproduction of diagrams and reports on A4 paper is a common requirement during systems development, yet very often is not a straightforward task. The increasing use of desktop laser printers will demand the provision of more straightforward printing facilities in CASE tools.
Criticisms
The major criticisms of CASE tools relate primarily to the principles and assumptions underlying their design. a) The predominant techniques used in CASE for RCA focus on conceptual modelling. However, such techniques are often difficult to grasp by users [43], and can be confusing vehicles of communication. Attempts have been made at providing more user friendly notations: Auto-Mate Plus and Excelerator for example, support the use of organisational diagrams and presentation charts. However, these are not rigourous and are not integrated with a development repository. The next generation of tools will need to consider more appropriate ways of modelling requirements in a rigourous notation yet be comprehensible by end users; in the following section we will suggest how Artificial Intelligence may play a role in this. b) A further weakness in the underlying design of CASE tools is that they are based upon passive conceptual modelling and do not utilise any available knowledge of the application domain. The system developer possessing such knowledge has been identified as an important factor in developing high quality information systems [9]. CASE tools should be automating domain specific rules in the form of a knowledge base and providing automated support for application specific requirements analysis and design decisions. The passive nature of existing CASE tools results in such rules having to be applied manually with the resultant risk of introducing errors and developing incomplete requirements specifications. c) We would argue that CASE tools are only effective within the context of an information system development methodology. For certain organisations this can be a constraint as some CASE tools use terms, techniques and procedures which are methodology specific and do not conform to their existing development standards. d) Many of the PC-based CASE tools currently available do not operate in a networked or multi-user environment. This is unfortunate, since benefits are to be gained when using CASE on medium to large software
5 . ENHANCED CASE FEATURES FOR RCA We have identified a number of features which should be available in the next generation of microcomputer based CASE tools. There is active research being undertaken in the area of RCA specific tools and the utilisation of artificial intelligence techniques. Also, the object-oriented model is beginning to have a significant impact in the area.
5.1
AI Techniques
RCA specific tools typically represent requirements by means of text based structured languages, and in recent years they have used knowledge based techniques for application domain verification, consistency checking and integrity preservation. The key features of artificial intelligence which play an important role in this area are symbolic processing, knowledge-based techniques, object-oriented modelling and natural language interfaces. The aim is to enhance such tools to allow for the intelligent generation of requirements models through data and text analysis. This research therefore builds on a combination of techniques from the areas of conceptual data modelling and natural language processing. It is important that these enhancements are not developed in isolation but are incorporated within the lifecycle CASE tools already available and used to address the weaknesses of the existing technology. The major weakness in RCA is the communication gap between the end user and requirements analyst (Figure 8). Users talk in their own language of narrative, business goals, report layouts, and current problems. Systems analysts talk about the same issues but in their own language of entity-relationship diagrams, dataflow diagrams, process/entity matrices, etc. We suggest that emerging AI techniques should provide solutions to this communication gap by means of: • •
a rigourous requirements translator and an application domain knowledge base.
I. McChesney et al. / CASE tool support for RCA
ANALYST
USER
English
Rigourous / Intelligent Requirements ii Translator Entity Relationship Diagrams
Business Goals
Data Flow Diagrams
A Report Layouts
Entity Life Histories Current Problems
287
In an object-oriented perspective (Figure 9), the principle of aggregation is centred on the underlying data abstractions. That is, every function must be associated with a particular object, and thus functions are grouped together if they operate on the same data abstraction. In this way, objects encapsulate both state and behaviour. Functions which are constituents of a higher level process may reside in different objects and a sequence of messages (or function calls) between objects is necessary to perform a higher level process.
P r o c e s s / Entity Matrices
Object-Oriented Perspective
Figure 8.
Enhanced CASE features for RCA
• •
Identifying entities/objects and their attributes Identifying the functions to be applied to each
•
Establishing the interface each object presents
•
Implementing the objects
object to other objects
Such facilities should be incorporated within PC-based CASE tools, and utilising a robust object-oriented interface, should be accessible to the end user who may then develop requiren~nts specifications in conjunction with the systems analyst and will cross check each others understanding of the resultant system. The major bottleneck in designing systems that understand requirements expressed in natural language is the acquisition of sufficient knowledge about the domain of discourse and the expression of that knowledge in a precise and unambiguous form. Current technology in the area limits applications to narrow domains with well-defined semantics. One application area that generally meets these criteria is the development of natural language front ends for querying databases. Although databases may store large amounts of information, such information is highly structured and generally narrow in scope. In addition, the popular data models are sufficiently rigid to ensure that database semantics are well-defined. The development of natural language interfaces for requirements analysis is an appropriate extension of the work on database systems. The task is made less difficult if we have a well-defined, high-level model for the application domain knowledge. In our view the object-oriented model offers considerable advantages in this regard. 5.2
Object-Oriented Modelling
As described in Section 3.5, traditional systems development methodologies view an information system from two separate perspectives, the data perspective and the process perspective. In this traditional approach, processes are introduced to represent transformations of input data to output data and, by the principle of stepwise refinement, processes are successively decomposed into simpler subprocesses. Thus we have a principle of aggregation in which functions are grouped together if they are constituents of the same higher level function. These constituent functions may operate on different data stores. Data flow analysis thus places rather weak emphasis on the principle of data abstraction by which the functions operating on a particular data object should be encapsulated with that object. As a result the data flow technique can lead to great complexity for large systems.
Figure 9.
The object-oriented perspective
Because of the difference in aggregation principles, proceeding from a traditional structured analysis approach to an object-oriented design can be awkward. This can be avoided by adopting an object-oriented viewpoint during the RCA phase. A number of object-oriented requirements specification methods have been proposed in the literature [44]. However, little work has been done on the incorporation of such methods into CASE tools.
6. C O N C L U S I O N The ongoing advances in hardware and software technology have resulted in computerised information and control systems finding application in areas of increasing size and complexity. The requirements specification for these systems inherits many of the difficulties found in the application domain, and such requirements capture and analysis can only be successfully carried out with automated support. We have shown how existing CASE tools provide impressive support for the RCA stage of the lifecycle. However, the passive nature of such tools has been identified as a major weakness, and the use of artificial intelligence and sophisticated modelling techniques such as object oriented modelling are essential for providing the necessary automated assistance at the requirements stage. We anticipate that the further application of CASE to RCA will not only enable the development of more elaborate information systems but will increase development staff productivity. With computable requirements specifications becoming a reality, maintenance costs and overheads should also significantly decrease.
L McChesney et aL / CASE tool support for RCA
288
REFERENCES
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
[11]
[12] [13] [14] [15] [16] [17] [18] [19] [20] [21]
[22]
Boehm, B W, Software Engineering Economics, Prentice-Hail, Hemel Hempstead, UK (1981) Graham, D R 'Incremental Development' lnfo. & Softw. Tech., Vol 31, No 31 (January/February 1989) Lipp, M E (ed), State of the Art Report on Prototyping, Pergamon Infotech Ltd, Maidenhead, UK, (1986) Carey, J M, 'prototyping: alternative systems development methodology', Info. & Softw. Tech., Vol 32 No 2, (March, 1990) Gilb, T 'Evolutionary delivery versus the 'Waterfall Model", Softw. Eng. Notes, Vol 10, No 3, (1985) Gilb, T, Principles of Software Engineering Management, Addison-Wesley, Workingham, UK (1988) Shemer, I 'Systems analysis: a systematic analysis of a conceptual model' Comm. ACM, Vol 30, No 6, (June 1987) Daiy, E 'Management of software development' IEEE Trans. Softw. Eng., Vol 3, No 3, (1977) Curtis, B, Krasner, H, and Iscoe, N 'A field study of the software design process for large systems' Comm. ACM, Vol 31, No 11, (November 1988) Yeh, R T, Zave, P, Conn, A P and Cole, G E 'Software requirements: new directions and perspecfives' in Software Engineering Project Management (ed. Thayer, R H), Computer Society Press of the IEEE, Washington, (1988) Loucopoulos, P and Champion, R E M, 'Knowledge-based support for requirements engineering' Info. & Softw. Tech., Vol 31, No 3, (April, 1989) Haase, V and Koch, G 'Developing the connection between user and code', Computer, (May, 1982) Gane, C and Sarson, T, Structured Systems Analysis: Tools and Techniques, IST Databooks, New York, (1977) DeMarco, T, Structured Analysis and System Specification, Yourdon Inc, New York, (1978) Cameron, J R, 'An Overview of JSD', IEEE Trans. Softw. Eng., Vol 12, No 2, (February, 1986) Longworth, G and Nichols, D, The SSADM Manual, National Computer Centre, Manchester, UK (1987) Ashworth, C M 'Structured systems analysis and design method (SSADM)', lnfo. & Softw. Tech., Vol 30, No 6, (April, 1988) Martin, J, Information Engineering, Vols 1 and 2, Savant, Lancaster, UK (1986) The STARTS Guide, (2nd edition), NCC Publications, UK (1987) Wilson, D N, 'CASE: guidelines for success', lnfo. & Softw. Tech., Vol 31, No 7, (September, 1989) Teichroew, D and Hershey, E A, 'PSI./PSA: a computer aided technique for structured documentation and analysis of information processing systems', IEEE Trans. Softw. Eng., Vol 3, No 1, (1977) Alford, M, 'A requirements engineering methodology for real-time processing requirements', IEEE Trans. Softw. Eng., Vol 3, No 1, (1977)
[23] Rich, C, Waters, R, and Reubenstein, H, 'Toward a Requirements Apprentice', in Proc. 4th International Workshop on Software Specification and Design, pp 79-86, IEEE Computer Society Press, April 1987. [24] Chen, P, 'The entity-relationship model - toward a unified view of data', ACM Trans. Database Systems, Vol 1, No 1, (1976) [25] Ward, P T and Mellor, S J, Structured development for real-time systems, Yourdon Press, New York, (1985) [26] Martin, J and McClure, C, Structured Techniques: The Basis for CASE, Prentice-Hall, Englewood Cliffs, NJ, (1988) pp 245-274 [27] Auto-Mate Plus, Learmonth and Burchett Management Systems (LBMS) Pie, Evelyn House, 62 Oxford Street, London, UK [28] Excelerator, Index Technology Corporation, 1 Main Street, Cambridge, MA 02142-1585, USA [29] Information Engineering Workbench, KnowledgeWare Inc., 3340 Peachtree Road N.E., Atlanta, GA 30026, USA [30] Speedbuilder, Michael Jackson Systems Ltd, 22 Little Portland Street, London W1N 5AF [31] ASSET, AIMS Systems, 314-316 Harbour Yard, Chelsea Harbour, London SW10 0XD [32] TEAMWORK, Cadre Technologies, 222 Richmond Street, Providence, RI 02903. [33] Crozier, M, Glass, D, Hughes, J G, Johnston, W and McChesney, I, 'Critical analysis of tools for computer-aided software engineering', Info. & Softw. Tech., Vol 31 No 9, (November, 1989) [34] Humphries, G, 'Data migration between analyst workbenches', Internal Report, Dept Information Systems, University of Ulster, March 1990. [35] Thompson, A, K, The UK CASE Market, Internal Report, Institute of Software Engineering, Belfast, (November, 1989) [36] ISO IRDS (Information Resource Data System), Draft International Standard (DIS 10027) [37] ANSI IRDS flnformation Resource Data System) [38] CDIF (Common Data Interchange Format), EIA (Electronic Industries Association) [39] ATIS (A Tools Integrating Standard), Digital Equipment Corporation [40] Application Development Announcement Summary, IBM, (September, 1989) [41] MacDonald, I G, 'Automating the Information Engineering Methodology with the Information Engineering Facility', in Computerised Assistance during the Information Systems Life-Cycle (eds Olle, T W, Verrijn-Stuart, A A, and Bhabuta, I), NorthHolland, Amsterdam, (1988) [42] Hughes, J G, Database Technology: A Software Engineering Approach, Prentice-Hall, Hemel Hempstead, UK (1988) [43] Crozier, M and Glass, D 'When conceptual modelling fails', Internal Report, Dept Information Systems, University of Ulster, (December, 1989) [44] Booch, G., 'Object-oriented development', IEEE Trans. Softw. Eng., Vol. SE-12, (Feb. 1986)
Microprocessing and Microprogrammlng 30 (1990) 281-288
281
CASE T O O L SUPPORT F O R R E Q U I R E M E N T S CAPTURE AND ANALYSIS
I. McChesney, D. Glass & J.G. Hughes Department of Information Systems, Institute of Informatics, University of Ulster, Jordanstown, BT37 0QB, N. Ireland. This paper assesses the support given to the requirements capture and analysis (RCA) phase of the development lifecycle by existing microcomputer based CASE (Computer Aided Software Engineering) tools. A framework is outlined within which a range of CASE tool features are presented, and benefits and criticisms of the existing technology are highlighted. Future directions for the next generation of CASE tools are suggested, with emphasis on how key features from RCA specific tools, artificial intelligence and object-oriented modelling can address existing weaknesses in automated support for RCA.
1. I N T R O D U C T I O N Approaches to developing information systems can be described by means of various lifecycle models, from the traditional monolithic lifecycle [1, 2], to more recent approaches such as prototyping [3, 4] and evolutionary delivery [5, 6]. The most predominant of these is the Waterfall lifecycle model, a typical representation of which is given in Figure 1. The stages in this representation are: • • •
planning requirements capture and analysis design
•
implementation.
• construction
In both the traditional and contemporary approaches to information system development it is widely recognised that requirements capture and analysis (RCA) is the critical stage of the lifecycle [7-11]. Errors can cost up to 100 times less to correct if they are identified at the RCA stage of development compared with the cost of correction at construction or implementation [12]. To this end various structured modelling techniques (eg. dataflows diagrams, entity modelling) have been devised to assist the systems analyst in deriving complete, correct and consistent requirements specifications. Many of these techniques have gained acceptance in the computing industry in the form of information system development methodologies such as Structured Analysis [13, 14], Jackson System Design [15], SSADM [16, 17], Information Engineering [18], and CORE [19]. While the successful uptake of these methodologies has been limited [20], their acceptance has been improved by the emergence in recent years of Computer Aided Software Engineering (CASE) tools to provide automated support for systems development. There is a great diversity of CASE tools available on the market, running on a range of hardware platforms. However, the market leaders are primarily microcomputer based, utilising the powerful capabilities of '286' and '386' based machines. This paper will assess the support given to the RCA phase of the development lifecycle by existing microcomputer based CASE tools, and suggest future
directions for the next generation of these tools. Our comments are based primarily on CASE tools for developing business information systems. With substantial overlap in the nature of the RCA process in business and real-time applications, and with many structured development techniques common to both domains, we suggest our comments are applicable to CASE tool support for real-time system development. Exceptions are those areas where the nature of the business and real-t/me system requirements may differ significantly (e.g. where formal methods are necessary for specification): in such cases the tools and techniques discussed here would not be applicable.
Plannin~g Reai4i~m&en~ na~°,~ q C---)
Constructi~ C-') Implementation Figure 1.
Waterfall life-cycle model
2. TYPES OF TOOL In this paper, a distinction will be made between tools specifically designed for RCA and the more widely used lifecycle CASE tools. RCA specific tools typically represent requirements by means of text based structured languages, and in recent years, have used knowledge based techniques for application domain verification, consistency checking and integrity
L McChesney et aL / CASE tool support for RCA
282
preservation. The key features of Artificial Intelligence which play an important role in this area are symbolic processing, knowledge-based techniques, object-oriented modelling and natural language interfaces. The aim is to enhance such tools to allow for the intelligent generation of requirements models through data and text analysis. This research therefore builds on a combination of techniques from the areas of conceptual modelling and natural language processing. Examples of RCA specific tools are PSL/PSA [21], SREM [22], Analyst Assist [11], and The Requirements Apprentice [23]. While such tools will not be addressed in our discussion we will suggest how some of their features may be included in future CASE tools. CASE tools typically represent requirements by means of graphical notation based on structured techniques for requirements modelling. RCA techniques commonly supported by CASE tools include entity-relationship diagrams [24], dataflow diagrams [ 13], prototyping, entity-life histories [16], structure charts [13], state transition diagrams [25], and action diagrams [26]. In general the level of support given is that of passive conceptual modelling i.e. the tools have no built in mechanisms to make use of application domain knowledge. Nevertheless, a comprehensive range of 'passive' techniques are available to model the process, data, temporal, and external design perspectives of an information system. Examples of microcomputer based lifecycle CASE tools are Auto-Mate Plus [27], Excelerator [28], Information Engineering Workbench (IEW) [29], Speedbuilder [30], ASSET [31], and Teamwork [32].
Tool 3
! Tool 2
I
• • • • • 3.1
text documentation support for RCA support for RCA techniques use of an application development repository consistency and completeness analysis computable requirements specifications, Text Documentation Support for RCA
At the simplest level CASE tools can assist in RCA by providing simple text documentation facilities, or by interfacing to the range of general word processing packages available. However, various IS development methodologies define structured documents for use in RCA and their accompanying CASE tools often provide parallel facilities for this. Auto-Mate Plus supports a structured document known as the Problem/Requirements List, formalised in methodologies such as SSADM. This document allows the analyst to record in a structured manner user requirements, and keep track of proposed/agreed solutions to these requirements. Standard audit fields are also provided to record document author, date, reference number, and requirement priority.
I
Tool 1
I
I
Spectrum of Sophistication
Documentation Repository Computable Support Requirements RCA Techniques Consistency/Specificati°ns Support Completeness Analysis
Figure 2.
3.2
RCA support in commercially available CASE tools
Support for RCA Techniques
The majority of RCA techniques make use of graphical notations for conceptual modelling. Such graphical notations tend to be documentation intensive, compounded by the fact that RCA itself is a highly iterative process. For this reason, it has been necessary for CASE tools to provide automated support in the form of graphical editors not only for RCA techniques but many others used in systems development. Features of these editors are:
3. S P E C T R U M O F S O P H I S T I C A T I O N To illustrate the RCA support provided by commercially available CASE tools an informal framework has been devised within which they may be presented. Our purpose in developing this framework is not to conduct a comparative evaluation of PC-based CASE tools, but to provide a context for presenting the diversity of features available. The framework can be thought of in terms of a "spectrum of sophistication" ranging from simple text documentation through to code generation from requirements specifications (Figure 2). The specific functions we have identified for discussion are:
I
• • • •
use ofamouse menu of preset of icons ability to add, modify, delete, move, and scale annotation of diagrams.
While notation and style may vary according to both technique and CASE tool being used, functionality is essentially the same across tools. 3.3
Use of an Application Development Repository
For every requirements object further detailed requirements information can be supplied to a data dictionary or application development repository. For example, in entity-relationship diagrams further detailed requirements information on entities and relationships may be supplied (eg. number of records, volatility, attributes, description). Similarly for dataflow diagrams we can further define processes, data stores, dataflows, and external agents. Such a repository is a feature of many CASE tools, allowing the collection of information not only from the requirements definition stage but all stages of the development lifecycle. We suggest that the sophistication of a CASE tool is determined by the comprehensiveness of its repository, and the degree to which RCA techniques are integram:l with this repository [33]. Figure 3 illustrates the range of integration available across three representative CASE tools: Auto-Mate Plus, Excelerator, and IEW.
I. McChesney et al. / CASE tool support for RCA
Input~l
Zira~ialcseditor ~ Data
Input "I
• ~ t a Ke[~osttory
~nitiates Auto-MatePlus Input
[ ~ Graphics t editor I Input_ Repository
I
"
Excelerator
IEW Figure
3.
Input
•1 editorGraphicsl ] "
Input
1
Repository
Integration of RCA techniques with development repository
3 . 3 . 1 Integration of RCA Techniques with Repository Three types of integration of RCA techniques with repository can be identified: loose coupling, optional coupling and tight coupling. Loose coupling, as implemented in Auto-Mate Plus, is where the graphics editors and the repository operate independently. Requirements models developed using the graphics editors are downloaded "manually" into the repository by the tool user and additional requirements details supplied directly to the repository. The downloading operation involves a validation process which checks for syntactical errors in the requirements model. If an error exists the model must be revised and reloaded - in this way the integrity of the development repository is maintained. Optional coupling allows the repository to be accessed from the graphics editor when developing requirements models without being subject to on-line validation checks. Integration of this type is implemented in Excelerator where the tool user may choose to create diagrams without entries being made in the repository, or a requirements object may be 'described' (i.e. loaded to the repository) as soon as it is added to the diagram. The validation of requirements models is performed as a separate operation, in which inconsistencies in the repository are reported. However, such an approach does not ensure the integrity of the repository as the checks are performed after the objects have been loaded. Tight coupling, as in tools such as IEW, imposes rigourous validation of requirements models during their development. In IEW an object is added to the repository as soon as it is created in a diagram. Additionally, any modifications made to an object are immediately propagated via the repository to all other instances of the object. For example, the redefinition of an attribute in a view of a system data model is reflected in all other instances of the attribute in other views and in the global data model.
283
Many of the benefits to be gained from CASE tools depend on the quality of the underlying development repository and the ability to integrate tightly with the RCA techniques employed (see section Consistency and Completeness Analysis). However, disadvantages become evident during the RCA phase of the lffecycle if tight coupling is compulsory for the tool user. Loose and optional coupling allow the development of first cut requirements models without the burden of imposed syntax rules. Such a feature is desirable during the initial stages of requirements modelling when information is being elicitated from the end user and the requirements iteratively refined. It can be frustrating to have to contend with rigourous description of requirements when rigourous understanding has not yet been achieved. If PC-based CASE tools are to be useful in RCA we suggest that "optional tight coupling' should be available, i.e. the ability to 'switch off rigourous validation for the purposes of first cut diagramming. 3 . 3 . 2 Architectures for Application Development Repositories The diversity of microcomputer based CASE tools available has resulted in a corresponding diversity of architectures for development repositories. While most CASE products provide import/export facilities to enable the transfer of repository information to third party products, the lack of standards in this area results in a complex transfer process [34, 35] which essentially locks an organisation into a particular CASE product or vendor. The lack of repository standards has been a limiting factor in the uptake of CASE, and has resulted in widespread activity by various standards bodies to devise a suitable standard definition (for example [36-39]) to the degree that standardisation of the standards will be necessary. A significant development in this respect has been the announcement by IBM of its strategic AD/Cycle (Application Development Cycle) [40], incorporating a Common Repository for the storing and sharing of application development information throughout the lifecycle. There are obvious implications for PC-based CASE tools - to survive they must conform to the emerging standards for application development. Additionally, with a standard repository in place we may see the commercial availability of more specialised tools for the purpose of requirements capture and analysis with interfacing to other lower CASE tools via the standard repository.
3 . 3 . 3 Meta-models Microcomputer based CASE tools provide immediate productivity benefits through the documentation support they provide for structured RCA techniques. In addition, the development repository gives the basis for improved system quality by providing one central dictionary for development information. The critical feature of such repositories is that development information (requirements models, requirements specifications, program and data designs, etc) is organised in a structured manner, with the relationships and interaction between objects explicitly defined by a metamodel of development information (see Figure 4). As indicated, the lack of a standard for repositories has resulted in a variety of meta-models available. Setting aside the resultant limitations of information transfer between tools, some of the models which exist are sophisticated and comprehensive in nature. The IEW repository (known as the Encyclopaedia) is based on a meta-model in excess of 150
L McChesney et aL / CASE tool support for RCA
284
object types, with over 200 relationships or 'associations' available between these types. With information organised in such a manner and subject to various rules as specified in an accompanying IS development methodology, requirements definitions and their subsequent system design models can be rigourously analysed for consistency and completeness.
I
Business Activity
executes through [Busi .... [ Activity Involves Entity Type
Entity Type
/
I [
/ through is used ~ / through \ / characterised ~ ' x
/ \
(ii) Cross Referencing Many cross referencing mechanisms can be established to ensure that different perspectives of the information system are developed in a consistent manner. In most CASE tools these mechanisms are predefmed and cater for the most commonly required permutations. At the requirements stage process/entity cross references are typically provided: a process is cross referenced to every data entity it reads or updates, and every entity is cross referenced to each of its read/update processes. Many other cross references are available entity/attribute, process/event, data store/data flow. Excelerator is one of the few PC-based CASE tools which provides a more flexible, open ended mechanism for object cross referencing. The approach adopted here is to provide a structured query language and report generator front end to the repository, allowing the tool user to extract virtually any cross reference combination between objects.
Business [ Event li d ]through I ....
I
! I I IBusinessEvent [ I Attribute I I IInvolves I I I ] l Entity Type I ,'xecutes is involved\ [ hrou2h through \ i~ used is involved~ I mrough through Activity Event Involves Involves Attribute Attribute
In addition to ensuring consistency, the ability to cross reference also supports change control functions throughout the development process. When the user requirement for a particular object or view changes, the knock on effect of such a change can be assessed in terms of the other objects which will be affected.
"
Figure
3.4
4.
View of a typical development repository meta-model
The availability of automated consistency and completeness analyses is a major factor in improving the productivity and quality of information systems development. However, without the use of knowledge based techniques and application domain knowledge, it remains the responsibility of the tool user to take action on any inconsistencies identified.
Consistency and Completeness Analysis
PC-based CASE tools typically provide a set of analyses which may be performed and reviewed by means of various reports. The range of analyses can be considered under two categories: diagram verification and cross referencing.
O) Diagram Verification Depending on the RCA technique being used various checks can be performed on the resultant diagrams. For example, dataflow diagrams can be checked for : data connectivity: determines that each data flow is connected to valid sources and destinations across all levels of the datafiow diagram. • data conservation analysis: checks that data as defined in dataflows is not leaking into or out of the system. • isolated objects: identifies objects defined to the repository but not used in any particular view or context. Basic conformance to naming and referencing conventions is also enforced, particularly by CASE tools designed to support a particular methodology. For example, Auto-Mate Plus ensures that any reference numbers used to identify objects conform to SSADM standards. In addition to syntax checking operations, such analyses may be used on completion of a requirements modelling exercise to check the model for incomplete items such as undefined data flows, attributes, and screen fields.
3.5
Computable Requirements Specifications
For a period of time programmer workbenches have been available enabling mainframe program design, construction and testing to be performed on microcomputers, and then porting the program suite ready for implementation to the target mainframe. PC-based application generators have taken this a step further enabling automatic code generation from screen designs, file definitions and detailed process logic/4GL type languages. With a suitably rigourous and tightly integrated development repository for collecting all application development information, (including requirements definitions), it is possible to produce complete and consistent requirements specifications and generate compilable source code for the target environment [41, 29]. This approach has been identified as having considerable benefits for the quality of software development and in redressing the excessively high maintenance overheads which contribute to the application development backlog [26]. PC-based CASE tools are now available which support computable requirements specifications. The converging technologies which have enabled such tools to be viable are rigourous specification techniques, relational database, expert systems, and low cost extended memory facilities for desktop microcomputers. The essential features of such a CASE tool can be illustrated by the Information Engineering Workbench.
I. McChesney et al. / CASE tool support for RCA
285 l
1
QL (DML)J
Planning
Analysis ata Structure Design J
m
elainframe
Design
Jm
Figure 5. System development from computable requirements specifications in IEW
Con sta'uction
Using the development repository to ensure consistency, the process and data perspectives of the system can be developed concurrently (Figure 5). The steps involved are outlined below.
l
Repository Manager
Figure 6.
For the process perspective: requirements axe modelled primarily using dataflow diagrams. These are refined to a sufficient level of detail until for each activity "business rules" can be specified in Action Diagrams. the relationships of the identified business procedures are then modelled by Structure Charts and defined further through more detailed Action Diagrams. the Action Diagrams are then translated to COBOL code and SQL(DML) for IBM DB2 database systems.
•
Architecture of IEW
4. BENEFITS AND C R I T I C I S M S PC-based CASE tools are no longer simply documentation aids for software development, nor are they restricted to disjoint solutions for various phases of the development lifecycle. However, the power and sophistication now available is still largely unproven, and many major issues remain to be addressed. Before identifying these, we will summarise the main points we have made so far in terms of the major benefits and criticisms of existing tools. 4.1
For the data perspective:
l Repository Manager
Benefits
a) Modern information system development methodolo-
requirements are modelled using entity-relationship diagrams and refined to complete entity-relationship-attribute models, with precise attribute definitions and relationship cardinalities.
gies carry with them the overhead of excessive and volatile documentation. CASE tools provide the essential documentation support necessary to make these methodologies viable.
the data model is translated to a relational database model [42], and relation data structures generated from the attribute definitions.
b) The use of an application development repository for
from the relational database model, full SQL(DDL) is generated.
Human intervention is necessary at various stages to supply, for example, environment specific parameters. However, IEW still automates the definition of the IBM environment features, eg. VSAM definitions, MVS Job Control Language, CICS/IMS/DC protocols. The architecture of such CASE tools is a critical feature for the support of computable requirements specifications. IEW provides a seamless repository across all stages of the development lifecycle, such that a COBOL procedure can be automatically traced back to its originating user requirement, and vice versa; (see Figure 6).
requirements completeness checking, as provided in CASE tools, will help systems developers identify errors earlier in the lifecycle, and gain the subsequent savings by reducing the occurrence of errors in the later stages of system development.
c) The lower end (design, construction) stages of the development lifecycle have advanced through various stages of automation such as high-level language compilers, fourth generation languages, and code generators. Each of these advances in software development technology have enabled automation to progress one step back up the fife,cycle - a phenomena referred to as the salmon effect [2]. Lifecycle CASE tools have seen the salmon effect reach the stages of requirements specification and system design, to the extent that computable requirements specifications are realisable (See Figure 7). Such advances may see the framework for software development radically change, resulting in a two stage process: requirements specification followed by testing [2].
L McChesney et aL / CASE too/support for RCA
286
Plannint~~g
~utomated Techniques
Construction~ CD Implementation Figure7. TheSalmonEffect 4.2
developments involving a plurality of systems analysts with concurrent access to the application development repository. Stand-alone CASE tools impose an unrealistic mode of working in such projects: requirements models, etc. developed in isolation have to be resolved manually or in 'batch' mode at periodic intervals if consistency is to be maintained. With the increasing availablity and reliability of PC LANs, multi-user CASE tools are emerging to support on-line consistency checking and preservation of repository integrity across a number of systems analysts working on the same system development.
e) As a final criticism, we observe that the printing facilities of PC-based CASE tools have not always matched the versatility of their other features. The reproduction of diagrams and reports on A4 paper is a common requirement during systems development, yet very often is not a straightforward task. The increasing use of desktop laser printers will demand the provision of more straightforward printing facilities in CASE tools.
Criticisms
The major criticisms of CASE tools relate primarily to the principles and assumptions underlying their design. a) The predominant techniques used in CASE for RCA focus on conceptual modelling. However, such techniques are often difficult to grasp by users [43], and can be confusing vehicles of communication. Attempts have been made at providing more user friendly notations: Auto-Mate Plus and Excelerator for example, support the use of organisational diagrams and presentation charts. However, these are not rigourous and are not integrated with a development repository. The next generation of tools will need to consider more appropriate ways of modelling requirements in a rigourous notation yet be comprehensible by end users; in the following section we will suggest how Artificial Intelligence may play a role in this. b) A further weakness in the underlying design of CASE tools is that they are based upon passive conceptual modelling and do not utilise any available knowledge of the application domain. The system developer possessing such knowledge has been identified as an important factor in developing high quality information systems [9]. CASE tools should be automating domain specific rules in the form of a knowledge base and providing automated support for application specific requirements analysis and design decisions. The passive nature of existing CASE tools results in such rules having to be applied manually with the resultant risk of introducing errors and developing incomplete requirements specifications. c) We would argue that CASE tools are only effective within the context of an information system development methodology. For certain organisations this can be a constraint as some CASE tools use terms, techniques and procedures which are methodology specific and do not conform to their existing development standards. d) Many of the PC-based CASE tools currently available do not operate in a networked or multi-user environment. This is unfortunate, since benefits are to be gained when using CASE on medium to large software
5 . ENHANCED CASE FEATURES FOR RCA We have identified a number of features which should be available in the next generation of microcomputer based CASE tools. There is active research being undertaken in the area of RCA specific tools and the utilisation of artificial intelligence techniques. Also, the object-oriented model is beginning to have a significant impact in the area.
5.1
AI Techniques
RCA specific tools typically represent requirements by means of text based structured languages, and in recent years they have used knowledge based techniques for application domain verification, consistency checking and integrity preservation. The key features of artificial intelligence which play an important role in this area are symbolic processing, knowledge-based techniques, object-oriented modelling and natural language interfaces. The aim is to enhance such tools to allow for the intelligent generation of requirements models through data and text analysis. This research therefore builds on a combination of techniques from the areas of conceptual data modelling and natural language processing. It is important that these enhancements are not developed in isolation but are incorporated within the lifecycle CASE tools already available and used to address the weaknesses of the existing technology. The major weakness in RCA is the communication gap between the end user and requirements analyst (Figure 8). Users talk in their own language of narrative, business goals, report layouts, and current problems. Systems analysts talk about the same issues but in their own language of entity-relationship diagrams, dataflow diagrams, process/entity matrices, etc. We suggest that emerging AI techniques should provide solutions to this communication gap by means of: • •
a rigourous requirements translator and an application domain knowledge base.
I. McChesney et al. / CASE tool support for RCA
ANALYST
USER
English
Rigourous / Intelligent Requirements ii Translator Entity Relationship Diagrams
Business Goals
Data Flow Diagrams
A Report Layouts
Entity Life Histories Current Problems
287
In an object-oriented perspective (Figure 9), the principle of aggregation is centred on the underlying data abstractions. That is, every function must be associated with a particular object, and thus functions are grouped together if they operate on the same data abstraction. In this way, objects encapsulate both state and behaviour. Functions which are constituents of a higher level process may reside in different objects and a sequence of messages (or function calls) between objects is necessary to perform a higher level process.
P r o c e s s / Entity Matrices
Object-Oriented Perspective
Figure 8.
Enhanced CASE features for RCA
• •
Identifying entities/objects and their attributes Identifying the functions to be applied to each
•
Establishing the interface each object presents
•
Implementing the objects
object to other objects
Such facilities should be incorporated within PC-based CASE tools, and utilising a robust object-oriented interface, should be accessible to the end user who may then develop requiren~nts specifications in conjunction with the systems analyst and will cross check each others understanding of the resultant system. The major bottleneck in designing systems that understand requirements expressed in natural language is the acquisition of sufficient knowledge about the domain of discourse and the expression of that knowledge in a precise and unambiguous form. Current technology in the area limits applications to narrow domains with well-defined semantics. One application area that generally meets these criteria is the development of natural language front ends for querying databases. Although databases may store large amounts of information, such information is highly structured and generally narrow in scope. In addition, the popular data models are sufficiently rigid to ensure that database semantics are well-defined. The development of natural language interfaces for requirements analysis is an appropriate extension of the work on database systems. The task is made less difficult if we have a well-defined, high-level model for the application domain knowledge. In our view the object-oriented model offers considerable advantages in this regard. 5.2
Object-Oriented Modelling
As described in Section 3.5, traditional systems development methodologies view an information system from two separate perspectives, the data perspective and the process perspective. In this traditional approach, processes are introduced to represent transformations of input data to output data and, by the principle of stepwise refinement, processes are successively decomposed into simpler subprocesses. Thus we have a principle of aggregation in which functions are grouped together if they are constituents of the same higher level function. These constituent functions may operate on different data stores. Data flow analysis thus places rather weak emphasis on the principle of data abstraction by which the functions operating on a particular data object should be encapsulated with that object. As a result the data flow technique can lead to great complexity for large systems.
Figure 9.
The object-oriented perspective
Because of the difference in aggregation principles, proceeding from a traditional structured analysis approach to an object-oriented design can be awkward. This can be avoided by adopting an object-oriented viewpoint during the RCA phase. A number of object-oriented requirements specification methods have been proposed in the literature [44]. However, little work has been done on the incorporation of such methods into CASE tools.
6. C O N C L U S I O N The ongoing advances in hardware and software technology have resulted in computerised information and control systems finding application in areas of increasing size and complexity. The requirements specification for these systems inherits many of the difficulties found in the application domain, and such requirements capture and analysis can only be successfully carried out with automated support. We have shown how existing CASE tools provide impressive support for the RCA stage of the lifecycle. However, the passive nature of such tools has been identified as a major weakness, and the use of artificial intelligence and sophisticated modelling techniques such as object oriented modelling are essential for providing the necessary automated assistance at the requirements stage. We anticipate that the further application of CASE to RCA will not only enable the development of more elaborate information systems but will increase development staff productivity. With computable requirements specifications becoming a reality, maintenance costs and overheads should also significantly decrease.
L McChesney et aL / CASE tool support for RCA
288
REFERENCES
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
[11]
[12] [13] [14] [15] [16] [17] [18] [19] [20] [21]
[22]
Boehm, B W, Software Engineering Economics, Prentice-Hail, Hemel Hempstead, UK (1981) Graham, D R 'Incremental Development' lnfo. & Softw. Tech., Vol 31, No 31 (January/February 1989) Lipp, M E (ed), State of the Art Report on Prototyping, Pergamon Infotech Ltd, Maidenhead, UK, (1986) Carey, J M, 'prototyping: alternative systems development methodology', Info. & Softw. Tech., Vol 32 No 2, (March, 1990) Gilb, T 'Evolutionary delivery versus the 'Waterfall Model", Softw. Eng. Notes, Vol 10, No 3, (1985) Gilb, T, Principles of Software Engineering Management, Addison-Wesley, Workingham, UK (1988) Shemer, I 'Systems analysis: a systematic analysis of a conceptual model' Comm. ACM, Vol 30, No 6, (June 1987) Daiy, E 'Management of software development' IEEE Trans. Softw. Eng., Vol 3, No 3, (1977) Curtis, B, Krasner, H, and Iscoe, N 'A field study of the software design process for large systems' Comm. ACM, Vol 31, No 11, (November 1988) Yeh, R T, Zave, P, Conn, A P and Cole, G E 'Software requirements: new directions and perspecfives' in Software Engineering Project Management (ed. Thayer, R H), Computer Society Press of the IEEE, Washington, (1988) Loucopoulos, P and Champion, R E M, 'Knowledge-based support for requirements engineering' Info. & Softw. Tech., Vol 31, No 3, (April, 1989) Haase, V and Koch, G 'Developing the connection between user and code', Computer, (May, 1982) Gane, C and Sarson, T, Structured Systems Analysis: Tools and Techniques, IST Databooks, New York, (1977) DeMarco, T, Structured Analysis and System Specification, Yourdon Inc, New York, (1978) Cameron, J R, 'An Overview of JSD', IEEE Trans. Softw. Eng., Vol 12, No 2, (February, 1986) Longworth, G and Nichols, D, The SSADM Manual, National Computer Centre, Manchester, UK (1987) Ashworth, C M 'Structured systems analysis and design method (SSADM)', lnfo. & Softw. Tech., Vol 30, No 6, (April, 1988) Martin, J, Information Engineering, Vols 1 and 2, Savant, Lancaster, UK (1986) The STARTS Guide, (2nd edition), NCC Publications, UK (1987) Wilson, D N, 'CASE: guidelines for success', lnfo. & Softw. Tech., Vol 31, No 7, (September, 1989) Teichroew, D and Hershey, E A, 'PSI./PSA: a computer aided technique for structured documentation and analysis of information processing systems', IEEE Trans. Softw. Eng., Vol 3, No 1, (1977) Alford, M, 'A requirements engineering methodology for real-time processing requirements', IEEE Trans. Softw. Eng., Vol 3, No 1, (1977)
[23] Rich, C, Waters, R, and Reubenstein, H, 'Toward a Requirements Apprentice', in Proc. 4th International Workshop on Software Specification and Design, pp 79-86, IEEE Computer Society Press, April 1987. [24] Chen, P, 'The entity-relationship model - toward a unified view of data', ACM Trans. Database Systems, Vol 1, No 1, (1976) [25] Ward, P T and Mellor, S J, Structured development for real-time systems, Yourdon Press, New York, (1985) [26] Martin, J and McClure, C, Structured Techniques: The Basis for CASE, Prentice-Hall, Englewood Cliffs, NJ, (1988) pp 245-274 [27] Auto-Mate Plus, Learmonth and Burchett Management Systems (LBMS) Pie, Evelyn House, 62 Oxford Street, London, UK [28] Excelerator, Index Technology Corporation, 1 Main Street, Cambridge, MA 02142-1585, USA [29] Information Engineering Workbench, KnowledgeWare Inc., 3340 Peachtree Road N.E., Atlanta, GA 30026, USA [30] Speedbuilder, Michael Jackson Systems Ltd, 22 Little Portland Street, London W1N 5AF [31] ASSET, AIMS Systems, 314-316 Harbour Yard, Chelsea Harbour, London SW10 0XD [32] TEAMWORK, Cadre Technologies, 222 Richmond Street, Providence, RI 02903. [33] Crozier, M, Glass, D, Hughes, J G, Johnston, W and McChesney, I, 'Critical analysis of tools for computer-aided software engineering', Info. & Softw. Tech., Vol 31 No 9, (November, 1989) [34] Humphries, G, 'Data migration between analyst workbenches', Internal Report, Dept Information Systems, University of Ulster, March 1990. [35] Thompson, A, K, The UK CASE Market, Internal Report, Institute of Software Engineering, Belfast, (November, 1989) [36] ISO IRDS (Information Resource Data System), Draft International Standard (DIS 10027) [37] ANSI IRDS flnformation Resource Data System) [38] CDIF (Common Data Interchange Format), EIA (Electronic Industries Association) [39] ATIS (A Tools Integrating Standard), Digital Equipment Corporation [40] Application Development Announcement Summary, IBM, (September, 1989) [41] MacDonald, I G, 'Automating the Information Engineering Methodology with the Information Engineering Facility', in Computerised Assistance during the Information Systems Life-Cycle (eds Olle, T W, Verrijn-Stuart, A A, and Bhabuta, I), NorthHolland, Amsterdam, (1988) [42] Hughes, J G, Database Technology: A Software Engineering Approach, Prentice-Hall, Hemel Hempstead, UK (1988) [43] Crozier, M and Glass, D 'When conceptual modelling fails', Internal Report, Dept Information Systems, University of Ulster, (December, 1989) [44] Booch, G., 'Object-oriented development', IEEE Trans. Softw. Eng., Vol. SE-12, (Feb. 1986)