Date post: | 07-Sep-2014 |
Category: |
Documents |
Upload: | sameenjaved27 |
View: | 119 times |
Download: | 0 times |
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.
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST3
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.
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST4
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST5
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.)
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST6
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.
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST7
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST8
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:
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST9
• 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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST11
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST12
• 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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST13
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST14
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST15
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST16
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST18
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.
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST19
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.
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST20
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST21
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST22
SADT Level 1 Diagram
PerformATM Services
Transaction Info
Card Info
PIN
Cancel
Cash
Receipt
ATM UsageTerms andConditions
NetworksSoftware Toolsand Databases
A-1
Lost/StolenCards List
BankApprovals
DisplayMessages
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST23
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST24
SADT Level 1 Diagram
PerformOperatorServices
ShutdownMessage
StartupMessage
CashAmount
ATM UsageTerms andConditions
A-2
DisplayMessages
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST25
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST26
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST27
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST28
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST29
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST30
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST31
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST32
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST33
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”
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST34
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST35
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST36
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST37
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST38
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST39
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST40
Mapping on different styles same domain
Mapping on different domains same style
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST41
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST42
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
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST43
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)
Adv Requirements Engineering- MSCS 18 by Asst Prof Athar Mohsin, MCS-NUST44
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