University of Toronto, CANADA

---

GRL Tutorial

 
This is a tutorial to show how the GRL language can be used to analyse Non-Functional Requirement within an application domain. We will first give a brief description of the example application domain and then use GRL to describe how NFRs are dealt with in this domain. Note that this example provides for one particular way GRL can be used, which emphasizes softgoals during modelling. There are other ways GRL can be used such as placing emphasis on actors, or on task and goals during the modelling.

Application Description


An information system at Financial Institution provides support for point of sale systems for financial transactions. Security issues in such system concerns both the system developer and the system user. The remote input systems are located at Retailers sites (in the "field" outside of the financial institution itself) and are used by the Retailers to allow their customers to pay for their purchases. Other pertinent financial services are provided to the Retailers that can be done through the system. The system itself consists of a Base Station (BS) and a set of Terminals, and a Host computer. Terminals are connected to the Base Station via a LAN, while the Base Station in connected through a leased or dial-up line to the host computer located at the financial institutions. A software development contractor develops the financial transaction software that resides at the Retailers and on the Host computer. The hardware is purchased externally from a Manufacturer. There are two "business processes" relevant for this example: 1. When the system is newly deployed. 2. When Terminal software need to be updated.

Case 1: When the system is newly deployed:

The developers receive hardware from the manufacturer, and load the initial version of the software into the system. The system is then provided to the financial institution where it is validated. The financial institution then provides the system to retailers and keeps track of what software and hardware was provided to whom, and other pertinent information relevant to the Retailer (such as special configuration data). Finally, the Retailer operates the system.

Case 2: When the system is updated:

Developers provide updates to the financial institution. The Financial institution uploads the updates to their host computer. Maintainers in the field download the updates into the base station, from where they then transfer it to the terminals.
 

There is a need to address security needs when producing, deploying and updating the financial software at the financial institution and at the Retailers site. The basic problem to be addressed is, how to keep the software code secure both in its source code form during development, and when the software is deployed as object code, and related parameter tables. For example, how to ensure that only authorised personnel can upload new updates to the Host, download updates from the Host and install them onto the base station and terminals, how to ensure that only authorised terminals are used. These and other security issues need to be addressed during the specification and development of the financial software itself and the software that facilitate the maintenance processes. Security touches on ease of use, performance, and cost; these attributes need to be considered and traded off among each other.

GRL Definitions

ELEMENT Software

ELEMENT TerminalSoftware

ELEMENT BaseStationSoftware

ELEMENT HostComputerSoftware

These statements provide a definition of the kind of elements that need to be secured. These elements were imported from an external model.

The following statement defines a softgoal on the security of the software of the system:

SOFTGOAL Security OF Software

where "Security" is a softgoal type, and "Software" is a softgoal topic. For the purpose of referencing this softgoal, a default name is automatically generated, which is the concatenation of the softgoal type, "OF" and the topic, e.g. "SecurityOFSoftware". The user can override the default name with this alternative form of the statement:

SOFTGOAL SoftwareSecured IS Security OF Software

Let us now refine that softgoal to more specific ones. Refining the softgoal clarifies what we mean by Security of Software, and it may be achieved.

SOFTGOAL OperationalSecurity OF Software

SOFTGOAL DevelopmentalSecurity OF Software

CONTRIBUTION

OperationalSecurityOFSoftware,

DevelopmentalSecurityOFSoftware

HAS And CONTRIBUTION-TO SecurityOFSoftware

These statements refine what "Security OF Software" means. It means security of software during operational activities, that is all activities related to the provision, updating, and regular working of the software, and it means security of software during development activities. The contribution statement also states that both ("And") are needed in order to ensure security of software. Security is not dealt with well when having stringent security for operations, while having "free" access to the source code during development.

Next, we recognise that for operational security, one should distinguish between operations that take place within financial institution and the development site, and operations that take place outside of these boundaries, such as at the Retailers site. This distinction can be shown as follows:

SOFTGOAL InternalOperationalSecurity OF Software

SOFTGOAL ExternalOperationalSecurity OF Software

CONTRIBUTION

InternalOperationSecurityOFSoftware,

ExternalOperationalSecurityOFSoftware

HAS And CONTRIBUTION-TO OperationalSecurityOFSoftware

We now also wish to distinguish among security that is related to the securing of the Terminal and of the Base Station and security measures related to the host computer that might be attached through activities performed externally. These considerations are expressed by the following definitions:

SOFTGOAL ExternalOperationalSecurity
OF TerminalSoftware

SOFTGOAL ExternalOperationalSecurity OF BaseStationSoftware

SOFTGOAL ExternalOperationalSecurity OF HostComputerSoftware

CONTRIBUTION

ExternalOperationalSecurityOFTerminalSoftware,

ExternalOperationalSecurityOFBaseStationSoftware,

ExternalOperationalSecurityOFHostComputerSoftware

HAS And CONTRIBUTION-TO ExternalOperationalSecurityOFSoftware

We could now make another distinction between securing application related software and operating system software, if we wish to deal with them differently. Perhaps operating system software for the pieces of equipment needs at least as stringent security measures as the financial applications running on top of them. However, we will not introduce this distinction here.

Let us now further focus on the TerminalSoftware and refine security into confidentiality, integrity and Availability. Confidentiality is protection against unauthorized disclosure. Integrity is protection against unauthorized update or tampering, and availability is protection against interruption of service through outside attacks. This refinement makes the meaning of security more particular in that we know what aspects of security we would further like to address. This refinement is expressed by the following definitions:

SOFTGOAL ExternalOperationalConfidentiality OF TerminalSoftware

SOFTGOAL ExternalOperationalIntegrity OF TerminalSoftware

SOFTGOAL ExternalOperationalAvailability OF TerminalSoftware

CONTRIBUTION

ExternalOperationalConfidentialityOFTerminalSoftware,

ExternalOperationalIntegrityOFTerminalSoftware,

ExternalOperationalAvailabilityOFTerminalSoftware

HAS And CONTRIBUTION-TO ExternalOperationalSecurityOFTerminalSoftware

We will now focus on the operation of update, download and storage provided by the terminal software for which we wish to have confidentiality ensured. This is shown by the following statements. Note that in order to shorten the names of the softgoal we will override the internally generated name. We will use the acronym EOC standing for "ExternalOperationalConfidentiality":

SOFTGOAL EOC_OFTerminalSoftwareForStorage IS

ExternalOperationalConfidentialityForStorage OF TerminalSoftware

SOFTGOAL EOC_OFTerminalSoftwareForDownload IS

ExternalOperationalConfidentialityForDownload OF TerminalSoftware

SOFTGOAL EOC_OFTerminalSoftwareForUpdate IS

ExternalOperationalConfidentialityForUpdate OF TerminalSoftware

CONTRIBUTION

EOC_OFTerminalSoftwareForStorage,

EOC_OFTerminalSoftwareForDownload,

EOC_OFTerminalSoftwareForUpdate

HAS And CONTRIBUTION-TO EOC_OFTerminalSoftware

Up until now we have only provided refinements for making the softgoal of having secure software more precise, and found that, among other things, it means to find a way to have storage, download and update of terminal software made confidential, i.e. have the software in now way disclosed to unauthorised parties. We will now focus on the various means we could employ for achieving these goals. Let us now focus on the different means we can employ for achieving confidentiality for the updates of terminal software. Three means are discussed: providing access authorisation, providing some kind of encryption, and providing limited exposure to accessing the software. Each one of these means does have additional alternatives. Let us model one at the time:

TASK AccessAuthorization

TASK LimitExposure

TASK Encryption

CONTRIBUTION

AccessAuthorization,

LimitExpose,

Encryption

HAS Make CONTRIBUTION-TO EOC_OFTerminalSoftwareForDownload

The Task AccessAuthorization has two subtasks: Authentication and Identification while each subtask provides a few alternatives ways. Since both of these tasks provide alternatives we will model them using the GOAL construct, and then provide for each alternative a task together with a means end link to its goal.
 

GOAL Authentication

GOAL Identification

Authentication can be done by using digital signatures, biometrics, card key and card reader equipment or password protection. Let us describe those alternative uses.

TASK DigitalSignatureAuthenication

TASK BiometricsAuthenication

TASK CardkeyAuthenication

TASK PasswordAuthentication

MEANS-END FROM DigitalSignature
TO Authentication

MEANS-END FROM BiometicsAuthentication
TO Authentication

MEANS-END FROM CardkeyAuthentication
TO Authentication

MEANS-END FROM PasswordAuthenication
TO Authentication

TASK OneSidedID

TASK MutualID

MEANS-END FROM OneSidedID
TO Identification

MEANS-END FROM MutualID TO Identification

Each one of the alternatives discussed is able to address the confidentiality requirements for updating the terminal software. However, each alternative has a different set of tradeoffs among other quality requirements that might be of importance. For example, using BiometricsAuthentication would provide a high-level of security, however, would be very expensive to provide. On the other hand, using a Cardkey Authentication is less expensive, but still needs some equipment and very user friendly. Finally, using password protection is the least expensive but has not the same user friendliness as the cardkey reader. We would model this kind of reasoning through correlation links to other softgoals.

Finally, in order to demonstrate the Belief construct, let us add a justification for our claim that using Biometrics has very negative impact on the purchase cost of the terminal. We support the very negative impact by the belief that "Biometrics is no regular off-the-shelf technology" and thus still very expensive to provide. Since the Belief is linked to a correlation link, we override the machine-generated identifier and provide a correlation link identifier of our own. This identifier is then used in the BELIEF clause.

ELEMENT TerminalSystem

SOFTGOAL PurchaseCost OF TerminalSystem

ELEMENT TerminalSystemUserInterface

SOFTGOAL UserFriendliness OF TerminalSystemUserInterface

Note that we specify here the correlation link identifier and name it BiometricAuthenticationCorrelationLink. This name is then used when declaring the Belief intentional element.

CORRELATION BiometricAuthenticationCorrelationLink
IS

BiometricsAuthentication

HAS Break CONTRIBUTION-TO PurchaseCostOFTerminalSystem

CORRELATION

CardKeyAuthentication

HAS Some- CONTRIBUTION-TO PurchaseCostOFTerminalSystem

CORRELATION

CardKeyAuthentication

HAS Make CONTRIBUTION-TO UserFriendlinessOFTerminalSystemUserInterface

CORRELATION

PasswordAuthentication

HAS Make CONTRIBUTION-TO PurchaseCostOFTerminalSystem

CORRELATION

PasswordAuthentication

HAS Some- CONTRIBUTION-TO UserFriendlinessOFTerminalSystemUserInterface

This Belief link is added at the bottom of the following diagram.

The textual description of this link is:

BELIEF BiometricAuthenticationCorrelationLink "Biometric is no regular off-the-shelf technology".

All the correlations described provide a basis for evaluating the alternative approaches that may be taken to ensure confidentiality, i.e., unauthorised disclosure of update and related information of the terminal software updates.

In order to illustrate actor related features of GRL, let us consider the following diagram. We wish to show two Actors participating in the deployment process described in case 1. Both Actors are concerned about security; however, each one may make different choices, based on actor context-dependent considerations.

The first diagram shows the Developer actor (i.e. the people within the development organization), and parts of the process to deploy the software system to the financial institution. During this process, first the developed software is loading onto special purpose hardware (that was supplied by the manufacturer), and then the system deliverables (both software and hardware) is provide to the financial institution.

The diagram shows that there are security concerns related to the deploying of the system. This security requirement is addressed by requiring authentication before loading of the software onto the hardware can commence. The AuthenticateLoader GOAL shows that two alternatives authentication options are considered: use Biometrics or use a Card Reader. As we have seen in the previous example each alterative has different tradeoffs. Biometrics authentication provides very good security. This is denoted by the Make contribution link from BiometricAuthentication Task to the Security Softgoal. It is, however very costly, which is denoted by the Hurt correlation link from the BiomtricAuthentication Task to the Cost Softgoal. The CardRead authentication provides good security, albeit to a lesser extent than Biometric authentication. This is denoted by the Some+ contribution link between CardReaderAuthentication Task and the Security Softgoal. Card Reader technology is, however, less expensive. This is denoted by the Some- correlation link between CardReaderAuthentication Task and the Cost Softgoal. Note that a Belief node is added to explain why Card Reader Authentication is less secure, since cards can be stolen, which introduces a concern not applicable to Biometric Authentication.

Note that contribution links are used to denote the primary reason for the choice of Tasks, while correlation links denote "side-effects" that relate to these Tasks. Finally, the diagram also adds the Belief "Card can be stolen" to support the fact that CardReaders are only providing "some+" contribution to the Security Softgoal.

This diagram illustrates that reasoning related to Softgoals may be "context dependent" and needs to be considered within the boundaries of an Actor. For the Developer Actor, we can argue that the Development organization is very concerned about Security. It may even be an important factor to being chosen a supplier of the financial institution. They would therefore rather choose Biometric Authentication than Card Readers, although it is the more expensive authentication method.

The next diagram shows the Financial institution Actor now receives the system deliverables and wishes to deploy the system further to its Retailer clients. During its deployment process the financial institution first verifies the system deliverables. This is denoted by the VerifySystem Task. Note that this task is dependent on receiving the system deliverables from the Developers. This dependency is denoted by the TheSystemDeliverable Resource dependency link between the Developer actor and the Financial Institution Actor. The next step in the financial institutions’ deployment process, is to data relate to the distribution of the system. This data involves among others handling of the systems software to be distributed. Similarly to the Developers Actor, the Financial Institution is concerned with Security, and wishes to Authenticate users who deal with the tracking system. In this example, the same alternatives for authentication are considered. However, the financial institution may argue, that since its premises are rigorously secured anyway, Biometrics would be "overkill", while a CardReader authentication system might be enough for securing the access to the software code that is uploaded for further distribution (within the tracking system). Note that if the Security Institution would already have Card Readers installed on site, then using a card reader would have a synergistic effect on the costs involved for authentication. Since such systems are already widely used anyway. This consideration was, however, omitted from the diagram, and would have involved a correlation link between the CardReaderAuthentication Task and the Cost Softgoal of some positive extent.