Software requirements specification - ghrimx/StudX GitHub Wiki

Index:

Introduction

Product requirements (PRD) and the technical requirements (TRD) are combined in this "software requirements specification" document. The "technical design" will be covered in a distinct document (Technical design document - TDD).

Purpose

The purpose of this SRS document is to provide a detailed overview of our software product StudX, its features, capabilities and goals. This document describes the project's target audience and its user interface, hardware and software requirements. It defines the expectations of our stakeholders (client, team and audience,...) and how they see the product and its functionality. I, the author, hope the documents provided and the overall project help any designer and developer to assist in software delivery lifecycle (SDLC) processes.

Disclaimer: This document and the overall project is the fruit of the sole desire of the author to illustrate and to reflect on the process of Software development and is in no circumstances intended for commercial use. References to stakeholders, clients, team or audience and their needs is purely fictive

Scope

The purpose of the online school management system (StudX) is to ease management and to create a convenient and easy-to-use application for staff and non-staff people. Above all, we hope to provide a comfortable user experience along with the necessary features to manage a school on a daily basis. Finally, we make the wish to improve in general the educational system to make School a better place to be!

Definition, Acronyms, and Abbreviations

System overview

The system is based on a relational database with its records management and operation functions. The relational database has been design to be as flexible and scalable as possible. While every school has its own needs and requirements on the type of data to record, on the management of data and on how the end-user can access it, we hope the DB design and the functions used to retrieve these data cover the most common scenario.

References

Overall description

This document contains the solution proposed to School manager to favor collaboration among staff and external people as well as to improve work efficiency and data integrity. It contains a list of stakeholders and users of the proposed solution. It also gathers the needs and wants of the stakeholders that were identified by "self reflection". It further lists and briefly describes the major features and the overall architecture of the proposed system.

The detailed design and product functions of StudX with user characteristics permitted constraints, assumptions, dependencies and requirements subsets will be detailed in a separate document.

Product perspective

System Interfaces

StudX should support four types of interfaces namely user, hardware, software and communication. A brief description of each is provided in the following sections.

User interfaces

The user interface is a web page that allows the user to interact with the database. The web pages are rendered in a web browser and they should be compatible to any browser such Internet Explorer, Mozilla Firefox, Chrome, Safari,... The user interface should also be responsive to adapt various screen size.

Hardware interfaces

As the application will run over the internet, the hardware interface has to satisfy all the requirements to connect to the web and to distribute web pages. Some examples are modem, server, wan-lan, wifi, ethernet cable,...

Software interfaces

The software global interface will be organised in multiple modules, namely python apps*. Each module will be in charge of its own business logic (e.g. student related data management, user management, communication, finance, schedule,...)

  • The user interface content depends on the user's role and its permissions. To allow flexibility, the default authentication system will be abstracted. The default authentication system will therefore communicate with the user custom module
  • The student module shall communicate with the user module to get data permissions
  • The student module shall communicate with the communication module to report "events"
  • The student module shall communicate with the schedule module to manage attendance
  • The finance module shall communicate with the student module to get student information

*Python apps are used in this project to organize and segregate the code rather to make reusable standalone apps

Communication Interfaces

StudX system should use HTTP protocol to communicate over the internet. No intranet will be put in place. Internal communication will have to transit through the database.

Memory Constraints

The system and its database should have access to at least 2 To of physical memory. This size memory foreseen further growth of the database.

Design constraints

StudX system should be GDPR compliant. The following features are required:

  • user data privacy
  • student data privacy
  • authentication and role activated functionality
  • role base data authorization restriction
  • discipline management
  • student attendance management (arrival, departure, absences)
  • student and teacher schedule integration (a full feature planning system is out of scope)
  • internal/external communication
  • basic accountability system (fee issue/tracking)

Operations

Site Adaptation Requirements

Product functions

User characteristics

Constraints, assumptions and dependencies

Specific requirements

External interface requirements Functional requirements Performance requirements Logical database requirement Software System Attributes Reliability Availability Security Maintainability Portability. Functional requirements functional partitioning functional description control description Environment characteristics Hardware peripherals people others..