Context

Every student might have encountered the situation where he/she misses a lecture and afterwards has to ask other students for their notes. Bad enough, the student also misses all conversation and discussions during the lecture. They are gone. Forever. But we can do better! 💡

With our product, we want to enable tutors to save recorded lectures to our platform called LaMaS, Learning Management System. On this platform, each student can straightforwardly watch the recordings, discuss topics, ask questions and rate the lecture. In order to make the experience even better, LaMaS will provide access to the uploaded materials. No hassle anymore, just use LaMaS.

Objectives and functional overview

The main idea of our project is to offer tutors the possibility to upload video recordings or other materials of their lectures to a ZHAW internal website and allow their students the chance to easily rewatch single lessons.

During the meetings with our Product Owner we also came up with the following features:

• Every ZHAW member needs to be able to login.
• Every uploaded video must have a category like the class subject, which sorts it into a specific course.
• The students get the possibility to rate the different lectures or subjects.
• The tutor can upload course material.
• Both, the video and the used slide set in the video, gets shown synchronous.
• The tutor can add questions during the video, which can be answered by the students and help them understand the material better.
• The students and tutors get the possibility to add comments or ask questions below a video.
• All users also want to be able to search the website for specific information.
• The marks and points of practical trainings can be added by the tutor, so students always have access to this information.

This product can be called a success if the tutor can upload videos, if the tutor can add categories to the video, if the tutors and also the students can add comments to the videos and if the tutor also can upload course material.

Quality Attributes / non-functional requirements

This section provides information about the desired quality attributes (non-functional requirements) of our service.

Useability

The web application needs an easy-to-use user interface. It must be self-explanatory, so that everyone can use it without the need to read a handbook.

Browser compatibility

The web application must work correctly in the following browsers:

• Firefox, Version 64+
• Chrome, Version 72+ (main release branch)

Other browsers may also render the pages correctly, but are not officially supported.

Security 👮

The course materials can only be accessed after the user logs in. The web application needs to be secure, so that no content can be accessed without authentication.

Scalability

The backend application needs to be scalable, so that it can handle more users and more videos without an extension of the software. At the beginning, It must be able to handle 50 users simultaneously.

Performance ⌛️

Every link that is clicked needs to be loaded within 3 seconds. The videos must be shown without to stop because of latency on the server.

Internationalisation

The web interface will be completely in English. As all students are able to understand english, it’s not necessary to provide multi-language interface. Other languages are omitted in the initial release but may be an option for future development.

Constraints

This section provides information about constraints imposed on the development of our project.

Time ⏰

As the platform needs to be in a viable state (i.e. working core functionality) at the end of May 2019, and each team member can invest a limited time to implement the project, the resulting application will only provide some main features, rather than the full set of features that is intended to be integrated into LaMaS.

Budget and resources 💷

The team consists of six members, each of which has about 120h of work provided to the project. As an educational project, it is decided to use open source and free frameworks and platforms. The application will be delivered with limited resources. The free Firebase Spark Plan is limited to 1GB of stored data and 10GB of transfer per month (as of March 2019).

Target Platform

The product will be developed using Firebase and afterwards deployed on the Google Cloud Platform. As Firebase is a new technology for the team, more time might be invested to achieve the intended goal.

Legal constraint

The applications needs to provide a facility to ensure compliance with the Digital Millennium Copyright Act (DMCA). The intention of the DMCA is to prosecute copyright infringement on the internet.

Skillset of the Development team

Our team members have following skills:

Markus Wüest, Product Owner Full Stack Developer, NodeJs, RiotJs, C, Java, PHP, VBA, SQL, native HTML and CSS, Bootstrap

Vanessa Haas, Scrum Master Full Stack Developer, RiotJS, Assembler, C, Java, PHP, VBS/VBA, SQL, HTML, CSS, Bootstrap, PL/I, JCL, SQL for DB2, IMS

Tram Anh Duong, Developer Full Stack Developer, NodeJS + npm, React and React Native/JavaScript, Firebase (basic knowledge), Django/Python, C, (Java), (Drupal/PHP); Git, tests, code review, UI/UX; precise, flexible

David Kern, Developer Experienced in Java and C#/.Net. Basic Javascript and HTML knowledge

Martin Wädensweiler, Developer Basically no coding skills apart from what picked up in school

Aleksandar Spasojevic, Developer Java Backend Development with a bit Typescript in Angular. ML Knowledge with R and Rstudio

Principles

KISS: Keep it simple, stupid

To reach the goal of a working set of core features at the end of May, things are kept simple. This helps to keep the code easily maintainable and extendable for features that arise during the development process and may be desired in the future.

Boy Scout Rule

It is every team members responsibility, to refactor and “clean” the program code while working on it. This will help to improve the quality of the code during time. Additionally, team members can learn from the changes others made to the code and improve their own skills.

JED: Just enough documentation

The development process shall be documented in a way that enables new developers and stakeholders to understand the application’s intent and its architecture. However the documentation has to be concise and limited to key aspects to avoid redundancy.

RDUF: Rough design upfront

We will create a rough high-level design early that will be refined during the project.

Continuous Integration and Delivery

CI/CD are used to discover and address issues during the development process from early on and avoid integration issues in later development phases.

Git workflow

The Git-Flow model will be used as defined by Vincent Driessen.

Definition of Done and Ready

We consider the "INVEST criteria", which provides us with useful Definition of Ready requirements which can be applied to Product Backlog Items (PBI, User Stories).

• I (Independent). The PBI should be self-contained and it should be possible to bring it into progress without a dependency upon another PBI or an external resource.
• N (Negotiable). A good PBI should leave room for discussion regarding its optimal implementation.
• V (Valuable). The value a PBI delivers to stakeholders should be clear.
• E (Estimable). A PBI must have a size relative to other PBIs.
• S (Small). PBIs should be small enough to estimate with reasonable accuracy and to plan into a time-box such as a Sprint.
• T (Testable). Each PBI should have clear acceptance criteria which allow its satisfaction to be tested.

Definition of Ready for User Stories

Given this list, a User Story to be considered "Ready" needs to fulfil

• User Story in the format of "As a user role, I want action so that goal/benefit"
• User Story has a 2 – 4 word short summary
• User Story is small enough to fit in one sprint
• User Story is understood by all sprint participants
• User Story is estimated
• User Story has clear and concise acceptance criteria which describe all of the features of the story
• User Story needs to be testable
• User Story has no external dependencies that could block the progress of the user story
• User Story identifies external expertise and provides contact details

Definition of Done for User Stories

The very same principles e.g INVEST apply here as well.

A User Story to be considered "Done" needs to fulfil

• User Story is implemented
• Project builds without errors
• Project deployed on the test environment identical to production platform
• Automated functional, non-functional, system and system integration tests passed
• Tests on devices/browsers listed in the project assumptions passed
• Acceptance tests passing
• Pull Request to develop branch created
• Code Review session performed (Quality Assurance, Coding Guidelines and Standards, follow this: https://gist.github.com/cazala/3f6cc82f6b5aa42e210090f7a11f8cb7)
• Issues from Code Review session resolved
• Refactoring completed (Architecture, SonarQube)
• Any configuration or build changes documented
• Documentation updated (if exists)
• Internalization added

Definition of Ready for Sprint

• All User Stories of the following Sprint have status "Ready"
• Sprint Backlog prioritized
• Whole team has its capacity evaluated