using viewpoints for requirements elicitation aluno: cleviton monteiro...
Post on 17-Dec-2015
222 Views
Preview:
TRANSCRIPT
USING VIEWPOINTS FOR REQUIREMENTS ELICITATION
Aluno:Cleviton Monteiro (cvfm@cin.ufpe.br)
Professor:Jaelson Castro (jbc@cin.ufpe.br)
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
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
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 – 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
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
top related