28-08-2014, 12:35 PM
ONLINE MUSIC STORE
[attachment=67234]
INTRODUCTION
1.1 PURPOSE:
The purpose of this SRS document is to provide an overview of the system we are building. The
aim is to state the identified requirements and functionalities for our SURIL MUSICALS’ ONLINE
MUSIC STORE project and document them so that we can build upon this information. The SRS
is thus, in a way our parent document because all subsequent project management and
control documents, such as design documents – both Systems design and Detailed design,
statements of work, software architecture specifications, testing and validation plans, and
documentation plans, are related to it. A crucial point, which needs to be stated here, is that
this SRS contains only functional and nonfunctional requirements. It doesn't offer design
suggestions, possible solutions to other related issues, or any other information other than
what the development team understands the customer's system requirements to be. This
document also makes note of the requirements, which we plan to implement which are not
mandatory for the functioning of the product.
The main motive of coming up with SRS is that it provides a contract between client and
developers that they share same understanding of what is required, what needs to be done
and what will be finally delivered. The document aims at guiding the developers in every stage
of the Software Development Cycle. The specifications set forth in the document also provide
a point of reference to the developers. The client side is also aided in keeping track of the
project progress.
CONSTRAINTS:
An efficient trade-off must be achieved between a pool of exciting features and the
response time of the server.
Lack of availability of abundant web space, which compels the designers to
compromise on much of the functionalities.
Only some of the team members are well versed with PHP and HTML, so other
members should spend some quality time in learning those languages.
Rational Requisite Pro for developing Software Requirements Specification.
SOFTWARE LIMITATIONS:
Java and JavaScript enabled web browser like Internet Explorer 6 +, Mozilla Firefox
1.0+ etc.
DATABASE USED:
MySql Database
SAFETY AND SECURITY CONSTRAINTS:
As at the time of placing an order user is required to enter critical data like the credit card
numbers and personal details, so we will consider the following constraints:
User will have a Username (LoginID) and a Password for logging in to the system.
Session maintain for the transaction process at the time of placing an order.
The system should be secure to threats like hacking and viruses to the highest degree
possible.
Conclusion:
Looking back at the features that the client expects out of the website, we narrowed them
down to the following:
An online display of products, every kind, every brand. 40 | P a g e
Any new product would be “updated” and placed in a section like “New!”
The online shopping cart concept which helps in adding stuff “to the cart”, remove
“from the cart”, etc.
Payment of purchased products online, through any online payment scheme.
As the client mentioned that the customer would want to inquire/clarify about a
product, or obtain guidance regarding anything, we came up with the concept of a
“Discussion Forum” which would be a thread of messages, both by registered users of
the website and the owner. The forum would help in mingling of ideas as well, and
prove to be beneficial to the owner also.
A feature called “Jam Room Booking” could also be introduced, which would mark the
date and time of a particular slot in the day, so that people wanting to use the room,
can maintain a proper queue, and use it only at the time asserted by them, instead of
clogging the room.
[attachment=67234]
INTRODUCTION
1.1 PURPOSE:
The purpose of this SRS document is to provide an overview of the system we are building. The
aim is to state the identified requirements and functionalities for our SURIL MUSICALS’ ONLINE
MUSIC STORE project and document them so that we can build upon this information. The SRS
is thus, in a way our parent document because all subsequent project management and
control documents, such as design documents – both Systems design and Detailed design,
statements of work, software architecture specifications, testing and validation plans, and
documentation plans, are related to it. A crucial point, which needs to be stated here, is that
this SRS contains only functional and nonfunctional requirements. It doesn't offer design
suggestions, possible solutions to other related issues, or any other information other than
what the development team understands the customer's system requirements to be. This
document also makes note of the requirements, which we plan to implement which are not
mandatory for the functioning of the product.
The main motive of coming up with SRS is that it provides a contract between client and
developers that they share same understanding of what is required, what needs to be done
and what will be finally delivered. The document aims at guiding the developers in every stage
of the Software Development Cycle. The specifications set forth in the document also provide
a point of reference to the developers. The client side is also aided in keeping track of the
project progress.
CONSTRAINTS:
An efficient trade-off must be achieved between a pool of exciting features and the
response time of the server.
Lack of availability of abundant web space, which compels the designers to
compromise on much of the functionalities.
Only some of the team members are well versed with PHP and HTML, so other
members should spend some quality time in learning those languages.
Rational Requisite Pro for developing Software Requirements Specification.
SOFTWARE LIMITATIONS:
Java and JavaScript enabled web browser like Internet Explorer 6 +, Mozilla Firefox
1.0+ etc.
DATABASE USED:
MySql Database
SAFETY AND SECURITY CONSTRAINTS:
As at the time of placing an order user is required to enter critical data like the credit card
numbers and personal details, so we will consider the following constraints:
User will have a Username (LoginID) and a Password for logging in to the system.
Session maintain for the transaction process at the time of placing an order.
The system should be secure to threats like hacking and viruses to the highest degree
possible.
Conclusion:
Looking back at the features that the client expects out of the website, we narrowed them
down to the following:
An online display of products, every kind, every brand. 40 | P a g e
Any new product would be “updated” and placed in a section like “New!”
The online shopping cart concept which helps in adding stuff “to the cart”, remove
“from the cart”, etc.
Payment of purchased products online, through any online payment scheme.
As the client mentioned that the customer would want to inquire/clarify about a
product, or obtain guidance regarding anything, we came up with the concept of a
“Discussion Forum” which would be a thread of messages, both by registered users of
the website and the owner. The forum would help in mingling of ideas as well, and
prove to be beneficial to the owner also.
A feature called “Jam Room Booking” could also be introduced, which would mark the
date and time of a particular slot in the day, so that people wanting to use the room,
can maintain a proper queue, and use it only at the time asserted by them, instead of
clogging the room.