Table of Contents

Table of Contents.............................................................................................................................................1 List of Figures...................................................................................................................................................2 Introduction.......................................................................................................................................................3 1.1. Purpose..................................................................................................................................................3 1.2. Scope of Project.....................................................................................................................................3 1.3. Glossary.................................................................................................................................................3 1.4. References..............................................................................................................................................4 1.5. Overview of Document..........................................................................................................................4 2.0. Overall Description....................................................................................................................................5 2.1 System Environment...............................................................................................................................5 2.2 Functional Requirements Specification..................................................................................................6 2.2.1 Reader Use Case..............................................................................................................................6 Use case: Search Article......................................................................................................................6 2.2.2 Author Use Case..............................................................................................................................7 Use case: Submit Article......................................................................................................................7 2.2.3 Reviewer Use Case..........................................................................................................................7 Use case: Submit Review....................................................................................................................7 2.2.4 Editor Use Cases..............................................................................................................................8 Use case: Update Author.....................................................................................................................9 Use case: Update Reviewer.................................................................................................................9 Use case: Update Article...................................................................................................................10 Use case: Receive Article..................................................................................................................11 Use case: Assign Reviewer................................................................................................................11 Use case: Receive Review.................................................................................................................12 Use case: Check Status......................................................................................................................12 Use case: Send Response...................................................................................................................13 Use case: Send Copyright..................................................................................................................13 Use case: Remove Article..................................................................................................................14 Use case: Publish Article...................................................................................................................15 2.3 User Characteristics..............................................................................................................................15 2.4 Non-Functional Requirements..............................................................................................................16 3.0. Requirements Specification.....................................................................................................................17 3.1 External Interface Requirements..........................................................................................................17 3.2 Detailed Non-Functional Requirements...............................................................................................17 3.2.1 Logical Structure of the Data.........................................................................................................17 3.3.2 Security..........................................................................................................................................27

List of Figures
Figure 1 - System Environment........................................................................................................................5 Figure 2 - Article Submission Process..............................................................................................................7 Figure 3 - Editor Use Cases..............................................................................................................................8

with whom all communication is made. Glossary Term Active Article Author Database Editor Field Historical Society The existing membership database (also HS database). sends articles for review. The system also contains a relational database containing a list of Authors. the location of these forms is configurable via the application’s maintenance options. Database Member A member of the Historical Society listed in the HS database. 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 interfaces of the system.1. Person who receives articles. Reader Anyone visiting the site to read articles. Scope of Project This software system will be a Online Book for a local editor of a regional historical society. Preformatted reply forms are used in every stage of the articles’ progress through the system to provide a uniform review process. A cell within a form. This system will be designed to maximize the editor’s productivity by providing tools to assist in automating the article review and publishing process. Reviewers. reviewers. . which would otherwise have to be performed manually. 1. this term refers to the principal author. Definition The document that is tracked by the system. More specifically. Purpose The purpose of this document is to present a detailed description of the “Online Book”. may include suggestions for improvement. The software will facilitate communication between authors. what the system will do. it is a narrative that is planned to be posted to the public website. 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. and the editor via EMail. the constraints under which it must operate and how the system will react to external stimuli.3. 1. Review A written recommendation about the appropriateness of an article for publication. Collection of all the information monitored by this system. and makes final judgments for publications. By maximizing the editor’s work efficiency and production the system will meet the editor’s needs while remaining easy to understand and use.Introduction 1.2. and Articles. In case of multiple authors. Person submitting an article to be reviewed. It will explain the purpose and features of the system.

but are intended for different audiences and thus use different language. A document that completely describes all of the functions of a proposed system and the constraints under which it must operate. 1. of this document gives an overview of the functionality of the product. this document. the Overall Description section. . The third chapter. For example. of this document is written primarily for the developers and describes in technical terms the details of the functionality of the product. Reviewer or Author. It describes the informal requirements and is used to establish a context for the technical requirements specification in the next chapter. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications.4. Overview of Document The next chapter.5. Both sections of the document describe the same software product in its entirety. References IEEE. 1998. 1.Reviewer Software Requirements Specification User 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. Requirements Specification section. IEEE Computer Society.

is an example of using domain classes to make an explanation clearer.1 System Environment Figure 1 . << The division of the Online Book into two component parts. Any Author or Reviewer communication with the system is through email. >> . the Online Journal and the Article Manager. Overall Description 2. or Reviewer accesses the Online Journal through the Internet. The Editor accesses the entire system directly.System Environment The Online Book has four active actors and one cooperating system.0. There is a link to the (existing) Historical Society. Reader.2. Custom er Author Online Book Article Manager Publicatio n Online Book MANAGER Courier The Author.

The system provides the requested article. Initial Step-By-Step Description Before this use case can be initiated. Xref: Section 3. the author and the reviewer have only one use case apiece while the editor is main actor in this system. The system displays the choices to the Reader. The Reader selects the article desired. 5. Search Article Rewrite Review Active Article Submit Publish . the Reader has already accessed the Online Journal Website. category.2. or keyword. searches for an article and downloads it to his/her machine.2 Functional Requirements Specification This section outlines the use cases for each of the active readers separately. The Reader chooses to search by author name. The reader. 1. 6.2. 4.1 Reader Use Case Use case: Search Article Diagram: Search Article Reader Brief Description The Reader accesses the Online Journal Website. The system presents the abstract of the article to the reader.1.2. The Reader chooses to download the article. 3. 2. 2.

The Author chooses the Email Editor button.2 Author Use Case In case of multiple authors. 2. Xref: Section 3. Use case: Submit Article Diagram: Submit Book Author Brief Description The author either submits an original article or resubmits an edited article. The Author fills in the Subject line and attaches the files as directed and emails them. 4. The System uses the sendto HTML tag to bring up the user’s email system.3 Reviewer Use Case Use case: Submit Review Diagram: . 1. 3. this term refers to the principal author. Communicate 2.2. The Reviewers return their comments. with whom all communication is made. An Author submits an article for consideration.2. When that form is returned. or the Author is asked to make some changes based on the reviews. the article is published to the Online Journal.Article Submission Process The Article Submission Process state-transition diagram summarizes the use cases listed below. which are used by the Editor to make a decision on the article. the Editor sends a copyright form to the Author. The Editor enters it into the system and assigns it to and sends it to at least three reviewers. Initial Step-By-Step Description Before this use case can be initiated. Either the article is accepted as written. declined. 2.Figure 2 .2.2. the Author has already connected to the Online Journal Website. If it is accepted. The System generates and sends an email acknowledgement. possibly after a revision . Not shown in the above is the removal of a declined article from the system.

The Reviewer chooses the Email Editor Button.Submit Book Customer Brief Description The reviewer submits a review of an article.4 Editor Use Cases The Editor has the following sets of use cases: Update Info Handle Art Status Editor Send Rec Publish Art Figure 3 . 2. The System generates and sends an email acknowledgement. 4.2. Communicate 2.2. 1. The System uses the send to HTML tag to bring up the user’s email system. the Reviewer has already connected to the Online Journal Website. The Reviewer fills in the Subject line and attaches the file as directed and emails it.2. 3. Xref: Section 3.Editor Use Cases Update Information use cases . Initial Step-By-Step Description Before this use case can be initiated.

4. Initial Step-By-Step Description Before this use case can be initiated. the system presents a list of authors to choose from and presents a grid filling in with the information. The Editor selects to Add/Update Author. 1. 2.2. Xref: Section 3.5 Update Person Use case: Update Reviewer Diagram: Update Reviewer MANAGER Editor Brief Description The Editor enters a new Reviewer or updates information about a current Reviewer. 5.Use case: Update Author Diagram: Update Author Editor Brief Description The Editor enters a new Author or updates information about a current Author. Initial Step-By-Step Description .2. If the Editor is updating an Author. The Editor chooses to add or to update. 3. The system verifies the information and returns the Editor to the Article Manager main page. Section 3. The Editor fills in the information and submits the form. 6.3. else the system presents a blank grid. Add Author. the Editor has already accessed the main page of the Article Manager. The system presents a choice of adding or updating.

Initial Step-By-Step Description Before this use case can be initiated. Update Article Status Handle Article use cases . The system presents the information about the chosen article. Section 3. The Editor fills in the information and submits the form. Add Reviewer.2. else the system presents list of members for the editor to select a Reviewer and presents a grid for the person selected.Before this use case can be initiated. Update Person Use case: Update Article Diagram: Update Article Editor Brief Description The Editor enters information about an existing article. 4. The system links to the Historical Society Database.5. the Editor has already accessed the main page of the Article Manager. 4. 1. The system presents a choice of adding or updating. the Editor has already accessed the main page of the Article Manager.2. 6.4. 2. the system and presents a grid with the information about the Reviewer. 7. The Editor chooses to add or to update. The system verifies the information and returns the Editor to the Article Manager main page. The Editor selects to Update Article. 1. The system presents s list of active articles. 3. If the Editor is updating a Reviewer. The Editor selects to Add/Update Reviewer. Xref: Section 3.2. 2. 5. Xref: Section 3. 3. The Editor updates and submits the form. The system verifies the information and returns the Editor to the Article Manager main page. 5.6.

the Editor has already accessed the main page of the Article Manager and has a file containing the article available. 3. The Editor chooses to add or to update. else the system presents a blank grid. The system presents a choice of entering a new article or updating an existing article. Xref: Section 3. 4. Initial Step-By-Step Description Before this use case can be initiated.Use case: Receive Article Diagram: Receive Article Editor Brief Description The Editor enters a new or revised article into the system. The Editor fills in the information and submits the form.7. Enter Communication Use case: Assign Reviewer This use case extends the Update Article use case. 6.2. . 1. 2. Diagram: Assign Reviewer CUSTOMER MANAGER Brief Description The Editor assigns one or more reviewers to an article. Initial Step-By-Step Description Before this use case can be initiated. If the Editor is updating an article. The system verifies the information and returns the Editor to the Article Manager main page. The Editor selects to Receive Article. 5. the system presents a list of articles to choose from and presents a grid for filling with the information. the Editor has already accessed the article using the Update Article use case.

The Editor fills in the information and submits the form. Diagram: Receive Review MANAGER Brief Description The Editor enters a review into the system.7. attaching the article and requesting that they do the review. The system presents a grid for filling with the information.1.8. The Editor selects a Reviewer. Xref: Section 3. Xref: Section 3. 2. The Editor selects to Receive Review.2. Enter Communication Check Status use case: Use case: Check Status Diagram: Check Status CUSTOMER . Assign Reviewer Use case: Receive Review This use case extends the Update Article use case. The system returns the Editor to the Update Article use case. 3. 4. 5. 1. The system verifies that the person is still an active member using the Historical Society Database. 4. The system emails the Reviewers.3 below). The Editor repeats steps 3 and 4 until sufficient reviewers are assigned. the Editor has already accessed the article using the Update Article use case. 2. The system presents a list of Reviewers with their status (see data description is section 3. The Editor selects to Assign Reviewer. 7. The system verifies the information and returns the Editor to the Article Manager main page. 6.2. 3. Initial Step-By-Step Description Before this use case can be initiated.

The Editor fills out the email text and sends the message. 1. Send Communication Use case: Send Copyright This use case extends the Update Article use case. Diagram: Send Response CUSTOMER Brief Description The Editor sends a response to an Author. Xref: Section 3. Check Status Send Recommendation use cases: Use case: Send Response This use case extends the Update Article use case. The system returns a scrollable list of all active articles with their status (see data description in section 3. . The system returns the Editor to the Article Manager main page. 3. Xref: Section 3. Initial Step-By-Step Description Before this use case can be initiated. The Editor selects to Check Status. 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. The Editor selects to Send Response.Brief Description The Editor checks the status of all active articles. the Editor has already accessed the main page of the Article Manager. 1. 2. the Editor has already accessed the article using the Update Article use case. Initial Step-By-Step Description Before this use case can be initiated.2. 2.9.3 below). The system returns the Editor to the Article Manager main page.210. 3. 4.

The Editor fills out the email text and sends the message. The Editor selects to remove an article from the active database. the name of the article on the subject line. 2. the Editor has already accessed the article using the Update Article use case. 3. The system provides a list of articles with the status of each. Initial Step-By-Step Description Before this use case can be initiated.10. 4. 1.2.Diagram: Send Copyright MANAGER Brief Description The Editor sends a copyright form to an Author. and attaches the copyright form. Send Communication Use case: Remove Article This use case extends the Update Article use case. The Editor selects to Send Copyright. . the Editor has already accessed the article using the Update Article use case. The system returns the Editor to the Article Manager main page. Diagram: Remove Article CUSTOMER Brief Description The Editor removes an article from the active category. Initial Step-By-Step Description Before this use case can be initiated. 1. 2. Xref: Section 3. The system calls the email system and puts the Author’s email address in the Recipient line.

The system removes the article from the active article database and returns the Editor to the Article Manager main page.12. the summary diagram only involves the Editor. 4. Xref: Section 3. Xref: Section 3. The Editor is expected to be Windows literate and to be able to use button. >> 2. pulldown menus. The main screen of the Online Journal Website will have the search function and a link to “Author/Reviewer Information. Adapt the rules to the needs of the document rather than adapt the document to fit the rules. Initial Step-By-Step Description Before this use case can be initiated.2. Remove Article Publish Article use case: Use case: Publish Article This use case extends the Update Article use case. 3. The Editor selects to Publish Article.” The Author and Reviewer are expected to be Internet literate and to be able to use email with attachments. The Editor selects an article for removal. the Editor has already accessed the article using the Update Article use case.3. 1. Publish Article << Since three of the actors only have one use case each.3 User Characteristics The Reader is expected to be Internet literate and be able to use a search engine. 2. and similar tools.2.11. . Diagram: Publish Article Editor Brief Description The Editor transfers an accepted article to the Online Journal. The system transfers the article to the Online Journal and updates the search information there. The system removes the article from the active article database and returns the Editor to the Article Manager home page.

2. The software developed here assumes the use of a tool such as Tomcat for connection between the Web pages and the database.4 Non-Functional Requirements The Online Journal will be on a server with high speed Internet capability. The speed of the Reader’s connection will depend on the hardware used rather than characteristics of this system. The physical machine to be used will be determined by the Historical Society. Access is already installed on this computer and is a Windows operating system.2 below. The Article Manager will run on the editor’s PC and will contain an Access database. .The detailed look of these pages is discussed in section 3.

1 Detailed Non-Functional Requirements Logical Structure of the Data The logical structure of the data to be stored in the internal Article Manager database is given below. membership numbers and (optional) email addresses when adding a new Reviewer.2. The Update Reviewer use case requests a list of member names. then the customer is asked to Enter the full detail of the book for procurement of the book by the bookshop. 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. It returns a Boolean for membership status when updating a Reviewer. the query for the book is used to increment a request field for the book. The Assign Reviewer use case sends the Reviewer ID to the HS Database and a Boolean is returned denoting membership status.2 . 3. 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. .2. the exact number of copies available and the rack number in which the book is located should be displayed. • If a book in stock. • If a book not in the stock.3.Functional Requirement: • BAS should help the customers query whether a book in a stock the user can query the availability of a book either by using the book title or by using the name of author. • If the book is not currently sold by the bookshop. The HS Database fields of interest to the Web Publishing Systems are member’s name.2 3. Requirements Specification 3. so that he can be intimated automatically by the software as and when the book copy received.0. membership (ID) number. • The customer can also provide his e-mail address and mobile. and email address (an optional field for the HS Database).

• Everyday the bookshop owner would give a command for BAS to print the book which have fallen below the threshold and the number of copies to be procured with the full address of the publisher. • The inventory level required for a book is equal to the number of copies of the book sold over a period of one week multiplied by the average number of weeks it takes to procure the book from its publisher. number of copies sold and the sales revenue) for any period. the sale clerk would enter the ISBN number of the books. The sales statistics will help the owner to know the exact business done over any period of time and also determine the inventory level required for various books. • BAS should allow employees to update inventory whenever new supply arrives. ISBN number. BAS should update the stock and generate the sales receipt for the book. • • BAS should generate sales statistics (viz. .• The manager can periodically view the request field of the book arrive at a rough estimate regarding the current demand for different books. As soon as customer selects his book for purchase. • • BAS should maintain the price of various books. publisher. Also upon request by the owner of book shop. book name.

NET VERSION : Visual Studio 2008 . Dot Matrix / Ink Jet Color HARD DISC SPACE : PRINTER MONITOR : : SOFTWARE REQUIRMENT: OPERATING SYSTEM : 2000 / XP/Vista.3 Hardware Requirement: HARDWARE REQUIREMENT      PROCESSOR RAM : : Pentium IV & Above. 40 GB & above.2. And all above (but Must be Microsoft Os) VISUAL BASIC .3. 1 GB & Above.

Design (validation). construction. The life cycle model demands a Systematic sequential approach to software development that begins at the system level and progress through analysis design coding. in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception initiation. Begins by establishing requirement for all system elements and Then allocating some subset of these requirement to the software system Engineering and analysis encompasses the requirement gathering at the system level with a small amount of top level design and analysis.Classic life cycle model is also known as WATER FALL MODEL. The Classic Life Cycle Model The waterfall model is sequential software development process. Testing and maintained.Software Life Cycle Model: In order to make this Project we are going to use Classic LIFE CYCLE MODEL . testing and maintenance. 1) System Engineering and Analysis:- Because software is always a part of larger system work. Analysis. .

. The coding step performs this task.Requirement for the both system and software are discussed and reviewed with the customer. procedural detail and interface of the software that can be assessed or quality before coding begins . The customer specifies the entire requirement or the software and the function to be performed by the software. If design is programmed in a detailed manner. 3) Design: Software design is actually a multi-step process that focuses on distinct attributes of the program data structure. software architecture. 5) Testing: Once code has been generated programmed testing begins. 4) Coding: The design must be translated into a machine readable form. coding can be accomplished mechanically. The testing process focuses on the internals of the software ensuring that all statement have been tested and on the functional externals hat is conducting tests to uncover the errors and ensure that defined input will produce the results that agree with the required results.Like requirement the design is documented and becomes part of the software.2) Software requirement Analysis: = The requirement gathering process is intensified and focused specifically on the software .

the smallest Unit is a class. Unit testing is software Verification and validation method where the programmer gains confidence that individual units of source code are fit to use A unit is the smallest testable part of an application. while in objectoriented programming. Developers looking to learn what functionality is provided by a unit and how to use it can look at the tests to gain a basic understanding of the unit API. The classic life cycle is the oldest and most widely used paradigm or software engineering .Unit testing:In computer programming. Limitation of unit testing: Testing cannot be expected to catch error in the program –It is impossible to evaluate all execution paths for all but the most trivial programs. 6) Maintenance: Software will undoubtedly undergo change after it is Delivered to the customer .Change will occur because errors have been encountered because the software must be able adopted to accommodate changes in its external environment because the customer requires functional or performance enhancement enhancements. Additionally. The same is true for unit testing. procedure. In procedural programming a unit may be an individual programmed. which may belong to a base/super class abstract class or derived/child class. by unit testing only types the functionality if the units themselves. A unit test provides a strict written contract that the piece of code must satisfy. Benefits: The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. Documentation:Unit testing provides a sort of living documentation of the system. function. etc.

Conclusion: • Using this project “Online Book Shop”. Now. • . it can be done using this software and hence. it reduces the manual work of submitting the infrastructure related complains. it makes the employee’s work easier and comfortable.

DFD .

First Level DFD .

.

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 ERD .2 Security The server on which the Online Journal resides will have its own security to prevent unauthorized write/delete access. Only the Editor will have physical access to the machine and the program on it. The use of email by an Author or Reviewer is on the client systems and thus is external to the system.he Logical Structure of the data to be stored in the Online Journal database on the server is as follows: Published Article Entity 3. There is no restriction on read access.3. The PC on which the Article Manager resides will have its own security.

Sign up to vote on this title
UsefulNot useful