Extending UML Use Case Diagrams to Represent Non ... · Use case modelling is one of the most widely-used methods to represent and document functional requirements of the system

e-Informatica Software Engineering Journal, Volume 14, Issue 1, 2020, pages: 97–115, DOI 10.37190/e-Inf200104

Extending UML Use Case Diagrams to RepresentNon-Interactive Functional Requirements

Saqib Iqbal∗, Issam Al-Azzoni∗, Gary Allen∗∗, Hikmat Ullah Khan∗∗∗

∗Department of Software Engineering and Computer Science, Al Ain University, Al Ain, UAE∗∗Department of Computer Science, University of Huddersfield, UK

∗∗∗Department of Computer Science, COMSATS University Islamabad, Wah Campus, [email protected], [email protected], [email protected],

[email protected]

AbstractBackground: The comprehensive representation of functional requirements is a crucial activityin the analysis phase of the software development life cycle. Representation of a complete set offunctional requirements helps in tracing business goals effectively throughout the development lifecycle. Use case modelling is one of the most widely-used methods to represent and documentfunctional requirements of the system. Practitioners exploit use case modelling to representinteractive functional requirements of the system while overlooking some of the non-interactivefunctional requirements. The non-interactive functional requirements are the ones which areperformed by the system without an initiation by the user, for instance, notifying something tothe user or creating an internal backup.Aim: This paper addresses the representation of non-interactive requirements along withinteractive ones (use cases) in one model. This paper calls such requirements ‘operation cases’ andproposes a new set of graphical and textual notations to represent them.Method: The proposed notations have been applied on a case study and have also been empiricallyevaluated to demonstrate the effectiveness of the new notations in capturing non-interactivefunctional requirements.Results and Conclusion: The results of the evaluation indicate that the representation ofoperation cases helps in documenting a complete set of functional requirements, which ultimatelyresults in a comprehensive translation of requirements into design.

Keywords: Use Case modeling UML Requirements Engineering Functional Requirements

1. Introduction

Software Engineering is concerned with develop-ing software as per the stakeholders’ expectations(requirements). Gathering, eliciting and docu-menting these requirements is the most crucialphase of the software engineering process. Dur-ing this phase, detailed software requirementsspecification (SRS) documents are developed tospecify the system requirements. One of the mostwidely used requirements specification tools isuse case modelling, which represents the system

users (actors) and their interactive requirements(use cases). Use case modelling was proposed byJacobson [1] and was later adopted by the UnifiedModelling Language (UML) [2]. The purpose ofuse case modelling is to represent requirementsin such a way that all stakeholders (from a tech-nical or non-technical background) could easilyunderstand and review them [3]. Use case mod-elling has been considered as an effective toolby the academic research community [4, 5] andindustry [6, 7] to specify and model functional re-quirements. There are, however, some functional

Submitted: 3 September 2019; Revised: 13 April 2020; Accepted: 4 June 2020; Available online: 24 June 2020

http://www.e-informatyka.pl/wiki/e-Informatica

http://www.e-informatyka.pl/attach/e-Informatica_-_Volume_14/eInformatica2020Art04.pdf

98 Saqib Iqbal et al.

requirements which often are not represented asuse cases as they are not initiated by an actor.Examples of such requirements in a simple ATMbanking system would be ‘Check Cash Dispenser’,‘Notify Bank About an Empty Cash Dispenser’ or‘Display Promotional or Informational Messages’.These functions are triggered either in responseto an interactive requirement (a use case), anevent, or at a specified time according to theinternal system clock. We may call these require-ments non-interactive requirements as they aretriggered by the system without users’ initiation.System specification is not complete without therepresentation of these requirements along withuse cases.

A use case, as the name suggests, has alwaysbeen considered as a case of usage of the system,a usage scenario in other words. The represen-tation of a requirement that does not representa usage scenario (a non-interactive requirement)as a use case would only lead to confusions. Thereis a need for a separate representation for suchrequirements which is graphically and textuallydifferent from a use case. Both types of require-ments, however, are needed to be representedin one model because they are both functionalrequirements and their representation in onemodel would provide a single point of referencefor a complete list of functional requirements.

To cater for this need, we propose a new con-struct called ‘Operation Case’. The OperationCase is a system function which is not initiatedby an actor, rather is triggered either by a usecase or is initiated in response to an event or sys-tem clock. Operation cases are modelled alongwith the use cases in the same subject (systemor module) to represent a full set of functionalrequirements of the subject. The construct hasbeen added to the use case models in addition toother constructs by introducing a new profile toUML. The proposed constructs have been appliedon a case study to show the comprehensivenessof the approach in representing functional re-quirements. In addition, an empirical evaluationhas been conducted. The evaluation focuses onaddressing the hypothesis that the proposed con-structs and method represent a comprehensivelist of functional requirements which eventually

leads to a complete and consistent design. Theempirical evaluation demonstrates that use casemodelling without operation cases can lead tooverlooking of key functional requirements.

The rest of the paper is organized as follows:Section 2 provides a review of the related litera-ture. Section 3 outlines the problem and motiva-tions behind the research. Section 4 describes op-eration cases in detail. Section 5 provides detailsof the implementation of the proposed concepts.Section 6 illustrates the application of the new no-tation via a worked case study. Section 7 reportson the results of a controlled experiment. Toaddress possible internal validity threats to theconclusion of the controlled experiment, a secondexperiment was conducted and it is presented inSection 8. Section 9 concludes the paper witha discussion on the future work.

2. Related work

In [8], Glinz identifies and demonstrates severaldeficiencies of UML, with emphasis on use casemodels and system decomposition. Our workattempts to address two of the deficiencies men-tioned. The first deficiency is the omission ofactive objects in UML use case diagrams. In-clusion of active objects in use case diagramsis needed to specify interaction requirementswhere the system itself initiates an interactionbetween the system and an external actor. Theuse of observers in our new notation fills thisgap. The second deficiency is that UML use casemodels cannot express state-dependent systembehaviour adequately. We address this issue byintroducing operation cases, which can be speci-fied to capture the system state.

Several papers have also presented prob-lems and limitations of use cases. The paperby Génova et al. [9] identifies sources of ambi-guity that exist in use case models. The paperby Metz et al. [10] looks at the problem of usecase interleaving present in UML 1.3. In [11],the authors highlight major problems associatedwith the semantics of extension points and rejoinpoints, which are used as branching and returnlocations for a use case’s alternative interaction

Extending UML Use Case Diagrams to Represent Non-Interactive Functional Requirements 99

courses. The paper by Simons [12] traces the un-stable semantics of use cases from Jacobson [13]to UML 1.3.

The paper by Tiwari and Gupta [14] presentsa systematic literature review that examines theevolution of use cases, their applications, qualityassessments, open issues and the future direc-tions. In addition, the paper identifies a totalof twenty existing templates that are used tospecify use cases. In [15], the authors investi-gate via empirical studies the comprehensionand learnability aspects of these templates.

The paper by Misbhauddin and Alshayeb [16]proposes an extension to the UML use case meta-model. The extended metamodel captures boththe structural and behavioural views of use cases.The aim is to exploit the extended metamodelfor model composition, model evaluation, andmodel interchange.

In [17], the authors propose an extension tothe UML metamodel for presenting a refinementrelationship between two use cases. The authorsdiscuss the differences between include and refinerelationships. The refinement of a use case resultsin more detailed use cases. Refinement can be de-fined by decomposing a use case according to theparts that compose the object of that use case, oraccording to the activities that compose the usecase being refined. In our new notation, we donot attempt to represent use case refinement, butrather we introduce the concept of operation caseto model non-interactive requirements. In [17],both the refining and refined use cases representexternal functionality of the system and thusthey agree with the UML definition of use cases.In our work, an operation case is not a type ofuse case. Other work that builds on use caserefinement is [18]. There the authors present anapproach to decompose a use case model intomodels at several levels of abstraction. The au-thors extend the UML use case metamodel witha refine relationship between a use case and a Use-CaseModel. For each abstraction level, severaluse case diagrams are used to capture the usecases at that abstraction level.

Several authors have attempted to formal-ize use case notations. In [19], the control-flowsemantics of use cases is described in terms of

control-flow graphs. The technical report by Hurl-but [20] presents a survey of approaches for de-scribing and formalizing use cases. The paper byMetz et al. [21] provides definitions for differenttypes of alternative interaction courses in thecontext of goal-driven requirements engineering.Stevens [22] explores how UML use case nota-tions can be formalized. Savic et al. in [23] pro-pose the idea of use case specification at differentlevels of abstraction: interaction, behaviour, anduser interface levels. Each abstraction level ex-tends the previous level. The interactions in a usecase are specified using the SilabReq language,which is a textual domain specific language.

The paper of Al-alshuhai and Siewe [24] pro-poses an extension to the UML use case dia-gram with new notations to model context-awareapplications. The proposed extension, calleda use context diagram, allows the modelling ofcontext-aware requirements in addition to thefunctional requirements of a software application.The new notations include new metamodel ele-ments such as Context Sources and Use Contextsas well as a new utilise relationship between UseContexts. This extension is useful to cater forthe modelling and analysis of the requirements ofcontext-aware applications. We note that our newnotation can also be used to model context-awarerequirements: an Operation Case can be used asa Use Context to model sequences of actionsa system performs to acquire, aggregate, or infercontext information. A Context Source can berepresented as an Observer that measures contextinformation, and a trigger relationship replacesthe utilise relationship.

A systematic literature review on producinghigh quality use case models is presented byEl-Attar andMiller [25]. In their work, twentysix anti-patterns are suggested. A use caseanti-pattern explains a repeated pattern in usecase models that may initially appear beneficialbut ultimately may cause deficiencies [25]. Mod-ellers can exploit these anti-patterns to improvethe quality of their use case models.

Identifying use cases can be very useful forthe subsequent phases in software development.For instance, Yue et al. have created a tool toautomatically generate a UML analysis model


comprising class, sequence, and activity diagramsfrom a use case model [26]. The tool also supportsthe automatic generation of traceability linksbetween model elements of the use case modeland the generated analysis model. Wang et al.have proposed an approach for automatically gen-erating executable test cases by exploiting thebehavioural information described in use casespecifications [27]. The use cases are assumedto be specified in a restricted form of use casespecification called Restricted Use Case Mod-elling (RUCM) [28]. Kesserwan et al. present anapproach for generating test artefacts from sce-nario models through model transformation [29].In the proposed approach, the scenarios are de-duced from use case specifications written in theCockburn use case notation [30]. It is of interestto apply such work on operation cases as well.

In the book by Smialek and Nowakowski [31],the authors present a language specific for re-quirements modelling, called the RequirementsSpecification Language (RSL). RSL forms thebasis for the framework of model transformationand code generation presented in the book. Func-tional requirements in RSL are defined mostlythrough use case models. Use cases in RSL arederived from UML, but several new and changedfeatures exist. These changes are due to the am-biguous semantics of the use case models, asdefined in the UML specification [31]. RSL is de-signed to be a comprehensive language to modeluse case scenarios while linking those scenariosto their respective domain model elements. Wenote that the authors define use cases in relationto outside actors. In their definition, a use casesstarts with the interaction of an outside actorwith the system. Hence, RSL seems to capture in-teractive functional requirements only. The abil-ity of RSL to model non-interactive requirementsrequires further investigation.

Use cases can also be useful for effort es-timation in use case driven projects. Qi andBoehm [32] have proposed an effort estimationmodel based on a use case model that can beused to estimate project effort during the earlyiterations in system development. In their work,the size metrics are defined based on the arte-facts of a use case model. For example, the Early

Use Case Points (EUCP) metric is a size metricthat weights each use case with the number ofscenarios identified from the use case description.We believe that operation cases can be dealtwith in a manner similar to use cases and theycan be useful in effort estimation as well. UseCase Points (UCP) is a software effort estimationtechnique based on the use case model. A reviewof effort estimation frameworks and tools basedon UCP is provided in [33].

3. Problems and motivation

There have been a number of efforts to extenduse case models for representing non-functionalrequirements [8, 34] along with use cases butthere is no evidence in the literature of addressingrepresentation of non-interactive requirements.These requirements are the functional require-ments, which are not initiated by an actor ratherare triggered by a use case, event or the sys-tem clock. For instance, ‘turn on power savingmode’ in a mobile phone operating system istriggered in response to the battery level drop-ping to a certain level. Similarly, messages tothe user, such as ‘battery fully charged’, ‘newSMS received’, or ‘application update available’are also triggered without the user’s involvement.We may call these requirements non-interactiverequirement as they are performed by the systemwithout interaction with the user.

To illustrate these non-interactive require-ments in more detail, let us consider LibraryManagement System with the use case diagramin Figure 1. The functional requirements of thesystem would be:R1: The librarian shall be able to add items

such as books, journals and magazines tothe system.

R2: The librarian shall be able to issue a li-brary item to a user.

R3: The librarian shall be able to return anissued item.

R4: The librarian shall be able to send a re-quest for a new library item to a vendor.

R5: The user shall be able to search for a li-brary item.


Figure 1. The use case diagram of Library Management System

R6: The user shall be able to request issuanceof an item that is available.

R7: The user shall be able to reserve an item ifthe item is already issued to someone else.

R8: The user shall be able to pay fines wherethese have been incurred.

R9: The user shall be able to make suggestionsfor new library items.

R10: The system shall notify the user whena reserved book becomes available.

R11: The system shall calculate fine for latereturns, with fines accruing each day after15 days of issuance of an item.

R12: The system shall notify the user of anyfines every 3 days.

R13: The system shall notify the suggestionsprovided by the users to the librarian.

R14: The system shall make backups at speci-fied times.

The use case diagram of these functional re-quirements, shown in Figure 1, captures the in-teractive requirements, but is unable to capturethe system requirements, R10 to R14. Theserequirements are as important for the completefunctionality of the system as any other require-ment, but they cannot be captured/representedby a use case model as they are not initiated byan actor.

The design artefacts extracted from the usecase model would not include these requirements,

which would eventually lead to incomplete imple-mentation. Representation of these requirementsat use case modelling level would make the re-quirement specification complete and compliantwith the system goals. More detailed discussionof this example is provided in Section 7.

4. Operation cases

We propose a new construct for the representa-tion of non-interactive requirements, called ‘op-eration cases’. An operation case is an internalfunction which is initiated within the systemeither by a system timer, an event observer, ora use case. An operation case cannot initiateother operation cases, but can interact with theuser, for instance, in case of a dialogue inputor a message display to the user. The rationalebehind the name of the operation case is that anoperation case will represent a complete scenarioof an internal operation. It has a separate nota-tional representation to distinguish it from a usecase. A complete use case model would includeboth use cases and operation cases representingall functional requirements identified during theanalysis phase, which later will be translated intodesign mechanisms and design constructs.

A complete list of new notations and relatedassociations is given in Table 1.


Table 1. Notations and Descriptions of New Constructs

Construct Notation Description

Operation Case

An Operation Case specifies a set of actions performed by its subjects,which may or may not yield an observable result that is of value forone or more Actors or other stakeholders of each subject. The actions inan Operation Case can only be triggered by an action in a Use Case orinitiated by an Observer or a Timer.

Timer A Timer represents an internal clock of the system or a specific intervalof time represented in the implementing software.

Observer An Observer represent a system component that initiates Operation Casesin response to an internal or external event.

Trigger Trigger relationship defines that a Use Case triggers an Operation Case.

Initiate Initiate relationship defines that an Observer or a Timer initiates anOperation Case.

5. Extension to use case modelling

The UML [1] is a widely used modelling lan-guage for representing and designing structuraland behavioural properties of a system. It pro-vides graphical models and notations that helpin modelling internal and external behaviour ofa system and representing the structural orga-nization of system modules. Although UML isthe most popular visual modelling language insoftware design, it only supports one paradigm ofsoftware design, which is object-oriented design.To counter this problem, the Object ManagementGroup (OMG), the proprietary owner of UML,has proposed UML 2.0, which offers flexibility ofextending UML diagrams and design notations.The extension is achieved through the introduc-tion of profiles. A UML profile is an element ofthe UML; it is defined inside the UML meta-model [2]. Profiles are used to extend classes ofthe UML metamodel with additional stereotypes,tagged values, and constraints. The stereotypesare used to distinguish similar design notationsrepresenting different concepts; the tagged valuesare new attributes attached to a design construct;whereas constraints are used to introduce invari-ants and semantic-related limitations on a designdiagram or a notation.

5.1. Operation cases profile definition

Since the operation cases introduce a new nota-tional concept in the use case model, we intro-

duce a new profile, named OperationCasesProfile,to extend UML metaclasses. The new profile de-fines several stereotypes which extend standardUML metaclasses. Figure 2 shows the new op-eration cases profile. The new stereotypes are:OperationCase, Trigger, Initiate, Observer, andTimer. Their corresponding icons are shown inTable 1.

An OperationCase extends the UML meta-class UseCase. An OperationCase specifies somebehaviour that a subject can perform. An Opera-tionCase defines an offered behaviour of the sub-ject with possible reference to its internal struc-ture. Similar to a UseCase, an OperationCasemay apply to any number of subjects.

An OperationCase may include or extend anynumber of other OperationCases, but may notinclude or extend any other BehaviouredClassi-fiers (i.e. UseCases or Actors). In addition, anOperationCase cannot be included or extendedby a UseCase. The definitions of the Include andExtend relationships between OperationCases isthe same as those between UseCases.

A new relationship added by the profile isthe Trigger relationship. It is a relationship froma UseCase to an OperationCase. It specifies thata UseCase triggers an OperationCase. Trigger ex-tends both Include and Extend metaclasses, suchthat the source is the triggering UseCase andthe target is the triggered OperationCase. Thisindicates that the behaviour of theOperationCaseis triggered while the behaviour of the UseCase isbeing executed. In UML profiles, if a stereotype


OperationCasesProfile <<import>>

«metaclass»UseCase

«metaclass»BehaviouredClassifier

«metaclass»Include

«metaclass»Extend

«stereotype»OperationCase

«stereotype»Observer

«stereotype»Timer

«stereotype»Trigger

<<metamodel>>uml

«stereotype»Initiate

«metaclass»Association

Figure 2. The operation cases profile

extends several metaclasses, it can only be appliedto exactly one instance of one of those metaclassesat any point of time. The rationale for extendingboth Include and Extend metaclasses is that thebehaviour of a triggered operation case can beinserted into the behaviour of the including opera-tion case (in the case of Include), or can be added,possibly conditionally, to the behaviour of theextended operation case (in the case of Extend).

When an OperationCase applies to a subject,it specifies a set of behaviours performed by thesubject. These behaviours can be triggered by anaction in a UseCase or initiated by an Observeror a Timer. An Observer extends the UML meta-class BehaviouredClassifier. Part of a subject, anObserver observes events and when an observedevent occurs it causes (initiates) the executionof the behaviour of an associated OperationCase.A Timer also extends BehaviouredClassifier. Partof a subject, a Timer initiates an operation casewhen its time interval expires. Observers areuseful to model behaviours that are initiated byinternal or external events. Timers are useful tomodel behaviours that are initiated at specifiedtimes according to an internal system clock. TheOperationCasesProfile defines an Initiate stereo-type which extends the UML metaclass Associa-tion. An Initiate association is between a Timeror an Observer on one end of the association andan OperationCase on the other end.

An OperationCase cannot be associated withActors. Rather, it can only be associated withTimers or Observers. An Actor interacts witha subject through its associated UseCases whichcan indirectly trigger OperationCases.

We also add the following constraints to theoperation cases profile:– OperationCases can only be involved in bi-

nary associations.context OperationCaseinv : As soc i a t i on . a l l I n s t a n c e s ( )−>

f o rA l l ( a | a .memberEnd . type −>inc l ud e s ( s e l f ) imp l i e sa .memberEnd−>s i z e ( ) = 2)

– An OperationCase cannot include Opera-tionCases that directly or indirectly include it.context OperationCaseinv : not a l l Inc ludedOperat i onCase s ( )

−> inc l ude s ( s e l f )Here, the operation allIncludedOpera-tionCases() returns the transitive closureof all OperationCases included by this Oper-ationCase.

– An OperationCase must have a name.context OperationCase

inv : name −> notEmpty ( )– An Observer must have a name. The same is

true for a Timer.context Observer

inv : name −> notEmpty ( )– An Observer can only have Associations to

OperationCases. Furthermore, these Associ-ations must be binary. The same is true forTimerscontext Observerinv : As soc i a t i on . a l l I n s t a n c e s ( ) −>

f o rA l l ( a | a .memberEnd −>c o l l e c t ( type ) −> inc l ude s ( s e l f )imp l i e s(

a .memberEnd −> s i z e ( ) = 2 and


l e tobserverEnd : Property =a .memberEnd −> any ( type = s e l f )inobserverEnd . oppos i t e . c l a s s .

oc l I sKindOf ( OperationCase ))

)

5.2. Operation case template

Jacobson [1] introduced a use case template torepresent and document the description of a usecase. Due to the complexity and unneeded for-malism within the template, several variationshave been introduced [35–39]. Operation casesare represented in a similar textual template, asshown in Table 2. The template contains a de-scription of constituent items of an operationcase, its associations, and related details. Thetemplate also mentions the requirements whichare represented by the operation case. This helpsto improve documentation and traceability.

6. Application of new notations

We have selected a subset of functional require-ments of a simple mobile phone system for the

sake of simplicity. The selected subset of require-ments is summarised according to their classifi-cation below:– Interactive Functional Requirements:

– Make a phone call,– Receive a phone call,– Send a message,– Add a contact,– Set an alarm.

– Non-Interactive Functional Require-ments:– Transmit data to the service provider,– Manage Contact Book (This requirement

is concerned with system adding new con-tacts and placing them in alphabeticalorder),

– Receive Push Notifications,– Turn on Power Saving Mode in the case

that the battery is lower than a threshold,– Notify user of updates,– Make the phone ring on receipt of an in-

coming call,– Sound an alarm at the required time.Figure 3 shows the traditional representa-

tion of these requirements in a use case dia-gram. The non-interactive requirements are miss-ing from this model as they do not representany usage scenario. This model is supposed to

Table 2. Operation Case Template

Operation Case ID:Operation Case Name:Requirement ID:Created By: Last Updated By:Date Created: Date Last Updated:Description:Pre-conditions:Post-conditions:Priority:Frequency of Use:Normal Course of Events:Alternative Courses:Exceptions:Includes:Triggered/Initiated By:Special Requirements:Assumptions:Notes and Issues:


Figure 3. Use case diagram of a mobile phonesystem

Figure 4. Revised use case diagram of a mobilephone system with operation cases

be translated into design artefacts and models,but if the model is taken as a complete setof functional requirements, a number of criti-cal requirements (non-interactive requirements)may be overlooked. Figure 4, on the other hand,shows a representation of a complete set of re-quirements. The requirements, such as ‘Turn onpower saving mode’ or ‘Receive push notifica-tion’, are represented along with other interactivefunctional requirements in the same sub-systemboundary.

As can be seen, the basic use cases remainthe same, showing how the user will interact withthe system. However, we can also see that:– The “Receive Call”, “Make Call”, and “Send

Message” use cases each trigger a “TransmitData” operation case. In traditional use casemodelling this could be modelled as a step inthe primary path of each of the three sepa-rate use cases, but would not be shown on thediagram. By triggering an operation case theshared nature of this functionality becomesexplicit, thus both simplifying the descrip-tions of the individual use cases and captur-ing the relationships between these functionalconcerns.

– The “Add Contact” use case triggers the“Manage ContactBook” operation case. Itcould be argued that the latter is simplya step in the primary path of the former, how-

ever we would argue that our model is clearerand it allows for reuse of the “Update ContactBook” operation case. Additionally, the imple-mentation of the operation case would needto deal with issues such as poor network con-nectivity and failure to connect to the server.This functionality would sit more sensibly inthe “Update Contact Book” operation casethan in the “Add Contact” use case.

– Three observers have been implemented, twoof which monitor incoming connections (in-coming calls and incoming push notifications),and one of which monitors the battery andturns on power saving mode when required.This latter example is a classic case of func-tionality that is difficult to represent clearlyusing a traditional use case model. There isno actor to drive the functionality, as it is notan interactive use case, instead being eventdriven. The use of the observer makes thisinternal functionality explicit.

– One timer driven event has also been imple-mented. This is the “Sound Alarm” operationcase, which is initiated by a timer. Again,standard use case models do not allow for therepresentation of such functionality.Note that, while a use case can trigger an op-

eration case, the reverse is not true. Take as anexample the “Make Phone Ring” operation case.It may, at first sight, appear that this could in


turn trigger the “Receive Call” use case. However,making the phone ring does not necessarily causethe user to answer it. The user may be away fromthe phone, the phone may be on silent, or theuser may simply choose to ignore the incomingcall. It is not, therefore, possible to assume thatthe operation case will cause the user to react.Similarly, the “Display Message” operation casemay cause the user to read that message, butthis is not certain, so the operation case cannottrigger a “Read Message” use case, nor can theoperation case deliver data to the user via a di-rected association. In essence, an operation casemay be triggered by use cases, but not vice-versa.

Having modelled the use cases and operationcases in a diagrammatic form, the next step isto write up detailed use case and operation casedescriptions. Traditional use case modelling al-ways includes this step, and several standardshave been suggested for the layout of use casedescriptions. These standards tend to be verysimilar, and the one chosen for use here is one ofthe selection that can be found at [40]. One exam-ple operation case description, for the TransmitData operation case, is given in Table 3.

As can be seen, the primary, alternative, andexception paths of several of the use cases can besimplified by the use of operation cases, as theiruse helps to partition the system behaviour, andto identify and abstract out shared or commonfunctionality. As an example, the Send Messageuse case in the traditional model contains thefollowing steps in the primary path:5. The phone handset connects to the mobile net-

work and attempts to send the SMS message.6. The message is sent successfully.and the following alternatives or exceptions:5.1. If the mobile network is unreachable then the

phone will retry at intervals until successful.5.2. If the receiver’s phone is unreachable (e.g.

a wrong number or the phone is switched off)then an error is displayed to the phone user.

All of this behaviour can be abstracted out to theTransmit Data operation case, thus simplifyingthe use case description.

In order to integrate Operation Cases fullyinto the requirements model a small number ofamendments have been made to the use case de-

scription template. The template has also beenadapted for the description of Operation Cases.The changes proposed are:– A new section, “Triggers:” has been added

to the Use Case Description template. Thissection lists the Operation Cases that can(optionally) be triggered by the use case.

– When describing Operation Cases, the “UseCase ID” and “Use Case Name” have beenchanged to “Operation Case ID” and “Oper-ation Case Name”.

– When describing Operation Cases, the “Ac-tor” section has been removed.

– When describing Operation Cases, a newsection, “Triggered/Initiated By:” has beenadded to the template. This section is used tolist the use cases, operation cases, observers,or timers that can trigger or initiate the op-eration case.

With these modifications and additions to thetemplate, we have provided a clear mechanismfor the description of all use cases and operationcases within the system model.

We can see that the operation case “TransmitData” is triggered by the “Make Call”, “ReceiveCall”, and “Send Message” use cases. The clarityof this information aids understanding of thestructure of the requirements, and helps softwareengineers identify shared and core functional-ity, in a way that traditional use case modellingis unable to support. This should in turn helpsoftware architects with the design of the soft-ware, and help project managers to prioritise thedevelopment of the system components.

7. A controlled-experiment basedevaluation

This section reports on a controlled experimentthat was conducted to test whether using use casediagrams extended with operation cases results ina comprehensive system design that incorporatesboth interactive and non-interactive functionalrequirements. Section 7.1 presents the researchquestion and hypothesis. Section 7.2 presents theresearch design, and Section 7.3 presents anddiscusses the results.


Table 3. Transmit Data Operation Case Description

Operation Case ID: MP_OC1

Operation Case Name: Transmit Data

Requirement ID: SR15, SR20, SR35

Created By: GA Last Updated By: GA

Date Created: 25 May, 2018 Date Last Updated: 29 May, 2018

Description: This is a background process running on the phone which receivesdata from apps such as the dialler app and the messaging app anduploads those data to the mobile network.

Pre-conditions: The phone must be switched on and connected to the mobile network.

Post-conditions: None.

Priority: High – this is a core piece of functionality.

Frequency of Use: Variable, depending on the usage patterns of the user.

Normal Course of Events: 1. The operation case receives a request to upload data from anotheruse case or operation case.2. A connection to the mobile network is opened.3. The data are uploaded.4. The connection to the mobile network is closed.

Alternative Courses: 2.1 A connection cannot be established. Try again.3.1 The data does not upload correctly. Try again.

Exceptions: If at any time the connection is lost and cannot be re-establishedwithin 1 second, then the operation case will return an error to thecalling use case or operation case.

Includes: None.

Triggered/Initiated By: Triggered by use cases MP1a Make Call; MP2a Receive Call; MP3aSend Message.

Special Requirements: None.

Assumptions: None.

Notes and Issues: None at present.

7.1. Research question and hypothesis

Our main proposition is that the UML use casediagrams fail to represent non-interactive func-tional requirements. Therefore, a systems ana-lyst following an object-oriented developmentmethodology that uses these diagrams to designthe system, i.e., construct the class diagram,will likely fail to include the necessary methodsto implement the system’s non-interactive func-tional requirements. The end result is a design

and an implementation of a system that do notimplement all functional requirements and forwhich late changes are likely to be costly.

We carried out a controlled experiment toinvestigate the following research question:

Will using extended use case diagramshelp systems analysts to not miss incorpo-rating non-interactive functional require-ments in system design?The experiment was structured as follows. We

developed a system story and asked the partici-


pants to draw the class diagram. We separatedthe participants into two equal groups: partici-pants in the UC group were requested to drawthe use case diagram for the system first and useit to draw the class diagram, while participantsin the OC group were instructed on the useof operation cases and extended use diagramsand subsequently requested to draw the extendeduse case diagram and use it to draw the classdiagram. More details on the participants areprovided in Section 7.2.

In relation to our research question, we for-mulated the following hypothesis:

The number of correctly identified meth-ods and classes related to non-interactivefunctional requirements will be higher inthe OC group compared to the UC group.The research variables are as follows. The

independent variable is the diagram used: theuse case diagram in the case of the UC groupor the extended use case diagram in the caseof the OC group. The dependent variable is thecompleteness of the class diagram with respectto incorporating the non-interactive functionalrequirements. This is captured in a score thatranges from 0 to 9. The scoring system is de-scribed in the next section.

7.2. Research design

There were 14 participants in the experiment.The participants were asked to fill a consent formbefore participating in the experiment. Theseparticipants were undergraduate students takingcore courses in the program of Software Engi-neering in the College of Engineering at Al AinUniversity of Science and Technology. The OCgroup consisted of 7 students taking the course“Formal Specifications and Design Methods”, andthe UC group consisted of 7 students takingthe course “Software Measurement and Testing”.These courses were selected because they areadvanced courses and the prerequisite course forboth courses is “Software Requirements and Spec-ification”. In this prerequisite course the studentsstudy capturing and representation of require-ments. The students have completed courseworksand projects in which they have gathered and

represented requirements using use case mod-elling.

The experiment was conducted in the formof two voluntary quizzes; one in each course.The quizzes were conducted on separate days,and involved the participation of the first twoauthors. The students were given an incentive inthe form of bonus points, which would be addedto their final grade for the course. To encour-age the students, the number of bonus pointsfor each student were tied with the student’sscore as follows: 3 points to scores of 7 or more,2 points to scores of 4–6, and 1 point to scores of3 or less. During the selection of students it wasalso ensured that the average Cumulative GradePoint Average (CGPA) of both groups was thesame (UC group = 2.54/4, OC group = 2.62/4).

The students had been informed of the vol-untary quiz and the bonus points in the earlierclass. They were simply asked to show up in thesame classroom at the regular class time. Therewere 10 students who attempted the quiz fromthe course “Formal Specifications and DesignMethods”. On the other hand, only 7 studentsattempted the quiz from the course “SoftwareMeasurement and Testing”. Since the cumula-tive degree averages of both groups are different,we only scored a subset of the students whoattempted the quiz in the “Formal Specifica-tions and Design Methods” class. We rankedthe 10 students in terms of their cumulative de-gree averages, and then we selected a sequenceof 7 students such that the group’s cumulativedegree average was close to the that of the groupof the second course. The attempts by the otherstudents were discarded; these attempts werenever evaluated.

The experimental procedure was as follows:the first author gave a half-an-hour tutorial re-viewing use case modelling. For both groups,the tutorial included a review of use cases anduse case diagrams. An example system storywas used in both tutorials. The instructor ofthe tutorial worked out an exercise developinga use case diagram that modelled the functionalrequirements presented in the example systemstory. The instructor presented how to createa class diagram based on the identified use cases.


In particular, the instructor reminded the stu-dents of the usefulness of use case scenarios inidentifying the classes and their methods. The in-structor encouraged the students to apply whatthey had learned in their earlier courses suchas the use of sequence diagrams to model theuse case scenarios and construct the class dia-gram. The instructor worked with the studentson constructing the class diagram representingthe initial design of the example system story.

The contents mentioned earlier were commonin both tutorials. However, there were two keydifferences between the two. In the tutorial in-structing the UC group, there was no mention ofnon-interactive requirements. The students weresimply asked to apply what they already knew.On the other hand, operation cases and extendeduse case diagrams were introduced in the tutorialinstructing the OC group. Non-interactive func-tional requirements were defined and discussedin this tutorial. These were also applied on theexample system story. The students were rec-ommended to use the identified operation casesin constructing the class diagram in a similarfashion to what they would do using use cases.

Figure 5 shows the system story. It describesthe functional requirements of an online librarymanagement system. We selected this systemsince undergraduate students at this level aretypically familiar with the services provided bythe University’s online library system. Therefore,they are familiar with library concepts such assearching for and reserving library items. The

figure includes the instructions handed to theUC group’s students; for the OC group, thestudents were given the same instructions butwere asked to first draw the extended use casediagram with operation cases rather than thestandard UML use case diagram. The descrip-tion includes a set of interactive requirements,such as requesting an item for issuance and re-questing new items from vendors, in additionto a set of non-interactive requirements, suchas the weekly back-up and the fine’s calculationand notification requirements.

An expert solution in the form of a classdiagram was created by the first author andchecked by the second author. The class diagramincludes five classes, including the class Librarywhich is used as a system class implementingthe methods that are necessary to realise somenon-interactive requirements. A total of 19 meth-ods were identified, including 6 methods to realisethe non-interactive requirements. The form usedin the evaluation of each student’s work is pre-sented in Figure 6. The six methods realising thenon-interactive requirements are shown in bold.

Since the experiment is concerned with non-in-teractive requirements, we developed a scor-ing method for these requirements only. A stu-dent gets one point for each correctly identifiednon-interactive method, i.e., one of the six meth-ods realising the non-interactive requirements. Ifa student places a method in an incorrect class,they are not rewarded the point. The justificationfor this is that the use case diagram (or its ex-

Figure 5. The description of Library Management System used in the evaluation


Evaluation Form Student ID:

Completeness - Identification of Classes Library LibraryItem User Librarian Vendor Score:

Completeness – Correct Allocation of Methods to the Classes Library

notifySuggestion() notifyLateReturn() notifyFine() createBackUp()

User reserveItem() returnItem() makeSuggestion() payFine() requestIssuence()

LibraryItem searchItem() reserveItem() return() issue() calculateFine() notifyAvailability()

Librarian

addItem() orderItem() issueItem() returnItem()

Vendor supplyItem()

Score: No. of Methods Identified: No. of Non-Interactive Methods Identified:

Figure 6. The evaluation form used in evaluating a student’s work

tended diagram variant) should help the systemsanalyst in building a complete and sound design.The only class that is critical to implement thenon-interactive requirements is the system classLibrary. Four out of six non-interactive methodsare in this class. Given its relevance, we assignedthe weight of three points for identifying theLibrary class. Thus, the maximum score is ninepoints, including three points for the Libraryclass and one point for each correctly identifiednon-interactive method. The presented scoringmethod is similar to [41], but it only considersnon-interactive requirements.

The first author who presented the tutori-als also evaluated the students’ class diagrams.These were subsequently checked by the sec-ond author. Since the expert solution is not theonly correct one, the evaluators were tolerant of

class diagram variations as long as the identifiedclasses and methods were in line with the criteriamentioned earlier. For example, a student mayuse different method and class names and/orplace a method in a different, but correct class.

7.3. Results and discussion

To address our research question presented inSection 7.1, we tested the following hypothesiswhich is similar to hypotheses in [41–43]:H0: There is no difference between the scores ofthe UC and OC groups.

We tested the research hypothesis using theMann–WhitneyU test, as in [42, 44]. Mann–Whit-ney U test is a nonparametric test for the differ-ence in two means [45]. The results of the testwere obtained using XLSTAT which is a statis-


tical analysis tool for Microsoft Excel [46]. Thefindings indicate that the score of the OC groupis significantly higher than the score of the UCgroup (p-value = 0.027), and therefore hypothesisH0 is rejected. Note that a significance level ofα = 0.05 is chosen as the level of significance.On average, participants in the OC group scoredsignificantly higher (X̄ = 4.286, SD = 2.498)than participants in the UC group (X̄ = 1.286,SD = 2.215; p = 0.027) (see Figure 7).

Below, we consider the four categories ofthreats to validity:1. Conclusion validity: A study has con-

clusion validity if the results are statisti-cally significant using appropriate statisticaltests [47, 48]. We used the Mann–WhitneyU test to analyse the results. The assump-tions of using this test have been checked.In order to increase the reliability of mea-sures [48], all student evaluations performedby the first author were checked by the secondauthor. All solutions were checked against anexpert solution that was constructed priorto the evaluation and checked for correctnessand completeness by the authors.

2. Internal validity: Internal validity refers tothe cause and effect relationship between theindependent and dependent variables. Onefactor affecting this kind of validity is hav-ing any prior significant difference between

the groups. In the design of our experiment,there was no significant difference betweenthe groups with respect to the cumulative de-gree average. In addition, we believe that theexercise of identifying operation cases causesthe systems analyst to identify non-interactivefunctional requirements, and thereby not missincorporating them in system design. This isour rationale for why the independent variablewould affect the dependent variable. One couldargue that the participants in the OC groupreceived direct training on identifying andmodelling non-interactive requirements whilethe participants in the UC group did not. Thiscould represent a threat to the internal validityof the experiment. To address this potentialthreat, we conducted a second experiment (seeSection 8) that demonstrates that practitionersoftware engineers who typically create usecase diagrams and follow the unified processof constructing use case diagrams first andusing them to create the analysis and designlevel class diagrams are expected to miss somenon-interactive requirements. This is becausethese non-interactive requirements are not em-phasized (in fact, they are neglected) by thestandard use case notations.

3. Construct validity: Construct validity con-cerns the use of measures that are relevantto the study. One factor affecting construct

OC

UC

0

1

2

3

4

5

6

7

8

9

Box plots

Figure 7. The box plots depicting the scores of the OC and UC groups


validity is how much the experimental settingdiffered from a real-world setting. The par-ticipants were not involved in a real-worldsystem with real clients and users. However,with regards to the limitation of use case di-agrams in modelling non-interactive require-ments, the experimental setup highly resem-bles real-world conditions. A systems analystcannot capture non-interactive requirementsusing a use case diagram only; and this hasa significant impact on the completeness of sys-tem design and implementation. Another rele-vant factor is the use ofmeaningful measures ofthe completeness of designmodels with respectto non-interactive requirements. We used thesame measure for completeness in terms ofthe number of identified methods in the classdiagram as in [41]. We believe that this isa relevant measure since missing a methodimplies a design and an implementation thatdo not implement all functional requirements.

4. External validity: External validity refersto the generalisability of the results. One fac-tor related to external validity concerns thefact that all participants were students. How-ever, the study in [49], as noted in [42], foundthat there are minor differences between soft-ware engineering students and professionalsoftware developers suggesting the use of stu-dents instead of professional developers insoftware engineering experiments is valid un-der certain conditions. A second factor is re-lated to the number of participants which isrelatively small. Given the resources availableon hand, this is the best subject populationwe could find. A third factor is related to thesize of the task which is relatively small anddoes not reflect the typical work by a systemsanalyst. However, most software engineeringexperiments use such small tasks due to theinherent difficulty of measuring attributes oflarge and complex tasks [41–43, 47].

8. An Empirical evaluation usinga case study

To address the threats to the internal validity ofthe controlled experiment presented in Section 7,

a second experiment was conducted. The experi-ment was in the form of a case study analysingthe performance of 30 graduate students in theMaster of Science in Computer Science programat COMSATS University Islamabad (Wah Cam-pus) on identifying non-interactive requirementsof a system. All of the students who participatedin the study had a bachelor’s degree and had com-pleted at least one undergraduate-level course onobject-oriented analysis and design. The majorityof the students were part-time students who wereactively working in industry. They were takingthe course Advanced Topics in Object-OrientedSoftware Engineering at the time of the exper-iment. The experiment was conducted duringregular class hours. All students completed thetasks during the regular class hours, althoughthey had been informed that extra time wouldbe given in case it was needed.

This experiment used the same system storyas the one in the controlled experiment. The stu-dents were handed the description of the LibraryManagement System shown in Figure 5. Thetask was identical to the task performed by theUC group in the controlled experiment, howeverno tutorial was provided on use case modelling.Information on each participant was collectedwith the submission, including the student idnumber, number of years since graduation, andcurrent employment if any. The class diagramsdeveloped by the students were collected andevaluated following the same scoring procedureas in the controlled experiment.

The same evaluation form was used as in thecontrolled experiment (shown in Figure 6). Withrespect to the number of non-interactive methodsidentified, the average score was 1.1 out of 6. Ona 95%-confidence level, the confidence interval forthe average score was (0.66, 1.54). The analysiswas done using XLSTAT. This shows that manynon-interactive requirements were missed andtherefore not incorporated in the class diagram.Furthermore, there were only 20 participants whohad identified at least one non-interactive method.Of these, 13 participants (i.e., 65%) incorrectlyrepresented the system itself as an actor in the usecase diagram. This shows that the standard usecase notation as practised might be inadequatein capturing non-interactive requirements.


Since the task done by the participants in thisexperiment is identical to that of the UC groupin the controlled experiment, this experiment islikely to suffer from the same threats to validityas in the controlled experiment. However, thenumber of participants is much higher in thisexperiment. In addition, the participants havehigher proficiency on use case modelling sincethey are graduate students with the majorityworking in industry. This experiment demon-strates that systems analysts who typically createuse case diagrams and follow the unified processof constructing use case diagrams first and usingthem to create the analysis-level class diagramsare expected to miss some non-interactive re-quirements. This is because these non-interactiverequirements are not emphasized (in fact, theyare neglected) by the standard use case notations.

9. Conclusion and future work

The representation and documentation of func-tional requirements at the analysis phase is themost crucial activity in the software developmentlife cycle. Use case modelling solves this problemby providing both textual and graphical methods,which makes it the most widely-used methodol-ogy. Use cases are designed into implementablemodules in the next phase of the developmentlife cycle. The problem, however, is the exclusionof some of the functional requirements in the usecase models. These requirements are often notrepresented as use cases as they are not initiatedby a user, and are thus known as non-interactiverequirements. Such requirements are often di-rectly addressed in the design phase without hav-ing any backward tracing to the use case models.It is evident from the available literature andexisting software development practices that usecase models are considered as a complete repre-sentation of all functional requirements of the sys-tem. Due to this practice, non-interactive require-ments are often overlooked and consequently re-sult in implementation of an incomplete system.To represent and document a complete system,non-interactive requirements need to be com-prehensively represented and documented along

with interactive requirements (use cases) in theanalysis phase. This paper addresses this problemand proposes an extension to use case modelsto accommodate non-interactive requirements.These requirements have been named as Opera-tion Cases and are represented with a new set ofgraphical notations and textual templates. Thepaper presents a new profile to extend UML’suse case notation with operation cases and theirrelated constructs. The addressing of operationcases at the analysis phase allows analysts anddesigners to comprehensively document and tracethe functional requirements effectively.

We applied operation cases in modellinga (partial) Mobile Phone operating system. Forthe sake of keeping it concise, only a few relevantfunctional requirements of the case study are dis-cussed. In the case study, we showed that usinguse case models alone cannot represent internalnon-interactive requirements of the system. Rep-resentation of operation cases solves this problemand makes use case models a more comprehensivegraphical representation of the functional require-ments of the system. A controlled experimentwas also conducted to investigate the hypothesisthat using operation cases results in more com-prehensive designs than when using traditionaluse cases only. The results of the experimentconfirmed our hypothesis.

Acknowledgement

This work has not received any funding.

References

[1] I. Jacobson, “Object-oriented development inan industrial environment,” in Proceedings ofthe Conference on Object-oriented Program-ming Systems, Languages and Applications, 1987,pp. 183–191.

[2] “Unified modeling language,” 2015, [AccessedSeptember 2019]. [Online]. http://www.omg.org/spec/UML/2.5

[3] J. Rumbaugh, I. Jacobson, and G. Booch, TheUnified Modeling Language Reference Manual.Addison-Wesley, 1999.

[4] B. Anda, K. Hansen, and G. Sand, “An investiga-tion of use case quality in a large safety-critical

http://www.omg.org/spec/UML/2.5

http://www.omg.org/spec/UML/2.5


software development project,” Information andSoftware Technology, Vol. 51, No. 12, 2009,pp. 1699–1711.

[5] S. Tiwari and A. Gupta, “Does increasing for-malism in the use case template help?” in Pro-ceedings of the 7th India Software EngineeringConference, 2014, pp. 6:1–6:10.

[6] D. Parachuri, A.S.M. Sajeev, and R. Shukla, “Anempirical study of structural defects in industrialuse-cases,” in Proceedings of the 36th Interna-tional Conference on Software Engineering, 2014,pp. 14–23.

[7] M. Ivarsson and T. Gorschek, “A method forevaluating rigor and industrial relevance of tech-nology evaluations,” Empirical Software Engi-neering, Vol. 16, No. 3, 2011, pp. 365–395.

[8] M. Glinz, “Problems and deficiencies of UML asa requirements specification language,” in Pro-ceedings of the International Workshop on Soft-ware Specification and Design, 2000, pp. 11–22.

[9] G. Génova, J.L. Morillo, P. Metz, R. Prieto-Díaz,and H. Astudillo, “Open issues in industrial usecase modeling,” Journal of Object Technology,Vol. 4, No. 6, 2005, pp. 7–14.

[10] P. Metz, J. O’Brien, and W. Weber, “Againstuse case interleaving,” in Proceedings of the In-ternational Conference on the Unified ModelingLanguage, Modeling Languages, Concepts, andTools, 2001, pp. 472–486.

[11] P. Metz, J. O’Brien, and W. Weber, “Specifyinguse case interaction: Clarifying extension pointsand rejoin points,” Journal of Object Technology,Vol. 3, No. 5, 2004, pp. 87–102.

[12] A.J.H. Simons, “Use cases considered harmful,”in Proceedings of the International Conferenceon Technology of Object-Oriented Languages andSystems, 1999, pp. 194–203.

[13] I. Jacobson, M. Christerson, P. Jonsson, andG. Övergaard, Object-oriented software engineer-ing – A use case driven approach. Addison-Wesley,1992.

[14] S. Tiwari and A. Gupta, “A systematic litera-ture review of use case specifications research,”Information and Software Technology, Vol. 67,2015, pp. 128–158.

[15] S. Tiwari and A. Gupta, “Investigating com-prehension and learnability aspects of use casesfor software specification problems,” Informa-tion and Software Technology, Vol. 91, 2017,pp. 22–43.

[16] M. Misbhauddin and M. Alshayeb, “Extendingthe UML use case metamodel with behavioralinformation to facilitate model analysis and inter-

change,” Software and Systems Modeling, Vol. 14,No. 2, 2015, pp. 813–838.

[17] S. Azevedo, R.J. Machado, A. Bragança, andH. Ribeiro, “The UML �include� relationshipand the functional refinement of use cases,” inProceedings of the EUROMICRO Conference onSoftware Engineering and Advanced Applications,2010, pp. 156–163.

[18] E.F. Cruz, R.J. Machado, and M.Y. Santos, “Onthe decomposition of use cases for the refinementof software requirements,” in Proceedings of theInternational Conference on Computational Sci-ence and Its Applications, 2014, pp. 237–240.

[19] K. van den Berg and A.J.H. Simons, “Con-trol-flow semantics of use cases in UML,” Infor-mation and Software Technology, Vol. 41, No. 10,1999, pp. 651–659.

[20] R.R. Hurlbut, “A survey of approaches for de-scribing and formalizing use cases,” Departmentof Computer Science, Illinois Institute of Tech-nology, Tech. Rep., 1997.

[21] P. Metz, J. O’Brien, and W. Weber, “Specify-ing use case interaction: Types of alternativecourses,” Journal of Object Technology, Vol. 2,No. 2, 2003, pp. 111–131.

[22] P. Stevens, “On use cases and their relationshipsin the unified modelling language,” in Proceed-ings of the International Conference on Fun-damental Approaches to Software Engineering,2001, pp. 140–155.

[23] D. Savic, A.R. da Silva, S. Vlajic, S. Lazarevic,V. Stanojevic, I. Antovic, and M. Milic, “Use casespecification at different levels of abstraction,” inProceedings of the International Conference onthe Quality of Information and CommunicationsTechnology, 2012, pp. 187–192.

[24] A. Al-alshuhai and F. Siewe, “An extension ofthe use case diagram to model context-aware ap-plications,” in Proceedings of the SAI IntelligentSystems Conference, 2015, pp. 884–888.

[25] M. El-Attar and J. Miller, “Constructing highquality use case models: a systematic review ofcurrent practices,” Requirements Engineering,Vol. 17, No. 3, 2012, pp. 187–201.

[26] T. Yue, L.C. Briand, and Y. Labiche, “aToucan:an automated framework to derive UML analysismodels from use case models,” ACM Transac-tions on Software Engineering and Methodology,Vol. 24, No. 3, 2015, pp. 13:1–13:52.

[27] C. Wang, F. Pastore, A. Goknil, L.C. Briand,and M.Z.Z. Iqbal, “Automatic generation ofsystem test cases from use case specifications,”in Proceedings of the International Sympo-


sium on Software Testing and Analysis, 2015,pp. 385–396.

[28] T. Yue, L.C. Briand, and Y. Labiche, “Facili-tating the transition from use case models toanalysis models: Approach and experiments,”ACM Transactions on Software Engineering andMethodology, Vol. 22, No. 1, 2013, pp. 5:1–5:38.

[29] N. Kesserwan, R. Dssouli, J. Bentahar, B. Stepien,and P. Labrèche, “From use case maps to ex-ecutable test procedures: a scenario-based ap-proach,” Software and Systems Modeling, 2017.

[30] S. Adolph, A. Cockburn, and P. Bramble, Pat-terns for Effective Use Cases. Addison-WesleyLongman Publishing Co., 2002.

[31] M. Smialek and W. Nowakowski, From Require-ments to Java in a Snap – Model-Driven Require-ments Engineering in Practice. Springer, 2015.

[32] K. Qi and B.W. Boehm, “A light-weight in-cremental effort estimation model for use casedriven projects,” in Proceedings of the IEEESoftware Technology Conference, 2017.

[33] M. Saroha and S. Sahu, “Tools and methods forsoftware effort estimation using use case pointsmodel – A review,” in Proceedings of the Inter-national Conference on Computing, Communi-cation and Automation, 2015, pp. 874–879.

[34] M. Grossman, J.E. Aronson, and R.V. McCarthy,“Does UML make the grade? insights from thesoftware development community,” Informationand Software Technology, Vol. 47, No. 6, 2005,pp. 383–397.

[35] D. Kulak and E. Guiney, Use Cases: Require-ments in Context. ACM Press, 2000.

[36] D. Liu, K. Subramaniam, B. Far, and A. Eber-lein, “Automating transition from use cases toclass model,” in Proceedings of the CanadianConference on Electrical and Computer Engi-neering. Toward a Caring and Humane Technol-ogy, 2003, pp. 831–834.

[37] P. Kruchten, The Rational Unified Process: AnIntroduction, 3rd ed. Addison-Wesley, 2003.

[38] S.S. Somé, “Supporting use case based require-ments engineering,” Information and SoftwareTechnology, Vol. 48, No. 1, 2006, pp. 43–58.

[39] J. Kettenis, “Getting started with use case mod-eling: White paper,” Oracle Corporation, Tech.Rep., 2007.

[40] “40 use case templates and examples,” [AccessedSeptember 2019]. [Online]. http://templatelab.com/use-case-templates/

[41] B. Anda and D.I.K. Sjøberg, “Investigating therole of use cases in the construction of class dia-grams,” Empirical Software Engineering, Vol. 10,No. 3, 2005, pp. 285–309.

[42] D. Beimel and E. Kedmi-Shahar, “Improving theidentification of functional system requirementswhen novice analysts create use case diagrams:the benefits of applying conceptual mental mod-els,” Requirements Engineering, 2018.

[43] F. Ricca, G. Scanniello, M. Torchiano, G. Reggio,and E. Astesiano, “Assessing the effect of screenmockups on the comprehension of functionalrequirements,” ACM Transactions on SoftwareEngineering and Methodology, Vol. 24, No. 1,2014.

[44] M. Dahan, P. Shoval, and A. Sturm, “Compar-ing the impact of the OO-DFD and the use casemethods for modeling functional requirementson comprehension and quality of models: a con-trolled experiment,” Requirements Engineering,Vol. 19, No. 1, 2014, pp. 27–43.

[45] D.C. Montgomery and G.C. Runger, AppliedStatistics and Probability for Engineers, 6th Edi-tion. John Wiley and Sons, 2013.

[46] “XLSTAT,” [Accessed March 2019]. [Online].https://www.xlstat.com/en/

[47] N. Fenton and J. Bieman, Software Metrics:A Rigorous and Practical Approach, 3rd ed. CRCPress, Inc., 2014.

[48] C. Wohlin, P. Runeson, M. Hst, M.C. Ohlsson,B. Regnell, and A. Wessln, Experimentation inSoftware Engineering. Springer Publishing Com-pany, 2012.

[49] M. Höst, B. Regnell, and C. Wohlin, “Usingstudents as subjects-a comparative study ofstudents and professionals in lead-time impactassessment,” Empirical Software Engineering,Vol. 5, No. 3, 2000, pp. 201–214.

http://templatelab.com/use-case-templates/

http://templatelab.com/use-case-templates/

https://www.xlstat.com/en/

Documents

Extending UML Use Case Diagrams to Represent Non ... · Use case modelling is one of the most widely-used methods to represent and document functional requirements of the system