User Stories - Fetyali7/MAK-soen341project2023 GitHub Wiki

User Story #1 [Name of Product]:

  • As a developer, I want to have a good name for the product

~Story point: 1, very low effort needed, easy to come up with a name.

~Risk: 1, very low risk, name won't affect project much.

User Story #2 [Three Programming Languages]:

  • As a developer, I want three languages to build a career service

~Story point: 1, very low effort needed, researched best languages for databases and backend according to javascript.

~Risk: 2, depending on languages chosen, this may affect future needs for website; somewhat risky.

User Story #3 [Front-End Layout design]:

  • As a developer, I want a design layout for the front-end of the website

~Story point: 2, low effort, designed the layout using canva.

~Risk: 1, very low risk, can change the CSS styling easily and not affect the rest of the project.

User Story #4 [User Account]:

  • As a user, I want to create an account so that I can apply to job listings

~Story point: 4, mediocre amount of effort needed in order to learn and then implement/execute task.

~Risk: 2, must make database accordingly or else may affect future searches.

User Story #5 [Job Sorting]:

  • As a student, I want to be able to sort the job postings by company name or job position

~Story point: 3, one of the risks is the functionality of sorting with a medium probability and impact. The countermeasure is to use testing tools, such as integration testing and user acceptance testing to implement an accurate sorting algorithm. Another risk is related to performance issues with a high probability and impact. The countermeasure is to use techniques, such as caching and indexing to minimize the load on the system and speed up the process to sort. A story point of 3 was given because the level of difficulty is low.

~Risk: 2, important to sort properly if not, future sorting may be affected.

~Acceptance test suites: Functional and Usability acceptance tests.

User Story #6 [Application and notification from employers]:

  • As an applicant user, I would like to apply to Employers' job postings and get informed by the system in case the Employer selects me for an interview

Tasks:

  • Implement a job application form
  • Implement a page so the applicants can see the jobs they have applied to!
  • Implement an inbox page for employers so they get notified when someone applies for their job and an applicant inbox page for applicants so they get notified when an employer selects them for an interview
  • Implement databases for applying and notification

~Story point: 5, a risk related could be a privacy violation with a low probability and a high impact. The countermeasure is to ensure that the application is not visible to the public but only to the user or has an access control mechanism. Another risk could be an issue related to application visibility with a high probability and a high impact. A countermeasure to avoid this issue is to make sure that the application is visible to the user right after submission. This user story is straightforward as it displays the information that the user has submitted on the application form, hence the 5 story point.

~Risk: 3, high risk, most core functionalities are implemented in this user task and have major effects on the project.

~Acceptance test suites: Functional and Performance acceptance tests.

User Story #7 [Sign-up page]:

  • As a user, I would like to be able to sign up either as a Company or as a student.

Tasks:

  • Implement the options for applicants or employers
  • Store them in the database

~Story point: 4, were not sure how to do this. Most effort was spent referencing.

~Risk: 2, mediocre risk, need this functionality to make sure the site performs as envisioned.

User Story #8 [Employer job postings]:

  • As a company I would like to post my job offering

Tasks:

  • Create react front end for job posting page
  • Add css to job posting page
  • Send posted job to SQL database
  • Post job on finding page from database
  • Add css to finding page

~Story point: 5, the CSS was a low-effort task. The finding and getting/posting was more difficult due to inexperience.

~Risk: 3, great risk, this is a major backbone of the website, and without it, may cause major conflicts.

User Story #9 [Delete Job posting]:

  • As a company I would like to delete my job offering

Tasks:

  • Implement delete button on finding page job postings
  • Add css to delete button
  • If delete button is pressed delete job posting from database
  • Only I as a company can delete my own job postings

~Story point: 4, we got a hang of the database, so deleting was simple. More effort was done when only allowing the employer to delete their own posting.

~Risk: 1, low risk, does not affect platform too much.

User Story #10 [Edit Job posting]:

  • As a company I would like to edit my job offering

Tasks:

  • Implement edit button on finding page job postings
  • Add css to edit button
  • Implement react for when edit button is pressed to allow editing of job posting
  • When job posting is done being edited send the edited job posting to SQL database
  • Only I as a company can edit my own job postings

~Story point: 5, once again, got the hang of posting/getting the database. Most effort was due to the amount of implementations needed.

~Risk: 1, very low risk, not editing a job offer is not the end of the world.

User Story #11 [Login Page settings]:

  • As a user, I would like to login

Tasks:

  • Implement a login page
  • Implement css for the page
  • Get the data from the database and compare them to the values given on the login page and login if they match and put them in a new database called UserLogin

~Story point: 3, low effort. The CSS style is basic and comparing data from user input and database was much more familiar to us.

~Risk: 2, inorder to post and apply to jobs, users must login, this is risky as an error would lead to unpleasant affects.

User Story #12 [Logout Page settings]:

  • As a user, I would like to logout

Tasks:

  • Implement a logout page on the navbar
  • The functionality works and logs out the user
  • Delete the data from the UserLogin database

~Story point: 3, most effort was due to conceptualizing how to make this work, and maintaining another database for user logins.

~Risk: 1, very low risk, won't affect the platform too much, could implement an instant logout instead.

User Story #13 [Page Directed for applicant or Employer]:

  • As a user, I would like to have different pages such as posting jobs or job applications depending on whether I'm an applicant or an employee

Tasks:

  • Implement the pages
  • Filter the navbar based on the user being an applicant or employer

~Story point: 4, due to inexperience, mediocre effort was due to learning how to use mapping in javascript.

~Risk: 2, mediocre risk, is a core feature of the platform, and if it does not work may impact us negatively.

User Story #14 [Profile Page]:

  • As a user, I would like to have a profile page

Tasks:

  • Create profile page
  • Connection to profile database

~Story point: 2, low effort needed.

~Risk: 1, very low risk, does not affect the project too greatly.

User Story #15 [Static analysis with SonarQube]:

  • Use SonarQube to analyze front-end and back-end code

~Story point: 2, low effort needed, manual bug fixes.

~Risk: 1, very low risk, does not affect the project too greatly.

User Story #16 [CI Pipeline]

  • Set up a continuous integration pipeline using Jest

~Story point: 3, minimal effort needed.

~Risk: 1, very low risk as it won't affect the project.