sagi/se-hub
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity
Page: SDS
Pages
Class diagram & CRC Cards Deployment Diagram Development Home Inception Iterations Persistence SDS SRS Team Use Cases User Manual ZFR Iteration 0
65 SDS
devMatan edited this page 2015-05-09 11:15:31 +03:00
  1. Introduction

1.1 Document Goals

  • a. Understanding features that needs to be implemented and the risk level involved.
  • b. Specifying Classes/Objects/Database structure and information.
  • c. Describing relations between different Objects.
  • d. Splitting assignments between team members according to knowledge, abilities and will.

1.2 Capabilities

Capability Risk Level if not implemented Capability description
Login via Github Critical All of the information is pulled from the user's Github Account. The user has to log in with proper credentials.
Lecturer Progress View Critical Lecturer Dashboard contains information about all students projects. The info will be pulled from students projects (unlike student Dashboard which contains private info).
Task Submmision Critical Students must have the ability to submit Tasks from our Dashboard in a simple way, that will also inform Lecturer when a Task has been submited
Communication Critical Both student and lecturer need a system in which they can send private or group messages.
Information Parsing High Information pulled from Github should be parsed correctly and presented in a simple way.
Notifications/Alerts Medium We wish to have an option to notify the students about upcoming submition dates and/or messages from student/lecturer.
Simple UI Medium-Low The UI should be as simple as can be, yet contain all features. It's very important to make the Dashboard a "clean" working enviorment with no distractions
  1. Deployment Diagram

Deployment Diagram Page

  1. Class diagram & CRC cards

Class diagram & CRC cards - Wiki Page

  1. Sequence Diagram

Send Class message Sequence Diagram

  1. The lecturer must login with valid account.

  2. Once in lecturer dashboard, press messaging system button.

  3. Choose message type - private/group/class. (in this case Class)

  4. Input message.

  5. Check optional fields (Notify all/on-response).

  6. Send or cancel message.

  7. Returns to messaging system window.

  8. Persistence

Persistence Page

  1. Non-Functional Demands
  • a. Simple to use- UI would be simple and "clean" so that usage will be as easy as possible.
  • b. Secure- Login via Github will suffice a secure connection to an already existing profile.
  • c. Generic Structure- Dashboard is designed in a way that it can be used for different Courses/Colleges
  • d. Compatibility- Works on any web browser from every computer.
  • e. light- The Dashboard is just a "Tunnel" from Github, thus not holding alot of Data itself.

7.Risk Management

Risk Level of effect Probability Avoidance
Unstable web service Low risk Possible Testing all possible edge cases
Miss-information for handling the web app High risk Low A friendly and simple interface
Site crush Medium-Low risk Possible Check if Git-Hub is down for maintenance or any other activity
Lack of cooperation from the users High risk Medium It is a new application thus it is necessary making the dashboard alluring and welcoming
Complicated database design High risk Medium - Low Discussing about the database design in order to make it departmentalized and efficient

©️ SE-Hub 2015 Team niptop