Knowledge-Based Support for Requirements Engineering P. Loucopoulos and R.E.M. Champion Department of Computation, UMIST, P.O. Box 88, ( Manchester, M60 lQD, United Kingdom, Tel. 061 236 3311. ABSTRACT The accurate capture and representation of user requirements plays a critical role in the construction of effective and flexible information systems. However, despite the introduction of development methods and CASE tools in the project life-cycle, the process of developing a requirements specification remains problematical. This paper proposes that future development in CASE environments should provide facilities which more closely match the activies of expen system analysts. These activities include: the creation of infonnal models and scenarios about the modelled domain prior to the formalisation of captured concepts in a schema according to the l chosen development method's model; extensive use of domain knowledge; use of method specific knowledge; consideration of multiple views about the modelled domain; the creation of hierarchies of concepts; formulation of hypotheses about modelled structures; and resolution of different hypotheses and decision fonnulation. To this end, the paper reports on a prototype system which provides facilities for the support of these activities by exploiting knowledge-based techniques for the capture of concepts about an application domain and their specification in JSD constructs. . ACKNOWLEDGEMENT • 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, MOD(ARE) and Iste!. The work undertaken by the authors of this paper is supported by the UK Science and Engineering Research Council Grant No. GRID 72648 - SE/I13 as part of the Alvey Programme of Research and Development and experimentation prior to developing a 1. Introduction specification according to the constructs of the chosen method. To this end, the paper reports on a In recent years there has been a growing prototype system which is used as part of a larger realisation that the development of large CASE environment in the context of the Jackson information systems is becoming increasingly System Development (ISo) method [Jackson, more difficult as user requirements become 1983]. Section 2 discusses. t~e proce.ss of broader and more sophisticated. The complexity capl1lring concepts of an ~pphcauon domatn and which is exhibited by most contemporary derives a set of deslfable features of a application domains and the subsequent problem requirements engineering support srstem. Secti?n of developing automated information syste.":ls for 3 introduces the p.rototype syst~m 10 terms ?f Its these domains has proved that the tradiuonal, underlying formalism and funcuons and se~lion.4 informal approach is no longer feasible since the describes the way the system may be explolled 10 gap, between initial requirements st~tement and the terms of the system's three m~n facilitie,s, of verification of these requirements 10 terms of the concept elicitation, concept resolulion and deCISIOn implemented system, is too large. An altema~ive to ttaeing. the traditional approach has been the adopuon of paradigms which attempt to establish appropriate ( management procedure~ withiln 'da ~fiysedtematkic 2. Requirements Specification framework which recogmses we l I enli I tas s and milestones. Examples of such methods are A requirements specification represents both a Information Engineering [MacDonald, 1986], ISO model of what is needed and a statement of the [Jackson, 1983], NIAM [Verheijen & van problem under consideration [Rzepka and Ohno, Bekkum, 1982], SADT [Ross, 1977], SASO 1985]. The activities involved, are 10,ng and [DeMarco, 1978], STRADIS [Gane & Sarson, iterative, and involve much tnformallty and 1979] and a plethora of other more or less similar uncertainty. Conseqi!ently, many ?f th~ problems methods (cf [Layzell & Loucopoulos, 1987] for a associated with requrrements speclficat.lOn can be bibliography). attributed to the naMe of the task llself. The following are key. char.acteris~cs ~f the ~ask of These proprietory methods and their associated requirements speclficalion [Vllalan & Dickson, CASE tools pay particular attention to the 1983]: construction of a high level specification of a system before the implementation of software. • because the task is carried out at the early Emphasis is placed in .establishi":g a clear stages of the development lifecycl~ it is often understanding of the funcl10nal requlfements of difficult to define the boundanes of the the information system, since it has often been universe of discourse in an exact way reported that .o~er. 50% of software malf~nctions have their ongtn 10 the process of requlfements • because there is little structure of the problem capture, the effect however not being detected until domain before hand there is a considerable later stages thus giving rise to a figure of 80% of degree of uncertainty about the naMe and personnel resources being committed to t!te make-up of the possible solutions debugging and testing of source code [Chapm, 1979, van Assche et al, 1988]. • analysis problems are dynamic that is, they change while they are being solved becaus~ of Despite the increasi~g use of the~e meth~s, their organisational co~text and the. !Uulliple however users conunue to expenence major participants involved 10 the definll10n and difficulti~s [Morris, 1985]. From the viewpoint of specification process requirements specification, a major criticism levelled at contemporary approaches is their poor • solutions to analysis problems require handling of the capl1lring and modelling of the interdisciplinary knowledge and skill knowledge of the universe of discourse [Greenspan, 1984; Balzer et al, 1983; van ~ssche • the process of analysis .i~self, is primarily et ai, 1988]. These shortcomings can be attributed cognitive in naMe, requmng the analyst to partly to the inherent nal1lfe of the process of struCl1lfe an abstract problem, proces.s diverse capturing, modelling and verifying concepts of the information, and develop a lOgIcal and modelled domain and partly to inadequate internally consistent set of models. formalisms used for the representation of these concepts. Within requirements specification two basic activities take place: modelling and analysis This paper argues that future development [Dubois et all, 1986]. Modelling t:efers to mapping methods and CASE environments must support the real world phenoJ!lena. into baSIC concepts of,a early stages of requirements specification, by requirements specificauon language. These baSIC providing J!lodelling formalisms, and funclions concepts serve as the means of building various which permIt the development of lIi/ormal models structures which, in their totality, constitute the a. Use of Analogy requirements specification for a problem domain. Analysis refers to techniques used to facilitate Developers use information from the communication between requirements engineers environment to classify problems and relate and end-users using the developed requirements them to previous experience. On the other specification as the basis of that communication. hand lack of information provides triggers to search for missing data. Empirical studies have Following this view, requirements engineering can shown that experienced developers begin by be defined as the systematic process of developing establishing a set of context questions and then requirements through an iterative process of proceed by considering alternatives. One basic analysinll the problem, documenting the resulting prerequisite for using analogy during observanons and checking the accuracy of the requirements elicitation is the knowledge that understanding gained. the analyst has about the domain under examination. Loucopoulos and Champion In order to manage this process there is a need for [1988] argue that such knowledge is crucial to support in three areas. Firstly, an analyst's the development of a requirements reasoning process must be guided by some specification. ( underlying process which is appropriate to the task as well as the problem domain. Such an b. Hierarchies of Models underlying process must be generic in nature, so that all analysts may use its constructs, and must Expert developers tend to start solving a represent a standard approach within an problem by forming a mental model of the organisation, so that a specification generated by a problem at an abstract level. This model is then development team is achieved in an integrated refined, by a progression of transformations, way. Secondly, facilities must be provided for to a concrete model, as more information is locating information about an evolving obtained. Developers are aware of the various specification. Many facts are gathered during the levels of policy within a domain and use this process of constructing a· requirements knowledge to guide a. user during a specification and these facts must be correlated, requirements capture session. irrelevant ones discarded and appropriate facts organised in meaningful structures. Thirdly, c. Fonnulation of Hypotheses assistance is needed in the communication between analysts and end users during the phases of facts Hypotheses are developed as to the nature of acquisition and specification verification. the solution, as information is collected. An Capturing and verifying requirements are labour- experienced developer uses hypothetical intensive activities which demand skilful examples to capture more facts from a user but interchange between those that understand the also to clarify some previously acquired problem domain and those that need to model the information about the object system. problem domain. Experience in the application domain seems to be an important factor in formulating likely Contemporary approaches provide support in all outcomes of the solution space. three areas through the use of method steps, project encyclopedias, and diagramming tools. d. Summarisation Certainly, these approaches are a major improvement on the ad-hoc traditional approach. However, further major benefits can only come about if the three areas of design discipline, documentation and communication are supplemented by support facilities which closely Developers almost always summarise in order to verify their findings. It has been observed that dun'ng a typical user-analyst session the analyst will summarise two or three times and each time the summarisation will trigger a new I match the behaVIOur of expert analysts. . set of questions. Summarisation may be used in order to clarify certain points from previous A number of empirical studies have been carried discussions or to encourage participants to out in an attempt to better understand the process contribute more information about the of developing a requirements specification. The modelled domain. differences in behaviour between high and low- rated analysts were investigated in three separate e. Domain Knowledge projects [Vitalari & Dickson, 1983; Fickas, 1987; Adelson & Soloway, 1985]. Based upon the Expert analysts normally have a good results of these studies, it is possible to identify knowledge of the concepts involved in the several major (not mutually exclusive) types of business processes of the organisation being working practices by system developers, as investigated. Some concepts will be common follows: to information systems, regardless of the underlying organisation. This common knowledge enables an . expert analyst to tool has been developed within the context of the approach a familiar analysis problem in a new Analyst Assist system [Loucopoulos et ai, 1988] domain with some expectations, which can be and attempts to provide assistance in capturing used to guide the investigation. informal requirements, specifying and documenting requirements using the Jackson A further important finding of a study on the use System Development Method (JSD), and validating of the JSD method which has implications on the the specification by prototyping and animation. use of development methods at the early stages of REST provides facilities which: the project lifecycle is the use of informal models before any captured concepts are formulated • encourage the development of informal models according to the method's prescribed formalism in the form of scenarios about the modelled [Gibson & Harthoorn, 1987]. The first step in the domain JSD method is the derivation of the entity stucture model which considers entities of the modelled • maintain many different views about captured domain and actions suffered by each entity. The concepts investigation on the use of the method by experienced analysts revealed that, in their attempt • enable the tracing of decisions taken by to structure the problem domain and identify what analysts about discarding or accepting are appropriate entities and actions for modelling, particular scenarios these analysts consistently used informal models (or even models of other methods with which they • assist the identification of candidate concepts were familiar). As shown in figure 1, these by exploiting domain knowledge and informal models, were considered along with domain expertise and JSD method expertise in • assist in the mapping of informal models onto ( deriving a f1I'St-cut JSD entity model. JSD model structures using JSD knowledge. 3. The Requirements Elicitation Support System 3.1 The System Architecture initialfactgathering An abstract architecture of REST is shown in figure 2. The user fact base (UFB) is concerned with the storage of application dependent concepts before build model build model these concepts are interpreted in terms of JSD I'·'''··........·, ....••.. ·..... 1" .. • .. •.. • .. •• .. • .. ·, .. ··"··1 constructs. This database IS \,?pulated using a Fact ! '11 .....z.-...... ,~ -z, ! Input Tool. This tool is gwded by an Elicitation Analyst Dialogue Formulator which makes use of the User domain knowledge base and the current state of Interaction JSDMODEL InteractiOl the UFB. It is feasible for the UFB to contain ~. ~ -., several different and possibly contradictory views Do~iio;.p;;ii:, of the concepts pertaining to the modelled domain. isi)",;,,;;/', I At any stage. one of these views is considered to represent the current view, that is the view which most closely reflects the analysts opinion about the JSD NETWORK 4·····.,···~ modelled domain (but may be replaced at any point L.-_ _~_--JJSDexpernse by any of the other views should the analyst's opinion is modified). The lSD specification holds an evolving system SYSTEM specification in terms of JSD structures for the model and network stages of that method. This specification is developed via the REST (making Figure 1: Working Method of Expert JSD Analysts use of the UFB) and with the assistance of two diagramming tools shown in figure 2 as the lSD On the basis of the findings of these studies a Input Tool component prototype tool known as the Requirements Elicitatton Support Tool (REST) has been The lSD Method Advisor acts as an assistant on developed in order to provide assistance at the the method steps of JSD and provides consistency very early stages of requirements capture. This ISD • ~ Fact Input Tool Knowledgf ~ Analyst • ., Elicitation Fact Base ISD Dialogue toISD Primitive Formulator Translator Identifier User Fact . -.. ·············1 REST 1····jSD···· ..... ISD Base • Spec • Knowledge! Tracmg. ! Advisor . Domain ••• FactBase !• Method Exploiter i Facility i (Model & • ••• •• Network) ~ i r ( Analyst ( Domain Iknowledgf .ISD Input ..... Tool - f Figure 2: The Requirements Elicitation and SpecifiCaly.. : bob ~ option, n Input n "nalve n trio. n broun I fNT~ .dd to UFEI ' ' 'lAMI 1M I t "Inu , R cl_ C,.... Bo ,,1II'r.:;::7~::::::-~::::::-=------------'~'" ne rbooke Mborrow. M~."blr. A un1v.r.1~W 11brarw hal ~."b.r. who borrow book•. 00 1"I,,,,b'l"l liI1th bookl barrol,j KEKBER t ,110"'0,,., \lith book. art borroulet. Bo In cBOOKj' (PRRT l. [MEKBERl • (ROKT) • [BORROW]. (BOOK • (PA~T • [MEMBER • (OBJ) • [aO~~O~], BORROW BOOK bookl with I"Ill"1blrl art borrow'd. cookl of "I"'berl are borrowed, book, art borrowed bW ~I"b.r" bookl are borrOl,j,d I"Ilnb.rl. ( Figure 6: Scenario Fonnation Analyst Assist Stage II fact Gathering Prototype 'Oro/OIl l2.o-P I At>aly.t : bob ............ "Ike aurr.nt YI.w III dlllllo.rd Join ? bookl~' renewed OW l'I'I'ID.rl. ? book, are returned bW 1"I'l'Iblrt. Figure 7: Resolution Options Analyst Assist - Stage II Fact Gathering Prototype ••ro/on 12.00P - I Ana/YI' : bob DONClOT ..'aMlATIW ~,TtXT.) N•• olvld Inrornatlon Unresolyed InforMa'lon Disoirded In'ornltlan Dlol!llontl Orl,ln l1li D,clel0nl rllated ~E~BERIOEHERIC -~----_ dllBS dl199 Cfl2l2 to orl , .. _--------------_ .. - I DEClSIDH DETRILS, rlalonl Mo,lWltl ,hadow ,nforcld b~ u.lr date of •••• 10n' bob Ige'~3121 ( ~- D.e1l1on I d125'4 Shadow I I ·CO?S4 ( R.llre,. DECISIDH DETRILS, rlalon, ,hadou enforced bW u••r analwltl bob date of •••• 10nl 1'8'/3/21 Figure 8: Tracing Analysts' Decisions 4.3 Tracing Analyst Decisions In the UFB, conceptual graphs attached to concept types are marked as either 'shadowed' or During the development of a requirements 'current'. At any given time only one current view specification, analysts adopt certain lines of action, of a concept is allowed. Each current view would decide which information is appropriate, discard be linked to a decision showing how it was previously considered options and so on, In other derived and hence which scenarios and previous words, the construction of a requirements views are shadowed by it. New scenarios and specification is non-monotonic and therefore, tools current views may be shadowed by subsequent to assist in the tracing of the diverse decisions decisions, but traceability is maintained by taken by analysts in the process of deriving a including these changes in the decision history. specification are considered as providing another source of assistance. The tracing of analysts' decisions in the current version of the prototype is shown in figure 8. The The current version of REST allows the source of 'decision history' window shows the details of the information in the UFB to be traced. This may decision labelled 'd1254' which has been selected include details of the source document, the analyst by the analyst as relevant to the current view of the or the date of the input session. In addition to this, concept MEMBER. These details include a the system provides traceability of analyst description of the type of decision made, the decisions. In order to facilitate tracing of analyst responsible, the date and a list of the decisions, two types of information need to be scenarios which have been shadowed as a result of stored. Firstly, facts which the analyst wishes to the decision. Subsequently, the analyst can review add without providing a documentary source, i.e. any of the scenarios listed. the analyst's own ideas and notes. Secondly, specific information concerning the decisions made about the data in the UFB, in particular decisions to do with the reconciliation of differing S. Conclusions views. This paper has argued that the demand for more reliable and cost effective information systems should force us to seek solutions in areas most likely to yield maximum benefits. One of the The informality which characterises much of the major emerging themes in the area of information initial requirements elicitation process is supported systems development research is the realisation by the linguistic basis of conceptual structures. that correct requirements specification holds the The representation is based on a user-defined type key to the construction of effective and flexible hierarchy of concepts occurring in the domain of systems. At the same time it is recognised that the interest. Linked to each concept in the hierarchy is area of requirements capture is fraught with a definition, together with examples of semantic problems such as uncertainty and vagueness in the and episodic information about the concept, users' requirements. complexity about the expressed as conceptual graphs. Our choice of modelled domain and lack of adequate techniques formalism also has implications for the validation and tools which can bridge the gap between users of the requirements independemfy of a design and developers. method. The linguistic basis of the concept and relationship definitions allows both the domain The work reported in this paper represents an knowledge and the existing application knowledge attempt to improve requirements capture and to be presented to the user in terms of the specification through the use of knowledge semantics of the domain rather than the semantics engineering techniques. It is proposed that imposed by any design method, thus broadening ( requirements specification is primarily a the applicability of the general approach to any knowledge-intensive activity and the work system development method. reported here follows the premise that the next generation of requirements engineering environments will be knowledge-based REFERENCES environments. To this end. the work presented complements other research efforts in the wider Adelson, B. and Soloway, E. (1985) The sphere of software engineering. notably those of Role of Domain Experience in Software Design, [Waters. 1985; Rich et ai, 1987; Pietri, 1987; in IEEE Transactions on Software Engineering, Keiser & Feiler, 1987; Lubars & Harandi, 1987]. Vol. SE-Il. No. 11, November 1985. In this paper a clear distinction is made between Adhami, E. (1988) An Environment for the requirements and design specifications. It is Execution and Graphical Animation of JSD argued that a requirements specification should be Specifications, International Workshop on concerned with the understanding of a problem Knowledge-Based Systems in Software whereas a design specification should pay Engineering, UMIST, Manchester, U.K., March attention to logical and physical structures that 1988. implement the requirements. Therefore, the development of a requirements specification van Assche F., Layzell, P.J., involves modelling the relevant application domain Loucopoulos, P., Speltincx, G.(1988) resulting in a model which is cognitive in nature. RUBRIC: A Rule Based Representation of In the past. requirements specifications have Information System Constructs. in Proc of the 5th played a passive role and have been viewed as Annual ESPRIT Conference. Brussels, Nov 14- fixed throughout the life of an information system. 17. 1988. Nort-Holland. pp.438-452. The thesis put forward in this paper is that a requirements specification needs to evolve to Balzer, R., Cheatham, T.E, Green, C., reflect changes m the application domain and that (1983) Software Technology in the 1990's: these changes must be implemented in such a way Using a New Paradigm, Computer. November 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 1983, pp. 39-45. Bird, B. Specifications. Knowledge-Based (1988) Building Intematicn