SDS - Software Design Specification

Introduction Document Goals

This document will show in detail the software architecture and design for the Project 'Bishvil' - community system. This document will provide several views of the system's design in order to understand the architecture. Diagrams attached to this document for providing explanation of our plugin design.

Main Product Features & Capabilities

	Capability	Capability Description	Risk Level
1	Add new requests	All types of users (contributor, service provider, administrator) can open requests from the four main types decided in the initial development	Critical
2	Register and login system	Registration system in a database (currently firebase) in order for all user details to be registered in a protected location.	Critical
3	Chat	Service girls will be able to correspond to each other in a room that we set up to give solutions to each other	Critical
4	Information Station	An area on the main page where management notices will appear	Low
5	Security and secret information	All the information and the details about the girls have to be private	Critical
6	Permissions	Just the managers of the application will have permission to delete items, and will be responsible for the content	Critical
7	Users profiles	Each user will have a profile with picture and some details that the other users will be able to see	avarage
8	Update details	The users will be able to update their personal details and items that published by them	avarage

Risk Management

UML Diagrams

Deployment Diagrams:

Pages/ Components Diagram:

Permission Table:

Sequence Diagram - Add event (for example):

Persistence

Website:

The application is a web application, which means that all information displayed is compatible with any type of device, tablet, cell phone of any kind, all the information found on the site such as the message store, requests and users is stored in the database in firebaseThe application is a web application, which means that all information displayed is compatible with any type of device, tablet, cell phone of any kind, all the information found on the site such as the message store, requests and users is stored in the database in firebase

Plugin:

The information about the activities, as well the system structure and objects - will be stored in a database placed at the organization’s server(firebase@google).Therefore, further maintenance and management will be in their hands.

Non-functional Requirements

• All system’s components are based on angular2, as required.

• AngularFire2 provides simple management interface which does not require any knowledge in software development or programming languages.

Initial Test Plan

Test Plan:

• Test the database by trying to save a lot of information and see how we maintain it effectively.
• Trivial functionality testing:
• Check how to sign up with Google and Facebook
• Control database
• create/delete/edit requests.
• try to do some functions dynamic.
• dont forget doing all with boostrap!.

SDS Review Summary