Software Project Management: Software Requirement Specification

ResearchColab

Software Requirement Specification

Team: Reckless 7

Institute of Information Technology University of Dhaka

25 November, 2016

i

Executive Summery

ResearchColab is a research collaboration and data collection platform. Here researchers can submit their draft papers to professional reviewers for review purpose. They can also share research ideas and get data that is required to conduct their research. Researchcolab.com will be a web based platform for the researchers and paper reviewers to interact with each other. To avail the service, each user needs to register in the system. Researchers will post review jobs on the website and reviewers will bid for the review. Then the researcher will choose the most suitable candidate, and have a one to one communication with the person in order to hire him for the paper review. If satisfied, the researcher can hire the reviewer for the review job. Researches can also post data on the website that can be used in further researches. The data can either be free or paid. Researchers can also discuss research related issues in discussion boards.

ii

Contents

Introduction .......................................................................................................................... 1

1.1 Purpose ............................................................................................................................................... 1

1.2 Intended Audience .............................................................................................................................. 1

Inception ............................................................................................................................... 3

2.1 Introduction ........................................................................................................................................ 3

2.2 Identifying Stakeholders ..................................................................................................................... 3

2.3 Recognizing Multiple View Points ....................................................................................................... 4

2.4 Working towards Collaboration .......................................................................................................... 6

2.5 Conclusion ........................................................................................................................................... 7

Elicitation .............................................................................................................................. 8

3.1 Introduction ........................................................................................................................................ 8

3.2 Eliciting Requirements ........................................................................................................................ 8

3.3 Collaborative Requirements Gathering .............................................................................................. 8

3.4 Quality Function Deployment ............................................................................................................. 9

3.5 Usage Scenario .................................................................................................................................... 9

3.6 Elicitation Work Product ................................................................................................................... 11

Scenario-Based Model ......................................................................................................... 12

4.1 Introduction ...................................................................................................................................... 12

4.2 Use Case Scenario ............................................................................................................................. 12

4.3 Use Case Description ........................................................................................................................ 15

4.3.1 ResearchColab ................................................................................................................................ 15

4.3.1.1 Authentication ............................................................................................................................ 16

4.3.1.2 Review Management .................................................................................................................. 18

4.3.1.3 Data Sharing ................................................................................................................................ 22

4.3.1.4 Discussion Room ......................................................................................................................... 24

4.3.1.5 Profile Management ................................................................................................................... 27

Data Model ......................................................................................................................... 29

5.1 Introduction ...................................................................................................................................... 29

5.2 Data Object Selection ........................................................................................................................ 29

5.3 Data Objects and Attributes ............................................................................................................. 31

5.4 E-R Diagram ....................................................................................................................................... 32

Class-Based Model .............................................................................................................. 33

iii

6.1 Purpose ............................................................................................................................................. 33

6.2 General Classification ........................................................................................................................ 33

6.3 Selection Characteristics ................................................................................................................... 35

6.4 Attribute Selection ............................................................................................................................ 38

6.5 Method Selection .............................................................................................................................. 38

6.6 Class Diagram .................................................................................................................................... 40

6.7 Class Card .......................................................................................................................................... 41

Behavioral Model ................................................................................................................ 44

7.1 Purpose ............................................................................................................................................. 44

7.2 Identifying Events.............................................................................................................................. 44

7.3 Sequence Diagram ............................................................................................................................ 46

Conclusion ........................................................................................................................... 51

1

Chapter-1

Introduction

1.1 Purpose

This is the Software Requirements Specification (SRS) for ResearchColab. The document contains detailed functional, non-functional, and support requirements for the project. It also establishes a baseline for the development of the system in respect of the analyzed requirements.

This SRS serves as the ground of presenting user requirements to the developer. It provides a common reference point for both the developer team and stakeholder community. This document’s content may evolve over time as users and developers work together in developing the system. But its fundamental output will remain unchanged.

1.2 Intended Audience

This SRS is intended for all the stakeholders related to ResearchColab - project managers, system analyst, designers, developers and quality assurance engineers. They will use it for the following reasons-

The project managers will design their plan on the basis of this document. They will set milestones and delivery dates. They will also ensure that the development team is on track.

The system analyst will utilize this document in order to solve the problem domain and build up an effective architecture that the developers will implement.

The designers will prepare the systems design based on this document. They will continually refer back to this SRS to ensure that the system they are designing will fulfill the customers’ needs.

Developers will use this document as a basis for developing the system’s functionality. The developers will link the requirements defined in this SRS to the

2

software they create to ensure that they have created software that will fulfill all of the customers’ documented requirements.

Quality assurance engineers will use the SRS to derive test plans and test cases. When portions of the software are complete, they will run their tests on that software to ensure that the software fulfills the requirements documented in this SRS. They will again run their tests on the entire system when it is complete and ensure that all requirements documented in this SRS have been completed.

3

Chapter-2

Inception

2.1 Introduction

At this chapter we have analyzed the scope and the nature of problem in hand. We have identified the concurrent needs and conflict requirements among the stakeholders of ResearchColab. To establish the groundwork, we have worked with the following factors:

Identifying Stakeholders

Recognizing Multiple Viewpoints

Working towards Collaboration

2.2 Identifying Stakeholders

For this project, we have determined the stakeholder as the person or group who will be affected by the system directly or indirectly. Out stakeholders mainly consists of end-users who interact with the system. Although, we intend to develop ResearchColab for industrial use, we are building it for using only in the IIT premises for the sake of this project. For this reason, we have selected the stakeholders from the scope of IIT only. To identify the stakeholders, considered the following facts:

o Who will be using the project outcomes? o Who gets to make the decisions about the project? o Who has resources I need to get the project done? o Whose work will my project affect? (During the project and also once the

project is completed)

Concluding thoughts on Stakeholders, we identified following stakeholders for our project:

1. Course coordinator: The Course coordinator is the person who has the final authority over our finished product. His position empowers him to veto a decision made

4

by the other Stakeholders. As head of the course, he has direct authority over the resources and our team— the people developing the web application and doing much of the “management” end of this project.

2. Researchers: The researchers are the ultimate user of the final developed product. We have considered the students of final year of BBSE program and the students of Master’s program of IIT as the researchers of our domain.

3. Paper reviewers: The reviewers will be another important end user along with the researchers. That’s why we have considered them as our stakeholders. But our limitation does not permit us to have an interview of a range of reviewers. That’s why we have talked with the faculty members from IIT in order to get a basic idea regarding the requirements and developed a baseline of requirement according to our understanding.

4. Project manager: The success and failure of this project is fully depended on project manager. Moreover, further development, change management, every steps of the life cycle of software development will be coordinated and monitored by the project manager.

5. Developers: We have selected developers as stakeholders because they will develop this system and work for further development. If any system interruption occurs, they will find the problem and try to solve it.

6. QA engineers: Quality Assurance Engineer will control the quality of the product, test to find bug. They need to refer to this documentation and validate the final product and check if it’s up to the mark or not.

2.3 Recognizing Multiple View Points

We have collected the following view points by discussing with our stakeholders.

1. Course coordinator:

a. A proper documentation incorporating all the software engineering phases should be made with the product.

b. The product needs to innovative and needs to address some sort of real world problem of the users.

5

c. The project development team needs to follow all the required steps of the software engineering process.

2. Researchers:

a. The UI needs to be user friendly and easily accessible.

b. The discussion forum needs to be navigation friendly. And any topic can be searched efficiently.

c. The system can be accessible through the browser from anywhere and anytime.

d. There needs to be a separate mobile friendly version for the website.

e. A strong security system should be imposed here. And all sorts of privacy issues need to be taken care of.

3. Paper reviewers:

a. There needs to be a secured way of payment and any type of issues regarding payment needs to be resolved effectively.

b. The UI needs to be user friendly.

c. The whole system needs to be strongly secured.

4. Project manager:

a. The product should be maintained easily.

b. A proper documentation incorporating all the software engineering phases should be made with the product.

c. Allocating resources in such a way so that every resource will be available on demand basis.

5. Developers:

a. Documentation regarding the development needs to be done properly, so that any future issues can be resolved easily.

6

b. The product design and architecture, software development lifecycle needs to be defined clearly and effectively so that the developers know what to do.

6. Quality assurance engineers:

a. Documentation regarding the requirement analysis needs to be done properly so that the end product can be tested properly.

2.4 Working towards Collaboration

Every stakeholder has their own requirements. We followed following steps to merge these requirements:

Identify the common and conflicting requirements

Categorize the requirements

Take priority points for each requirement from stakeholders and on the basis of this voting prioritize the requirements

Make final decision about the requirements

Common Requirements:

User will be able to post review request

Any user will be able to bid on a review post

Dataset can be shared by all users

Users can open discussion room and post comment there

User friendliness

Security

Proper documentation

Conflicting Requirements:

Ease of access and strong security

Final Requirements:

We finalized following requirements for the system by categorizing and prioritizing the requirements:

The UI will be user friendly and easily accessible. There needs to be effective search function and other functionality.

7

User will be able to post review request and any other user will be able to bid on that

Dataset can be shared by all users

Users can open discussion room and post comment there The system will be highly secured. Any issues related the payment and

privacy will be handled effectively.

2.5 Conclusion

Inception phase helped us to establish basic understanding about ResearchColab; identify the people who will be benefited if this software is developed, define the nature of the software and establish a preliminary communication with our stakeholders.

8

Chapter-3

Elicitation

3.1 Introduction

Elicitation helps the customer to define the requirement more specifically. This phase faces many problems like- problems of scope, problems of volatility, and problems of understanding. To overcome these problems, we have worked in an organized and systematic manner.

3.2 Eliciting Requirements

Unlike Inception, where Question and Answer approach is used, Elicitation makes use of a requirements elicitation format that combines the elements of problem solving, elaboration, negotiation, and specification. It requires the cooperation of a group of end-users and developers to elicit requirements.

3.3 Collaborative Requirements Gathering

There are many different approaches to collaborative requirements gathering. Each approach makes use of a slightly different scenario. We followed the subsequent steps to do it:

i. Meetings were conducted with probable clients, researchers and data scientists. They were questioned about their requirements and expectations from the tool.

ii. They were asked about the problems they are facing in their work. We also inquired regarding the efficiency of the current process.

iii. At last we selected our final requirement list from these meetings.

9

3.4 Quality Function Deployment

The technique which translates the needs of the customer into technical requirements for software is called Quality Function Deployment (QFD).

QFD concentrates on maximizing customer satisfaction from the Software Engineering process. With respect to our project the following requirements are identified by QFD-

User will be able to post review request and any other user will be able to bid on that.

Dataset can be shared by all users.

Users can open discussion room and post comment there.

Users will be able to chat with other users.

There needs to be effective search function and other functionality.

The system will be highly secured. Any issues related the payment and privacy will be handled effectively.

3.5 Usage Scenario

ResearchColab is a web-based platform which aims to assist researchers with their work. Researchers will be able to invite reviewers for examining their draft paper through post, and share dataset with others. There will be discussion rooms on different topics or ideas. Users can also search through the site for posts, datasets, discussions rooms, and researchers. Guest users will view posts of review request, data offering, and conversations of public discussion rooms. They can search through the sites as well. For getting further privileges they will need to sign up and become an authenticated user. Authenticated users have all the privileges of a guest user. They can post review request, response to interested review requests, and comment under them. They can also share and download datasets. They have privilege to create public or private discussion room as well as comment in discussions. They will also have to manage their profile information. When a review request is posted it enters into open for response phase. A review request will contain research domain, work overview, time limit for review,

10

payment range, attachment (optional) and expertise tag for expected reviewers. Interested users will be able to response against any request, as well as post comments under it. Now review request poster will choose probable reviewer from the list of interested users. He can then converse one-to-one with interested reviewers and finalize the contract. After the contract is confirmed, the reviewer enters time range and payment. Then request poster accepts the deal as well as submits his draft paper to the reviewer in PDF. Now the review request enters into review under progress phase and the selected reviewer will be marked as appointed. Reviewer will not be able to download or copy text of the submitted research document. He can read the document only through the website. After the completion of review, reviewer will submit his review work as a document to the request poster. The post now enters into transaction phase. The request poster will see that review work is submitted. But he will not be able to access it then (will get to see a preview though); the payment must be issued first. After the payment is cleared reviewer accepts it and the post enters into feedback phase. In this phase both request poster and reviewer can score each other from 1 to 5, as well as give a response comment. Researchers can share dataset in with other researchers through the system. Data offering will contain name, detail description, paper (optional), attached dataset, topic tag, and cost (can be 0 too). Users will not have direct access to the attached dataset. If a user really wants the dataset, he will send a get request to the dataset owner. The dataset owner then will forward the dataset to the user. But the user will not be able to download the dataset yet, except for some preview. He will have to issue the payment, and will get access to the dataset after the payment is accepted. Users may create both public and private discussion rooms on different topics. Only the creator of a room can add other users to the discussion. A User may join in any public discussion rooms. But private discussion rooms are only accessible to added users. Users can post comments in the discussion rooms and vote up or down to other users’ comments. Every user will have to maintain his profile information. There will be three categories of information- general, professional, performance. General information includes- name, profile photo, email, short biography and social websites. Professional information will contain expertise tags, links to published

11

papers, and CV. Previous works (both as reviewer and request poster), shared dataset, and feedback score will comprise performance information. Users will only be able to change his general and professional information. Performance information will be managed by the system. All these information, except for email address, will be available publicly.

3.6 Elicitation Work Product

Our elicitation work product includes:

Statement of our requirements for ResearchColab

Set of usage scenarios

A statement of scope for our solution

A list of clients, users, and other stakeholders who participated in requirement specification process

12

Chapter-4

Scenario-Based Model

4.1 Introduction

The user’s point of view is used to describe Scenario-Based Model. In SRS this is the first modeling phase. So, it serves as an input for the creation of other models.

4.2 Use Case Scenario

With the advancement of requirements gathering, functionalities and responsibilities of the software starts to materialize. The following table enlists primary components of the system:

Table-4.2 Use Case Scenario Level-0 Level-1 Level-2 Actors

ResearchColab Authentication Sign up Guest User

Login Authenticated User

Logout Authenticated User

Review Management

Post Review Request Authenticated User

(Researcher)

Bid for Review Request

Authenticated User

(Reviewer)

Choose Reviewer Authenticated User

(Researcher)

13

Comment Authenticated User

One-to-One Conversation

Authenticated User

Contact Authenticated User

(Researcher &

Reviewer)

Review Work Submission

Authenticated User

(Reviewer)

Payment Authenticated User

(Researcher)

Feedback Authenticated User

(Researcher &

Reviewer)

Data Sharing Share Data Authenticated User

(Dataset Owner)

Request for Data Authenticated User

(Dataset Seeker)

Forward Dataset Authenticated User

(Dataset Owner)

Payment Authenticated User

(Dataset Seeker)

Download Data Authenticated User

(Dataset Seeker)

Discussion Room

Create Discussion Room

Authenticated User

(Discussion Creator)

Add Members Authenticated User

14

(Discussion Creator)

Join Public Discussion Room

Authenticated User

(Non-Member)

Comment Authenticated User

(Discussion Creator &

Member)

Vote Authenticated User

(Discussion Creator &

Member)

Profile Management

Update Personal

Information

Authenticated User

Update Performance

Information

Authenticated User

View Professional

Information

Authenticated User

15

4.3 Use Case Description

In this section Use Case Scenario will be elaborated to Use Case Diagram, and Description. Figure-4.3 is the Use Case Diagram of level-0 for ResearchColab:

4.3.1 ResearchColab

Here Figure-4.3.1 is the detailed form of level-0:

16

4.3.1.1 Authentication

Authentication can be divided into three sub-modules. Figure-4.3.1.1 shows this:

4.3.1.1.1 Use Case: Sign up Primary Actor: Guest User.

Secondary Actor: N/A

Goal in Context: User registers to the system.

Scenario:

1. Visit the sign up page.

2. Enter email address and password.

3. Click ‘Sign up’ button.

Exceptions:

1. System failure. 2. Error in connection.

Priority: Essential, must be implemented.

Precondition: N/A

When Available: First increment.

17

Frequency of Use: Many times per day.

4.3.1.1.2 Use Case: Log in Primary Actor: Guest User.


Goal in Context: User enters the system.

Scenario:

1. Visit the log in page.

2. Enter valid email address and password.

3. Click ‘Log in’ button.

Exceptions:

1. System failure.

2. Error in connection.


Precondition: N/A



4.3.1.1.3 Use Case: Log out Primary Actor: Authenticated User.


Goal in Context: User exits from the system.

Scenario:

1. Click the ‘Log out’ button.

2. Get out of the system.

Exceptions:

1. System error.

18



Precondition: Must be logged in.



4.3.1.2 Review Management

Review Management has nine sub-modules (Figure-4.3.1.2):

4.3.1.2.1 Use Case: Post Review Request Primary Actor: Authenticated User (Researcher).


Goal in Context: Researcher posts a review job on the system.

19

Scenario:

1. Select ‘Post Review Request’.

2. Enter title.

3. Give description.

4. Add expertise tag.

5. Click on ‘Post’ button.

Exceptions:

1. System is not responding. 2. Unable to Upload. 3. File format mismatch.



When Available: Second increment.

Frequency of Use: Several times per month.

4.3.1.2.2 Use Case: Bid for Review Request Primary Actor: Authenticated User (Reviewer).

Secondary Actor: Authenticated User (Researcher).

Goal in Context: Reviewer shows interest to a review job.

Scenario:

1. View a review request.

2. Click on the “Bid” button.

Exceptions:

1. System is not responding. 2. Network error.




20

Frequency of Use: Several times per week.

4.3.1.2.3 Use Case: Choose Reviewer Primary Actor: Authenticated User (Researcher).

Secondary Actor: Authenticated User (Reviewer).

Goal in Context: Researcher selects probable reviewer.

Scenario:

1. Open bidder list of review post.

2. Enter into bidders’ profile.

3. Select bidder.

Exceptions:

1. System is not responding.

2. Network error.



When Available: Third increment.


4.3.1.2.4 Use Case: Comment Primary Actor: Authenticated User.


Goal in Context: User posts comment to a post.

Scenario:

1. Enter the comment.

2. Press ‘Ok’ button.

Exceptions:

1. Connection problem.

21


Priority: Moderate, may be implemented.



Frequency of Use: Several times per week.

4.3.1.2.5 Use Case: One-to-One Conversation Primary Actor: Authenticated User.


Goal in Context: Users communicates with each other.

Scenario:

1. Select user.

2. Write message.

3. Send message.

Exceptions:

1. Connection error.

2. System failure.

Priority: moderate, may be implemented.



Frequency of Use: Several times per day.

22

4.3.1.3 Data Sharing

This module has five phases. Figure-4.3.1.3 shows this:

4.3.1.3.1 Use Case: Share Data Primary Actor: Authenticated User (Data Owner).


Goal in Context: Data owner shares dataset to other data scientists.

Scenario:

1. Select ‘Share Data’.

2. Enter title.

3. Give description.

4. Add data tag.

5. Click on ‘Post’ button.

Exceptions:


23

2. Unable to Upload.

3. Dataset format mismatch.

4. Dataset size exceeds limit.

5. Invalid dataset.





4.3.1.3.2 Use Case: Request for Data Primary Actor: Authenticated User (Dataset Seeker).

Secondary Actor: Authenticated User (Dataset Owner).

Goal in Context: Get dataset.

Scenario:

1. View dataset information.

2. Click on the “Send Request” button.

Exceptions:

1. System is not responding. 2. Network error.





24

4.3.1.4 Discussion Room

Discussion Room can be divided into five sub-modules (Figure-4.3.1.4):

4.3.1.4.1 Use Case: Create Discussion Room Primary Actor: Authenticated User (Discussion Creator)

Secondary Actor: N/A.

Goal in Context: A private or public room is created for discussion.

Scenario:

1. Select “Discussion Room Creation” option.

2. Enter room title.

3. Select room accessibility- private, or public.

4. Click “Create Room” button.

Exceptions:

1. Invalid discussion room title. 2. System failure.

25

3. Connection failure.



Frequency of Use: Few times per year.

4.3.1.4.2 Use Case: Add Member Primary Actor: Authenticated User (Discussion Creator)


Goal in Context: Add member to a room.

Scenario:

1. Select “Add Member” option.

2. Search users by name.

3. Select user.

4. Click “Add” button.

Exceptions:

1. User with the name does not exist. 2. System failure.


Priority: Moderate, may be implemented.

When Available: Third increment.

Frequency of Use: Several times per day.

4.3.1.4.3 Use Case: Join Public Discussion Primary Actor: Authenticated User (Non-Member)


Goal in Context: User becomes member to a room.

Scenario:

1. Select discussion room.

26

2. Click “Join” button.

Exceptions:

1. System failure.




Frequency of Use: Few times per week.

4.3.1.4.4 Use Case: Comment Primary Actor: Authenticated User (Member)

Secondary Actor: Authenticated User (Discussion Creator).

Goal in Context: Post comment in discussion room.

Scenario:

1. Enter into a discussion room.

2. Enter comment.

3. Click “Ok” button.

Exceptions:

1. System failure.


Priority: Essential, may be implemented.



27

4.3.1.5 Profile Management

Following Figure-4.3.1.5 shows three sub modules of Profile Management:

4.3.1.5.1 Use Case: Update Personal Information Primary Actor: Authenticated User.


Goal in Context: Update Profile Information.

Scenario:

1. Select “Update Personal Information” option.

2. Update required Information.

3. Click “Update” button.

Exceptions:

1. Invalid input. 2. System failure.



28


Frequency of Use: Few times per month.

4.3.1.5.2 Use Case: Update Professional Information Primary Actor: Authenticated User.


Goal in Context: Update Profile Information.

Scenario:

4. Select “Update Professional Information” option.

5. Update required Information.

6. Click “Update” button.

Exceptions:

4. Invalid input. 5. System failure.




Frequency of Use: Few times per month.

29

Chapter-5

Data Model

5.1 Introduction

When software requires interfacing with a database or complex data structures need to be constructed and manipulated, data model is performed as part of overall requirements modeling.

5.2 Data Object Selection

Data objects are representation of information which has different attributes. Table-5.2 enlists all nouns from Usage Scenario and marks potential data objects:

Table-5.2 Data Object Selection

Noun Attributes Remark

researchcolab rejected researchers rejected

reviewers rejected share dataset rejected

discussion rooms rejected

topics rejected users cv, email, profile photo, short

biography, social website, personal information, professional information, performance information

accepted

search rejected

guest users rejected view posts rejected

review request research domain, work overview, comment, expertise tag, payment, time limit

accepted

download datasets rejected

30

profile information rejected

research domain rejected work overview rejected

time limit rejected payment rejected

expertise tag rejected

post comments rejected review request poster rejected

probable reviewer rejected pdf rejected

progress phase rejected

research document rejected review work rejected

payment phase rejected

data sharing description, dataset, preview, payment, comment, rating, tag, purchase count

accepted

dataset rejected

detail description rejected

topic tag rejected

direct access rejected

dataset owner rejected

profile photo rejected

short biography rejected

social websites rejected

professional information rejected

cv rejected

feedback score rejected

discussion comment, members, discussion type, Creator, Topic, Tag, Votes

accepted

performance information rejected

professional information rejected

performance rejected

email address rejected

31

5.3 Data Objects and Attributes

This is a brief view of all attributes we have found so far:

32

5.4 E-R Diagram

Here relationships among all entities are shown as a diagram (Figure 5.4):

33

Chapter-6

Class-Based Model

6.1 Purpose

The objects that the system will manipulate, the operations that will be applied to the objects and relationships between the objects are represented by Class-Based Modeling. It also defines the collaborations that occur between the classes.

6.2 General Classification

Analysis classes can be marked by one of the following ways:

1. External Entity

2. Thing 3. Occurrence

4. Role

5. Organizational Unit

6. Place

7. Structure

Table-6.2 General Classification

Potential Class General Classification

ResearchColab Thing

researchers Role

reviewers Role

share dataset Structure

discussion rooms Thing

topics Thing

users Role

search Occurrence/ Event

34

guest users Role

viewing posts Occurrence/ Event

review request Thing

downloading datasets Occurrence/ Event

profile information Structure

research domain Thing

work overview Thing

time limit Occurrence/ Event

payment Thing

expertise tag Thing

posting comments Occurrence/ Event

review request poster Role

probable reviewer Role

pdf Thing

progress phase Occurrence/ Event

research document Thing

review work Thing

payment phase Occurrence/ Event

dataset Thing

detail description Thing

topic tag Thing

direct access Occurrence/ Event

dataset owner Role

profile photo Thing

short biography Thing

social websites Thing

personal information Structure

cv Thing

35

feedback score Thing

performance information Structure

professional information Structure

performance Thing

email address Thing

authenticated users Role

6.3 Selection Characteristics

Coad and Yourdon suggest six selection characteristics that should be used to consider each potential class for inclusion in the analysis model:

1. Retained Information

2. Needed Services

3. Multiple Attributes

4. Common Attributes

5. Common operations

6. Essential Requirements

Table-6.3 Selection Characteristics

Potential Class

Characteristic Number That Applies

Comment

ResearchColab None Rejected, problem domain

researchers All Rejected, as it can be

represented by authenticated

user

reviewers All Rejected, as it can be

represented by authenticated

user

36

sharing dataset 2 Rejected as 1,3,4,5,6 violated

discussion rooms All Accepted

topics None Rejected

users All Rejected, can be represented

by autheticated and guest

users

search 2 Rejected as 1,3,4,5,6 violated

guest users 1,2,3,5,6 Rejected

viewing posts 2 Rejected as 1,3,4,5,6 violated

review request 2 Rejected as 1,3,4,5,6 violated

and represents an action

downloading datasets 2 Rejected as 1,3,4,5,6 violated


profile information 1,2,3,4 Rejected

research domain None Rejected, problem domain

work overview 1 Rejected

time limit 1 Rejected

payment All Accepted

expertise tag 1 Rejected

posting comments 2 Rejected as 1,3,4,5,6 violated


review request poster 1,2,3,4,5 Rejected, as it can be

represented by researcher

probable reviewer 2 Rejected

pdf None Rejected, problem domain

progress phase 1 Rejected, represents a state

research document 1 Rejected, represents an

37

attribute

review work None Rejected, represents an action

payment phase 1 Rejected, represents a state

dataset 1,2,3,4,6 Accepted

detail description 1 Rejected, represents an

attribute

topic tag 1 Rejected, represents an

attribute

direct access None Rejected

dataset owner 1,2,3,4,5 Rejected, as it can be

represented by researcher

profile photo 1 Rejected, represents an

attribute

short biography 1 Rejected, represents an

attribute

social websites 1 Rejected, represents an

attribute

personal information 1,2,3,4,6 Accepted

cv 1 Rejected, represents an

attribute

feedback score 1 Rejected, represents an

attribute

performance information 1,2,3,4,6 Accepted

professional information 1,2,3,4,6 Accepted

performance None Rejected

email address 1 Rejected, represents an

attribute

38

authenticated users All Accepted

6.4 Attribute Selection

i. AuthenticatedUser = personalInformation + performanceInformation + professionalInformation

ii. DiscussionRoom = comment + AuthenticatedUser

iii. Payment = paymentState + timeLimit + reviewRequest + amount + sender + receiver

iv. Dataset = owner + topicTag + detailDescription + preview + paymentAmount

v. PersonalInformation = name + profilePhoto + emailAddress + socialWebsites + shortBiography

vi. ProfessionalInformaton = CV + expertiseTag

vii. PerformanceInformation = feedbackScore + performance + reviewWorks + discussionRooms

6.5 Method Selection

i. AuthenticatedUser = postReviewRequest(), respondToReviewRequest(), search(), createDiscussionRoom(), postDiscussion(), comment(), updateProfile(), bid(), pay(), receiveReview(), postData(), downloadData(), provideFeedback()

ii. DiscussionRoom = getComment(), getDiscussionRoom()

iii. Payment = issuePayment(), receivePayment(), closePost()

iv. Dataset = getOwner(), setOwner(), getTopicTag(), setTopicTag(), getDetailDescription(), setDetailDescription(), getPreview(), setPreview(), getPaymentAmount(), setPaymentAmount()

39

v. PersonalInformation = getName(), setName(), getProfilePhoto(), setProfilePhoto(), getEmailAddress(), setEmailAddress(), getSocialWebsiteList(), setSocialWebsiteList(), getShortBiography(), setShortBiography()

vi. ProfessionalInformaton = uploadCV(), getExpertiseTag(), setExpertiseTag()

vii. PerformanceInformation = getFeedbackScore(), setFeedbackScore(), calculatePerformance(), getPerformanceInformation(), buildReviewWorkList(), getReviewWorks(), getDiscussionRoomPosts()

40

6.6 Class Diagram

We have shown here (Figure- 6.6), how the classes interact together to accomplish

certain goal.

Figure 6.6: Class Diagram

AuthenticatedUser

personal Information performance information

professional information postReviewRequest() respondToReviewRequest() search() createDiscussionRoom() postDiscussion() comment() updateProfile() bid() bid

pay()

PersonalInformation

name profilePhoto emailAddress socialWebsites shortBiography

getName() setName() getProfilePhoto() setProfilePhoto() getEmailAddress() setEmailAddress() getSocialWebsiteList() setSocialWebsiteList() getShortBiography() setShortBiography()

DiscussionRoom

comment AuthenticatedUser

getComment() getDiscussionRoom()

Dataset

owner topicTag detailDescription preview paymentAmount

getOwner()setOwner() getTopicTag() setTopicTag() getDetailDescription() setDetailDescription() getPreview() setPreview() getPaymentAmount() setPaymentAmount()

PerformanceInformation

feedback score performance reviewWorks discussionRooms

getFeedbackScore() setFeedbackScore() calculatePerformance() getPerformanceInformation() buildReviewWorkList() getReviewWorks() getDiscussionRoomPosts()

Payment

paymentState timeLimit reviewRequest amount sender receiver

issuePayment() receivePayment() closePost()

ProfessionalInformaton

CV expertise tag

uploadCV() getExpertiseTag() setExpertiseTag()

get

or

give

has

has

has create

shar

e

41

6.7 Class Card

Class card represents a graphical view of responsibility and collaborator for each class.

AuthenticatedUser

Responsibility Collaborator

[1] PostReviewRequest

[2] Respond toReviewRequest

[3] Search

[4] CreateDiscussionRoom

[5] PostDiscussion

[6] Comment

[7] UpdateProfile

[8] Bid

[9] Pay

GuestUser

GuestUser


[1] ViewReviewRequest

[2] ViewData

[3] ViewDiscussion

DiscussionRoom


[1] GetComment [2] GetDiscussionRoom

AuthenticatedUser

42

Payment


[1] IssuePayment [2] ReceivePayment [3] ClosePost

AuthenticatedUser Dataset

Dataset


[1] GetOwner [2] SetOwner [3] GetTopicTag [4] SetTopicTag [5] GetDetailDescription [6] SetDetailDescription [7] GetPreview [8] SetPreview [9] GetPaymentAmount [10] SetPaymentAmount

AuthenticatedUser

PersonalInformation


[1] Get Name [2] Set Name [3] GetProfilePhoto [4] Set Profile Photo [5] Get Email Address [6] Set Email Address

AuthenticatedUser

43

[7] GetSocialWebsite List [8] Set Social Website List [9] GetShort Biography [10] Set Short Biography

ProfessionalInformaton


[1] Upload CV [2] Get Expertise Tag [3] Set Expertise Tag

AuthenticatedUser

PerformanceInformation


[1] GetFeedbackScore [2] SetFeedback Score [3] Calculate Performance [4] GetPerformanceInformation [5] Build Review Work List [6] GetReview Works [7] Get Discussion Room Posts

AuthenticatedUser Dataset

44

Chapter-7

Behavioral Model

7.1 Purpose

When the system is perceived in terms of states and transitions, it is called Behavior Modeling. It is also known as State Modeling, State Machines, or State Transition Matrix.

This requires both identifying all of the interesting states of being that software or its components are likely to be in. And also, at a high level, abstracting what events are likely to cause software or its components to change between states of being.

7.2 Identifying Events

Here we have identified events from the Usage Scenario and listed their corresponding initiators & collaborators.

Table-7.2 Identifying Events

Event Initiator Collaborator search posts, datasets, discussions rooms, and researchers

Authenticated User, Guest User

post review request Authenticated User (Researcher)

response to interested review requests

Authenticated User (Reviewer)

Authenticated User (Researcher)

converse one-to-one Authenticated User

send a get request to the dataset owner

Authenticated User ( Researcher)

Authenticated User (Dataset Owner)

45

create public or private discussion rooms

Authenticated User (Discussion Room Creator)

add users to the discussion Authenticated User ( Discussion Room Creator)

Authenticated User (Non-Member)

maintain profile information Authenticated User

46

7.3 Sequence Diagram

Here we have identified events from the Usage Scenario and listed their corresponding initiators & collaborators. Figure-7.3.1 to Figure-7.3.5 represents Sequence Diagrams for all major events of this project.

47

48

49

50

51

Chapter-8

Conclusion

From this document, the readers will get a clear and easy view of the project. He will also get a good understanding of how the system will work.

This SRS document can be used effectively to maintain the software development cycle for the project. We have presented a detailed description of the total system. It will be much easy to conduct the whole project using this SRS. It will also help us to determine the pitfalls that may come ahead.