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.
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:
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:
2. Network error.
When Available: Third increment.
4.3.1.2.4 Use Case: Comment
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
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:
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
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
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()
getorgive
has
has
hascreate
share

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.

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.

Software Project Management: Software Requirement Specification

More Related Content

What's hot

Viewers also liked

Similar to Software Project Management: Software Requirement Specification

More from Minhas Kamal

Recently uploaded

Software Project Management: Software Requirement Specification