TCS 422

IMPLEMENTATION OF DATA STRUCTURES USING

GRAPHICS

BY

Ridhi Gupta
Ruchi Jain
Shruti Jain
Software Requirements Specification

Document

Version: (1.1) Date :( 24/10/2008)

Table of Contents

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Overview
2. The Overall Description
2.1 Product Perspective
2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions and Dependencies

3. Specific Requirements
3.1 External interfaces
3.2 Functions
3.3 Performance Requirements

3.4 Design Constraints

4. Future Extensions
1. Introduction

1.1 Purpose

This SRS document deals with the development of project based on

the topic "implementation of data structures using graphics" to
provide the better knowledge about the data structures.

This document is meant to delineate the features of the project, so

as to serve as a guide to the developers on one hand and a
software validation document for the prospective client on the
other.

1.2 Scope

This software will provide people in any country, at any

location to understand the concept of data structures very
easily. They can have a visual knowledge and the capability
to implement data structures more easily.

This software will provide quick and easy access to the user.
It will save the user's time and money to understand the
concepts.

1.3 Definitions, Acronyms, and Abbreviations

The software will contain following abbreviations:-

1. SRS- Software Requirements Specification

2. Info- Information
3. WWW-World Wide Web
4. GUI- Graphical User Interface
1.4 References

1. Book used for database design: - ORACLE 10G, Norton

Andrews
2. This document is designed on basis of SRS recommended by
IEEE, downloaded from http//:www.ieee.org/

1.5 Overview

This software will automize all the activity related to the

implementation of data structures using graphics. This will
automatically implement the data structures according to the
users input. It will automatically draw the data structures
and perform their respective operations.

It will be user friendly software which will interact with the

user and will perform the actions entered by the user.

The rest of this SRS is organized as follows:-

Section 2 gives an overall description of the software. It

gives what level of proficiency is expected of the user, some
general constraints while making the software and some
assumptions and dependencies that are assumed.

Section 3 gives specific requirements which the software is

expected to deliver. Functional requirements are given by
various use cases. Some performance requirements and
design constraints are also given.

Section 4 gives some possible future extensions of the system.

2. The Overall Description

2.1 Product Perspective

The product is independent and totally self-contained. It aims

to the person who wants a better grasp of the data structures
and who is having a problem in understanding the concepts
of data structures. It will provide a visual implementation of
the subject and thus the user will be able to solve the
problems more efficiently.

This software is aimed towards a person who has

considerable number of problems in understanding the
concepts of data structures, and so needs software for visual
implementation of the same for a better understanding. It is
user friendly, 'quick to learn' and reliable software for the
above purpose.

It will run on any operating system which supports the

“TURBO C ".

2.2 Product Functions

CLASS OF USE CASE DESCRIPTION

USE CASE OF USE CASE

Linked List Void add() Describe to add

the node
Void add(int Describe to add after
x) which node
Void add(char Describe whether we
 end) can add more nodes or
not
Void del() Describe the process to
delete the nodes

Stack1 Public int Describe process of

create() creation of stack
Public Void Describe the push
push1() operation
Public Void Describe the pop
pop1() operation
Inline int Tells if the stack is full
is_full() for push
Inline int Tells if the stack is
is_empty() empty for pop

Queue1 Public Void Describe the process to

add() add the element
Public Void Describe the process to
del() delelte the element
Public int Describe the process to
create() create the queue
Inline int Tells if queue is full for
isfull() further addition
Inline int Tells if queue is empty
isempty() for deletion
It provides a summary of the major functions that the software will
perform.

For clarity:
1)The functions are organized in a way that makes the list of functions
understandable to the customer or to anyone else reading the
document for the first time.

The functionality of the system is described in the language of the

customer.

2.3 User Characteristics

1. User should be familiar with the terminology like push, pop.

2. User should know the basic details.

2.4 Constraints
Here we provide a general description of any other items that will
limit the developer's options.
These can include:

1) It is single-user software.
2) It is fully secured and safe.

2.5 Assumptions and Dependencies

1) Full working of this project depends on the availability of

“TURBO C”.
2) The working of the project requires the understanding of
using the keyboard.
3) This project does not require the usage of mouse.
 This section is catch-all for everything else that might influence the
design of the system and that did not fit in any of the categories above.
These factors are not design constraints on the software but are,
rather, any changes to them that can affect the requirements in the
SRS. If, in fact, the operating system were not available, the SRS would
then have to change accordingly.

3. Specific Requirements

This section contains all the software requirements at a level of

detail sufficient to enable designers to design a system to satisfy
those requirements, and testers to test that the system satisfies those
requirements. Throughout this section, every stated requirement is
made to be externally perceivable by users, operators, or other
external systems. These requirements include at a minimum a
description of every input (stimulus) into the system, every output
(response) from the system and all functions performed by the system
in response to an input or in support of an output.

Before examining specific ways of organizing the requirements, it is

helpful to understand the various items that comprise requirements
as described in the following subclasses.

This section reiterates section 2, but is for developers not the

customer.

3.1 External Interfaces

This contains a detailed description of all inputs into and outputs

from the software system. It complements the interface
descriptions in section 2 but does not repeat information here.
Remember section 2 presents information oriented to the
customer/user while section 3 is oriented to the developer.
 It displays the screen or the output which has follows:

• Screen 1
♦ It contains the introduction or the heading of the software.
♦ To move to second screen enter is pressed.

• Screen 2
♦ Asks the user to enter the choice amongst the options of
“Linked List”, “Queue”, “Stack”, or “Exit”.
♦ It takes the input in the form of numbers.

• Screen 3
♦ It depends on the input of screen 2.
♦ Accordingly it asks for the various operations of the
chosen data structure.
♦ Along with the options of the operations it also has the
option for the exit to the screen 2.

• Screen 4
♦ It gives the information of the team members who
completed this project.

3.2 Functions

Functional requirements define the fundamental actions that must

take place in the software in accepting and processing the inputs
and in processing and generating the outputs.
So,
We describe the functional requirements by giving various use
cases.

Use case related to installation:

Use Case1: Installation

Primary actor: User

Pre Condition: User should have the executable file.
Main Scenario:
1. User initiates the installation program.
2. System provides with the screen 1 and waits for any key
to be pressed.

Use case 2: Main Menu

Primary Actor: User

Pre Condition: User is in executable file.
Main Scenario:
1. Main menu is shown.
2. Asks the user for the input.
3. Takes the input in the form of numbers.

Use Case 3: Stack

Primary Actor: User

Pre Condition: User chooses “stack implementation”.
Main Scenario:
1. Various operations of stack are listed.
a. Create a Stack of up to 10 size.
b. Push elements until the size defined in
above step.
c. Pop elements according LIFO(Last In First
Out) manner.
2. Exit to main menu option returns to the main menu
Use Case 4: Queue

Primary Actor: User

Pre Condition: User chooses “Queue implementation”.
Main Scenario:
1. Various operations of queue are listed
a. Create a queue.
b. Insert the element in queue to the size defined.
c. Delete elements according to FIFO (First In First Out)
manner.
2. Exit to main menu option returns to the main menu.

Use Case 5: Linked List

Primary Actor: User

Pre Condition: User chooses “Linked List implementation”.
Main Scenario:
1. Various operations of linked list are listed.
a. Create linked list.
b. Add a node after a certain node.
c. Add a node in between two nodes.
d. Deletes the node by specifying the value of node.
2. Exit to main menu option returns to the main menu.

Use Case 6: Exit

Primary Actor: User

Pre Condition: User chooses “Exit”.
Main scenario:
1. The screen 4 is displayed.
2. It contains the information of the team members.
 3.3 Performance Requirements

This subsection specifies both the static and the dynamic

numerical requirements placed on the software or on human
interaction with the software, as a whole.

1. Should run on 1.60GHz, 1 GB machine.

2. 90% of the responses should be within 1 minute, except for
some exceptions.

3.4 Design Constraints

Specifies design constraints that can be imposed by other

standards, hardware limitations, etc.

1. Security: The file should be secured against the malicious

deformations.
2. Fault Tolerance: Data should not become corrupted in case of
system crash or power failure.

4.Future Extensions

It is single user software. The future possibilities would be to make it

multi user and to introduce more data structures for better
understandability.