software project management: software requirement specification
TRANSCRIPT
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.
Secondary Actor: N/A
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.
Priority: Essential, must be implemented.
Precondition: N/A
When Available: First increment.
Frequency of Use: Many times per day.
4.3.1.1.3 Use Case: Log out Primary Actor: Authenticated User.
Secondary Actor: N/A
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
2. Error in connection.
Priority: Essential, must be implemented.
Precondition: Must be logged in.
When Available: First increment.
Frequency of Use: Many times per day.
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).
Secondary Actor: N/A
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.
Priority: Essential, must be implemented.
Precondition: Must be logged in.
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.
Priority: Essential, must be implemented.
Precondition: Must be logged in.
When Available: Second increment.
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.
Priority: Essential, must be implemented.
Precondition: Must be logged in.
When Available: Third increment.
Frequency of Use: Several times per month.
4.3.1.2.4 Use Case: Comment Primary Actor: Authenticated User.
Secondary Actor: N/A
Goal in Context: User posts comment to a post.
Scenario:
1. Enter the comment.
2. Press ‘Ok’ button.
Exceptions:
1. Connection problem.
21
2. System is not responding.
Priority: Moderate, may be implemented.
Precondition: Must be logged in.
When Available: Second increment.
Frequency of Use: Several times per week.
4.3.1.2.5 Use Case: One-to-One Conversation Primary Actor: Authenticated User.
Secondary Actor: N/A
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.
Precondition: Must be logged in.
When Available: Second increment.
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).
Secondary Actor: N/A
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:
1. System is not responding.
23
2. Unable to Upload.
3. Dataset format mismatch.
4. Dataset size exceeds limit.
5. Invalid dataset.
Priority: Essential, must be implemented.
Precondition: Must be logged in.
When Available: Second increment.
Frequency of Use: Several times per month.
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.
Priority: Essential, must be implemented.
Precondition: Must be logged in.
When Available: Second increment.
Frequency of Use: Several times per month.
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.
Priority: Essential, must be implemented.
When Available: Second increment.
Frequency of Use: Few times per year.
4.3.1.4.2 Use Case: Add Member Primary Actor: Authenticated User (Discussion Creator)
Secondary Actor: N/A.
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.
3. Connection 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)
Secondary Actor: N/A.
Goal in Context: User becomes member to a room.
Scenario:
1. Select discussion room.
26
2. Click “Join” button.
Exceptions:
1. System failure.
2. Connection failure.
Priority: Essential, must be implemented.
When Available: Second increment.
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.
2. Connection failure.
Priority: Essential, may be implemented.
When Available: Second increment.
Frequency of Use: Many times per day.
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.
Secondary Actor: N/A.
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.
3. Error in connection.
Priority: Essential, must be implemented.
28
When Available: Second increment.
Frequency of Use: Few times per month.
4.3.1.5.2 Use Case: Update Professional Information Primary Actor: Authenticated User.
Secondary Actor: N/A.
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.
6. Error in connection.
Priority: Essential, must be implemented.
When Available: Second increment.
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
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
and represents an action
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
and represents an action
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
Responsibility Collaborator
[1] ViewReviewRequest
[2] ViewData
[3] ViewDiscussion
DiscussionRoom
Responsibility Collaborator
[1] GetComment [2] GetDiscussionRoom
AuthenticatedUser
42
Payment
Responsibility Collaborator
[1] IssuePayment [2] ReceivePayment [3] ClosePost
AuthenticatedUser Dataset
Dataset
Responsibility Collaborator
[1] GetOwner [2] SetOwner [3] GetTopicTag [4] SetTopicTag [5] GetDetailDescription [6] SetDetailDescription [7] GetPreview [8] SetPreview [9] GetPaymentAmount [10] SetPaymentAmount
AuthenticatedUser
PersonalInformation
Responsibility Collaborator
[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
Responsibility Collaborator
[1] Upload CV [2] Get Expertise Tag [3] Set Expertise Tag
AuthenticatedUser
PerformanceInformation
Responsibility Collaborator
[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.