Software Requirements Specification

for

CLUBHUB
Version 1.0 approved

Prepared by Sanjit Verma

Clun Hub society

5th September 2019

Software Requirements Specification for ClubHub Page iii

Table of Contents
Table of Contents ......................................................................................................................... iii
Revision History ............................................................................... Error! Bookmark not defined.
1. Introduction ................................................................................................................................
1.1 Project Details ....................................................................................................................................
1.2 Purpose...............................................................................................................................................
1.3 Product Scope ....................................................................................................................................
1.4 Objective ............................................................................................................................................
1.5 References ..........................................................................................................................................
2. About the System .......................................................................................................................
2.1 SRS
~ Product Precpective
~ Product Function
~ User Classes and Characteristics
~Other Non - funtional req.
2.2 Feasibility Study
2.3 Project Plan ........................................................................................................................................
3. Analysis .......................................................................................................................................
3.1 Technology And Analysis..................................................................................................................
3.2 Hardware Interfaces ...........................................................................................................................
3.3 Software
Interfaces ....................................................................................................................................................

4. Design ..........................................................................................................................................
4.1 E-R Diagram ......................................................................................................................................
4.2 Dataflow Diagram..............................................................................................................................
4.3 Use Case Diagram..............................................................................................................................
4.4 Activity Diagram …………………………………………………………………………………………………………………………….

4.5 Class Diagram………………………………………………………………………………………………………………………………..

4.6 Sequence Diagram…………………………………………………………………………………………………………………………

4.7 User interface……………………………………………………………………………………………………………………………….

5. Testing .........................................................................................................................................
5.1 Testing Plan .......................................................................................................................................
5.2 Testing Strategy .................................................................................................................................
5.3 Testing
Methods......................................................................................................................................................

6. Conclusion And Future Work ..................................................................................................

Software Requirements Specification for ClubHub Page iv
Ch. 1: Introduction:
1.1Project detail:
1.1.1Definition:
 The definition of the project is College Technical Event Scheduling and
Organization. This application leads for the handling and formation of the event and
its schedule plus there payments.
1.1.2 Project Profile:

ClubHub.
Name of Project:
The Application generally relates to a system and method
to schedule events, and more particularly, to a system and
Object
method for scheduling technical events among entities such
Description:
as organization.
OS: Android , IOS
Front End: Android version 5.0
Back End: Firebase (google paid service)
Methodology: Object Oriented Development
Android studio
Android Virtual Device(AVD)
Support Tools Used: Microsoft Office 2016

Time Duration: 3 Months

1.2 Purpose:
The purpose of making this application is to provide a easiness of finding the event
schedule at one place plus the user can easily communicate with team leaders and can also
make payments directly to the respective club’s account with UPI integration present in our
app . The user will find the technical event schedule in one application rather to visit different
web pages. The invention satisfies the foregoing needs and avoids the drawbacks and

1
limitations and frustrations of the prior art, and provides a better, more timely and effective
process of communication to schedule and coordinate events by utilizing our app. The people
may get fail to answer the call or would be unable to check the email so this Application will
lead a better communication of the people about the event.
1.3Project Scope:
The scope of the project includes creating a user interface to Android system as well as
a backend that will emulate some of its behaviour, specifically for testing. Event
management is the application of management to the creation and development of
Technical festivals, events and conference.
The Application generally relates to a system and method to schedule events, and more
particularly, to a system and method for scheduling technical events among entities such
as organization that may have limitations for scheduling, such as constraints by timing,
conflicts, availability, or other factors.
This Application provides the user especially students the reliability in finding the
schedule of events at one place rather to go for each of the college websites and our
application also allows then to talk to leaders of respectable clubs. The college will just have
to post the event in .pdf file and that will be downloaded by students. By this Application the
matter of time which go in informing each other for the event will also be solved out.
1.4Objectives:
The people sending mail or message of technical event to other is wasting of time and
memory and involvement of money in the form of cash arise confusion and conflicts ,but our
application will solve this problem too . To overcome this problem our invention provides a
medium where one can get the schedule of an event by just opening our application with the
internet connection and refreshing it.Another thing our Application provides is all in one
characteristic. i.e. all technical event schedule in just one application.

Ch. 2: About the System:

2.1 Software Requirement Specification
 Introduction:
This Software Requirements Specification (SRS) document is intended to give a
complete overview of ClubHub(working title), including the user interface , Event
organization and payments methods .

 Product Perspective

2
 This product and application is newer which provides the user a new utility in their
role as a student or Club leader. We give this application to the college so they can post
their upcoming events in the database. The other person who will use this application
will be student they will get the details of the upcoming technical events by just logging
to the application and downloading the desired event details.
 Product Features
Functionality
The invention satisfies the foregoing needs and avoids the drawbacks and
limitations and frustrations of the prior methods, and provides a better, more timely
and effective process of communication to schedule and coordinate events by
utilizing application.
This product contains three major Users. First the admin will allow the user for
accessing this application by giving the permission rights and access control. Second
The college login will have a right to see the events listing and they can post their
new schedule of a technical event as well. And third The End User i.e. Student, they
can see the list of the events and schedule of event.
 User Classes and Characteristics
Admin
The Admin will have all the access to this product. The Admin will provide the
access permission to the users which are students and Colleges. The admin can also
delete or discard the unwanted events reported as spam. They also manage the
database like deleting the past events.

College
The college admin will be the second admin to this product, but with less access
control. The college admin will be provided the access the database like to add event
in .pdf format and to delete event. The college admin will be logged in using their id
and password provided.
Student
The student are the end-user entity, they will be having the access rights to see
the event schedule by pdf format. And register their new account providing their basic
details.
 Other Non-Functional Requirements
Performance Requirements

3
 Better performance will lead to better operating environment. For better
environment the user needs a high speed internet so that the upload and download
will be done better.
Security Requirements
The login details must be kept confidential so that other user may not login using
other's id and password. Especially the college login details must be kept confidential
so that other user may not post a fake event schedule.
2.2Feasibility Study
 Feasibility Analysis:
 A feasibility study is a short focused, which aims to answer a number of questions:
 Does the system contribute to the overall objective of the organization?
 Can the system be implemented using the current technology and within given cost
and schedule constraints?
 Can the system be integrated with system which is already in place?
 Economic Feasibility:
 The project is economically feasible as it only requires a mobile phone with Android
operating system.
 The application is free to download once released for student and payable for college
into Android market.
 The users should be able to connect to internet through mobile phone and this would
be the only cost incurred on the project.
 Technical Feasibility:
 To develop this application, an internet connection, a database server, a web server
and software are required. The current project is technically feasible as the
application was successfully deployed on Android Emulator.
2.3 Project Plan
At the beginning of the project, we scheduled meeting time for the group to discuss on
the design and implementation of the software and what language to use in writing the
software. We had several meetings to this effect. When then developed a time-line for the
project–when we would be releasing the first version for scrutiny and the estimated time
we thought we would use for refactoring. We also pondered on a suitable name to give the
project.

4
 The group was then divided that would work on parts of the code. We kept in touch with
each other and whenever we had difficulties, we asked each other questions. On some
occasions, we had to pretend we were the customer so as to try to figure out some of the
things that user would desire, such as the friendliness of the user interface and ease of
navigation through the software.

Ch. 3: Analysis:
3.1 Technology And Analysis
The technology used here is ANDROID. Android is basically an operating system for
smartphones. The OS was created by the start-up of the same name, which is owned by
Google since 2005. Now a day’s people using android as an operating system in their mobile
phones have been increased. So people using android are, much more and they are familiar
with it. Students increase their craze about android phones. The operating system is based
on Linux. Android allows multitasking in the sense that multiple applications can run
simultaneously. The database here used is Firebase. The Google Paid service.
Software and Hardware Requirements
 Software Requirements:
 Android version 5.1 or above.
 Hardware Requirements:
 Minimum 500MB RAM
 Minimum 20MB space.
 Hardware Constraints/Limitations
 Require Android supporting devices.
 Would work better in android 5.1 or above.
 Internet access needed.

Ch. 4: Design:
4.1E-R Diagram
Entity-Relationship diagram is a detail & logical representation of entities and data
elements for an organization. This technique is used in database that helps in an enterprise
are related to each other. There are 3 types of E-R diagram:

5
1. one to one :
It is a one to one relationship is an association between 2 entities.
2. one to many:
One-to-many relationship exists when one entity related to one or more entity.
3. Many to many:
It describes entities that may have many relationships among each other.

The basic symbols for E-R diagram are as described below:

This rectangle represents entity set.
This arrow is known as flow line. It links attributes to entity set &
entity set to relationship.

This diamond represents relationship among entity set. The

association among several entities in E-R diagram is known as
Relationship.

6
 This oval represents various types of data items that describes an
entity are known as its attributes.

4.2Data Flow Diagram

The data flow diagrams are pictorial or graphical representation of the outline of the
system study. The data flow diagram covers all the processes and data storage area which
takes place during any transaction in the system. The data flow diagrams are functionally
divided into context level, Zero level, First level and Second level data flow diagrams.

Following are the Symbols used in DFD:

Process: Here flow of data is transformed. E.g. Purchase
of items, update inventory file, etc.
External Entity: A source or destination of data which is
external to the system. E.g. Customer, Supplier etc.

A data flow: It is packet of data. It may be in the form

of document, letter etc.

7
 Data store: Any store data but with no reference to the
physical method of storing.

4.3Use Case Diagram

Use Case for System:

SYSTEM BOUNDARY

Login

*
*
*

List Of User

*
*
* **
Update Details
*
Top Package::College *

Post Event Name

*

Upload Event pdf

*

*
*
*

Payment
* *
*
*

Top Package::Admin

Check Event

*
*
*
Get Schedule
* *
*

*
Top Package::Student
Registration

Delete User

Register College

Use Case for Admin:

8
 ADMIN BOUNDARY

Login

Register College

Get Payment
*
*
**
**

Delete User
Top Package::Admin *

View Users
*

Use Case for College:

COLLEGE BOUNDARY

Login

Update Details

Post Event Name

*
**
*
**

Upload Event pdf

Top Package::College *

Payment
*

9
Use Case for Student:

STUDENT BOUNDARY

Login

Update Details

Check Schedule
*
**
** *

Get Event pdf

Top Package::Student *

Registration
*

10
4.5Class Diagram

Admin

Name
Admin_id
Admin_password

Manage()
Reports ()
User_Action ()
Explore () Student
Clubs
Name
Club Name Id
Multiplicity
Club_id Password
Event Name
Register ()
Description () View_Events ()
Post_Event () Explore ()
Explore ()
Notifications()
Database

Users_ids
Users_password
Event details

Store ()
Retrieve ()

Figure Class Diagram

11
4.6Sequence Diagram

(2.2)
Update Person_data
Update
Details

Give Details

(2.1)
College Details Get Data
Login

Event Title

(2.3)

Create Event

Upload pdf schedule

(2.4)
Event_pdf
Post Event

12
4.9User Interface

Login Page: The below figure shows the login screen/activity of an application.

13
Student Registration Page: This below given figure shows the user interface of the
registration activity of Leader.

After Student Registration Success: The given figure shows the activity to the
student user when the login is successfully done.

14
Main Activity page: The figure shows the activity when Admin is successfully login.

Club Request: The page shows all the club request to the admin. This can be seen by only
admin of the application.

15
Ch.5: Testing:
5.1 Testing Plan
5.1.1 The Testing Process:
We have tested the software process activities such as design, implementation and
requirement engineering because design errors are very costly to repair once system has been
started to operate. Therefore, it is quite obvious to repair them at early stage of the system.
So analysis is the most important process of any project.
5.1.2 Requirement Traceability:
As the most interested portion is whether the system is meeting its requirements or not,
for that testing should be planned so that all requirements are individually tested. We have
to check out that output of certain combinations of inputs gives the desirable results or not.
Your requirement specification gives us the path to get the desirable result.
5.1.3 Tested Modules:
 Administrator
 Users
 Leaders
5.1.4 Testing Schedule:
We have tested each procedure back to back so that errors and omissions can be found
as early as possible. Once the system has been developed fully we tested it on another
machines, which differs in combinations.
5.2 Testing Strategy
A strategy for the software testing integrates software test case design methods into a
well-planned series of steps that result in the successful construction of software. The
strategy provides a road map that describes the steps to be conducted as part of testing. When
these steps are planned and then undertaken, very much efforts, time and resources are
required.
A software testing strategy should be flexible enough to promote a customized testing
approach. At that same time it must be rigid enough to promote reasonable planning and
management tracking as the project progresses.

16
 A software testing strategy has following characteristics
 Testing begins at the component level and works outward towards the integration
of the entire computer based system.
 Different testing techniques are appropriate at different points in time.
 Testing & Debugging are different activities but debugging must be
accommodated in any testing strategy.
We checked entire project thoroughly so not even a single mistake would be there.
5.3 Test Methods
Testing presents an interesting anomaly for the software engineering activities, the
engineer attempts to build software from an abstract concept to a tangible product. Now
comes testing. The engineer creates a series of test case that are initiated to "demolish" the
software that has been build. Infect, testing is the one step in the software process that could
be viewed (psychologically, at least) as destructive rather than constructive.
Models of Testing:-
There are different Models of testing. On the basis of testing methods there are two types
of testing:
1. Black-box testing.
2. White-box testing
Black-box tests are used to demonstrate that software functions are operational, that input
is properly accepted and output is correctly produced, and that integrity of external
information is maintained.
White-box tests are used to examine the procedural details. It checks the logical paths by
test case. It can also checks the conditions, loops used in the software coding. It checks that
loops are working correctly on defined boundary value.
5.3.1 White-Box Testing:
White-box testing sometimes called glass-box testing, is a test case design method that
users the control structure of the procedural design to drive the test case. Always we are
thinking that there is no necessary to execute or checks the loops and conditions. And so
large number of errors is uncovered. With using white-box testing methods, we have checked
that; all independent paths within a function have been executed at least once, All logical

17
decisions on their true and false side, A11 loops working correctly at their boundary values
and within their specified conditions.
In our coding we test that all the loops works truly in each module. The one technique of
white-box testing is basis path testing. It contains two parts, one is flow graph notation and
the second is cyclometer complexity. In flow graph notation we are checking logical control
of flow. By using cyclometer complexity we find complexity of our project structure.
5.3.2 Black-Box Testing:
Black-box testing focuses on the functional requirements of the software. That is black-
box testing enables the software engineer to drive sets of input conditions that will fully
exercise all functional Requirements for the program. Black-box testing is not an alternative
to white-box testing techniques. Rather, it is a complementary approach that is likely to
uncover a different class of errors than white-box methods.
We use in our coding to find errors in the following categories:
 Incorrect or missing functions
 Interface errors
 Errors in database
 Performance errors
 Initialization and termination errors.
Unlike white-box testing, which is performed earlier in the testing process, black-box
testing tends to be applied during later stages of testing. Because black-box testing purposely
disregards control structure, attention is focused on the information domain.
By applying black-box techniques, we derive a set of test cases that satisfy following
criteria test cases that reduce, by a count that is greater than one, the number of additional
test cases must be designed to achieve reasonable testing.
Level 1 - Build Acceptance Tests
Other related test cases ensure that adopters received the proper Development
Release Document plus other build related information (drop point, etc.). The objective
is to determine if further testing is possible. If any Level 1 test case fails, the build is
returned to developers un-tested.

Level 2 - Critical Path Tests

18
 Critical Path test cases must pass by the end of every 2-3 Build Test Cycles. They
do not need to be tested every drop, but must be tested at least once per milestone. Thus,
the Critical Path test cases must all be executed at least once during the Iteration cycle,
and once during the Final Release cycle.
Level 3 - Standard Tests
Test Cases that need to be run at least once during the entire test cycle for this
release. These cases are run once, not repeated as are the test cases in previous levels.
Functional Testing and Detailed Design Testing (Functional Spec and Design Spec Test
Cases, respectively). These can be tested multiple times for each Milestone Test Cycle
(Iteration, Final Release, etc.).Standard test cases usually include Installation, Data,
GUI, and other test areas.

5.4Test Cases

Ch. 6: Conclusion And Future Work:

Conclusion:
This Application leads to the new product for student and college which provide effective
intercommunication of technical event. The wastage of time in sending mail, calling each
other and checking each other site is reduced here. The student will get a better medium for
getting Event Schedules , communicating with each others(also leaders of that events) And
their payments.

Future Enhancement:
 Registration Services:

The future needs of providing registration for the specific event will be provided. This
provides students not to interact with the college for registration, but they can directly register
their names in any event.

 Email Services:

When the user is registered they will get the confirmation mail to their registered mail.
This service will make sure to the Student that they are successfully registered to the event.

19