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

^ Back to top

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.

^ Back to top