CONTENT MANAGEMENT SYSTEM (E-LEARNING)

SUBMITTED BY: THAKRAR SAGAR ASHOKBHAI 09BCE550

SOFTWARE REQUIREMENT SPECIFICATION

TABLE OF CONTENTS

1. INTRODUCTION
1.1. Purpose 1.2. Scope 1.3. Document Conventions-Acronyms and Abbreviations 1.4. Intended audience 1.5. Problem definition 1.6. References 1.7. Overview

2. OVERALL DESCRIPTION
2.1. Product perspective 2.2. Product functions 2.2.1. Articles 2.2.2. Videos 2.2.3. Forums

3. SPECIFIC REQUIRMENTS 3.1.Functional Requirements

3.1.1. Login 3.1.2. Search articles 3.1.3. Add articles 3.1.4. Remove articles 3.1.5. Add videos 3.1.6. Remove videos 3.1.7. Post comments 3.1.8. Opening a topic on forum 3.1.9. Update article 3.1.10. Posting in forum 3.1.11. Creating a user account 3.1.12. Rating an article 3.1.13. Moderating of posts and articles via back end 3.1.14. Article management via backend

3.2. Non-Functional Requirements 3.2.1Usability 3.2.2Reliability

3.2.2.1. Availability 3.2.2.2. Mean Time Between Failures (MTBF) 3.2.2.3. Mean Time to Repair (MTTR) 3.2.2.4. Accuracy 3.2.2.5. Access Reliability

3.2.3. Performance
3.2.3.1. Response Time 3.2.3.2. Throughput 3.2.3.3. Capacity 3.2.3.4. Resource Utilization

3.2.4. Supportability
3.2.4.1. Internet Protocols 3.2.4.2. Information Security Requirement 3.2.4.3. Maintenance

3.2.5. Security 3.2.6. Time 4. USER CLASS AND CHARACTERISTICS 5. OPERATING ENVIRONMENT 6. DESIGN CONSTRAINTS
6.1.Software Language Used 6.2.Development Tools

7. ON-LINE USER DOCUMENTATION AND HELP SYSTEM 8. INTERFACES

8.1.User Interfaces 8.2.Hardware Interfaces 8.3.Software Interfaces

9. REPORTS

10. OTHER IMPORTANT ISSUES 11. TEAM SIZE 12. FINAL DELIVERABLE PRODUCT

1. INTRODUCTION:
1.1. PURPOSE: The purpose of this document is to present a detailed description of the Content Management System for E-learning. It will explain the purpose and features of the system, the interfaces of the system, what the system will do, the

constraints under which it must operate and how the system will react to external stimuli. This document is intended for both the stakeholders and the developers of the system and will be proposed to the concerned authorities for its approval. 1.2. PRODUCT SCOPE Easy way for the students to learn. Medium for teachers to provide valuable information. Ease in doubt solving via forums. 1.3 DOCUMENT CONVENTIONS: Main headings: Bold 1.4. INTENDED AUDIENCE AND READING SUGGESTIONS: The different types of readers are: Teachers Students Inquisitive people who want to learn 1.5. PROBLEM DEFINITION: It consists of Adding and Deleting articles Posting videos Adding comments to the article Rating an article Discussion on forums

1.6. REFERENCES IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society, 1998.

1.7. OVERVIEW

The next section, the Overall Description section, of this document gives an overview of the functionality of the product. It describes the informal requirements and is used to establish a context for the technical requirements specification in the next chapter. The third Section, Requirements Specification section, of this document is written primarily for the developers and describes in technical terms the details of the functionality of the product. Both sections of the document describe the same software product, but are intended for different audiences and thus use different language.

2. OVERALL DESCRIPTION:
2.1. PRODUCT PERSPECTIVE: It enables us to provide information on various things by means of an article which can be commented on and rated. Also videos can be included in the article. Discussions on various topics can be done in forums. 2.2. PRODUCT FUNCTIONS: It tells the short note about the product.
2.2.1. ARTICLES

Users can view various articles posted on the website. They can search articles, add new article if an article doesnt exist for a particular subject. If some content is inappropriate or wrong the users can ask for updation. The users can comment on the article and rate it too.
2.2.2. VIDEOS

Users can add videos related to an article once they are logged in. These videos are approved by the administrator and then available to the audience
2.2.3. FORUMS

For clearing doubts on various topics open discussions can be held in a forum. This will help in better understanding of the topic as well as clear misconceptions and doubts.

3. SPECIFIC REQUIRMENTS:
3.1.FUNCTIONAL REQUIRMENTS:
3.1.1.Login

Inputs: - Username, Password. Process:There can be 2 types of users registered and unregistered. If a user is unregistered then he/she can create a new account By clicking on the signup option.

 If the user is already registered then the required username and Password are matched with the entries in the database if it is correct then the user is redirected to the welcome page. Output: - Welcome page is the home page of the website where there is a search bar, articles recently viewed by different users, latest articles, link to the forum, main menu etc
3.1.2. Search the articles

Inputs: - Keyword to search the article. Process: - When a user enters a keyword to search the articles, the system runs a scan in the database to find that keyword. If no entry is found then the result displayed is No article found. Output: - The output will be a list of articles which are relevant to the keyword.
3.1.3. Add article

Input:- Information on the topic, topic name. Process:-When the user wants to add an article, he goes to the profile page and selects add an article. Then he enters the name of the article and the information in an onsite word processor. If there are images, the user can upload them. The article will be submitted to the moderator which on acceptance will be published on the website. Output:-The article is submitted to the moderator for approval and message saying so is displayed.

3.1.4. Delete an article

Input:-User clicks on the delete button. Process:When the user requests an article to be deleted he is prompted first whether he is sure of the action. If the user says yes, a delete request is sent to the moderator and the article is deleted If the user says no, he is returned back to the page Output:-The deletion request for the article is sent to the moderator and a message saying so is displayed.

3.1.5. Add videos

Input:-The video file which is to be uploaded. Process:-The user requests a video file to be uploaded to an existing article. In that case the video file is uploaded and the request is sent to the moderator. After the approval of the moderator, the video is posted. Output:-The request for addition of video file is sent to the moderator and a message saying so is displayed.
3.1.6. Removing a video

Input:-User clicks on the delete button. Process:When the user requests a video to be deleted he is prompted first whether he is sure of the action. If the user says yes, a delete request is sent to the moderator and the video is deleted If the user says no, he is returned back to the page Output:-The deletion request for the video is sent to the moderator and a message saying so is displayed.
3.1.7. Post comments

Input:-The user enters a comment on an article Process:-A user when logged in is given an option of commenting on an article. To do so, he comments in the text box given below in the article and submits it. The comment is displayed immediately on the screen. Output:-The comment is displayed below the article.

3.1.8. Opening a topic on forum

Input:-The user enters the topic and clicks on create a new discussion button. Process:-The user has the option to open a new topic on forum. For that he goes to the forum page, clicks on open a new topic, enters the name of the topic and description and finally submits it. The topic is immediately opened and the notification is sent to the moderator. Output:-A new topic is opened on the forum page.
3.1.9. Update article

Input:-Details to be updated and references for proof.

Process:- A user can ask for an article to be updated or changed. For that he submits a request along with the details for the updation and also the references which can be used to verify that the provided details are correct. The moderator then approves or rejects the requests and the article is affected. Output:-A request for the change of the article is sent to the moderator.
3.1.10. Posting in forum

Input:-Material for the post. Process:-A user may start posting messages on the forum after he is logged. Also, if required, files can be uploaded for sharing via the forum. Output:-The message posted is displayed on the forum.
3.1.11. Creating an account

Input:-Personal information or a facebook id or a gmail id. Process:-A user might register and create a new account. For this there are two procedures: A user can fill the form for creating a new account. A user can directly register using facebook or gmail account. Output:-A new user account is created.
3.1.12. Rating an article

Input:-The user rates an article out of 5 stars. Process:-There is a rating system for every article to maintain quality. The user can simply select his rating out of 5 starts by selecting it and then clicking on rate it. The average rating is immediately updated. Output:-The updated average rating is displayed.

3.1.12. Moderating of posts and articles via backend

Input:-The moderator selects an option whether to delete, grant request or block a user. Process:-The moderator actually controls what is posted on the site. The reports of addition and deletion request for articles and videos is generated and posted to the moderator who then decides whether to approve or disapprove the request. Also the comments and posts are randomly scanned by the moderator to make sure that there is no violation of the terms of usage. If the moderator wants he can delete the post or comment and even block or suspend the user membership. Output:-Article/video is displayed or updated.

3.1.3. Article management via backend

Input:- Information on the topic, topic name. Process:-The moderator can directly add an article/video from the backend using an online word processor. Also he can delete an article/video or modify it. Output:-The article/video is displayed or deleted according to the action 3.2 NON FUNCTIONAL REQUIREMENTS: In systems engineering and requirements engineering, non-functional requirements are requirements which specify criteria
3.2.1. USABILTY:

This requirement is already present in the project as this system will interact with the moderator who will keep an eye on what is being uploaded or posted. However, as far as usability is concerned the users will find it convenient. The system has wide range of usability. For eg if the user wants to find some information on a topic, he can find it. If he finds something interesting he can share it. Also he can clear his doubts with forums. No doubt usability is here of main concern for the customers.

3.2.2. RELIABILTY:

The system is highly robust. It is supported with good error handling mechanisms which help to go immediately to the previous state if something wrong happens in the between. Reliability is always concerned at each design phase making the system helpful for the passengers.
3.2.2.1 Availability:

The system is available 100% for the user and is used 24 hrs a day and 365 days a year. The system shall be operational 24 hours a day and 7 days a week.
3.2.2.2. Mean Time Between Failures (MTBF):

The system will be developed in such a way that it may fail once in 6 months.

3.2.2.3. Mean Time to Repair (MTTR):

Even if the system fails, the system will be recovered back up within an hour or less.
3.2.2.4. Accuracy:

The accuracy of the system is limited by the accuracy of the speed at which the moderators and users use the system.
3.2.2.5. Access Reliability:

The system shall provide 100% access reliability.

3.2.3.PERORMANCE:

The system is fast enough to produce the output fast for any operation. As soon as the customer opens the login page and submits the username with the password it will not take more than 10 seconds to display the main page. The uploading of the videos and articles is fast enough to carry out efficient use.
3.2.3.1. Response Time:

The Information page should be able to be downloaded within 10 seconds. The information is refreshed every five minutes. The access time for a mobile device should be less than a minute. The system shall respond to the member in not less than two seconds from the time of the request submittal. The system shall be allowed to take more time when doing large processing jobs.
3.2.3.2. Throughput:

The number of transactions is directly dependent on the number of users, the users may be moderators and also the people who use the cms site for various purposes.
3.2.3.3. Capacity:

The system is capable of handling 2000 users at a time.

3.2.3.4. Resource Utilization:

The resources are modified according the user requirements and also according to the content requested by the users.

3.2.4. SUPPORTABILTY:

The system designers shall take in to considerations the following supportability and technical limitations:
3.2.4.1. Internet Protocols:

The system shall be comply with the TCP/IP protocol standards and shall be designed accordingly.
3.2.4.2. Information Security Requirement:

The system shall support the UHCL information security requirements and use the same standard as the UHCL information security requirement.
3.2.4.3. Maintenance:

The maintenance of the system shall be done as per the maintenance contract.

3.2.5. SECURITY:

The system is designed with all secured features. No transaction fail will lead to the loss of information of the users. If something like that happens by fault the system ensures that the information is saved beforehand so that it can be restored later. Login also requires a strong password for customers account safety.

3.2.6. TIME:

The project should be completed within the stipulated time period. Conventionally it is a non-functional requirement (security) because it does not specify specific system functionality. The role of time in any project is very important. If there is delay in any phase of the project it may produce diverse effects on the other phases. A proper timeline description before starting is very necessary. It should be strictly followed.

4. USER CLASS AND CHARACTERISTICS:

Knowledgeable user Moderator Expert user

5. OPERATING ENVIRONMENT:
The OS types are Windows NT Windows XP

Windows 98 Windows 7 and all the previous versions of windows Linux Mac OSx

6. DESIGN CONSTRAINTS:
6.1. Software Language Used:

The languages that shall be used for coding the CMS are PHP (PHP Hypertext Preprocessor), JavaScript, SQL (Server Query Language), HTML, JQuery, and CSS (Cascading Style Sheets). For working on the coding phase of the CMS, the Apache server needs to be installed.
6.2. Development Tools:

We will make use of the available Microsoft Expressions web. Also will make use of the online references available for developing programs in PHP (PHP Hypertext Preprocessor), JavaScript, SQL (Server Query Language), HTML, JQuery, and CSS (Cascading Style Sheets).

7. ONLINE USER DOCUMENTATION AND HELP SYSTEM:

Online help is provided for each of the feature available with the CMS. All the applications provide an on-line help system to assist the user. The nature of these systems is unique to application development as they combine aspects of programming (hyperlinks, etc) with aspects of technical writing (organization, presentation). Online help is provided for each and every feature provided by the system. The User Manual describes the use of the system to user and Employees. It

describes the use of the system on mobile systems. The user manual should be available as a hard copy and also as online help. An installation document will be provided that includes the installation instructions and configuration guidelines, which is important to a full solution offering. Also, a Read Me file is typically included as a standard component. The Read Me includes a Whats New With This Release section, and a discussion of compatibility issues with earlier releases. Most users also appreciate documentation defining any known bugs and workarounds in the Read Me file. Since the installation of CMS is a complex process, our experts will do it. So an installation Guide will not be provided to the employees.

8. INTERFACES:
8.1. User Interfaces: We will make use of the existing Web Browsers such as Microsoft Internet Explorer or Mozilla Firefox. The user-interface of the system shall be designed as shown in the user-interface prototypes. . 8.2. Hardware Interfaces: The existing wide Area Network (WAN) will be used for collecting data from the users. 8.3. Software Interfaces: A firewall will be used with the server to prevent unauthorized access to the system.

9. REPORTS
1. Details of user and usage 2. Trail of user logon and usage. 3. Trail of changes made to articles. 4. Trail of added or deleted articles and videos. 5. Trail of blacklisted users, comments, posts, forums, videos and articles

10. FINAL DELIVERABLE PRODUCT

Final deliverables must include: A. Online or offline help to above said users and application deployment B. Application archive with source code C. Database backup and DDL Script D. Complete Source code