Requirements 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
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.
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.
The following phases are followed in order to gather requirements for MUDS;
- Data Collection phase
- Data analysis 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.
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.
- Premium account student
Considering a premium student account for student John Doe.
- John Doe opens the application
- Application displays the login page
- John Doe enters his username and password to login into the system.
- The application validates the login credentials and opens the user profile
- John Doe presses the account setting option.
- System displays the user’s account page.
- John Doe selects make account inactive option
- System displays a form to fill the period that the user wants to inactivate the account.
- John Doe enters the period and presses the save button
- System saves the details and makes the account inactive and displays a message to the user.
- John Doe presses log out button.
- System destroys the user session and logs out the user.
Considering MUDS manager with the name Jon Snow.
Scenario: Generate activity report.
- Jon snow opens the application
- Application displays the login page
- Jon Snow enters his username and password.
- System validates the login credentials and opens the manager dashboard.
- Jon Snow selects generate activity report option
- System fetches all students who have a pending review.
- Jon Snow selects a student.
- The system fetches and displays details of the student.
- 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.
- 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.
- 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.
Figure 1: context diagram
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
- 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 |
Sequence diagram for send request for a student actor.
Figure 3: Send request sequence diagram
Figure 4: Class diagram
The following state diagram is for the admin class as shown in figure 4 above.