JSS SCIENCE AND TECHNOLOGY

UNIVERSITY (formerly SJCE),

MYSURU

A report submitted to fullment of curriculum prescribed for

Software Engineering

CS530

Amogh Deshpande
01JST17CS017
Anoop Krishna Y
01JST17CS022
Dhananjay V Jahagirdar
01JST17CS046
Madan G S
01JST17CS078
Santosh S
01JST17CS140

Submitted to :- Dr. Trisiladevi C. Nagavi

Assistant Professor
Department of Computer Science and Engineering

1
1 DECLARATION
We, Amogh Deshpande, Anoop Krishna Y, Dhananjay V J, Madan
G S, Santosh S, hereby declare that this project is entirely our own
original work and that, to the best of our knowledge, it has not
been presented or submitted for any degree or examination in any
other university. And that all the sources we have used or quoted
have been indicated and acknowledged by complete references.

PROJECT SUPERVISOR
Name: Dr Trishiladevi Nagavi
Signature:
Date:

2
2 Abstract
The purpose of this project is to solve the problems in manual
management of the class notes for the students by providing a dig-
ital notes repository. In recent times, where technology is at an
all-time high, it can easily assist an individual to make his/her life
less troublesome. By receiving a complete set of requirements from
the stakeholders we prepared an ecient design of the end product
incorporating all the features and functionalities desired by stake-
holders. The standard procedures for requirement collection are
sincerely obeyed and the all the steps are clearly explained in this
document.

3
3 Acknowledgement
We are over helmed in all humbleness and gratefulness to acknowl-
edge our depth to all those who have helped us to put our ideas
and assigned work, well above the level of simplicity and into some-
thing concrete. We would like also like to extend our gratitude to
our Software Engineering Lecturer, Dr Trisila Devi Nagavi, who
guided and provided us with all the aid we required to bring forth
this submission.
We would also like to show gratitude to our HOD, Dr.Pushpalatha.M.P,
for always encouraging and motivating us to explore new arenas.
She has been a constant pillar of support. We would also like
to thank all the dierent stakeholders of the project who agreed to
take out time from their busy schedules to provide us with in-depth
knowledge about the ground problems of the project.

4
4 Project Team Details

1.Anoop Krishna Y
USN : 01JST17CS022
Roll no. : 06
2.Amogh Deshpande
USN : 01JST17CS017
Roll no. : 04

3.Dhananjay V Jahagirdar
USN : 01JST17CS046
Roll no. : 14

4.Madan G S
USN : 01JST17CS078
Roll no. : 21

5.Santosh S
USN : 01JST17CS140
Roll no. : 37

5
Fig: Group Picture
`

6
Contents
1. DECLARATION
2. ABSTRACT
3. ACKNOWLEDGEMENT
4. PROJECT TEAM DETAILS
5. CHAPTER 1: INTRODUCTION
5.1 Problem Denition
5.2 Aim
5.3 Objective
5.4 Time of Schedule or Completion of The Project Work
6. CHAPTER 2: SYSTEM REQUIREMENTS ENGI-
NEERING
6.1 Inception
6.2 Elicitation
6.3 Elaboration
6.4 Negotiation
6.5 Specication
6.6 Validation
6.7 Requirement Management
7. CHAPTER 3: SYSTEM DESIGN AND IMPLEMENTA-
TION
7.1 Architecture of the Notes Repository
7.2 Design
7
7.3 DFD
7.4 Module Wise Algorithms
8 CHAPTER 4: SYSTEM TESTING AND RESULT ANAL-
YSIS
8.1 Plan and Data Collection Of Testing
8.2 Unit Testing
8.3 Integration Testing
8.4 Acceptance Testing
9 CHAPTER 5: CONCLUSION AND FUTURE WORK
9.1 Conclusion
9.2 Scope of Future Work
10 REFERENCES

8
 5 CHAPTER 1: INTRODUCTION
5.1 Problem Denition
Many of the college going students have a problem during
their internals and semester end examinations due to lack of
resources. This in turn decreases the student understandability
and skill required for that particular subject.
This document serves as the requirement engineering study for
our academic project Notes Repository. The project requires
research into the features, functions and also the design that
the developers must implement to implement user satisfaction.
This document contains the direct responses from the students,
lecturers, the analysis of their requirements and a comprehen-
sive list of list of all features and models.
User interactions, system interfaces and system specications
are all recorded in this document along with validation and
requirement management. The goal of this report is is to pro-
vide the designers of the product with clear specications and
a clear concept of the implementation of the project.

5.1. Aim
Our vision is to provide the students and also the lecturers with
various resources. Resources in the sense it can be notes from a
lecturer, a textbook pdf of that particular subject, or an online
video link. This provides a greater platform for gaining knowledge
on that subject.

5.3 Objective
The software is for the automation of notes repository.
9
It maintains the two level of user:

1) Administrator level
2) User level/ Student level

The software provides the solution for the following problems:

Students Perception:

1. How often do they misplace their notes?

2. Where do they get the notes from?
3. What do they do if they lose their notes?
4. How do they maintain/organize their notes?
5. What do they want from our app?

Lecturers Perception:
5.1. Isn't it too much to rely on one person (CR) to forward the
notes they intended to share to the whole class?

10
 6. Time of Schedule or Completion of The
Project Work

Fig.: Gantt Chart

6 CHAPTER 2: SYSTEM REQUIREMENTS

ENGINEERING
6.1 INCEPTION
Our institution is comprised of many branches and each branch
have their own textbooks and class notes. The successful manage-
ment of any of these notes requires handling of lots of tasks and
maintenance. Currently, all these tasks are done manually and it
is unorganized. More often, this becomes a tedious if not done in a
systematic manner. This puts a lot of needless pressure on a single
11
individual and constraints them to focusing on the documentation.
This reduces the performance on the part of the student. Further in
those day and age having things on paper or having important re-
sponsibilities on the heads of individuals gives way to a lot of scope
of human error, malpractices and other intrusions which eectively
break the system.
One of our team members (Madan G S), having missed
some of the classes due to his health issues, identied this issue
as a common one amongst most students of our institution. So,
we decided to address this issue by coming with a software which
would facilitate notes repository service for students and the teach-
ers too. The software would eectively take care of all the class
notes, textbook, question papers and Calendar of Events in a dig-
italized manner. This system shall provide the students with a
platform where they can share their notes with their fellow class-
mates. We saw a lot of scope of automation for the management
of notes usually handled manually by the stakeholders and so de-
cided to undertake the developing a software solely on providing
better undertakings for the students and not on futile tasks such
as manual documentation of their class notes.
For the end users that is the students, the product would act as
an interface to maintain and organize their notes. It would allow
his/her to monitor their documents. The software would keep the
students well informed about the class notes being uploaded.
The software service would also extend to the Teaching sta of
our Institution consisting of Lecturers and students. We thought
of providing a safe and secure experience to our stakeholders by
providing unique Login ID and Password. It has a very promising
Graphical User Interface for ease of use for the end stakeholders.
Understanding the domain was our next step. The soft-
ware is designed with a point of view of providing students with a
12
systematic and ordered collection of notes and documents needed
for the students. Lastly, giving the selected students a privilege
to verify the notes, in-hand overview and the administrators are
provided with the control over the notes being uploaded. The end
stakeholders can access this database using an Android Applica-
tion.

6.2 ELICITATION
We approached the dierent stakeholders and interacted with them
in order to gather all requisites that they desire in the software.
Topics on which questions were raised by our group to the stake-
holders:

First, we asked the following questions to students of our college:

1. How often do you misplace your notes?

2. Where do you get the notes from?
2. What do you do if you lose your notes?
3. How do you maintain/organize your notes?
4. What do you want from our app?
5. How often do you write notes?
6. How do you complete the notes if you miss few classes?
7. What do you think if we come up with a digital solution to
solve this problem?

13
Then we talked to some of the lecturers of CSE Department and
we put forward these following questions:

1) Isn't it too much to rely on one person (CR) to forward the

notes you intended to share to the whole class?
2) What do you think if we come up with a digital solution to
solve this problem?

The section below lists and elaborates all the meetings that were
conducted with the dierent stakeholders for the purpose of col-
lecting their perspective upon the product and their desired re-
quirements. For the purpose of doing so we approached them with
requests of meeting at an agreed location and also briefed them
about the purpose of the meet.
Stakeholders 1 :
1. Akshay Anand, Seventh Semester, CSE who is the Chief Co-
rdinator of the executive committee of LCC.
2. Vijeth Vaishnav, Third Semester, CSE.

This is the transcript of the meeting conducted with the stakehold-

ers for the project. The objective of this meeting was to collect
the requirements for the product from these stakeholders and to
understand the current problems facing by them.

1. We asked the students how often they misplaced their notes due
to various reasons. Forgetting to get the right notes to a class was
one of the reason. They forget where they had written their notes
and where they keep it after writing it.

14
2. Next, we asked them where they got their notes from. Currently
the rst years and few of the higher semesters are getting their notes
from MCV Xerox Centre. The long queues just before the internals
and the Semester End Exams was the major issue. The paper used
for Xerox is waste and most of the notes are not passed on to the
juniors.
3. Next, we asked the students what they would do if they lost
their notes. The most common answer was “Ask for a friend to
send a PDF of their notes” and study from it. We asked them
what if the message sent by your friend gets deleted or you cannot
nd the PDF he/she sent you? And the answer was the same, ask
another person to send their notes. It is a recurring problem to
which a solution is need to be found.

4. Next, we asked them how they organized their notes. This was
their biggest hurdle. Most of the stake holders said they lost or
could not nd the right notes during the right time.

5. Next, we gave our brief description about our Android Applica-

tion which solves all these problems. We explained about how easy
it is to maintain all their notes in a single app and never stand in
queues to get their notes Xeroxed.

Requirements Acquired:

1. User-Friendly GUI:
All the stakeholders (students) wanted a user-friendly Graphical
User Interface for ease of use.
15
2. Neatly Organized:
Every student wanted a neatly organized structure where all the
notes are separated based on the subjects and their semester.

Vijeth Vaishnav, 2nd year CSE.

Akshay Anand, 4th year CSE.

16
Stakeholders 2:

1. Dr. Trisiladevi C Nagavi, CSE Department.

2. Prof. Bindiya AR, CSE Department.
3. Prof. Ashritha R Murthy, CSE Department.

This is the transcript of the meeting conducted with the stakehold-

ers for the project. The objective of this meeting was to collect
the requirements for the product from these stakeholders and to
understand the current problems facing by them.

1. We asked the lecturers whether it was dicult to rely on a

single person (CR) to forward the notes you intended to share with
the whole class. The answer we got was “Yes, sometimes the CR
might forget to forward the notes/message sent to him and it's a
major issue we are facing now” . So we gave a brief explanation
on how our Android Application gives a platform to share notes to
students.

Requirements Acquired:

1. Video Lectures:
The lecturers wanted video lectures to be added to the app so that
students can refer to the videos whenever the miss classes or didn't
understand a concept. NPTEL video links can be added to the app
for students to refer.

2. Textbook PDF's:

17
Textbook PDF's can be provided to the students via `Noteix' so
that students instead of buying a book can refer the textbook using
this app.
We considered this requirement to be implemented in this applica-
tion.

3 Check for malwares:

Malware detection and security was a major issue. Currently in
this beta version we are not implementing this feature due to lack
of technical skills.

1) Check for duplicates:

Checking for duplicates was another major issue where a person

can spam the same notes and the database gets lled with the
same notes. We came up with a verication technique where a
privileged person must verify the notes within three days and the
Non-veried notes gets removed from the database.

18
Dr. Trisiladevi C Nagavi, CSE Department

Prof. Bindiya AR, CSE Department

19
6.3 ELABORATION
A detailed explanation for the information obtained from the stake-
holders is presented by elaboration phase. The requirements spec-
ied by one stakeholder may be repeated by another stakeholder.
When the requirements collected are analysed all together, a kind
of pattern may be recognized.
Who are the stakeholders?

1) Students.
Students play the major role of the stakeholder as they are
the people who utilize this software to the maximum amount.
They are given the highest priority.
2) Teachers/Faculty.
The role of the teacher or a faculty is to assign privilege to cer-
tain number of students who in turn will verify the uploaded
documents. Even the lecturers or faculty can verify the up-
loaded documents. They come next to the students in the
priority.
3) Long distance learning.
Many students learning at distant places wish to access the
notes of a particular institution or the notes of a particular
lecturer taking classes. They can utilize this software in order
to study the course. They also play an important as that of
the students.
We have listed the major stakeholders as above. By taking the
requirements from the above, we build our software in order to
meet there demands.
After analysis we got the following common requirements from
the stakeholders. Some of them are as mentioned below:

20
 a) Availability of notes in an easy storable/ downloadable for-
mat. (preferably PDF format)
b) Easy uploading of notes must be possible.
c) Verication of the uploaded notes (chances of incorrect
notes to be uploaded)
d) Availability of notes in a sorted or ordered manner even
after addition of many other documents onto the software.
e) If possible to have the video lectures of the course related
to the notes. (the links of the particular videos can be
provided in the software)

The pattern may be elaborated to facilitate the formation of

complete and consistent requirement document. Problems in
realizing the product are inevitable. The pattern allows easy
identication of such problems and through the reuse of de-
ned and tested solutions to the known problems it guides us
throughout the project. Also, it is very important to under-
stand the problem statement completely before attempting to
design the solution. The scope of usage, technical risks involved
and most essential features that are to be integrated into the
system are recognized and an architectural plan for the project
called architectural prototype is developed.
The architectural plan includes the following things:
1. Scope of usage. (how far the idea is feasible/feasibility)
2. The technical risks involved. (which all softwares can be
used)

Then after checking the above the prototype is carefully de-

signed for stability and adaptability to changes.
Elaboration enables organized study of the system to help ac-
commodating changes in user demands from time to time. The
21
prototype is carefully evaluated for stability and adaptability
to change and also a validity test is performed to check whether
it adheres to the set vision without compromising time and cost
of development. This facilitates clear understanding of critical
use cases in which the product must prove itself. Elaboration
also helps in getting a better picture of development environ-
ment and the way in which the tools and software components
t in.
With a strategic plan considering component costs and possible
reuses, elaboration also acts as a preface for construction. Any
bugs identied in overall elaboration activities are resolved to
convince the customers that we have a realistic approach to
the nal product. The outcome of elaboration phase is the use
case model.
Use case model is a model of system's intended functions and
its environment, and serves as a contract between stakeholders
and developers. It consists of a collection of:
Use cases: Sequence of actions performed by the system which
oers observable and valuable result to a particular actor.
Actor: Denes a coherent set of roles that users of the system
can play when interacting with it. A user can either be an
individual or an external system.
Supplementary specications: Capture the system requirements
that are not readily identied in use cases.
Analysis model: It is an object model describing realization
of use cases, which serves as an abstraction of Design model.
It contains results of use case analysis, analysis classes and
associated documents.
Analysis classes: Identies major responsibilities which are to
be handled and represents prototypical classes of the system.
It is the `rst-pass' at the major abstraction that the system
must handle.

22
Design model: It is an object model describing the realization
of use cases, and serves as an abstraction of implementation
model and its source code. It is used as an essential input to
activities in implementation and test.
Design classes: It is a description of a set of objects that share
the same responsibilities, relationships, operations, attributes
and semantics. They are 37 derived from Analysis classes as a
result of design process.
From the ow diagram we get to know that the user has to sign
up or login to the software application at rst. A particular
username and password is assigned to the user. The user has
to enter the details that is known to him. Once the user has
logged into the system, there will be a portal for the selection
of the particular branch of the student. After the branch entry
it will lead the user to enter the semester. This is the platform
where the user has given all the credentials required, and now it
is possible for the user to upload his/her documents only in the
form of a PDF. Here the lecturer would have assigned certain
number of privilege students who in turn will check / verify the
uploaded document that has been sent any student. Once the
document is veried, we will receive a watermark at the bottom
of the document. And this particular document can be now
downloaded for further use. In case if the document uploaded
by any student is not veried, then under 3 days the document
gets automatically deleted/ moved to trash. This will allow us
to remove unwanted documents into this software. In a nutshell
it provides the security to this software application.
Service Facilities:
As a software developer we need to keep in mind that our
software should be platform independent. So the best way to
do so is to go for web based applications rather than going for
desktop based application.
Also the stakeholder wanted a simple way of having the database
23
made available while accessing with the interface being suitable
to all. So during our discussion we came out at the conclusion
that there could be no better and most importantly cheaper
way to store the data other than using cloud services.
Advantages of cloud services:
The data can be accessed from anywhere if you are authorized.
The maintenance is cheaper.
Data security is possible.
In current demand i.e. up to date with the current scenario.
Thus, by using cloud services any number of computers can be
connected to a particular database.

6.4 NEGOTIATION
The clients of our software application are the students of our
college and the lecturers/faculty members. We had some ses-
sions with our stakeholders and noted down their requirements.
The stakeholders cannot completely state their all requirements
explicitly. When the requirements collected from all stake-
holders are collaborated, certain requirements appeared to be
unfeasible. It was highly important for a negotiation strat-
egy to be applied to resolve the unfeasible/conicting require-
ments.Because we have many live examples of failed projects
due to poorly negotiated requirements among the stakeholders.
Negotiation leads to benets such as understanding the problem
statement, implicit requirements, constraints applicable along
with fostering team learning, resolving ambiguity and complex-
ity, dealing with uncertainty and nding better solutions. But
for utilizing the benets of negotiation to fullest, the process
implementing the correct negotiation is necessary. A collab-
orated discussion regarding functions, features and priorities
24
and delivery dates with all the stakeholders can set a common
goal for the product outcome and also resolve the disagreement
between the stakeholders. The set of requirements collected
from the discussion needs to be properly analyzed for the nal
template to be prepared with rich set of functionalities which
accomplishes the desires of all the stakeholders. When the nal
software product is delivered to the stakeholders, a smile of
satisfaction on their faces is expected which in turn will be a
fruitful result of our hard work.
With the above idea in our minds, we put forward these nego-
tiations:
These are some of the functionalities we had to drop because
of the complexities:
1. Currently, in the Beta version we are planning to give the
repository only for the fth Semester CSE students as it is very
expensive to host the data of all the classes in the rebase DB.
Firebase has a storage limit of 1GB per month and anything
in excess of that will be charged a fee of 25$ .
2. Search function and reviewing of the uploaded notes had to
be dropped because of the complexity of the algorithm.
3. Video lectures are not feasible because video les are gener-
ally larger in size and will nish up the 1GB per month quota
of rebase DB.
Functions we are incorporating as per stakeholder requests:
1. Spam reduction model: We plan on giving some of the
users the privilege of verifying the notes. If the status of the
document does not get veried in 3 days' time, it gets deleted
automatically.
2. Our platform can also be used to share miscellaneous docu-
ments such as calendar of events, old question papers and time
table.
3. We provide folders for every subject so that the notes can
be maintained in an orderly fashion.

25
6.5 SPECIFICATIONS

The tools that were instrumental in making this android ap-

plication were:
1. Android Studio:

Android studio is the ocial IDE (Integrated Develop-

ment Environment) or tool (layman terms) for developing ap-
plication exclusively for Android platform.
It has a strong editor tool for developing creative UI and emu-
lators for dierent versions to test and simulate sensors without
having actual Android devices.
It also has a very useful Gradle plugin using which one can cre-
ate application les (apks) with dierent congurations. More-
over it makes exporting and uploading apk on “playstore” easy
with a single click. It also oers ANT build.
In the recent updates Android studio has brought instant run
which makes testing even faster and easier.
Most of the code for this particular application is written on
this platform. The coding language used to develop the appli-
cation is JAVA.
Android studio is very ecient as it allows connection with
Firebase DB and bitbucket.(these are the other important tools
used in this project).
2. Firebase Database:

Firebase Realtime database is a cloud hosted database that

supports multiple platforms Android, iOS and Web. All the
data is stored in JSON format and any changes in data, reects
immediately by performing a sync across all the platforms &
devices. This allows us to build more exible realtime apps

26
easily with minimal eort.
Firebase covers the essentials so you can monetize your business
and focus on your users.
The term essentials are divided into three parts :
1. Building your App
2. Improving the Quality of App
3. Business Growth
To achieve the above essentials these are the tools developed
by rebase:
1. Firebase gives you functionality like analytics, databases,
messaging and crash reporting so you can move quickly and
focus on your users.
2. Firebase helps in building applications without server side
programming language.
3. Firebase is built on Google infrastructure and scales auto-
matically, for even the largest apps.
4. It is supported on dierent platforms:- Android, iOS, Web,
C++ and Unity.
5. Firebase provides many library functions for querying, in-
serting, updating and deleting data.
3. Bitbucket:

1. Access control to restrict access to your source code.

2. Workow control to enforce a project or team workow.
3. Pull requests with in-line commenting for collaboration on
code review.
4. Jira integration for full development traceability.
5. Full Rest API to build features custom to the workow.

27
 Bitbucket enabled us to simultaneously work on our respective
tasks. For example, both designer and back end developer of
this application could work parallelly and were able to integrate
in the end using this software. Thus, saving a lot of time.

4) Adobe Xd:

Adobe XD is a vector-based user experience design tool for

web apps and mobile apps, developed and published by Adobe
Inc. It is available for macOS and Windows, although there are
versions for iOS and Android to help preview the result of work
directly on mobile devices. XD supports website wireframing,
and creating simple interactive click-through prototypes.
Everything from designing logo to designing user interfaces are
done using this software. Even the prototypes of the applica-
tion is designed using this software.

6.6 VALIDATION
Requirements should be validated before the software product
as a whole is ready. The validation step is basically a review of
requirements collected, to make sure that they meet needs of
stakeholders and to identify any problems with the requirement
specications. It is preferable to x any bugs in the requirements
in the initial stages rather than dealing with their complex
consequences in the nal product because changes in the re-
quirements usually demand changing and re-testing of design
and implementations. Any mismatch in the requirements in-
terpreted and those which are desired by the stakeholders may
result in an incorrect product to be developed.
28
Our software product has students from dierent years. We
conducted meetings with all of them personally and listened
to their requirements meticulously. We as a team, sat together
and carefully analysed overall bundle of requirements and had
a constructive discussion to conrm that we have understood
all the aspects appropriately, thus nishing internal validation
phase.
We carried out external validation by having another meeting
with our stakeholders to clarify our doubts and to obtain their
consent for the nal requirement document that we had created,
but there were still several clarications that had to be made,
which were cleared once we met the stakeholders. Through
internal validation we decided that there would be four dierent
types of users (lectures, students and admin) where the admins
and lecturers would have the same features and options.
But later after talking to the stakeholders (external validation)
we realized that the all students shouldn't be given access to
verication remark.
The requirements are now clear and we have started the de-
velopment of the software and the requirements can be tested
after implementation. We will have a fairly ecient and error
free Notes-Repository system in the initial release.
As our software product has a scope of development throughout
its lifetime, we consider the external validation phase to be
a continuous process. Most of the requirements passed the
validation phase, yet we noticed some problem areas like:
a) We had planned to provide an automatized assistance with
an OTP mechanism for login.
b) We will include software to track back for one time down-
load facility.
c) We are planning to provide video tutorials in addition to
the notes and textbooks.

29
 d) We had planned to provide a graphical representation of
performance of an individual, so that our software could
assist the user easy and user friendly. Student to choose
its future Resources by recognizing the veried mark with
peak performance statistics. Also, it demands considerable
amount of software expertise to make sure the result of
assessments is accurate.

During the requirements validation process, dierent types of

checks are carried on the requirements, they are:
1. Validity check: The functions proposed by the stakeholders
should be aligned with what the system needs to perform. You
may nd later that there are additional or dierent functions are
required instead.
2. Consistency checks: Requirements in the documents should
not conict or dierent description of the same function.
3. Completeness checks: The document should include all the
requirements and constraints.
4. Reality checks: Ensure the requirements can actually be
implemented using the knowledge of the existing technology,
the budget, schedule etc.
5. Veriable: Requirements should be written so that this can be
tested, this means you should be able to write a set of tests that
demonstrate that the system needs the specied requirements.

30
Prototype

6.7 REQUIREMENT MANAGEMENT

It is a set of activities that help the project team to identify,
control and track the requirements and changes can be made
to the requirements at any time of the ongoing project.
These tasks start with the identication and assign a unique
31
identier to each of the requirement. After nalizing the re-
quirement traceability table is developed. The examples of
traceability table are the features, sources, dependencies, sub-
systems and interface of the requirement.
Require Management is process of documenting, analysing,
tracing, prioritizing and controlling change on requirements.
It is set of activity that help the project team to identify and
track the requirements at any time ongoing project. It in-
volves communication between the project team members and
stakeholders. Eective Requirements management is solution
to Software Crisis.
a) It involves communication between the project team mem-
bers and stakeholders (students and lectures). Syllabus
change adding or removing subjects and update resources(notes)
these are main issue in managing requirements. Maintain-
ing new uploaded notes. Verication by privilege user can
reduce spams and viruses. The verication mark indica-
tion to every notes will give user proper clarication on
resource.
b) Simu

∗ Require Management is also systematic approach to

1. Eliciting
2. Organizing
3. Documenting
4. Managing

32
Six main steps are in Require Management
1. Investigation and Analyze Resources
2. Feasibility
3. Design and managing the scope of the system
4. construction and testing Resources upload by user
5. Requirement change management done by privilege users.
6. Release

The institutions may require that dierent members with dier-

ent levels of authorization should be allowed to view Notes that
they have access to, this can be accommodated with the help of
passwords and other means of authentication. This restricted
could also serve to restrict the ability to modify sensitive in-
formation to only those who have the authority to do so. The
product can also be modied to allow for share messaging be-
tween the members of a club, this may also need end to end
encryption to make sure that the account remain private. The
account could also be linked with email accounts so that the
privilege user can identify their members. volunteers and par-
ticipants about upcoming events. There can also be a connec-
tivity to new updated notes so that sharing Resources(notes).
In these and many other ways the product may be modied
as and when new requirements are given by the stakeholders.
This shows that the product is rugged and exible enough to
handle changes in requirements even late in its life.

33
7 CHAPTER 3: SYSTEM DESIGN
AND IMPLEMENTATION
7.1 Architecture of the Notes Repository

When referring to architecture; a concept is an idea, thought

or notion that forms the backbone and foundation of a design
project and one that drives it forward. It becomes the force
and identity behind a projects progress and is consistently con-
sulted throughout every stage of its development. Design is the
only way
we can accurately translate user requirements into a complete
software product or system. Without design we risk building
a unstable system that might fail if small changes are made.
The architectural style used in this system is the Data centered
style where in there exists a central data store or repository.
All the modules or components access this repository to store,
retrieve or manipulate data as a result of which any changes
made to the database will be updated and this updated version
is available to all modules. The main purpose of this style
is to achieve integrity of data. Data-centered architecture con-
sists of different components that communicate through shared
data repositories.

7.2 Design
Certain Standards are used while designing the architecture.
camelCase standards are used throughout in the code ex: eBay.
Each object starts with lowercase letter m followed by camel-
Case ex: mProgressBar. Classes, functions, objects are real
world entities so that the reader can easily understand the code

34
and readability of the code is enhanced.
Android studio a strong editor tool for developing creative UI
and emulators for dierent versions to test and simulate sensors
without having actual Android devices.
It also has a very useful Gradle plugin using which one can cre-
ate application les (apks) with dierent congurations. More-
over, it makes exporting and uploading apk on “play store”
easy with a single click. It also oers ANT build.
Firebase Realtime database is a cloud hosted database that
supports multiple platforms Android, iOS and Web. All the
data is stored in JSON format and any changes in data, reects
immediately by performing a sync across all the platforms &
devices. This allows us to build more exible real-time apps
easily with minimal eort.

7.3 DFD

35
7.4 Module Wise Algorithms

• Module for Login Page

//Check if user has entered email and password elds , if 'YES' proceed ,otherwise
toast error messages

if(validateEntries(email,password)){
mAuth.signInWithEmailAndPassword(email,password)
.addOnCompleteListener(new OnCompleteListener<AuthResult>() {
@Override
public void onComplete(@NonNull Task<AuthResult> task) {
if(task.isSuccessful()){
FirebaseUser user = mAuth.getCurrentUser();
updateUI(user);
}
else{
Toast.makeText(LoginPage.this,"Authentication failed",Toast.LENGTH_SHORT).show();
//updateUI(null);
}

}
} );
}
else
{
if(email.equals("")){
Toast.makeText(LoginPage.this,"Please Enter Email-ID",Toast.LENGTH_SHORT).show();
} else{
Toast.makeText(LoginPage.this,"Please Enter Password",Toast.LENGTH_SHORT).show();
}
}
}

36
} );

mForgotPasswordTextView.setOnClickListener(new View.OnClickListener() {

@Override

public void onClick(View v) {

startActivity(new Intent(LoginPage.this,ForgotPasswordPage.class));

} );

mSignUpTextView.setOnClickListener(new View.OnClickListener() {

@Override

public void onClick(View v) {

startActivity(new Intent(LoginPage.this,SignUpPage.class));

} );

@Override

public void onStart() {

super.onStart();
// Check if user is signed in (non-null) and update UI accordingly.

FirebaseUser currentUser = mAuth.getCurrentUser();

updateUI(currentUser);

37
private boolean validateEntries(String email,String password){
if(!email.equals("") & & !password.equals("")){
return true;
}

else {
return false;
}

private void updateUI(FirebaseUser user){

if(user != null){
// mSharedPreferenceCong.writeUserUID(user.getUid());

startActivity(new Intent(this,HomePage.class));

else{
Toast.makeText(LoginPage.this, "Login here", Toast.LENGTH_SHORT).show();

38
• Module for Reset Password
String userEmail = mEmailEditText.getText().toString();

if(isValidEntry(userEmail)){
mAuth.sendPasswordResetEmail(userEmail)
.addOnCompleteListener(new OnCompleteListener<Void>() {
@Override
public void onComplete(@NonNull Task<Void> task) {
if(task.isSuccessful()){
Toast.makeText(ForgotPasswordPage.this,"Please check your mail to reset your
password ",Toast.LENGTH_SHORT).show();
//startActivity(new Intent(ForgotPassword.this,LogIn.class));
}

else{
Toast.makeText(ForgotPasswordPage.this,"Oops! Some Error Occurred....Please
Try Again",Toast.LENGTH_SHORT).show();
}

} );

} );

/∗

∗ Function to check if email eld is not empty

∗∗/

39
private boolean isValidEntry(String mail){
if(mail!=null ){
if(mail.indexOf('@')>=0){
return true;
}

else{
Toast.makeText(ForgotPasswordPage.this,"Invalid email",Toast.LENGTH_SHORT).show();

return false;
}

else{
Toast.makeText(ForgotPasswordPage.this,"Please enter your E-mail address",Toast.LENGTH_

return false;
}

40
• Module for Download Adapter
public DownloadAdapter.DownloadViewHolder onCreateViewHolder(@NonNull
ViewGroup parent, int viewType) {

LayoutInater inater = LayoutInater.from(mContext);

View view = inater.inate(R.layout.notesviewholder,null);
return new DownloadAdapter.DownloadViewHolder(view);
}

@Override
public void onBindViewHolder(@NonNull nal DownloadViewHolder holder,
nal int position) {

holder.mDocName.setText(downloadModels.get(position).getDocName());
holder.mUri.setText(downloadModels.get(position).getUri());
holder.mDownload.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {

downloadFile(mContext,downloadModels.get(position).getDocName(),"pdf", DI-
RECTORY_DOWNLOADS, downloadModels.get(position).getUri());
}

} );

@Override

public int getItemCount() {

return downloadModels.size();

41
 }

public class DownloadViewHolder extends RecyclerView.ViewHolder {

TextView mDocName;

TextView mUri;

Button mDownload;

public DownloadViewHolder(@NonNull View itemView) {

super(itemView);
mDocName = itemView.ndViewById(R.id.DocNameTextView);

mDownload = itemView.ndViewById(R.id.DownloadButton);

mUri = itemView.ndViewById(R.id.UriTextView);

• Module for Download Manager

void downloadFile(Context context,String lename,String leExtension ,String

destinationDirectory,String url){

DownloadManager downloadManager = (DownloadManager) context

.getSystemService(Context.DOWNLOAD_SERVICE);

Uri uri = Uri.parse(url);

DownloadManager.Request request = new DownloadManager.Request(uri);

42
 request.setNoticationVisibility(DownloadManager.Request.VISIBILITY_VISIBLE_NOTIFY

request.setDestinationInExternalFilesDir(context,destinationDirectory,lename+leExtension)

downloadManager.enqueue(request);

• Module for Verication prole up-

dater

//mutlithreaded to increase the speed of the appeared

public class VeriedProleUpdater extends Thread{

FirebaseUser user;
FirebaseFirestore mFirestoreDB;
FirebaseAuth mAuth;
Activity mActivity;
Context mContext;
Map<String, Object> proleDetails = new HashMap<>();
ProgressBar mProgressBar;
FirebaseStorage mFirebaseStorage;

VeriedProleUpdater(Context context, Activity activity, Map<String,Object> pro-

leDetails, FirebaseUser user, FirebaseAuth auth, FirebaseFirestore db, FirebaseStor-
age mFirebaseStorage){

this.mContext = context;

43
this.proleDetails = proleDetails;
this.user = user;
this.mAuth = auth;
this.mFirestoreDB = db;
this.mActivity = activity;
this.mFirebaseStorage = mFirebaseStorage;

UploadDetails();

public void UploadDetails(){

mFirestoreDB.collection("users")

.document(user.getUid()).set(proleDetails).addOnSuccessListener(new OnSuccessLis-
tener<Void>() {

@Override

public void onSuccess(Void aVoid) {

Toast.makeText(mContext,"Account created successfully",Toast.LENGTH_SHORT).show();

mContext.startActivity(new Intent(mContext,HomePage.class));

} ).addOnFailureListener(new OnFailureListener() {

@Override

public void onFailure(@NonNull Exception e) {

Toast.makeText(mContext,"Error ! Try after sometime",Toast.LENGTH_SHORT).show();

user.delete()

44
.addOnCompleteListener(new OnCompleteListener<Void>() {

@Override

public void onComplete(@NonNull Task<Void> task) {

if(!task.isSuccessful()){
Toast.makeText(mContext,"Bug Report # 1",Toast.LENGTH_SHORT).show();

} );

} } )}

8 CHAPTER 4: SYSTEM TESTING

AND RESULT ANALYSIS
8.1 Plan and Data Collection of Testing
Testing and quality assurance denition
The plan for testing in our android application follows the steps
given below:
1. The content model for the Android App is reviewed to
uncover errors.
2. The interface model is reviewed to ensure that all use cases
can be accommodated.
3. The design model for the Android App is reviewed to un-
cover navigation errors.
4. The user interface is tested to uncover errors in presentation
45
and/or navigation mechanics.
5. Each functional component is unit tested.
6. Navigation throughout the architecture is tested.
7. The Android App is implemented in a variety of dierent
environmental congurations and is tested for compatibility with
each conguration.
8. Security tests are conducted in an attempt to exploit vul-
nerabilities in the Android App or within its environment.
9. Performance tests are conducted.
10. The Android App is tested by a controlled and monitored
population of end users. The results of their interaction with
the system are evaluated for content and navigation errors,
usability concerns, compatibility concerns, and Android App
reliability and performance.

46
Fig 8.1 Login Page Fig 8.2 Sign-up page

47
Fig 8.3 Home page Fig 8.4 Courses

48
Fig 8.5 Documents

8.2 Unit Testing

49
Test Number. Features Input Expected out- Actual output
put
Manage ac- Fill in the Email of the Email of the
counts along necessary elds user should user should
with rebase and click sign be added in be added in
authentication. up button. the rebase the rebase
authentication authentication
eld. eld.
Add details of Input all the Details such Details such
the user. elds in the as name, mo- as name, mo-
user verica- bile no., mail bile no., mail
tion page. should be should be
added to the added to the
user details user details
eld in the eld in the
rebase. rebase.
Password re- Input email Password is Password is
covery method. and click on reset using the reset using the
the link sent link provided link provided
to the mail by rebase. by rebase.
for recovery
options.
Semesters in Click on the Courses of Courses of
the form of button takes the respective the respective
recycler view. the user to semester are semester are
the respective listed. listed.
course page
view.
Courses in the Click on the Documents/notes Documents/notes
form of recycler button takes of the respec- of the respec-
view. the user to tive semester tive semester
the respective are listed. are listed.
notes page
view.
Notes in the Click on the PDF gets PDF gets
form of recycler download downloaded. downloaded
view. button down-
loads the pdf
through the
download
manager.
Logout button Clicking on the Log out logs Log out logs
in navigation logout button the user out. the user out.
drawer. logs out the
user. 50
Shared prefer- Checks if the If the user is If the user is
ence user was previ- logged in then logged in then
 8.3 Integration Testing
Integration Testing is a level of software testing where
individual units are combined and tested as a group. The pur-
pose of this level of testing is to expose faults in the interaction
between integrated units. All the units of the software are im-
plemented after integrating and the output of the software is
tested for correctness of the results. Sometimes when the the
units are integrated, the interaction between the various units
may pose errors due to which the desired or expected output
may not be obtained. Integration testing is done by giving
a variety of inputs to the integrated unit or nal product and
testing the working of the software.
When each of the module was created and was t to use, we had
to integrate the modules. When all the modules of our project
were integrated to build the complete website the behaviour of
the modules with each other were observed. We didn't face any
kind of problems while integrating the modules. The informa-
tion was shown as expected. The separate modules of down-
load adapter, forgot password, login page, download manager,
veried prole updater worked properly for each type of user.

8.4 Acceptance Testing

Acceptance testing, a testing technique performed to de-
termine whether or not the software system has met the re-
quirement specications. The main purpose of this test is to
evaluate the system's compliance with the business require-
ments and verify if it is has met the required criteria for deliv-
ery to end users.
The acceptance testing for the Notes Repository was performed
by the end users of the software, who are also the stakehold-

51
ers of the project. The demo of the software was shown to
the students and also to dierent lecturers of our institution.
The students and the lecturers tested the complete software
and successfully accepted all the features implemented and the
constraints that was taken into consideration for the develop-
ment of the software. All the features and functionalities of
the Notes Repository was demonstrated in a systematic and
predened manner. All the stakeholders approved the software
that is developed and are said to have accepted it.

Fig 8.4.1: Acceptance testing by Prof Ashritha R Murthy,

CSE Department

52
Fig 8.4.2: Acceptance testing by student

53
9 CHAPTER 5: CONCLUSION AND
FUTURE WORK
9.1 CONCLUSION
The main aim of our product is to provide services to the stake-
holders which make their task of managing or handling the
notes, proper usage in a more ecient and easier manner. The
product provides an easy to use platform for various students
both in the college and also who are at a distant place. Any
user can sign in to the software and can download the docu-
ments necessary, which in turn would have been veried by the
privilege members assigned by the faculty. The product pro-
vides a high level security as it is protected by a password The
main aim of our product is to provide services to the stake-
holders which make their task of great platform for the users.

It's not only the software we have developed, but

also we have taken a great initiative in saving the trees that
are being cut all year for the paper production as the amount
of paperwork is reduced. As we all know that preservation of
trees is a great concern and the need of the hour.

54
9.2 SCOPE OF FUTURE WORK
The Notes Repository project can include more number of mul-
tiple notes, text books and a complete video lecture related to
that particular topic of that particular subject if we have more
storage availability. Here we have used the rebase which pro-
vides us the maximum storage of 1 GB of storage space.
Right now we have only one privileged user who can upload,
delete, modify the documents that are put onto the rebase.
In future, we can have multiple number of users who can up-
load their own documents. These particular documents have
to be in turn veried by the privilege member. If the docu-
ments are not veried by the privilege member in a particular
amount of time the documents get automatically deleted from
the database.
Any student of a particular university can access the notes of
the other university. It can also be used in Distance learning
programs by dierent students who can get all the resources at
a single place rather than searching for them.

55
.

10 REFERENCES
• Software Engineering: A Practitioner's Approach by Roger
S Pressman.
• Ian Sommerville: Software Engineering, 10th Edition, Pear-
son Education Ltd, 2015.
•

• Udacity-Georgia Tech, Youtube Channel.

56