Software Requirements Specification Version 1.

0 <<Annotated Version>> April 15, 2004 Web Publishing System Joan Teamleader Paul Adams Bobbie Baker Charles Charlie Submitted in partial fulfillment Of the requirements of CS 310 Software Engineering

<<Any comments inside double brackets such as these are not part of this SRS but are comments upon this SRS example to help the reader understand the point being made.

Refer to the SRS Template for details on the purpose and rules for each section of this document.

This work is based upon the submissions of the Spring 2004 CS 310. The students who submitted these team projects were Thomas Clay, Dustin Denney, Erjon Dervishaj, Tiffanie Dew, Blake Guice, Jonathan Medders, Marla Medders, Tammie Odom, Amro Shorbatli, Joseph Smith, Jay Snellen, Chase Tinney, and Stefanie Watts. >>

Table of Contents
Table of Contents...............................................................................................................................................i List of Figures...................................................................................................................................................ii 1.0. Introduction...............................................................................................................................................ii 1.1. Purpose..................................................................................................................................................ii 1.2. Scope of Project.....................................................................................................................................ii 1.3. Glossary................................................................................................................................................iii 1.4. References............................................................................................................................................iii 1.5. Overview of Document........................................................................................................................iv 2.0. Overall Description....................................................................................................................................1 2.1 System Environment...............................................................................................................................1 2.2 Functional Requirements Specification..................................................................................................1 2.2.1 The Administrator............................................................................................................................1 Use case: Search Article......................................................................................................................1 2.2.2 User Use Case..................................................................................................................................1 ..............................................................................................................................................................2 2.3 User Characteristics................................................................................................................................2 2.4 Non-Functional Requirements................................................................................................................2 .........................................................................................................................................................................2

List of Figures

1.0. Introduction
1.1. Purpose The purpose of this document is to present a detailed description of the CCS Automation System. It will explain the purpose and features of the system, the interfaces of the system, what the system will do and how the system will react to external stimuli. This document is intended for both the stakeholders and the developers of the system. 1.2. Scope of Project This software system is being designed to cater to the needs of students and faculty of this University who are interested in any aspect of this society. The system will provide a user-friendly base to increase awareness about this societys events, workshops, financial aspects and other relevant information. Students will be able to join this society by filling an online form and providing their necessary details. All information about forthcoming events/workshops/guest lectures of the semester as well as details of events/workshops/guest lectures held in the past will be available on this website that will be linked to the universitys homepage. Using this system, the administrator will be able to recruit new members and manage financial data effectively using a well-built relational database at the backend. This will increase the productivity of the society and replace the manual procedures being carried out at present.

ii

It will also facilitate communication between the core team and other members as new updates can be posted on this interactive website. Suggestions, feedbacks and other innovative ideas can also be entertained via this website.

1.3. Glossary Term Active Article Definition The document that is tracked by the system; it is a narrative that is planned to be posted to the public website. Author Person submitting an article to be reviewed. In case of multiple authors, this term refers to the principal author, with whom all communication is made. Database Collection of all the information monitored by this system. Editor Person who receives articles, sends articles for review, and makes final judgments for publications. Field A cell within a form. Historical Society Database The existing membership database (also HS database). Member A member of the Historical Society listed in the HS database. Reader Anyone visiting the site to read articles. Review A written recommendation about the appropriateness of an article for publication; may include suggestions for improvement. Reviewer A person that examines an article and has the ability to recommend approval of the article for publication or to request that changes be made in the article. Software Requirements A document that completely describes all of the functions Specification of a proposed system and the constraints under which it must operate. For example, this document. Stakeholder Any person with an interest in the project who is not a developer. User Reviewer or Author. 1.4. References IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society, 1998.

iii

1.5. Overview of Document The next chapter, 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 chapter, 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 in its entirety, but are intended for different audiences and thus use different language.

iv

2.0.Overall Description
2.1 System Environment

The CCS Automation System has two active actors, (The Administrator and The User) and one cooperating system(Relational Database System). 2.2 Functional Requirements Specification This section outlines the use cases for each of the active readers separately. The reader, the author and the reviewer have only one use case apiece while the editor is main actor in this system. 2.2.1 The Administrator

Use case: Search Article Diagram:

Perform db operations

Administrator

Brief Description The Administrator can make changes to the relational database in terms of updation, insertion, retrieval and deletion on the database.

2.2.2 User Use Case In case of multiple authors, this term refers to the principal author, with whom all communication is made.

SRS V 1.0

April 15, 2004

Diagram:

Retrieve from db

User

Brief Description The User has permission to only retrieve and view the data.

2.3

User Characteristics The User is expected to be Internet literate. The main screen of the CCS Website

will contain information about the society and links to Register As a Member, View Past Records, View Event Calender and Contact Details The Administrator is expected to be Internet Literate and have background knowledge of Oracle. 2.4 Non-Functional Requirements The Website will be linked to the Universitys homepage. The software developed here assumes the use of a tool such as Tomcat for connection between the Web pages and the database. The speed of the Users connection will depend on the hardware used rather than characteristics of this system.

SRS V 1.0

April 15, 2004