Download presentation
Presentation is loading. Please wait.
Published byAlan Thomas Modified over 9 years ago
1
USING VIEWPOINTS FOR REQUIREMENTS ELICITATION Aluno: Cleviton Monteiro (cvfm@cin.ufpe.br)cvfm@cin.ufpe.br Professor: Jaelson Castro (jbc@cin.ufpe.br)jbc@cin.ufpe.br
2
Agenda Motivation Viewpoint approach VORD Preview Conclusions
3
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)
4
Improving specification’s quality Can 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
5
Requirements model Requirements activities fall into two classes [Leite and Freeman, 1991]: Elicitation activities* Modeling activities
6
Viewpoint approach Based on collecting and analysing requirements from different perspectives
7
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
8
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
9
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
10
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
11
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
12
Viewpoint methods VORD Preview
13
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)
14
VORD artifact
15
VORD Process
16
VORD – Identify viewpoints Provides a pre-defined set of viewpoint classes “Start point” (Isn’t complete) Each organization must establish its own hierarchy
17
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
18
VORD – Documenting viewpoints Consist of documenting viewpoints’ name, requirements constraints... in the viewpoint artifact VORD has a toolset to support this
19
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
20
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
21
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
22
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
23
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
24
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
25
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)
26
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)
27
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)
28
Preview – Process
29
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
30
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
31
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
32
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
33
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)
34
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
35
USING VIEWPOINTS FOR REQUIREMENTS ELICITATION Aluno: Cleviton Monteiro (cvfm@cin.ufpe.br)cvfm@cin.ufpe.br Professor: Jaelson Castro (jbc@cin.ufpe.br)jbc@cin.ufpe.br
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.