Case Study Report

Futsal Management System

Submitted by:

Ram Tamang & Umesh Niure Sharma

Semester 4

BACHELOR OF INFORMATION & COMMUNICATION TECHNOLOGY

SCHOOL OF SCIENCE & TECHNOLOGY
VIRINCHI COLLEGE
MANBHAWAN, JAULAKHEL, LALITPUR

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT

 ACKNOWLEDGEMENT

First of all, we would like to thank you Er. Nhurendra Shakya for providing us this beautiful
opportunity to complete the project report on a tech company. On the journey of this report, we have
improved on our skills, and were able to boost our group communication skills as well as creative
thinking.

We have to express our deep indebtedness to my internal supervision Nhurendra Shakya of Virinchi
College for the valuable direction, kind guidance, continuous co-operation and timely supervision.
We are also thankful to all the teachers and staffs.

We would also like to express our special thanks to our Principal Pradeep Pant, coordinator Roshan
K.C, and all the members of Virinchi college for their valuable suggestion and support for collecting
the information needed to study.

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT

 DECLARATION

We hereby declare that the project work entitled Futsal Management System submitted to the
Virinchi College, is an original work done by us. This project work has not performed the basis for
the award of any degree or diploma / associateship / fellowship and similar project of any.

August 9, 2021
Ram Tamang
Umesh Niure Sharma

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT

 APPROVAL SHEET

This is to certify that the report entitled “Futsal Management System” submitted by Umesh Niure
Sharma and Ram Tamang has been supervised. In my opinion the research follows the standard
requirement for the Bachelor of Information and Communication Technology.

__________________ __________________

Er. Nhurendra Shakya Roshan KC

Faculty Member Academic Coordinator
Requirement Engineering Virinchi College

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT

 Contents

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT

Introduction
Futsal is an exciting, fast paced, small, sided football game that originates from South America in the
1930s. It is widely played across the world, and is the small, sided football format that is officially
recognized by both UEFA and FIFA. The nature of the game places a large emphasis on technical
skill and ability in situations of high pressure and is subsequently an excellent breeding ground for
football competencies that can be translated into the 11-a-side format of the game.

Although Futsal is very much a game in its own right, there are also a number of benefits for football
by encouraging young people to play Futsal as part of a balanced training program to improve their
overall technical development. The game of Futsal creates an environment that allows young people
to simulate and develop many skills and proficiencies that are transferrable to the 11-a-side game.
The speed and fluidity of the game supports players in understanding and improving their skills in
the transition (counterattacking) phase.

Despite being in the technologically advance period, we (Nepal) don’t have modern system to
approach futsal game. In this case study, we have studied the problems of why any system has not
been built yet for the online futsal management and tried to solve those issues. We have done all the
feasibility study, risk analysis, and has developed the suitable model scheme for the system
development. More of it is on the below document.

Objectives of futsal management system

Mission
The futsal management system tends to modernize the traditional futsal management system. First,
the system will be implemented inside the valley and the eventually, to the major cities of Nepal and
finally to all over Nepal. It will make the futsal management mush more modern, convenient, secure,
reliable and fast.

Vision
The futsal management will modernize the overall futsal management from both customer and futsal
manager perspective and enhancing the user experience and the management system.

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT

Goal
The ultimate goal of futsal management system is to provide online services to all the futsal player
all over Nepal from booking, payment, match fixing and many more.

METHODOLOGY
In this section, we describe the company profile, respondent information, questionnaire used in our
case study and the steps conducted in our research.

A. Respondent Information
The people that responded to the case study play different roles in the companies, namely
product owners, UI designers, software engineers and Scrum masters. They are involved in
the process of requirements gathering and creating user stories in an agile environment. The
majority of the respondents have been practicing agile for more than seven years.
B. Questionnaire Design
The questions for this case study were designed on the basis of results and findings of a
literature review of agile RE practices. The literature review focused primarily on these areas
- customer involvement, face-to-face communication, requirements prioritization, continuous
planning and requirements modelling. The findings provided good insight into how agile RE
is being practiced in the software industry. We considered the following aspects in order to
come up with questions for this case study.
 Questions should be simple and clearly understood.
 The flow of questions should be logical and engaging.
 There should be a combination of objective and subjective questions.
 Terms and concepts used in questionnaire should be familiar to industry

We followed these steps to finalize the questionnaire:

1. Finalize the five main research questions

2. Finalize the sixteen sub-questions under the main research questions.
3. Questions were reviewed by a few agile practitioners
4. Questions were updated as per the review comments and finalized

The questionnaire for the case study was structured in two sections.

Section 1: consists of objective questions around organization profile, size, and agile
maturity. Section 2: focuses on how requirement gathering is practiced, followed by some of

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT

 the best practices being used and common challenges faced around RE. This information is
collected through a series of sixteen subjective questions that condense into five research
questions. Table 1 shows the case study questionnaire organized as per the research
questions.

C. Case Study Execution

We used two approaches in gathering information from the respondents. In the first
approach, we conducted face-to-face interviews. Face-to-face interviews lasted around 45
minutes, during which time handwritten notes of the interview were created. Interview
questions were adjusted as per the role of the respondent and the flow of the topic.

1.5 System Purpose

1.5.1 Users
Those who will primarily benefit from the new system and those who will be affected by the new
system include

Customers:

Upon implementation of the new system, customers will find site navigation, product identification
and product ordering easier. Customers will be able to choose whether to buy directly from SBE or
work with a sales agent.

Footstall owner

Product owners will be allowed to maintain the data and information about their footstall directly.

The new system will provide footstall info with more detailed, accurate and up-to-date information.
They will provide the timing, booking, and all information about the footstall to the player.

Footsall Manager:

Footstall manage will provide the footstall features, location, pricing open time and provide
information of challenger for other team to play football and discount price, offer all information will
be provide.

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT

1.5.2 Location
The system will be available to any potential user using the Internet but usefull for those who live in
valley. And futsal manager and owner can add footstall detain from anywhere.

1.5.3 Responsibilities
The primary responsibilities of the new system:

 provide players direct access to up-to-date, accurate product information on which they
can make a decision to buy
 customize footstall offerings to specific users
 allow differential access to web pages based on type of user
 allow players to book, challenge and challenge accept option.
 allow user to request book the footstall one day before.
 provide sales timing, schedule information.
 allow manager or owners to maintain information about their footstall directly.

Other desired features of the new system:

 a consistent "look and feel" throughout the website

 full-text searches of the web pages a user has permission to access
 on-line help in website navigation
 password protection scheme for non-public web pages
 translation of a web page to another language

1.5.4 Need
This system is needed in order to service the player to easily book with desire time and cost with a
near location Replacement of the current websites will eliminate the shortcomings of those sites.
The new system will allow footstall to rapidly increase players rapidly with help of different features
and in the future, it will be implemented in different locations of Nepal.

1.6 Overview of Document

The rest of this document gives the detailed specifications for the new footstall system. It is
organized as follows:

 Section 2: Functional Objectives

Each objective gives the desired behavior for the system, a business justification, and a
measure to determine if the final system has successfully met the objective. These
9

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT

 objectives are organized by priority. In order for the new system to be considered
successful, all high-priority objectives must be met.
 Section 3: Non-Functional Objectives
This section is organized by category. Each objective specifies a technical requirement or
constraint on the overall characteristics of the system. Each objective is measurable.
 Section 4: Context Model
This section gives a text description of the goal of the system, and a pictorial description
of the scope of the system in a context diagram. Those entities outside the system that
interact with the system are described.
 Section 5: Use Case Model
The specific behavioral requirements of the system are detailed in a series of use cases.
Each use case accomplishes a business task and shows the interaction between the
system and some outside actor. Each use case is described with both text and an
interaction diagram. An interface prototype is also shown. The system use case diagram
depicts the interactions between all use cases and system actors.
 Section 6: Class Model
A class is a collection of objects in the system that have the same data and behavior. All
analysis classes and their relationships are shown on the class diagram.
 Section 7: An appendix containing a glossary that
defines terms specific to this project

2. Functional Requirements
2.1 High Priority
5. The system shall allow for online footstall booking for player. It also provides the update,
cancel the bookings.
6. The system shall reflect a new and changed rules description within x minutes of the
database being updated by the owner. This will reduce the number of incidents of
incorrectly displayed information by x%. This eliminates the current redundant update of
information.
7. The system shall display information of footstall like rules, offers, location etc.
8. The system shall allow owner with administrator control with control panel and player as
user.

10

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT

 9. The system shall allow a player to directly contact the nearest footstall in his area. This
will improve service by reducing the time to respond to a user request to no more than x
days.
10. The system will provide the challenge option for team and other team can accept
challenge.
11. Every notification of updates like, challenge, closed/open information will be sent to the
players who register in system.

2.2 Medium Priority

12. The system shall provide a search facility that will allow full-text searching of all web
pages that the user is permitted to access. The system must support the following
searches:
o find all words specified
o find any word specified
o find the exact phrase
o Boolean search
13. Player can watch detail about the other team and they can fix match and individual
players can be join if team is incomplete.

2.3 Low Priority

14. The system shall allow the user's status to be stored for the next time he returns to the
web site. This will save the user x minutes per visit by not having to reenter already
supplied data.
15. The system shall provide marketing with customer navigation information. This
information will allow marketing to determine what information prompts a purchase and
help target potential customers more effectively. This will increase annual revenue by $x
in additional sales.

3. Non-Functional Objectives
3.1 Reliability
 The system shall be completely operational at least x% of the time.
 Down time after a failure shall not exceed x hours.

3.2 Usability
 A footstall manager should be able to use the system in his job after x days of training.
11

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT

  A user who already knows what product he is interested in should be able to locate and
view that page in x seconds.
 The number of web pages navigated to access product information from the top page
should not exceed x.
 The system shall provide additional options for Nepali language translation beside the
default English language for better usability.

3.3 Performance
 The system should be able to support x simultaneous users.
 The mean time to view a web page over a reliable modem connection shall not exceed x
seconds.

3.4 Security
 The system shall provide password protected access to web pages that are to be viewed
only by register user.
 Manager of the footstall have and admin level access with login id.
 Transaction data must be transmitted in encrypted form.

3.5 Supportability
 The system supports the all device like desktop, tablets, mobile etc.
 The system web site shall be viewable from Internet Explorer 4.0 or later, Netscape
Navigator/Communicator 3.0 or today updated all browsers.

3.6 Online user Documentation and Help

 The system shall provide a web page that explains how to navigate the site. This page
should be customized based on what pages that user is allowed to access.
 This help page should be accessible from all other pages.

3.7 Purchased Components

 A language translation tool from English to Nepali will be needed.
 A web site search engine will be needed.

3.8 Interfaces
The system must interface with

 The current Oracle database systems for product and order information
 The current Oracle Financial accounting system

12

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT

  The current AccountPro inventory system
 The acquired language translation tool
 The acquired web site search engine

Feasibility Analysis:
Technical Aspects

Technical factors aim to evaluate the requirements to accomplish the code review from a technical
point of view. These technical factors are determined by the technologies and tools necessary to
execute the code review. They are as follows:

 Knowledge Factor: This factor analyses two different types of knowledge: the analyzed
programming languages and the security concepts of the code. This knowledge can be
contained in the code review method documents. This factor is fulfilled when the code
review project team meets the knowledge benchmark desired. This degree of knowledge is
required to execute all the project tasks (being able to examine any code and detect security
flaws). It also evaluates the project team skills that are required to carry out the project.
 Tool Factor: The tool factor aims to analyze if the code review project team has the required
tools to perform the code review, and if they are correctly installed and configured. This
factor is satisfied if the code review project has the necessary tools and they are ready to
use.

Economic Aspects

Economic factors evaluate the economic aspect of the project. Costs and benefits are the two
factors to consider, and the way of analyzing them is different. While costs result from the sum of all
project resources, benefits are quite hard to determine. Making estimations to quantify the benefits
of any preventive measure is difficult, so the approach will consist in listing the benefits without a
numeric estimation.

 Costs Factor: this factor evaluates the code review project costs, and it is an important
element since the feasibility is calculated by adding up the different costs of the project (e.g.
development, testing tool, logistics, and any other costs that can be generated during the
13

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT

 project execution). This factor is fulfilled when the total cost remains below the Cost Limit
established.

Topic Domain Hosting Testing and security

service

Cost 1100 1000 2000

Legal Aspects

Legal factors aim to analyze the legal aspects of the code review project and their potential effects.
Due to the nature of this kind of projects, legal aspects have a minor effect on the feasibility of the
project, because they are related to the software license of the testing tools.

 Tool License Factor: It aims to evaluate the software licenses of the tools. The tool involved
in the code review has to adhere to the relevant licensing terms. If it is a proprietary tool, the
license cost also has to be considered within the cost factor. This factor is fulfilled when the
tool adheres to the license terms.

Operational Aspects

Operational Factors address the evaluation of the effects that operational aspects could incur in
code review projects. Any project needs a set of elements; the project input, the processes to
transform said input into the project output, and the people to perform the tasks. This is why these
factors are related to people, project inputs and project processes. The factors related to specific
individuals are:

 Project Developer Factor: It analyses whether the project team includes the required number
of people to execute the project. We do not have the required team members for the project
but overall it can be considered.
 Stakeholder Factor: It analyses if the project has been able to engage key people in the
project (e.g. software owners, sponsor (DIGIT), project managers), in addition to the code
reviewers. They are necessary as they have to provide the software documentation and be
available if any other requirements are needed. In the event that a critical vulnerability is
detected, they will be contacted to determine how to approach the solution. This factor takes
into account the engagement and commitment of the project stakeholders, who are

14

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT

 necessary for the success of the project. This factor is fulfilled when those people are
actively involved in the code review project. With regard to the project input there are two
factors to consider:
 Code Factor: Since this is a code review project, the code to analyze is the project input. This
factor is fulfilled when the code is available in the proper format (source code, etc.) to
perform the code review.
 Code Documentation Factor: It evaluates if the documentation of the code is available.
Depending on the scope of the code review, the documentation required may be different in
terms of module design or in the description of some functionalities. This factor is fulfilled
once the code review team has been provided with that documentation.
 Scope Factor: It analyses the scope of the code review project, what part of the code or what
modules are going to be analyzed, and how (managed, defined, or optimized). In a feasible
code review project, the scope has to fall within the Scope Limit. This factor is fulfilled when
the scope of the code review (Scope Factor) is less than or equal to the Scope Limit.

Scheduling Aspects

In scheduling it takes one month to cover all things in project all the things are shown in below table

Task\Time 08/0 08/10 08/16 08/20 08/24 08/28 09/01 09/05 09/09
7

Planning

Requirement gathering and

analysis

Design

Development

Testing and maintenance

Implementation

Risk Analysis and management

Requirement risk is potential for the loss due to project’s requirements themselves or requirement
process. Such risks are closely tied to the quality of the requitements in that low low quality
requirement risk to the project. Projects are garbage-in garbage-out meaning project are fully
15

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT

dependent on the requirement i.e. faulty requirement produce failure product. During the course of
our project planning, requirement gathering and development, we have faced the following problems
that would affect the quality development of the product. They are listed below along with how we
resolved the issues.

 Missing stakeholders
Missing stakeholders refers to failing to identify or engage the stakeholders. While we went
to gather the requirements, we did not the find the stakeholders in most of the cases. This
would impact our project by inadequate requirement gathering.

We solved this issue by a couple of methods. If we did not find the stakeholder during
requirement gathering, we waited for a longer time and wait for the stakeholder to return and
gather requirements afterward. In case of the stakeholder was unable to return, we collected
the phone number and gathered the required information later on.
 Wrong stakeholders
In some scenarios, while gathering requirements, we got to interact with the very lower-level
stakeholders who are unknown of the requirements and are unable to decide what to say
and whether to say anything or not. For example, security guards, friends of the manager,
etc. due to which we were not able to gather requirement properly.

In this case, we asked the wrong stakeholder we met the contact detail of the stakeholders
and gathered the requirement or physically met another day to gather requirement.
 Ambiguous requirements
Most of the users or stakeholders presented the requirement in such a way that they are very
open to misinterpretation. In some cases stakeholders ntentionallt defined open-ended
requirements in order to avoid making decision to protect themselves from different aspect
and in some cases, stakeholders requirements were poor worded.

To solve this issue, we explained the each feature of the system how it works, asked them
yes/no questions instead of long explanation. We also asked the straight forwarded question
for easy answer. This way we were able to reduce ambiguous requirements.
 Incomplete requirements

16

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT

 Due to incomplete requirement's users (players and managers) may unsatisfied and due to
these, they can reject our project. So, we need to think with a global concept which satisfies
the l-user requirements from basic to advance.

To overcome this risk, we are going to testing the process with a different test case where
the user manager and players both check the system with their requirements and
performance, all of the things they need to be going to the digital platform.

 Security

We are going to integrate the real-time online payment system for the footstall booking. So,
there is high chance of the security breach. Today there are so many active cyber attackers
so they can attack our system and monitor all transaction history user account.

We are going to implement the data encryption with all forms use in template and backend
database with the data encryption and administrator password. We will update security and
features every 2 months. In case of a security attack, we plan about backup and if there is
any change of attack and someone trying to attack, we remove all history and freez website
until security is managed.

4. DATA MODELING
This data modeling describes the all modules, attributes, entity and their relationship of the futsal
management system. in futsal management system in an initial stage there is more than seven
classes in module. We represent these modules with different structure like UML, DFD (up to level
2) and ER diagram.
A. ER-Diagram

17

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT

 18

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT

 B. Data flow diagram

19

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT

 20

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT

 21

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT

 C. The Use Case Model
C.1 System Use Case Diagram

Verification and Validation

Requirement's validation is the fourth component—with elicitation, analysis, and specification—of
requirements development. We assess whether a system actually satisfies the customer needs
(doing the right thing). In contrast, verification determines whether the product of a development
activity meets the requirements established for it (doing the thing right). Both activities are vital to
successful product development, but we will focus on validation here.

A. Reviewing Requirements

22

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT

We review the all requirements we collected and recheck the in-software requirements specification
documents. And finally, we can say that that these requirements satisfy the customer needs. We
check these with comparing our questionaries and data model and these give us validated
requirements and in future will be give futsal manager and player to test this system. Some of the
review topics are:

 Completeness checks
 Consistency checks
 Validity checks
 Realism checks
 Ambiguity checks
 Verifiability

In our requirements there is describe the all-complete requirements in proper way with data
modeling language. We also check the system consistency, realism because we are not able to
meet all owner of the futsal. In our requirements there is complete, clear and non ambiguous
requirements.

23

FUTSAL MANAGEMENT SYSTEM CASE STUDY REPORT