04-04-2012, 11:38 AM
[attachment=19424]
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 editor’s 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 editor’s work efficiency and production the system will meet the editor’s 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 application’s maintenance options. The system also contains a relational database containing a list of Authors, Reviewers, and Articles.
1.3. Glossary
Term Definition
Active Article 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 Specification 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.
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.
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.
2.0. Overall Description
2.1 System Environment
Figure 1 - System Environment
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.
<< The division of the Web Publishing System into two component parts, the Online Journal and the Article Manager, is an example of using domain classes to make an explanation clearer. >>
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:
Brief Description
The Reader accesses the Online Journal Website, searches for an article and downloads it to his/her machine.
Initial Step-By-Step Description
Before this use case can be initiated, the Reader has already accessed the Online Journal Website.
1. The Reader chooses to search by author name, category, or keyword.
2. The system displays the choices to the Reader.
3. The Reader selects the article desired.
4. The system presents the abstract of the article to the reader.
5. The Reader chooses to download the article.
6. The system provides the requested article.
Xref: Section 3.2.1, Search Article
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
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 editor’s 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 editor’s work efficiency and production the system will meet the editor’s 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 application’s maintenance options. The system also contains a relational database containing a list of Authors, Reviewers, and Articles.
1.3. Glossary
Term Definition
Active Article 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 Specification 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.
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.
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.
2.0. Overall Description
2.1 System Environment
Figure 1 - System Environment
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.
<< The division of the Web Publishing System into two component parts, the Online Journal and the Article Manager, is an example of using domain classes to make an explanation clearer. >>
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:
Brief Description
The Reader accesses the Online Journal Website, searches for an article and downloads it to his/her machine.
Initial Step-By-Step Description
Before this use case can be initiated, the Reader has already accessed the Online Journal Website.
1. The Reader chooses to search by author name, category, or keyword.
2. The system displays the choices to the Reader.
3. The Reader selects the article desired.
4. The system presents the abstract of the article to the reader.
5. The Reader chooses to download the article.
6. The system provides the requested article.
Xref: Section 3.2.1, Search Article
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