1 / 13

HOPE Remote Management and Requirements

HOPE Remote Management and Requirements. Team PowerDroid. Imran Merchant Paul Asere Doug Beach Tommy Omen. Agenda. Our work so far Class Diagram Functional Requirements Nonfunctional Requirements SIG Diagrams What’s left Further Requirements Analysis Design Architecture

arwen
Download Presentation

HOPE Remote Management and Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. HOPE Remote Management and Requirements Team PowerDroid Imran Merchant Paul Asere Doug Beach Tommy Omen http://utdallas.edu/~imerchant/hope_remote

  2. Agenda • Our work so far • Class Diagram • Functional Requirements • Nonfunctional Requirements • SIG Diagrams • What’s left • Further Requirements Analysis • Design Architecture • Implementation • Reiterate • Questions

  3. Class Diagram

  4. Functional Requirements PFR1: HOPE shall provide the user with a remote access registration option after running the application. Issue 1: What if the user does not want to register? Proposal A: Offer the user the option to skip the registration process. The user can register their account a later date or not at all. Proposal B: Allow user to cancel but prompt the user to register every time they open the HOPE application. Proposal C: Automatically register the device without asking the user.

  5. Tradeoff Analysis ++ = 100% + = 75% +- = 50% - = 25% -- = 0% Decision: Based off the tradeoff analysis, the best decision is Proposal A. Proposal A allows the maximum amount of configurability and usability. It gives the user the option to register now or later. Proposal B negatively impacts usability by constantly asking the user to register. Proposal C negatively impacts configurability by assuming the user wants to enable the remote access feature.

  6. Nonfunctional Requirements NFR1: The Remote Management System shall be Secure Issue: How do we ensure security? Phone Side Proposal A: A single Pair Activation code shall be used to ensure security. The activation code shall be a onetime use only at first setup of the Hope application. The user shall also have the option to turn this off in the configuration settings. Proposal B: On first run of the Hope application, a username password prompt would be provided. The user would have to register the Hope application using this feature. Proposal C: Fingerprint recognition would be embedded into the Hope application to ensure security. This would be used every time the user has starts the Hope application.

  7. Tradeoff Analysis ++ = 100% + = 75% +- = 50% - = 25% -- = 0% Decision: After carrying out tradeoff analysis, we determined Proposal A satisfices security and usability while being feasible at the same time. Proposal B is feasible and easy to maintain; however, it presents the user with password fatigue and negatively affects usability.

  8. Web Interface Proposal A: Provide the user with a username password prompt to login to the web interface. Proposal B: Use certificate based authentication for each assistive user computer.

  9. Tradeoff Analysis Decision: Although Proposal A has a downside due to usability it still remains the most feasible of the two, as certificate based authentication would be difficult to implement due to time constraint.

  10. SIG Phone

  11. SIG Web Interface

  12. What’s Left • Further Requirements Analysis • Design Architecture • Implementation • Testing • Reiterate

  13. Questions?

More Related