SIF 8060 - Modellering av informasjonssystemer, 20031 VORD Viewpoint Oriented Requirements...
-
Upload
moris-riley -
Category
Documents
-
view
216 -
download
0
Transcript of SIF 8060 - Modellering av informasjonssystemer, 20031 VORD Viewpoint Oriented Requirements...
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.