Professional Documents
Culture Documents
Replacement SRS
Replacement SRS
Replacement SRS
Version 1.0
<<Annotated Version>>
-Prepared By:
1-Hasan Ali (Teamleader)
2-Ali Derhem.
3-Hamdi Mohammed.
4-Taha Ahmed.
5-Abdulrahman Mahyoup.
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.....................................................................................................................................1
1.1. Purpose..................................................................................................................................................1
1.2. Scope of Project.....................................................................................................................................1
1.3. Glossary.................................................................................................................................................2
1.4. References.............................................................................................................................................2
1.5. Overview of Document.........................................................................................................................2
2.0. Overall Description..............................................................................................................4
2.1 System Environment........................................................................................................................4
2.2 Functional Requirements Specification............................................................................................5
2.2.1 Reader Use Case.......................................................................................................................5
Use case: Search Article......................................................................................................................5
2.2.2 Author Use Case.......................................................................................................................6
Use case: Submit Article......................................................................................................................6
2.2.3 Reviewer Use Case...................................................................................................................7
Use case: Submit Review....................................................................................................................7
2.2.4 Editor Use Cases.......................................................................................................................8
Use case: Update Author.....................................................................................................................8
Use case: Update Reviewer.................................................................................................................9
Use case: Update Article.....................................................................................................................9
Use case: Receive Article..................................................................................................................10
Use case: Assign Reviewer...............................................................................................................11
Use case: Receive Review.................................................................................................................11
Use case: Check Status......................................................................................................................12
Use case: Send Response...................................................................................................................12
Use case: Send Copyright..................................................................................................................13
Use case: Remove Article.................................................................................................................14
Use case: Publish Article...................................................................................................................14
2.3 User Characteristics........................................................................................................................15
2.4 Non-Functional Requirements........................................................................................................15
3.0. Requirements Specification..........................................................................................17
3.1 External Interface Requirements....................................................................................................17
3.2 Functional Requirements................................................................................................................17
3.2.1 Search Article.........................................................................................................................17
3.2.2 Communicate..........................................................................................................................18
3.2.3 Add Author.............................................................................................................................18
3.2.4 Add Reviewer.........................................................................................................................19
3.2.5 Update Person.........................................................................................................................19
3.2.6 Update Article Status..............................................................................................................20
3.2.7 Enter Communication.............................................................................................................20
3.2.8 Assign Reviewer.....................................................................................................................21
3.2.9 Check Status...........................................................................................................................21
3.2.10 Send Communication.............................................................................................................22
3.2.11 Publish Article........................................................................................................................22
3.2.12 Remove Article.......................................................................................................................23
3.3 Detailed Non-Functional Requirements.........................................................................................23
3.3.1 Logical Structure of the Data.................................................................................................23
3.3.2 Security...................................................................................................................................25
Index...............................................................................................................................................................26
i
List of Figures
ii
1.0. Introduction
1.1. Purpose
Replacement 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 system developers. It will be officially proposed for approval to Dr.
will be designed to be more friendly, maximize the user’s productivity, facilitate the
replacing null lectures, filling Application Request of different reasons easier and faster
than being performed manually. By increasing the user’s work efficiency, the system will
which all are concerned with mitigating and improving the lecturer attendance along with
their lost or Null lectures that need to be systematically replaced. The software will
Term Definition
Collection of all replacement information stored and
Database
monitored by this system.
Users(Admin) A person who receives Application Requests, sends articles
for review, and makes final judgments for publications.
A person who fills out the application to request for any
Lecturer
reason
A person who is responsible for receiving and assigning
Dean
(approving) Application Requests from lecturers
Replacement The process of replacing cancelled lectures.
The process of cancelling (making a lecture as absent or
not attended) which can be done in two ways:
Cancellation
-Automatically as receiving from Fingerprint.
-Manually through this system itself.
Online Application in which lecturers can fill their details
via the Website Interface and request for a lecture
Application Request
cancellation or decancellation under any reason such as for
Pre-excuse, Forgot Fingerprint, Holiday etc.
Which cancel half lectures. As an example, when a lecturer
does not present his Enter-fingerprint but presents his Exit-
Half-Cancellation fingerprint because he was late. So these Half-
Cancellations will be collected as Remaining Hours to be
replaced as a full lecture later.
These are the lecture hours that remain NULL/unattended
Remaining-Hours due to being late and losing the first hour of each lecture to
be replaced as full lectures later.
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 such as (Lecturer).
1.4. References
IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements
The next chapter, the Overall Description section of this document gives an
primarily for the developer team which mostly define and describe the details in technical
Both sections of the document describe the same software saystem in its
wholeness and entirety, but are intended for different audiences, therefore they are
Lecturer
Actor Cancellation
Replacement
Dean
Replacement System
Admin
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
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
Search Article
Reader
Brief Description
The Reader accesses the Online Journal Website, searches for an article and downloads it
to his/her machine.
Review
Rewrite
Active
Article
Submit Publish
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.
Submit Article
Author
Brief Description
The author either submits an original article or resubmits an edited article.
Submit Review
Reviewer
Brief Description
The reviewer submits a review of an article.
Update Info
Handle Art
Ck Status
Editor
Send Rec
Publish Art
Update Author
Editor
Brief Description
The Editor enters a new Author or updates information about a current Author.
Update
Reviewer
Hist Soc DB
Editor
Brief Description
The Editor enters a new Reviewer or updates information about a current Reviewer.
Update Article
Editor
Receive Article
Editor
Brief Description
The Editor enters a new or revised article into the system.
Assign Reviewer
Hist Soc DB
Editor
Brief Description
The Editor assigns one or more reviewers to an article.
Receive Review
Editor
Brief Description
The Editor enters a review into the system.
Check Status
Editor
Brief Description
The Editor checks the status of all active articles.
Send Response
Editor
Brief Description
The Editor sends a response to an Author.
Diagram:
Send Copyright
Editor
Brief Description
The Editor sends a copyright form to an Author.
Diagram:
Remove Article
Editor
Brief Description
The Editor removes an article from the active category.
Diagram:
Publish Article
Editor
Brief Description
<< Since three of the actors only have one use case each, the summary diagram only
involves the Editor. Adapt the rules to the needs of the document rather than adapt the
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
The Editor is expected to be Windows literate and to be able to use button, pull-
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
Web pages and the database. The speed of the Reader’s connection will depend on the
The Article Manager will run on the editor’s PC and will contain an Access
system.
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
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.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
The logical structure of the data to be stored in the internal Article Manager
Reviewer
writes
sent to
writes
Article
has
Review
The Logical Structure of the data to be stored in the Online Journal database on the server
is as follows:
3.3.2 Security
The server on which the Online Journal resides will have its own security to
prevent unauthorized write/delete access. There is no restriction on read access. The use
of email by an Author or Reviewer is on the client systems and thus is external to the
system.
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