Requirements Specification

Software Requirements Specification

Introduction
1.1. Purpose
1.2. Overview
1.3. Environmental Characteristics
1.3.1. Hardware
1.3.2. Software
1.3.3. Usability
Goals of Implementation
Overall Description
3.1. Product Functions
3.2. Platform Users and Characteristics
3.3. Product Glossary
Requirements
4.1. Functional Requirements
4.2. Non-Functional Requirements

1. Introduction

1.1. Purpose

This documents provides an overview of the Software Requirements Specification for "SWE574 Class Project - HorusCope" with system characteristics, description, functional and non-functional requirements, behavioral description and questions. The document aims to gather and analyze the specifications of HorusCope.

1.2. Overview

The document examines the implementation goals in Section 2, overall description in Section 3, functional and non-functional requirements in Section 4.

1.3. Environmental Characteristics

1.3.1. Hardware

There are no requirements for a bare-metal server. For ease of use, cloud based service providers will be used. (PaaS and IaS services can be used, leaving out SaaS components)

Candidates for cloud providers:

Microsoft azure
Amazon Web Services

1.3.2. Software

Web Server: Any container supporting Java/Python
Programming Language: Java/Python
Database: PostgreSQL/MongoDB
Frontend: Angular/React/Bootstrap

In client side, the web application should be reachable from common web browsers with HTML 5.0 support.

1.3.3. Usability

User interfaces of the platform should be friendly enough to enable non-technical people to use the platform from targeted client environment which can be mobile or web application.

2. Goals of Implementation

Develop a timeline to insure milestone dates are met and the project is completed within the established timeline.
Manage implementation within pre-determined time.
Follow SDLC- Software/System Development Life Cycle
Follow Agile project management practices.

The application development phases include requirements analysis(gathering requirements), design(high level design and detailed design), implementation(development to transfer a design to product), testing (unit and integration testing) and evolution(deployment and maintenance) phases.

3. Overall Description

3.1. Product Functions

3.1.1 General

Register new user
Login
Browse anonymously

3.1.2 Community

Create new community
Delete community
Join community
Leave community
Create Custom DataType
Modify own Custom DataType
Delete own Custom DataType

3.1.3 Post

Read all posts inside a community
Modify own posts inside a community
Submit own posts inside a community
Delete own posts inside a community
Query all posts inside a community
Flag inappropriate posts

3.1.4 Administration

Delete users
Modify users
Moderate flagged posts
Author community moderators

3.1.5 Generic DataType

HorusCope provides a primitive datatype for all communities which is called "Generic DataType". Common fields;

Title - used for short name, required
Description - used for detailed description
Semantic Tag - used for semantic search and relations, required

3.1.6 Custom DataType

Community specific datatypes which inherit fields "Title" and "Semantic Tag" from primitive structure "Generic DataType". A community can have multiple DataType's. Custom DataType posts can use the following field types;

Image
Audio
Video
Text
Enumaration
Email
Url
Datetime
Number

3.1.7 Comments

Create comments on posts
View all comments
Delete own comment

3.1.8 Annotations

Create annotations on text
Create annotations on image
Delete own annotation
View Annotations
Filter annotations

3.1.9 Activity Streams

Subscribe to posts
Subscribe to data types
Subscribe to users
Get notifications for subscribed content
Unsubscribe from content

3.1.10 Semantic Search

Search all content
View semantic results

3.2. Platform Roles and Functions

3.2.1 Roles

Registered User
Anonymous
Administrator
Moderator

3.2.2 Roles & Functions

Function	Registered User	Anonymous	Administrator	Moderator
Register		x
Login	x		x	x
Browse	x	x	x	x
Create Community	x		x	x
Join Community	x		x	x
Leave Community	x		x	x
Delete Community			x
Browse Community	x	x	x	x
Create Custom DataType	x		x	x
Modify own Custom DataType	x		x	x
Delete own Custom DataType	x		x	x
Read Posts	x	x	x	x
Submit Post	x		x	x
Modify Own Posts	x		x	x
Delete Own Posts	x		x	x
Query All Posts	x	x	x	x
Delete Users			x
Modify Users			x
Create comments	x		x	x
View comments	x	x	x	x
Delete own comment	x		x	x
Subscribe to content	x		x	x
Unsubscribe from content	x		x	x
View Activity Stream	x		x	x
Search Content	x	x	x	x
Flag posts	x		x	x
Moderate posts			x	x
Create Annotations	x	x	x	x
View Annotations	x	x	x	x
Delete own Annotation	x	x	x	x
Author moderators			x

3.3. Product Glossary

Community - A group of DataType's with subscribed users having a particular characteristic in common
DataType - A structure to hold information with predefined fields
Community Builder - Community User's who create new communities or custom data types
Community User - Registered user who has "Registered User" role
Anonymous User - Unregistered users who has "Anonymous" role
Field - Representation of data in specific types
Primitive Data Type - A basic structure to hold the predefined format of a community (Title, Description, Semantic Tag)
Generic DataType - Initial common datatype and official channel of a community
Custom DataType - A predefined structure and sub category to gather data from community users in a structured way
Activity Stream - A list of activities which shows the interactions of the users with different users
Annotation - A structured model and format, in JSON, to enable information to be shared and reused across different platform
City - A special datatype which can be assigned to communities

4. Requirements

4.1. Functional Requirements

Requirement	Short Description	Perspective	Details
4.1.1	Register	User	Users shall be able to register to the platform by providing Firstname, Lastname, username, password details
4.1.2	Login	User	Users shall be able to login to the platform by providing username and password
4.1.3	Reset Password	User	Users shall be able to reset their password using provided email address during registration
4.1.4	Create Community	User	Registered users shall be able to create new communities
4.1.5	Define Data Types	User	Registered users shall be able to create predefined structures for storing information inside communities
4.1.6	Content Evolution	User	Users who are owners of a predefined structure shall be able to modify this predefined structure by adding or removing fields to evolve the stored information
4.1.7	Generic Data Type Structure	Product	Generic Data Type shall have Title, Description and Semantic Tag fields
4.1.8	Custom Data Type Structure	Product	Custom Data Type shall inherit Title and Semantic Tag fields and have user specified number of primitive types
4.1.9	WikiData Tags	User	Users shall be able to relate posts with recommendations from WikiData services on a query topic
4.1.10	Full-Text Search	User	Users shall be able to search all information stored inside communities using full-text search
4.1.11	Filtered Search	User	Users shall be able to search information stored in predefined structures using fields from these structures as filters
4.1.12	Primitive Types	Product	Platform shall provide users primitive types {Image, Audio, Video, Text, Enumaration, Email, Url, Datetime, Number} to be used when creating predefined structures to hold community specific information
4.1.13	WikiData Recommendations	Product	Platform shall provide community recommendations to users using membership information and WikiData tags
4.1.14	Browse Communities	User	Anonymous or registered users shall be able to view communities and read posts inside communities
4.1.15	Post	User	Registered users shall be able to post information to communities using generic or predefined structures
4.1.16	Enumeration Field	User	When creating predefined structures to hold information inside a community, user shall be able to use a special field which allows them to select values from predefined options
4.1.17	Upload Rich Content	User	Users shall be able to store rich content (Video, audio or image) inside communities
4.1.18	Update Community	User	Community owner users shall be able to update community information
4.1.19	Update Post	User	Users shall be able to update own posts
4.1.20	Delete Post	User	Users shall be able to delete own posts
4.1.21	Required Field	User	Users shall be able to define required fields when creating predefined structures to store information inside a community
4.1.22	Comment Post	User	Registered users shall be able to add their comments using free text input on posts, and read other people's comments
4.1.23	Flag Post	User	Registered users shall be able to flag inappropriate posts
4.1.24	Audio Post	User	Users shall be able to create audio versions of posts using annotations using W3C Web Annotation Standard
4.1.25	Semantic Search	User	Users shall be able to query content and get semantic search results based on relations between contents through semantic tags
4.1.26	Summary Reports	User	Users shall be able to render summary reports on posts
4.1.27	Moderators	User	A group of users authored by administrator shall be able have the moderator role of a community. Community moderators shall be able to moderate flagged content.
4.1.28	Flag posts	User	Users shall be able to flag inappropriate post
4.1.29	Moderate posts	User	Moderators shall be able to author posts which are flagged more than the predefined system threshold
4.1.30	City Search	User	Users shall be able to search communities by their assigned City information
4.1.31	Post Status	Product	Platform shall provide a way to track the status of content from a predefined set of values (Open, Closed, In progress)
4.1.32	Subscription	User	Registered users shall be able to subscribe to communities, posts, data types and users. Subscribed users shall be able to unsubscribe from same content
4.1.33	Activity Stream	User	Registered users shall be able to view their activity stream for subscribed content
4.1.34	Annotations	User	Outside users shall be able to annotate text and image content and view existing annotations from this platform using W3C Web Annotation Standard
4.1.35	Annotations	User	Outside users shall be able to filter annotations by various aspects such as "Today's/This week's annotations" or a specific user's annotations

4.2. Non-Functional Requirements

Requirement No	Short Description	Type	Details
4.2.1	Database	Product	Database used for the platform shall be MongoDB or PostgreSQL
4.2.2	Programming Language	Product	Programming language used to implement the platform shall be Java or Python
4.2.3	Front-end	Product	Platform front-end shall be mobile or web application
4.2.4	Database	Product	Annotation server data shall be isolated from platform data
4.2.5	Database	Product	Annotation data shall be stored in json-ld format and it shall contain the minimum attributes for the targets and conform to W3C Web Annotation Standard
4.2.6	Front-end	Product	Annotation client shall use xpath as selector

5. Assumptions

Assumption No	Short Description	Details
5.1	Orphaned Values	When builders alters Custom Data Type definition, the platform shall behave optimistic about orphaned information