- Email: [email protected]
Knowledge-based support for requirements engineering
Knowledge-based support for requirements engineering P Loucopoulos and R E M Champion
The accurate capture and representation of user requirements plays a critical role in the construction of effective and flexible information systems. Despite the introduction of development methods and CASE tools in the project life-cycle, the process of developing a requirements specification remains problematical. The paper proposes that the process of requirements specification should be considered from a viewpoint that is close to an analyst's cognitive processes. To this end the paper presents a requirements specification support environment that is based on the premise that it is advantageous to carry out modelling at the early stages of development independent of any particular software engineering method. This support environment, known as the Analyst Assist system, exploits knowledge-based paradigms for the capture and modelling of facts about an application domain, which are then transformed into a functional specification represented in the Jackson System Development method. information systems, systems development methods, requirements engineering, knowledge-based environments
In recent years there has been a growing realisation that the development of large information systems is becoming increasingly more difficult as user requirements become broader and more sophisticated. The complexity that is exhibited by most contemporary application domains and the subsequent problem of developing automated information systems for these domains has proved that the traditional, informal approach to development (as shown in Figure l(a)) is no longer feasible. The gap between the initial statement for the requirement of an automated information and its eventual implementation is far too great for this approach to be feasible. Obviously, there is a need for a discipline that establishes the appropriate procedures for managing large development teams within a systematic framework that recognises well identified tasks and milestones. The major response to such a need has been the emergence of a number of system development methods, each consisting of metamodels for system representation, a process by which to construct specifications and a set of computer-assisted Department of Computation, UMIST, PO Box 88, Manchester, M60 IQD, UK vol 31 no 3 april 1 9 8 9
software engineering (CASE) tools to aid development ~-3. Examples of such methods are Information Engineering 4, JSD 5, NIAM 6, SADT 7, SASD s, STRADIS 9, and a plethora of other more or less similar methods (see Layzell and Loucopoulos ~° for a bibliography). These methods and associated CASE tools pay particular attention to the construction of a high-level specification of a system before this system is developed. This is shown in Figure l(b) as the 'system specification' component. Such a component normally contains a functional specification of the intended information system. Despite the increasing use of these methods and the undisputed advantages that these methods bring to the management of a project, however, users continue to experience major difficulties~~. It has often been reported that over 50% of software malfunctions have their origin in the process of requirements capture, although the effect is not detected until later stages, giving rise to a figure of 80% of personnel resources being committed to the debugging and testing of source code 12'13. In essence the difficulty with the model of development shown in Figure l(b) is that there is a large gap between the user's world (the application domain) and the developer's objective (the target system). A more appropriate approach to development would be one that explicitly recognised requirements analysis and specification and that provided formalisms and tools for the effective undertaking of these activities. This approach, shown schematically in Figure l(c), is increasingly receiving attention by researchers in the field of software technology13 - t 6 According to the paradigm of Figure l(c), the tasks associated with requirements specification fall into two areas, namely, modelling and analysis ~7. Modelling refers to the mapping of real world phenomena onto basic concepts of a requirements specification language. Such concepts serve as the means of building various structures that, in their totality, constitute the requirements specification for a problem domain, while analysis refers to the techniques that are used to facilitate communication between requirements engineers and end-users for the purpose of verification. Following these views, requirements engineering can be defined as the systematic process
0950-5849/89/030123-13 $3.00 © 1989 Butterworth& Co (Publishers) Ltd
123
-I
Automated information system
-I
Automated information system
_1
Build
Verify
a
Analyse a n d
j 4 1 1
1
Vet i fY ''
_I
--Build System specification 91~----Ve r i fy
b Universe of discourse model
S
Observe
/ rify
-..
Constrain Verify
-.... Build
Automated information system
Design specification ,41~-- Ve r i fy
S'v, C
½
Design~~ Functional system model
~ e r i f y
- -
Figure 1. Paradigms for developing automated information system
of developing requirements through an iterative process of analysing a problem, documenting the resulting observations, and checking the accuracy of the understanding gained. It is becoming increasingly obvious that a requirements specification should be more than just a functional specification of the system. What is also required is a model of the application domain that expresses clearly the domain's properties and constraints that, together with a set of nonfunctional requirements, dictate the behaviour of the system. It is the authors' belief that such a view should be supported by requirements elicitation techniques and computer-assisted tools that support this process. In addition to this, there is a need to provide facilities that better reflect the problem-solving behaviour of requirements analysts. Vitalari and Dickson 1a showed that experienced analysts exhibit five major types of behaviour: 124
• • • •
analogical reasoning planning, goal setting, and strategy formulation hypothesis management operative knowledge for the application of heuristic knowledge • problem facilitation This behaviour is supported by different 'knowledge bases', which fall under the following categories' 9: • • • •
organization-specific knowledge functional domain knowledge application domain knowledge development method knowledge
An emerging theme from most studies on the task of requirements specification is the importance of application domain. In a recent field study of the software design information and software technology
process for large systems, Curtis e t al. 2° report that to build successful systems, a developer needs to be familiar with application-specific knowledge and in particular must be able to integrate knowledge from different domains. The study in Curtis e t aL 2° revealed, however, that in most cases application domain knowledge is thinly spread throughout the development team, with the result that the productivity and quality are compromised. From the preceding analysis of the requirements specification task, it becomes obvious that the current state of the art in CASE environments scarcely addresses any of the issues of concern. Simplistic reasoning, found in most contemporary tools, merely serves as a passive agent (i.e., a data dictionary of specification components), and therefore a new approach that recognises the issues discussed above must be sought. A prototype system known as Analyst Assist has been developed to provide a richer environment for the capture and specification of requirements. This system provides novel facilities for the acquisition and modelling of domain-specific facts and their integration into specifications following the Jackson System Development (JSD) method syntax. The remainder of this paper describes this prototype system, its basic architecture, and functionality of one of its main components, namely, the requirements elicitation subsystem. The next section gives an overview of the entire system, together with an introduction to the requirements elicitation subsystem. The section 'Model for fact representation' briefly introduces the formalism used for modelling any captured facts about an application domain. The section 'Requirements modelling using Analyst Assist' gives a detailed description of the requirements elicitation subsystem. This is done in terms of the three main facilities of concept elicitation, concept resolution, and decision tracing.
ARCHITECTURE OF KNOWLEDGEBASED REQUIREMENTS ENGINEERING ENVIRONMENT The hypothesis of the work presented in this paper is that a knowledge-based approach, with appropriate techniques and tools, shows considerable promise in aiding the process of requirements capture. This hypothesis is partly based on the results of a number of empirical studies that set out to investigate the process of requirements analysis. In two such studies the differences in behaviour between high- and low-rated analysts were investigated in an attempt to identify efficient practices 18'21. In a similar study, Adelson and Soloway 22 looked at the differences between novice and expert analysts. Gibson and Harthoorn 23 carried out a task analysis of the way that experienced analysts apply the JSD method in large application domains. Based on the results of these studies, several major types of reasoning process and behaviour that contribute to the performance of experienced and expert analysts have been identified 24, including analogical reasoning, hypothesis formulation, summarization, and the use of vol 31 no 3 april 1989
domain knowledge. Therefore, CASE tools should possess not only the standard documentation and consistency checking capabilities found in many contemporary tools, but that they should also have a reasoning capability based on expert analysts' knowledge. To this end, a prototype system, Analyst Assist, has been developed to provide assistance during the phases of requirements elicitation, modelling, and verification 25"26. The main objectives of the system are: to capture informal requirements and improve the transition from informal requirements capture to formal representation through the use of domain and analysis knowledge to specify and document requirements using the JSD method • to validate the specification by prototyping and animating the specification
Analyst Assist system architecture The architecture of the system for meeting these objectives is shown in Figure 2, which, for convenience, is divided into two realms the user's realm and the analyst's realm, each of which is intended to represent the different levels of abstraction involved in knowledge capture. The user's) realm part of the system is concerned with the elicitation of facts about an application domain from users. The typical processes involved in this activity are the questioning of users, recording of answers, and validation of gathered information. It is assumed that the questioning and recording activities will be conducted by analysts with machine-assistance (fact gathering) in the construction of question checklists and a facility for the summarizing and recording of users' answers in a structured fashion. Central to this activity is the use of domain knowledge. In the validation activity, the models produced through the analysis of gathered information are presented to users for checking, either in static form (specification presentation) or through dynamic presentation, simulation, and execution (specification execution). The analyst's realm is concerned with the structuring of gathered facts into a consistent specification of a system, primarily driven by method knowledge, in this case knowledge that pertains to JSD. Typical processes involved in this activity are structuring of gathered facts in a form consistent with JSD constructs (specification building) and consistency checking (specification verification). The functionality of the modules in the analyst's realm is analogous to that of current CASE tools. The specification building component provides the means of generating and recording a specification in terms of the entity structure diagram and the system structure diagram. In addition to this standard facility, however, the specification verification module provides the means of animating a specification. The functionality of the specification building and specification verification modules is described elsewhere 27,2s. Arguably the most problematic of requirements engineering activities is the capture of pertinent facts about an 125
User's realm
Analyst knowledge
Specification execution
Specification representation
Specification verification
Specification translation
Specification building
AnalysPs realm
Implementation environment
Figure 2.
Analyst Assist architecture
application domain. The Analyst Assist system provides a number of powerful facilities that attempt to ease the task of requirements capture, and the remainder of this paper concentrates on this critical function.
Requirements elicitation subsystem Central to the Analyst Assist system in the Requirements Elicitation and Specification Tools (REST), which is a composite term to refer to a number of software modules, each contributing towards the interpretation of facts in a user fact base and the development of a JSD specification. An abstract architecture of REST is shown in Figure 3. The user fact base is concerned with the storage of application-dependent concepts before these concepts are interpreted in terms of JSD constructs. This database is populated using a fact input tool. This tool is guided by an elicitation dialogue formulator, which makes use of the domain knowledge base and current state of the user fact base. The JSD specification holds an evolving system specification in terms of JSD structures for the model and network stages of that method. This specification is developed via the REST (making use of the user fact base) and with the assistance of two diagramming tools shown in Figure 3 as the JSD input tool component. The JSD method advisor acts as an assistant on the method steps
126
of JSD and provides consistency checking on the evolving JSD specification. The JSD to fact base tracing facility is used to link a JSD specification to the concepts in the user fact base from which it was derived and to update or annotate information held in it due to information input by the analyst using the JSD input tool.
MODEL
FOR
FACT
REPRESENTATION
To simplify the system architecture, the knowledge bases and user fact base share the same underlying representation. The formalism chosen is broadly based on the use of conceptual structures 35 for knowledge representation and reasoning. While conceptual structures are often associated with the understanding of natural language, involving large semantic nets, comprehensive lexicons, and precise grammar rules, it is important to emphasize that the use of conceptual graph theory within requirements elicitation and formalization does not involve the same degree of complexity. The concepts and relationships employed can be limited to those that are relevant to the current domain of interest. Conceptual graphs are finite, connected bipartite graphs, and the two nodes of the bipartite graph are concepts and conceptual relations. Every conceptual relation has one or more arcs, each of which must be linked to some concept. The collection of all the
information and software technology
Analyst
Fact i n p u t too I
!
I Elicitation dialogue formulator
I aI
Fact base to JSD translator
I I I I
JSD p r i m i t i v e identifier
I
REST
G
I Domain knowledge exploiter
I
i
I I
I
JSD to fact base tracing facility
I I I I
G
JSD method advisor (model and network)
I
I
JSD i n p u t tool
Figure 3.
Analyst
Requirements Elicitation and Specification Tool architecture
relationships that concepts have to other concepts is called the semantic net. All conceptual graphs are linked to the semantic net, and so access to any graph is possible from any concept or relation. The following components of conceptual graph theory have been implemented to provide a representation and reasoning medium for use by the domain knowledge base and user fact base that directly support the process of fact gathering.
A detailed description of the conceptual structures employed in the model for REST is beyond the scope of this paper. The interested reader is referred to Champion et aL 29 for a comprehensive description of these conceptual structures.
• Separate hierarchies of concept types and relation types, which define the relationships between domain concepts and relations at different levels of generality. • Prototype descriptions of each concept, which can be linked to the concept type hierarchy. • Formation rules to determine how each type of concept may be linked to conceptual relations and to other concepts. • Conceptual graphs linked to each concept, defining how the concept should be used in a domain (canonical graph) or how it may be used (scenario graph).
Requirements elicitation in Analyst Assist is based on the premise that an analyst should be able to define any 'thing' of the modelled application domain as a potential concept of interest and that the final set of concepts can only be decided on after careful consideration of various scenarios about the role that these concepts play. Therefore, 'concepts capturing and resolution' uses:
vol 31 no 3 april 1989
REQUIREMENTS MODELLING USING ANALYST ASSIST
• The semantics of conceptual graphs. Concepts are placed in semantic networks with the top-level concepts 127
being predefined as those of ENTITY, EVENT, Q U A N T I F I E R , VALUE, STATE, and TIME. Conceptual relations are also classified by type. A hierarchy is defined over the type labels of the conceptual relations defined for the current domain. • The domain knowledge base. The domain knowledge base may contain information about one or more concepts about the current application domain. This knowledge is used in automatically deriving conceptual graphs for these concepts and later on for their resolution. • A natural language output facility. All information presented to the analyst during an input session and subsequent resolution is shown in such a way as to hide the underlying formalism. Where possible, general rules for translating conceptual graphs into English are used; however, where more complicated representation is required in the user fact base, for example, in the representation of constraints, these must be dealt with by special purpose rules.
Capture and representation o f domain-specific facts The purpose of capturing facts about an application domain is to allow an analyst to reason with all information that is perceived to be relevant so that a system specification can be constructed. Because of the
Analyst Assist
nature of the process of facts gathering it is advantageous to permit an analyst to carry out this process in a variety of ways. Analyst Assist provides the following three tools.
Text analyser This tool allows an analyst to highlight keywords and phrases from a document. Single words are stored in the user fact base as concepts. Phrases highlighted by the analyst are analysed by the system to find known concepts and to insert the appropriate conceptual relations between them. The concepts include those identifed by the analyst and those that are known to the system as part of the domain knowledge. Where the concepts are known to the domain knowledge base, the appropriate conceptual relations can also be derived. Otherwise the conceptual relations have to be derived from the concept hierarchy or by use of the elicitation dialogue formulator. The concepts and relations thus derived are used to produce conceptual graphs for storage in the user fact base.
Hierarchy editor The concepts known to the system are described in terms of their relationships with other concepts and are arranged in a concept hierarchy. This tool allows an analyst to classify concepts by placing them directly in the hierarchy, thus bypassing the text analyser.
= Stage II Fact Gathering Prototype
vorslon 112.o-o / Analymt : bob
I°m~'*"" I I 'nmu~ II ~.o,ve l I ~ee*e ]l beoo,e I
Figure 4.
128
Text analyser
information and software technology
Eiieitation dialogue formulator In situations where more information about a concept is required, and neither of the tools described above are appropriate, it may be necessary for an analyst to be asked specific questions to elicit the information. This tool uses the information contained in the user fact base and the domain knowledge base to construct these questions as they are needed. As an example of the fact gathering process using Analyst Assist, consider the case of a university library. Text about this application domain is shown in the text analyser window in Figure 4. The underlined text signifies that an analyst has highlighted these concepts as being of interest. The process of storing these concepts in the user fact base is demonstrated graphically in Figure 5. Figure 5 shows the basic types of data to be stored in the user fact base during an elicitation session. The schema 'cgl' represents the conceptual graph of the user-supplied information. As a direct result of this c o n c e p t t y p e , schemas are created for the concepts 'MEMBER', 'BORROW', and 'BOOK'. The conceptual graph cgl is linked to each of these as a scenario for the concept. The relevant domain knowledge for the concept 'BORROW' is shown as cg2 and is also provided as a scenario for the concept. The resolution of the two scenarios is trivial in this example, and the resulting conceptual graph, cg3, is linked to the current view slot of the concept schema. The schemas cgl and cg2 are then marked as 'shadowed', to indicate that they have been resolved with the current view. The concepts represented in the user fact base may be viewed (and further extended) by using the hierarchy editor as shown in Figure 6. The hierarchy editor window shows the type of specialization of each concept in relation
to the predefined system concepts. This means that each new concept introduced in the user fact base inherits relationships with other concepts from its supertype. The placement of a concept in the hierarchy does not preclude subsequent alterations that would change its position in the hierarchy. Such a change may result from further analysis and resolution of requirements, which are handled by the resolution facility of the system. As well as identifying individual concepts such as MEMBER, BORROW, and BOOK, it is possible to highlight phrases within the text that imply semantic links between the concepts. Then the system can be prompted to derive the nature of these links. An example of this is shown in Figure 7. The selected phrase window shows the highlighted phrase from the original text, together with a list of all currently known concepts. Links may be established between the three concepts, and the system's interpretation of these links is presented in the created scenario window. It is now up to the analyst, working with the end-user, to select the most appropriate interpretation, which will subsequently be stored in the user fact base.
Resolution of captured domain-specific facts Resolution of information within the user fact base takes place under the supervision of the analyst, but some automatic checking of consistency can be carried out. These checks imply the need for a more formal representation of facts in the user fact base. Where more complicated dependencies exist in the information, for example, in the interdependence of requirements and constraints, a set of rules is required to maintain consistency. The current version of the prototype includes facilities for viewing the entire contents of the user fact base about
cgl Input_ source I ~'¢
I
Figure 5.
Concept_type 'BORROW'
Creation of C o n c e p t T y p e
vol 31 no 3 april 1989
From domain knowledge
'BORRO W" in user fact base
129
1~ Analyst Assist
Stage II Fact Gathering Prototype
-
wr,mn #e.~e /
Anmlyat : bob
I°p,,*.. I m..,~m
I.°.*'~. I I *'0"
II b..~.. I
ADO -NEWOONOEPT| BOOK BORROM LORM MEHBER OVERDUE REMEW RE6ERVE RETURM GTflFF 6TU~ENT
exl~
I'~m,lu.ohy editor
xenu
®
i
F'RunlversitW l: Books m~W be ~orrowed for UP to three wee~e0 A f t ° r whlc~ the~ must OO returned. ~ Member M~W borro W no More than 5 book8 ~ • time, BOOKS on loan w hich mr° B . ~ are eu~Ject to = d=ll~ flne, Book° MnU be rene~ed, if the~ ~re not elrea~ rem lrvmO b W mnother mem~lr.
COMMANO WINOOW
Figure 6.
Hierarchy editor
Analyst Assist
=
Stage Ii Fact Gathering Prototype
verWon #t.0-e -
/
Anll~/ot : bob
l opt,o-I[
,.pot J l"o'~'l[
~.*e
II b.o... I
IWmrarol~
sdtor
F.N~R |CENAR~ add t o UFB
exlt
nenu
ul: PB,RB; LO.TENT#)
)elected PBraN R unlvmrmlt W ~ibrarw ha| ~ember| who borrow bookm
Crettod|oooar~|
I
4b bOokm # members membere CBO0~ *
~soo~] • (eRm) j. O00kB booke Dook# bookm
MEMBER ~BORROW
borrows #membere. ! with ~ooke ~orrow. wlth booke are borroweo. (PART) * [MEMBER] * (RGNT) * CBORRO
•
!BOOK
[MEMBER] • (OeJ) * [BORROW
Wlth flembor8 Are Oorro~eo. of member° a r e Oorrowmd. ore Dorrowed OW memOers, ewe borrowed mem~ere,
m
WINDOW
Figure 7. Scenarioformation 130
information and software technology
options, and so on. In other words, the construction of a requirements specification is nonmonotonic and, therefore, tools to assist in the tracing of the diverse decisions taken by analysts in the process of deriving a specification are considered as providing another source of assistance. The current version of the prototype system allows the source of information in the user fact base to be traced. This may include details of the source document, the analysis, or the date of the input session. In addition to this, the system provides traceability of analyst decisions. These will correspond to two different additions to the user fact base. First, facts that the analyst wishes to add without providing a documentary source, i.e., the analyst's own ideas and notes. Second, there is a need to record information concerning the decisions made about the data in the user fact base, in particular decisions to do with the reconciliations of differing views or contradictory information. Figure 9 shows how this extra information will be stored in the user fact base. In the diagram, since cg9 represents the current view of the c o n c e p t t y p e 'BORROW', and cg9 is linked to a resolution of cgl, cg4, and cg5, these scenarios need not be considered unless an analyst wishes to investigate the origin of a current view. Scenarios can be shadowed by a decision in this way and so reduce the amount of information presented to an analyst at each session. New scenarios and old current views may be shadowed by subsequent decisions, but the traceability is maintained by the decision history.
a particular concept and for the rationalization of this information. As an example, consider again the university library case study. Figure 8 shows the information stored in the user fact base, in the window labelled User Fact Base and Domain Knowledge Scenarios about the concept MEMBER. The window scenario options shows the available operations that can be performed on the user fact base knowledge about MEMBER. The 'make current view' option allows the analyst to mark a conceptual graph as that which represents the most accurate description of the concept; the 'shadow' option refers to those scenarios that have been previously discarded (but nevertheless saved); the 'join' option permits the merging of two or more existing scenarios. Figure 8 shows two unresolved scenarios for the concept MEMBER that may be joined and be made the current view. The advantage of the resolution facility is that it allows the incremental development of information about each concept in the user fact base. The join operation includes functions to enforce consistency in the scenarios being joined, but in the case where conflicts arise, different views of the same concept may be developed in parallel.
T r a c i n g analyst decisions During the development of a requirements specification, analysts adopt certain lines of action, decide which information is appropriate, discard previously considered
Analyst Assist
- Stage II Fact Gathering Prototype
I
,,r, to, #~,0-p -
/
Arml.yl¢ : bob
I op~'*"'ll i.p., I - - - - - - - [
'-*,
I1 b . . , , ] U . r Flct B i l e &rid Dlmt41n Knowiodlle Iclk~4Plee of MEMRR
IOENANO0~|
RIkf ourrent dlsoePd Join
VItw ? ?
C M
Figure 8.
books ~ r e renewed b W nombore, bookl arl ~orrould bW RIR~Irl.
lI
U W
Resolution options
vol 31 no 3 april 1989
131
I s Input-~ ource_l~
From domain knowledge
ConceptMype 'BORROW'
cg6
Input_ source_2
Resolution between cgl, cg4, and cg5
Figure 9.
Resolution and decision recording in user fact base
For the representation in the user fact base, conceptual graphs attached to concept types will be marked either 'shadowed' or 'current'. There may be only one current view for each concept type that is marked as current. Each current view will be linked to a decision, showing how it was derived and hence which scenarios and previous current views are shadowed by it. The tracing of analysts' decisions in the current version of the prototype is shown in Figure 10. The 'decision history' window shows the details of the decision labelled 'd540', which has been selected by the analyst as relevant to the current view of the concept MEMBER. These details include a description of the type of decision made, the analyst responsible, the date, and a list of scenarios that have been shadowed as a result of the decision. Subsequently, the analyst can review any of the scenarios listed.
CONCLUSIONS This paper has argued that the demand for more reliable and cost effective information systems should force 132
Decision linking cg9 with cgl, cg4 and cg5
solutions to be sought in areas most likely to yield maximum benefits. One of the major emerging themes in the area of information systems development research is the realisation that correct requirements specification holds the key to the construction of effective and flexible systems. At the same time it is recognised that the area of requirements capture is fraught with problems such as uncertainty and vagueness in the users' requirements, complexity about the modelled domain, and lack of adequate techniques and tools that can bridge the gap between users and developers. The work reported in this paper represents an attempt at improving requirements capture and specification through the use of knowledge engineering techniques. It is proposed that requirements specification is primarily a knowledge-intensive activity and the work reported here follows the premise that the next generation of requirements engineering environments will be knowledge-based environments. To this end, the work presented complements other research efforts in the wider sphere of software engineering 3°-34. In this paper a clear distinction is made between requirements and design specifications. It is argued that information and software technology
Analyst Assist
= Stage II Fact Gathering Prototype
eermJon I,P..O.P /
Armlyat : bob
I *P"*"" I I ,.pu,
I ~
mm..m
I b.~.
I
OONOLrPT WFOOIMAIlON Rwsolvsd Information
Unresolved Information Dlsoarded InFornatlon 9eolslons
moues
information
For f u r t h m r OltAILll
Origin e~lt
Dsclslone r i l A t e ~ to
nenu
MEMgER#GENERIO e r e ............................
i
O~g O524 ............................ moues l n f o r m s t l o n
Oeolek~ Hlet~y Deolelon
:
for F u r t h e r
~et=11e
~54e
ShadowS:
CG512
Ameerts~
C0531
Reeolveded Into
DECIBION DETRILS: reoson: user Oeclelon in resolve tool • n~Iwet: bOO O A t l Of I l l l l O n : .........................
Current U1ew - C053! R s e e r t e O DW D e e l e l o n ........................
~9e9/1/23
a , 0540
Doecrlpclon of ourront vlow I DooRs renews DW memOere Are O o r r o w m O DW meMOs re. ........................ ~eclsIQn :eSalle , R n m l w e t Involve: Robson for ~ o o l s l o n Date of D e c l e l o n -
::D - NIL 198911/23
COMMAND WINNOW
Figure 10.
Tracing analysts' decisions
a requirements specification should be concerned with the understanding of a problem, whereas a design specification should pay attention to logical and physical structures that implement the requirements. Therefore, the development of a requirements specification involves modelling the relevant application domain, resulting in a model that is cognitive in nature. In the past, requirements specifications have played a passive role and have been viewed as fixed throughout the life of an information system. The thesis put forward in this paper is that a requirements specification needs to evolve to reflect changes in the application domain and that these changes must be implemented in such a way so as to ensure that users and developers are clear on the implications that the changes will have on the design and operational characteristics of the system. Because of the nature of requirements elicitation, the paper proposes that this objective can be achieved by a knowledge-based approach, such as that followed in the Analyst Assist system. The system described in this paper has been developed on Texas Instruments Explorers using ART and Common LISP. The prototype system has also been ported on Sun workstations also running under ART and Common LISP. It has been the intention of the authors to adopt a single unifying representation formalism for the expression of facts in the user fact base and knowledge within the vol 31 no 3 april 1989
domain knowledge bases since such an approach has several advantages. The informality that characterizes much of the initial requirements elicitation process is supported by the linguistic basis of conceptual structures. The representation is based on a user-defined type hierarchy of concepts occurring in the domain of interest. Linked to each concept in the hierarchy is a definition, 'together with examples of semantic and episodic information about the concept, all expressed as conceptual graphs. The choice of formalism also has implications for the validation of the requirements independent of a design method. The linguistic basis of the concept and relationship definitions allows both the domain knowledge and the existing application knowledge to be presented to the user in terms of the semantics of the domain rather than the semantics imposed by any design method, thus broadening the applicability of the general approach to any system development method.
ACKNOWLEDGMENTS The work reported in this paper was conducted as part of the Analyst Assist project. This is a collaborative project involving Data Logic, UMIST, Scicon, MJSL, MUD(ARE), and Istel. The work undertaken by the authors of this paper is supported by the UK Science and 133
Engineering Research Council Grant No GR/D 72648SE/113 as part of the Alvey Programme of Research and Development.
REFERENCES 1 0 l l e , T W, Sol, H G and Verrijn Stuart, A A Information systems design methodologies: a comparative review (IFIP WG 8.1 CRIS I) North Holland, Amsterdam, The Netherlands (1982) 2 0 l l e , T W, Sol, H G and Tully, C J Information systems design methodologies: a feature analysis (IFIP WG 8.1 CRIS II) North Holland, Amsterdam, The Netherlands (1983) 3 0 l l e , T W, Sol, H G and Verrijn-Stuart, A A Proc. IFIP WG 8.1 Working Conf. Comparative Review o[ Information Systems Design Methodologies: Improving the practice Noordwijkerhout, The Netherlands (5-7 May 1986) 4 MacDonald, I 'Information engineering an improved, automatable methodology for designing data sharing systems' in Olle, T W, Sol, H G and VerrijnStuart, A A (eds) Information systems methodologies." improving the practice IFIP-North Holland, Amsterdam, The Netherlands (1986) pp 173-224 5 Jackson, M System development Prentice-Hall, Englewood Cliffs, N J, USA (1983) 6 Verheijen, G and van Bekkum, J 'NIAM: an information analysis method' in Olle, T W, Sol, H G and Verrijn-Stuart, A A (eds) Information systems methodologies: improving the practice IFIP-North Holland, Amsterdam, The Netherlands (1986) 7 Ross, D T 'Structured analysis: a language for communicating ideas' IEEE Trans. Softw. Eng. Vol SE-3 No 1 (1979) 8 DeMareo, T Structured analyis and system specification Yourdon Press, New York, NY, USA (1978) 9 Gane, C and Sarson, T Structured systems analysis: tools and techniques Prentice-Hall, Englewood Cliffs, NJ, USA (1979) 10 Layzeil, P J and Loueopoulos, P Systems analysis and development (2nd edition) Chartwell-Bratt, Bromley, UK (1987) I 1 Morris, E P 'Strengths and weaknesses in current large DP' in Proc. Alvey/BCS SGES Workshop Sunningdale, UK (January 1985) 12 Chapin, N 'Software lifecycle' in Proc. INFOTEC Conf. Structured Software Development (1979) 13 van Assche, F, Layzell, P J, Loucopoulos, P and Speltincx, G 'RUBRIC: a rule based representation of information system constructs' in Proc. 5th Annual ESPRIT Conf. Brussels, Belgium (14-17 November 1988) North-Holland, Amsterdam, The Netherlands (1988) pp 438-452 14 Greenspan, S 'Requirements modeling: a knowledge representation approach to software requirements definition' Technical Report No CSRG-155 University of Toronto, Toronto, Canada (1984) 134
15 Hagelstein, J 'Declarative approach to information systems requirements' Knowl.-Based Syst. Vol 1 No 4 (September 1988) pp 211-220 16 Jarke, M, Jeusfeld, M and Rose, T 'Modelling software processes in a knowledge base: the case for information systems' Knowl.-Based Syst. Vol 1 No 4 (September 1988) pp 197-210 17 Dubois, E et al. 'The ERAE model: a case study' in Olle, T W, Sol, H G and Verrijn-Stuart, A A (eds) Information systems methodologies: improving the practice IFIP-North Holland, Amsterdam, The Netherlands (1986) pp 87-106 18 Vitalari, N P and Dickson, G W 'Problem solving for effective systems analysis: an experimental exploration' Commun. ACMVo126 No 11 (November 1983) pp 948-956 19 Vitalari, N P 'Knowledge as a basis for expertise in systems analysis: an empirical study' MIS Q. (September 1985) pp 221-241 20 Curtis, B, Krasner, H and lscoe, N 'A field study of the software design process for large systems' Commun. ACM Vol 31 No 11 (November 1988) pp 1268 1287 21 Fickas, S 'Automating the analysis process: an example' in Proc. 4th Int. Workshop Software Specification and Design Monterey, USA (1987) 22 Adeison, B and Soloway, E 'The role of domain experience in software design' IEEE Trans. Softw. Eng. Vol SE-11 No 11 (November 1985) 23 Gibson, M and Harthoorn, C 'The use of JSD' Analyst Assist internal report AA-UO010 UMIST, Manchester, UK (1987) 24 Loucopoulos, P and Champion, R E M 'Knowledgebased approach to requirements engineering using method and domain knowledge' Knowl.-Based Syst. Vol 1 No 3 (June 1988) pp 179-187 25 Flynn, D J, Layzell, P J and Loucopoulos, P 'Assisting the analyst the aims and objectives of the Analyst Assist project' in Proc. BCS Conf. Software Engineering Southampton, UK (1986) 26 Loueopoulos, P, Layzell, P J, Champion, R E M and Gibson, M 'A knowledge-based requirements engineering environment' in Proc. Conf. Knowledge Based Software Assistance (KBSA) Utica, USA (2-4 August 1988) 27 Adhami, E 'An environment for the execution and graphical animation of JSD specifications' in Proc. Int. Workshop on Knowledge-Based Systems in Software Engineering UMIST, Manchester, UK (March 1988) 28 Bird, B 'Building of JSD specifications' in Proc. Int. Workshop on Knowledge-Based Systems in Software Engineering UMIST, Manchester, UK (March 1988) 29 Champion, R E M, Gibson, M and Harthoorn, C 'Conceptual structures in the fact gathering system' Analyst Assist internal report AA-UO067 UMIST, Manchester, UK (1987) 30 Waters, R C 'The Programmer's Apprentice: a session with KBEmacs' IEEE Trans. Softw. Eng. Vol 11 No 1 (November 1985)pp 1296-1320 31 Rich, C, Waters, R C and Reubenstein, H B 'Toward a information and software technology
requirements apprentice' in Proc. 4th Int. Workshop Software Specification and Design Monterey, USA (1987) 32 Pietri, F et ai. 'ASPIS: a knowledge-based environment for software development' in Proc. ESPRIT "87: Achievements andlmpact North Holland, Amsterdam, The Netherlands (1987) pp 375 391 33 Kaiser, G E and Feller, P H 'An architecture for intelligent assistance in software development' in Proc. 9th Int. Conf. Software Engineering Monterey, USA (30 March--2 April 1987) 34 Lubars, M D and Harandi, M T 'Knowledge-based software design using design schemas' in Proc. 9th Int. Conf. Software Engineering Monterey, USA (30 March 2 April 1987)
vol 31 no 3 april 1989
35 Sowa, J F Conceptual structures: information processing in mind and machine Addison-Wesley, Wokingham, UK (1984)
BIBLIOGRAPHY Roseh, E et ai. 'Basic objects in natural categories' Cog. Psychol. Vol 8 No 3 (July 1976) Rzepka, W and Ohao, Y 'Requirements engineering environments: software tools for modelling user needs' IEEE Computer (April 1985) Wetherbe, J C Systems analysis and design." traditional, structured and advanced concepts and techniques West Publishing Co (1979)
135
The accurate capture and representation of user requirements plays a critical role in the construction of effective and flexible information systems. Despite the introduction of development methods and CASE tools in the project life-cycle, the process of developing a requirements specification remains problematical. The paper proposes that the process of requirements specification should be considered from a viewpoint that is close to an analyst's cognitive processes. To this end the paper presents a requirements specification support environment that is based on the premise that it is advantageous to carry out modelling at the early stages of development independent of any particular software engineering method. This support environment, known as the Analyst Assist system, exploits knowledge-based paradigms for the capture and modelling of facts about an application domain, which are then transformed into a functional specification represented in the Jackson System Development method. information systems, systems development methods, requirements engineering, knowledge-based environments
In recent years there has been a growing realisation that the development of large information systems is becoming increasingly more difficult as user requirements become broader and more sophisticated. The complexity that is exhibited by most contemporary application domains and the subsequent problem of developing automated information systems for these domains has proved that the traditional, informal approach to development (as shown in Figure l(a)) is no longer feasible. The gap between the initial statement for the requirement of an automated information and its eventual implementation is far too great for this approach to be feasible. Obviously, there is a need for a discipline that establishes the appropriate procedures for managing large development teams within a systematic framework that recognises well identified tasks and milestones. The major response to such a need has been the emergence of a number of system development methods, each consisting of metamodels for system representation, a process by which to construct specifications and a set of computer-assisted Department of Computation, UMIST, PO Box 88, Manchester, M60 IQD, UK vol 31 no 3 april 1 9 8 9
software engineering (CASE) tools to aid development ~-3. Examples of such methods are Information Engineering 4, JSD 5, NIAM 6, SADT 7, SASD s, STRADIS 9, and a plethora of other more or less similar methods (see Layzell and Loucopoulos ~° for a bibliography). These methods and associated CASE tools pay particular attention to the construction of a high-level specification of a system before this system is developed. This is shown in Figure l(b) as the 'system specification' component. Such a component normally contains a functional specification of the intended information system. Despite the increasing use of these methods and the undisputed advantages that these methods bring to the management of a project, however, users continue to experience major difficulties~~. It has often been reported that over 50% of software malfunctions have their origin in the process of requirements capture, although the effect is not detected until later stages, giving rise to a figure of 80% of personnel resources being committed to the debugging and testing of source code 12'13. In essence the difficulty with the model of development shown in Figure l(b) is that there is a large gap between the user's world (the application domain) and the developer's objective (the target system). A more appropriate approach to development would be one that explicitly recognised requirements analysis and specification and that provided formalisms and tools for the effective undertaking of these activities. This approach, shown schematically in Figure l(c), is increasingly receiving attention by researchers in the field of software technology13 - t 6 According to the paradigm of Figure l(c), the tasks associated with requirements specification fall into two areas, namely, modelling and analysis ~7. Modelling refers to the mapping of real world phenomena onto basic concepts of a requirements specification language. Such concepts serve as the means of building various structures that, in their totality, constitute the requirements specification for a problem domain, while analysis refers to the techniques that are used to facilitate communication between requirements engineers and end-users for the purpose of verification. Following these views, requirements engineering can be defined as the systematic process
0950-5849/89/030123-13 $3.00 © 1989 Butterworth& Co (Publishers) Ltd
123
-I
Automated information system
-I
Automated information system
_1
Build
Verify
a
Analyse a n d
j 4 1 1
1
Vet i fY ''
_I
--Build System specification 91~----Ve r i fy
b Universe of discourse model
S
Observe
/ rify
-..
Constrain Verify
-.... Build
Automated information system
Design specification ,41~-- Ve r i fy
S'v, C
½
Design~~ Functional system model
~ e r i f y
- -
Figure 1. Paradigms for developing automated information system
of developing requirements through an iterative process of analysing a problem, documenting the resulting observations, and checking the accuracy of the understanding gained. It is becoming increasingly obvious that a requirements specification should be more than just a functional specification of the system. What is also required is a model of the application domain that expresses clearly the domain's properties and constraints that, together with a set of nonfunctional requirements, dictate the behaviour of the system. It is the authors' belief that such a view should be supported by requirements elicitation techniques and computer-assisted tools that support this process. In addition to this, there is a need to provide facilities that better reflect the problem-solving behaviour of requirements analysts. Vitalari and Dickson 1a showed that experienced analysts exhibit five major types of behaviour: 124
• • • •
analogical reasoning planning, goal setting, and strategy formulation hypothesis management operative knowledge for the application of heuristic knowledge • problem facilitation This behaviour is supported by different 'knowledge bases', which fall under the following categories' 9: • • • •
organization-specific knowledge functional domain knowledge application domain knowledge development method knowledge
An emerging theme from most studies on the task of requirements specification is the importance of application domain. In a recent field study of the software design information and software technology
process for large systems, Curtis e t al. 2° report that to build successful systems, a developer needs to be familiar with application-specific knowledge and in particular must be able to integrate knowledge from different domains. The study in Curtis e t aL 2° revealed, however, that in most cases application domain knowledge is thinly spread throughout the development team, with the result that the productivity and quality are compromised. From the preceding analysis of the requirements specification task, it becomes obvious that the current state of the art in CASE environments scarcely addresses any of the issues of concern. Simplistic reasoning, found in most contemporary tools, merely serves as a passive agent (i.e., a data dictionary of specification components), and therefore a new approach that recognises the issues discussed above must be sought. A prototype system known as Analyst Assist has been developed to provide a richer environment for the capture and specification of requirements. This system provides novel facilities for the acquisition and modelling of domain-specific facts and their integration into specifications following the Jackson System Development (JSD) method syntax. The remainder of this paper describes this prototype system, its basic architecture, and functionality of one of its main components, namely, the requirements elicitation subsystem. The next section gives an overview of the entire system, together with an introduction to the requirements elicitation subsystem. The section 'Model for fact representation' briefly introduces the formalism used for modelling any captured facts about an application domain. The section 'Requirements modelling using Analyst Assist' gives a detailed description of the requirements elicitation subsystem. This is done in terms of the three main facilities of concept elicitation, concept resolution, and decision tracing.
ARCHITECTURE OF KNOWLEDGEBASED REQUIREMENTS ENGINEERING ENVIRONMENT The hypothesis of the work presented in this paper is that a knowledge-based approach, with appropriate techniques and tools, shows considerable promise in aiding the process of requirements capture. This hypothesis is partly based on the results of a number of empirical studies that set out to investigate the process of requirements analysis. In two such studies the differences in behaviour between high- and low-rated analysts were investigated in an attempt to identify efficient practices 18'21. In a similar study, Adelson and Soloway 22 looked at the differences between novice and expert analysts. Gibson and Harthoorn 23 carried out a task analysis of the way that experienced analysts apply the JSD method in large application domains. Based on the results of these studies, several major types of reasoning process and behaviour that contribute to the performance of experienced and expert analysts have been identified 24, including analogical reasoning, hypothesis formulation, summarization, and the use of vol 31 no 3 april 1989
domain knowledge. Therefore, CASE tools should possess not only the standard documentation and consistency checking capabilities found in many contemporary tools, but that they should also have a reasoning capability based on expert analysts' knowledge. To this end, a prototype system, Analyst Assist, has been developed to provide assistance during the phases of requirements elicitation, modelling, and verification 25"26. The main objectives of the system are: to capture informal requirements and improve the transition from informal requirements capture to formal representation through the use of domain and analysis knowledge to specify and document requirements using the JSD method • to validate the specification by prototyping and animating the specification
Analyst Assist system architecture The architecture of the system for meeting these objectives is shown in Figure 2, which, for convenience, is divided into two realms the user's realm and the analyst's realm, each of which is intended to represent the different levels of abstraction involved in knowledge capture. The user's) realm part of the system is concerned with the elicitation of facts about an application domain from users. The typical processes involved in this activity are the questioning of users, recording of answers, and validation of gathered information. It is assumed that the questioning and recording activities will be conducted by analysts with machine-assistance (fact gathering) in the construction of question checklists and a facility for the summarizing and recording of users' answers in a structured fashion. Central to this activity is the use of domain knowledge. In the validation activity, the models produced through the analysis of gathered information are presented to users for checking, either in static form (specification presentation) or through dynamic presentation, simulation, and execution (specification execution). The analyst's realm is concerned with the structuring of gathered facts into a consistent specification of a system, primarily driven by method knowledge, in this case knowledge that pertains to JSD. Typical processes involved in this activity are structuring of gathered facts in a form consistent with JSD constructs (specification building) and consistency checking (specification verification). The functionality of the modules in the analyst's realm is analogous to that of current CASE tools. The specification building component provides the means of generating and recording a specification in terms of the entity structure diagram and the system structure diagram. In addition to this standard facility, however, the specification verification module provides the means of animating a specification. The functionality of the specification building and specification verification modules is described elsewhere 27,2s. Arguably the most problematic of requirements engineering activities is the capture of pertinent facts about an 125
User's realm
Analyst knowledge
Specification execution
Specification representation
Specification verification
Specification translation
Specification building
AnalysPs realm
Implementation environment
Figure 2.
Analyst Assist architecture
application domain. The Analyst Assist system provides a number of powerful facilities that attempt to ease the task of requirements capture, and the remainder of this paper concentrates on this critical function.
Requirements elicitation subsystem Central to the Analyst Assist system in the Requirements Elicitation and Specification Tools (REST), which is a composite term to refer to a number of software modules, each contributing towards the interpretation of facts in a user fact base and the development of a JSD specification. An abstract architecture of REST is shown in Figure 3. The user fact base is concerned with the storage of application-dependent concepts before these concepts are interpreted in terms of JSD constructs. This database is populated using a fact input tool. This tool is guided by an elicitation dialogue formulator, which makes use of the domain knowledge base and current state of the user fact base. The JSD specification holds an evolving system specification in terms of JSD structures for the model and network stages of that method. This specification is developed via the REST (making use of the user fact base) and with the assistance of two diagramming tools shown in Figure 3 as the JSD input tool component. The JSD method advisor acts as an assistant on the method steps
126
of JSD and provides consistency checking on the evolving JSD specification. The JSD to fact base tracing facility is used to link a JSD specification to the concepts in the user fact base from which it was derived and to update or annotate information held in it due to information input by the analyst using the JSD input tool.
MODEL
FOR
FACT
REPRESENTATION
To simplify the system architecture, the knowledge bases and user fact base share the same underlying representation. The formalism chosen is broadly based on the use of conceptual structures 35 for knowledge representation and reasoning. While conceptual structures are often associated with the understanding of natural language, involving large semantic nets, comprehensive lexicons, and precise grammar rules, it is important to emphasize that the use of conceptual graph theory within requirements elicitation and formalization does not involve the same degree of complexity. The concepts and relationships employed can be limited to those that are relevant to the current domain of interest. Conceptual graphs are finite, connected bipartite graphs, and the two nodes of the bipartite graph are concepts and conceptual relations. Every conceptual relation has one or more arcs, each of which must be linked to some concept. The collection of all the
information and software technology
Analyst
Fact i n p u t too I
!
I Elicitation dialogue formulator
I aI
Fact base to JSD translator
I I I I
JSD p r i m i t i v e identifier
I
REST
G
I Domain knowledge exploiter
I
i
I I
I
JSD to fact base tracing facility
I I I I
G
JSD method advisor (model and network)
I
I
JSD i n p u t tool
Figure 3.
Analyst
Requirements Elicitation and Specification Tool architecture
relationships that concepts have to other concepts is called the semantic net. All conceptual graphs are linked to the semantic net, and so access to any graph is possible from any concept or relation. The following components of conceptual graph theory have been implemented to provide a representation and reasoning medium for use by the domain knowledge base and user fact base that directly support the process of fact gathering.
A detailed description of the conceptual structures employed in the model for REST is beyond the scope of this paper. The interested reader is referred to Champion et aL 29 for a comprehensive description of these conceptual structures.
• Separate hierarchies of concept types and relation types, which define the relationships between domain concepts and relations at different levels of generality. • Prototype descriptions of each concept, which can be linked to the concept type hierarchy. • Formation rules to determine how each type of concept may be linked to conceptual relations and to other concepts. • Conceptual graphs linked to each concept, defining how the concept should be used in a domain (canonical graph) or how it may be used (scenario graph).
Requirements elicitation in Analyst Assist is based on the premise that an analyst should be able to define any 'thing' of the modelled application domain as a potential concept of interest and that the final set of concepts can only be decided on after careful consideration of various scenarios about the role that these concepts play. Therefore, 'concepts capturing and resolution' uses:
vol 31 no 3 april 1989
REQUIREMENTS MODELLING USING ANALYST ASSIST
• The semantics of conceptual graphs. Concepts are placed in semantic networks with the top-level concepts 127
being predefined as those of ENTITY, EVENT, Q U A N T I F I E R , VALUE, STATE, and TIME. Conceptual relations are also classified by type. A hierarchy is defined over the type labels of the conceptual relations defined for the current domain. • The domain knowledge base. The domain knowledge base may contain information about one or more concepts about the current application domain. This knowledge is used in automatically deriving conceptual graphs for these concepts and later on for their resolution. • A natural language output facility. All information presented to the analyst during an input session and subsequent resolution is shown in such a way as to hide the underlying formalism. Where possible, general rules for translating conceptual graphs into English are used; however, where more complicated representation is required in the user fact base, for example, in the representation of constraints, these must be dealt with by special purpose rules.
Capture and representation o f domain-specific facts The purpose of capturing facts about an application domain is to allow an analyst to reason with all information that is perceived to be relevant so that a system specification can be constructed. Because of the
Analyst Assist
nature of the process of facts gathering it is advantageous to permit an analyst to carry out this process in a variety of ways. Analyst Assist provides the following three tools.
Text analyser This tool allows an analyst to highlight keywords and phrases from a document. Single words are stored in the user fact base as concepts. Phrases highlighted by the analyst are analysed by the system to find known concepts and to insert the appropriate conceptual relations between them. The concepts include those identifed by the analyst and those that are known to the system as part of the domain knowledge. Where the concepts are known to the domain knowledge base, the appropriate conceptual relations can also be derived. Otherwise the conceptual relations have to be derived from the concept hierarchy or by use of the elicitation dialogue formulator. The concepts and relations thus derived are used to produce conceptual graphs for storage in the user fact base.
Hierarchy editor The concepts known to the system are described in terms of their relationships with other concepts and are arranged in a concept hierarchy. This tool allows an analyst to classify concepts by placing them directly in the hierarchy, thus bypassing the text analyser.
= Stage II Fact Gathering Prototype
vorslon 112.o-o / Analymt : bob
I°m~'*"" I I 'nmu~ II ~.o,ve l I ~ee*e ]l beoo,e I
Figure 4.
128
Text analyser
information and software technology
Eiieitation dialogue formulator In situations where more information about a concept is required, and neither of the tools described above are appropriate, it may be necessary for an analyst to be asked specific questions to elicit the information. This tool uses the information contained in the user fact base and the domain knowledge base to construct these questions as they are needed. As an example of the fact gathering process using Analyst Assist, consider the case of a university library. Text about this application domain is shown in the text analyser window in Figure 4. The underlined text signifies that an analyst has highlighted these concepts as being of interest. The process of storing these concepts in the user fact base is demonstrated graphically in Figure 5. Figure 5 shows the basic types of data to be stored in the user fact base during an elicitation session. The schema 'cgl' represents the conceptual graph of the user-supplied information. As a direct result of this c o n c e p t t y p e , schemas are created for the concepts 'MEMBER', 'BORROW', and 'BOOK'. The conceptual graph cgl is linked to each of these as a scenario for the concept. The relevant domain knowledge for the concept 'BORROW' is shown as cg2 and is also provided as a scenario for the concept. The resolution of the two scenarios is trivial in this example, and the resulting conceptual graph, cg3, is linked to the current view slot of the concept schema. The schemas cgl and cg2 are then marked as 'shadowed', to indicate that they have been resolved with the current view. The concepts represented in the user fact base may be viewed (and further extended) by using the hierarchy editor as shown in Figure 6. The hierarchy editor window shows the type of specialization of each concept in relation
to the predefined system concepts. This means that each new concept introduced in the user fact base inherits relationships with other concepts from its supertype. The placement of a concept in the hierarchy does not preclude subsequent alterations that would change its position in the hierarchy. Such a change may result from further analysis and resolution of requirements, which are handled by the resolution facility of the system. As well as identifying individual concepts such as MEMBER, BORROW, and BOOK, it is possible to highlight phrases within the text that imply semantic links between the concepts. Then the system can be prompted to derive the nature of these links. An example of this is shown in Figure 7. The selected phrase window shows the highlighted phrase from the original text, together with a list of all currently known concepts. Links may be established between the three concepts, and the system's interpretation of these links is presented in the created scenario window. It is now up to the analyst, working with the end-user, to select the most appropriate interpretation, which will subsequently be stored in the user fact base.
Resolution of captured domain-specific facts Resolution of information within the user fact base takes place under the supervision of the analyst, but some automatic checking of consistency can be carried out. These checks imply the need for a more formal representation of facts in the user fact base. Where more complicated dependencies exist in the information, for example, in the interdependence of requirements and constraints, a set of rules is required to maintain consistency. The current version of the prototype includes facilities for viewing the entire contents of the user fact base about
cgl Input_ source I ~'¢
I
Figure 5.
Concept_type 'BORROW'
Creation of C o n c e p t T y p e
vol 31 no 3 april 1989
From domain knowledge
'BORRO W" in user fact base
129
1~ Analyst Assist
Stage II Fact Gathering Prototype
-
wr,mn #e.~e /
Anmlyat : bob
I°p,,*.. I m..,~m
I.°.*'~. I I *'0"
II b..~.. I
ADO -NEWOONOEPT| BOOK BORROM LORM MEHBER OVERDUE REMEW RE6ERVE RETURM GTflFF 6TU~ENT
exl~
I'~m,lu.ohy editor
xenu
®
i
F'RunlversitW l: Books m~W be ~orrowed for UP to three wee~e0 A f t ° r whlc~ the~ must OO returned. ~ Member M~W borro W no More than 5 book8 ~ • time, BOOKS on loan w hich mr° B . ~ are eu~Ject to = d=ll~ flne, Book° MnU be rene~ed, if the~ ~re not elrea~ rem lrvmO b W mnother mem~lr.
COMMANO WINOOW
Figure 6.
Hierarchy editor
Analyst Assist
=
Stage Ii Fact Gathering Prototype
verWon #t.0-e -
/
Anll~/ot : bob
l opt,o-I[
,.pot J l"o'~'l[
~.*e
II b.o... I
IWmrarol~
sdtor
F.N~R |CENAR~ add t o UFB
exlt
nenu
ul: PB,RB; LO.TENT#)
)elected PBraN R unlvmrmlt W ~ibrarw ha| ~ember| who borrow bookm
Crettod|oooar~|
I
4b bOokm # members membere CBO0~ *
~soo~] • (eRm) j. O00kB booke Dook# bookm
MEMBER ~BORROW
borrows #membere. ! with ~ooke ~orrow. wlth booke are borroweo. (PART) * [MEMBER] * (RGNT) * CBORRO
•
!BOOK
[MEMBER] • (OeJ) * [BORROW
Wlth flembor8 Are Oorro~eo. of member° a r e Oorrowmd. ore Dorrowed OW memOers, ewe borrowed mem~ere,
m
WINDOW
Figure 7. Scenarioformation 130
information and software technology
options, and so on. In other words, the construction of a requirements specification is nonmonotonic and, therefore, tools to assist in the tracing of the diverse decisions taken by analysts in the process of deriving a specification are considered as providing another source of assistance. The current version of the prototype system allows the source of information in the user fact base to be traced. This may include details of the source document, the analysis, or the date of the input session. In addition to this, the system provides traceability of analyst decisions. These will correspond to two different additions to the user fact base. First, facts that the analyst wishes to add without providing a documentary source, i.e., the analyst's own ideas and notes. Second, there is a need to record information concerning the decisions made about the data in the user fact base, in particular decisions to do with the reconciliations of differing views or contradictory information. Figure 9 shows how this extra information will be stored in the user fact base. In the diagram, since cg9 represents the current view of the c o n c e p t t y p e 'BORROW', and cg9 is linked to a resolution of cgl, cg4, and cg5, these scenarios need not be considered unless an analyst wishes to investigate the origin of a current view. Scenarios can be shadowed by a decision in this way and so reduce the amount of information presented to an analyst at each session. New scenarios and old current views may be shadowed by subsequent decisions, but the traceability is maintained by the decision history.
a particular concept and for the rationalization of this information. As an example, consider again the university library case study. Figure 8 shows the information stored in the user fact base, in the window labelled User Fact Base and Domain Knowledge Scenarios about the concept MEMBER. The window scenario options shows the available operations that can be performed on the user fact base knowledge about MEMBER. The 'make current view' option allows the analyst to mark a conceptual graph as that which represents the most accurate description of the concept; the 'shadow' option refers to those scenarios that have been previously discarded (but nevertheless saved); the 'join' option permits the merging of two or more existing scenarios. Figure 8 shows two unresolved scenarios for the concept MEMBER that may be joined and be made the current view. The advantage of the resolution facility is that it allows the incremental development of information about each concept in the user fact base. The join operation includes functions to enforce consistency in the scenarios being joined, but in the case where conflicts arise, different views of the same concept may be developed in parallel.
T r a c i n g analyst decisions During the development of a requirements specification, analysts adopt certain lines of action, decide which information is appropriate, discard previously considered
Analyst Assist
- Stage II Fact Gathering Prototype
I
,,r, to, #~,0-p -
/
Arml.yl¢ : bob
I op~'*"'ll i.p., I - - - - - - - [
'-*,
I1 b . . , , ] U . r Flct B i l e &rid Dlmt41n Knowiodlle Iclk~4Plee of MEMRR
IOENANO0~|
RIkf ourrent dlsoePd Join
VItw ? ?
C M
Figure 8.
books ~ r e renewed b W nombore, bookl arl ~orrould bW RIR~Irl.
lI
U W
Resolution options
vol 31 no 3 april 1989
131
I s Input-~ ource_l~
From domain knowledge
ConceptMype 'BORROW'
cg6
Input_ source_2
Resolution between cgl, cg4, and cg5
Figure 9.
Resolution and decision recording in user fact base
For the representation in the user fact base, conceptual graphs attached to concept types will be marked either 'shadowed' or 'current'. There may be only one current view for each concept type that is marked as current. Each current view will be linked to a decision, showing how it was derived and hence which scenarios and previous current views are shadowed by it. The tracing of analysts' decisions in the current version of the prototype is shown in Figure 10. The 'decision history' window shows the details of the decision labelled 'd540', which has been selected by the analyst as relevant to the current view of the concept MEMBER. These details include a description of the type of decision made, the analyst responsible, the date, and a list of scenarios that have been shadowed as a result of the decision. Subsequently, the analyst can review any of the scenarios listed.
CONCLUSIONS This paper has argued that the demand for more reliable and cost effective information systems should force 132
Decision linking cg9 with cgl, cg4 and cg5
solutions to be sought in areas most likely to yield maximum benefits. One of the major emerging themes in the area of information systems development research is the realisation that correct requirements specification holds the key to the construction of effective and flexible systems. At the same time it is recognised that the area of requirements capture is fraught with problems such as uncertainty and vagueness in the users' requirements, complexity about the modelled domain, and lack of adequate techniques and tools that can bridge the gap between users and developers. The work reported in this paper represents an attempt at improving requirements capture and specification through the use of knowledge engineering techniques. It is proposed that requirements specification is primarily a knowledge-intensive activity and the work reported here follows the premise that the next generation of requirements engineering environments will be knowledge-based environments. To this end, the work presented complements other research efforts in the wider sphere of software engineering 3°-34. In this paper a clear distinction is made between requirements and design specifications. It is argued that information and software technology
Analyst Assist
= Stage II Fact Gathering Prototype
eermJon I,P..O.P /
Armlyat : bob
I *P"*"" I I ,.pu,
I ~
mm..m
I b.~.
I
OONOLrPT WFOOIMAIlON Rwsolvsd Information
Unresolved Information Dlsoarded InFornatlon 9eolslons
moues
information
For f u r t h m r OltAILll
Origin e~lt
Dsclslone r i l A t e ~ to
nenu
MEMgER#GENERIO e r e ............................
i
O~g O524 ............................ moues l n f o r m s t l o n
Oeolek~ Hlet~y Deolelon
:
for F u r t h e r
~et=11e
~54e
ShadowS:
CG512
Ameerts~
C0531
Reeolveded Into
DECIBION DETRILS: reoson: user Oeclelon in resolve tool • n~Iwet: bOO O A t l Of I l l l l O n : .........................
Current U1ew - C053! R s e e r t e O DW D e e l e l o n ........................
~9e9/1/23
a , 0540
Doecrlpclon of ourront vlow I DooRs renews DW memOere Are O o r r o w m O DW meMOs re. ........................ ~eclsIQn :eSalle , R n m l w e t Involve: Robson for ~ o o l s l o n Date of D e c l e l o n -
::D - NIL 198911/23
COMMAND WINNOW
Figure 10.
Tracing analysts' decisions
a requirements specification should be concerned with the understanding of a problem, whereas a design specification should pay attention to logical and physical structures that implement the requirements. Therefore, the development of a requirements specification involves modelling the relevant application domain, resulting in a model that is cognitive in nature. In the past, requirements specifications have played a passive role and have been viewed as fixed throughout the life of an information system. The thesis put forward in this paper is that a requirements specification needs to evolve to reflect changes in the application domain and that these changes must be implemented in such a way so as to ensure that users and developers are clear on the implications that the changes will have on the design and operational characteristics of the system. Because of the nature of requirements elicitation, the paper proposes that this objective can be achieved by a knowledge-based approach, such as that followed in the Analyst Assist system. The system described in this paper has been developed on Texas Instruments Explorers using ART and Common LISP. The prototype system has also been ported on Sun workstations also running under ART and Common LISP. It has been the intention of the authors to adopt a single unifying representation formalism for the expression of facts in the user fact base and knowledge within the vol 31 no 3 april 1989
domain knowledge bases since such an approach has several advantages. The informality that characterizes much of the initial requirements elicitation process is supported by the linguistic basis of conceptual structures. The representation is based on a user-defined type hierarchy of concepts occurring in the domain of interest. Linked to each concept in the hierarchy is a definition, 'together with examples of semantic and episodic information about the concept, all expressed as conceptual graphs. The choice of formalism also has implications for the validation of the requirements independent of a design method. The linguistic basis of the concept and relationship definitions allows both the domain knowledge and the existing application knowledge to be presented to the user in terms of the semantics of the domain rather than the semantics imposed by any design method, thus broadening the applicability of the general approach to any system development method.
ACKNOWLEDGMENTS The work reported in this paper was conducted as part of the Analyst Assist project. This is a collaborative project involving Data Logic, UMIST, Scicon, MJSL, MUD(ARE), and Istel. The work undertaken by the authors of this paper is supported by the UK Science and 133
Engineering Research Council Grant No GR/D 72648SE/113 as part of the Alvey Programme of Research and Development.
REFERENCES 1 0 l l e , T W, Sol, H G and Verrijn Stuart, A A Information systems design methodologies: a comparative review (IFIP WG 8.1 CRIS I) North Holland, Amsterdam, The Netherlands (1982) 2 0 l l e , T W, Sol, H G and Tully, C J Information systems design methodologies: a feature analysis (IFIP WG 8.1 CRIS II) North Holland, Amsterdam, The Netherlands (1983) 3 0 l l e , T W, Sol, H G and Verrijn-Stuart, A A Proc. IFIP WG 8.1 Working Conf. Comparative Review o[ Information Systems Design Methodologies: Improving the practice Noordwijkerhout, The Netherlands (5-7 May 1986) 4 MacDonald, I 'Information engineering an improved, automatable methodology for designing data sharing systems' in Olle, T W, Sol, H G and VerrijnStuart, A A (eds) Information systems methodologies." improving the practice IFIP-North Holland, Amsterdam, The Netherlands (1986) pp 173-224 5 Jackson, M System development Prentice-Hall, Englewood Cliffs, N J, USA (1983) 6 Verheijen, G and van Bekkum, J 'NIAM: an information analysis method' in Olle, T W, Sol, H G and Verrijn-Stuart, A A (eds) Information systems methodologies: improving the practice IFIP-North Holland, Amsterdam, The Netherlands (1986) 7 Ross, D T 'Structured analysis: a language for communicating ideas' IEEE Trans. Softw. Eng. Vol SE-3 No 1 (1979) 8 DeMareo, T Structured analyis and system specification Yourdon Press, New York, NY, USA (1978) 9 Gane, C and Sarson, T Structured systems analysis: tools and techniques Prentice-Hall, Englewood Cliffs, NJ, USA (1979) 10 Layzeil, P J and Loueopoulos, P Systems analysis and development (2nd edition) Chartwell-Bratt, Bromley, UK (1987) I 1 Morris, E P 'Strengths and weaknesses in current large DP' in Proc. Alvey/BCS SGES Workshop Sunningdale, UK (January 1985) 12 Chapin, N 'Software lifecycle' in Proc. INFOTEC Conf. Structured Software Development (1979) 13 van Assche, F, Layzell, P J, Loucopoulos, P and Speltincx, G 'RUBRIC: a rule based representation of information system constructs' in Proc. 5th Annual ESPRIT Conf. Brussels, Belgium (14-17 November 1988) North-Holland, Amsterdam, The Netherlands (1988) pp 438-452 14 Greenspan, S 'Requirements modeling: a knowledge representation approach to software requirements definition' Technical Report No CSRG-155 University of Toronto, Toronto, Canada (1984) 134
15 Hagelstein, J 'Declarative approach to information systems requirements' Knowl.-Based Syst. Vol 1 No 4 (September 1988) pp 211-220 16 Jarke, M, Jeusfeld, M and Rose, T 'Modelling software processes in a knowledge base: the case for information systems' Knowl.-Based Syst. Vol 1 No 4 (September 1988) pp 197-210 17 Dubois, E et al. 'The ERAE model: a case study' in Olle, T W, Sol, H G and Verrijn-Stuart, A A (eds) Information systems methodologies: improving the practice IFIP-North Holland, Amsterdam, The Netherlands (1986) pp 87-106 18 Vitalari, N P and Dickson, G W 'Problem solving for effective systems analysis: an experimental exploration' Commun. ACMVo126 No 11 (November 1983) pp 948-956 19 Vitalari, N P 'Knowledge as a basis for expertise in systems analysis: an empirical study' MIS Q. (September 1985) pp 221-241 20 Curtis, B, Krasner, H and lscoe, N 'A field study of the software design process for large systems' Commun. ACM Vol 31 No 11 (November 1988) pp 1268 1287 21 Fickas, S 'Automating the analysis process: an example' in Proc. 4th Int. Workshop Software Specification and Design Monterey, USA (1987) 22 Adeison, B and Soloway, E 'The role of domain experience in software design' IEEE Trans. Softw. Eng. Vol SE-11 No 11 (November 1985) 23 Gibson, M and Harthoorn, C 'The use of JSD' Analyst Assist internal report AA-UO010 UMIST, Manchester, UK (1987) 24 Loucopoulos, P and Champion, R E M 'Knowledgebased approach to requirements engineering using method and domain knowledge' Knowl.-Based Syst. Vol 1 No 3 (June 1988) pp 179-187 25 Flynn, D J, Layzell, P J and Loucopoulos, P 'Assisting the analyst the aims and objectives of the Analyst Assist project' in Proc. BCS Conf. Software Engineering Southampton, UK (1986) 26 Loueopoulos, P, Layzell, P J, Champion, R E M and Gibson, M 'A knowledge-based requirements engineering environment' in Proc. Conf. Knowledge Based Software Assistance (KBSA) Utica, USA (2-4 August 1988) 27 Adhami, E 'An environment for the execution and graphical animation of JSD specifications' in Proc. Int. Workshop on Knowledge-Based Systems in Software Engineering UMIST, Manchester, UK (March 1988) 28 Bird, B 'Building of JSD specifications' in Proc. Int. Workshop on Knowledge-Based Systems in Software Engineering UMIST, Manchester, UK (March 1988) 29 Champion, R E M, Gibson, M and Harthoorn, C 'Conceptual structures in the fact gathering system' Analyst Assist internal report AA-UO067 UMIST, Manchester, UK (1987) 30 Waters, R C 'The Programmer's Apprentice: a session with KBEmacs' IEEE Trans. Softw. Eng. Vol 11 No 1 (November 1985)pp 1296-1320 31 Rich, C, Waters, R C and Reubenstein, H B 'Toward a information and software technology
requirements apprentice' in Proc. 4th Int. Workshop Software Specification and Design Monterey, USA (1987) 32 Pietri, F et ai. 'ASPIS: a knowledge-based environment for software development' in Proc. ESPRIT "87: Achievements andlmpact North Holland, Amsterdam, The Netherlands (1987) pp 375 391 33 Kaiser, G E and Feller, P H 'An architecture for intelligent assistance in software development' in Proc. 9th Int. Conf. Software Engineering Monterey, USA (30 March--2 April 1987) 34 Lubars, M D and Harandi, M T 'Knowledge-based software design using design schemas' in Proc. 9th Int. Conf. Software Engineering Monterey, USA (30 March 2 April 1987)
vol 31 no 3 april 1989
35 Sowa, J F Conceptual structures: information processing in mind and machine Addison-Wesley, Wokingham, UK (1984)
BIBLIOGRAPHY Roseh, E et ai. 'Basic objects in natural categories' Cog. Psychol. Vol 8 No 3 (July 1976) Rzepka, W and Ohao, Y 'Requirements engineering environments: software tools for modelling user needs' IEEE Computer (April 1985) Wetherbe, J C Systems analysis and design." traditional, structured and advanced concepts and techniques West Publishing Co (1979)
135