2. Fall 2017 Software Specification
1. Introduction
2. Description
3. Requirements
3.1 UI Requirements
3.2 Functional Requirements
3.3 Non-Functional Requirements
4. Prioritization
5. Diagrams
StudyGroup is a desktop application that allows students to study together no matter where they are. This wiki serves as a collection of requirements for the development of this software. These requirements are to aid in the development of the app by providing a proper outline of priorities to be followed during various stages of development.
StudyGroup is a program by students, for students. Many benefit from cooperative learning. This application looks to fill the gap faced by students that do not have the ability to easily meetup with others for study sessions. StudyGroup provides various functionality for efficient studying over the internet. With students being the primary consumer, the application needs to be freely available for everyone.
Every user first makes an account and connects their StudyGroup client to the server, which is able to host multiple groups at once. These groups are able to study together and use the built-in study tools, such as whiteboard mode and flashcard mode. The server and database must be able to facilitate account creation/login and transmit chat to users within the appropriate group. The client must be able to establish a reliable connection with the server and communicate relevant information when needed.
This wiki first covers an in-depth description of the aspects of the project's scope. Sections are broken down to better illustrate the purpose and concept behind the application. In the next section specific design, functional, and performance requirements are presented. These requirements are given with dependencies in mind. This section serves as a reference for the developers to follow during development. Finally, a breakdown of feature priorities are given. This provides the expected flow of the development and testing phases.
There are three main components to this product: the client, the server, and the database.
2.1.1 The Client
The client is the user interactive experience. This is the application that users download and is the direct line of interaction for the user with the rest of the components, including other clients. The client has the role of initiating communication with the server. Since the client's responsibility stems from user interaction, a GUI is an essential component of the client and everything else must be built around it. Furthermore, as the direct line to the user, performance is key. For these reasons Qt C++, a powerful GUI development framework, is chosen to expedite these development needs.
2.1.2 The Server
This component is the intermediary between clients and the database. This software is responsible for processing all requests from all clients, interacting with the database if necessary, and then relaying the relevant communications to the proper clients. The server is always running, listening on a chosen port for incoming TCP data from clients. A popular language for server-side programming, PHP is chosen to fill this role.
The server must be able to keep track of all users currently logged in, all groups created and users currently in each group, and handle implement all the logic required for interaction between clients. The database is instrumental in allowing this to happen.
2.1.3 The Database
The database stores information for accounts, retaining group information, and chats. Chats must be stored so logging in from a different client does not affect the ability of the client to display chat history. This component is interacted with by the server, and instructions are passed through PHP MySQLi functions to it. The database will also store real-time information such as current users in each group, and online users.
Example account storage table:
| Username | Pass | Status | |
|---|---|---|---|
| Testuser1 | testpass | example@email.com | Online |
| Usertest2 | pass123 | another@example.com | Offline |
Example group table:
| Admin | userList | ipAddress | User | Clock | Message | Whiteboard |
|---|---|---|---|---|---|---|
| iMadeDis | NULL | NULL | NULL | NULL | NULL | NULL |
| NULL | iMadeDis | 11.22.33.111 | NULL | NULL | NULL | NULL |
| NULL | SecondUser | 11.11.22.333 | NULL | NULL | NULL | placeholder |
| NULL | NULL | NULL | iMadeDis | 11-02-2017 01:30:22 | Welcome everyone! | % PNG (a(( |
| NULL | NULL | NULL | SecondUser | 11-02-2017 01:40:21 | Thanks for inviting. | NULL |
| NULL | NULL | NULL | iMadeDis | 11-02-2017 01:42:01 | Is anyone else coming? | NULL |
Example flashcard table:
| id | user | side1 | side2 |
|---|---|---|---|
| 1 | iLoveCalc | Easiest thing ever? | Derivatives! |
| 2 | iHateCalc | Toughest thing ever? | Integrals :( |
| 3 | whatIsCalc | Derivative of 3x? | 3 |
This application has only one type of user. All users interact only with the client desktop application. The client must provide all the functionality for the user. Some examples of required functionality would be creating accounts, creating new groups, joining groups, and changing account information. These users must be able to also communicate with each other, and therefore client applications must be capable of transferring data through a server to each other.
Login page, profile page, chat page, study page, etc etc
ID: UIR1
Main window:
- Description: Given that a user has downloaded and started the program, a window must be displayed to the user.
- Rationale: In order for the user to see a UI.
- Dependency: None.
ID: UIR2
Login/Create/recover account page:
- Description: Given that a main window has opened, the first page displayed by the window should be a page that allows a user to either log in, to create a new account, or to recover a username/password.
- Rationale: In order for the user to see how to log in or create an account.
- Dependency: UIR1
ID: UIR3
Main page:
- Description: Given that a user has logged in, the login/create account page should change into a main page where all other functionality of the program can be held.
- Rationale: In order for the UI to have space for the main functionality.
- Dependency: UIR2
ID: UIR4
Group buttons and inputs:
- Description: Given that the UI is on the main page, there must be buttons that allow a user to join or create a group that depend on text inputs also available.
- Rationale: In order for the UI to support joining and creating groups.
- Dependency: UIR3
ID: UIR5
Group widget:
- Description: Given that a user has joined or created a group, a group widget must open within the main page that facilitates all the group functionality required.
- Rationale: In order for groups to be supported in the UI.
- Dependency: UIR4
ID: UIR6
Group chat:
- Description: Given that the group widget is displayed, there must be a chat area with a chat box and text input area.
- Rationale: In order for chats to be supported in the UI.
- Dependency: UIR5
ID: UIR7
Users online list:
- Description: Given that the group widget is displayed, there must be an area where all online users are displayed. > - Rationale: In order for online users to be seen in the UI.
- Dependency: UIR5
ID: UIR8
Whiteboard:
- Description: Given that the group widget is displayed, there must be an area where all users may draw.
- Rationale: In order for whiteboards to be supported in the UI.
- Dependency: UIR5
ID: UIR9
Flash cards:
- Description: Given that the group widget is displayed, there must be an area where users may use flashcards.
- Rationale: In order for flash cards to be supported in the UI.
- Dependency: UIR5
ID: FR1
Download desktop software
- Description: A user should be able to download the software through either a direct download link or through the group website.
- Rationale: In order for a user to download the software
- Dependency: None
ID: FR2
User registration
- Description: Given that a user has downloaded the software, then the user should be able to register through the client. The user must provide username, password, and email address.
- Rationale: In order for a user to register through the client.
- Dependency: FR1
ID: FR3
User log-in
- Description: Given that a user has registered, then the user should be able to log in to the client. The log in information will be stored in a database and in the future the user will be required to submit their information.
- Rationale: In order for a user to log in through the client.
- Dependency: FR2
ID: FR4
Retrieve password
- Description: Given that a user has logged in, then the user should be able to retrieve their password or username through the recovery screen.
- Rationale: In order for a user to retrieve his/her password.
- Dependency: FR3
ID: FR5
Group creation
- Description: Given that a user is logged in, then the user should be able to create a new group. After submitting the group name, the user should automatically join the group.
- Rationale: In order for a user to create a new group.
- Dependency: FR3
ID: FR6
Group join
- Description: Given that a user is logged in, then the user should be able to access any group by using a password. The groups will by default have a chat room.
- Rationale: In order for a user to join a group.
- Dependency: FR5
ID: FR7
Chat room
- Description: Given that a user is in a group, there should be a scrolling chat room available. A user may type in the chat bar, and upon pressing enter whatever they typed will be stored in a database and become visible to every user in the group.
- Rationale: Functionality of a group chat room.
- Dependency FR5
ID: FR8
Whiteboard
- Description: There should be an optional additional screen of the group room taken up by a whiteboard. Users of the group can write and draw on the whiteboard at will, where their input will be shown to all members of the group.
- Rationale: Functionality of whiteboards.
- Dependency: FR5
ID: FR9
Flashcards
- Description: There should be an optional additional screen of the group room taken up by flashcards. Users of the group should be able to write on either side of multiple cards, and make them available to the rest of the group.
- Rationale: Functionality of flashcards.
- Dependency: FR5
3.3.1 Responsive UI:
- Description: The wait time between interacting with the User Interface and receiving a response needs to be no more than 5 seconds for any action.
- Rationale: In order for a fluid and enjoyable user experience.
3.3.2 Network connectivity:
- Description: All networking functions needs to take no longer than 5 seconds and time out if 5 seconds is reached.
- Rationale: In order to prevent infinite blocking of networking.
3.3.3 Operating System compatibility:
- Description: The application needs to be able to deploy to both Windows and MacOS.
- Rationale: In order for the application to be available to users of both operating systems.
3.3.4 Screen Size:
- Description: The application needs to be fully usable at a minimum of 1024x768 screen size.
- Rationale: In order to support usability by users with low resolutions.
3.3.5 Whiteboard Draw:
- Description: The whiteboard should draw on the screen no less than once every 50ms while the user is drawing.
- Rationale: In order for the user drawing experience to be responsive and fluid.
| Week | Back-end Goal | Front-end Goal |
|---|---|---|
| 1-2 | Set up server and database Plan and document back-end functional requirements |
Download and setup Qt Plan and document basic UI requirements |
| 3 | Establish client-server connection and basic TCP protocols | Establish client-server connection and basic TCP protocols |
| 4-5 | Login functionality Login testing |
Design UI layout Implement login functionality Login requirements testing |
| 6-7 | Plan Group TCP protocols Group creation and joining Group functionality testing |
Design Group UI Implement Group creation and joining TCP protocols Group functionality testing |
| 8 | Establish chat and whiteboard TCP protocols | Establish chat, whiteboard, flash-cards TCP protocols |
| 9-10 | Implement chat, whiteboard, flash-cards multi-user functionality | Develop chat-box, whiteboard, and flash-cards UI Implement chat, whiteboard, and flash-cards TCP protocols |
| 11 | Server/Database test-cases Testing and debugging |
UI test-cases Testing and debugging Design revisions |
| 12-13 | Testing and debugging | Testing and debugging |
