In: Computer Science
in software engineering what are the domain requirements for a museum ?
. In use case model 1, following steps are followed; User runs the application, User accesses main page, User selects “language change” button, User browses language change page, User selects another language from the list, Finally, system sets application language as selected. Second use case includes museum searching steps: User runs the application, User goes main page, User selects “search museum” button, User browses search museum page, User selects search by map button, User explores via Google map and sets location, User selects a museum in this map, If user selects direction icon, system draws direction line (user current location with museum), If the user clicks car icon, system calculates taxi price, If the user clicks bus icon, system gives options bus name for current location, If the user clicks walk icon, system calculates the distance (user current location with museum). Main concept of the designed system listed in the second use case model and illustrated in Fig.4. Fig. 4. Use Case Modeling diagram for searching museums Functional requirements can be best obtained by using use case models (Jacobsen et al., 1992; Jacobsen et al., 1998). Business analysts and system analysts prefer to prepare the use www.intechopen.com 192 Advances and Applications in Mobile Computing case models which include more practical business rules and descriptive statements of natural language. As mentioned before, use case modeling helps analysts to develop functional requirements and task models such as HTA or sub goal templates (SGT) are feeding user interface design stage. In the specification of use cases, the described activities are performed by entity when interacting with an actor (here end user or visitor). Use cases, introduced by Jacobsen et al. (1992), versus task descriptions to identify sequences of actions, considering variants to generate a response from system to an actor (Booch, 1999). The definition emphasized that actions performed by system not user. The UML diagram reflects this, showing use cases as bubbles inside the system. Task descriptions don’t cover Quality requirements such as response time and usability, but they point out where quality is crucial (Lauesen, 2003). As Lauesen (2003) declared that, a UML use case diagram, which deals only with the computer system’s actions and separate human and computer actions; but the task descriptions, which do not separate human and computer actions. This feature supports the requirements engineering activities based on the object oriented analysis and design side. Use Cases Description Use Case 1 User changes language Use Case 2 Find your current location and Museum location, explore the map. User get real time direction to museum User get distance to museum User get transportation option (taxi, bus, on foot) Use Case 3 User search museums with some criteria (this criteria: by map, by city, museum type, culture, term, era, year) Use Case 4 User adds favorite museums to favorite page. Use Case 5 User display museum search result with some criteria (display all, A to-Z, area, distance, popularity) Use Case 6 User display overview about selected museum and rate it. Use Case 7 User display selected museum’s exhibitions. Use Case 8 User display selected museum’s floor plan. Use Case 9 User downloads selected museum’s application. Use Case 10 User display selected museum’s multimedia tours. Use Case 11 User display museum calendar (what’s happening today, tomorrow and this weekend) Use Case 12 User gets detailed information about selected museum (address, phone, web site address etc.) Use Case 13 User searches alternative restaurant, café, shops near the selected museum. Use Case 14 User share museum opinion with social network (Facebook, Twitter