Software Requirements Specification April 15, 2012 Telephone Directory Nishchhal Srivastva Vasanthi Kakarla Kanika Kanwar Uday

Veer Singh J.Gayathri 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 2012 CS 310.

Table of Contents
Table of Contents...............................................................................................................................................i List of Figures...................................................................................................................................................ii 1.0. Introduction...............................................................................................................................................ii 1.1. Purpose..................................................................................................................................................ii 1.2. Scope of Project.....................................................................................................................................ii 1.3. Glossary................................................................................................................................................iii 1.4. References............................................................................................................................................iii 1.5. Overview of Document........................................................................................................................iv 2.0. Overall Description....................................................................................................................................1 2.1 System Environment ...............................................................................................................................1 2.2 Functional Requirements Specification..................................................................................................1 2.2.1 User Use Case..................................................................................................................................1 Use case: Search Contact.....................................................................................................................1 2.2.2 .........................................................................................................................................................2 Use case: Add contact ...........................................................................................................................2 2.2.3 .........................................................................................................................................................3 Use case: delete contact........................................................................................................................3 2.2.4 User Use Cases................................................................................................................................3 Use case: Update contact.....................................................................................................................4 2.3 User Characteristics................................................................................................................................5 2.4 Non-Functional Requirements ..............................................................................................................5 The system is user friendly which makes user easy to use the system, interact with the System by using the GUI 3.0. Requirements Specification.......................................................................................................................5 3.1 Functional Requirements........................................................................................................................5 3.2.1 Search Contact.................................................................................................................................5 3.2.3 Add Contact....................................................................................................................................6 3.2.4 Delete Contact................................................................................................................................6 3.2.5 Update Contact................................................................................................................................7 3.3 Detailed Non-Functional Requirements.................................................................................................8 3.3.1 Logical Structure of the Data...........................................................................................................8 3.3.2 Security............................................................................................................................................9

List of Figures
Figure 1 - System Environment........................................................................................................................1 Figure 2 Contact search Process....................................................................................................................2 Figure 3 - Use Cases.........................................................................................................................................4 Figure 4 - Logical Structure of the Article Manager Data................................................................................8

1.0. Introduction
1.1. Purpose The purpose of this document is to present a detailed description of the telephone directory application 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. 1.2. Scope of Project The project is an application of telephone directory system that manages contacts information in well and efficient manner. This system will be designed to maximize the users productivity by providing tools that is totally GUI based and menu driven which would otherwise have to be performed with more complexity. By maximizing the users work efficiency the system will meet the users needs while remaining easy to understand and use. More specifically, this system is designed to allow a user to save, retrieve, delete, update, search the contact information as required by the user. The options are available in interactive manner which a user can choose accordingly which is just a click away. The system also contains files containing a list of name, address, email-id, phone no.

ii

1.3. Glossary Term Active Article Author Database Editor Field Historical Society Database Member Reader Review Reviewer Software Requirements Specification Stakeholder User 1.4. References IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society, 1998. 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, 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 improvement. 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. 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.

iii

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.

iv

2.0.Overall Description
2.1 System Environment

Figure 1 - System Environment

The Telephone directory system has four active actors and one cooperating system. . The User 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 user is main actor in this system. 2.2.1 User Use Case Use case: Search Contact Diagram:

Search contact

SRS V 1.0user

April 15, 2012

Brief Description The Reader accesses the telephone directory and searches for an contact Initial Step-By-Step Description Before this use case can be initiated, the user has already accessed the telephone directory 1. The user selects the option icon on the GUI screen 2. On selecting the option icon a drop down menu is displayed 3. Select the search option from the drop down 4. The user enter the keyword of name attribute of the contact that has be searched. 5. The system displays the names of the person which have the given keyword to the user. 6. The user selects the contact of the person desires from the displayed results. 7. The system the displays the contact of the selected person on the screen. Xref: Section 3.2.1, Search contact

Figure 2 Contact search Process

The Contact search process state-transition diagram summarizes the use cases listed below. A user submits an search keyword for searching. The user enters it into the system and then the search starts retrieving contact information from the database. The system then displays many contacts whose name is similar match to the entered keyword. The user then selects one among many results available on the screen then the system displays the total contact information of that particular person which are retrieved from the database. 2.2.2 Use case: Add contact Diagram:

Add contact

user

SRS V 1.0

April 15, 2012

Brief Description The user submits the details and information of the new contact and adds it to the file. Initial Step-By-Step Description Before this use case can be initiated, the user has already access to the telephone directory. The user selects the option icon on the GUI screen 9. On selecting the option icon a drop down menu is displayed 10. Select the add option from the drop down 11. Enter the details of the persons contact information into the input fields. 12. Click on the add button and then the contact details are added to the file. 13. And a message is displayed on the screen to tell the successfully the operation was performed.
8.

Xref: Section 3.2.2, Communicate 2.2.3 Use case: delete contact Diagram:

Delete contact

user

Brief Description The user deletes the contact from the file database. Initial Step-By-Step Description Before this use case can be initiated, the user has already access to the system. 1. The user selects the option icon on the GUI screen 2. On selecting the option icon a drop down menu is displayed. 3. Select the delete option from the drop down menu. 4. The user enter the keyword of name attribute of the contact that has to be searched. 5. The system displays the names of the person which have the given keyword to the user. 6. The user selects the contact of the person desired to be deleted from the displayed results. 7. The system deletes the contact of the person and displays a success message on the screen. 2.2.4 User Use Cases The User has the following sets of use cases:

SRS V 1.0

April 15, 2012

user

Figure 3 - Use Cases

2.2.4 Update Information use cases Use case: Update contact Diagram:

Update contact

user

Brief Description The user enters a new contact information . Initial Step-By-Step Description Before this use case can be initiated, the user has already accessed the system. 1. The user selects the option icon on the GUI screen 2. On selecting the option icon a drop down menu is displayed. 3. Select the update option from the drop down menu. 4. The user enters the keyword of name attribute of the contact that has to be searched. 5. The system displays the names of the person which have the given keyword to the user. 6. The user selects the contact of the person desired to be updated from the displayed results. 7. The system updates the contact of the person and displays a success message on the screen.

SRS V 1.0

April 15, 2012

2.3

User Characteristics The user is expected to select an option (which action he desires to perform) among

many available from the drop down on the screen. The user also needs to provide the system with appropriate information to the system. 2.4 Non-Functional Requirements The user will run on the PC and will contain an Access database. Access is already installed on this computer and is a Windows operating system. The system is user friendly which makes user easy to use the system, interact with the System by using the GUI

3.0.
3.1

Requirements Specification

Functional Requirements The Logical Structure of the Data is contained in Section 3.3.1.

3.2.1 Search Contact

Use Case Name XRef Trigger Precondition Basic Path Search Contact Section 2.2.1, Search contact The User assesses the system The Screen is displayed using menu driven displays 1. The user selects the option icon on the GUI screen 2. On selecting the option icon a drop down menu is displayed 3. Select the search option from the drop down 4. The user enter the keyword of name attribute of the contact that has be searched. 5. The system displays the names of the person which have the given keyword to the user. 6. The user selects the contact of the person desires from the displayed results. 7. The system the displays the contact of the selected person on the screen. The required contact is displayed on the screen.

Post condition

SRS V 1.0

April 15, 2012

Exception Paths Other

The User may abandon the search at any time. The resultant contact list is generated from the information provided by predefined in the file database.

3.2.3 Add Contact

Use Case Name XRef Trigger Precondition Basic Path Add Contact Section 2.2.2, add contact The User selects to add a new contact to the database. The User has accessed the Telephone directory on the main screen. 1. The user selects the option icon on the GUI screen 2. On selecting the option icon a drop down menu is displayed 3. Select the add option from the drop down 4. Enter the details of the persons contact information into the input fields. 5. Click on the add button and then the contact details are added to the file. 6. And a message is displayed on the screen to tell the successfully the operation was performed. If in step 3, either field is blank, the User is instructed to add an entry. No validation for correctness is made. The contact has been added to the database. The User may abandon the operation at any time. The contact information includes the name mailing address and email address.

Alternative Paths Postcondition Exception Paths Other

3.2.4 Delete Contact

Use Case Name XRef Trigger Precondition Basic Path Delete contact Section 2.2.3, delete contact The User selects to delete a contact from the database. The user has accessed the Telephone directory on the main screen. 1.The user selects the option icon on the GUI screen 2. On selecting the option icon a drop down menu is displayed. 3. Select the delete option from the drop down menu. 4. The user enter the keyword of name attribute of the contact that has to be searched. 5. The system displays the names of the person which have the given keyword to the user. 6. The user selects the contact of the person desired to be deleted from the displayed results. 7. The system deletes the contact of the person and displays a
6 April 15, 2012

SRS V 1.0

Alternative Paths Postcondition Exception Paths Other

success message on the screen. . In step 3, if there is no entry for the contact in the HS database , the user will be re prompted for an entry. The contact has been deleted from the database. The user may abandon the operation at any time. The contact information includes name, mailing address, and email address.

3.2.5 Update Contact

Use Case Name XRef Trigger Precondition Basic Path Update contact Sec 2.2.4 update contact The User selects to update a contact that is already in the database. The user has accessed the telephone directory on the main screen. 1. The user selects the option icon on the GUI screen 2. On selecting the option icon a drop down menu is displayed. 3. Select the update option from the drop down menu. 4. The user enters the keyword of name attribute of the contact that has to be searched. 5. The system displays the names of the person which have the given keyword to the user. 6. The user selects the contact of the person desired to be updated from the displayed results. 7.enter the new information for the contact in the entry fields and select update option. 8. The system updates the contact of the person and displays a success message on the screen. In step 5, if any required field is blank, the user is instructed to add an entry. No validation for correctness is made. The database has been updated. If the contact is not already in the database, the use case is abandoned. In addition, the user may abandon the operation at any time. This use case is not used when one of the other use cases is more appropriate, such as to add a contact.

Alternative Paths Postcondition Exception Paths Other

SRS V 1.0

April 15, 2012

3.3 3.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.

Figure 4 - Logical Structure of the Article Manager Data

The data descriptions of each of these data entities is as follows: Author Data Entity Data Item Type Name Text Email Address Text Article Pointer Description Name of principle author Internet address Article entity Comment May be several

SRS V 1.0

April 15, 2012

Contact Data Entity Data Item Type Name Text ID Integer Email Address Text Mailing address pointer P_no Integer

Description Name of any person ID number of Historical Society member Internet address Address of the person Phone number of the person

Comment Used as key in Historical Society Database May be several

3.3.2

Security

The PC on which the Telephone directory resides will have its own security. Only the User 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 user with write access to the contact database.

SRS V 1.0

April 15, 2012

SRS V 1.0

10

April 15, 2012