USING VIEWPOINTS FOR REQUIREMENTS ELICITATION

Aluno:Cleviton Monteiro (cvfm@cin.ufpe.br)

Professor:Jaelson Castro (jbc@cin.ufpe.br)

Agenda

Motivation Viewpoint approach VORD Preview Conclusions

Motivation

“For technical, human and environmental reasons, system requirements specifications will always be imperfect.” (Sommeville)

“However, although perfection is impossible, there is no doubt that much can be done to improve the quality of most system specifications” (Sommeville)

Improving specification’s qualityCan be achieved in two ways:

1. Improving requirements engineering process Trying to do not introduce errors on specification

2. Improving the organization and presentation of specification itself

More amenable to validation

Viewpoints aims to address the these points

Requirements model

Requirements activities fall into two classes [Leite and Freeman, 1991]: Elicitation activities* Modeling activities

Viewpoint approach

Based on collecting and analysing requirements from different perspectives

Viewpoint approach

Viewpoint is an encapsulation of partial information about a system’s requirements

Are used to structure the processes of: Requirements elicitation Requirements specification

Viewpoint arguments

Systems usage is heterogeneous Different types of information are needed to specify

systems, including information of: The application domain System’s environment Engineering information about system’s development

May be used as a means of structuring the process of requirements elicitation

May be used to structure the requirements description and expose conflicts between different requirements

Viewpoint approach

Kinds of viewpoints Viewpoints associated with system stakeholders

Stakeholders direct or indirect affected by the system End-user of the system, managers of organization, other

systems, external entities (regulatory bodies), etc/

Viewpoints associated with organizational and domain knowledge Knowledge that constraints system requirements Physical (e.g. network performance), organizational (different

hardwares), human (average operator error rate), laws, etc

Viewpoint approach

Warning!! If too many viewpoints are identified -> It’s difficult to

manage Then, select only the most critical viewpoints to

be used in the analysis (magic number: 5) Trade-off:

Additional viewpoints X Cost of analysis and management

Influential work

Nuseibeh [Nuseibeh, B. et al, 93] Most Influential Paper award in ICSE’03 Threat explicit relationships between viewpoints

Manage multi-perspective software development Presents the xlinkit toolkit

Problem: Viewpoints may cause overlaps and conflicts

The work proposes a framework to explicitly identify the inconsistencies

Viewpoint methods

VORD Preview

VORD

Kotonya and Sommerville work Covers since the initial requirements discovery

through to the detailed system modeling Service-oriented: viewpoints are analogous to

clients in a client-server system Direct viewpoints Indirect viewpoints (organizational requirements

and concerns)

VORD artifact

VORD Process

VORD – Identify viewpoints

Provides a pre-defined set of viewpoint classes “Start point”

(Isn’t complete)

Each organization must establish its own hierarchy

VORD – Identify viewpoints

Stages:1. Prune the class hierarchy to eliminate not relevant

classes

2. Include in the tree classes of stakeholders that aren’t in it but are relevant

3. Identify subsystem viewpoints from system architecture model

4. Potential viewpoints are system operators

5. For indirect viewpoints consider the roles of principal individuals

VORD – Documenting viewpoints Consist of documenting viewpoints’ name,

requirements constraints... in the viewpoint artifact

VORD has a toolset to support this

VORD – Analysis

Two stages:1. Correctness of viewpoint documentation

Consistent and not omitted sections

2. Conflict analysis Conflicts among different viewpoints

VORD toolset help Not automatically Just facilitate viewpoints’ information presentation

VORD – Characteristics

VORD viewpoints is defined by its attributes, services, events and specializations

Provide a framework that distinguish between user classes

Orientation of a service permits distinguish between user needs and what is required at system level

Indirect viewpoints brings to light the importance of people who won’t interact directly

The user of both formal and informal notations helps to reduce the lack of communication

VORD – Problems

Difficult to apply to systems those don’t fit into the service-oriented systems paradigm

Do not provides change control mechanism Permits both formal and informal notations, but

doesn’t provides means to demonstrates equivalence among them

Preview

Sommerville and Sawyer work Aims to enhance the requirements engineering process

Improving requirements discovery, analysis and negotiation rather than system specification

Adds the notion of viewpoint concerns Generalization of goal notion

Its viewpoint encapsulates some information about the system.

System’s requirements are obtained integrating different viewpoints

Preview – State of the art

Aspect oriented requirement engineering (AORE)

2 works: Araújo and Coutinho, 2003 Rashid et al, 2002

Proposes approaches to threat crosscut concerns in viewpoints approaches

Preview – Artifacts

2 types: Viewpoints Concerns

Viewpoints Is defined by its focus 3 Types: interactor viewpoint, indirect stakeholder viewpoint and

domain viewpoint

Concerns Explicitly link the requirements to organizational goals and

priorities Requirements are consistent with organization’s business goals

Preview – Artifacts

Viewpoint information: Name Focus (viewpoint’s scope, how it relates to a part of

the whole system) Concerns (goals, objectives, constraints) Source (sources of information) Requirements History (changes)

Preview – Artifacts

Concerns: Explicitly link the requirements to organizational goals

and high-level strategic objectives Examples:

Safety Availability Maintainability

Number of concerns should be small (max. 6)

Preview – Artifacts Difference between concerns and viewpoints:

Concerns reflect organization priorities Concerns are broken into sub-concerns then derive

questions witch must be considered by all viewpoints Concerns express requirements that are applied for

the system as a whole (not specific services)

Preview – Process

Preview – Process

Identification of viewpoints (guidelines) Identify at least one viewpoint of each type Decide which viewpoints are likely to be relevant to

the problem (observing the hierarchy) If more than 6 viewpoints are taken as relevant, think

about the complexity of manage to much information Define the foci of each identified viewpoint. If this is

difficult or unduly vague, you probably need to define more specific viewpoints

Preview – Process

Requirements analysis Eliminate inconsistencies and incompleteness

Requirements X Concerns Requirements X Viewpoints Internal Viewpoints conflicts Cross viewpoint conflicts

The viewpoint focus shall be used to direct the analysis

(+) overlap

(-) conflict

() independence

Preview - Characteristics

Requirements associated with a viewpoint may be expressed in any notation

Viewpoints has a limited scope and explicitly describe their perspective

Preview may be used for the analysis of processes as well as system requirements

Preview - Problems

At analysis stage comparing viewpoints foci aren’t infallible Don’t identifies implicit organizational and political

factors The absence of clear guidelines for concern

decomposition may cause difficulties Doesn’t support inconsistency management and

trade-off analysis Only few number of concerns can be addressed Small number of viewpoints should be used

Conclusion

Viewpoint addresses the importance of explicitly threat the heterogeneous system usage

Promotes the structuring of requirements elicitation process

Exposes conflicts from different requirements The difficult to threat many viewpoints is similar

in different viewpoint methods The use of an automatic tool analysis can be a good

way to address this issue (future work)

Future work

Development of a case study for a deeper study on approaches

The use of viewpoints to threat aspect oriented requirements engineering (AORE)

How to estimate system size directly from the viewpoints

USING VIEWPOINTS FOR REQUIREMENTS ELICITATION

Aluno:Cleviton Monteiro (cvfm@cin.ufpe.br)

Professor:Jaelson Castro (jbc@cin.ufpe.br)