Version 0.1 Project Requirements - SqueezyWeb/KYSS GitHub Wiki

Document Properties

Goals

The main goal is to have a working base as soon as possible, which should include:

  • User management (registration, authentication, roles, and permissions)
  • Public homepage (visible to non-authenticated visitors)
  • A single dashboard visible to all authenticated users
  • A widget system used to populate the dashboard
  • An administrative section (for application-wide settings)

Background and strategic fit

KYSS has first been developed a project for the University of Padua, Italy, by Mattia Migliorini and Nicola Dalla Costa. It aimed to be a simple management system for Linux User Groups to handle members, meetings, documents, and other useful stuffs.

Today we want to make KYSS something bigger. It should be modern, modular and scalable. At first we don't want to pack it full of features, instead we want to build a strong API-driven base that can be easily extended to add features that fit a wide range of use cases.

We choose Laravel as the base framework because it represents a strong and modern codebase and allows us to focus on the features that matter the most for our project: modularity and scalability.

Assumptions

  • Users will access the application with every type of device
  • Developers may choose to create other apps to access KYSS features (through APIs)
  • There will be different types of users, each with different permissions over contents and settings
  • KYSS will be extended in a number of different ways

Requirements

  1. Developers should be able to extend KYSS features with third-party packages installed with Composer
  2. KYSS should be able to run with PHP >= 5.5.9
  3. KYSS should be able to handle a huge number of data without big performance losses
  4. Users should be able to authenticate
  5. There should be various user roles
  6. Each user role should have different permissions associated to it
  7. Administrators should be able to choose whether the registration is public or not. Public registration means that people can create a user account themselves, private registration means that only administrators can register new user accounts.
  8. Every visitor should be able to see a public homepage
  9. The public homepage should have links to the login page and (if allowed by the settings - see requirement 7) the registration page
  10. There should be an administration area that allows management of application settings
  11. Only administrators should see the administration area and manage application settings
  12. There should be a dashboard visible to all logged-in users
  13. The dashboard should contain a collection of widgets
  14. Widgets should have a default permission level to be viewed by users
  15. Widgets should be able to define a new permission level to be viewed by users, overriding the default permission level
  16. At this stage, widgets' data should be read-only
  17. Extensions should be able to add custom widgets
  18. The design of the application should be mobile-first

User interaction and design

Include any mockups, diagrams or visual designs relating to these requirements.

Questions

Below is a list of questions to be addressed as a result of this requirements document:

Questions

  1. ...

Outcomes

  1. ...

Not Doing

List the features discussed which are out of scope or might be revisited in a later release.

  • Users should be able to reorder widgets in the dashboard with a drag-and-drop
  • Users should be able to show/hide widgets in the dashboard
  • Support for multiple dashboards