Online Journal Article Management System Use Cases, Assignments of Web Application Development

Download Online Journal Article Management System Use Cases and more Assignments Web Application Development in PDF only on Docsity! 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. >> 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. SRS V 1.0 1 April 15, 2004 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. SRS V 1.0 2 April 15, 2004 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. SRS V 1.0 3 April 15, 2004 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: Brief Description The author either submits an original article or resubmits an edited article. Initial Step-By-Step Description SRS V 1.0 6 April 15, 2004 Author Submit Article Rewrite Review Active Article Submit Publish Before this use case can be initiated, the Author has already connected to the Online Journal Website. 1. The Author chooses the Email Editor button. 2. The System uses the sendto HTML tag to bring up the user’s email system. 3. The Author fills in the Subject line and attaches the files as directed and emails them. 4. The System generates and sends an email acknowledgement. Xref: Section 3.2.2, Communicate 2.2.3 Reviewer Use Case Use case: Submit Review Diagram: Brief Description The reviewer submits a review of an article. Initial Step-By-Step Description Before this use case can be initiated, the Reviewer has already connected to the Online Journal Website. 1. The Reviewer chooses the Email Editor button. 2. The System uses the sendto HTML tag to bring up the user’s email system. 3. The Reviewer fills in the Subject line and attaches the file as directed and emails it. 4. The System generates and sends an email acknowledgement. Xref: Section 3.2.2, Communicate SRS V 1.0 7 April 15, 2004 Reviewer Submit Review 2.2.4 Editor Use Cases The Editor has the following sets of use cases: Figure 3 - Editor Use Cases Update Information use cases Use case: Update Author Diagram: Brief Description The Editor enters a new Author or updates information about a current Author. Initial Step-By-Step Description Before this use case can be initiated, the Editor has already accessed the main page of the Article Manager. 1. The Editor selects to Add/Update Author. 2. The system presents a choice of adding or updating. 3. The Editor chooses to add or to update. 4. If the Editor is updating an Author, the system presents a list of authors to choose from and presents a grid filling in with the information; else the system presents a blank grid. SRS V 1.0 8 April 15, 2004 Editor Update Author Update Info Editor Handle Art Ck Status Send Rec Publish Art Use case: Assign Reviewer This use case extends the Update Article use case. Diagram: Brief Description The Editor assigns one or more reviewers to an article. Initial Step-By-Step Description Before this use case can be initiated, the Editor has already accessed the article using the Update Article use case. 1. The Editor selects to Assign Reviewer. 2. The system presents a list of Reviewers with their status (see data description is section 3.3 below). 3. The Editor selects a Reviewer. 4. The system verifies that the person is still an active member using the Historical Society Database. 5. The Editor repeats steps 3 and 4 until sufficient reviewers are assigned. 6. The system emails the Reviewers, attaching the article and requesting that they do the review. 7. The system returns the Editor to the Update Article use case. Xref: Section 3.2.8, Assign Reviewer Use case: Receive Review This use case extends the Update Article use case. Diagram: Brief Description The Editor enters a review into the system. SRS V 1.0 11 April 15, 2004 Editor Assign Reviewer Hist Soc DB Editor Receive Review Initial Step-By-Step Description Before this use case can be initiated, the Editor has already accessed the article using the Update Article use case. 1. The Editor selects to Receive Review. 2. The system presents a grid for filling with the information. 3. The Editor fills in the information and submits the form. 4. The system verifies the information and returns the Editor to the Article Manager main page. Xref: Section 3.2.7, Enter Communication Check Status use case: Use case: Check Status Diagram: Brief Description The Editor checks the status of all active articles. Initial Step-By-Step Description Before this use case can be initiated, the Editor has already accessed the main page of the Article Manager. 1. The Editor selects to Check Status. 2. The system returns a scrollable list of all active articles with their status (see data description in section 3.3 below). 3. The system returns the Editor to the Article Manager main page. Xref: Section 3.2.9, Check Status Send Recommendation use cases: Use case: Send Response This use case extends the Update Article use case. SRS V 1.0 12 April 15, 2004 Editor Check Status Diagram: Brief Description The Editor sends a response to an Author. Initial Step-By-Step Description Before this use case can be initiated, the Editor has already accessed the article using the Update Article use case. 1. The Editor selects to Send Response. 2. The system calls the email system and puts the Author’s email address in the Recipient line and the name of the article on the subject line. 3. The Editor fills out the email text and sends the message. 4. The system returns the Editor to the Article Manager main page. Xref: Section 3.210, Send Communication Use case: Send Copyright This use case extends the Update Article use case. Diagram: Brief Description The Editor sends a copyright form to an Author. Initial Step-By-Step Description Before this use case can be initiated, the Editor has already accessed the article using the Update Article use case. 1. The Editor selects to Send Copyright. 2. The system calls the email system and puts the Author’s email address in the Recipient line, the name of the article on the subject line, and attaches the copyright form. 3. The Editor fills out the email text and sends the message. SRS V 1.0 13 April 15, 2004 Editor Send Response Editor Send Copyright developed here assumes the use of a tool such as Tomcat for connection between the Web pages and the database. The speed of the Reader’s connection will depend on the hardware used rather than characteristics of this system. The Article Manager will run on the editor’s PC and will contain an Access database. Access is already installed on this computer and is a Windows operating system. SRS V 1.0 16 April 15, 2004 3.0. Requirements Specification 3.1 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 member’s 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. 3.2 Functional Requirements The Logical Structure of the Data is contained in Section 3.3.1. 3.2.1 Search Article Use Case Name Search Article XRef Section 2.2.1, Search Article SDD, Section 7.1 Trigger The Reader assesses the Online Journal Website Precondition The Web is displayed with grids for searching Basic Path 1. The Reader chooses how to search the Web site. The choices are by Author, by Category, and by Keyword. 2. If the search is by Author, the system creates and presents an alphabetical list of all authors in the database. In the case of an article with multiple authors, each is contained in the list. 3. The Reader selects an author. 4. The system creates and presents a list of all articles by that author in the database. 5. The Reader selects an article. SRS V 1.0 17 April 15, 2004 6. The system displays the Abstract for the article. 7. The Reader selects to download the article or to return to the article list or to the previous list. Alternative Paths In step 2, if the Reader selects to search by category, the system creates and presents a list of all categories in the database. 3. The Reader selects a category. 4. The system creates and presents a list of all articles in that category in the database. Return to step 5. In step 2, if the Reader selects to search by keyword, the system presents a dialog box to enter the keyword or phrase. 3. The Reader enters a keyword or phrase. 4. The system searches the Abstracts for all articles with that keyword or phrase and creates and presents a list of all such articles in the database. Return to step 5. Postcondition The selected article is downloaded to the client machine. Exception Paths The Reader may abandon the search at any time. Other The categories list is generated from the information provided when article are published and not predefined in the Online Journal database. 3.2.2 Communicate Use Case Name Communicate XRef Section 2.2.2, Submit Article; Section 2.2.3, Submit Review SDD, Section 7.2 Trigger The user selects a mailto link. Precondition The user is on the Communicate page linked from the Online Journal Main Page. Basic Path This use case uses the mailto HTML tag. This invokes the client email facility. Alternative Paths If the user prefers to use his or her own email directly, sufficient information will be contained on the Web page to do so. Postcondition The message is sent. Exception Paths The attempt may be abandoned at any time. Other None 3.2.3 Add Author Use Case Name Add Author XRef Section 2.2.4, Update Author SDD, Section 7.3 Trigger The Editor selects to add a new author to the database. Precondition The Editor has accessed the Article Manager main screen. Basic Path 1. The system presents a blank grid to enter the author information. 2. The Editor enters the information and submits the form. 3. The system checks that the name and email address fields are not blank and updates the database. SRS V 1.0 18 April 15, 2004 Alternative Paths None Postcondition The article entry is updated in the database. Exception Paths The Editor may abandon the operation at any time. Other This use case extends 3.2.6, Update Article Status 3.2.8 Assign Reviewer Use Case Name Assign Reviewer XRef Section 2.2.4, Assign Reviewer SDD, Section 7.8 Trigger The Editor selects to assign a reviewer to an article. Precondition The Editor has accessed the Article Manager main screen and the article is already in the database. . Basic Path 1. The Editor selects the article using the 3.2.6, Update Article Status use case. 2. The system presents an alphabetical list of reviewers with their information. 3. The Editor selects a reviewer for the article. 4. The system updates the article database entry and emails the reviewer with the standard message and attaches the text of the article without author information. 5. The Editor has the option of repeating this use case from step 2. Alternative Paths None. Postcondition At least one reviewer has been added to the article information and the appropriate communication has been sent. Exception Paths The Editor may abandon the operation at any time. Other This use case extends 3.2.6, Update Article Status. The Editor, prior to implementation of this use case, will provide the message text. 3.2.9 Check Status Use Case Name Check Status XRef Section 2.2.4, Check Status SDD, Section 7.9 Trigger The Editor has selected to check status of all active articles. Precondition The Editor has accessed the Article Manager main screen. Basic Path 1. The system creates and presents a list of all active articles organized by their status. 2. The Editor may request to see the full information about an article. Alternative Paths None. Postcondition The requested information has been displayed. Exception Paths The Editor may abandon the operation at any time. Other The editor may provide an enhanced list of status later. At present, the following categories must be provided: 1. Received but no further action taken SRS V 1.0 21 April 15, 2004 2. Reviewers have been assigned but not all reviews are returned (include dates that reviewers were assigned and order by this criterion). 3. Reviews returned but no further action taken. 4. Recommendations for revision sent to Author but no response as of yet. 5. Author has revised article but no action has been taken. 6. Article has been accepted and copyright form has been sent. 7. Copyright form has been returned but article is not yet published. A published article is automatically removed from the active article list. 3.2.10 Send Communication Use Case Name Send Communication XRef Section 2.2.4, Send Response; Section 2.2.4, Send Copyright SDD, Section 7.10 Trigger The editor selects to send a communication to an author. Precondition The Editor has accessed the Article Manager main screen. Basic Path 1. The system presents an alphabetical list of authors. 2. The Editor selects an author. 3. The system invokes the Editor’s email system entering the author’s email address into the To: entry. 4. The Editor uses the email facility. Alternative Paths None. Postcondition The communication has been sent. Exception Paths The Editor may abandon the operation at any time. Other The standard copyright form will be available in the Editor’s directory for attaching to the email message, if desired. 3.2.11 Publish Article Use Case Name Publish Article XRef Section 2.2.4, Publish Article SDD, Section 7.11 Trigger The Editor selects to transfer an approved article to the Online Journal. Precondition The Editor has accessed the Article Manager main screen. Basic Path 1. The system creates and presents an alphabetical list of the active articles that are flagged as having their copyright form returned. 2. The Editor selects an article to publish. 3. The system accesses the Online Database and transfers the article and its accompanying information to the Online Journal database. 4. The article is removed from the active article database. Alternative Paths None. SRS V 1.0 22 April 15, 2004 Postcondition The article is properly transferred. Exception Paths The Editor may abandon the operation at any time. Other Find out from the Editor to see if the article information should be archived somewhere. 3.2.12 Remove Article Use Case Name Remove Article XRef Section 2.2.4, Remove Article SDD, Section 7.12 Trigger The Editor selects to remove an article from the active article database. Precondition The Editor has accessed the Article Manager main screen. Basic Path 1. The system provides an alphabetized list of all active articles. 2. The editor selects an article. 3. The system displays the information about the article and requires that the Editor confirm the deletion. 4. The Editor confirms the deletion. Alternative Paths None. Postcondition The article is removed from the database. Exception Paths The Editor may abandon the operation at any time. Other Find out from the Editor to see if the article and its information information should be archived somewhere. 3.3 Detailed Non-Functional Requirements 3.3.1 Logical Structure of the Data The logical structure of the data to be stored in the internal Article Manager database is given below. SRS V 1.0 23 April 15, 2004 The PC on which the Article Manager resides will have its own security. Only the Editor will have physical access to the machine and the program on it. There is no special protection built into this system other than to provide the editor with write access to the Online Journal to publish an article. SRS V 1.0 26 April 15, 2004 Index Abstract, 6, 17, 27 add, 9, 11, 19, 20, 21 Add, 8, 9, 19 Article, 1, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28 Article Manager, 5, 8, 9, 10, 11, 12, 13, 14, 15, 16, 19, 20, 21, 22, 23, 24, 25, 28 Author, 1, 4, 5, 6, 7, 8, 9, 13, 14, 16, 17, 19, 20, 22, 23, 25, 26, 27 Category, 5, 14, 17, 18, 20, 21, 23, 26, 27 Database, 2, 9, 11, 14, 15, 16, 17, 18, 19, 20, 21, 22, 24, 25, 26, 27 Editor, 1, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 19, 20, 21, 22, 23, 24, 25, 28 Field, 17, 19, 20 Form, 1, 6, 9, 10, 11, 12, 14, 19, 20, 21, 23, 24, 27 Grid, 9, 11, 12, 19, 20, 21 Historical Society, 1, 5, 9, 11, 16, 17, 19, 20, 26 Online Journal, 4, 5, 6, 7, 15, 16, 17, 18, 24, 27, 28 Reader, 4, 5, 6, 16, 17, 18 Review, 1, 7, 11, 12, 18, 21, 23, 26, 27 Reviewer, 1, 4, 5, 6, 7, 9, 11, 16, 17, 19, 20, 21, 22, 23, 26, 27 Security, 27, 28 Status, 11, 12, 13, 14, 17, 21, 22, 23, 27 update, 9, 11, 20, 21 Update, 8, 9, 10, 11, 12, 13, 14, 15, 17, 19, 20, 21, 22 User, 7, 16, 18 Web Publishing System, 1, 4, 5, 17 SRS V 1.0 27 April 15, 2004