SRS

PUBLISHING SYSTEM

WEB

Software Requirements Specification Web Publishing System

NMIET

Page i

1.0. Introduction
1.1. Purpose The purpose of this document is to present a detailed description of the Web Publishing System. 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 Regional Historical Society for its approval. 1.2. Scope of Project This software system will be a Web Publishing System for a local editor of a regional historical society. This system will be designed to maximize the editors productivity by providing tools to assist in automating the article review and publishing process, which would otherwise have to be performed manually. By maximizing the editors work efficiency and production the system will meet the editors needs while remaining easy to understand and use. More specifically, this system is designed to allow an editor to manage and communicate with a group of reviewers and authors to publish articles to a public website. The software will facilitate communication between authors, reviewers, and the editor via E-Mail. Preformatted reply forms are used in every stage of the articles progress through the system to provide a uniform review process; the location of these forms is configurable via the applications maintenance options. The system also contains a relational database containing a list of Authors, Reviewers, and Articles.

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

2.0.
2.1

Overall Description

System Environment

Figure 1 - System Environment

Reader

Author Online Journal

Article Manager Reviewer Web Publishing System HS DB

Editor

The Web Publishing System has four active actors and one cooperating system. The Author, Reader, or Reviewer accesses the Online Journal through the Internet. Any Author or Reviewer communication with the system is through email. The Editor accesses the entire system directly. There is a link to the (existing) Historical Society.

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 Reader Use Case

Use case: Search Article Diagram:

Search Article

Reader

Rewrite

Review

Active Article Submit Publish Figure 2 - Article Submission Process

The Article Submission Process state-transition diagram summarizes the use cases listed below. An Author submits an article for consideration. The Editor enters it into the system and assigns it to and sends it to at least three reviewers. The Reviewers return their comments, which are used by the Editor to make a decision on the article. Either the article is accepted as written, declined, or the Author is asked to make some changes based on the reviews. If it is accepted, possibly after a revision , the Editor sends a copyright form to the

Author. When that form is returned, the article is published to the Online Journal. Not shown in the above is the removal of a declined article from the system. 2.2.2 Author Use Case In case of multiple authors, this term refers to the principal author, with whom all communication is made. Use case: Submit Article Diagram:

Submit Article

Author

2.2.3

Reviewer Use Case

Use case: Submit Review Diagram:

Submit Review

Reviewer

2.2.4

Editor Use Cases

The Editor has the following sets of use cases: Update Information use cases
Update Info Handle Art

Ck Status

Editor Send Rec Publish Art

Use case: Update Author Diagram:

Update Author

Editor

Use case: Update Reviewer Diagram:

Update Reviewer Hist Soc DB

Editor

Use case: Update Article Diagram:

Update Article

Editor

Handle Article use cases Use case: Receive Article Diagram:

Receive Article

Editor

Use case: Assign Reviewer This use case extends the Update Article use case.

Assign Reviewer

Editor

Hist Soc DB

Use case: Receive Review This use case extends the Update Article use case.

Receive Review

Editor

Check Status use case: Use case: Check Status Diagram:

Editor

Send Recommendation use cases: Use case: Send Response This use case extends the Update Article use case. Diagram:

Send Response

Editor

Diagram: Use case: Remove Article This use case extends the Update Article use case. Diagram:

Remove Article

Editor

Publish Article use case: Use case: Publish Article This use case extends the Update Article use case. Diagram:

Publish Article

Editor

2.3

User Characteristics The Reader is expected to be Internet literate and be able to use a search engine.

The main screen of the Online Journal Website will have the search function and a link to Author/Reviewer Information. The Author and Reviewer are expected to be Internet literate and to be able to use email with attachments. The Editor is expected to be Windows literate and to be able to use button, pulldown menus, and similar tools. The detailed look of these pages is discussed in section 3.2 below.

2.4

Non-Functional Requirements The Online Journal will be on a server with high speed Internet capability. The

physical machine to be used will be determined by the Historical Society. 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 Readers connection will depend on the hardware used rather than characteristics of this system. The Article Manager will run on the editors PC and will contain an Access database. Access is already installed on this computer and is a Windows operating system.

3.0.
3.1

Requirements Specification
External Interface Requirements The only link to an external system is the link to the Historical Society (HS)

Database to verify the membership of a Reviewer. The Editor believes that a society member is much more likely to be an effective reviewer and has imposed a membership requirement for a Reviewer. The HS Database fields of interest to the Web Publishing Systems are members name, membership (ID) number, and email address (an optional field for the HS Database). The Assign Reviewer use case sends the Reviewer ID to the HS Database and a Boolean is returned denoting membership status. The Update Reviewer use case requests a list of member names, membership numbers and (optional) email addresses when adding a new Reviewer. It returns a Boolean for membership status when updating a Reviewer.
1.2

Requirements Specification: This section describes in detail all the functional requirements.

3.2.1 Functionality 3.2.1.1 Logon capabilities: The system should provide the users with logon capabilities. 3.2.1.2 To generate report: The system assist the Team leader (LT) to create day wise, CSR wise, query wise and region wise records. 3.2.1.3 Accommodate Market update: The system shall update the details from WEB. 3.3 Usability: The system is user friendly and self explanatory. Since all users are familiar with general usage of computer, no specific training is required.

3.4 Reliability: The system has to be very reliable due to criticality of dada and the damages incorrect or incomplete data can do. 3.5 Availability:

The system is operational as per the working hours of the WEB organization.

3.6 Performances: 3.6.1 Response Time: The splash page or information page should be able to be downloaded within minute using 56K modem. The information is refreshed every two minute. 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.6.2 CSR Response: The system shall take as less time as possible to provide service to the CSR or to the TL. 3.6.3 Throughput: The number of transaction is directly dependent on the member of users. The users may be CSR, TL, and BDM. 3.6.4 Capacity: The system is capable of handling number of users at a time. 3.6.5 Resource Utilization: The resources are modified according the user requirement. 3.7 Hardware Requirements: Processor: Intel Pentium IV or any advanced processor. Hard Disk: 80GB. RAM: 512MB 3.8 Software Requirements: Operating System: Windows XP, Windows vista, Windows 7 etc. Programming language: J2SE 5.2, PHP, JavaScript. Database: Oracle 10G