Requirements Elicitation and UML Modelling for Macquarie University Dating System (MUDS)

This article discusses the requirements elicitation techniques and UML modelling used for Macquarie University Dating System (MUDS). It covers the use of questionnaires and semi-structured interviews for requirement gathering, user scenarios and stories, functional and non-functional requirements, context and use case diagrams, and more. The article also includes a class diagram and state transition diagram for the system.

COVER PAGE
STUDENT DETAILS

Contents
1 Requirements elicitation..........................................................................................................................3
1.2.1 Requirement gathering techniques................................................................................................3
1.1.1 Questionnaires............................................................................................................................3
1.1.2 Interviewing................................................................................................................................3
1.2 Strategy.............................................................................................................................................4
1.2.1 Data collection phase..................................................................................................................4
1.2.2 Data analysis phase.....................................................................................................................4
2 Requirements specification and UML modelling......................................................................................4
2.1 User scenarios...................................................................................................................................4
2.2 User stories........................................................................................................................................5
2.3 Functional requirements...................................................................................................................5
2.4 Non-functional requirements............................................................................................................5
2.5 Context diagram................................................................................................................................6
2.6 Use case diagram...............................................................................................................................7
2.7 Use case descriptions........................................................................................................................8
2.8 Sequence diagram...........................................................................................................................10
2.9 Entity-class diagram.........................................................................................................................11
2.10 State diagram................................................................................................................................12

1 Requirements elicitation
1.2.1 Requirement gathering techniques
There are any requirement gathering techniques but the two selected techniques to be used to find out
about the problem are;
 Questionnaires
 Interviewing
1.1.1 Questionnaires
This technique of requirements gathering involves preparing a set of questions and giving it to
respondents in order to get information from the respondents. Questionnaires can be administered
though different techniques such as;
 Oral questionnaires- This questionnaires are administered to the respondents orally by the
researcher.
 Printed questionnaires- This type of questionnaires are printed on a piece of paper and the
respondents are given to answer the questionnaires.
 Online questionnaires- This questionnaires are prepared on a web form which respondents can
access and answer the different questions by filling the web form.
Questionnaires will be used for requirements gathering for the Macquarie University Dating System
(MUDS). The type of questionnaires that will be administered to the students are online questionnaires
where by a web form with all the questions will be prepared and students will be given the link to take
the questionnaire.
Administering questionnaires is one of the best techniques to use to collect additional requirements for
this system. This is because use of questionnaires is a cheap and easy method to implement for the
university especially because the questionnaire will be a web form which will be very easy to access for
the respondents. Specifically using online questionnaires will make easy for the university to administer
the questionnaires to a large number of respondents within a short period of time and using minimal
resources. Quantifying the data will also be easy since the university can use existing tools to get
information from the responded questionnaires.
1.1.2 Interviewing
This is another technique that will be used to collect data from the respondents. This technique will be
used to facilitate questionnaires and to get more quality data from the respondents. There are three
types of interviews;
 Structured interviews
 Unstructured interviews.
 Semi structured interviews
Structured interview involves administering a series of predetermined questions that interviewees
answer in the same order.
Unstructured interviews involves conducting the interview with no set of predetermined questions. The
interviewer determines the nature of the interview.

Semi-structured interviews- this type of interview is a combination of structured and unstructured
interviews. For this type of interview, a set of predetermined questions is asked to the interviewees but
more additional questions might be asked during the interview to get more clarification.
For MUDS requirements gathering semi-structured interview will be used to gather requirements. The
reason for using semi-structured interviews is because this technique will be used interchangeably with
questionnaires thus questions that will not have been captured in the questionnaires will be asked in the
semi-structured interview. This techniques is also efficient to use because data analysis of the collected
data will be easy.
1.2 Strategy
The following phases are followed in order to gather requirements for MUDS;
 Data Collection phase
 Data analysis phase.
1.2.1 Data collection phase
Collection of data is the first phase that will be conducted while during requirements elicitation.
Collection of data will be done using the questionnaires and interviews as explained in section 1 above.
After data collection is done the project team can proceed to the next phase.
1.2.2 Data analysis phase
Data analysis phase involves taking the data collected in the data collection phase and analyzing it in
order to come up with the requirements of the system. All the data will be analyzed using laid out
procedures to make sure that all requirements are captured during the analysis of the data.
2 Requirements specification and UML modelling
2.1 User scenarios
 Premium account student
Considering a premium student account for student John Doe.
Scenario: make account inactive
1. John Doe opens the application
2. Application displays the login page
3. John Doe enters his username and password to login into the system.
4. The application validates the login credentials and opens the user profile
5. John Doe presses the account setting option.
6. System displays the user’s account page.
7. John Doe selects make account inactive option
8. System displays a form to fill the period that the user wants to inactivate the account.
9. John Doe enters the period and presses the save button
10. System saves the details and makes the account inactive and displays a message to the
user.
11. John Doe presses log out button.
12. System destroys the user session and logs out the user.

 MUDS Manager
Considering MUDS manager with the name Jon Snow.
Scenario: Generate activity report.
1. Jon snow opens the application
2. Application displays the login page
3. Jon Snow enters his username and password.
4. System validates the login credentials and opens the manager dashboard.
5. Jon Snow selects generate activity report option
6. System fetches all students who have a pending review.
7. Jon Snow selects a student.
8. The system fetches and displays details of the student.
2.2 User stories
 Student
 As a student I want to be able register and create an account in the system
 As a student I want to see all my potential matches.
 As a student I want to be able to send a connection request to one or more of my
matches.
 As a student I want to be able to see all notifications for requests sent to me
 MUDS Manager
 As a manager I want to be able to login and access the admin dashboard.
 As a manager I want to be able to see all students who have been reported for abuse.
 As a manager I want should be able to see the report sent by a student who claims they
were abused.
 MUDS staff member
 As a staff I want to be able to login and access the staff admin section.
 As a staff I want to be able to see all students who have made requests for their
accounts to be deleted.
 As a staff I should be able to delete a student account.
2.3 Functional requirements.
 The application should enable students to upgrade to a premium account after making a
payment.
 The application should maintain a user session when any user is logged in and should
automatically log out the user if he or she becomes inactive for five continuous minutes.
2.4 Non-functional requirements
 Availability-The application should be available at all times for any user to use.
 Robustness- The application should implement mechanisms that ensure there is continued
operation if the application encounters any errors while being used by any user.

2.5 Context diagram
dfd Context Diagram
MUDS
Student
MUDS_Manager
MUDS_Staff
MQNS
MQFSS
E-student
register
view requests
send connection request
requests
view request
accept request
reject request
notifications
matches
delete request
deactivate account
report abuse
upgrade/downgrade
validate student
validation results
student payment details
send notification
notification
generate report
report
view requests
deletion requests
approve/reject request
Figure 1: context diagram

2.6 Use case diagram
uc Use Case diagram
MUDS
student
register
login
manage Account
upgrade
dow ngrade
make innactiv e
process payment
MQFSS
send request
v iew matches
manage friend
request
accept request
rej ect request
delete request
report abuse
MUDS manager
generate report
E-student
v alidate student
v iew
notifications
MQNS
send notification
MUDS staff
v iew deletion
requests
manage deletion
requests
approv e
rej ect
start liv echat
v iew users w ho hav e
v iew ed you
«include»
«include»
«include»
«extend»
«include»
«include»
«include»
«invokes»
«extend»
«include»
«include»
Figure 2: Use case diagram
The two added use cases for premium users are;
 Start live chat use case- A premium student can start a live chat with another premium user in
the application
 View users who have viewed your profile use case- premium students can view users who have
viewed their profiles in the last 1 week.

2.7 Use case descriptions
 Send request (problem use case)
Use
Case ID:
UC1
Use Case Name: Send request
Created By: Author Last Updated By: Author
Date Created: 3/12/2018 Date Last Updated: 3/12/2018
Actor: Student
Description: Student sends a request to one of his or her matches
Preconditions: Student must be logged in
Postconditions: The system has to generate a notification
Priority: High
Frequency of Use: Frequent
Normal Course of Events: 1. Student selects a match
2. System displays details of the match
3. Student sends request by pressing send request button
4. System sends request to the match
Alternative Courses:
Exceptions:
Includes: Generating notification
Special Requirements: The student must have matches to send requests to
Assumptions: Every student has at least one match in the system
 Start live chat (my use case)
Use
Case ID:
UC2
Use Case Name: Start live chat
Created By: Author Last Updated By: Author
Date Created: 3/12/2018 Date Last Updated: 3/12/2018
Actor: Student

Description: A premium students starts a live chat with another student
Preconditions: Student must be logged in
Postconditions:
Priority: Low
Frequency of Use: Moderate
Normal Course of Events: 1. Premium student selects a friend
2. System displays details of the friend
3. Premium student selects start live chat button
4. System checks whether the recipient friend is a premium
member
5. System initiates live chat
Alternative Courses: 4.1 system gets recipient is not a premium user.
4.2 System shows a message to the user
Exceptions:
Includes:
Special Requirements: The student must be a premium user to start a live chat
Assumptions: Live chat between two students can only happen between two
premium users

2.8 Sequence diagram
Sequence diagram for send request for a student actor.
sd Sequence diagram
student
MUDS Database MQNS
view matches()
retrieveMatches()
matches()
select match()
display match()
match()
send request()
save request()
results()
generatenotification()
send notification()
deliver notification()
status()
success Message()
Figure 3: Send request sequence diagram

2.9 Entity-class diagram
class Class Diagram
student
- studentID: int
+ register() : void
+ login(char, char) : boolean
+ viewMatches() : void[]
+ reportAbuse(int) : void
account
- studentID: int
+ upgrade(int) : void
+ downgrade(int) : void
+ deactivate(int) : void
premiumUsers
+ register() : void
+ startLivechat(int) : void
+ login(char, char) : boolean
+ viewMyviewers() : void[]
+ viewMatches() : void[]
+ reportAbuse(int) : void
friendRequest
- requestID: int
+ sendRequest(int) : void
+ acceptRequest(int) : void
+ DeleteRequest(int) : void
+ rejectRequest(int) : void
deletionRequest
+ apply(int) : void
+ approve(int) : void
+ reject(int) : void
staff
- staffID: int
- username: char
+ login() : void
+ viewReuests() : void[]
notification
+ generateNotification() : void
admin
- adminID: int
+ login(char, char) : void
+ generateReport() : void
1
1..
1..
1..*
1
0..*
10..*
1 1
Figure 4: Class diagram

2.10 State diagram
The following state diagram is for the admin class as shown in figure 4 above.
stm state Transition diagram
Start
login
correct login credentials?
generateReport
End
[NO]
[YES]