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 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. . 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
In recent years there has been a growing
realisa tion that the development of large
information systems is becoming increasingly
more difficult as user requirements become
broader and more sophisticated. The complexity
which is exhibited by most contemporary
application domains and the subsequent problem
of developing automated information syste.":ls for
these domains has proved that the tradiuonal,
informal approach is no longer feasible since the
gap, between initial requirements st~tement and the
verification of these requirements 10 terms of the
implemented system, is too large. An altema~ive to
the traditional approach has been the adopuon of
paradigms which attempt to establish appropriate
management procedure~ withiln 'da ~fiysedtematkic
framework which recogmses we l I enli I tas s
and milestones. Examples of such methods are
Information Engineering [MacDonald, 1986], ISO
[
These proprietory methods and their associated
CASE tools pay particular attention to the
construction of a high level specification of a
system before the implementation of software.
Emphasis is placed in .establishi":g a clear
understanding of the funcl10nal requlfements of
the information system, since it has often been
reported that .o~er. 50% of software malf~nctions
have their ongtn 10 the process of requlfements
capture, the effect however not being detected until
later stages thus giving rise to a figure of 80% of
personnel resources being committed to t!te
debugging and testing of source code [Chapm,
1979,
Despite the increasi~g use of the~e meth~s,
however users conunue to expenence major
difficulti~s [
This paper argues that future development
methods and CASE environments must support the
early stages of requirements specification, by
providing J!lodelling formalisms, and funclions
which permIt the development of lIi/ormal models
and experimentation prior to developing a
specification according to the constructs of the
chosen method. To this end, the paper reports on a
prototype system which is used as part of a larger
CASE environment in the context of the Jackson
System Development (ISo) method [
A requirements specification represents both a
model of what is needed and a statement of the
problem under consideration [
Within requirements specification two basic
activities take place: modelling and analysis
[
In order to manage this process there is a need for support in three areas. Firstly, an analyst's reasoning process must be guided by some underlying process which is appropriate to the task as well as the problem domain. Such an underlying process must be generic in nature, so that all analysts may use its constructs, and must represent a standard approach within an organisation, so that a specification generated by a development team is achieved in an integrated way. Secondly, facilities must be provided for locating information about an evolving specification. Many facts are gathered during the process of constructing a· requirements specification and these facts must be correlated, irrelevant ones discarded and appropriate facts organised in meaningful structures. Thirdly, assistance is needed in the communication between analysts and end users during the phases of facts acquisition and specification verification. Capturing and verifying requirements are labour intensive activities which demand skilful interchange between those that understand the problem domain and those that need to model the problem domain.
Contemporary approaches provide support in all
three areas through the use of method steps,
project encyclopedias, and diagramming tools.
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
match the behaVIOur of expert analysts. .
A number of empirical studies have been carried
out in an attempt to better understand the process
of developing a requirements specification. The
differences in behaviour between high and low
rated analysts were investigated in three separate
projects [
Developers use information from the
environment to classify problems and relate
them to previous experience. On the other
hand lack of information provides triggers to
search for missing data. Empirical studies have
shown that experienced developers begin by
establishing a set of context questions and then
proceed by considering alternatives. One basic
prerequisite for using analogy during
requirements elicitation is the knowledge that
the analyst has about the domain under
examination. Loucopoulos and
Expert developers tend to start solving a problem by forming a mental model of the problem at an abstract level. This model is then refined, by a progression of transformations, to a concrete model, as more information is obtained. Developers are aware of the various levels of policy within a domain and use this knowledge to guide a. user during a requirements capture session. c. Fonnulation of Hypotheses
Hypotheses are developed as to the nature of the solution, as information is collected. An experienced developer uses hypothetical examples to capture more facts from a user but also to clarify some previously acquired information about the object system. Experience in the application domain seems to be an important factor in formulating likely outcomes of the solution space. d. Summarisation to verify their findings. It has been observed I Developers almost always summarise in order 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 set of questions. Summarisation may be used in order to clarify certain points from previous discussions or to encourage participants to contribute more information about the modelled domain. e.
Expert analysts normally have a good knowledge of the concepts involved in the business processes of the organisation being investigated. Some concepts will be common to information systems, regardless of the underlying organisation. This common knowledge enables an . expert analyst to approach a familiar analysis problem in a new domain with some expectations, which can be used to guide the investigation.
A further important finding of a study on the use
of the JSD method which has implications on the
use of development methods at the early stages of
the project lifecycle is the use of informal models
before any captured concepts are formulated
according to the method's prescribed formalism
[
initialfactgathering build model build model
I'·'''··........·,....••..·..... 1"..•..•..•..••..•..·,..··"··1 ! '11 ,~ !
.....z.-......- z ,
Do~iio;.p;;ii:,
JSDMODEL ~.
~
Analyst InteractiOl
- . , isi)",;,,;;/', I JSD NETWORK 4·····.,···~ L.-_ _~_--JJSDexpernse
SYSTEM On the basis of the findings of these studies a prototype tool known as the Requirements Elicitatton Support Tool (REST) has been developed in order to provide assistance at the very early stages of requirements capture. This tool has been developed within the context of the Analyst Assist system [Loucopoulos et ai, 1988] and attempts to provide assistance in capturing informal requirements, specifying and documenting requirements using the Jackson System Development Method (JSD), and validating the specification by prototyping and animation. REST provides facilities which: • • • • • 3.
encourage the development of informal models in the form of scenarios about the modelled domain maintain many different views about captured concepts enable the tracing of decisions taken by analysts about discarding or accepting particular scenarios assist the identification of candidate concepts by exploiting domain knowledge and assist in the mapping of informal models onto JSD model structures using JSD knowledge.
The Requirements Elicitation
Support System 3.1
The System Architecture 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 these concepts are interpreted in terms of JSD constructs. This database IS \,?pulated using a Fact Input Tool. This tool is gwded by an Elicitation Dialogue Formulator which makes use of the domain knowledge base and the current state of the UFB. It is feasible for the UFB to contain several different and possibly contradictory views of the concepts pertaining to the modelled domain. 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 modelled domain (but may be replaced at any point by any of the other views should the analyst's opinion is modified).
The lSD 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 UFB) and with the assistance of two diagramming tools shown in figure 2 as the lSD Input Tool component The lSD Method Advisor acts as an assistant on the method steps of JSD and provides consistency ( ( • Analyst
User Fact Base ~
Fact Input
Tool ~ • Elicitation
Dialogue
Formulator . -.. ·············1
Fact Base
toISD Translator
REST
Domain •••• FactB.ase .!•• Knowledge! Tracmg !
Exploiter i• Facility i
••• •• i
Domain
Iknowledgf .,
ISD Primitive
Identifier 1····jSD····
Method Advisor (Model & Network) ~ r .....
ISD
Spec ( Analyst .ISD Input ..... f
Tool checking on the evolving JSD Specification. The Fcu;t Base Tracing Fcu;j/ity is used to link a JSD specification to the concepts in the UFB 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.
Each item stored in the UFB or the JSD specification is linked to its source, in terms of the input session, date and analyst involved. This provides the capabability for tracing the history of the evolving models, and also allows for the summarisation of any subset of the specification. 3.2
The Model for Concept
Representation
In order to simplify the system architecture, the
knowledge bases and UFB share the same
underlying representation. The formalism chosen
is broadly based upon the use of conceptual
structures [
The formalism has been chosen for its flexibility and power of representation. Conceptual structures can be mapped onto ftrSt order logic statements, which allows for reasoning and consistency checks on the contents of the UFB. Sunnmarisation of the UFB in English phrases is made possible by the relatively simple mapping of conceptual graphs onto the constructs of a natural language.
Conceptual graphs are finite, connected bipartite I graphs, the two nodes of the bipartite graph being 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 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 fcu;t base which directly support the process of fact gathering. 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 fonnation 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).
A detailed description of the conceptual structures
employed in the model for !ffiST is beyond ~e
scope of this paper. The mterested reader IS
referred to [
Requirements elicitation in REST is based on the premise that an analyst should .be ~ble to d~fine any 'thing' of the modelled appltcatlon domam as a potential concept of interest and that the final set of concepts can only be decided upon after careful consideration of various scenarios about the role that these concepts play. Therefore, 'concepts capturing and resolution' uses: • • • • • • •
The semantics of conceptual graphs. Concepts are placed in semantic networks with the top level concepts being pre-defined as those of ENTITY, EVENT, QUANTIFffiR, 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 (DKB). The DKB 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 for example, in the representation of constraints, these must be dealt with special purpose rules. 4.
An Example Requirements Elicitation Session Capture and Representation of
Domain Specific Facts The purpose of capturing facts about an application domai~ is to aI.low !ill anal y~t to reason with all information which IS perceived to be relevant so that a system specification can be constructed. Because of the nature of the process of concept identification and capturing, it is advantageous to pe.rmit an analyst to carry out this process in a vanety of ways. FollOWing ~he discussion in section 2 about the underlymg characteristics of the requirements elicitation process, REST provides two main suppon facilities for the identification of concepts:
This facility allows an analyst to highlight keywords and phrases from a document. Single words are stored in the UFB as concepts. Phrases are analysed to fmd the concepts of interest and the con~eptual relations between them. The concepts Illclude those identified by the analyst and those which are known to the system as pan of domain knowledge. Where the concepts are know~ to the domain knowledge, the appropnate conceptual relations can be denved. thus producing conceptual graphs for storage III the UFB.
The concepts known t.o the. syst~m ~ described in terms of therr relationships With other concepts, and ar~ arran~ed i~ ~ concept hierarchy (in fact a lattice). This faclltty allows an analyst to classify concepts by placing them directly in the hierarchy in terms of each concept's perceived semantics. The placement of a concept at a particular n.ode ~as implications as to its allowable relations WIth other concepts. This in turn facilitates the development of scenarios based on these allowable relations which may be J:r~s"ntoo.'o a system developer for funher analysis.
As an example of the fact gatheri~g pr~ess. using REST consider the case of a Urnverslty Library. Text about this application domain is shown ~ the text analyser window in figure 3..Th~ underlmed text signifies that an analyst has hlghltghted these concepts as being of. interest. ~e process of storing these concepts m the UFB IS demonstrated graphically in figure 4. The schema 'cg l' represents the conceptual ~aph of the us~r supplied information. As a direct result of thiS, concept tvoe, schemas are created for the concepts "MEMBER,f, - "BORROW" and "BOOK". The
• Stage 11 Fact Gathering Prototype ~ ap'lons n Inpu' n,.uolu.1l '''.0.
II II: ~"uUnttlvb,r.l1ttiwth,lrltl~H¥anlolr ~Iw0ho' ~~lVif~Jlt••W'M'Plb,r. hBlWook~,u.Ptlaybb..~bo'rrdow.. A'orPI'uP~lb,r Pl&thWr•b•orrWowllknlo, Palfotr.,r thwahnleh, bt Ook, At A tliii":"""1'OOk' on lW Which art ~ art lubJ'C t to A dally 'lnl.
Booke Pl4W b. ClClild, l' th.y Gr. not alr.ady r•••rv.d bw ¬h.r l'I'JIlb,r.
cgl
cg2
Type 'BORROW'
I conceptual graph cg I is linked to each of these as a scenario for each 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, but in many cases an analyst might be faced with a number of different interpretations (most of which would be quite leginmate). By highlighting all possible interpretations of a concept, in particular those likely that an analyst would capture a situation in a I guided by the domain knowledge, it is much more more faithful manner. In the example, 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 by cg3.
The concepts represented in the UFB may be viewed (and further extended) by using the hieTa!'chy editor as shown in figure 5. Figure 5 shows the type of specialisation of each concept in relation to the pre-defmed system concepts. This means that each new concept introduced in the UFB inherits relationships with other concepts from its supertype. The placement of a concept in the hierarchy does not preclude subsequent alterations which would change its position in the hierarchy.
Such a change may result from further analysis and resolution of requirements.
- Stage II Fact GatherIng Prototype ===~::~~:1~r:.~..:;;n broun I
ADD. NIW DOHDOTI BOOK BORROW LOAR RERBER OYEROUE REnEW RETURR
SIAFF . SlUDERl III A un1vlrlltw ~•• ~.~b.r. "Ute bl 11tner or , 0 • unlVirfltw, Soak. "&ij b, borrowl (or up 0 three WI.kl, ~'t.r which t oneowk,"aUtleII.btll;;~e:.--BdO,ok. oAn"J'"JWbelrw~h&iWchbo41r"r1o~ ~no"ora,rtthaInUb~J'Cb Btotooke.."&dwalbly. ~fin.•d., 1( th.W art not Already r,••rued by .mtn,r "'"Dlr, ••,",on Il.o-P In addition to identifying individual concepts such as MEMBER, BORROW and BOOK it is possible to highlight phrases within the text which 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 6. 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 scenarios window. It is now up to the analyst working together with the end user to select the most appropriate interpretation which will subsequently be stored in the UFB. Resolution of information within the UFB 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 UFB.
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 UFB about a particular concept and for the rationalisation of this information. As an example consider again the University Library case study.
Figure 7 shows the information stored in the UFB, in the window labelled User Fact Base and Domain KIWwledl;e Scenarios about the concept MEMBER. The wmdow scenario options shows the available operations that can be performed on the UFB knowledge about MEMBER. The 'make current view' option relates to the agreed position as far as a concept is concerned; the 'discard' option allows the analyst to remove scenarios from consideration (they are nevertheless saved for possible future use); the 'join' option permits the merging of two or more existing scenarios. Figure 7 shows two unresolved scenarios for the concept MEMBER which 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 UFB. The join o~tion 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. (
Stage II fact Gathering Prototype ~ option,
Input n n"nalve n trio.
n broun I .dd to UFEI
fNT~ '''''lAMI 1M I t "Inu
cl_ nBeo r,b,o1oIkIe'rM.:b;o:rr:o7w~.::M:~:.:":b-l~r.::::::-=------------'~'" 1"I,,,,b'l"l liI1th bookl barrol,j ,110"'0,,., \lith book. art borroulet. cBOOKj' (PRRT l . [MEKBERl • (ROKT) • [BORROW]. (BOOK • (PA~T • [MEMBER • (OBJ) • [aO~~O~], 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.
book•.
KEKBER BORROW BOOK
A un1v.r.1~W 11brarw hal ~."b.r. who borrow
............ At>aly.. : bob 'Oro/OIl l2.o-P
I
At>aly.t : bob
- I Ana/YI' : bob
~,TtXT.) DEClSIDH DETRILS, rlalonl ,hadow ,nforcld b~ u.lr dMaot,elWolftl ••••bo1b0n' Ige'~3121 D.e1l1on I
d125'4 ShadowI I ·CO?S4 R.llre,.
DECISIDH DETRILS, rlalon, ,hadou enforced bW u••r analwltl bob date of •••• 10nl 1'8'/3/21 ( (
- Stage II Fact Gathering Prototype l1li ~DE,~cBlEeRl0InOElHErRllIaCteodrlto, -~----_.._--------------_..dllBS dl199 Cfl2l2 ~
DONClOT ..'aMlATIW N••olvld Inrornatlon Unresolyed InforMa'lon Disoirded In'ornltlan Dlol!llontl Orl,ln During the development of a requirements specification, analysts adopt certain lines of action, decide which information is appropriate, discard previously considered options and so on, In other words, the construction of a requirements specification is non-monotonic 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.
In the UFB, conceptual graphs attached to concept types are marked as either 'shadowed' or 'current'. At any given time only one current view of a concept is allowed. Each current view would be linked to a decision showing how it was derived and hence which scenarios and previous views are shadowed by it. New scenarios and current views may be shadowed by subsequent decisions, but traceability is maintained by including these changes in the decision history.
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 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 which can bridge the gap between users and developers.
The work reported in this paper represents an
attempt to improve 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. notably those of
[
In this paper a clear distinction is made between requirements and design specifications. It is argued that 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 which 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 m 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 unifyinj: representation formalism for the expressIOn of facts in the user fact base and knowledge within the domain knowledge-bases since such an approach has several advantages.
The informality which characterises 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, expressed as conceptual graphs. Our choice of formalism also has implications for the validation of the requirements independemfy 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.
System
Development, Keiser, G.E. & Feiler, P.H. (1987) An Architecture for Irneffigent Assistance in Software Development, 9th International Conference on Software Engineering, March 30 - April 2, 1987, Monterey, USA.
Layzell, P.J. & Loucopoulos, P. (1987) Systems Analysis and Development, Chartwell Bratt, 2nd edition.
Loucopoulos, P. and
Loucopoulos, P., Layzell, P.J.,
A Knowledge-based Requirements Engineering Environment, Proc, Conf. on Knowledge Based Software Assistance (KBSA), Utica, USA, 2-4 August, 1988.