1 Introduction In this section, documentation describe purpose of system, scope, and different possible interaction with system. 1.1 Purpose The purpose of this documentation is to give a detailed information about “Chili Flax (Dish advisor)” web site.
In this documentation, we describe various interactions, interfaces and system constraints for this system. The main purpose of this documents is to give illusion to developer and user about system. 1.2 Scope The “Chili Flax (Dish Advisor)” is a website, which helps user to compare food’s serving all restaurants in the city. It compares based on price and customers review on particular food selected by user.
It will help user to find best food nearby his/her location. Main advantage that it brings transparency in price and quality of food is serving in the city. Restaurant owners will provide information about its menu and other information about restaurants like establishment years, experience in this business, connected with another firm and schedule. Restaurant owner can have Owner panel to modify menu whenever they want.
The software need GPS (location) permission for find nearby place feature which allow software to calculate minimum distance with user and provide best search result. 1.3 Definitions, acronyms and abbreviations
Requirement specification and detailed terms and definitions of the different interfaces mansion in third chapter of documentation. Technologies used during implementation of requirement also mentioned. In the Fourth chapter prioritization of requirement is mention and also mentioned what basis developers are choose those requirement is first and all filtration process. The appendixes in the end include all results of requirement prioritized and launch plan of development. 2. Overall description This section will provide associate summary of the entire system.
The system will be explained in its context to indicate however the system interacts with alternative systems and introduce the essential practicality of it. It will additionally describe what kind of stakeholders which will use the system and what practicality is obtainable for every kind. At last, the constraints and assumptions for the system will be given. 2.
1 Product perspective This system mainly contain two parts first one is web browser and second is database. Web browser serve application pages which contains different pages to serve. GPS will be used by mobile application to locate user. Distance between user and restaurant will be displayed by GPS and also da of application will be displayed by GPS.
User can use function of GPS seamlessly manner. This application contains centralized database so it requires to store data somewhere. Mobile application as well as website both can access to database. They will use database in different ways. Mobile application will use database to display those data which is required by user.
Web portal will use database to store and modify those data needed by administration team of system. Internet will be used for this kind of communication. There are limited resources available for mobile application. The maximum amount of hard drive space required by application will be 20 MB.
2.2 Product functions User can search restaurants using mobile application. The result will be displayed using inputs given by user. Administrator of system can change of add criteria.
Search result will be displayed in either list view or in map view according to the requirements of user. The list view will have one list item for each restaurant. Location of each restaurants will be displayed in map view. In both views user, can view information about restaurants.
The web portal will be used for data population and administration purpose. 2.3 User characteristics The number of types of users is three which will interact with system: User of mobile application, administrators and restaurant owners. Each user carries different role, requirements and rights on system. The mobile application users can see data only.
They can input criteria for search restaurants and gets directions to reach there. The restaurant owners will use web portal to populate date. The can manage their menu and information about restaurants. The administrators will use web portal to system.
They will have maximum rights on system. They are responsible for removing uncourts data and harmful contents. 2.4 Constraints Mobile application needs GPS system to be functional properly.
Mobile devices with different GPS will use same interface. The application will also require internet connection. Connectivity to database is established over internet so internet connection will be needed by application. Both the application and web portal will have limited size of database. Database is shared between both application and web portal so it can happen that they can be forced to queue incoming requests. 2.
5 Assumptions and dependencies We can assume that application will be installed on capable devices. If device does not have enough space, then application will not be installed. Another assumption is that all mobile devices in which application is installed, have working GPS with same interface. If the phones have different interfaces to the GPS, the requirements for GPS will needed to be changed.
2.6 Apportioning of requirements If project is about to be delayed, there are some requirements that will be implemented in the next versions of application. Those requirements are to be implemented in the next release, see Appendix IV. 3. Specific requirements The functional and quality requirements are contained by this section. Detailed description of system and interface is given in this section.
A‚A 3.1 External interface Requirements This section describes all inputs and outputs of system. It also describes the software, hardware and the communication interfaces. This section provides basic prototypes of the user interface.
3.1.1 User interfaces Login page will be displayed to first time user, see Figure 2. User can navigate registration page from login page. Search page will be displayed to user if user is not first time user, see Figure 3.
User will select search criteria here and able to get list of required restaurants. User will have profile page to manage personal and contact information, see Figure 4. Also, the user can change its preferred language. 3.1.2 Hardware interfaces Applications are installed on fully built systems so they don’t need any external hardware.
The GPS and database will be handled by underlying processes of operating system of respected devices. 3.1.3 Software interfaces The mobile application will use GPS to get location of user and will use database to fetch data about restaurants which is required by user, see Figure 1.
Mobile application can only read data from database. Web portal will have all rights on data of database. 3.1.4 Communications interfaces The different parts of system are highly dependent on each other so communication among them is very important. Way of communication is doesn’t concerned by whole system.
So, communication will be handled by underlying processes of operation system on respective devices. 3.2 Functional requirements 3.2.1 User Class 1 – The User 3.2.
1.1 Functional requirement 1.1 ID: FR1 TITLE: Download mobile application DESC: Application should be downloaded by user from application store and free of cost RAT: So, user can download application. DEP: None 3.2.1.
2 Functional requirement 1.2 ID: FR2 TITLE: Notification of new releases DESC: When new release of application comes, user will get notification about it. RAT: So, user can download new version of application. DEP: FR1 3.2.1.
3 Functional requirement 1.3 ID: FR3 TITLE: Registration DESC: User should create an account on system. RAT: So, user can create an account. DEP: FR2 3.2.
1.4 Functional requirement 1.4 ID: FR4 TITLE: Login DESC: User should login in system in order to user features of system. RAT: So, user can access its profile. DEP: FR1, FR3 3.
2.1.5 Functional requirement 1.5 ID: FR5 TITLE: Get password DESC: User can get password by email.
RAT: Recovery of password. DEP: FR1 3.2.1.6 Functional requirement 1.6 ID: FR6 TITLE: User ratings DESC: User should rate restaurants.
RAT: Improved feedback. DEP: FR4 3.2.1.7 Functional requirement 1.7 ID: FR7 TITLE: Search restaurants DESC: User should search restaurants by food, price, distance and rating.
RAT: Search for a restaurant. DEP: FR6 3.2.1.
8 Functional requirement 1.8 ID: FR8 TITLE: Admin panel DESC: Administrators should be able to manage database of system. RAT: System management. DEP: None 4.
Prioritization and Release Plan 4.1 Choice of prioritization method Top 10 most important requirements will be selected first. This will be done by simple number method in which higher number means high priority. Number will be assigned base on decision of meting of stockholders. The highest summed number associated with requirement will decide priority of requirement.
The results will be red marked and others will be left as are they before. These requirements were prioritized according to the points they got and the results can be viewed under Appendix II. 4.2 Release Plan The requirements were divided in three groups and each group will be implements in each release of application. Each release will be work as complete working system. The first release will contain essential requirements.
The last release will contains most advanced requirements. Other requirements can be implemented in middle release, Gantt Chart
