Oasis – Open architecture for Accessible Services Integration and Standardization
Download 1.2 Mb.
|
- Navigate this page:
- Methodology
Use Cases DefinitionsWhat is meant by the term ‘use case’? Different definitions are presented below, that help understanding the need of developing the Use Cases, as a requirements-gathering tool, prior to the development of any tool or system.
When specifying Use Cases, an important thing to know is that it is not a methodology. In fact, it is a powerful description to preview and analyze the functionality of a system. It is essential to capture the interaction between the user and the system being developed. Also, Use Cases can be an effective tool, if they are developed in a disciplined (systematic) and coherent manner, as part of a methodology that first creates a well defined domain-model. Thus, Use Cases can be useful when used properly! Another aspect to consider is that Use Cases can be used during many stages of a system development, being associated with different objectives. Used at the analysis stage, can prevent the occurrence of costly error correction at later stages of the development cycle. At this initial phase of OASIS development, Use Cases will satisfy the objective of capturing the system requirements. Use Cases are not object-oriented, they are a broadly applicable requirements analysis tool that can be applied to non-object-oriented projects, which increases their usefulness as a requirements method (Larman C., 2000); they resemble functional decomposition and show aspects of behaviour. According to Ferg (2003), a Use Case, as a description of an actor’s interaction with the system to be designed, is both a description of the system’s user interface and an indirect description of some function that the system will provide. Thus, the use case is a powerful description to preview and analyze the functionality of a system and its human-computer interaction characteristics, to satisfy the user needs. There is a narrow area where the real world interacts directly with the system and this is exactly the use cases area. 
Figure 1: Use cases as an interaction between the real world with the computer system (Ferg, 2003). Use Cases are generated using a goal-oriented methodology: examining all the actor’s goals that the system satisfies yields the functional requirements. Use Cases are goals that are made up of scenarios. Scenarios do not just refer to what the system can do, but also refer to those interactions that the system must be able to identify as invalid (e.g. error conditions and exceptions). Scenarios consist of a sequence of steps to achieve the goal, which define the interaction level between user-system; each step in a scenario is a sub goal of the use case. As such, each sub-goal represents an autonomous action that is at the lowest level desired by our use case decomposition. This hierarchical relationship is needed to properly model the requirements of a system being developed. In addition, it helps avoid the explosion of scenarios that would occur if we were to try to simply list all possible ways of interacting with the system.
This section presents the methodology followed for the extraction of the Use Cases and implementation scenarios of Subproject 3 ‘Autonomous Mobility and Smart Workplaces’ of OASIS. The work started with a technological benchmarking on mobility issues and smart workplaces, which led to the identification of relevant gaps. In it, existing products, services and research projects are included (the current number of entries is 766). Next, face-to-face interviews were realised in five countries (with totally 38 carers and 132 users), in order to find the elderly users specific needs. The initially defined UCs by the Consortium (38 in total) were then linked to the specific end user profiles and interviews results, to assess the level they satisfy the users expectations. The partners that lead the development of a specific module/system (as part of the OASIS SP3 services) specified the appropriate UCs relevant to their module/system, after reviewing the benchmarking (database) and the interviews results. The main issue before extracting the Use Cases for OASIS was the development of an adequate format to describe them. Thus, an analytic template has been developed, in order to identify and describe as thoroughly as possible the Use Cases, and the way they should be formally described. The UCs are partially based upon the aims of the 4 Workpackages of SP3, where innovative developments are to be carried out regarding:
Thus, the UC falling in each one of the above categories, are related to one of their modules. However, various of these modules are included also in UCs of different categories. The OASIS UCs template is constructed according to the project objectives. The template, together with the elements that are normally included on this kind of UC description (actors, goals, scenarios, etc.), is presented in Annex 3 of this report. Each UC is fully complemented by a relevant UML scheme, to support the development team in realising it. Directory: docs docs -> Application for acem docs -> Observational Assessment of Teaching Practices Teaching Assessment Initiative Proposal Submitted to The Teachers for a New Era project docs -> Traditional British values docs -> From Warfighters to Crimefighters: The Origins of Domestic Police Militarization docs -> Borzoi Club of America Register of Merit Program I. What is a Register Of Merit docs -> Protecting the rights of the child in the context of migration docs -> United Nations E/C. 12/Esp/5 docs -> 9th May 1950 the schuman declaration docs -> Getting To Outcomes® in Services for Homeless Veterans 10 Steps for Achieving Accountability Download 1.2 Mb. Share with your friends:
|