=Paper=
{{Paper
|id=None
|storemode=property
|title=Knowledge-Based Support for Requirements Engineering
|pdfUrl=https://ceur-ws.org/Vol-961/paper38.pdf
|volume=Vol-961
|dblpUrl=https://dblp.org/rec/conf/caise/LoucopoulosC89
}}
==Knowledge-Based Support for Requirements Engineering==
https://ceur-ws.org/Vol-961/paper38.pdf
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