notes guru paper

8/7/2019 Notes Guru Paper

1/42

Notes Guru

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

Brooklyn College

12th May 2010


2/42

SoftwareRequirements 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].................................................................................52.4 Operating Environment.....................................................................................................6

2.5 Design and Implementation Constraints...........................................................................6

2.6 User Documentation..........................................................................................................6

2.7 Assumptions and Dependencies [1]..................................................................................62.7.1 Login requirements.....................................................................................................6

3. Use Cases..........................................................................................................7

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

3.2 Use Cases by user..........................................................................................................143.2.1 Use Cases associated with Student/Professor...........................................................143.2.2 Use Case associated with Professor.........................................................................183.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.....................................................................................................................234.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


3/42


5.1.1 Failed Case:..............................................................................................................255.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........................................................................................................386.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


4/42


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.2 Document Conventions [1]

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.


5/42


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.3 Project Scope [1]

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 Gurus 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.


6/42


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.

2.3 User Classes and Characteristics [1]

There will be 3 kinds of users for this system

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


7/42


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.

2.7 Assumptions and Dependencies [1]

2.7.1Login 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.


8/42


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]


9/42


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 elses.


10/42


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

doesnt 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


11/42


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.


12/42


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.


13/42


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.


14/42


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


15/42


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:


16/42


17/42


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.

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.

Rewrite

Review

ActiveNote

Submit Publish


18/42


Initial Step-By-Step Description

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.


Before this use case can be initiated, the Student has already logged in to the

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.


19/42


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:

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

Professor

ViewContact

Info


20/42


Use case: Publish Notes

Diagram:

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

Moderator

PublishNotes


21/42


4. Functional Requirements Specification

[1]

4.1 Register

Use Case

Name

Register

XRef Section 3.1.2, RegisterTrigger The User hears about NotesGuru, and decides to

joinPrecondition A User is a current Student/Professor at a

UniversityBasic Path 1. The User goes to the Login page and clicks on

Register2. The system asks for various details of the user3. The user clicks on Register4. The system validates the users email to be of

a university5. The system saves the users information into

the database

Alternative

Paths

None.

Postconditio

n

The user receives a notification that he is now a

member of NotesGuru.Exception

Paths

The user may abandon the operation at any time.

Other None

4.2 Login

Use Case

Name

Login


22/42


XRef Section 3.1.2, LoginTrigger 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 userslog in id and password.

2. The system throws up home page of the user.

Alternative

Paths

None.

Postconditio

n

The user is able to use all the subsequent page of

the system in as long as the session lasts.Exception

Paths

The user may abandon the operation at any time

Other None

4.3 Edit Profile

Use Case

Name

Edit Profile

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 button4. The system updates the database for the

changes made to the users profile.Alternative

Paths

None.

Postconditio

n

The selected changes are displayed to the Users

personal profile.Exception

Paths

The User may abandon the change operation

before they hit the save button.


23/42


Other None

4.4 Search Notes

Use Case

Name

Search Notes

XRef Section 3.1.1, Search NotesTrigger 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 byTopic.

2. If the search is by School, the system createsand presents an alphabetical list of all Schoolsin 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

Paths

In step 2, if the User selects to search by Course,the system creates and presents a list of all

Courses in the database.3. The User selects a Course.4. The system creates and presents a list ofall notes in that Course in the database. Returnto step 5.

In step 2, if the User selects to search by topic, thesystem presents a dialog box to enter the topic.The User enters a topic.

4. The system searches all notes with thattopic and creates and presents a list of all suchnotes in the database. Return to step 5.

Postconditio

n

The selected note is downloaded to the client

machine.

Exception

Paths

The User may abandon the search at any time.

Other The categories list is generated from the


24/42


information provided when note are published and

not predefined in the NotesGuru database.

4.5 Share Notes

Use Case

Name

Share Notes

XRef Section 3.1.1, Share NotesTrigger 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

Paths

None

Postconditio

n

The selected note is uploaded from the client

machine.Exception

Paths

The User may abandon the upload at any time.

Other This use case is followed by some work at the backend 1. The Moderator reviews the Note.2. Moderator Declines/ Publishes Note.

4.6 Comment on/Rate Notes

Use Case

Name

Comment on/Rate Notes

XRef Section 3.1.1, Comment on/Rate NotesTrigger The user decides to comment on a Note on the

NotesGuru Website.Precondition The user has accessed the Notes that have already


25/42


been uploaded by another user.

Basic Path 1. The user reads a particular Note and decidesto comment on/ Rate it.

2. The user goes to the Comment on/Rate NoteScreen.

3. The user rates Notes by clicking on therelevant star and/or types their comments inthe Comment Text Area

4. The user hits save.

Alternative

Paths

None

Postconditio

n

The comment/rating is saved to the system.

Exception

Paths

The User may abandon the operation at any time.

Other None

4.7 View Contact Information

Use Case

Name

View Contact

XRef Section 3.1.2, View ContactTrigger The Professor likes Notes/Profile of a particular

student.Precondition A Student has a profile on NotesGuruBasic 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

Paths

None.

Postconditio

n

None.

Exception The Professor may abandon the operation at any


26/42


Paths timeOther None

4.8 Publish Notes

Use Case

Name

Publish Notes

XRef Section 3.1.3, Publish NotesTrigger The Moderator receives a Note in his queue for

review.Precondition A user uploads notesBasic 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 button4. The system publishes the Note to the Authors

Profile.Alternative

Paths

None.

Postconditio

n

The author receives an update informing him of

the publishing of the Note.

Exception

Paths

The Moderator may abandon the operation before

they hit the publish button.Other None

5. Sequence, Class and CRC Diagrams

5.1 Sequence diagram for Searching Notes

5.1.1Failed Case:


27/42


5.1.1 Successful Case:


28/42


5.2 Sequence diagram for Sharing Notes


29/42



30/42


5.3 Class diagram


31/42


5.4 CRC diagram


32/42


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.


33/42


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.


34/42


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.


35/42


36/42


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.


37/42


6.6 Comment/Rate Sample Interface

This interface will be used by the students to comment on/rate notes uploaded

by other students.


38/42


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.


39/42


6.8 Screen Flow

6.9 Hardware Interfaces

There are no specific hardware interfaces for this system.


40/42


6.10Software Interfaces

Along with the internet connection, the system makes indirect use of an

internet browser. Outside of the HTML code and PHP, the code doesnt tell any

software, including the browser, what to do.

6.11Communications 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.


41/42


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 IDs 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
http://www.processimpact.com/http://www.gradeguru.com/http://www.processimpact.com/http://www.gradeguru.com/


42/42


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

notes guru paper

Documents