Enhancing a requirements baseline with scenarios - …julio/Slct-pub/baseline.pdf · Enhancing a...

Requirements Eng (1997) 2:184-198 �9 1997 Springer-Verlag London Limited Requirements

Engineering

Enhancing a Requirements Baseline with Scenarios

Julio Cesar Sampaio do Prado Leite a, Gustavo Rossi a, Federico Balaguer b, Vanesa Maiorana b, Gladys Kaplan b, Graciela Hadad b and Alejandro Oliveros b aDepartamento de Informatica, PUC-Rio, Rio de Janeiro, Brazil DDep. de Investigacion, Universidad de Belgrano, Buenos Aires, Argentina

Scenarios are well recognised as an important strategy towards understanding the interface between the environment and the system as well as a means o f eliciting and specifying software behaviour. We adopt a broader view of scenarios. For us, a scenario is an evolving description o f situations in the environment. Our proposal is framed by Leite's work on a client-oriented requirements baseline, which aims to model the external requirements o f a software system and its evolution. Scenarios start by describing the environment situations, according to the main actions performed outside the software system. Scenarios also help to clarify the interrelation between functional and non-functional requirements. We have validated our strategy and the related representations based on case studies.

Keywords: Requirements baseline; Requirements modelling; Scenarios; Traceability

1. Introduction

The issue of traceability, a major concern in software engineering, becomes even more important, if we understand the software process as a "complex, multi loop multilevel feedback system" [1]. As such, feedback is also present in the definition of a requirement baseline. In particular, it is important to stress the interactive nature of requirements definition. Data from real projects [2] have shown that the tasks of gathering information, identifying requirements and

Correspondence and offprint requests to: Julio Cesar Sampaio do Prado Leite, Departamento de Inform,'ttica, PUC-Rio, R. Marqu0.s de S. Vicente 225, Rio de Janeiro, 22453-900, Brazil. Email: julio@ inf.puc-rio.br

validating them do occur interactively. The number of interactions reported varies from project to project, but most of the surveyed projects had three or more interactions.

A requirements baseline is a structure which incorporates descriptions about a desired software system in a given Universe of Discourse (UofD). It is perennial. Although it is built during the requirements engineering process, it keeps evolving as the software construction evolves. Leile [3] understands the UofD as "the overall context in which software will be developed and operated. The UofD includes all the sources of information and all the people related to the software. These people are referred to as actors in this UofD. It is the reality trimmed by the set of objectives established by those demanding a software solution." As such, the evolution of a requirements baseline occurs in the context of an UofD.

Figure 1 tries to express the idea of evolution in the context of the software process. Note that a baseline evolves both from a maintenance time perspective as well as from a development time perspective. Thus, a requirements baseline has to be capable of evolving in two dimensions, in the interactions akin to the requirements definition and in the interactions due to the reification of the client's needs. Feedback is always present as a reaction to the availability of the software (different representations) in the UofD, which also changes due to the presence of software. Controlling these complex feedback loops is hard, and for a long time the software engineering approach has been one of freezing reality. Today, we understand the need for methods, techniques and tools that take these feedback loops in consideration. Our work deals with this problem and provides a vision centered on the concept of a requirements baseline, which makes it possible to trace these needs to their origins, that is, in the UofD.

Enhancing a Requirements Baseline with Scenarios 185

Traceability is seldom present in the initial requirements engineering process. This paper reports on a proposal for extending the requirements baseline model [3] with a scenario view, in which evolution is the major driving factor. The scenario view should evolve, as part of the requirements baseline, during the software construction process. The baseline is perennial, so that scenarios will change as software development progresses. The baseline cannot be considered to be the requirements specification. This specification will be built based on information contained in the baseline.

The requirements baseline model [3] understands that software is a subsystem of a more complex system, called the macrosystem. As a consequence, the first requirements to be considered in the baseline are external requirements, that is, requirements of the macrosystem. The overall design of a macrosystem helps establish the Universe of Discourse (UofD) for

the software production process. For instance, if we are producing embedded software for an airplane engine, the macrosystem will be the engine design, which will help to establish the UofD within which the software process will take place. This vision is similar to the difference made by Jackson [4] between application domains and the machine. In our case, focusing on external requirements means basing the evolution of requirements expressions on designations anchored to real phenomena occurring in the application domain [4].

Our understanding of scenarios is a combination of a series of ideas presented in the literature [5,6,7] [8,9], to which we added four main concepts:

�9 a scenario starts by describing situations in the macrosystem, and its relation with the outer system. We first consider the interfaces of the macrosystem, and then describe the interfaces of the software with its macrosystem:

Universe of Dlscourtm

Fig. 1. The context of the requirements baseline.

186 J. C, S do P. Leite et al

�9 a scenario evolves as we progress in the software construction process;

�9 scenarios are naturally linked to the LEL (Language Extended Lexicon) [10] and to the basic model view (BMV) of the requirements baseline [3];

�9 a scenario describes situations, with an emphasis on the behavioural description. Scenarios, like BMV, use a natural language description as their basic representation.

The Language Extended Lexicon is a metamodel designed to help the elicitation of the language used in the macrosystem. This model is centred on the idea that a circular description of language terms improves the comprehension of the environment (the macrosystem); see Figs 2 to 5 for an example.

The basic model view (BMV) is a structure which incorporates sentences about the desired system. These sentences are written in natural language following defined patterns. Figure 6, using an entity relationship notation, shows the basic conceptual model behind the basic model.

Our scenario model view is a structure composed of goal, context, resources, actors and episodes. Goal, context, resources and actors are declarative sentences. Episodes are a set of sentences according to a very simple language, that makes it possible to give opera- tional descriptions of behaviours.

The addition of a scenario view to the requirements baseline makes it possible to uncover a series of aspects to which neither the LEL not the basic model view give particular attention. The explicit introduction of goals,

Photo Cabin

�9 Notion: - A sector of the Documents and Cert i f icates Division. - It is where the ci t izen's picture is taken and charged.

�9 Behavioural Response: - T h e fo rm is stamped with the same number as the

picture. - The ci t izen receives two copies of the photo. - The Photo cabin clerk files away the third copy.

Fig. 2. LEL entry: photo cabin,

Check Fingerpr ints

�9 Not ion:

- A n action taken by the Fingerpr int Divis ion to verify if the citizen is who he/she says he/she is.

�9 Behavioural Response: - I n the case of request new passport the f ingerpr in t

form is filed away, - I n the case of request passport renewal the Finger-

print Division checks the fingerprints in the fo rm with the fingerprint form.

- In the case of problems with the fingerprints, the ci t izen has to be directed to the Revis ion Division.

Fig. 3. LEL entry: check fingerprints.

Form

�9 Notion: - A printed document containing blanks to be filled in by a

citizen who wishes to request a new passport or request passport renewal.

- It registers the ci t izen's data. �9 Behavioural Response:

- It is completed by the cit izen. - It is stamped by the cash ier clerk, - It is stamped by the photo cabin clerk. - I t is filled in, signed and stamped by a General Index

Division clerk. - I t is filled in, signed and stamped by a Fingerpr int

Division clerk. - It is appended to the folder. - The stub is detached from the form.

Fig. 4. LEL entry: form.

Stub

�9 Notion: - I t is the detachable bottom part of the fo rm which is

requested in order to receive the passport. - It includes the ci t izen's identification number,

�9 Behavioural Response: - It is signed, stamped and delivered to the ci t izen at the

Reception Cabin. - The ci t izen presents it to the Del ivery Sector in order to

receive the passport.

Fig. 5, LEL entry: stub,

the relationship between resources and the identification of actors enrich the requirements baseline by extending its static amplitude. Episodes give the requirements baseline a representation capable of dealing with behavioural aspects. For instance, in the basic model view, we have actions and external events linked to these actions in a sequential fashion. How- ever, it is not possible to represent conditions, exceptions or parallel events. A language able to express such situations as episodes of a scenario improves the capability of describing what does happen in the macrosystem.

If, for one side, the addition of a scenario view augments the expressive power of the requirements baseline, it is also the case that it improves the traceability capability of the baseline. For instance, having links to actors, resources and episodes of the macrosystem helps to anchor the origins of the requirements. Gotel [11] has pointed out that most of the research and use of traceability methods and tools happens after the availability of a software specification. We understand that part of our work addresses this issue. Unlike other proponents of pre-traceability models [12], we do not make explicit the link to a requirements specification. We understand that the construction of a requirements specification is a process that comes after the availability of a requirements baseline.


a .

decomposed into

" / . . . . 4 I . . . . . . . .

D

f a t e d

!

n ~ e r a t e )

have

Fig. 6. The ER diagram for the baseline basic model.

187

The organisation of our text follows Parnas' advice [13]. We present the proposal as it should be, which is not exactly how it was used in our case studies. As such, the proposal described and exemplified in Section 2 is the result of cleaning up several aspects observed during the process of using the proposal in a real case. The same applies to Section 3, where we give more examples of scenarios and describe how they evolve. It is also important to note, that our description focuses on the representation, its navigation (presentation) and how it can be managed from the point of view of traceability. Although we do not focus on the process of producing the scenarios, the L E L or the basic model, which are treated elsewhere [10,14,15], in Section 4 we briefly describe observations about the production and usage of scenarios. Section 5 reports on related work. We conclude summarising the ideas, stressing our contribution and pointing to future work.

2. The Requirements Baseline Conceptual Model

As a consequence of adding scenarios to our baseline, it is now structured as follows:

�9 the lexicon model view �9 a basic model view �9 a scenario model view �9 a hypertext view �9 a configuration view.

It is important to note that the configuration view and the hypertext view are orthogonal to the other three. These views may be seen as indispensable support services to be provided by the baseline in order to guarantee traceability (configuration view) and access to the stored information (hypertext view). The hypertext supports works as an integrator of the lexicon, the basic model and the scenario views, enabling the definition of links between these views.

2.1. LEL, the Lexicon View

The Language Extended Lexicon is a representation of the symbols in the problem domain language. The L E L is anchored on a very simple idea: understand the language of the problem, without worrying about understanding the problem [10]. It is a natural language representation that aims to capture the vocabulary of an application. The Lexicon's main goal is to register signs (words or phrases), which are peculiar to the

188 J. C. S do P. Leite et al

domain. Each entry in the lexicon has two types of description, as opposed to the usual dictionary which has just one. The first type, called Notion, is the usual one and its goal is to describe the denotation of the word or the phrase. The second type, called Behav- ioural Response, is intended to describe the connota- tion of the word or the phrase, that is, it provides extra information about the context at hand. Besides using this extra information, L E L construction heuristics force the use of links between the entries in the lexicon.

Concerning this basic representation, we establish two major principles.

�9 When describing a notion or a behavioural response, maximize the use of the signs of the language extended lexicon. We call this the principle of circularity.

�9 When describing a notion or a behavioural response, minimise the use of signs external to the target domain. When using external signs make sure they belong to the basic vocabulary of the natural language in use, and, as much as possible, have a clear mathematical representat ion (e.g. set, belongs, inter- section, function). We call this the principle of minimal vocabulary.

By imposing the principles of minimal vocabulary and circularity we can define a self-contained set with several links between its elements, thus forming a graph. This graph is in reality a hypertext document, where the authoring rules are the structure of L E L and the two principles. We have designed a customised hypertext system [10]. HyperLex, which implements the structure of L E L and provides support for its use. HyperLex not only provides support for the acquisition of lexicons but also provides reports on several statistics regarding the hyperdocument .

Figures 2 to 5 exemplify the use of the lexicon and are based on the Argentina passport emission domain 1 [14].

2.2. Basic Model View

The basic model extends the entity-relationship frame- work [16[, and its metamodel is shown in Fig. 6. The conceptual model behind the BMV was proposed in [15] and was extended in [3]. The basic idea behind the model is the representat ion of external requirements, that are propounded by the clients of the macrosystem. The major concept is that of action, used to describe

1Please note that all the examples were written in Spanish and were loosely translated to English.

activities that occur in the macrosystem. Each action has a client, who is responsible for that action. External events are the triggers for the actions, and either happen in the outer system of the macrosystem (external stimulus) or are determined by certain intervals of time ( temporal stimulus). Inputs and Outputs are the interfaces between the external requirements and the software system. Inputs are related to the external stimulus and Outputs to the external stimulus or temporal stimulus. Figure 7 provides an example in the passport domain.

2.3. The Scenario Model View

In the same style as the basic model view [3] we describe the scenario model again as an extension of the entity-relationship f ramework [16]. Figure 8 shows the entity-relationship diagram of the scenario model behind the baseline. Note that, in the entity-relationship diagram, an episode 2 can itself be expressed on a scenario, thus enabling the possibility of decomposit ion of a scenario in sub-scenarios.

We describe below the entities pertaining to the ER model 3,

�9 Title - - The title of the scenario. In the case of a sub- scenario, the title is the same as the episode sentence (see below), without the exceptions and/or constraints. It has the following structure: [Phrase I ([Actor I Resource] + Verb + Predicate)]. Ex: Request a new passport. (Phrase)

�9 Goal - - An objective to be achieved in the macrosystem. The scenario describes the achievement of the goal. It is described by the following structure. [Subject] + Verb + Predicate. Ex. Charge the citizen the passport fee. (Verb) (Predicate)

�9 Context - - Describes the geographical location (setting) of the scenario as well as an important initial state. Context is represented by a sentence with the following structure: Location + State Where Location is: Name. Where State is: [Actor I Resource] + Verb + Predicate + {Constraint}.

2Episodes are a set of particular actions or situations that describe the behaviour of a scenario. A scenario may have more than one episode. An episode can also be described as a scenario. 3 + means composition. { x I means zero or more occurrences of x. 0 is used for grouping, I stands for or. and [x] denotes that x is optional.


;r client il~ ext. stimulus

acUon ]l~. input

EE

EE exLevent output

189

Has to be

Fig. 7. The BMV instantiated for the action REQUEST A NEW PASSPORT.

Ex: Cashier, (Name) Citizen has received the forms and (Actor) (Verb) (Predicate) must be in the cashier 's line. (Constraint)

�9 Resource - - Means of support or devices that must be available in the scenario. Resource is represented by a sentence with the following structure: Name + [Constraint}

Ex: Stub, (Name) which must match the name of the requesting citizen (Constraint)

�9 Actor - - A person or an organisation structure that has a role in the scenario. It has the following structure: Name

iR ht~-nded b~ i

1

I

B

satisfies >

1 " :" '~" / ' ; ' i ~: ' l

I constraint

E 1

U l

m,

has 1

triggers 4 P

l::pressed

(0,1)

Involves

m Fig. 8. The ER diagram for the scenario model.


Ex. Cashier's clerk �9 Episodes - - A series of episode sentences which

detail the scenario and provides its behaviour. The following partial BNF description gives an idea of how episodes are structured. (episodes) :: = (series) (series) :: = (sentence) I (series) (sentence) (sentence) :: = (sequential sentence) I (non-sequential sentence) I (conditional sentence) (sequential-sentence) :: = (episode sentence) CR J(conditional sentence) :: = If (condition) Then (episode sentence) CR (non-sequential sentence) :: = # (series) #. Where (episode sentence) is described by the following structure: [Actor I Resource] + Verb + + Predicate + {Constraint} + {Exception} Ex: Photo Cabin clerk takes Citizen's photo. (Actor) (Verb) (Predicate) Exception: Camera is not working,

The most important attributes of our ER model are the Constraint and the Exception attributes. A Con- straint is a scope or quality requirement referring to a given entity. It is represented by a short sentence with the following structure: MUST + Verb + Predicate. An exception causes serious disruption in the scenario, implying a different set of actions, described separately

as exception scenarios. It is represented by a short sentence, or by a small paragraph and usually reflects the lack or malfunction of a necessary resource.

The terms: Name, Location, Subject, Verb, Predicate, Actor and Resource can be chosen from the Language Extended Lexicon table, a structure that makes the usage of a controlled vocabulary possible.

Below we give a scenario description related to the BMV of Fig. 7 and one sub-scenario of the REQUEST A NEW PASSPORT scenario. The sub-scenario FINGERPRINT

CABIN CLERK TAKES CITIZEN'S FINGERPRINTS is described in graphical form (Fig. 9). Observe below, that the links to the LEL are given by the underlined terms. TITLE:

Request a New Passport. GOAL;

Satisfy the initial requirements for a new passport. CONTEXT.

Documents and Certificates Division. The citizen does not have a passport. ACTORS:

Citizen Cashier's clerk Fingerprint Cabin clerk Photo Cabin Documents and Certificates Division clerk RESOURCES:

Camera

C o n t e x t

Fingerprint Cabin Citizen has an aut. Form

Goal Obtain citizen's Fingerprint Id.

Resource +

i,nk i

Scenario Fingerpdnt Cabin clerk takes citizen's fingerprints

satisfies

Episode i CiUzen gives the i form to clerk : !

h u n Resource

\ Flngerpdnt \ form, must

present if...

Resource

I

be I I n v o l v e s ~

Actor Actor + F+Ingermlnt i I Clllzen ! + CamnClerk I

Fig. 9. An instantiated scenario view.

Episode if citizen has no I id; lhen clerk + I pdnts aut. Fingers ! on fingerprint i ,orm ! Episode Clark pdnts the I r +1!I~ ,'S + right

I thumb on the form

Episode

Cltlzeds cleans I his/her hand in paper towel

Clerk returns I , the form to citizen

Episode , I C i ~ . haa no id., clerk returns ~f lngerpdnt -fo~ to ~e: citizen . . . . .


F o r m

Empty Passport Stub Citizen Documents EPISODES:

Citizen fills in the form. Constraint: Fill in with a pen. Documents and Certificates Division clerk checks the form. Constraint Form must be correctly filled in. Exception. Missing documents. # Photo Cabin clerk takes citizen photo. Exception: Camera is not working Fingerprint Cabin clerk takes Citizen's fingerprints # Citizen pays the passport fee. Citizen signs the passport. Citizen receives stub.

2.4. The Hypertext View

The hypertext view is orthogonal to the BMV, LEL and SMV. The use of hypertext for the BMV is described in [3] and the LEL, itself in hypertext, is described in [10]. Here we will focus on the hypertext view from the scenario standpoint.

There are many relationships to be explored among scenarios and other components of the requirements baseline. From each scenario we derive one or more hypertext modes which are related by hypertext links. We may have one node class for each type of entity defined in the scenario model (Fig. 8). Links in turn are derived in three different ways.

�9 From existing structural relationships among scenarios, for example the sub-scenario relationship. Struc- tural relationships allow us easily to navigate composite structures (such as scenarios composed of episodes) in a closed context.

�9 From information in the LEL table, which allows us to relate different scenarios that use the same resource or in which the same actor participates; for example we can define a hypertext index containing all scenarios in which Forms are used (and navigate among them as explained below).

�9 Defined ad hoc. In this case we may add relationships with more complex semantics; for example we may relate scenarios that use the same kind of resources of scenarios that may occur in the same area of the organisation. The reason why hypertext nodes are derived from

scenarios is that we can build different view of the same scenario according to the user profile or task, e.g. given t h e s c e n a r i o REQUEST A NEW PASSPORT w e c o u l d d e f i n e

a view that is useful for specific clients. Each view defines a hypertext node and the set of nodes and links defines the hypertext. This approach is now usual in

modern hypermedia design approaches [17,18] and allows us to focus on the particular concern of the different stakeholders using the hypermedia; for example, while the software engineer may be interested in exploring certain relationships in more detail, we may want a domain expert to have a global view of the scenario baseline helping him to explore facts in his domain. We may also concentrate all information we want from a scenario in a composite node containing: Title, Goal, Context, and Resources as attributes and the set of episodes as parts of the node and reachable by following structural links. When episodes are them- selves scenarios we have an interesting navigation pattern that will be described below.

As we may have a large number of nodes and relationships, we must use some structuring mechanism in order to organise the information and prevent cognitive overhead when we are navigating the hypermedia. We organise the hyperspace in Navigational Contexts [18], a set of nodes that are closely related with each other and that we intend to navigate in a straightforward way. Navigational Contexts may be derived from composite nodes: the set formed out of the components, with 1-to-n links: the set formed out of target nodes, or grouping nodes sharing some property. The same node may appear in different navigational contexts and its appearance may be different each time because we "decorate" it with context-related information. Some navigational contexts are derived from the compositional structure of scenarios as defined in the scenario metamodel; for example, we can consider the navigational context formed out with all sub-scenarios of a given scenario and include the corresponding links which allow us to reach the first member of this set and also remaining members of the set (even recursively, see Fig. 10). Note that we have added links between the components of scenario A. When we are navigating such a context as the episodes of A, we suppose that all the components of A are connected by the next link, corresponding the compositional structure of A, and the same is true for A.1.

Another interesting context is derived from information contained both in the scenario and in the L E E For

Fig. 10. Navigational Contexts.


example, we could select an entry in the L E L table representing a resource in the scenario model and find all scenarios using that resource. These nodes may not be related by a hierarchical relationship existing in their conceptual counterparts, as in the previous example, though their corresponding nodes will be organised in a similar way, i.e. as a set with a navigation strategy which allows us to navigate the whole set easily. Other interesting relationships arise when we take into account the configuration view, so that we could build a set formed from the different versions of a scenario. Note that the same scenario may be navigated in different contexts and that the meaning of next is always the next scenario (node) in that context.

As mentioned before, it is important to note that by separating scenarios from scenarios views (the hypertext nodes) we can provide different appearances to different users' profiles, and we can organise the hypertext navigation according to each user's need. For instance, we would not define the navigational context called versions of a given scenario for some kind of users, although we would certainly define this context for members of the software engineering team. At the same time, we would define some guided tours (i.e. navigational contexts whose nodes have been chosen ad hoc) for domain experts.

We have enriched the concept of LEL table as described in [3] by including information about scenarios (see Fig. 11) in this way, for example, two scenarios that are not related structurally but have some term in common may be automatically linked. However, as this approach would cause a link explosion in the hypertext view, the software engineer has to select the important links.

We may also want to link two scenarios that are not related structurally, i.e. the sub-scenario-of conceptual relationship, or such that they do not share some item in the LEL. This kind of link is not generated automatically in our model and must be explicitly described. This may happen when we discover a new

+ Fmm

LEL TABLE I DELTA TABLE

�9 TERM ,ENTITLE8 SCENARIOS, ADDRF.88ES

8r Fing, Cab. /b~llr:. Fing. Cabin ded ( i lum c b " clldt . flnoerpdntl i . . . . - ' "

Output: Form Episode: Citizen

i , s t ~ :] i ~ Stub] I m l ~ : C l U ~ ' ~ " r r i c l l ~ s stub

I

term that may be considered for further inclusion in the L E L table. We use an approach similar to [3]; by using a Delta table and thus reducing this kind of navigation to the one described above.

Finally, scenarios are linked to nodes representing entries in the L E L table and to nodes reflecting information in the Basic Model View (BMV). Entries in the LEL table appear in a scenario node as hotwords, for instance, Form in the scenario REQUEST A NEW PASSPORT is defined by the LEL, Fig. 4, and is used at the BMV described in Fig. 7. Figure 12 gives an example of the navigational possibilities of our baseline. It is interesting to note that, by providing a rich set of navigational contexts and links, we are, somehow, replacing the need to define specific queries to the baseline metamodels as we provide different ways to reach each item of information in the baseline by navigating it. As many navigational contexts may be created automatically, we free the requirements engineer from this task.

2 .5 . T h e C o n f i g u r a t i o n V i e w

The configuration view is essential in order to maintain the traceability of the products and their revisions. The LEL, the BMV and SMV (Scenario Model View) are all subject to configuration and version control. At a given time a view from the baseline may be requested based on the actual configuration or on past configurations. Each version of each model keeps the following information: date, time, person making the change (user), reasons for the change (change trigger, date of trigger, authorisation) and type of change (input, modification, exclusion).

I ~ " ! Refers to : + : 4 : : 1 i

~ t ! a i :) ~ = m t , I

b y _ _

" -~ ! ! . . . . . . ~ ~ ~-'~-~ . . . . . . I ~ ,:.~ ~ .....

! - , ; ( ; . . . . . . . . . ; : : + Q l l l l l ( l l l { l l : - . . ~ . + , . ; ~ i J; ~ : ' i : ~ + ~ ' : : - ' ; ' ~ m p ~ t , m I . . . . . . , . . . . . . . I F, + . . . . . t : " - 1 . = u ~ +-; : i emt " :l

Fig. 11. Enr iched LEL table. Fig. 12. An examp le o f hyper tex t l inks.


The consistency of the configuration is warranted by consistency constraints determined by each model. As such, change operations trigger a process for consistency checking responsible for the consistency of a given configuration. If, in the SMV, an episode is excluded, and if it is described as a sub-scenario, the sub-scenario must be excluded as well. The example of the configuration view is given below in Section 3, where we stress the evolving aspect of SMV.

3. Scenarios

In this section we give more examples of scenarios: we show scenarios for the Agenda de Reuniones 4 case study [19] and explore the evolution aspect of the Passport system. We conclude with a brief description of the process used in both scenario elicitation and evolution.

3.1. Meeting Scheduler

The meeting scheduler case study was proposed by van Lamsweerde [20] as a concise description of a real and complex problem arising in every organisation. In our case study we have used the Universidad de Belgrano (UB) as the target organisation for a meeting scheduler system [19]. Using unstructured, structured interviews and meetings we have built the UB Meeting Scheduler LEL and a set of scenarios. The terms and the situations are specific to the Universe of Discourse at hand. Below we list two of the UB Meeting Scheduler scenarios. The underlined terms are the terms defined in the UB Meeting Scheduler LEL. T I T L E

Organise a Meeting. GOAL:

Make sure that the meeting will be developed efficiently. CONTEXT.

It must happen after the meeting agenda design. ACTO R S:

Initiator Secretary Participants RESOURCES:

Equipment and Supplies Meeting Themes List of Participants Agenda

4Meeting Scheduler

Communication media (telephone, fax, post-office, computer) EPISODES:

The initiator gives instructions to the secretary about the invitation to a meeting. Call a meeting. Exception: Cancel a meeting, Change a meeting date, Change a meeting requirements. # Inform attendance. Inform no attendance. Request equipment and supplies. Confirm the meeting with participants. The secretary makes sure that that equipment and supplies are available for the meeting date. The secretary, makes sure that the physical space is available for the meeting. # The following episodes are sub-scenarios (see Fig. 9) of the O R G A N I S E A MEETING" C A L L A MEETING. C A N C E L A

MEETING~ C H A N G E A MEETING DATE, C H A N G E A MEET-

ING REQUIREMENTS, INFORM AI-II:zNDANCE, INFORIVl NO

ATTENDANCE, R E Q U E S T EQUIPMENT AND SUPPLIES, CON -

FIRM THE MEETING WITH PARTICIPANTS. Below we detail one of them. T I T L E

Confirm the meeting with participants. GOAL:

Contact the participants in order to remind them of a meeting. CONTEXT.

An invitation to a meeting must be issued beforehand. Constraint: Participants that have a note of absence are not asked. ACTORS:

Secretary Participants RESOURCES:

List of Participants Communication media (telephone, fax, mail, computer) EPISODES:

The secretary confirms with each participant, using a communication medium, the meeting date, time and locale. Constraint: Participants must be in the List of Participants. If participant, did not provide a note of absence. Then the secretary asks for the confirmation of participation to the meeting. The secretary makes note of the confirmation in the List of Participants.

3.2. Scenario Evolution

In order to show how scenarios evolve, we used the Fingerprint Cabin clerk takes citizen's fingerprints from

194 J. C, S do P. Leite et al

clerk

c i t izen

4

clerk

setup |

hands on o

result

conf i rm |

cWzen , print

Mach ine F ingerpr in t ; Objec t I i

resul t I

f lngerl~rinta

I I

J

Person Ob lct

I I

) ; I save m e , , save

save m e

~ result

Da tabase

Fig. 13. The use case for fingerprint cabin clerk takes citizen's fingerprints.

the scenario REOUEST A NEW PASSPORT (see Fig. 9). This evolution aims to show how a scenario changes from a pure macrosystem view to one that deals with the interface of the future computer system. After the two versions we show the use case [8] representation for describing version 2 (Fig. 13). Our work regarding scenario evolution is in the early stages, but we believe that the use of a hypertext and a configuration management approach will provide a solid basis for the study of interconnection aspects of evolving scenarios. In Version 1, we have the following information:

�9 D a t e : 2/15/96 �9 Time 2:00 pm �9 U s e r : Federico �9 Trigger: The passport case study �9 D a t e o f Trigger: 10/20/95 �9 Type: Inclusion

T I T L E :

Fingerprint Cabin clerk takes citizen's fingerprints. G O A L :

Obtain citizen's fingerprint identification. CONTEXT.

Fingerprint Cabin. Citizen has an authorised form. ACTORS:

Fingerprint Cabin clerk. Citizen. R E S O U R C E S ;

Form, which must have been previously checked. Ink. Fingerprint form, must be present if citizen has no prior identification.

EPISODES:

Citizen gives the form to clerk. If citizen has no prior identification, Then clerk prints the citizen's fingers on the fingerprint form. Clerk prints the citizen's right thumb on the form. Citizen cleans his/her hand in paper towel. Clerk returns the form to the citizen. I f citizen has no prior identification, Then clerk returns the fingerprint form to the citizen. Version 2 has the following information:

�9 D a t e : 3/10/96 �9 Time: 3:30 pm �9 User: Federico �9 Trigger: The discussion about how the Fingerprint

Cabin would work with the fingerprint reading machine.

�9 D a t e o f Trigger: 3/1/96 �9 Type: Modification

T I T L E

Fingerprint Cabin clerk takes citizen's fingerprints. G O A L :

Obtain citizen's fingerprint identification. CONTEXT.

Fingerprint Cabin. Citizen has an authorised form. ACTORS"

Fingerprint Cabin clerk. Citizen. R E S O U R C E S :

Form, which must have been previously checked. Fingerprint reading machine. Fingerprint database. EPISODES:

Citizen gives the form to clerk. Clerk gives instructions on how to position the citizen's hand. Clerk positions the form for printing and starts the machine. I f Fingerprint reading machine signals red, Then clerk makes sure that the citizen's finger is properly posi- tioned and restart the machine. # Machine prints the fingerprint on the form. Machine saves the information on the database. Con- straint: Save must be done in less than four seconds. #

Version 2 brings to the scenario terms that were not present in the original LEL, such as: prints the fingerprint, database, restart the machine and Finger- print reading machine. These new terms must be defined in a new version of LEL in the configuration related to the scenario evolution as pictured above. Figures 14 and 15 detail possible descriptions of two of those new terms.


Fingerprint reading machine/Machine

�9 Notion: - An object responsible for receiving the fingerprint image from

the fingerprint reading device and prints the result. �9 Behavioural Response:

- It is act ivated by the se tup service. - It sends the citizen's fingerprint image to the person object. - Clerk confirms the result. - It receives resul t from the da tabase object.

Fig. 14. LEL entry: f ingerprint reading machine.

Pdnts the fingerprint/Prints the result

�9 Notion: - A service provided by the mach ine object, that prints the

fingerprint image on the form. �9 Behavioural Response:

- I t is act ivated by the message resul t from the database object.

- It requires a previous con f i rms by the clerk. - The fo rm is returned to the citizen.

Fig. 15. LEL entry: prints the fingerprint.

3.3. Scenario Processes

We have been using several different strategies for producing scenarios in order to learn more about their relative merits. For the meeting scheduler case [19], we decided to base the scenario construction on the LEL. The overall strategy is to focus on the main actors appearing in the L E L and from their behavioural responses identify possible scenarios (situations). We have mostly concentrated on pruning the descriptions and how to manage them. Future work will pay more attention to the process side.

With respect to evolution, we have made several exercises with both the passport case study, as seen above, as well as with the meeting scheduler. The scenario and LEL evolution exercises have showed us that the idea of maintaining an evolving requirements baseline is feasible and necessary, but demands a very strong configuration management platform. The amount of work necessary to keep track of different versions and different configurations is taking most of the time during the exercises, which were done with very little computational support. It is important to note that L E L evolution is not simply a question of adding more entries. The entries have to be based on some concept and should interact with existing terms.

The strategy being used for scenario evolution is based on an object-oriented architecture. As we take into consideration design choices and constraints, objects start to appear in the scenarios as the interface between the macrosystem and the software system. We believe that this characteristic of maintaining an anchor

195

in the Universe of Discourse is a major aspect of our research.

4. Observations on the Use of Scenarios

The work reported here presents the first results from a joint project between PUC-Rio and Universidad de Belgrano. Our project [21] explores the use of scenarios through the development process, looking into how to evolve scenarios towards testing strategies. Our first step was to investigate an initial representation for scenarios. We decided that Leite's previous work on natural language based representations for requirements could be used as a starting point. So we went on to look at how scenarios could be defined at the same level of abstractions as the LEL and the BMV.

Once we decided to integrate the scenario into the requirements baseline, we established a plan with the following steps:

�9 review of the literature on scenarios, �9 definition of a basic scenario representation, �9 application in a restricted case study, �9 application in a real case by two different groups �9 evaluation of case studies.

The review of the literature confirmed our hypothesis that we had an innovative view of scenarios. The basic representation we have sketched did not use a standard for episode description, constraints or exceptions. We also did not have a very clear idea of how to deal with scenario decomposition. We first used the scenario in the restricted elevator problem [22] and then decided to use the issue of passports in Argentina as our domain. One group elicited the scenarios departing from the LEL without using the BMV [14], and the other group constructed the BMV for the domain and anchored the construction of the scenarios in the BMV [23].

The case study reported in [14] used both unstructured and structured interviews to produce a first version of the LEL, which was then validated with the user (employees of the Argentina Passport Office, Policia Federal). Scenario construction used the following elicitation strategies: observations, structured interviews and the LEL. The construction of scenarios led to some changes in the LEL. The L E L has 38 entries. The group decided to give more emphasis to the entities (objects, actors and states) and less to the process (actions) on the LEL entries, so several verbal phrases pertaining to the problem were not included in the LEL, but were present in the scenarios. In describing the scenarios, the group listed 24 scenarios, using 20


sub-scenarios, with an average of 5 episodes each. The group discovered the need to use special comments, not previously planned, to register alternative cases and restrictions, which were then renamed as exceptions and constraints. The group also pointed out the necessity of having different types of sentences, since we had only thought of sequential phrases, so we have included the non-sequential sentence and the conditional sentence in the grammar for episodes. Another finding was that the hierarchical structure of scenarios was an important aspect in organising scenarios. The 6verall impression of the group conducting the case study was that the scenarios substantially helped the comprehension and description of the domain and that the integration with the LEL was straightforward.

The case study reported in [23] had the other group as their main source of information about the domain. They also used direct observation in order to acquire a better understanding of the domain. This group did not use the LEL directly. They built the BMV from the information available to them. The resulting BMV had 8 actions and 26 external events. The group decided to focus only on the actor solicitante, which in the English version we have called citizen, because doing so, they would concentrate on the interface between the external world and the macrosystem. From the BMV the group described 8 scenarios. They have not organised the scenarios in a hierarchical way; all the scenarios described were atomic, with an average of 4 episodes each. In this exercise the group came out with a general set of heuristics to compose the skeleton of a scenario. These heuristics help the definition of title, goal, resources and actors, so the elicitation of episodes can occur in a bounded context. For instance, an action gives the title of the scenario, the input can provide hints for resources, as the client points to one of the actors. The group also helped in improving the definition of CONTEXT, noting that, besides the geographical location, it was necessary to point to an important initial state previous to the performance of a scenario. The group centered their scenario on the workflow of the passport emission, and did not deal explicitly with constraints and exceptions. This group also produced an evolution of half of the scenarios detected, thus changing the focus to the interface of the macrosystem and the computer system that would help the process of passport emission. This evolution was performed using common sense, and does not represent a real situation.

After finishing the passport case study, and with a more solid idea of scenarios we decided to use the overall strategy for the meeting scheduler problem. Here, instead of using just a written document [20] as an information source, we used a mixture of different

information sources. First of all, we used the meeting scheduler description as meta-knowledge about the problem, then we focused on producing a meeting scheduler system for the Universidad de Belgrano [19]. For the Belgrano system, the emphasis was on interviews and on reading an internal document about meetings. Three different people were interviewed. Based on these sources of information, the L E L was constructed and afterwards validated with one of the people interviewed. An interesting aspect of this L E L is that it pays a lot of emphasis on the macrosystem, the organisational system responsible for managing meetings, instead of centering on the software system and its interface with their users. The scenarios were derived from the LEL as explained before, the case study generated 34 L E L entries and 16 scenarios (12 sub- scenarios). Each scenario has an average of 7 episodes.

Overall, we confirmed that scenarios are an important tool for the requirements engineer, not only because of the natural way in which they describe behaviour, but also because they force the software engineer to map the macrosystem in which the future software will work. The case studies confirmed our hypothesis that scenarios must be in the requirements baseline, and that their link with the BMV and the LEL can be achieved based on links defined by common terms. We have also learned aspects of scenario evolution and their dependence on a hypertext system in order to make this requirements baseline usable. The case studies were not conducted with the hypertext support, which is under construction. Regarding the elicitation aspect, our strategy of maintaining the application vocabulary has helped the task of elicitors as well as the task of validation.

5. Related Work

The scenario evolution process is very much centered in what Rolland [24] calls expansion, that is "a change in the object spatial environment", and is exemplified as the addition of an attribute to an entity in a entity- relationship model. Rolland describes two other forms of changes: transformation and mutation. Transforma- tion "is a change which affects the object definitional properties" for example: changing the name of an entity. Mutation is the change which occurs when the object changes its data-type, and an example is the usual evolution in relational databases from entities to tables. Our main concern, as we based the requirements evolution on natural language descriptions, is to avoid transformation and minimise mutation. So, we must


maintain the names as they appear in the first LEL and should keep the mutation under control, by changing the original name with prefixes or suffixes and by maintaining the links (see Hypertext View) to the previous configurations of the LEL.

Our scenario work was influenced by several authors, in particular: [5-8] and [9,25]. From Rubin and Jacob- son we have been convinced of the importance of scenarios to improve the description of object behaviour, and the importance of tracing this behaviour to interfaces aspects of the software system. Carrol gave us a better understanding of the cognitive aspects of scenario based development, as well as a configuration of our idea that scenarios should be born in the macrosystem (UofD) and not only at the interface of the software system. This idea was also reinforced by the work of Zorman, that adequately defines scenarios as situations. From Zorman we also used her survey of scenario representations. Potts showed us the importance of relating scenarios to goals, and by the same token we profited from our previous knowledge of the goal-oriented metamodel proposed by Dardenne [26].

Unlike Potts [25], we organise goals from the point of view of scenarios, so that a scenario hierarchy will be similar to a goal hierarchy. Like Potts [25] we give special attention to constraints and exceptions, which he named obstacles [27]. We have differentiated between constraints and exceptions, because exceptions require a special treatment and constraints highlight two important aspects of non-functional requirements [28]. It is also important to note that the BMV has special treatment for non-functional requirements (see Fig. 6).

Recent work has used scenarios in combination with other strategies to help the elicitation of requirements [29] as well as a basis for systematic derivation of systems [30]. Sutcliffe [29] presents a strategy for requirements definition based on three techniques:

�9 prototypes or concept demonstrators, �9 scenario scripts, that describe users' work situations �9 exposure of the design rationale.

The work reported in [30] describes an approach that, starting with a tabular representation of scenarios uses Petri Nets to analyse the scenarios as well as to transform them into object-oriented state diagrams.

6. Conclusion We have presented a proposal to integrate scenarios into a requirements baseline, making possible their evolution as well as the traceability of the different views of the requirements baseline. Our proposal is

197

innovative in three important aspects: the use of scenarios as means for describing evolution, the vision that scenarios start from situations in the macrosystem, and the integration of their representation into an environment oriented towards hypertext navigation and configuration management.

Our proposal is an evolution of work being performed at PUC-Rio, where the main focus is in using natural language descriptions to help the elicitation and modelling of requirements. The case studies performed helped us to tune the scenario view as well as confirming the suitability of the LEL and the BMV as requirements representation models.

Future work will focus on continuing the use of the requirements baseline in real cases. The methodology has been used by the Brazilian state oil company, Petrobr~s [3], a major Brazilian bank also started to use it, but discontinued the project due to a management change. We still do not have a solid prototype: the one used in the Petrobr~is case did not evolve to integrate the configuration and the hypertext view. We continue to work on support for the original baseline and are now incorporating the scenario representation as well. We also plan to explore the hypermedia [31] capability of our model, which already has all the necessary infrastructure to support such an extension.

Our experience has shown that our major problems are related to the control of the information generated by the evolution process. As we tried to show in Figure 1, the evolution is a constant process that occurs during and after the process of development, so that in evolving a LEL, for instance, we not only have to maintain links between maintenance versions of a LEL (LEL H ..... LELI.n), but as well between development versions of LEL's (LEL1.4, LEL2.2). Doing this without automated support, as we did, is cumbersome, but it is also not a trivial task to implement in software our vision of hypertext and configuration management. Regarding the process, we are awaiting results of other ongoing case studies in order to write a process description for the production and evolution of requirements baselines. We are also collecting metrics regarding the products and the processes being used.

We hope that a consolidation of the baseline, by experiences with real cases and with adequate software support, will provide a more solid ground to the proposal of a requirements baseline as a knowledge base, and as such be amenable to automated analysis of different types.

Acknowledgement This work has been supported in part by CNPq grant n. 510845/93-2 and Universidad de Belgrano. It has also been


partially supported by Conicet (Argentina) and Universidad de Belgrano (Argentina). We wish to thank the anonymous referees for the questions and comments made on the submitted version to the Third IEEE International Sympo- sium on Requirements Engineering. We also are grateful for the editorial guidance of Prof. John Mylopoulos and Prof. Michael Stanton.

References

1. Lehman MM. Process Improvement - - The Way For- ward, Anais do X Simp6sio Brasileiro de Engenharia de Software, Sociedade Brasileira de Computaqao, Out. 1996, pp. 23-33

2. Chatzoglou PD, Macaulay LA. Requirements Capture and Analysis: A Survey of Current Practice Requirements Engineering Journal, Springer Verlag London, 1996, Vol:l, N.2, 75-87

3. Leite JCSP and Oliveira APA. A Client Oriented Requirements Baseline, In Proceedings of the Scnd IEEE International Symposium on Requirements Engineering, IEEE Computer Society Press, 1995 pp. 108-115

4. Jackson MA. Software Requirements & Specifications, Addison-Wesley, ACM Press, 1995

5. Carrol J (ed). Scenario-Based Design: Envisoning Work and Technology in System Development, Wiley. New York, 1995

6. Zorman L. Requirements Envisaging by Utilizing Scenar- ios (Rebus), Ph.D. Dissertation, University of Southern California, 1995

7. Rubin KS, Goldberg J. Object Behavior Analysis, Com- munications of the ACM, Vol. 35, No. 9, Sep. 1992, 48-62.

8. Jacobson I, Christerson M, Jonsson P, Overgaard G. Object-Oriented Software Engineering - - A Use Case Driven Approach, Reading, MA: Addison-Wesley; New York: Acm Press, 1992

9. Potts C, Takahashi K, Ant6n AI. Inquiry-Based Require- ments Analysis, IEEE software, Mar. 1994, Vol. 11, n. 2, pp. 21-32

10. Leite JCSP and Franco APM. A Strategy for Conceptual Model Acquisition In Proceedings of the First IEEE International Symposium on Requirements Engineering, San Diego, Ca, IEEE Computer Society Press. 1994 pp. 243-246

11. Gotel OCZ and Finkelstein ACW. An Analysis of the Requirements Traceability Problem, In Proceedings of the First International Conference on Requirements Engineering, Colorado Springs, IEEE Computer Society Press, 1994, pp. 94-101

12. Pohl K. PRO-ART: Enabling Requirements Pre-Trace- ability, In Proceedings of the Scnd International Con- ference on Requirements Engineering, IEEE Computer Society Press, 1996 pp. 76-84

13. Parnas DL, Clements PC. A Rational Design Process: How and Why to Fake it, IEEE Transactions on Software Engineering, Feb. 1996, VoI.SE-12, No. 2, 251-257

14. Kaplan G, Hadad G, Oliveros A. Uso de Lexico Exten- dido del Lenguaje (LEL) y de Escenarios para la Elicitacion de Requerimientos. Aplicacion a un Caso Real, Irfforme d Investigaci6n Departamento de Inver- stigaci6n, Universidad de Belgrano, Buenos Aires, 1996

15. Oliveira AP, Leite JCSP. SERBAC: Uma Estratrgia para a Definiq~o de Requisitos, In Proceedings of the VIII Simp6sio Brasileiro de Engenharia de Software, Sociedade Brasileira de Computaq~o, Out. 1994, pp. 109-123

16. Elmasri and Navathe S. Fundamentals of Data Base Systems, Benjamin/Cummings Publishing Comp. Inc, 1989

17. Schwabe D, Rossi G. The Object-Oriented Hypermedia Design Model, Communications of the ACM, Aug. 1995, Vol. 38 (8), 45-46

18. Schwabe D, Rossi G, Barbosa S. Systematic Hypermedia Design with OOHDM, Proceedings of the Seventh ACM International Conference on Hypertext, Hypertext '96, pp. 116-128

19. Hadad G, Kaplan G, LAxico extendido del lenguaje y escenarios del Agenda de Reuniones, Documento de Trabajo, Dep. de Investigaci6n, Universidad de Belgrano, 1997

20. van Lamsweerde A, Darimont R, Massonet Ph. The Meeting Scheduler System - - Preliminary Definition, Internal Report, University of Louvain, 1993

21. Oliveros A, Leite JCSE Rossi G. Uso de Escenarios en el Desarrollo de Software, Proyecto de Investigacion, Departamento de Inverstigaci6n, Universidad de Bel- grano, Buenos Aires, 1995

22. Jackson MA. Systems Development, Prentice-Hall, 1983 23. Maiorana V, Balaguer E La Relacion Entre el Modelo

Baseline y Escenarios, Informe de Investigaci6n Departa- mento de Inverstigaci6n, Universidad de Belgrano, Bue- nos Aires, 1996

24. Rolland C. Modelling the Evolution of Artifacts. In Proceedings of the First International Conference on Requirements Engineering. IEEE Computer Society Press, 1994, pp. 216-219

25. Pott, C. "Using Schematic Scenarios to Understand User Needs" Proceedings of the Symposium on Designing Interactive Systems. ACM Press, Ann Arbor, 1995, pp. 247-256

26. Dardenne A, van Lamsweerde A, Fickas S. Goal Directed Requirements Acquisition, Science of Computer Pro- gramming, Apr. 1993, Vol. 20 (1), 3-50

27. Ant6n AL. Goal-Based Requirements Analysis, Proceed- ings of the IEEE Second International Conference on Requirements Engineering, Colorado Springs, IEEE Computer Society Press, 1996, pp. 136-144

28. Mylopoulos J, Chung L, Nixon B. Representing and Using Non-Functional Requirements: A Process Ori- ented Approach, IEEE Transactions on Software Engi- neering, Jun. 1992, Vol. 18, No. 6, 483-497

29. Sutcliffe A. A Technique Combination Approach to Requirements Engineering, In Proceedings of the Third International Symposium on Requirements Engineering, IEEE Computer Society Press, 1997, pp. 65-74

30. Dano B, Briand H, Barbier E An Approach Based on the Concept of Use Case to Product Dynamic Object- Oriented Specifications, In Proceedings of the Third International Symposium on Requirements Engineering, IEEE Computer Society Press, 1997, pp. 54-64

31. Gough P, Fodemski FT, Higgins SA, Ray SJ. Scenarios - An Industrial Case Study and Hypermedia Enhance- ments, In Proceedings of the Scnd IEEE International Symposium on Requirements Engineering, IEEE Com- puter Society Press, 1995, pp. 10-17

Enhancing a requirements baseline with scenarios - …julio/Slct-pub/baseline.pdf · Enhancing a...

Documents

Transcript of Enhancing a requirements baseline with scenarios - …julio/Slct-pub/baseline.pdf · Enhancing a...