Notes Guru: Prepared By: Dipali Mhetre, Aparna Patil, Jia Bin Huang

Notes Guru
Prepared by: Dipali Mhetre, Aparna Patil, Jia Bin Huang
Brooklyn College
12th May 2010

Software Requirements Specification for Notes Guru Page 1
Table of Contents
Table of Contents.................................................................................................1
1. Introduction......................................................................................................3
1.1 Purpose ............................................................................................................................3

1.2 Document Conventions [1]................................................................................................3
1.3 Project Scope [1]...............................................................................................................4
2. Overall Description............................................................................................5
2.1 Product Perspective...........................................................................................................5

2.2 Product Features...............................................................................................................5
2.3 User Classes and Characteristics [1].................................................................................5
2.4 Operating Environment.....................................................................................................6
2.5 Design and Implementation Constraints...........................................................................6
2.6 User Documentation..........................................................................................................6
2.7 Assumptions and Dependencies [1]..................................................................................6
2.7.1 Login requirements.....................................................................................................6
3. Use Cases..........................................................................................................7
3.1 Use cases by Module........................................................................................................7

3.2 Use Cases by user..........................................................................................................14
3.2.1 Use Cases associated with Student/Professor...........................................................14
3.2.2 Use Case associated with Professor.........................................................................18
3.2.3 Use Case associated with Moderator........................................................................18
4. Functional Requirements Specification [1].......................................................20
4.1 Register...........................................................................................................................20
4.2 Login................................................................................................................................20
4.3 Edit Profile.......................................................................................................................21
4.4 Search Notes...................................................................................................................22
4.5 Share Notes.....................................................................................................................23
4.6 Comment on/Rate Notes.................................................................................................23
4.7 View Contact Information................................................................................................24
4.8 Publish Notes...................................................................................................................25
5. Sequence, Class and CRC Diagrams..................................................................25
5.1 Sequence diagram for Searching Notes –........................................................................25

5.1.1 Failed Case:..............................................................................................................25

5.1.1 Successful Case:.......................................................................................................26
5.2 Sequence diagram for Sharing Notes –...........................................................................27
5.3 Class diagram –...............................................................................................................29
5.4 CRC diagram –.................................................................................................................30
6. User Interfaces................................................................................................31
6.1 Login / Sign up Sample Interface.....................................................................................31
..........................................................................................................................31
6.2 Home Page Sample Interface..........................................................................................32

6.3 User Profile Sample Interface..........................................................................................33
.............................................................................................................................................33
6.4 Search Notes Sample Interface.......................................................................................34
.............................................................................................................................................34
6.5 Share Notes Sample Interface.........................................................................................35
.............................................................................................................................................35
6.6 Comment/Rate Sample Interface....................................................................................36
.............................................................................................................................................36
6.7 View contact Sample Interface........................................................................................37
.............................................................................................................................................37
6.8 Screen Flow.....................................................................................................................38
6.9 Hardware Interfaces........................................................................................................38
6.10 Software Interfaces.......................................................................................................39
6.11 Communications Interfaces...........................................................................................39
7. Other Nonfunctional Requirements...................................................................39
7.1 Performance Requirements.............................................................................................39

7.2 Safety Requirements.......................................................................................................39
7.3 Security Requirements....................................................................................................40
8. Other Requirements.........................................................................................40
Appendix A: Glossary..........................................................................................40
References...........................................................................................................................40
1. Introduction
1.1 Purpose
The purpose of this document is to present a detailed description of the
Knowledge Sharing System. It will explain the purpose and features of the
system, the interfaces of the system, what the system will do, the constraints
under which it must operate and how the system will react to external stimuli.
It will also explain the working of the system through diagrams and use cases.
This document is intended for both the stakeholders and the developers of the
system and will be proposed to the Brooklyn College Computer Science
Department for its approval.
[1]
1.2 Document Conventions
The next chapter, the Overall Description section, of this document gives
an overview of the functionality of the product. It describes the use classes
and is used to establish a context for the use cases in the next chapter.
The fourth chapter, Requirements Specification section, of this document
is written primarily for the developers and describes in technical terms the
details of the functionality of the product.
Both sections of the document describe the same software product in its
entirety, but are intended for different audiences and thus use different
language.
[1]
1.3 Project Scope
This Knowledge Sharing system will provide a social learning environment to
students where they can share their study materials, engage in collaborative
learning and get peer-feedback while building their online academic profiles
for internships and career opportunities. Notes Guru’s university and class
specific communities will provide a relevant and intuitive social learning
environment for thousands of students form universities across the globe.
More specifically this system will allow students to submit notes to the
website, which will then be reviewed by moderators and then published to the
website. The professors are a different set of users who can view various notes
and comment on them and can contact the students for various research
opportunities. The more notes a student uploads the more points they earn,
which can then be converted to badges and can mean additional career
opportunities.
2. Overall Description
2.1 Product Perspective
This is a new and independent system. It may however be linked with other
social networking sites in the future.
2.2 Product Features
The system will have the following features:
• User register to system
• User login to system
• User searches for Notes [2]
• User shares Notes, uploads them to the system [2]
• User edits their Profile
• User posts comment/rates particular Notes [2]
• Professor views contact information of student for Research opportunity.
[1]
2.3 User Classes and Characteristics
There will be 3 kinds of users for this system –
Students: Students may search notes, upload notes, comment on notes

Professors: Professors will have the same rights as students; they may use the
system to view contact information for student for their Research
Projects/Programs.
Moderators: Moderators have special rights to publish/delete Notes. Checking
notes of students is their main job, i.e. for plagiarism, etc.
2.4 Operating Environment
The system is web-based and will be hosted by a web server. It can be viewed
by any web browser, and has been tested for compliance with Mozilla, Internet
Explorer, Netscape Navigator, and Opera.
2.5 Design and Implementation Constraints
There are no constraints as of now.
2.6 User Documentation
User documentation will be available in the form of online help, which will be a
part of the system itself.
[1]
2.7 Assumptions and Dependencies
2.7.1 Login requirements
To make a valid registration a user must have a legitimate university e-mail id.
This is true for both the Student and Professors, the moderator on the other
hand can be given special registration incentives.

3. Use Cases
3.1 Use cases by Module
According to David Lorge Parnas, structural description of a system is an
effective way to explain the work flow through the system; it essentially
requires decomposition of the system. One of the best ways to decompose the
system is to divide it into different ‘modules’. Module of a system is task
specific; it might contain one or more programs to accomplish the task. [3]
Keeping that in mind, we have divided our system in 6 basic modules –
• Access Notes
• Share Notes
• Peer Evaluation
• Access Member Information
• Access Personal Information
• Backend Information Management
Use case Associated with Modules [4] –

With the help of this module a user (registered or unregistered) can Read
Notes, Rate Notes and Search for notes. The Use case diagram also shows a
generalization between the ‘Search Notes’ Use cases because notes can be
searched in various ways like search by topic, search by University or search
by course. There are commonalities in their behavior, purpose and structure in
the search notes use cases. The ‘Delete Notes’ use- case shows an “extends”
relationship with the ‘Validate User’ use case, since only a valid user can
delete notes. Clearly, a user can delete only his notes and not anyone else’s.
In the ‘Share Notes’ module, the ‘User’ is essentially a registered member of
the system. ‘User’ is an active actor who initiates various actions whereas,
‘Notes Repository’ is a passive actor who participates in various tasks but
doesn’t actively initiate any action. This module enables the user to
submit/post notes onto the system. The notes are thoroughly moderated
before approval to avoid plagiarism and publishing of anything inappropriate.
When a user submits notes they are temporarily stored into a buffer.
Moderators evaluate the notes and make a decision either Publishing/Declining
them. The ‘Publish Notes’ Use case is extended by ‘Upload/Change Data’ Use
case, which makes appropriate changes into the ‘Data Repository’. If the notes
are declined ‘Clear Buffer’ will simply clear the notes from the temporary
buffer.
User can read comments and post comments using this module. The
comments and ratings are immediately posted once the user confirms them.
The ‘Upload/Change Data’ is an extended use case which makes the changes
in the ‘Notes Repository’. A user can delete only his/her notes. Thus, the
‘Validate User’ Use case checks the authenticity of user.

The system has imposed some restrictions over accessing member
information. Only privileged users (Registered Professors) have the right to
view contact details of all the registered members, send emails to other
members and search for other professors. A registered student can only view
profiles of the members and can search for member students. The
generalization on ‘Search Student’ Use case suggests that the system give the
user options to search by University or search by course.

An unregistered user can register into the system using this module. Once a
user completes the registration requirements additions are made into the
‘Member Information Database’ using the ‘Upload/Change Data’ Use case.
Using this module a registered user can login to the system and change
his/her personal information. The authentication of the user is checked before
making any changes.

There are lots of processes that work at the back-end of the system, not
directly visible to the user. Every registered member is allotted points
depending upon the ratings on his uploads. ‘Calculate Points’ is an automated
function which is performed on the ‘Member Information Database’.
Registered students having a gold batch are shortlisted by the ‘Shortlist
Potential Students’ use case. Emails about career opportunities are sent to
these students by the system. Any change detected is extended by the

‘Upload/Change Data’ Use case to make the appropriate changes into the
database or in the repository.
3.2 Use Cases by user
This section outlines the use cases for each of the active users
separately. The Moderator has only one use case apiece while the Student is
main actor in this system. The Use cases for the Professor are the same as for
the Student, except for View contact information for another user.
3.2.1 Use Cases associated with Student/Professor
Diagram:
Use case: Search Notes
Brief Description
The Student accesses the system, searches for notes and downloads it to their
machine.
Initial Step-By-Step Description
Before this use case can be initiated, the Student has already logged in to the
system.
1. The Student chooses to search by University, Topic or Course.
2. The system displays the choices to the Student.
3. The Student selects the Notes desired.
4. The Student chooses to download the Notes.
5. The system provides the requested Notes.
XRef: Section 4.4, Search Notes
Use case: Share Notes
Brief Description
The Student accesses the system, to share their notes and uploads it to the
system.
system.
1. The system displays the choices to the Student.

2. The Student chooses to share by Scanned or Digital Format.
3. The Student browses the Notes file on his machine.
4. The Student chooses to upload the Notes.
5. The system uploads the requested Notes.
XRef: Section 4.5, Share Notes
The System then goes on to the Review process for the Notes carried on by
the team of Moderators, before the Notes are published on to the system.
Rewrit Review
e
Active
Note
Submit Publish
Figure 1 - Notes Submission Process
The Notes Submission Process state-transition diagram summarizes the
process listed above. A Student submits a Note for consideration. The
Moderator reviews the Note for plagiarism and other potential copyright
violations. Either the Note is accepted as written, declined, or the Student is
asked to make some changes based on the reviews. Not shown in the above is
the removal of declined Notes from the system.
Use case: Comment/Rate Notes
Brief Description
The user accesses the system, to comment and rate the notes.
Before this use case can be initiated, the user has already logged in to the
system.
1. The user reads the notes and decides to write comments on the notes
and/or rate the notes.
2. The system displays screen where the user can write comments and rate
the notes.
3. Once the user finishes writing comments and/or rating the notes he
confirms it.
4. The comments and ratings are immediately posted on the website specific
to the notes.
XRef: Section 4.6, Comment/Rate Notes
Use case: Edit Profile
Brief Description
The Student accesses the system, to edit their Personal details on the system.
system and are accessing their profile page.
6. The system displays the details to the Student.
7. The Student chooses the detail to be edited.
8. The Student chooses save the change.
9. The system saves the changes to the Students Profile.

XRef: Section 4.3, Edit Profile
3.2.2 Use Case associated with Professor
This is in addition to the use cases similar to the Student.
Use case: View Contact Information
Diagram:
View
Contact
Info
Professo
r
Brief Description
The Professor likes Notes published by a student and has a Research
opportunity for that student.
Before this use case can be initiated, the Professor has already logged in to
the system.
1. The Professor views Notes by a particular Student.
2. The Professor clicks on the Students name and views their contact
information.
XRef: Section 4.7, View Contact Information
3.2.3 Use Case associated with Moderator

Use case: Publish Notes
Diagram:
Publish
Notes
Moderat
or
Brief Description
The Moderator reviews Notes and publishes them
Before this use case can be initiated, the Moderator has already logged in to
the system.
3. The system assigns the Moderator a Note that has to be reviewed.
4. The Moderator reviews the Note.
5. The Moderator chooses to either Decline or Publish the Note.
The Decline of the Notes is not explained here.
XRef: Section 4.8, Publish Notes

4. Functional Requirements Specification
[1]
4.1 Register
Use Case Register
Name
XRef Section 3.1.2, Register
Trigger The User hears about NotesGuru, and decides to
join
Precondition A User is a current Student/Professor at a
University
Basic Path 1. The User goes to the Login page and clicks on
Register
2. The system asks for various details of the user
3. The user clicks on Register
4. The system validates the users email to be of
a university
5. The system saves the users information into
the database
Alternative None.
Paths
Postconditio The user receives a notification that he is now a
n member of NotesGuru.
Exception The user may abandon the operation at any time.
Paths
Other None
4.2 Login
Use Case Login
Name
XRef Section 3.1.2, Login

Trigger The Professor likes Notes/Profile of a particular
student.
Precondition A Student has a profile on NotesGuru
Basic Path 1. The System checks the validity of the users
log in id and password.
2. The system throws up home page of the user.
Alternative None.
Paths
Postconditio The user is able to use all the subsequent page of
n the system in as long as the session lasts.

Exception The user may abandon the operation at any time
Paths
Other None
4.3 Edit Profile
Use Case Edit Profile
Name
XRef Section 3.1.1, Edit Profile
Trigger The user assesses their profile on the NotesGuru
Website.
Precondition The Web is displayed with personal details.
Basic Path 1. The system displays personal details with
option to change.
2. The user makes desired change.
3. The user clicks on the save button
4. The system updates the database for the
changes made to the user’s profile.
Alternative None.
Paths
Postconditio The selected changes are displayed to the Users
n personal profile.
Exception The User may abandon the change operation
Paths before they hit the save button.

Other None
4.4 Search Notes
Use Case Search Notes
Name
XRef Section 3.1.1, Search Notes
Trigger The user assesses the NotesGuru Website.
Precondition The Web is displayed with grids for searching.
Basic Path 1. The user chooses how to search the Web site.
The choices are by School, by Course, and by
Topic.
2. If the search is by School, the system creates
and presents an alphabetical list of all Schools
in the database.
3. The user selects a School.
4. The system creates and presents a list of all
notes by that School in the database.
5. The User selects a note.
6. The system displays the Note.
7. The User selects to download the note or to
return to the note list or to the previous list.
Alternative In step 2, if the User selects to search by Course,
the system creates and presents a list of all
Paths Courses in the database.
3. The User selects a Course.
4. The system creates and presents a list of
all notes in that Course in the database. Return
to step 5.
In step 2, if the User selects to search by topic, the
system presents a dialog box to enter the topic.
The User enters a topic.
4. The system searches all notes with that
topic and creates and presents a list of all such
notes in the database. Return to step 5.
Postconditio The selected note is downloaded to the client
n machine.
Exception The User may abandon the search at any time.
Paths
Other The categories list is generated from the
information provided when note are published and
not predefined in the NotesGuru database.
4.5 Share Notes
Use Case Share Notes
Name
XRef Section 3.1.1, Share Notes
Trigger The user decides to upload a Note to the
NotesGuru Website.
Precondition The user has accessed the Share Notes screen.
Basic Path 1. The user chooses how to upload Notes to the
Web site. The choices are Digital and Scanned.
2. In either of the choice the system lets the user
choose a file from their system.
3. The user uploads the file to the website.
Alternative None
Paths
Postconditio The selected note is uploaded from the client
n machine.
Exception The User may abandon the upload at any time.
Paths
Other This use case is followed by some work at the back
end –
1. The Moderator reviews the Note.
2. Moderator Declines/ Publishes Note.
4.6 Comment on/Rate Notes
Use Case Comment on/Rate Notes
Name
XRef Section 3.1.1, Comment on/Rate Notes
Trigger The user decides to comment on a Note on the
NotesGuru Website.
Precondition The user has accessed the Notes that have already
been uploaded by another user.

Basic Path 1. The user reads a particular Note and decides
to comment on/ Rate it.
2. The user goes to the Comment on/Rate Note
Screen.
3. The user rates Notes by clicking on the
relevant star and/or types their comments in
the Comment Text Area
4. The user hits save.
Alternative None
Paths
Postconditio The comment/rating is saved to the system.
n
Exception The User may abandon the operation at any time.
Paths
Other None
4.7 View Contact Information
Use Case View Contact
Name
XRef Section 3.1.2, View Contact
Trigger The Professor likes Notes/Profile of a particular
student.
Precondition A Student has a profile on NotesGuru
Basic Path 1. The system checks for the rights of the user to
be that of the Professor.
2. The user clicks on the Students Name.
3. The system throws up contact information of
the Student.
Alternative None.
Paths
Postconditio None.
n
Exception The Professor may abandon the operation at any
Paths time
Other None
4.8 Publish Notes
Use Case Publish Notes
Name
XRef Section 3.1.3, Publish Notes
Trigger The Moderator receives a Note in his queue for
review.
Precondition A user uploads notes
Basic Path 1. The system checks for the rights of the user to
be that of the moderator.
2. The user reviews the Note.
3. The user clicks on the Publish button
4. The system publishes the Note to the Authors
Profile.
Alternative None.
Paths
Postconditio The author receives an update informing him of
n the publishing of the Note.

Exception The Moderator may abandon the operation before
Paths they hit the publish button.

Other None
5. Sequence, Class and CRC Diagrams
5.1 Sequence diagram for Searching Notes –
5.1.1 Failed Case:

5.1.1 Successful Case:

5.2 Sequence diagram for Sharing Notes –

5.3 Class diagram –

5.4 CRC diagram –

6. User Interfaces
6.1 Login / Sign up Sample Interface
This is the very first page that the users will see, where a first time user signs
up or an existing user logs in to the system.

6.2 Home Page Sample Interface
This interface is the home page for that particular user, which lists all the
notes uploaded by the student until then and their respective ratings. It also
displays the Reward points accumulated by the user until then.

6.3 User Profile Sample Interface
This interface will be used by the users to view their profile. It contains all the
personal details of that particular user.

6.4 Search Notes Sample Interface
This interface will be used by the students to search based on three different
criteria, i.e. University, Course and Topic.

6.5 Share Notes Sample Interface
This interface will be used by the students to upload notes, either in digital or
scanned format. If the notes are in digital format, they will be saved as a
.txt, .doc files etc. or if they are in scanned format they will be saved as .jpg,
.gif files etc.

6.6 Comment/Rate Sample Interface
This interface will be used by the students to comment on/rate notes uploaded
by other students.
6.7 View contact Sample Interface
This interface is same as View profile interface, the only difference is that a
professor will see the students’ email id, in order for them to be able to
contact for internship/research opportunities.

6.8 Screen Flow
6.9 Hardware Interfaces
There are no specific hardware interfaces for this system.

6.10 Software Interfaces
Along with the internet connection, the system makes indirect use of an
internet browser. Outside of the HTML code and PHP, the code doesn’t tell any
software, including the browser, what to do.
6.11 Communications Interfaces
The system uses an internet connection to connect to the database. The code
itself though, does not specifically direct the network controllers to do any
work.
7. Other Nonfunctional Requirements
7.1 Performance Requirements
The NotesGuru system should be hosted on a server that can provide
adequate response times. Students who are a huge part of the client base,
generally tend to have a fast pace and small attention span, hence a slow
server would not suffice.
7.2 Safety Requirements
There are no specific safety requirements for this system.

7.3 Security Requirements
Access to the database should be restricted to people that are required to view
information about Students and Notes. Passwords and ID’s should be
regulated to be at least a certain length and must contain non-alphanumeric
characters in both the password and ID.
8. Other Requirements
The system may be linked to other social networking websites like Facebook
and twitter in the future.
Appendix A: Glossary
Author: Student or User who is the author of the Notes.
References
[1] www.processimpact.com - SRS outline template
[2] www.gradeguru.com – Some features of the system got inspiration from
this website
[3] David Parnas - Paper on ‘Software Engineering Principles’

[4] Booch, Rumbaug and Jacobson - Book ‘Unified modeling language guide’

Notes Guru: Prepared By: Dipali Mhetre, Aparna Patil, Jia Bin Huang

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Notes Guru: Prepared By: Dipali Mhetre, Aparna Patil, Jia Bin Huang

Uploaded by

Copyright:

Available Formats

Notes Guru

Prepared by: Dipali Mhetre, Aparna Patil, Jia Bin Huang

12th May 2010

1.1 Purpose ............................................................................................................................3

2.1 Product Perspective...........................................................................................................5

3.1 Use cases by Module........................................................................................................7

4. Functional Requirements Specification [1].......................................................20

5. Sequence, Class and CRC Diagrams..................................................................25

5.1 Sequence diagram for Searching Notes –........................................................................25

5.1.1 Failed Case:..............................................................................................................25

6.1 Login / Sign up Sample Interface.....................................................................................31

6.2 Home Page Sample Interface..........................................................................................32

7. Other Nonfunctional Requirements...................................................................39

7.1 Performance Requirements.............................................................................................39

The purpose of this document is to present a detailed description of the

system and will be proposed to the Brooklyn College Computer Science

Department for its approval.

an overview of the functionality of the product. It describes the use classes

The fourth chapter, Requirements Specification section, of this document

details of the functionality of the product.

This Knowledge Sharing system will provide a social learning environment to

specific communities will provide a relevant and intuitive social learning

environment for thousands of students form universities across the globe.

2.1 Product Perspective

social networking sites in the future.

2.2 Product Features

The system will have the following features:

• User register to system

• User login to system

• User searches for Notes [2]

• User shares Notes, uploads them to the system [2]

• User edits their Profile

• User posts comment/rates particular Notes [2]

• Professor views contact information of student for Research opportunity.

There will be 3 kinds of users for this system –

Students: Students may search notes, upload notes, comment on notes

system to view contact information for student for their Research

Moderators: Moderators have special rights to publish/delete Notes. Checking

notes of students is their main job, i.e. for plagiarism, etc.

2.4 Operating Environment

Explorer, Netscape Navigator, and Opera.

2.5 Design and Implementation Constraints

There are no constraints as of now.

2.6 User Documentation

part of the system itself.

2.7.1 Login requirements

hand can be given special registration incentives.

3.1 Use cases by Module

According to David Lorge Parnas, structural description of a system is an

system is to divide it into different ‘modules’. Module of a system is task

Keeping that in mind, we have divided our system in 6 basic modules –

• Access Member Information

• Access Personal Information

• Backend Information Management

Use case Associated with Modules [4] –

searched in various ways like search by topic, search by University or search

by course. There are commonalities in their behavior, purpose and structure in

In the ‘Share Notes’ module, the ‘User’ is essentially a registered member of

‘Notes Repository’ is a passive actor who participates in various tasks but

before approval to avoid plagiarism and publishing of anything inappropriate.

Moderators evaluate the notes and make a decision either Publishing/Declining

‘Validate User’ Use case checks the authenticity of user.

The system has imposed some restrictions over accessing member