Question: QUESTION: ---------------------------------------------------------------------------------PROJECT------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Software Requirements Specification for Page 9 1. Identify the domain classes for your project from a) UML models (use case and sequence
QUESTION:

---------------------------------------------------------------------------------PROJECT------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------









Software Requirements Specification for Page 9 1. Identify the domain classes for your project from a) UML models (use case and sequence diagrams) b) other sources (using any brainstorming approach) 2. Filter the candidatc domain classes collected from both sources a) and b) using any 1 Approach (studid in class). 3. For the selected domain classes write the contents of the requirements. Hint: Sample for Requirement Contents is mentioned in the below table. Contents of the Requirements for a Sample Class Section Heading(e.g., "Customers") Subsection 1. Attributes (required properties) e.g., "The application shall maintain the names of all customers." Subsection 2. Instances (specific ones that must exist -if applicable) e.g., "The application shall accommodate John D. Rockefeller ..." Subsection 3. Functionality (the heart of the requirements spec.) e.g., "The application shall be able to print customer profiles ..." Subsection 4. Events (events that instances are sensitive to -if any) e.g., "Whenever a customer's address is changed, ..." Software Requirements Specification for Page i Table of Contents Purpose...... Table of Contents.... 1. Introduction....... 1.1 1.2 Product Scope. 1.3 References, 2. Overall Description..... 2.1 Product Functions... 2.2 User Classes and Characteristics. 2.3 Operating Environmen............. 2.4 Design and implementation Constraints. 2.5 Assumptions and Dependencies. 3. System Features............. 3.1 System Feature 3.2 Systein Feature 2 (and so on). 4. Other Nonfunctional Requirements.. 4,1 Performance Requirements 4.2 Safety Requirements. 4.3 Security Requirements. 4.4 Software Quality Attributes. 4,5 Business Rules..... Appendix A: Glossary..... Software Requirements Specification for Page 1 1. Introduction 1.1 Purpose We propose to build a unique and easy way to hire a mechanic through an online service. Online Mechanic Service System can be used a temporarily for a fee during a specific period. Hired mechanic will help people to maintain their motors. User can hire mechanic for motor's service and replacement of motor's body parts. After that, bill will be calculated according to their service. Bill will later deducted from user's account. 1,2 Product Scope This project covers a wide range of topics, from business concepts to computing, and it necessitated the completion of various studies in order to meet the project's objectives. Online Mechanic Service: It will include study on how the online mechanic business is being done and which processes involved. Java technology will use for the development of application. User as well as company's staff will be able to use the system effectively. System will be available for access 24/7 except when there is an issue in server or maintenance issue. 1.3 References Software Requirements Specification.pdf 2. Overall Description 2.1 Product Functions Online Mechanic Service provides the fcatures for hiring a mechanic online. It will include several fictionalities which are: Software Requirements Specification for Page 2 Mechanic Service Management: It provides Mechanic hiring facility online. User can visit the application and check for various mechanics. If they are feasible with requirement, then hiring can be done. Checking For Availability: Employee can check the availability of mechanic. He/she maintains the database of the mechanic. If none of any mechanic is available then it is the responsibility of the employee to provide alternative options. Payment System: Administrator of the applications responsible for payment to the employees. Mechanic hiring, cancellation, finalization is done by the Administrator of the application. Maintenance Manager: r maintain the data about If any motor requires replacement of any parts, then maintenance that. 2.2 User Classes and Characteristics Admin: . Admin can login to the system Verify the mechanic information database Generate price key Handle the Payment System Finalizing the mechanic Cancel the mechanic . . Employee: . It will update database. Will give information to the user about the mechanic. Provides the alternatives Maintain contacts. Maintenance Manager: Software Requirements Specification for Page 3 It checks for the maintenance. Give information to the admin Update database. User: User can login to the system Visit the app Hire Mechanic Cancel Hired Mechanic 2.3 Operating Environment Server Side: Processor: Intel Xeon processor 3500 series HDD: Minimum 500GB Disk Space RAM: Minimum 16GB OS: Windows 8, 10, Linux Database: SQT. Server 2014(SQL14) Application: XAMP, phpmyadmin Client Side (minimum Requirement): Processor: Intel Dual Core HDD: Minimum 80GB Disk Space RAM: Minimum 1GB OS: Windows 7, 8, 10, Linux 2.4 Design and Implementation Constraints Application will use Java, JavaScript, JQuery and css as main web technologies. Software Requirements Specification for Page 4 . . HTTP and FTP protocols are used as communication protocols. FTP is used to upload the web application in live domain and the client can access it via HTTP protocol. Several types of validations make the application a secured one and SQL injections can also be prevented. Since Online Mechanic Service System is a web-based application, internet connection must be available. 2.5 Assumptions and Dependencies Regularity Policies: Each center user has an account created and admin authenticated it. This application can be accessible within company's internet and other user can see the all details about the franchise. Each user has to first login itself to present him/her after entry in franchise. This will be done automatically. No user can share their username and password to each other. Hardware Limitations: There is no limitation in the operating system in which Online Mechanic Service System will work. However, the Online Mechanic Service System and the database will work done on a server that needs to be always online. Users can access the system with any internet browser. 3. System Features Some features that are used in the given scenario are given below: 3.1 System Feature 1 Description and Priority Reserve Mechanic and high priority. Functional Requirements Software Requirements Specification for Page 5 These are statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations. It specifies the application functionality that the developers must build into the product to enable users to accomplish their tasks. Reserve Mechanic: . . The system must allow the customer to register for reservation of mechanic. The systein shall allow the customer to view the detail description of particular mechanic. The system must notify on the selection of unavailable mechanics while reservation. The system must view the list of available mechanic during reservation. The system shall allow the customer to cancel hired mechanic using hired confirmation number. The system shall allow the employee to update reservation information. The system shall allow the employee to view the reservation made by customers. The system must be able to provide a unique selected mechanic confirmation number for all successfully committed reservation. The system must be able to display reservation summary for successfully committed reservation . . . 3.2 System Feature 2 Description and Priority Log in and high priority. Functional Requirements Log in: Software Requirements Specification for Page 6 . + The system should allow manager to login to the system using their username and password. The system should allow employee to login to the system using their username and password. The system shall allow the manager to create new user account. The system shall allow manager to change account password. The system shall allow staff to change account password. The system shall allow staff to logout. The system shall allow manager to logout. . . + 3.3 System Feature 3 Description and Priority Mechanic and high priority. Functional Requirements Mechanic: 1 . . The system should allow staff to register new mechanics. The system shall allow staff to select mechanics in the list. The system shall allow customer to select mechanics in the list. The system shall allow staff to search mechanics by specific record. The system shall allow customer to Search mechanics by specific record. The system shall allow staff to display all lists of mechanics. The system shall allow staff to display all available mechanics. The system shall allow staff to display all hired mechanics. The system shall allow staff to display all off duty mechanics. . Software Requirements Specification for Page 7 3.4 System Feature 4 Description and Priority Billing and high priority. Functional Requirements Bill: . + The system shall allow staff to register customers into bill list. The system shall allow staff to update about customer bill record details in the bill list. The system shall be able to save all changes made on the customer bill list. The system shall allow staff to select customer bill record by specific search category. The system shall allow staff to display all customers' bill record. The system must provide printable summary for successful committed bill. . . + 4. Other Nonfunctional Requirements 4.1 Performance Requirements The system response time for every instruction conducted by the user must not exceed more than a minimum of 10 seconds. The system should have high performance rate when executing user's input and should be able to provide response within a short time span usually 50 second for highly complicated task and 20 to 25 seconds for less complicated task. 4.2 Safety Requirements Verification process is linked with dummy data. It will be kept in private and safe which will be used for the personal data of the bill. 4.3 Security Requirements User Account will be verified through CNIC, for which all the user will have only one account to open in order to provide secure application. The system provides username and password to prevent the system from unauthorized access. The staffs' password must be greater than eight characters. Software Requirements Specification for Page 8 The subsystem should provide a high level of security and integrity of the data held by the system, only authorized personnel of the company can gain access to the company's secured page on the system; and only users with valid password and username can login to view user's page. 4.4 Software Quality Attributes Reliability: Good validations of user inputs will be done to avoid bug in records. Maintainability: During the maintenance stage, SRS document can be referred for any validations. Security: Security of the system is maintained by giving access to only authenticated user id and password as we mentioned above. Portability: This system can be easily viewed in any browser. bility: The system keeps on updating the data according to the transactions that takes place. Timeless: The system carries out all the operations with consumption of very less time. 4.5 Business Rules All the rules for the design and development of the application will be under the jurisdiction