+
-[[homepage](http://www.comp.nus.edu.sg/~damithch)]
-[[github](https://github.com/johndoe)]
-[[portfolio](team/johndoe.md)]
+[[github](http://github.com/JeffZincatz)] [[portfolio](team/jeffzincatz.md)]
-* Role: Project Advisor
+* Role: Developer
+* Responsibilities:
+ * Position and interview modelling
+ * List commands (`list_p` and `list_i`)
+ * Refactoring GUI components
+ * Formatting for UG and DG
+ * Reviewing PRs
-### Jane Doe
+### Chua Sue-Ann
-
-[[github](http://github.com/johndoe)]
-[[portfolio](team/johndoe.md)]
+[[github](http://github.com/sueann-chua)] [[portfolio](team/sueann-chua.md)]
-* Role: Team Lead
-* Responsibilities: UI
+* Role: Developer
+* Responsibilities:
+ * Edit and Assign commands (`edit_p`, `edit_i` and `assign`)
+ * Proofreading changes to UG and DG
-### Johnny Doe
+### Mohamed Noriman
-
-[[github](http://github.com/johndoe)] [[portfolio](team/johndoe.md)]
+[[github](http://github.com/seaweediman)] [[portfolio](team/seaweediman.md)]
* Role: Developer
-* Responsibilities: Data
+* Responsibilities:
+ * Remark candidate command (`remark_c`)
+ * Add position command (`add_p`)
+ * Delete interview command (`delete_i`)
+ * 'Unassign' command (`unassign`)
+ * Reviewing PRs
-### Jean Doe
+### Liu Wanyu
-
-[[github](http://github.com/johndoe)]
-[[portfolio](team/johndoe.md)]
+[[github](http://github.com/wanyu-l)] [[portfolio](team/wanyu-l.md)]
* Role: Developer
-* Responsibilities: Dev Ops + Threading
+* Responsibilities:
+ * Draft Position Model
+ * Changes to Storage Component
+ * Delete position command (`delete_p`)
+ * Add interview command (`add_i`)
+ * Code tests
-### James Doe
+### Nobel Ang
-
-[[github](http://github.com/johndoe)]
-[[portfolio](team/johndoe.md)]
+[[github](http://github.com/angnobel)] [[portfolio](team/angnobel.md)]
* Role: Developer
-* Responsibilities: UI
+* Responsibilities:
+ * Handle Github issues and milestones
+ * `find_x` command, documentation and tests
diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md
index 46eae8ee565..b1f79467ef2 100644
--- a/docs/DeveloperGuide.md
+++ b/docs/DeveloperGuide.md
@@ -2,20 +2,42 @@
layout: page
title: Developer Guide
---
-* Table of Contents
+
--------------------------------------------------------------------------------------------------------------------
-
## **Acknowledgements**
-* {list here sources of all reused/adapted ideas, code, documentation, and third-party libraries -- include links to the original source as well}
+* This project is based on the AddressBook-Level3 project created by the [SE-EDU initiative](https://se-education.org).
+
+--------------------------------------------------------------------------------------------------------------------
+## **Introduction** ##
+
+HR Manger is a simple to use and easy to learn local desktop application that allows you to easily manage your candidates, positions and interviews.
+HR Manager is built on Java and can be run on all major desktop operating systems. HR Manager has a graphic user interface to display information and uses text-based commands to interact with the application.
+
+--------------------------------------------------------------------------------------------------------------------
+## **Purpose** ##
+
+The purpose of this guide is to provide a comprehensive documentation of the design and overview of the application for developers to quickly onboard and develop the application.
+
+You can read the entire guide from the start, which will give you a complete view of the structure of HR Manager.
+
+Alternatively, you can quickly get started by reading through the [Setting Up](#setting-up-getting-started) and [Design](#design) sections to get a overview of the application.
+You can then read the [Feature Implementation](#feature-implementation) for more details of specific features.
--------------------------------------------------------------------------------------------------------------------
## **Setting up, getting started**
-Refer to the guide [_Setting up and getting started_](SettingUp.md).
+
+*HR Manager* is a desktop application built with JavaFX GUI which aims to help with the HR management in small companies. With the application, the user will be able to easily manage their candidates, job postings, and interview sessions.
+
+To set up the application, please refer to the guide [_Setting up and getting started_](SettingUp.md).
+
--------------------------------------------------------------------------------------------------------------------
@@ -23,12 +45,12 @@ Refer to the guide [_Setting up and getting started_](SettingUp.md).
+
The ***Architecture Diagram*** given above explains the high-level design of the App.
@@ -36,7 +58,7 @@ Given below is a quick overview of main components and how they interact with ea
**Main components of the architecture**
-**`Main`** has two classes called [`Main`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/Main.java) and [`MainApp`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/MainApp.java). It is responsible for,
+**`Main`** has two classes called [`Main`](https://github.com/AY2122S1-CS2103T-W13-1/tp/tree/master/src/main/java/seedu/address/Main.java) and [`MainApp`](https://github.com/AY2122S1-CS2103T-W13-1/tp/tree/master/src/main/java/seedu/address/MainApp.java). It is responsible for,
* At app launch: Initializes the components in the correct sequence, and connects them up with each other.
* At shut down: Shuts down the components and invokes cleanup methods where necessary.
@@ -54,7 +76,7 @@ The rest of the App consists of four components.
The *Sequence Diagram* below shows how the components interact with each other for the scenario where the user issues the command `delete 1`.
-
+
Each of the four main components (also shown in the diagram above),
@@ -63,19 +85,19 @@ Each of the four main components (also shown in the diagram above),
For example, the `Logic` component defines its API in the `Logic.java` interface and implements its functionality using the `LogicManager.java` class which follows the `Logic` interface. Other components interact with a given component through its interface rather than the concrete class (reason: to prevent outside component's being coupled to the implementation of a component), as illustrated in the (partial) class diagram below.
-
+
The sections below give more details of each component.
### UI component
-The **API** of this component is specified in [`Ui.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/ui/Ui.java)
+The **API** of this component is specified in [`Ui.java`](https://github.com/AY2122S1-CS2103T-W13-1/tp/tree/master/src/main/java/seedu/address/ui/Ui.java)
The UI consists of a `MainWindow` that is made up of parts e.g.`CommandBox`, `ResultDisplay`, `PersonListPanel`, `StatusBarFooter` etc. All these, including the `MainWindow`, inherit from the abstract `UiPart` class which captures the commonalities between classes that represent parts of the visible GUI.
-The `UI` component uses the JavaFx UI framework. The layout of these UI parts are defined in matching `.fxml` files that are in the `src/main/resources/view` folder. For example, the layout of the [`MainWindow`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/ui/MainWindow.java) is specified in [`MainWindow.fxml`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/resources/view/MainWindow.fxml)
+The `UI` component uses the JavaFx UI framework. The layout of these UI parts are defined in matching `.fxml` files that are in the `src/main/resources/view` folder. For example, the layout of the [`MainWindow`](https://github.com/AY2122S1-CS2103T-W13-1/tp/tree/master/src/main/java/seedu/address/ui/MainWindow.java) is specified in [`MainWindow.fxml`](https://github.com/AY2122S1-CS2103T-W13-1/tp/tree/master/src/main/resources/view/MainWindow.fxml)
The `UI` component,
@@ -86,168 +108,191 @@ The `UI` component,
### Logic component
-**API** : [`Logic.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/logic/Logic.java)
+**API** : [`Logic.java`](https://github.com/AY2122S1-CS2103T-W13-1/tp/tree/master/src/main/java/seedu/address/logic/Logic.java)
Here's a (partial) class diagram of the `Logic` component:
-
+
How the `Logic` component works:
-1. When `Logic` is called upon to execute a command, it uses the `AddressBookParser` class to parse the user command.
-1. This results in a `Command` object (more precisely, an object of one of its subclasses e.g., `AddCommand`) which is executed by the `LogicManager`.
+1. When `Logic` is called upon to execute a command, it uses the `HrManagerParser` class to parse the user command.
+1. This results in a `Command` object (more precisely, an object of one of its subclasses e.g., `AddCandidateCommand`) which is executed by the `LogicManager`.
1. The command can communicate with the `Model` when it is executed (e.g. to add a person).
-1. The result of the command execution is encapsulated as a `CommandResult` object which is returned back from `Logic`.
+1. The result of the command execution is encapsulated as a `CommandResult` object which is returned from `Logic`.
-The Sequence Diagram below illustrates the interactions within the `Logic` component for the `execute("delete 1")` API call.
+The Sequence Diagram below illustrates the interactions within the `Logic` component for the `execute("delete_c 1")` API call.
-
+
-:information_source: **Note:** The lifeline for `DeleteCandidateCommandParser` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
Here are the other classes in `Logic` (omitted from the class diagram above) that are used for parsing a user command:
-
+
How the parsing works:
-* When called upon to parse a user command, the `AddressBookParser` class creates an `XYZCommandParser` (`XYZ` is a placeholder for the specific command name e.g., `AddCommandParser`) which uses the other classes shown above to parse the user command and create a `XYZCommand` object (e.g., `AddCommand`) which the `AddressBookParser` returns back as a `Command` object.
-* All `XYZCommandParser` classes (e.g., `AddCommandParser`, `DeleteCommandParser`, ...) inherit from the `Parser` interface so that they can be treated similarly where possible e.g, during testing.
+* When called upon to parse a user command, the `HrManagerParser` class creates an `XYZCommandParser` (`XYZ` is a placeholder for the specific command name e.g., `AddCandidateCommandParser`) which uses the other classes shown above to parse the user command and create a `XYZCommand` object (e.g., `AddCandidateCommand`) which the `HrManagerParser` returns as a `Command` object.
+ * Most significantly, the ArgumentTokenizer is used to parse the arguments using the provided prefixes to retrieve the inputs from the user
+* All `XYZCommandParser` classes (e.g., `AddCandidateCommandParser`, `DeletePositionCommandParser`, ...) inherit from the `Parser` interface so that they can be treated similarly where possible e.g, during testing.
### Model component
-**API** : [`Model.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/model/Model.java)
-
-
+**API** : [`Model.java`](https://github.com/AY2122S1-CS2103T-W13-1/tp/tree/master/src/main/java/seedu/address/model/Model.java)
+ +
+
+
The `Model` component, -* stores the address book data i.e., all `Person` objects (which are contained in a `UniquePersonList` object). -* stores the currently 'selected' `Person` objects (e.g., results of a search query) as a separate _filtered_ list which is exposed to outsiders as an unmodifiable `ObservableList
:information_source: **Note:** An alternative (arguably, a more OOP) model is given below. It has a `Tag` list in the `AddressBook`, which `Person` references. This allows `AddressBook` to only require one `Tag` object per unique tag, instead of each `Person` needing their own `Tag` objects.
- -
-
-
-
-
### Storage component
-**API** : [`Storage.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/storage/Storage.java)
+**API** : [`Storage.java`](https://github.com/AY2122S1-CS2103T-W13-1/tp/tree/master/src/main/java/seedu/address/storage/Storage.java)
-- -
-
-
+
The `Storage` component,
-* can save both address book data and user preference data in json format, and read them back into corresponding objects.
-* inherits from both `AddressBookStorage` and `UserPrefStorage`, which means it can be treated as either one (if only the functionality of only one is needed).
-* depends on some classes in the `Model` component (because the `Storage` component's job is to save/retrieve objects that belong to the `Model`)
+* can save both HR Manager data and user preference data in json format, and read them back into corresponding objects.
+* inherits from both `HrManagerStorage` and `UserPrefStorage`, which means it can be treated as either one (if only the functionality of only one is needed).
+* depends on some classes in the `Model` component (because the `Storage` component's job is to save/retrieve objects that belong to the `Model`).
### Common classes
-Classes used by multiple components are in the `seedu.addressbook.commons` package.
+Classes used by multiple components are in the `seedu.address.commons` package.
--------------------------------------------------------------------------------------------------------------------
-## **Implementation**
+## **Documentation, logging, testing, configuration, dev-ops**
-This section describes some noteworthy details on how certain features are implemented.
+* [Documentation guide](Documentation.md)
+* [Testing guide](Testing.md)
+* [Logging guide](Logging.md)
+* [Configuration guide](Configuration.md)
+* [DevOps guide](DevOps.md)
-### \[Proposed\] Undo/redo feature
+--------------------------------------------------------------------------------------------------------------------
+## **Feature Implementation** ##
-#### Proposed Implementation
+### **Find Commands** ###
-The proposed undo/redo mechanism is facilitated by `VersionedAddressBook`. It extends `AddressBook` with an undo/redo history, stored internally as an `addressBookStateList` and `currentStatePointer`. Additionally, it implements the following operations:
+The `find_c`, `find_p` and `find_i` command allows users to search for candidates, positions and interviews using their parameters.
+Generally, they are called `find_x` in this section.
-* `VersionedAddressBook#commit()` — Saves the current address book state in its history.
-* `VersionedAddressBook#undo()` — Restores the previous address book state from its history.
-* `VersionedAddressBook#redo()` — Restores a previously undone address book state from its history.
+The class structure of an execution of `find_x` command is as follows. Only important classes are shown.
+
-These operations are exposed in the `Model` interface as `Model#commitAddressBook()`, `Model#undoAddressBook()` and `Model#redoAddressBook()` respectively.
+The `FindXCommandPredicate` holds the parsed arguments from the command and a `test` method to check if X fufils the condition
-Given below is an example usage scenario and how the undo/redo mechanism behaves at each step.
+The sequence diagram of a `find_x` command execution is as follows:
-Step 1. The user launches the application for the first time. The `VersionedAddressBook` will be initialized with the initial address book state, and the `currentStatePointer` pointing to that single address book state.
+Firstly, the parsing of the command and argument occurs as follows
+
-
+Continuing the previous diagram, the FindXCommand is executed, and the UI is updated
+
-Step 2. The user executes `delete 5` command to delete the 5th person in the address book. The `delete` command calls `Model#commitAddressBook()`, causing the modified state of the address book after the `delete 5` command executes to be saved in the `addressBookStateList`, and the `currentStatePointer` is shifted to the newly inserted address book state.
+#### Design Considerations ####
+Aspect: Logical operators and combinations for find fields
+* Implemented: AND between separate fields and OR within multiple entries in same field
+ * eg: `find_c name=alex brad phone=12345678` === `(phone=12345678) AND (name contains alex OR brad)`
+ * Pros: Easy to implement, simple command format for the most common usecase
+ * Cons: Unable to search using more complex combination of logical operators
+* Alternative: Allow users to specify which operators are used and how they are combined
+ * Pros: Give granular control to the user for find
+ * Cons: Very complex command format
-
-Step 3. The user executes `add n/David …` to add a new person. The `add` command also calls `Model#commitAddressBook()`, causing another modified address book state to be saved into the `addressBookStateList`.
+### **List Commands** ###
-
+The `list_c`, `list_p` and `list_i` command allows users to list all candidates, positions and interviews in the respective display panel.
+Generally, they are called `list_x` in this section.
-:information_source: **Note:** If a command fails its execution, it will not call `Model#commitAddressBook()`, so the address book state will not be saved into the `addressBookStateList`.
+The class structure of an execution of `list_x` command is as follows. Only important classes are shown.
-
+
-Step 4. The user now decides that adding the person was a mistake, and decides to undo that action by executing the `undo` command. The `undo` command will call `Model#undoAddressBook()`, which will shift the `currentStatePointer` once to the left, pointing it to the previous address book state, and restores the address book to that state.
+The `ListXCommandPredicate` uses the preset predicate such that all X fulfills the condition.
-
+The sequence diagram of a `list_x` command execution is as follows:
-:information_source: **Note:** If the `currentStatePointer` is at index 0, pointing to the initial AddressBook state, then there are no previous AddressBook states to restore. The `undo` command uses `Model#canUndoAddressBook()` to check if this is the case. If so, it will return an error to the user rather
-than attempting to perform the undo.
+Firstly, the parsing of the command and argument occurs as follows
-
+
-The following sequence diagram shows how the undo operation works:
+Continuing the previous diagram, the ListXCommand is executed, and the corresponding X panel in the UI is updated
-
+
-:information_source: **Note:** The lifeline for `UndoCommand` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
+### **Edit Commands** ###
-
-
-The `redo` command does the opposite — it calls `Model#redoAddressBook()`, which shifts the `currentStatePointer` once to the right, pointing to the previously undone state, and restores the address book to that state.
+The `edit_c`, `edit_p` and `edit_i` commands allow users to edit a specific candidate, position
+or interview in the respective display panel.
-:information_source: **Note:** If the `currentStatePointer` is at index `addressBookStateList.size() - 1`, pointing to the latest address book state, then there are no undone AddressBook states to restore. The `redo` command uses `Model#canRedoAddressBook()` to check if this is the case. If so, it will return an error to the user rather than attempting to perform the redo.
-
-
+Generally, they are called `edit_x` in this section.
-Step 5. The user then decides to execute the command `list`. Commands that do not modify the address book, such as `list`, will usually not call `Model#commitAddressBook()`, `Model#undoAddressBook()` or `Model#redoAddressBook()`. Thus, the `addressBookStateList` remains unchanged.
+The edit mechanism is facilitated by `editXDescriptor`, where X is the placeholder for the object to be edited, for example
+`editPersonDescriptor` for editing candidates, `editPositionDescriptor` for editing positions, and
+`editInterviewDescriptor` for editing interviews, and each non-empty field value will replace the corresponding
+field value of the object that is being edited. `editXDescriptor` stores the details to edit the candidate,
+position or interview with. `editXCommand` extends `Command` and implements the
+`Command#execute()` operation, which executes the command and returns a result message to be displayed.
-
+Similar to any other command, the `Command#execute()` operation is exposed in the `Logic` interface as
+`Logic#execute()`. Please refer to the 'Logic component' under 'Design' for information on how the `Logic`
+component works when a command is executed.
-Step 6. The user executes `clear`, which calls `Model#commitAddressBook()`. Since the `currentStatePointer` is not pointing at the end of the `addressBookStateList`, all address book states after the `currentStatePointer` will be purged. Reason: It no longer makes sense to redo the `add n/David …` command. This is the behavior that most modern desktop applications follow.
+As an example, the parsing and execution of an edit_p command is as follows
-
+
-The following activity diagram summarizes what happens when a user executes a new command:
+### **Add commands** ###
-
+The `add_c`, `add_p` and `add_i` commands allow users to add a candidate, position
+or interview in the respective display panel.
-#### Design considerations:
+Generally, they are called `add_x` in this section. I will also be using X to represent a candidate, position or interview here.
-**Aspect: How undo & redo executes:**
+The add_x functionality is facilitated by `ModelManager`. It uses the following operation of `ModelManager`.
+- `ModelManager#hasX()` — Check if the candidate, position or interview already exists within Hr Manager. If so, `CommandException` will be thrown.
-* **Alternative 1 (current choice):** Saves the entire address book.
- * Pros: Easy to implement.
- * Cons: May have performance issues in terms of memory usage.
+- `ModelManager#addX()` — Adds a candidate, position or interview to Hr Manager. If that position already exists, a
+ `DuplicatePositionException` will be thrown.
-* **Alternative 2:** Individual command knows how to undo/redo by
- itself.
- * Pros: Will use less memory (e.g. for `delete`, just save the person being deleted).
- * Cons: We must ensure that the implementation of each individual command are correct.
+`AddXCommandParser` and `AddXCommand` are created to achieve this functionality.
+
-_{more aspects and alternatives to be added}_
+Given below is an example usage scenario and the workflow of the`add_x` command.
-### \[Proposed\] Data archiving
+Step 1. The user executes command `add_x...`.
+`Ui` component reads the command as a string from user's input. After that, `MainWindow`
+passes the string to `LogicManager` to manipulate the command.
-_{Explain here how the data archiving feature will be implemented}_
+Step 2. `LogicManager` passes the command to `HrManagerParser` to parse the command. Since the command starts
+with `add_x`, a new `AddXCommandParser` is created to parse the command further.
+Step 3. `AddXCommandParser` uses `ArgumentMultimap` to tokenize the prefixes part the command. After extracting the
+information of the object such as the title of a position or the name of a candidate, a new `X` is created and a new
+`AddXCommand` is created with that `X`.
---------------------------------------------------------------------------------------------------------------------
+Step 4. `AddXCommand` passes the given `X` to `ModelManager#hasX`. If the position does not exist in the app, `AddXCommand`
+passes the `Position` to `ModelManager#addPosition()`.
-## **Documentation, logging, testing, configuration, dev-ops**
+Step 5. `Modelmanager#addX()` updates the respective list with the new added `X`.
-* [Documentation guide](Documentation.md)
-* [Testing guide](Testing.md)
-* [Logging guide](Logging.md)
-* [Configuration guide](Configuration.md)
-* [DevOps guide](DevOps.md)
+To better illustrate this example, the parsing and execution of an add_p command is as follows
+
--------------------------------------------------------------------------------------------------------------------
@@ -257,73 +302,259 @@ _{Explain here how the data archiving feature will be implemented}_
**Target user profile**:
-* has a need to manage a significant number of contacts
+* is HR professional
+* has to manage multiple applicants, roles, and interviews
* prefer desktop apps over other types
* can type fast
* prefers typing to mouse interactions
* is reasonably comfortable using CLI apps
-**Value proposition**: manage contacts faster than a typical mouse/GUI driven app
-
+**Value proposition**: help them quickly enter the data into the system, reminders of interview timings and ranking of candidates for roles
### User stories
Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unlikely to have) - `*`
-| Priority | As a … | I want to … | So that I can… |
-| -------- | ------------------------------------------ | ------------------------------ | ---------------------------------------------------------------------- |
-| `* * *` | new user | see usage instructions | refer to instructions when I forget how to use the App |
-| `* * *` | user | add a new person | |
-| `* * *` | user | delete a person | remove entries that I no longer need |
-| `* * *` | user | find a person by name | locate details of persons without having to go through the entire list |
-| `* *` | user | hide private contact details | minimize chance of someone else seeing them by accident |
-| `*` | user with many persons in the address book | sort persons by name | locate a person easily |
-
-*{More to be added}*
+| Priority | As a … | I want to … | So that I can… |
+| -------- | ---------- | ------------------------------ | ---------------------------------------------------------------------- |
+| `* * *` | user | be able to add a candidate with all relevant information such as full name, age, contact information, scheduled interview time and date.| |
+| `* * *` | user | be able to delete a candidate | remove the application if it was withdrawn entirely |
+| `* * *` | user | be able to see all active candidates | |
+| `* * *` | user | be able to see the details of a specific candidate | |
+| `* * *` | user | be able to edit the information related to a candidate | correct any wrongly filled information |
+| `* * *` | user | be able to categorize the candidate, whether it was self-applied or referred | carry out administrative processes afterwards more easily |
+| `* * *` | user | be able to add a remark/status to a candidate | make it more visible for the next course of administrative action|
+| `* * *` | user | be able to edit comments of a candidate | update any further remarks for them|
+| `* * *` | user | be able to delete comments of a candidate | remove mistakenly put remarks entirely |
+| `* * *` | user | be able to edit existing tags of a candidate | |
+| `* * *` | user | be able to remove existing tags of a candidate | |
+| `* * *` | user | be able to search for a particular candidate to see his/her upcoming sessions | |
+| `* * *` | user searching for candidates | be able to search for candidates who have a certain remark/description | find candidates by criteria |
+| `* * *` | user | be able to add a job position with its job title | |
+| `* * *` | user | be able to delete a job position | remove the job posting if it was no longer open |
+| `* * *` | user | be able to see all posted job positions | |
+| `* * *` | user preparing interviews | be able to delete an interview session for a candidate if it no longer takes place | |
+| `* * *` | user preparing interviews | be able to view all candidates who will be interviewed on a particular date | keep track of the interviews planned for that day |
+| `* * *` | user after interviews | be able to tag a candidate e.g. by the position they are applying for | group them according to the tags |
+| `* *` | user | see all the candidates scheduled for interview sessions for a particular job posting | |
+| `* *` | user searching for candidates | be able to filter the candidates for some specific requirements | find the right person for the post more efficiently |
+| `* *` | user searching for candidates | be able to search who applied for certain positions | I know all the candidates for that specific position |
+| `* *` | user after interviews | be able to mark a candidate as ‘Interviewed’ | |
+| `* *` | user preparing interviews | be able to schedule a new interview for a candidate | recruit more talent |
+| `* *` | user preparing interviews | be able to delete all other scheduled interview sessions for a particular candidate once I decide to assign him a particular post | |
+| `* *` | user preparing interviews | be reminded of what interviews I have the next day | keep track of them |
+| `* *` | user preparing interviews | be able to reschedule the interview session for a candidate | so that I can keep up with changes coming from the candidate's end |
+| `* *` | user preparing interviews | be able to delete the interview sessions on a particular date | |
+| `* *` | user preparing interviews | search what interviews I have for a particular date | better prepare for that day |
+| `*` | user preparing interviews | add a co-interviewer to an interview | I know who I will be interviewing the candidate with |
+| `*` | user | be able to password lock the application to prevent unauthorised access | |
+| `*` | user | encrypt the save file | prevent my data from being easily stolen |
### Use cases
-(For all use cases below, the **System** is the `AddressBook` and the **Actor** is the `user`, unless specified otherwise)
+#### Use case: UC01 - Add a candidate
+
+**MSS**
+
+1. User requests to add a new candidate, with the initial details of the new candidate.
+2. User can see the added candidate.
+
+ Use case ends.
+
+**Extensions**
+
+* 1a. The format when adding a candidate is incorrect.
+
+ * 1a1. HR Manager shows an error message.
+
+ Use case ends.
+
+* 1b. The position title the user provided does not exist in the position list.
+
+ * 1b1. HR Manager shows an error message.
+
+ Use case ends.
+
-**Use case: Delete a person**
+#### Use case: UC02 - List all candidates
**MSS**
-1. User requests to list persons
-2. AddressBook shows a list of persons
-3. User requests to delete a specific person in the list
-4. AddressBook deletes the person
+1. User requests to list all candidates.
+2. HR Manager shows a list of all candidates.
- Use case ends.
+ Use case ends.
**Extensions**
-* 2a. The list is empty.
+* 2a. The list of candidates is empty.
+ * 2a1. HR Manager shows that list is empty.
- Use case ends.
+ Use case ends.
+
+#### Use case: UC03 - Delete a candidate
+
+**MSS**
+
+1. User requests to list all candidates (UC02).
+2. User requests to delete a specific candidate.
+3. HR Manager deletes the corresponding candidate and displays result.
+
+ Use case ends
+
+**Extensions**
* 3a. The given index is invalid.
- * 3a1. AddressBook shows an error message.
+ * 3a1. HR Manager shows an error message.
Use case resumes at step 2.
-*{More to be added}*
+#### Use case: UC04 - Add a position
-### Non-Functional Requirements
+**MSS**
+
+1. User requests to add a new position, with the title of the new job position.
+2. User can see the added job position.
+
+ Use case ends.
+
+**Extensions**
+
+* 1a. The format when adding a position is incorrect.
+
+ * 1a1. HR Manager shows an error message.
+
+ Use case ends.
+
+* 1b. The position title the user provided already exists in the position list.
-1. Should work on any _mainstream OS_ as long as it has Java `11` or above installed.
-2. Should be able to hold up to 1000 persons without a noticeable sluggishness in performance for typical usage.
-3. A user with above average typing speed for regular English text (i.e. not code, not system admin commands) should be able to accomplish most of the tasks faster using commands than using the mouse.
+ * 1b1. HR Manager shows an error message.
-*{More to be added}*
+ Use case ends.
+
+#### Use case: UC05 - List all positions
+
+**MSS**
+
+1. User requests to list all positions
+2. HR Manager shows a list of all positions
+
+ Use case ends.
+
+**Extensions**
+
+* 2a. The list of positions is empty.
+ * 2a1. HR Manager shows that list is empty.
+
+ Use case ends.
+
+#### Use case: UC06 - Delete a position
+
+**MSS**
+
+1. User requests to list all positions (UC05).
+2. User requests to delete a specific position.
+3. HR Manager deletes the corresponding position and displays result.
+
+ Use case ends
+
+**Extensions**
+
+* 2a. The given index is invalid.
+
+ * 2a1. HR Manager shows an error message.
+
+ Use case resumes at step 2.
+
+
+#### Use case: UC07 - Add an interview
+
+**MSS**
+
+1. User requests to list all positions (UC05).
+2. User requests to list all candidates (UC03).
+3. User requests to add an interview with details for the interview.
+4. HR Manager adds interview.
+5. User can see the added job position.
+
+ Use case ends.
+
+**Extensions**
+
+* 3a. The given position is invalid.
+
+ * 3a1. HR Manager shows an error message.
+
+ Use case resumes at step 3.
+
+* 3b. The given index is invalid.
+
+ * 3b1. HR Manager shows an error message.
+
+ Use case resumes at step 3.
+
+* 3c. The given date is invalid.
+
+ * 3c1. HR Manager shows an error message.
+
+ Use case resumes at step 3.
+
+* 3d. The given time is invalid.
+
+ * 3d1. HR Manager shows an error message.
+
+ Use case resumes at step 3.
+
+* 3e. The given duration is invalid.
+
+ * 3d1. HR Manager shows an error message.
+
+ Use case resumes at step 3.
+
+* 3f. The given status is invalid.
+
+ * 3d1. HR Manager shows an error message.
+
+ Use case resumes at step 3.
+
+#### Use case: UC08 - List all interviews
+
+**MSS**
+
+1. User requests to list all positions
+2. HR Manager shows a list of all positions
+
+ Use case ends.
+
+#### Use case: UC09 - Delete an interview
+
+1. User requests to list all interviews (UC08).
+2. User requests to delete a specific interview.
+3. HR Manager deletes the corresponding position and displays result.
+
+ Use case ends.
+
+**Extensions**
+
+* 2a. The given index is invalid.
+
+ * 2a1. HR Manager shows an error message.
+
+ Use case resumes at step 2.
+
+
+### Non-Functional Requirements
+
+1. Program needs to run on all operating systems with Java 11 installed.
+2. Application needs to handle at least 500 candidates and 500 interviews without a noticeable sluggishness in performance for typical usage and no graphical errors.
+3. A user with above average typing speed should be able to complete tasks faster using commands than they would have using a click-based interface.
### Glossary
* **Mainstream OS**: Windows, Linux, Unix, OS-X
* **Private contact detail**: A contact detail that is not meant to be shared with others
---------------------------------------------------------------------------------------------------------------------
## **Appendix: Instructions for manual testing**
@@ -334,44 +565,244 @@ testers are expected to do more *exploratory* testing.