Lecture 10- VORE

Viewpoint Oriented Requirements Engineering Methods

Lecture 10

Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST2

Viewpoints • A viewpoint-based approach to requirements

engineering recognizes that:– All information about the system requirements cannot be

discovered by considering the system from a single perspective.

– It is needed to collect and organize requirements from a number of different viewpoints.

• A viewpoint is an encapsulation of partial information about a system’s requirements. – Information from different viewpoints must be integrated

to form the final system specification.


Viewpoints • Arguments in favor of a viewpoint-based approach to

requirements engineering are:– Systems usage is heterogeneous - there is no such thing as a

typical user. • Viewpoints may organize system requirements from different classes of

system end-user and other system stakeholders.

– Different types of information are needed to specify systems including:

• information about the application domain, system’s environment and about the system’s development.

– Viewpoints may be used to collect and classify this information.

– Viewpoints may be used as a means of structuring the process of requirements elicitation.

– Viewpoints may be used to encapsulate different models of the system each of which provides some specification information.

– Viewpoints may be used to structure the requirements description and expose conflicts between different requirements.


Viewpoints-Oriented Requirements Engineering• RE involves the capture, analysis and resolution of many

ideas, perspectives and relationships at varying levels of detail– Methods based on rigid global schemes do not adequately address

the diversity of issues presented by RE problems– Methods based on the notion of viewpoints evolved to address the

problem

• Viewpoints Oriented Analysis – Stakeholders represent different ways of looking at a problem or

problem viewpoints• different types of stakeholders

• different views among stakeholders of same type

– This multi-perspective analysis is important as there is no single correct way to analyze system requirements


Viewpoints in RE• Two different kinds of viewpoints in the VP-based RE

methods:– Viewpoints associated with system stakeholders.

• Informally, a system stakeholder is anyone who is, directly or indirectly, affected by the existence of a system.

– Stakeholders may be end-users of a system, managers of organizations where systems are installed, other human and computer-based systems in an organization, external entities who have some kind of interest in the system (e.g. regulatory bodies, customers of an organization which has installed the system) and engineers involved in the design, development and maintenance of the system.

– Viewpoints associated with organizational and domain knowledge.• Organizational and domain knowledge is knowledge which constrains

the system requirements. – The constraints may be physical (e.g. network performance), organizational

(e.g. incompatible hardware used in a company), human (e.g. average operator error rate) or may reflect local, national or international laws, regulations and standards.

• This type of viewpoint cannot be associated with a single class of stakeholder but includes information collected from many different sources (people, documents, other systems, etc.)


Types of viewpoint• Interactor viewpoints

– People or other systems that interact directly with the system.

• e.g. In an ATM, the customer’s and the account database are interactor VPs.

• Indirect viewpoints– Stakeholders who do not use the system themselves but

who influence the requirements. • e.g. In an ATM, management and security staff are indirect

viewpoints.

• Domain viewpoints– Domain characteristics and constraints that influence the

requirements. • e.g. In an ATM, an example would be standards for inter-bank

communications.


Viewpoint identification• Identify viewpoints using

– Providers and receivers of system services;– Systems that interact directly with the system being specified;– Regulations and standards;– Sources of business and non-functional requirements.– Engineers who have to develop and maintain the system;– Marketing and other business viewpoints.

Articleproviders

FinanceLibrarymanager

Librarystaff

Users

InteractorIndirect

All VPs

Classificationsystem

UIstandards

Domain

ExternalStaffStudents CataloguersSystem

managersLIBSYS viewpoint hierarchy


Example• Consider the requirements for a system to be installed on

a train which will automatically bring the train to a halt when it wrongly goes through a danger signal

• Some examples of viewpoints for this system and the requirements they encapsulate might be:– Driver:– Trackside equipment:– Safety engineer:– Existing on-board systems:– Braking characteristics:


• Driver:– Requirements from the train driver on the system.

• For automatic system these will mostly be NFRs concerning usability

• Trackside equipment:– Requirements from trackside equipment

• These must be interface related with the system to be installed

• Safety engineer:– Safety requirements for the system from the railway safety engineer

• Existing on-board systems:– Compatibility requirements coming from other on-board control systems

• Braking characteristics:– Requirements which are derived from the braking characteristics of a train.

VP-based RE Methods


Structured Analysis and Design Technique (SADT)• A model of the problem is constructed, which is composed

of hierarchy of diagrams– Each diagram is composed of boxes and arrows– The topmost diagram, called the context diagram, defines the

problem most abstractly– As the problem is refined into sub-problems, this refinement is

documented into other diagrams• Boxes should be given unique names that should always be verb

phrases, because they represent functions

• All boxes should be numbered in the lower right corner, to reflect their relative dominance

• Arrows may enter top, left, or bottom sides of the box, and can exit only from the right side of the box

An SADT Context Diagram


• An arrow pointing into the left side of a box represents things that will be transformed by the box. – Represents the inputs

• An arrow pointing down into the top of the box:– Represents control that affects how the box transforms the

things entering from left side• Arrows entering the bottom of a box:

– Represent mechanism and provide the analyst with the ability to document how the function will operate, who will perform it, or what physical resources are needed to perform the function


SADT & IDEF• IDEF (Integration Definition for Function Modeling) method is

designed to model the decisions, actions, and activities of an organization or system.– It was derived from the established graphic modeling

language SADT (Structured Analysis and Design Technique) developed by Douglas T. Ross

– In its original form, IDEF0 includes:• A definition of a graphical modeling language (syntax and

semantics) and • A description of a comprehensive methodology for developing

models


IDEF0 Fundamentals• Diagrams based on simple box and arrow graphics, arrows

convey data or objects– Text labels to describe boxes and arrows and glossary and text to

define the precise meanings of diagram elements– Box name shall be a verb or verb phrase, such as "Perform

Inspection”, arrows are nouns• Gradual exposition of detail, with the major functions at the

top and with successive levels of sub functions revealing well-bounded detail breakout– The limitation of detail to no more than six sub functions on each

successive function• A "node chart" that provides a quick index for locating

details within the hierarchic structure of diagrams• There is always an A-0 context diagram, and its box

number is always 0. – This is a strict part of the standard that helps identify the overall

description of the system


Pos

sibl

e V

iew

poin

ts

SADT viewpoints• SADT does not have an explicit notion of viewpoints

– Instead viewpoints are an intuitive extension of its modelling technique

• SADT “viewpoints” are sources and sinks of data – In example “viewpoints” are shown in square brackets

[Library user]

[Issue clerk]

library card

Issue library item [Library user]issued itemreturn date

requested item

[Library user]

I1

I2

I3

01

User database

User details

Item database

Item availability

example Library Issue item function-Activity Diagram

Library Items

Activity

Algo

Control

inputoutput

Control information/ Pre conditions

Output


Example

User database

Library Card

Item database

Check user

Check item

Issue item

Requested item

Return date

User detail

User status

Update details

Issued item

Item availability

Item status

Checked item

Refinement of the issue library item function

Data-flow diagram for Issue

Application of SADT on Banking System Case Study


Problem Description• A bank has several automated teller machines (ATMs),

which are geographically distributed and connected via a wide area network to a central server.

• Each ATM machine has a card reader, a cash dispenser, a keyboard/display, and a receipt printer.

• By using the ATM machine, a customer can withdraw cash from either current or savings account, query the balance of an account, or transfer funds from one account to another.

• A transaction is initiated when a customer inserts an ATM card into the card reader. Encoded on the magnetic strip on the back of the ATM card are the card number, the start date, and the expiration date.– Assuming the card is recognized, the system validates the ATM card to

determine that the expiration date has not passed, that the user-entered PIN (personal identification number) matches the PIN maintained by the system, and that the card is not lost or stolen.

• The customer is allowed three attempts to enter the correct PIN; the card is confiscated if the third attempt fails.

• Cards that have been reported lost or stolen are also confiscated.


Problem Description• If the PIN is validated satisfactorily, the customer is

prompted for a withdrawal, query, or transfer transaction.• Before withdrawal transaction can be approved, the

system determines that sufficient funds exist in the requested account, that the maximum daily limit will not be exceeded, and that there are sufficient funds available at the local cash dispenser.

• If the transaction is approved, the requested amount of cash is dispensed, a receipt is printed containing information about the transaction, and the card is ejected.

• Before a transfer transaction can be approved, the system determines that the customer has at least two accounts and that there are sufficient funds in the account to be debited.

• For approved query and transfer requests, a receipt is printed and card ejected.


Problem Description• A customer may cancel a transaction at any time; the

transaction is terminated and the card is ejected.

• Customer records, account records, and debit card records are all maintained at the server.

• An ATM operator may start up and close down the ATM to replenish the ATM cash dispenser and for routine maintenance. – It is assumed that functionality to open and close accounts and to

create, update, and delete customer and debit card records is provided by an existing system and is not part of this problem.

» ‘Designing Concurrent, Distributed, and Real-Time Applications with UML’ by H. Gomaa, Addison-Wesley, 2000


Banking System Context Diagram

ATM SystemTransaction Info

Card Info

PIN

Cancel

Cash

Receipt

ATM UsageTerms andConditions

NetworksSoftware Toolsand Databases

A-0

Lost/StolenCards List

BankApprovals

DisplayMessages

OperatorInstructions


SADT Level 1 Diagram

PerformATM Services

Transaction Info

Card Info

PIN

Cancel

Cash

Receipt


NetworksSoftware Toolsand Databases

A-1

Lost/StolenCards List

BankApprovals

DisplayMessages


SADT Level 2

Read & ValidateCard

ProcessRequest

PrintReceipt

DispenseCash

ATM UsageTerms andConditions Bank

Approvals

CardInfo

Transaction InfoPIN

Cancel

ReceiptData

Cash

Receipt

DisplayMessages

ValidCardInfo

A-1-1

A-1-2

A-1-3

A-1-4

Lost/StolenCards

ATMConditions

ATMConditions


SADT Level 1 Diagram

PerformOperatorServices

ShutdownMessage

StartupMessage

CashAmount


A-2

DisplayMessages


Controlled Requirements Expression (CORE)

• CORE was developed for the British Aerospace by System Designers– The CORE method is based on functional

decomposition approach

• CORE is explicitly adopts a VP approach to formulating requirements:

• CORE define its VPs at two levels – First level comprises of all entities that interact or affect

the intended system (Defining VPs) and entities that interact indirectly (Bonding VPs)

– Second level distinguishes between defining and bonding VPs


Controlled Requirements Expression (CORE)

• CORE is explicitly based on viewpoints– Two types of Viewpoints:

• Defining viewpoints Sub-processes of the system, viewed in a top-down manner

– Entities that interact with or affect the intended system » Functional & non functional view points are identified

• Bounding viewpoints Entities that interact indirectly with the intended system

– Entities that interact indirectly with the intended system

• The CORE method is made up of 7 iterative steps:1. Viewpoint identification

2. Viewpoint structuring

3. Tabular collection

4. Data structuring

5. Single viewpoint modelling

6. Combined viewpoint modelling

7. Constraint analysis


Step 1-Identifying viewpoints• Library example

– The first step involves identifying possible viewpoints– From this initial list, defining and bounding viewpoints are identified

• There are no hard and fast rules for identifying relevant viewpoints

Library user

Library card

Issue clerk

Update item database

Book

Catalogue item

User database

Video

Book supplier

Register user

Issue itemValidate user

Procure item

Return item

Item database

Initial viewpoints


Step 1 – continued…• The identified VPs are now grouped into a set of bounding

and defining viewpoints– Each bubble represents the most abstract form of the viewpoint

Library user Register user

Issue clerk

Book supplier

Catalogue item

Userdatabase Issue item

Validateuser

Order item

Return item

Itemdatabase

Update itemdatabase

Bounding Viewpoints Defining Viewpoints

Bounding and defining viewpoints


Step 2 - Viewpoint structuring• Involves iteratively decomposing the ‘target system’ into a

hierarchy of functional sub-systems– Structurally bounding viewpoints are placed at the same level as

the target system – Each functional subsystem constitutes a viewpoint

Library World

Library user Book supplier Library system Item database User database

Register function Issue function Updatefunctions

Orderfunctions

Library system- viewpoint structuring


Step 3 - Tabular collection• Each viewpoint is considered in turn with respect to the:

– Action it performs, Data used for these actions, the output data derived, the source of the data and the destination of the data

• Tabular collections serve the purpose of exposing omissions and conflicts in the information flow across viewpoints

Source Input Action Output Destination

Library user requesteditem

check item issued item Library user

error message Issue clerk

Library user library card validate user loan default message Issue clerk

Library system- tabular collection


Steps 4-7• The data structuring step involves decomposing

data items into constituent parts and creating a data dictionary

• Step 5 and 6 involve modelling viewpoint actions using action diagrams

– An action diagram is similar in notation to an SADT diagram

• The final step in CORE– involves performing constraint analysis on the system as a whole


Viewpoint-oriented System Engineering (VOSE)

• VOSE is a framework that addresses the entire system development cycle (integrate the development method in a lifecycle)– Viewpoints are used to partition and distribute the

activities and knowledge of the participants in software development

• Uses data-flow and state transition scheme to model the system– Requires further examination of consistency between

different viewpoints• Viewpoints capture the role and responsibility of a

participant at a particular stage of software development process


VOSE • VOSE as a framework:

– The software development involves the participation of many experts, in various aspects of software development and application areas.

– Each participant may have responsibilities and concerns which may change and shift the software develops and evolves.

• Viewpoints are used to partition and distribute the activities and knowledge of the participants in software development

• Viewpoints capture the role and responsibility of a participant at a particular stage of software development process

– Viewpoints are identified by the role of the participant, domain relevant to his interest and the knowledge about the domain of application

• The knowledge is encapsulated in viewpoint and represented using a single appropriate representative scheme Called a “STYLE”


Viewpoint template• A Viewpoint can be thought of as a template describing:

– Style or representative scheme what it sees– Domain as it sees – Specification– Work plan- identify the conditions under which the specification can

be changed – Work record

Standard viewpoint template slots


Viewpoint configurations• Viewpoints can be organised into configurations

– The collection of related viewpoints

• A configuration may consist of– Templates with different styles:

• ‘viewing’ the same partition of the problem domain, or

– Templates with the same style:• ‘viewing’ different partitions of the problem domain

• Final system is a combination of the configurations with all the conflict resolved

Library user domain

Issue desk domain

state transition model

state transition model data-flow model

Identify correspondence toresolve conflicts

Resolveconflicts

Different templates same domain

Different domains same template


Library example• Consider a library item presented the user at the

issue desk for borrowing, returning or reserving– ‘Library world’ can be partitioned into the domains of the

issue desk and the library user• Data-flow and state transition schemes are used to

model the library item from point of view each domain– Data flow model (issue desk domain)

» Items undergo certain processing at issue desk– State Transition model (issue desk domain)

» Various states can be seen at issue desk


Example – a VOSE data flow• Data flow model (issue desk domain)

– Items undergo certain processing at issue desk– Activities are represented as:

• Check, issue and Release processes

– Check process accepts as input the presented items and processes it for issue, remove or release

– Issue process accepts as input the checked item and provide as output an issued item

– The release process, release the item from reserve


Example – a VOSE state transition

Off-desk

Checked

Reserved

On-loanPresented

On-loan Finished On-shelf Presenteduse return present

check loan

reserverelease

remove

State transition diagram seen by the issue desk

State transition diagram seen by the library user


Conflict resolution• Important to ensure that consistency between different

representations of the domains– For similar styles conflicts are resolved by checking for the loss of

continuity between the models– For different styles the correspondences between representation

schemes need to be identified to facilitate consistency checking

Library user domain

Issue desk domain

state transition model

state transition model data-flow model

Identify correspondence toresolve conflicts

Resolveconflicts

Different templates same domain

Different domains same template

Consistency checking


Mapping on different styles same domain

Mapping on different domains same style


Viewpoint-oriented requirements definition- VORD

• Developed at the University of Lancaster– Mainly intended for specifying interactive systems

• Based on viewpoints that focus on user issues and organisational concerns

• The uses a service oriented model for viewpoints• VORD defines two main types of viewpoints;

– Direct viewpoints• Interact directly with the intended system

– Indirect viewpoints • Do not interact directly with the intended system


Direct and indirect viewpoints• Direct viewpoints-Interact directly with the intended system

– Correspond directly to clients in that they receive services the system and provide control information

– Include operators/users or other sub-systems interfaced to the system being analysed

• Indirect viewpoints-Do not interact directly with the intended system– Indirect viewpoints have an ‘interest’ in some or all the services which

are delivered by the system– Generate requirements which constrain the services delivered to

direct viewpoints– Includes organisation, environment, engineering and regulatory

viewpoints


Examples of direct and indirect viewpoints

• A systems planning viewpoint which is concerned with future delivery of library services (indirect)

• A library user viewpoint which is concerned with accessing the system services through the internet (direct)

• A trade-union viewpoint which is concerned with the effects of system introduction on staffing levels and library staff duties (indirect)


References • Viewpoints for requirements elicitation: a practical approach, I.

Sommerville, P. Sawyer and S. Viller, Computing Department, Lancaster University

• Viewpoints: Principles, Problems and a Practical Approach to Requirements Engineering Ian Sommerville and Pete Sawyer

• Practical Experience with Viewpoint-oriented Requirements Specification Gerald Kotonya

• ‘Software Design Methods for Concurrent and Real-Time Systems’ by H. Gomaa, Addison-Wesley, 1993

• ‘Designing Concurrent, Distributed, and Real-Time Applications with UML’ by H. Gomaa, Addison-Wesley, 2000

• Chapter 7 ‘Requirements Engineering: Processes and Techniques’ by G. Kotonya and I. Sommerville, John Wiley & Sons, 1998

Lecture 10- VORE

Documents

Transcript of Lecture 10- VORE