USING VIEWPOINTS FOR REQUIREMENTS ELICITATION

1. USING VIEWPOINTS FOR REQUIREMENTS ELICITATION Aluno: Cleviton Monteiro (cvfm@cin.ufpe.br) Professor: Jaelson Castro (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: • Improving requirements engineering process • Trying to do not introduce errors on specification • 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 informationaboutsystem’sdevelopment • 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 explicitlyidentify 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: • Prune the class hierarchy to eliminate not relevant classes • Include in the tree classes of stakeholders that aren’t in it but are relevant • Identify subsystem viewpoints from system architecture model • Potential viewpoints are system operators • For indirect viewpoints consider the roles of principal individuals

18. VORD – Documentingviewpoints • Consist of documenting viewpoints’ name, requirements constraints... in the viewpoint artifact • VORD has a toolset to support this

19. VORD – Analysis • Two stages: • Correctness of viewpoint documentation • Consistent and not omitted sections • 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. 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

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) Professor: Jaelson Castro (jbc@cin.ufpe.br)