Requirements
This page highlights details about the client we are delivering our application to, a short description of the problem definition, ways we used to gather our requirements and a list of MosCoW requirements and use cases.
Client, Problem Definition Requirements Use Cases
Our Client
Atos is a leader in digital services. Serving a global client base, Atos provides Consulting & Systems Integration services, Managed Services & BPO, Cloud operations, Big Data & Cyber-security solutions, as well as transactional services through Worldline, the European leader in the payments and transactional services industry.
Atos are also focused on business technology that powers progress and helps organizations to create their firm of the future. The client we are working with is based at the Nottingham Office.
Problem Definition
- Atos is a large firm consisting of multiple employees of different skillset and age group working in various departments.
- Our client wanted a way that would allow employees in their workplace to help improve each other’s skillset.
- Our cliet proposed an application that would pair up mentors who are experienced employees with newer employees which acts as their mentees.
- The client also addressed the stable marriage problem which is the problem of finding stable matching between the sample size of mentors and mentees.
Stable Marriage Problem
The stable marriage problem marriage problem is the problem of finding a stable matching between two equally sized sets of elements given an ordering of preferences for each element. This problem can be modeled by using the employees as an example where there are equal number of employees willing to act as mentors and similarly apply to become a mentee.
Currently the process of matching a mentor and mentee is done manually by human resources in Atos. Our client wanted an application that does this automatically and is also able to handle non-perfect data size such as when the number of mentors and mentees differ.
Requirements Gathering
Before constructing our MosCoW requirements, we decided to communicate as much with our client as possible to ensure that we agree on the list of requirements and deliverables the application must provide by the end of term. We initially drafted a list of requirements during our first meeting with our client when she briefed us about the problem definition and what was expected from us.
After making a draft of the requirements, we constantly emailed our client to get feedback and finalised a list of MosCoW requirements during a meeting.
MosCoW Requirements
This is a list of all the requirements as agreed and finalised with our client. These requirements are subject to change over the course of the development phase of this project.
| Requirement | Description | Category |
|---|---|---|
| Must Have | ||
| Matching system | There must be a matching algorithm that matches mentors and mentees as best as possible according to their preferences. | Functional |
| Preferences for matching | There must be a system for mentors and mentees to specify their preferences for matching, for instance interests. | Functional |
| Separate mentorship programmes | The system must allow for a number of separate mentorship programmes with their own matching constraints. | Non-Functional |
| Personal status | Users must be able to see the status of their mentorships, for instance whether they can match with users and how active the mentorship is. | Functional |
| Web Application | A complete web application must be provided by the end of the development phase which includes a client side user interface and a functional server back end | Functional |
| User Interface and Usability | The application must operate on a user friendly interface which is simple to use | Non-Functional |
| Should Have | ||
| Profile system | Users should be able to create and manage a simple profile so that other users can learn about them. Should include name, image and perhaps a short bio. | Functional |
| Notifications | Users should be able to receive notifications about key features of the app, for instance when matches are allocated. Should also work across different form factors | Functional |
| Admin bulk operation interface | There should be an interface that allows admins to perform bulk create/read/update/destroy (CRUD) operatons easily. | Functional |
| Could Have | ||
| Mentorship meeting record | The app could be able to store records of the mentor and mentee meeting each other during the course of the mentorship, with the ability to add comments to this. | Functional |
| Notifications to meet | The app could facilitate instant messaging betweenmentors and mentees. | Functional |
| Would Have | ||
| Corporate Directory Lookup | The app would be able to use the company’s internal “Corporate Directory” to populate users’ profiles | Functional |
| Instant messaging | The app could be able to store records of the mentor and mentee meeting each other during the course of the mentorship, with the ability to add comments to this. | Functional |
Use Cases
This is a list of use cases which aims to illustrate the interaction between users at different parts of the application.
| Use case ID | Use Case Name |
|---|---|
| UC1 | Create Account |
| UC2 | Explore information of program |
| UC3 | Register for a mentorship program |
| UC4 | Manage Mentor Programme |
| UC5 | Manage Cohorts |
| UC6 | Notification System |
| UC7 | Check individual profile |
| UC8 | Edit profile |
| UC9 | List user's mentors or mentees |
| USE CASE | Create Account |
|---|---|
| ID | UC1 |
| BREIF DESCRIPTION | Allow uses to create their own account and set up basic information |
| PRIMARY ACTORS | User |
| PRECONDITIONS | None |
| MAIN FLOW |
1.Click 'Create an Account' button. 2.Fill the required information in sign up page. 3.Click 'Sign up' button |
| POSTCONDITIONS | User account is set up and is redirected to home page |
| USE CASE | Find out more about specific mentorship program |
|---|---|
| ID | UC2 |
| BREIF DESCRIPTION | Users chooses from the listed mentorship programs to find more information about the mentoring program |
| PRIMARY ACTORS | User |
| PRECONDITIONS | User must be registered and is already signed in |
| MAIN FLOW |
1.Go to home page 2.Click on 'Find Out More' for the desired mentorship program which are listed. |
| POSTCONDITIONS | User is redirected to a decription page of the specific mentorship program before proceeding to next step. |
| USE CASE | Resgiter for a mentor program |
|---|---|
| ID | UC3 |
| BREIF DESCRIPTION | User registers for mentorship program of their interest. |
| PRIMARY ACTORS | User |
| PRECONDITIONS | User must be logged in to their account |
| MAIN FLOW |
1.Go to home page 2.Click on desired mentorship program 3.Click the 'Register Here' button 4.Choose the option of signing up as a mentor or mentee 5.Select tags and interest for matching. |
| POSTCONDITIONS |
1.Redirected back to home page upon successful registration. |
| USE CASE | Manage Mentor Programme |
|---|---|
| ID | UC4 |
| BREIF DESCRIPTION | Admin can create a mentor programme which users can register for |
| PRIMARY ACTORS | User(Admin) |
| PRECONDITIONS | 1.Logged in successfully. User MUST be an Admin. |
| MAIN FLOW |
1.Go to side menu 2.Select Create Mentor Program 3.Fill in form details and confirm creation. |
| POSTCONDITIONS | New program is created, user is redirected to home page and the new program is listed. |
| ALTERNATIVE FLOW |
1a.Admin decides to edit program. 1b.Admin decides to delete program. After confirming deletion, program is deleted |
| USE CASE | Manage Cohorts |
|---|---|
| ID | UC5 |
| BREIF DESCRIPTION | Admins can create cohort for mentor rogrammes which users can register for. |
| PRIMARY ACTORS | User(Admin) |
| PRECONDITIONS | Logged in successfully. User MUST be an admin |
| MAIN FLOW |
1.On home page, click on cohort button of desired mentor programme 2.Fill in open date, close date and match date 3.Confirm to create program |
| POSTCONDITIONS | New cohort is created. Admins can go to cohort page and a new cohort is listed. |
| ALTERNATIVE FLOW |
1a.Admin decides to edit a cohort. Admins clicks on edit cohort, and changes cohort details. 1b.Admin decides to delete cohort. Admin clicks on delete cohort button, after confirming, program is deleted. |
| USE CASE | Notification system for mentor and mentee |
|---|---|
| ID | UC6 |
| BREIF DESCRIPTION | Users can receive notifications when new programs are created and if the current date is the matching date. |
| PRIMARY ACTORS | User |
| PRECONDITIONS | User is registered and logged in successfully |
| MAIN FLOW |
1.Go to home page 2.On the tab bar go to notifications |
| POSTCONDITIONS | Users can see any notifications from their mentee or mentor |
| USE CASE | Check individual profile |
|---|---|
| ID | UC7 |
| BREIF DESCRIPTION | Users could see information about themselves which includes current role and current enrolled programs. |
| PRIMARY ACTORS | User |
| PRECONDITIONS | Logged in successfully |
| MAIN FLOW |
1.Go to home page 2.On tab bar click 'Profile' |
| POSTCONDITIONS | Users could see their own profiles along with its details. |
| USE CASE | Edit user profile |
|---|---|
| ID | UC8 |
| BREIF DESCRIPTION | Users can edit their profile if needed |
| PRIMARY ACTORS | User |
| PRECONDITIONS | Logged in successfully |
| MAIN FLOW |
1.Go to home page 2.Click the side-bar menu 3.Click 'Settings' button. |
| POSTCONDITIONS | User is redirected to profile page with profile details edited. |
| USE CASE | List user's mentors or mentees |
|---|---|
| ID | UC9 |
| BREIF DESCRIPTION | Users can see a list of their mentor or mentees in different mentor programs |
| PRIMARY ACTORS | User |
| PRECONDITIONS | Logged in successfully |
| MAIN FLOW |
1.Go to home page 2.Click the side-bar menu 3.Click 'My mentors' button or 'My mentees' button. |
| POSTCONDITIONS | A list of the currenty logged in user's mentors and mentees is displayed according to their respective mentor programs. |