Requirements - COS-301/graduates GitHub Wiki

Welcome to the Requirements Wiki!

Release 1.0.x

The client wants:

  • A graduates portal where students and industry come together. It is meant to be a platform that gives graduates and industry a chance to find potential talent with the intent of getting job opportunities.
  • Solve for me this problem: Towards the end of the final year, when students do their COS 301 projects, industry starts scouting for talent. After the students have shown promise in the capstone projects, industry starts inviting them to interviews. These interviews always require some form of request for CV, academic record, portfolio project or anything recruiters deem necessary. I find this to be incredibly tedious, because I need to email everybody, collate the feedback and organise everything from scratch. The process is so tedious and manual. Can I please get a portal where my company can register, to get to meet you. Think of it as a "LinkedIn for Graduates" where you can have a profile that gives this information (CV, academic record etc.) upon request. Say I meet John, and he is a graduate, I just ask for/request a view of his graduates profile. He accepts my request and I get to see a nice profile that serves the same purpose as a formal CV, with all these additional requests. I would like to see: All information you would generally see on a CV. Links to Github page, portfolio project, small video about yourself? Then share your academic record (later we can integrate), golden key membership, COS 301 Project, Interests, etc.
  • Notice the sensitivity of the information. Security is #1 priority.
  • Eventually a blockchain degree verification like this: https://news.mit.edu/2017/mit-debuts-secure-digital-diploma-using-bitcoin-blockchain-technology-1017 would be cool.
  • This is a project that is for you, by you. I hope it helps to find jobs easily. There should also be a fun "social component". Think about Alumni, etc. Perhaps graduates stories or something like that.
  • I leave you with just the above, the rest is for you to come up with.

More Technical Requirements:

Challenges:

  • Doesn't have to be initial approach, but eventually we want students to log in with their CS account (LDAP). But find out and document how to do this.
  • Industry Members log in using traditional email/password authentication.
  • There has to be a GREAT user experience for both Students and Industry Members.
  • Integration with UP's systems are challenging. So something like retrieval of academic record would be challenging. At first, we can just allow students to upload a PDF of their academic record they downloaded themselves. But find out and document how to do this.
  • Degree verification by Blockchain is a challenge on its own. We do not expect a full implementation here, but something towards this goal of verifying the degree. Some up with something creative for this round (release 1.0.x). Nonetheless, a blockchain approach would be cool. At the very least find out and document how to do this.
  • Management: Managing 160 people working on a project is no easy task. Let's delegate this responsibility. Project Owners will work with Project Managers. These Project Managers will manage their own feature teams.
  • Communication: To ensure that there is clarity and good communication, use the GitHub features extensively. This include project boards, issues, discussion boards, teams etc.
  • Hosting: We have not figured out hosting as of yet. We do know that we will be using a containerised approach using Docker. Please investigate options for us. Consider UP requirements such as VPNs, Firewalls, etc.

Features:

  • Authentication (Domain: Identity) :

    • Project Manager: Reece Stephenson

    • Featured Group: Delphi

    • Description:

      • Users will sign up and the program will ensure emails and passwords are valid. If valid, the email and passwords will be salted, hashed and stored to be used for log in. Logging in, the user will use their email and password to access the graduate portal, the program will check that the email is valid and the password is correct. Users will now have a cookie stored to validate that they have permission to access the portal. Users will be logged out after inactivity after a certain period of time or if they log out themselves.

    • Functional requirements:

      • FR1: Registration - Students and Clients/Employers should be able to register themselves on the portal for use in finding employment or seeking graduates to employ.
      • FR2: Login - Students and Clients should be able to login to the graduates portal to access or change their data as well as to seek potential employment if they are a graduate or to seek employers as a employer
      • FR3: Session Identification - Session identification should be implemented to ensure security for users while they are logged in and to prevent hackers from using other users data or accounts for malicious purposes.

    • Non-functional requirements:

      • NFR1 View password button
      • NFR2 Login feedback

    • Acceptance Criteria

      • AC All users should be able to login and register if they are a graduate or company wishing to scout graduates

  • Authorization (Domain: Identity, Role-Bases, Policy Driven):

    • Project Manager: Phumudzo Ndou

    • Featured Group: C++

    • Description:

      • Once a user has logged in, the user will have permission to add a profile, edit their profile and delete their profile. User will not have permission to do the above mentioned to another user's profile.If company profile wants to view a students/graduates profile, the system will check if the account is authorized to do so(if the request to view the students profile has been accepted by the student/graduate). Admin rights will be given to admin users only.

    • Functional requirements:

      • FR1 : The system will give users/company representatives the permission to edit their profiles and delete their profiles.

        • Editing their Profiles: Constraints: * When editing profiles, users will ONLY be authorized to edit changing attributes such as: - Contact details. - And/ Uploaded documents such as CVs, Profile Pictures etc. * Non-changing attributes will Not be tempered with. * Users will only also be authorized to change ONLY their profile details.

      • FR2 : The system will authorize or give company representatives permission to scout for prospective employees and view student’s/graduate’s profiles. By:

        • Allowing company representatives(users) to request for profile viewing
        • Once the student/graduate has accepted the request, the company will be given further access rights.
        • Rights to: ! Potentially communicate further details on their recruitment process ! AND/OR query for missing information. Constraints:
          • Company representatives can Only view student’s profile once the user(student/graduate) has given them access to.
          • Company representatives will NOT be authorized to change any student’s or graduate’s details.

      • FR3 : The system will permit authenticated Admins ! to change details no other user(student’s, graduates and company’s) can change or delete. Such as:

      • FR4 : The system should be able to inform users that they are not authorized to access certain pages/resources when they are not authorized.

      • FR5 : The system will give users-Suspended the permission to edit their profiles and delete their profiles

    • Non-functional requirements:

      • NFR1 - Speed : Users who want to access certain resources on the site should access these resources instantly. This is to say authorization should take place instantly, or atleast the process should start instantly. This is to also say users can view/access any resources they are eligible for at any given day/time.

      • NFR2 - Capacity: The system should be able to cater/ authorize more or less students each year as the number of students registered in the system may increase/decrease each year.

      • NFR3 - Scalability: The resources which can be requested for can grow as new information sources are made available on the system.

    • User Roles

      • User- General users of the system. This role is the general user of the system and will have limited permissions with the system.
      • Student - These are the roles reserved for University of Pretoria Computer Sciences graduates and will have more permissions to view other users and companies.
      • COMPANY - These users are the general companies that will search for employees and the STUDENT role will be able to search for employment at the listed companies. These companies will have to be thoroughly investigated as to not make it possible for malicious users to acquire the users of the systems information. These users will only have a very limited set of permissions before and during the vetting process.
      • Representative - These as the representatives of the different companies that will have high level authorities with only the companies account as well as the users accounts under the company.
      • ADMIN - The Admins will perform the vetting of the company role as well as perform the general administrative role in the system. The Admin role will be able to perform any task that requires permission except for creating new admins. The admin creation role will only be perform by the super admin account of University of Pretoria.
      • SUSPENDED - This is a role reserved for either companies who have not been vetted yet or suspicious accounts as to make sure that those users will not be able to access any information they shouldn't have.

    • Acceptance Criteria

      • All users eligible to access any information/resources on the sites at any given time should be authorized to do so.
      • All the different kinds of users permission rights can not be changed or swapped out with a different kind of user. This is to say user permissions are to stay constant
      • Users will receive an error notification page with error ‘403-denied access’ if they try to access or edit information they are not allowed to.
      • Buttons to request for authorization are to be put on the user interface. As long as there is a need to authorize the user.

  • Student Profiles (Domain: Students):

    • Project Manager: Adir Miller

    • Featured Group: Pascal

    • Description:

      • The Profile Page is the user's display of personal information, accessible by other users and recruiters. This includes:
        • User's name
        • Contact information
        • Academic record
        • Qualifications
        • Interests
        • Employment Preference
        • Employment Status
        • COS 301 Project

    • Functional requirements:

      • FR1: Student Profile page must have the name and surname of the Student.
      • FR2: Student Profile page must have the contact information of the Student, either an email address and/or phone number.
      • FR3: Student Profile page must have a Profile Photo of the Student
      • FR4: Student Profile page must have bio that details the Student
      • FR5: Student Profile page must have the ability for a Student to update/change any applicable information on the page.
      • FR6: Student Profile page must be publicly accessible by other Students and Companies.
      • FR7: Student Profile page must have addable tags such that users and companies can identify the Student's interests (including employment status).

    • Non-functional requirements:

      • NFR1: Student Profile page should allow students to add any personal interests and abilities.
      • NFR2: Student Profile page should allow Students to add professional information, including qualification and employment preference.
      • NFR3: Student Profile page should allow Students to link other socials (Instagram, Linkedin) on their Profile.
      • NFR4: Student Profile page should allow Students to link their COS 301 Capstone Project

    • Acceptance criteria:

      • AC1: The Student’s name and student number must be present.
      • AC2: The Student’s contact details must to be present.
      • AC3: The Student Profile page must have editing functionality present.

  • Company Profiles:

    • Project Manager: Thashil Naidoo

    • Feature Group: SAS

    • Description:

      • The graduate portal shall allow companies to register and create a profile page. This profile page should contain the relevant information pertaining to the company namely, the company name, logo, bio, office location as well as links to their website/recruitment page. The company page will be referenced on a company representative’s personal page. Company pages shall be made public access to the graduates. Company admins shall have rights to edit the company page and update any of the information as required.

    • Functional requirements:

      • FR1: Company profile page must have a detailed bio (description) of the company and the company vision.
      • FR2: Company profile page must list the basic details of the company such as: address, contact details, name, website, slogan.
      • FR3: Company profile page must have a picture of the company logo in a PNG or JPG format.
      • FR4: Company profile page must have a banner representing the company and it's values.
      • FR5: Company profile page must have an editing page for as company to be able to update outdated information.
      • FR6: Company profile page must only be able to be edited by a pre-approved company admin.
      • FR7: Company profile page must be public to all registered students.
      • FR8: Company profile page must contain social media links eg. Twitter, Facebook, LinkedIn etc.

    • Non-functional requirements:

      • NFR1: Company profile page shall have a section showing awards and certificates the company has won.
      • NFR2: Company profile page shall have a page showing company hiring statistics through the UP system. (future feature)
      • NFR3: Company profile page shall have a blogging functionality (future feature)
      • NFR4: Company profile page shall have an organizational structure tree showing the management order.
      • NFR5: Company profile page shall have a list of related or suggested companies.

    • Acceptance criteria:

      • AC1: The company name and description must be present
      • AC2: The basic company contact details need to be present
      • AC3: The company page needs to have select editing functionality present
      • AC4: The company representative list must be present
      • AC5: The company page needs to be public to all students as soon as a company is confirmed as legitimate.

  • Company Rep Profiles (Domain: Companies):

    • Project Manager: Isheanesu Joseph Dzingirai
    • Featured Group: Ada
    • Description:
      • Company representatives will sign up and have access to their profile where they are able to update and change the data they want on it. The goal is to create a company representative profile that will consist of a company page view, where the representative is able to upload media, profile information, company requirements, as well as have access to registration and login. Company representatives will also be able to access graduate profiles when in need to view a graduates information

  • Notifications (Email and Push, in-app and native?):

    • Project Manager: Thabo Chesane

    • Featured Group: R

    • Description:

      • Notifications are used to give users feedback and visibility of the system status. Notifications will be used in different aspects. A notifications tab where students can view requests by company and company representative profiles. (in-app) A request notification for when a company requests to view the profile of the student.

    • Functional requirements:

      • FR1: Students should be able to view all incoming notifications and their descriptions from a drop-down/expandable menu.
      • FR2: The student that is logged in should be able to mark all notifica- tions as seen, thereby allowing the tray to clear until the next batch of notifications come through.
      • FR3: Each notification will include the details of the sender including name, surname and email and likewise a company notification will include all details of that particular company.

    • Non-functional requirements:

      • NFR1: The notification bar should receive messages almost instanta- neously through various DB/API requests, this allows the user to im- mediately know if a party (Company/User) is trying to contact them for any important reason such as a recruitment message, etc
      • NFR2: The amount of notifications are not limited and thus rely on the user to clear them as they have finished viewing them. Thus essentially it is dependant on how much a specific individual is trying to contact the user.
      • NFR3: Unless the system is down, users should be able to view the no- tifications regardless of the time of day. This allows the user to view the messages at any given time and respond whenever they deem necessary.

    • Acceptance Criteria

      • User (Student/Company) relevant notifications for them
      • Notifications Will appear in the last first order.(The latest notifications will appear at the top)
      • Notifications must occur an almost instant rate and must maintain con- sistency

  • UI Kit :

    • Project Manager: Dhashin Reddy

    • Featured Group: SQL

    • Description:

      • The UI Kit is used to help improve the design workflow. By creating and making use of recyclable components, new ones will not need to be created all the time. It will provide current and future designers with the ability to create and/or update user interfaces with more ease. The main goals of the UI kits are to save time, free up creative energy and resources to focus on essential design tasks, make the designs easier to change, and give everyone opportunities to learn. Essentially the UI Kit will provide a set of files that contain critical UI components like fonts, layered design files, icons, documentation, and HTML/CSS files. There are more components that will be discussed more formally within the group.

    • The UI kit will require/contain the following UI components:

      • Navigation bar
        • Functional requirement(s)
          • Display tabs to different webpages
          • Indicate a way to show that a mouse is currently hovering a tab
      • Header
        • Functional requirement(s)
          • Display introductory content (e.g. logo)
          • Display any navigational aids
      • Footer
        • Functional requirement(s)
          • Display links to webpages
          • Display any copyright data
      • Buttons
        • Functional requirement(s)
          • Clickable
          • Display a possible action name
          • Deliver an event once clicked on
      • Dropdown menu
        • Functional requirement(s)
          • Clickable
          • Display a list of options
          • The items on the list once clicked should lead to either new webpages or an event.
      • Cards
        • Functional requirement(s))
          • Display a descriptive image related to its purpose
          • Provide any necessary text to further describe its purpose
          • Clickable
          • Indicate a way to show that a mouse is currently hovering over it
          • Once clicked an event/action should be delivered.
      • Tabs
        • Functional requirement(s)
          • Clickable
          • Lead to different webpages once clicked
          • Display a descriptive name of a webpage it will lead to once clicked
      • Notifications
        • Functional requirement(s)
          • Clickable
          • Display a number symbolizing the number of unread notifications
          • Once clicked must lead to a webpage where the unread notifications are situated.

    • Non-functional requirements:

      • The UI kit will be lightweight, considering it will only contain a few general UI elements. The fact that the UI kit is lightweight makes it easier to manage, ensuring that it will perform fast and reliably.
      • The UI kit will be easily integrable and accessible. The kit will be a single file of code containing 2-4 grouped components that will be uploaded into the developer's branch once released. Once each team updates their branch after the release of the UI kit, they will have to access the library and be able to use it as needed. Access is achieved by simply including the file.

    • Use case diagram:

Screenshot from 2022-03-24 15-45-28

  • Students Explore :

    • Project Manager: Jonah Gasura

    • Featured Group: Java

    • Description:

      • Companies will make use of this feature to scout for prospective employees. This feature will implement a page that displays a feed of relevant candidates that load as the user scrolls down the page. They will be able to filter students based on some criteria (e.g degree type, employment status and location). Search for a specific student using their name and use tags to find relevant students associated with that tag. The feature will implement a corresponding set of search algorithms to find suitable candidates based on the specified criteria. The feed will be self updating as the information of current students change and new students are added.

    • Functional requirements:

      • FR1 : The feature shall allow the user to open a page that will load students or candidates as the user scrolls down the page. A snippet of three student profiles shall be shown side by side. The snippets shall include a profile picture, name, contact details and biography. The snippets will also display 1 to 3 tags chosen by the student.
      • FR2 : The feature shall allow the user to input a name or general focus into a search bar located on the page. The page will then be reloaded to display the most relevant search results. The relevance of a search result will be determined using all of the available information(name and tags) from the profile snippets. The profile snippets will then be displayed in the order of their relevance to the search query. The search bar will be specific to this feature. It will not be available to other features.
      • FR3 : The feature shall allow the user to click on a profile snippet displayed on the main page. When clicked, the user shall be routed to a profile feature page. The profile feature page shall provide the user with more detailed information of a specific student.
      • FR4 : The feature shall have a radio list located on the main page that enables the user to filter the students by some criteria. The user shall be able to filter students by their degree type, location and employment status. The page will then be reloaded to show the most relevant search results.
      • FR5 : A user shall be able to filter the profile snippets using the tags associated with each student. When a tag is selected, the page will be reloaded to display students that may be associated with that tag. The profile snippets will be displayed in order of their relevance to the original tag.

    • Non-functional requirements:

      • NFR1 : The tags added to student profiles, by the students themselves, will enable our search to find more accurate results. The tags shall reflect possible search queries. For example, "AI", "Security", etc.
      • NFR2 : Loading the profiles of students as the user scrolls down must be done asynchronously. There should be no lagging or stuttering.

    • Acceptance Criteria:

      • AC1 : A list of student profiles should be shown to the user when the page is opened.
      • AC2 : A user should be able to filter the students profiles that are displayed.
      • AC3 : A user should be able to search for a specific profile using a search bar.
      • AC4 : A user should be able to search for a set of profiles using a search bar.
      • AC5 : A user should be able to use tags to filter the profiles displayed.
      • AC6 : A user should be able to click on a profile snippet and be redirected to a profile page.

  • Company Explore :

    • Project Manager: Rina Rene du Toit

    • Featured Group: Cobol

    • Description:

      • Students will make use of this feature to browse the companies that have signup on the system. They will be able to search for a specific company or filter the companies by certain categories to be determined, e.g. industry. This feature will have its own page on the site where a feed of all the companies will be displayed as well as the search and filter options. A default feed will be displayed after opening the page that will update routinely to display newly registered companies.

    • Functional requirements:

      • FR1: The system must retrieve pertinent information (e.g. Company Logo, Company Name) from the Company profile for each registered Company and display this information correctly.
      • FR2: Users should be able to use the Search function to locate a specific Company, or any Company/Companies that match the search criteria given by the user, and will be displayed.
      • FR3: Users should be able to filter through the List of Companies displayed using the filter function. This results in only companies' whose profile matches the filter criteria will be displayed.
      • FR4: The Feed for the Company explore must be dynamic, so that newly registered companies are automatically added to this feed.
      • FR5: Upon opening this page, the feed will automatically display.

    • Non-functional requirements:

      • NFR1: The feed will only contain concise information about the Companies' displayed, such as the Company Logo and Company Name, to avoid cluttering the feed.
      • NFR2: The retrieval of the information from the Company profile should be fast and efficient to avoid bottlenecks and backlogs.
      • NFR3: The Company Explore feed shall only display information that is publicly available from the Company profiles.

  • Admin Interface to Manage Site:

    • Project Manager: Sarah king

    • Featured Group: php

    • Description:

      • The admin interface will be implemented to allow site administrators to manage the system through specialized admin accounts. Once an admin logs into such an account - they will have access to all content available on the website that other standard users can see. Additionally, they will have access to the admin toolbar. This will allow the admin user to create any standard user (student/business/business rep) account, create admin accounts, suspend/reactivate standard user accounts (in the case of misconduct), approve/reject the registration of standard user accounts, archive content from the website and edit the site settings. The admin will also be able to assist standard users with changing vital information on their profiles upon agreement with said standard user. Extensive security measures will be implemented to ensure the safe and ethical use of the admin interface.

    • Main function: Allow site administrators to manage the system through specialised admin accounts through a console.

    • Functional requirements:

      • FR1: Administrators are required to have full access to the graduates portal along with an additional admin console from which they can perform administrative actions.

    • Using the admin console:

      • FR2: Administrators must be able to create other administrative accounts.
      • FR3: Administrators must be able to create any standard user (student/business/business rep) account.
      • FR4: Administrators must be able to approve or suspend a standard user account that is created by any standard user.
      • FR5: Administrators must be able to suspend standard user accounts (in the case of misconduct) as well as re-activate them.
      • FR6: Administrators must be able to archive content on the website, hiding the content from all standard users because of misconduct or other reasons but still being able to access it themselves.
      • FR7: Administrators must be able to edit the settings of the graduate portal.
      • FR8: Administrators must have the ability to change limited details of a standard user account upon agreement with that specific standard user.
      • FR9: Administrators should be provided with an interface to perform all of the aforementioned actions.

    • Non-functional requirements:

      • N-FR1: Availability - The administrative interface/console must be accessible at any time to an administrative user.
      • N-FR2: Usability - The console must also allow for simple creation/suspension/approval of user accounts.
      • N-FR3: Scalability - The console must able to register/create large groups of user accounts (i.e., a new year of COS students)
      • N-FR4: Performance - Administrative and user accounts should be created/suspended within a reasonable timeframe. Administrative accounts must be able to immediately archive content on the website.

  • Storage (for file uploads, organization etc):

    • Project Manager: Zoe Liebenberg

    • Featured Group: Fortran

    • Description:

      • The user and web application will need storage both locally and externally. Locally that would be the session storage and the latter would be server storage. These would be the two main storage functionalities that the web application would need to have to ensure good data capturing and file storage. Furthermore, these storage functions should be able to store different types of data such as JPEG, PDF, TEXT, JSON, and any other types of data. However, the user will only be able to choose from a limited number of file types. While giving users the ability to upload, download, append and remove data and files uploaded to the web application.

    • Functional requirements:

        1. Interface - System must be able to provide a user-friendly interface for the user to upload their files. This includes a "file upload" button as well as a brief menu to upload a file. If the incorrect file was uploaded, the user will be prompted to upload the correct file type.
      • Storage - System shall store all the users files on a database ,namely Firebase or PostgreSQL.
      • Data Retrieval - The respective Companies wishing to view the Undergraduate's documents shall have access to the files and can download them easily.

    • Non-functional requirements:

      • Security - The files uploaded must be stored securely in a database outside the reach of users who are not authorized to view such information.
      • Error Handling - System shall provide simple and understandable feedback when a user makes an error. Such as a pop up message when the user tries to upload an invalid file type.
      • Usability - System shall upload/download the required files within a reasonable time frame, assuming that the user has a decent internet speed. *Reliability - System shall have near perfect reliability when performing tasks with the database, assuming the user has a stable internet connection.

  • UP Integrations (Academic Record, CS Login) :

    • Project Manager: James Butler

    • Featured Group: C#

    • Description:

      • This feature will be responsible for the sharing of information between the graduate portal and the UP website. It will verify the cs email account of students at the University of Pretoria and will check if the academic record of the student is valid to prove that they are indeed graduates. This feature will also facilitate any other communication that needs to take place between the portal and UP, such as student details, etc. Lastly, once blockchain integration has occurred, this feature will retrieve the degrees from UP to be accessible through the portal.

    • Functional requirements:

      • FR1 :Getting the academic record for student authentication
      • FR2 :Verify if the CS email account is valid
      • FR3 : Retrieve degree to be stored on the blockchain
      • FR4 : Retrieve student details for the student profiles

    • Non-functional requirements:

      • NFR1 : Student privacy must always be maintained
      • NFR2 : The retrievals should be quick as to not create a speed bottleneck for the whole project
      • NFR3 :

  • Social Feature such as Student Stories or something:

    • Project Manager: Rayden Burger

    • Featured Group: Ruby

    • Description:

      • we will implement a feature that allows students to post videos or images to share with their fellow students. As the concept of “stories” is not an original one, successful existing implementations have been researched. YouTube Shorts, Instagram Stories and TikToks all function in the same way at their cores. Thus, the functionalities that make each of these platforms successful have been considered. There are multiple basic things that each of these platforms have in common. This includes an intuitive and simple interface, short attention-grabbing videos or images as well as navigation between content of different creators or different types of content. Thus, we will ensure that the above mentioned will apply to our implementation so that it is pleasant to use.

    • Functional requirements:

      • FR1: A story can be uploaded as a video or an image.
      • FR2: A person may upload multiple stories.
      • FR3: A student can remove their own story.
      • FR4: Page for viewing all stories.
      • FR5: Link from student profile displays all stories by the specific student.
      • FR6: Report button so that a story that students have reported can be reviewed.
      • FR7: Be able to add tags to stories.
      • FR8: Stories can be searched by tags from stories explore page.

    • Non-functional requirements:

      • NFR1: The videos should have a maximum resolution / file size so that all videos can be loaded quickly.
      • NFR2: Navigation between stories, student profiles and tags should be intuitive.

    • Acceptance criteria:

      • AC1: Students must be able to upload a video story.
      • AC2: Stories must be able to be viewed by other students.

  • Architecture:

    • Project Manager: Durandt Uys

    • Featured Group: Visual Basic

    • Description:

      • The Architecture feature defines the architecture of the project, meaning it defines where all the files and databases of all the other features are stored and how they are linked together. It defines the main structure of the project and how different elements communicate to each other in the most effective and efficient way. We are also responsible for the development, implementation, maintenance, support and changes of the project

    • Functional requirements:

      • FR1 -Defining the rules and layouts of each role in the project. Contributing to the decision making and logical flow of the order in which the processes will be done and steps that will follow upon each other.
      • FR2 - Specifying a basic structure and procedure as a guide for the linking and merging of different tasks , making sure that the work will be done on time and no delays will occur
      • FR3 - Creating the docker to enable developers to package applications into containers

    • Non-functional requirements:

      • NFR1 - Apps in the high level overview must be completed on time.
      • NFR2 - Apps folder will be responsible for any dependency configuration and library linking
      • NFR3 - Getting the planned layout from other groups and their required features to determine the architecture of their features.

  • Delivery is a feature :

    • Project Manager: Sboniso Masilela

    • Featured Group: Basic

    • Description:

      • This feature is about making sure and taking responsibility of the overall hosting of the application, choosing the suitable platform for hosting and working closely with DevOps team for continuous deployments from development, staging to production. Document delivery process and manage the environments (development, QA and staging)

    • Functional requirements:

      • Be able to host all technologies and systems required to deliver
      • Set up the different environments for testing as well as final delivery
      • Make sure UP integrations work on hosting platform

    • Non-functional requirements:

      • Ensure enough storage space to accommodate for media and userbase
      • Allow room for scalability

    • Acceptance criteria

      • The website can be accessed and used as per expected
      • All features implemented work and are accessible
      • Testing environment is accessible and useable by all teams for development

  • CI/CD (Go)

    • Project Manager: Alexander Muendesi

    • Featured Group: Go

    • Description:

      • The main aspect of this feature is to do with continuous integration, continuous deployment and continuous delivery. Goal is to solve the problem of integrating new code into the repo by introducing automation scripts and maintaining and ensuring the health of the repo by monitoring Pull Requests and Merges. Automation scripts include those for testing code, building the code and releasing validated code to correct branch

    • Functional requirements:

      • FR1: The implemented system needs to notify users if there are any issues during the integration of their changes.
      • FR2: The system needs to be automated so that there is no manual intervention required from the user in terms of building,testing and deploying.
      • FR3: The system should automatically integrate code/changes that have successfully passed the checks to the relevant repository.
      • FR4: Continuous delivery should ensure that there is always a code base ready for deployment to a production environment.
      • FR5: Each merge should trigger an automatic test and build sequence.

    • Non-functional requirements:

      • NFR1: (Usability) The implemented system needs to give users an adequate description of any issues experienced through integration to ease the correction process.
      • NFR2: (Safety Requirements) The Continuous integration/Continuous delivery system shall prevent any faulty code form being merged into the develop branch
      • NFR3: (Availability) The Continuous integration/Continuous delivery system shall be available 99 percent of the time to handle pull requests

    • Acceptance Criteria:

      • The building of the system should be automated for each pull request opened.
      • Unit testing and e2e testing should be automated.
      • Linting of code should be automated.
      • The correct standard for meta tags should be tested.
      • The automation scripts should also contain manual triggers for manual testing of code.
      • Automation scripts should run in parallel.
      • Test the entire code base after each push commit to main branches in the repository.

  • Blog

    • Project Manager: Estian Nel

    • Featured Group: The Radions

    • Description:

      • The blog will be a page that the University administrates that will contain information about the graduates, such as articles, information about the capstone project, demo day, marketing material etc.

    • Functional requirements:

      • FR1: Only admin can post and edit blogs. Must be viewable to anyone.
      • FR2: There should be an option to upload either a visual (pictures and videos) or textual story (with formatting-font, size, colour, bold, italics etc.). Also allow links to websites.
      • FR3: Blog will have its own page on the website, with a seperate page for admin (UP staff only) and one for viewing (general users).
      • FR4: The users should be able to comment and react to blogs. Previous blog posts should be viewable.
      • FR5: Content should be provided via an API as a “headless” content management system.

    • Non-functional requirements:

      • NFR1: When UP staff log in, they can access the blog page as admins and edit it and delete comments too. General users will not have access to this, they can only view the blog page.
      • NFR2: Blogs can be sorted starting with the most recently uploaded. Scroll to see previous blog posts.
      • NFR3: A user should be able to see when another blog was last posted more specifically the time and date.

    • Acceptance Criteria: - The general users must be able to easily navigate the page and read the blogs. The administrative staff that manage the blog must be able to easily upload blogs with various media content, as well as remove it if necessary.

  • Mobile

    • Project Manager: Andrey Omeltchenko

    • Featured Group: JavaScript

    • Description:

      • The mobile application feature will provide users with a pleasant user experience when interacting with the Graduates platform on a mobile device, as well as allowing users to access certain functions of the platform without requiring a constant internet connection. The 1.0 version release will be focused on implementing the UI and basic infrastructure of the application while keeping the key principles of a PWA in mind. Consecutive release versions could focus on integrating the features that are not ready for a mobile release at the time of the 1.0 version release.

    • Functional requirements:

      • FR1: Once the user opens the graduates portal, they should be able to install the web app and thereafter access it on their device.

      -the web app should have a web manifest with the correct fields

      -the web app should have a secure HTTPS domain

      -the web app should have an icon to represent it on the users device

      -the web app should have a registered service worker

      • FR2: When the web app is opened the user should have an experience on par with a mobile app.

      -the web app should have a simple installation process

      • FR3: The web app should be responsive to any screen size, meaning that the UI (User Interface) should fit on any device, thus the user should have the ability of opening the web app on any of their devices. (With regard to the first version of the web app, the web app should responsive to a generic device (ie. smartphones)).

      -icons and images: the web app should ensure that icons and images of the generic device of the appropriate size are retrieved.

      • FR4: The web app should work independent of internet connection (ie. work offline or at low network quality). The user should be able to revisit or browse sites they have once visited, even when internet connection is critical.
      • the web app should have a cached shell to load when offline.
      • FR5: All of the features of the web app should function as expected on a mobile app.

    • Non-functional requirements:

      • NFR1: The web app should be linkable, the user should have the ability to link to the web app using a specific URL without the need for an app store or a complicated installation procedure.

      • NFR2: the web app should have a look that aligns with the UI of the graduates portal.

      • NFR3: The performance of the web app should be similar to that of a mobile app, hence the user experience should be similar. The following metrics can be considered to ensure the web app performs optimally:

        • Time to interactive: The time it takes from when the application loads to the user being able to interact with it should be under 3.8 seconds.

      • First contentful paint: The time at which the first text or image is painted should be under 1.8 seconds.

      • Speed Index: How quickly content is visually displayed during page load should be under 3.4 seconds.

      • The largest contentful paint: The render time of the largest image or text block visible within the view-port, relative to when the page first started loading should be under 2.5 seconds.

      • Total blocking time: The total amount of time that the application’s pages are blocked from responding to user input should be under 0.2 seconds.

      • Cumulative layout shift: The largest burst of layout shift of layout shift scores for every unexpected layout shift that occurs during the entire lifespan of a page should have a score of 0.1 or less.

    • Acceptance Criteria: -When the user clicks on the install icon on the URL bar, they should be able to see the web app icon on the home screen of the respective device.

    -Upon opening the web app, the user should have the similar experience as they would if they were using a mobile app.

    -When the user once visited a page and losses connection or has bad internet connection, they still should be able to revisit the page they previously opened.

  • Request for access to information on student profile

    • Project Manager: Liam Burgess

    • Featured Group: C

    • Description:

      • A company's use of the graduates platform involves finding prospective employees for their bussiness (Company explore feature). When a company comes across a prospective employee (graduate) profile (Student profile feature), not all the information of such, may be available immediately to be viewed by the company. A request for access is required. This feature implements the request process from a request selection of what info, if not all, on the frontend to an api call and back end to reflect this request and what the requesting information is. The company request is acknowledged by the system and indicated to such company.
      • (for if the above is completed quickly or for next year):The student has the ability to review companies interested in them. This interest indicated in the form of requesting information from the user and being notified of such (Notification feature). This feature can further implement a frontend where the student may view such requests, accept or deny, and send the decision through the API to the backend to be reflected. And the system acknowledges and notifies the user.

    • Functional requirements (high level):

      • FR1 : The company is able request information of a prospective student for review
      • FR2 : The student is able to review and confirm/deny such requests

    • Non-functional requirements:

      • NFR1 : (Scalability) The information which can be requested can grow as new information sources are made available on profile
      • NFR2 : (Usability) The interface to make such requests should be simple and responsive with acknowledgements of such requests
      • Constraints: The system only allows request for access on CV, Academic Record and... for the system at release. The system requires to follow a color and UI scheme defined by the UI kit team.

    • Acceptance Criteria:

      1. The company can request for access on specific information and this information is reflected in the database.
      2. The fields requested for access are reflected upon viewing the student's profile again.

  • Company Representative's Profile

Rachel Hamilton, Business Analyst March 2022

- Project Manager: Isheanesu Joseph Dzingirai

- Featured Group: Ada

- Description:

The profile page for the representative of a company. Company Representatives will be able to sign up and sign into their account and have access to their profile where they are able to update and change the data they want on it.
The goal is to create a profile that will consist of a company page view, where the representative is able to upload media , profile information, view graduates profile information, and have access to registration and login.
Company representatives will also be able to access graduate profiles when in need to view a graduates information and/or contact them.

Functional Requirements

  1. The company representative must have the ability to create a profile.
  2. The company representative must have the ability to delete a profile.
  3. The company representative must have the ability to edit the profile. * add/remove media (profile picture, company logo, company feature videos) * add/remove basic profile information * add/remove links * add/remove company contact details (email, tel, branch locations) * add a short Company description * general information on the company representative
  4. The profile must include a private interface that only the company representatives can see which stores their prospective graduates they have scouted.
  5. The company representative must have the ability to contact graduates they have scouted.
  6. The profile must be graduate oriented, thus showing information related to the student.

Non-functional Requirements

  1. The basic design of the representatives profile should have a look that aligns with the UI of the company's portal.
  2. Data integrity - The company representative must have access to certain information on the graduates such as their academic record. This information cannot be leaked and should only be accessed by the company representative.
  3. Security - Certain information on the company representatives profile that needs to remain private, for the company representative's eyes only, can not be accessed by anyone else unless they login to the company representatives profile.
  4. Performance - All the features of the company representative profile must function as expected just as any profile on a web app should.

Constraints

  1. The profile must be maintained and managed by the Ada team.

  2. All profile implementation and documentation must be done by the Ada team.

  3. The company representative profile design created by the team designer, must be the design the Ada team follows.

  4. The UI Engineer of Ada must use nwrl/Angular to complete this project.

  5. The API Engineer of Ada must use GraphQl to complete this project.

  6. The Data Engineer of Ada must use Prisma, NestJS and Postgre to complete this project.

  7. The Services Engineer of Ada must use NestJS and CQRS to complete this project.