TDT 4242

Inah Omoronyia and Tor Stålhane

Requirements Handling

TDT 4242

Institutt for datateknikk oginformasjonsvitenskap

TDT 4242

Requirements Handling - 1

Characteristics of an effective RE process:• Minimizes the occurrence of requirements errors

• Mitigates the impact of requirements change

• Is critical to the success of any development project.

The goal of the RE process is to ensure that requirement for a system can be allocated to a particular software component that assumes responsibility for satisfying the requirement. When such allocation is possible:• The resulting software is well modularized.• The modules have clear interfaces • All requirements are clearly separated.

TDT 4242

Requirements Handling – 2

Criteria for good requirements handling

Handle

•the view points of the system-to-be•non-functional requirements and soft goals•the identification and handling of crosscutting and non-crosscutting requirements•the impact of COTS, outsourcing and sub-contracting

TDT 4242

Viewpoints, perspectives and views

• Viewpoint: a standing position used by an individual when examining a universe of discourse – in our case the combination of the agent and the view that the agent holds

• Perspective: a set of facts observed and modelled according to a particular aspect of reality

• View: an integration of these perspectives• Viewpoint language is used to represent the

viewpoints

TDT 4242

Two classes of viewpoints

• Direct viewpoint: corresponds directly to clients in that they receive services from the system and send control information and data to the system. Either system operators/users or other subsystems interfaced to the system being analysed

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

• Example – a bank teller system. Indirect viewpoints may be:

• A security viewpoint concerned with transaction security

• A system planning viewpoint concerned with future delivery of banking services

• A trade-union viewpoint concerned with the effects of the system introduction on staffing levels and bank staff duties

TDT 4242

Example: Train break viewpointsConsider the requirements for a system to be installed on a

train which will automatically stop the train if it goes through a red light • Driver Requirements from the train driver on the

system

• Trackside equipment Requirements from trackside equipment which must interface with the system to be installed

• Safety engineer Safety requirements for the system

• Existing on-board systems Compatibility requirements

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

TDT 4242

Example: ATM Viewpoints

• Bank customers• Representatives of other banks• Hardware and software maintenance engineers• Marketing department• Bank managers and counter staff• Database administrators and security staff• Communications engineers• Personnel department

TDT 4242

Types of viewpointsData sources or sinks

Viewpoints that are responsible for producing or consuming data. Analysis involves checking that data is produced and consumed and that assumptions about the source and sink of data are valid

Representation frameworksViewpoints that represent particular types of system

model (e.g. State machine representation). Particularly suitable for real-time systems

Receivers of servicesViewpoints that are external to the system and

receive services from it. Most suited to interactive systems

TDT 4242

Viewpoint

Each requirement source (viewpoint) has a relationship with the proposed system based on its needs and interactions with the system

It is therefore important that the techniques used should adequately capture and organise not only global but also specific requirements of the different viewpoints into a cohesive knowledge structure that is both complete and visible

A proposed viewpoint structure is showed on the next slide

TDT 4242

The VORD method – 1

VORD is a method designed as a service-oriented framework for requirements elicitation and analysis.

Viewpoint Identificatio

n

Viewpoint Structuring

Viewpoint Documentatio

n

Viewpoint System mapping

TDT 4242

The VORD method – 2

1.Viewpoint identificationDiscover viewpoints which receive system services

and identify the services provided to each viewpoint

2.Viewpoint structuringGroup related viewpoints into a hierarchy. Common

services are provided at higher-levels in the hierarchy

3.Viewpoint documentationRefine the description of the identified viewpoints

and services4.Viewpoint-system mapping

Transform the analysis to an object-oriented design

TDT 4242

Example: ATM

• System accepts customer requests and produces cash, account information, provides for limited message passing and funds transfer

• It is required to make provisions for major classes of customers

• Home customers

• Foreign customers

• Update customer account database each time there is a cash withdrawal or funds transfer

TDT 4242

Abstract viewpoint classes • The process of understanding the system under analysis, its

requirements and constraints places a lot of reliance on the ‘system authorities’

• These are people or documents with an interest in or specialist knowledge of the application domain

• They include system end-users, system procurers, system engineers and documentation of existing system(s)

• System authorities are generalized into a set of viewpoint classes which can be used as a starting point to find viewpoints to a specific problem domain

TDT 4242

VORD method stages1. Prune the abstract viewpoint class hierarchy to eliminate viewpoints classes that are not relevant to the specific problem domain2. Consider the system stakeholders 3. Using a model of the system architecture identify subsystem views. In the ATM example we can identify one main subsystem the customer database4. Identify system operators who use the system on a regular basis, who use the system on occasional basis and who request others to use the system for them5. For each indirect viewpoint class that has been identified consider the principal individual who might be associated with that class

TDT 4242

VORD standard forms

Viewpoint template

Reference: The view point name

Attributes: Attributes providing viewpoint information

Events: A reference to a set of event scenarios describing how the system reacts to viewpoint events

Services: A reference to a set of service descriptions

Sub-VPs: The names of sub-viewpoints

Service template

Reference: The service name

Rationale: Reason why the service is provided.

Specification: Reference to a list of service specifications. These may be expressed in different notations.

Viewpoints: A List of viewpoint names receiving the service

Non-functional requirements: Reference to a set of non-functional requirements which constrain the service.

Provider: Reference to a list of system objects which provide the service.

TDT 4242

Structure of ATM customer and service distribution

TDT 4242

Viewpoint: Service Information

ACCOUNT HOLDER BANK TELLER

FOREIGN CUSTOMER

Service list

Withdraw cash

Query balance

Order checks

Send message

Transaction list

Order statement

Transfer funds

Service list

Withdraw cash

Query balance

Service list

Run diagnostics

Add cash

Add paper

Send message

TDT 4242

Viewpoint hierarchy

Services

Query balance

Withdraw cash

Services

Order checks

Send message

Transaction list

Order statement

Transfer funds

Account holder

Account holder

Teller

Manager Engineer

Bank staff

Customer

All Viewpoints

TDT 4242

Customer/cash withdrawal

Reference: Customer

Attributes: Account number; PIN; Start transaction

Events: Select service;

Cancel transaction;

End transaction

Services: Cash withdrawal

Balance inquiry

Sub-Viewpoints:

Account holder

Foreign customer

Reference: Cash withdrawal

Rationale: To improve customer service and reduce paperwork

Specification: Users choose this service by pressing the cash withdrawal button. They then enter the amount required. This is confirmed and, if funds allow, the balance is delivered.

Viewpoints: Customer

Non-functional requirements: Deliver cash within 1minute of amount being confirmed

Provider: __________

TDT 4242

Requirement handling – Viewpoint

Advantages of viewpoint-oriented approaches in requirements handling:

Assist in understanding and controlling the complexity by separating interests of various actors

Explicitly recognise the diversity of sources of requirements

Provide a mechanism for organising and structuring this diverse information

Imparts a sense of thoroughness (completeness)

Provide a means for requirements sources or stakeholders to identify and check their contribution to the requirements

TDT 4242

NFR and soft goals – 1 Scenario:Imagine that you have been asked by your client to conduct a requirements analysis for a new system intended to support several office functions within the organization, including scheduling meetings.

Clients success criterion: The new system should be highly usable, flexible and adaptable to the work patterns of individual users and that its introduction should create as little disruption as possible.

Question:how are you going to deal with the client’s objectives of having a usable and flexible system?

Challenge:We need some way to represent flexibility and usability concern, along with their respective interrelationships.

TDT 4242

NFR and soft goals – 2

The concept of goal is used extensively in AI where a goal is satisfied absolutely when its subgoals are satisfied.

NFRF is centered around the notion of soft goals which do not have a clear-cut criterion for their satisfaction

•Soft goals are satisficed when there is sufficient positive and little negative evidence for this claim, and that they are unsatisficeable when there is sufficient negative evidence and little positive support for their satisficeability.

TDT 4242

NFR Framework – 1

Soft goals are not analyzed independently of one another, but rather in relation to each other.

Softgoal relationships

TDT 4242

NFR Framework – 2

Non-functional requirements analysis: • Step1: Begins with soft goals that represent non-functional

requirements agreed upon by the stakeholders, say Usability, Flexibility, etc.

• Step 2: Each soft goal is then refined by using decomposition methods.

Decomposition can be based on :• General expertise/knowledge about security, flexibility etc.

• Domain-specific knowledge

• Project-specific knowledge – decided upon jointly by the stakeholders of the project

TDT 4242

Non-functional requirements analysis: Example (partial) result of flexibility soft goal decomposition for of nonfunctional requirements analysis for an office support system

✔

Access of otherstaff’s files

✔

Flexibility

✔Flexible work

patterns

✔

Access ofdatabase

✔

Sharing ofInformation

✔

Task switching

✔

Future Growth

✔

Separate PerformanceStandards

✔

Design forExtra Terminals

✔

Design forModularity

Flexibility soft goal decomposition

NFR Framework – 3

TDT 4242

NFR Framework – 4 Non-functional requirements analysis: Also involves finding lateral relationship the soft goals of individual soft goal trees

✔

Access of otherstaff’s files

✔

Flexibility

✔Flexible work

patterns

✔

Access ofdatabase

✔

Sharing ofInformation ✔

Task switching

✔

Future Growth

✔Separate PerformanceStandards

✔

Design forExtra Terminals

✔

Design forModularity

Flexibility soft goal decomposition and interference with softgoals belonging to different soft goal tree structures

Usability

Usability

Performance

Performance

Security

Security

Security

Security

Profitability

Profitability

Maintainability

Maintainability

Performance

Performance

--

+

--

+

+-

-

TDT 4242

Advantages of NFR Framework

NFR are obtained by gathering knowledge about the domain for which a system will be built.

NFRF focuses on clarifying the meaning of non-functional requirements

NFRF provides alternatives for satisfying soft goals to the highest possible level, considering the conflicts between them.

TDT 4242

Cross-cutting requirements – 1

How do we deal with cross-cutting concerns in goals requirements and constraints? A sub-goal, concrete requirements, etc. can be involved in the satisfaction of more than one higher level goal representation.An agent in most cases is involved in executing a number of system behaviors.

Goal

Sub goals

Concrete requirements, design constraints, assumptions

Agents

TDT 4242

Cross-cutting requirements – 2

Cross cutting requirements and constraints come from several sources. Example: embedded systems, IS, COTS- Commercial, off-the-shelf)

Problem domainProblem domain Solution SpaceSolution Space

Proposed

solution

Proposed

solution

Problem definitio

n

Problem definitio

n

Organisational context

Operational context

Requirements /Constraints

Requirements, Constraints, Problems and Solutions in RE

Market forces

TDT 4242

Cross-cutting requirements – 3

The cross cutting attribute results in requirements without clear distinct/atomic allocation to modules.Many non-functional requirements fall into this category.

Example:Performance is a factor of the system architecture and its operational environment. We cannot develop a performance module independent of other parts of a software system.

Such requirements are termed crosscutting (or aspectual) requirements. Examples of such properties include security, mobility, availability and real-time constraints.

TDT 4242

Cross-cutting requirements – 4

Aspects oriented requirements engineering is about identifying cross-cutting concerns early during requirements engineering and architecture design phase rather than during implementation. This involves four basic steps:

• Identify

• Capture

• Compose

• Analyze.

TDT 4242

Cross-cutting requirements – 5

Aspects oriented requirements engineering

Example scenario: Consider a banking system with many requirements, include the following:

Requirement A

1. Pay interest of a certain percent on each account making sure that the transaction is fully completed and an audit history is kept.

2. Allow customers to withdraw from their accounts, making sure that the transaction is fully completed and an audit history is kept.

TDT 4242

Cross-cutting requirements – 6Central concerns revealed in requirement A:

• “pay interest,” “withdrawal,” “complete in full,” and “auditing”

• Of those concerns, “pay interest” and “withdrawal” are described in separate requirements.

• However, “complete in full” and “auditing” are each described in both requirements 1 and 2.

Main challenge in requirement A:• Concerns are scattered across the requirement set

• If we want to find out which transactions should be fully completed or audited, we must sift through the whole requirements set for references to transactions and auditing.

TDT 4242

Cross-cutting requirements – 7Attempt to rewrite requirement A to remove scattered concepts:

Requirement B1. Pay interest of a certain percent on each account.

2. Allow customers to withdraw from their accounts.

3. Make sure all transactions are fully completed.

4. Keep an audit history of all transactions.

Main challenge in requirement B:

• This rewriting introduces implicit tangling between the newly separated concerns (“auditing” and “complete in full”) and the other concerns (“pay interest” and “withdrawal”).

• You can’t tell, without an exhaustive search, which transactions the “complete in full” and “auditing” properties affect.

TDT 4242

Cross-cutting requirements – 8

Example scenario: The broadly scoped concerns are considered as aspects (i.e. “complete in full” and “auditing” properties)

Requirement C – Aspect Oriented (AO) solution

1Δ Pay interest of a certain percent on each account.

2Δ Allow customers to withdraw from their accounts.

3Δ To fully complete a transaction…

3A List of transactions that must be fully completed: {1Δ, 2Δ}

4Δ To audit…

4A List of transactions that must leave an audit trial: {1Δ, 2Δ}

The AO solution is to make the impact explicit by modularizing aspects into two sections:

• one describes the requirements of the aspect concern itself (3Δ, 4Δ)

• one describes the breadth of its impact (3A, 4A).

TDT 4242

Cross-cutting requirements – 9

Advantages of early aspects:

Captures the core or base concerns (“withdrawal” and “pay interest”): 1Δ, 2Δ

Captures cross-cutting concerns as aspects: 3Δ, 4Δ

Describes Impact requirements: a requirement describing the influence of one concern over other concerns: 3A, 4A

TDT 4242

Example: Road toll collection system • In a road traffic pricing system, drivers of authorized vehicles are

charged at toll gates automatically. o The gates are placed at special lanes called green lanes. A

driver has to install a device (a gizmo) in his/her vehicle. o The registration of authorized vehicles includes the owner’s

personal data, bank account number and vehicle details. o The gizmo is sent to the client to be activated using an ATM that

informs the system upon gizmo activation. • A gizmo is read by the toll gate sensors. The information is stored by

the system and used to debit the respective account. • Authorized vehicle passes through a green lane => green light is

turned on, and the amount being debited is displayed. • Unauthorized vehicle passes through green lane => yellow light is

turned on and a camera takes a photo of the plate. • The amount paid on motorways depends on the type of the vehicle

and the distance travelledo single toll, where the same type of vehicles pay a fixed amounto entry toll to enter a motorwayo exit toll to leave a motorway

Use Case Diagram and Sequence diagram

TDT 4242

Identify concerns• Concerns are identified by analyzing the

initial requirements• Since the owner of a vehicle has to indicate

his/her bank details during registration security is an issue that needs to be addressed

• Other concerns: • Response time, • Compatibility, • Legal issues, • Correctness, • Availability

TDT 4242

Example: Road toll collection system

• Identify and describe non-functional concerns• The “tollgate response time” concern can be

described with a numbered set of requirements, as follows:

• R1. “When a car crosses a toll-gate, the system has to read the identifier in time t1.”

• R2. “Unauthorized vehicles using the green lane, have their plate numbers photographed in time t2.”

• R3. “When a car crosses a toll gate, the system has to turn on the light in time t3.”

• R4. “When an authorized vehicle crosses the gate, the system has to display the amount in time t4.”

Concern TollGateResponseTime

TDT 4242

Requirements for COTS – 1

• As the size and complexity of systems grow, the use of commercial off the shelf (COTS) components is being viewed as a possible solution.

• In this case requirements are constrained by the availability of suitable COTS component.

• Early evaluation of candidate COTS software products is a key aspect of the system development lifecycle.

TDT 4242

Requirements for COTS – 2

The impact of using COTS based components is expected to vary with the domain:

• For business applications a large, pervasive COTS product may be used to deliver one or more requirements (e.g., MS Office, Oracle, Netscape, etc.).

• For embedded real time or safety critical domains, the COTS components are expected to be small and require large amounts of glue code to integrate the COTS components with the rest of the system

TDT 4242

Requirements for COTS – 3Problems with COTS:

• An organizations have limited access to product’s internal design.

• The description of commercial packages is sometimes incomplete and confusing.

• Customers have limited chance to verify in advance whether the desired requirements are met.

• Most selection decisions are based on subjective judgments, such as current partnerships and successful vendor marketing.

TDT 4242

Requirements for COTS – 4Advantages of COTS:

• We get a product that has been tested many times by real-world users with consequent improvement in software quality.

TDT 4242

Requirements for COTS - example

TDT 4242

Requirements for outsourcing – 1

This is a management strategy by which an organization outsources/contracts out major, non-core functions to specialized, efficient service providers and third parties.

It is a rapidly growing market all over the world.

• Onshore outsourcing: outsourcing a project within own country

• Offshore outsourcing:Includes outsourcing services offered by countries outside Europe, typically overseas

• Nearshore outsourcing:E.g., for Scandinavian countries nearshore might be Baltic countries

TDT 4242

Requirements for outsourcing – 2

Phases:• Selection: This is about selecting the subcontractor

and is synonymous to tendering.

• Monitoring: This phase starts with the signed contract and follows the subcontractor’s work till the product is delivered.

• Completion: It includes acceptance and installation of the product, and in many cases also the maintenance of the product over its lifetime

TDT 4242

Requirements for outsourcing – 3

Advantages:• Cost savings• Improving service delivery and quality (is

gaining in importance)• Keeping pace with technological innovation

Disadvantage:• Companies will lose control over business

process and in-house expertise.

TDT 4242

ConclusionThere are several approaches for identifying and handling

requirements that are inherently complex, interdependent and multi-faceted.

• Viewpoints aims to explicitly model the interest of various actors.

• Non-functional requirements framework focuses on modeling of soft goals and clarifying their meaning

• Early aspects focuses on identifying cross-cutting concerns in requirements at the early phase of a project lifecycle.

• There is additional requirements handling consideration when using COTS components, outsourcing or sub-contracting