SIF 8060 - Modellering av informasjonssystemer, 2003 1

VORDViewpoint Oriented Requirements

Definition

Raimundas Matulevičius

2

Viewpoint Oriented Requirements Definition Kotonya G. Sommerville I., “Requirements engineering:

Processes and Techniques” Wiley, 1998. Interactive systems are systems that involve a significant

degree of user interaction. Important issues are: User interface – the ability to model and represent user interface

requirements is important because of the central role of end-user interaction.

User classes – interactive systems have varied classes of users with potentially conflicting requirements and expectations.

Other systems – have interface with other systems in their environment.

Indirect system - concerns related with system design and implementation, the influence to the system of organization and the system’s influence on the environment.

Quality of service – the reliability of the services delivered by the system performance, format of service and etc.

Some links: www.comp.lancs.ac.uk/computing/users/rcm/vord.html www.comp.lancs.ac.uk/computing/resources/re/

3

Viewpoints for interactive system specification VORD has been primarily developed to support the specification

of interactive systems and focuses on the external entities that interact with the system or effect its development.

VORD viewpoints fall into two classes:1. Direct viewpoints correspond directly to clients in that they

receive services from the system and send control information and data to the system. • Direct viewpoints are either system operators/users or other sub-

systems, which are interfaced to the system being analysed.

2. Indirect viewpoints have an ‘interest’ in some or all the services which are delivered by the system but do not interact directly with it. • Indirect viewpoints may generate requirements, which constrain the

services delivered to direct viewpoints, and the system development process.

• Indirect viewpoints vary radically. They may include engineering viewpoints, organizational viewpoints and external viewpoints.

4

Requirements definition

Viewpoint identification and structuring; Viewpoint documentation; Viewpoint requirements analysis and specification.

Identifyviewpoints

Documentviewpoints

Analyserequirements

Abstract viewpoints andabstract requirements

Specifyrequirements

Validaterequirements

IdentifiedViewpoints

Documentedviewpoints

Viewpointinformation

structureNegotiated

requirementsRequirementsspecification

Requirements space

5

Viewpoint notation VORD uses a simple graphical notation to represent a

viewpoint: A rectangular box represents the viewpoint. The viewpoint identifier is shown on the top left-hand

corner of the box and the viewpoint label in the lower half of the box.

The viewpoint type is shown on the top right half of the box. A viewpoint attribute is indicated by a vertical line dropping

from the left side of the box. Viewpoint specializations or sub-classes are shown from

left to right. The notation is augmented with viewpoint

information templates

6

Viewpoint notation (cont.)

Label

n Type

n.1

n.2

[m | attribute]

Viewpoint identifier

attribute list

Generalisation

7

Identifying viewpoints

“System authorities” are people or documents with an interest or specialist knowledge of the application domain.

A set of viewpoint classes, which can be used as a starting point for finding viewpoints specific to the problem domain

Viewpoint

Direct

Indirect

System

Operator

Regulatory

Organisation

Engineering

Environment

Maintenance

Standards

8

Identifying viewpoints (cont.)1. Prune the abstract viewpoint class hierarchy to eliminate

viewpoint classes which are not relevant for the specific system being specified.

2. Consider the system stakeholders, i.e. those people who will be effected by the introduction of the system.

3. Using a model of system architecture, identify system viewpoints, i.e. viewpoints representing other systems. This model may either be derived from the existing system

models or may have to be developed as part of RE.4. Identify system operators who use the system on a regular

basis, who use the system on an occasional basis, who request others to use the system for them.

5. For each indirect viewpoint class which has been identified, consider the roles of the principal individual who might be associated with that class.

9

ATM viewpoints

Bank customer

Home customer Security officer

Bank

Bank staff

Bank manager

Bank teller

ATM operator

Customer database

Card database

2 Operator

2.1

Foreign customer

Bank customer2.2

Bank customer

1 Operator

Bank staff1.1

Bank staff1.2

Bank staff1.3

3 Organisation

4 Organisation

System5

System6

10

Bank staff viewpoint documentation

Viewpoint Requirement

Identifier.

Label Description Type SourceVP

1 Bank staff 1.1 Provide access to administrative services based onvalid staff PIN and the access permissions set outfor the bank staff

sv 4

1.1 Bankmanager

1.1.1 Provide transaction reports to bank manager.

1.1.2 The bank manager requires transaction reports tobe provided on a daily basis

sv

sv

1.1

1.1

1.2 Bank teller 1.2.1 Provide for cancellation of cash card in the eventof lose or cancellation of card by bank.

1.2.2 Provide for card cancellation effected in no morethan 3 minutes from request.

sv

nf

4

4

1.3 ATMoperator

1.3.1 Allow for system startup and shutdown based onvalid staff PIN from ATM operator

1.3.2 Provide a facility for paging operator when fundsare low in ATM

1.3.3 Failure rate of the paging service should notexceed 1 in 1000 attempts

sv

sv

nf

4

4

3

11

Bank customer viewpoint documentation

Viewpoint RequirementIdentifier

Label Description Type SourceVP

2 Bank customer 2.1 Provide access to ATM services based onvalid cash-card, valid PIN and accesspermissions set out for the bank customer

2.2 Provide for withdrawal of cash by bankcustomers

2.3 Cash withdrawal service should beavailable 999/1000 requests

2.4 Cash withdrawal service should have aresponse time of no more than 1 minute

2.5 At least 50% of the currency notes in theATM should be 5 and 10 dollars notes.

sv

sv

nf

nf

nf

4

4

2

2

2

2.1 Home customer 2.1.1 Provide home customers with the facilityto transfer funds

2.1.2 Provide home customers with the facilityto obtain a printout of their last fivetransactions

2.1.3 Provide for balance enquiry by bankcustomers

sv

sv

sv

4

4

4

2.2 Foreign customer

12

Documenting other viewpointsViewpoint Requirement

Identifier

Label Description Type SourceVP

3 Security officer 3.1 All system security risks shall be identified,analysed and minimised according to theALARP (as low as is reasonably possible)principle.

3.2 Standard encryption algorithms shall be used.3.3 System shall print paper record of all

transactions

nf

nf

nf

4

4

4

4 Bank 4.1 Complete system maintenance shall be doneonce every month.

4.2 Cash withdrawal service should be availablein 90% requests for the service.

4.3 Cash withdrawal should have a response timeof no more than 2 minutes from the time ofrequest

4.4 System shall be operational in 6months4.5 System should accommodate all current

currency notes

nf

nf

nf

nfnf

4

4

4

44

5 Customerdatabase

6 Card database

13

Documenting viewpoint attributes

Bank customer

Home customer Security officer

Bank

Bank staff

Bank manager

Bank teller

ATM operator

Customer database

Card database

2 Operator

2.1

Foreign customer

Bank customer2.2

Bank customer

1 Operator

Bank staff1.1

Bank staff1.2

Bank staff1.3

3 Organisation

4 Organisation

System5

System6

[1 | cash_card]

[2 | account]

[3 | PIN] [1 | affiliated_bank]

[1 | staff_PIN]

[1 | emergency_funds]

[1 | customer_account]

[2 | PIN]

[1 | card_information]

[2 | pager]

14

Prioritizing requirements The most obvious way to prioritise requirements, is to base

priorities on the relative importance of the requirements with respect to the viewpoint

This fails to take into account the resources needed to deliver the requirement and the risk associated with the requirement

VORD includes a simple weighting scheme that organises weightings around importance, resources and risk

Each requirement is weighted as high (H), medium (M) or low (L) in relation to each of the three factors on a scale of 1-3

Weighting

Factor

High(H) Medium(M) Low(L)

Importance 3 2 1

Resources required 1 2 3

Risk involved 1 2 3

15

Non-functional requirements Non-functional requirements translate to constraints

on viewpoint services; Attributes; Development process in general.

Viewpoint AttributeIdentifier Description Constraint1.1 staff_PIN 3.2 standard bank encryption algorithms must

be used2.1 cash_card 3.2 standard bank encryption algorithms must

be used2.3 PIN 3.2 standard bank encryption algorithms must

be used should be four characters long1.3.1 emergency_funds 2.5 At least 50% of the currency notes in the

ATM should be 5 and 10 dollar bills.5.1 customer_account5.2 PIN6.1 card_information

16

Constraints on servicesViewpoint Service

Identifier description Constraint

All services 4.1 Complete system maintenance to be done once every month

4.4 System must be operational in 6 months

1.1.1 Transaction reports 1.1.2 Transaction reports must be provided on a daily basis

1.2.1 Card cancellation 1.2.2 Service should have a response time of no more than 3minutes

1.3.2 Operator paging whenfunds are low in ATM

1.3.3 Failure rate of the paging service should not exceed 1 in10000 attempts

2.2 Cash withdrawal 2.3 Cash withdrawal service should be available 999/1000requests

2.4 Cash withdrawal service should have a response time of nomore than 1 minute

2.5 At least 50% of the currency notes in the ATM should be 5and 10 dollars bills.

4.2 Cash withdrawal service should be available 9/10 requestsfor the service

4.3 Cash withdrawal should have a response time of no morethan 2 minutes

17

Modeling behavior VORD uses event scenarios to model dynamic system behaviour. An event scenario is defined as a sequence of events together with

exceptions which may arise during the interchange of information between a viewpoint and the intended system.

Viewpoint events are a reflection of control requirements as perceived by the user.

VORD uses an extended state transition notation to model event scenarios.

Statei Statej

event_1(parameters)[precondition_1]

[precondition_2]/action

NoteNormal sequenceException sequence

18

Event scenario for service access

ready

insert(card)

[card validCards]/display errormessage/return card

validate

enter(PIN)[card validCards

quit/return card

service[PIN validPINs/display service menu

[PIN validPINs] &[attempts > maxAllowed]/retain card/display card retentionmessage

verify

enter(PIN)[PIN validPINsattempts maxAllowed]/display errormessage

Noteattempts = number of attempts at PINmaxAllowed = maximum allowed attemptsvalidPINs = set of valid PINsvalidCards = set of valid cash-cards

19

User interface requirements User interface considerations are important in formulating the

requirements of interactive systems. However there is a close relationship between user interface requirements and

viewpoints. User interface requirements describe the mode and presentation of viewpoint

services. They can therefore be represented as constraints on viewpoint services. This process is, in turn, informed by viewpoint event scenarios which describe

the interaction between the viewpoint (in this case the user) and the system.

Viewpoint Servicerequires

Systemprovides

Event Scenarioi

Event scenarios

mode of presentationlayout of presentation

presentation constraints

describes interaction

20

Requirements analysis There are two main stages to this analysis.

1. Correctness of viewpoint documentation. The viewpoint documentation must be checked to ensure that it is consistent and that there are no omitted sections.

2. Conflict analysis; conflicting requirements from different viewpoints must be exposed and resolved.

Viewpoint type

Information

Direct Indirect

Identifier yes yes

Label yes yes

Description yes yes

Type (trace) yes yes

Attributes yes no

History yes yes

Service yes* no

Control yes* no

Event scenario yes no

Non-functional requirements optional yes

Specialisations optional optional

21

Conflict analysis Conflicts may arise from contradictions among

individual viewpoint requirements. Examples include:

where the service provision across viewpoints is associated with different constraints of the same general type

where the provision of a service across viewpoints is associated with similar constraints; but differing constraint values

These type of conflicts can be exposed by:1. Analysing the constraints associated with a particular service,

for consistency2. Analysing one viewpoint’s requirements against other viewpoint

(all) requirements for contradictions.3. All individual requirements must be analysed against high-level

organisational and other global requirements that define the general quality attributes of the intended system (e.g. safety, security..).

22

Conflict analysis (example)

ID 2.3 4.1

Description

Requirement 2

Cash withdrawalservice should beavailable in 999/1000requests

Complete systemmaintenance must bedone once everymonth

ID Description

2.3 Cash withdrawal service should be available999/1000 requests

-

2.4 Cash withdrawal service should have a responsetime of no more than 1 minute

2.1.3 Provide for balance enquiry by bank customers ?

3.1 All system security risks must explicitly identified,analysed and minimised according to the ALARP(as low as is reasonably possible) principle.

c

4.1 Complete system maintenance must be done onceevery month

-

4.3 Cash withdrawal should have a response time of

no more than 2 minutes from the time of request

4.4 System shall be operational in 6 months c

Requirement 1

23

Service specification VORD supports the specification of viewpoint services in a variety

of notations. This is particularly important for two reasons:

1. The ability to represent the same requirement in different notations which are familiar to different people enhances communication and aids understanding.

2. No one requirements notation can adequately articulate all the needs of a system. More than one specification language may be needed to represent the requirement adequately.

Customer requests cash withdrawal

if any of the following conditions is true refuse withdrawal:

condition1: The requested amount exceeds customer balance.

condition2: The funds in ATM are less than requested amount

else do the following:

dispense cash

update customer account

endif

24

Formal representation with Z

Specification for cash withdrawal

Free types for cash withdrawal

CashWithdrawalPermitWithdrawal RefuseWithdrawal

FundStatus::= adequate | inAdequateAccountStatus ::= overdrawn | goodStandingcriticalLevel = 1000accountNumber:0..10

6

Specification of Bank

Specification of PermitWithdrawal and RefuseWithdrawal

PermitWithdrawalBankamount ?:

account ? :accountNumber

amount ? CustomerFunds(account ?)customerFunds(account ?)’ =customerFunds(account ?) - amount ?

RefuseWithdrawalBankamount ?:

account ? :accountNumber

amount ? >CustomerFunds(account ?)

BankatmFunds:

fundStatus:FundStatuscustomerFunds:accountNumber

customerStatus:accountNumber accountStatus

c:AccountNumber (fundStatus = inAdequate) (atmFundscriticalLevel) (customerFunds(c)<0) (customerStatus(c) = overdrawn)

25

The requirements specification documentation

The final product of the requirements definition process is a requirements document.

The IEEE standard 830-1998 recommends that the requirements document should have 3 main sections. Section 1 introduces the purpose

and scope of the requirements document.

Section 2 describes the factors that affect the intended system and its requirements.

Section 3 describes the software requirements.

26

VORD requirements document templates

3. SPECIFIC REQUIREMENTSViewpointsIdentifier (reference and name of viewpoint)

A Description A short description of viewpointB TypeThis section defines the viewpoint type. A viewpoint typeProvides a trace to the viewpoint parentC SpecialisationsThis section provides a list of viewpoint specialisationsD HistoryThis section describes the evolution of the viewpoint and its requirements including the source of changes, changes, date andrationale for the changes.

E RequirementsE1 Services

Identifier (unique service identifier)Description (short description of service)Source (source of service)Priority (measure of importance of service)Event scenario(reference to event scenario)Specification (reference to various specs)

E2 Non-functional RequirementsIdentifier (unique requirement identifier)

Description (short description of non-functional requirement)

Source (source of non-functional requirement)Priority (measure of importance of requirement)Affected Services(list of service reference affected or constrained bynon-functional requirement)

27

Transition to object-oriented design

VORD supports the object-oriented development process. VORD can be thought of as two layered approach to

requirements definition: The first layer, the viewpoint layer, is concerned with formulating

viewpoint requirements. The second layer, the system layer, reconciles and interprets these

requirements in a cohesive object-oriented framework. A viewpoint service can be viewed as the product of the

interaction between system-level objects. Viewpoints represent classes of objects that constitute the

system and its environment. Direct viewpoints represent entities that map directly onto

system level objects and represent the first level of object identification.

Objects can also be exploding viewpoint attributes.

28

Bank customer viewpoint object structure

bank customer

home_customer

foreign_customer[PIN]

cash_card

[customer_name][card_id][account_no][expiry_date]

account

[affiliated_bank]

[account_name][account_no][balance][sort_code]

29

Summary

• Interactive systems can be defined as systems whose operations involve a significant degree of user interaction

• To be effective, the requirements definition process must address usability, varied user requirements, environment, organisational, quality of service issues posed by these systems.

• VORD is based on viewpoints that focus on user issues and organisational concerns.

• VORD defines two main types of viewpoints; direct and indirect.

• System behaviour is defined in VORD using event scenarios.

• Scenarios can used to describe exceptions and normal behaviour.

30

FEF1. Representation dimension

Framework for Evaluation of Functional Requirements for RET

FEF3. Specification dimensionFEF2. Agreement dimension

FEF1.1. Specify uniquely identifiable description using informal language.

FEF1.2. Specify requirements using semi- formal language(s).

FEF1.3. Specify requirements using formal language(s).

FEF1.4. Define traceable associations between requirements and the different elements of requirements specification.

FEF1.5. Connect seamlessly with other tools and systems, by supporting interoperable protocols and standards.

FEF2.1. Maintain an audit trail of changes, archive baseline versions; and engage a mechanism to authenticate and approve change requests.

FEF2.2. Classify requirements into logical user- defined groupings.

FEF2.3. Support secure, concurrent cooperative work between members of a multidisciplinary team, which may be geographically distributed.

FEF2.4. Maintain a comprehensive data dictionary of all project components and requirements in a shared repository.

FEF3.1. Collect and store common system’s and product family’s domain requirements.

FEF3.2. Generate predefined and ad hoc reports, documents that comply with standard industrial templates, with support for presentation-quality output and in-built document quality controls.

FEF3.3. Generate the complete specification, expressed using formal language (informal and semiformal languages might also be included), commonly agreed by all stakeholders.

31

Activities for Framework for Evaluation of RET - Representation

FEF1.1

a) provide natural language description at the early requirements engineering stage (RET must provide the natural language description, since this is essential criteria for non-technical stakeholders)?

b) allow specifying unique identification (ID) for each separate requirement?

c) allow importing of requirements and their description from textual document?

d) provide other techniques (drawing tools, model-based, etc) for informal description?

FEF1.2a) provide tools for semiformal language description (ER-diagrams, UML diagrams, etc)?

b) provide forward/ backward traceability between informal, semiformal, formal descriptions?

FEF1.3a) provide tools for formal language description (Z-schemas, algebraic specifications, action semantics,

B-notations, etc)?

b) provide forward/ backward traceability between informal, semiformal, formal descriptions?

FEF1.4

a) provide V&V functions for testing traceability between informal, semiformal and formal requirement description?

b) create parent-child traceable relations between requirements?

c) create peer-to-peer traceable relations between requirements?

d) create traceable relation between different related information?

e) maintain forward/ backward traceability between source of requirements, requirements and design?

FEF1.5a) allow importing/exporting requirements description from/to textual documents?

b) allow importing/exporting requirements description from/to graphical documents?

32

Activities for Framework for Evaluation of RET - Agreement

FEF2.1

a) maintain user authentication to the system (provide user name, password)?

b) allow grouping users into different groups?

c) allow creating different functionality views (according to documents, requirements, attributes) for different groups of stakeholders?

d) register agreement/ rationale/ discussion/ negotiation/ changes/ history of requirements and by how it was achieved?

e) call the earlier requirement description/ versions and register them into history context?

FEF2.2a) allow specifying attributes/ properties of the requirement?

b) provide sorting according to different attributes/ properties?

c) provide filtering according to different attributes/ properties?

FEF2.3

a) deal with usability (standalone application, Intranet, Internet based program)?

b) provide www-based interface for geographically distributed users?

c) allow making copy for modification of already approved version of requirements description in different abstract levels (document, requirement, attribute)?

d) provide change approval cycle for multiple change negotiation and approval before posting into common repository?

e) provide forward/ backward traceability between informal, semiformal, formal descriptions?

FEF2.4a) provide the single repository or data dictionary?

b) provide separate data dictionaries for non-technical users and technical users?

c) provide the help system to the users?

33

Activities for Framework for Evaluation of RET - Specification

FEF3.1a) enable selection and extraction of common domain requirements?

b) incorporate common requirements to concrete project?

c) adapt/ spread changes in domain requirements to concrete projects within domain?

FEF3.2

a) provide wizards for report generation?

b) provide possibility to print report according views and sorting?

c) provide possibility to print results of rationale, brainstorm and etc?

d) provide techniques for error checking?

FEF3.3a) correspond to standards of software documentation?

b) support formal languages for complete, commonly agreed requirements specification?

34

Semiotic quality framework by RET evaluation framework

Features Physical Empiri-cal

Syntac-tic

Semantic Perceived semantic

Prag-matic

Social

Ext. Int. Min. err. freq.

Correct. Valid. Comp. Perc.

valid.

Perc. compl.

Compr. Agr.

FEF1.1. X X

FEF1.2. X X X

FEF1.3. X X X X

FEF1.4. X X X

FEF1.5. X X X

FEF2.1. X X X

FEF2.2. X X

FEF2.3. X X

FEF2.4. X X

FEF3.1. X X X

FEF3.2. X X X X

FEF3.3. X X X

35

Evaluation results

Features RET1 RET2 RET3 RET4 RET5 RET6 RET7 RET8

FEF1.1. High Medium Medium Medium High Medium High Medium

FEF1.2. High Medium Medium High Low Low Low Medium

FEF1.3. Medium Low Low High Low Low Low High

FEF1.4. High Medium Low Medium Medium Medium High High

FEF1.5. Medium Medium Medium High Low Medium Medium High

FEF2.1. Medium Medium High High Medium Medium Medium Medium

FEF2.2. Medium High Medium High High High High Medium

FEF2.3. Low Medium Medium Medium Low Low Low Low

FEF2.4. Low High Medium Medium Medium Low Medium Medium

FEF3.1. Low Medium Medium Medium Low Medium Medium High

FEF3.2. Medium High Medium High High Medium Medium Medium

FEF3.3. Medium Low Low Medium Low Medium Medium High

RETs: Core 3.1 Trial, DOORS 5.2., Caliber-RM Web v.4.0., RequisitePro, Vital Link, XTie-RT 3.1., RDT Version 3.0, Cradle-4.