DeveloperGuide.adoc

HireLah! - Developer Guide

By: AY1920S2-CS2103-W15-2      Since: Feb 2020      Licence: MIT

• 1. Introduction
  • 1.1. Purpose and Audience
• 2. Setting up
• 3. Design
  • 3.1. Architecture
  • 3.2. UI component
  • 3.3. Logic component
  • 3.4. Model component
  • 3.5. Storage component
  • 3.6. Common classes
• 4. Implementation
  • 4.1. Session Feature
  • 4.2. Find Best Interviewees Feature
  • 4.3. Logging
  • 4.4. Configuration
• 5. Documentation
• 6. Testing
• 7. Dev Ops
• Appendix A: Product Scope
• Appendix B: User Stories
• Appendix C: Use Cases
  • C.1. Use case: UC21 - Choose Best Interviewees
• Appendix D: Non Functional Requirements
• Appendix E: Glossary
• Appendix F: Product Survey
• Appendix G: Instructions for Manual Testing
  • G.1. Launch and Shutdown
  • G.2. Deleting a person
  • G.3. Saving data

1. Introduction

HireLah! is a productivity app designed to help busy interviewers manage multiple interview sessions in an orderly manner. During each interview session, HireLah! helps the user to keep track of interviewee information and interview rubrics in one central location, making the interview process more efficient.

HireLah! has the following main features:

1. Manage multiple interview sessions.

2. Manage interview rubrics for each interview session, including:

   1. Attributes to look out for in interviewees.

   2. Questions to ask interviewees.

   3. Metrics to rank interviewees based on their performance.

3. Manage remarks and score entered by the user during an interview.

4. Rank interviewees based on particular sets of attributes or a metric after interviews.

5. Export interview transcripts as reference.

1.1. Purpose and Audience

This Developer Guide specifies the architecture, design and implementation of HireLah!, as well as our considerations while designing this app.

It is intended for developers, software testers, and people who would like to enhance this project in one way or another to understand HireLah! on a deeper level.

2. Setting up

Refer to the guide here.

3. Design

3.1. Architecture

Figure 1. Architecture Diagram

The Architecture Diagram given above explains the high-level design of the App. Given below is a quick overview of each component.

💡	The .puml files used to create diagrams in this document can be found in the diagrams folder. Refer to the Using PlantUML guide to learn how to create and edit diagrams.

Main has two classes called Main and MainApp. 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 method where necessary.

Commons represents a collection of classes used by multiple other components. The following class plays an important role at the architecture level:

• LogsCenter : Used by many classes to write log messages to the App’s log file.

The rest of the App consists of four components.

• UI: The UI of the App.

• Logic: The command executor.

• Model: Holds the data of the App in-memory.

• Storage: Reads data from, and writes data to, the hard disk.

Each of the four components

• Defines its API in an interface with the same name as the Component.

• Exposes its functionality using a {Component Name}Manager class.

For example, the Logic component (see the class diagram given below) defines it’s API in the Logic.java interface and exposes its functionality using the LogicManager.java class.

Figure 2. Class Diagram of the Logic Component

How the architecture components interact with each other

The Sequence Diagram below shows how the components interact with each other for the scenario where the user issues the command add attribute leadership.

Figure 3. Component interactions for add attribute leadership command

The sections below give more details of each component.

3.2. UI component

Figure 4. Structure of the UI Component

API : 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.

The UI component uses 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 is specified in MainWindow.fxml

The UI component,

• Executes user commands using the Logic component.

• After executing each command, performs command-specific view updates as instructed by the CommandResult returned by that command.

• Listens for changes to Model data so that the UI can be updated with the modified data.

3.3. Logic component

Figure 5. Structure of the Logic Component

API : Logic.java

1. Logic uses either the NormalParser or InterviewParser class to parse the user command, depending on the app phase stored in the Model.

2. This results in a Command object which is executed by the LogicManager.

3. The command execution can affect the Model (e.g. adding an attribute).

4. The command execution may also call the storage to save the Model if the command modified the Model.

5. The result of the command execution is encapsulated as a CommandResult object which is passed back to the Ui.

6. The CommandResult object then instructs the Ui to perform certain actions, such as displaying the list of the current attribute.

Given below is the Sequence Diagram for interactions within the Logic component for the execute("add attribute leadership") API call.

Figure 6. Interactions Inside the Logic Component for the add attribute leadership Command

ℹ️

The lifeline for AddCommandParser should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram. The exact details of how AddAttributeCommand gets the AttributeList from Model, then modifies the list, then passes the AttributeList to Storage is left out in this diagram.

3.4. Model component

Figure 7. Structure of the Model Component

API : Model.java

The Model,

• stores a UserPref object that represents the user’s preferences.

• stores the session data including questions, attributes, metrics, and interviewees including their interview transcripts.

• stores the current app state, including whether the user has finalised the attributes and questions, the current phase that the app is in (pre-session, in the normal phase or in an interview), the current session and the current interviewee in focus, whether being interviewed or whose report is being viewed.

• exposes an unmodifiable ObservableList<Attribute>, ObservableList<Question>, ObservableList<Metric>, ObservableList<Interviewee> that can be 'observed' e.g. the UI can be bound to this list so that the UI automatically updates when the data in the list change.

3.5. Storage component

Figure 8. Structure of the Storage Component

API : Storage.java

The Storage component,

• can save UserPref objects in json format and read it back.

• can save the Model data in json format and read it back.

  • Save IntervieweeList to interviewee.json

  • Save AttributeList to attribute.json

  • Save QuestionList to question.json

  • Save MetricList to metric.json

  • Save Transcripts of individual interviewees to separate json files in /transcript

    • for example an interviewee with id = 1 has his/her transcript saved to transcript/1.json

3.6. Common classes

Classes used by multiple components are in the hirelah.commons package.

4. Implementation

This section describes some noteworthy details on how certain features are implemented.

4.1. Session Feature

HireLah! differs from AddressBook significantly in that a single user will likely have many sessions, as compared to just owning a single address book. The app thus provides means of managing multiple sessions from within the app itself, instead of having to change preferences.json to create a new session or switch between sessions.

4.1.1. Proposed Implementation

Having multiple sessions and changing between them from within the app means that HireLah! cannot load data from storage on app startup.

Instead, when the app starts, the ModelManager does not have its components (IntervieweeList, AttributeList, etc.) loaded, only UserPrefs, and the AppPhase is set to PRE_SESSION.

UI displays the SessionPanel which shows the available sessions in the "sessionsDirectory" folder.

In PRE_SESSION phase, logic uses the PreSessionParser which accepts commands to open an existing session or create a new one.

Once a session is chosen, the command calls Storage#loadSession which creates new Storage components for the new session (IntervieweeStorage, AttributeStorage etc.) that save to the correct session directory. loadSession then calls Storage#initModelManager, which loads new Model components (IntervieweeList, AttributeList etc.), then replaces the current ModelManager components. AppPhase is then set to NORMAL at which the app starts its usual behavior (adding interviewees etc.).

Finally after refreshing the ModelManager, then a new UI InterviewPanel is created that observes the new Model components. Since the Model’s components have been replaced (a different set of ObservableLists), the UI can only be created at this point else the UI would be data binding to the wrong lists.

The following activity diagram shows the sequence of initialization of components when a session is opened.

From the NORMAL phase, the close session command can be given, which simply un-sets the current session in Model and returns the AppPhase to PRE_SESSION. Thus the app is ready to open a new session, by resetting the storage components and the Model components, then creating a new UI InterviewPanel again.

4.1.2. Design Considerations

Aspect: How sessions are stored in the app

• Alternative 1 (current choice): Do not store information about sessions in Model. Directly read available sessions from the /data directory (or whatever the user set the "sessionsDirectory" to in preferences.json). Scan the directory again every time the SessionPanel is displayed.

  • Pros: Information about the available directories is always synchronized with the filesystem. It is possible to copy a session from somewhere else into the "sessionsDirectory" and the app will detect it.

  • Cons: Simplistic - app naively treats all directories in the "sessionsDirectory" directory as sessions and displays them as available sessions to the user. If a folder is created externally with invalid data, it will also be treated as a session, only failing when the user tries to load it.

• Alternative 2: Model contains a SessionList which tracks what sessions have been created or deleted.

  • Pros: User cannot create/delete sessions outside the app, changes to the sessions (new session/delete session) can be tracked within the app itself rather than repeatedly making IO calls to the filesystem.

  • Cons: There is no "single source of truth" as both the file system and the app have a list of sessions, and it is not straightforward to ensure both are synchronized, eg. if a session data directory is deleted on the file system, the app will not be aware of it.

Aspect: How session data is loaded and saved

• Alternative 1 (current choice): Load session only when a command is given to open a session from a directory.

  • Pros: Most user friendly, managing sessions is performed through the same CLI. Memory efficient - data is loaded only exactly when needed.

  • Cons: Complex to implement

• Alternative 2: Load all data for all sessions into memory when the app starts, open session merely selects the current session in focus and displays UI with current session data.

  • Pros: Straightforward to implement (All data can be loaded on app starting, need not change implementation from AddressBook). Switching between sessions is very straightforward.

  • Cons: Will be memory intensive as all data even from non-active sessions and past sessions will be loaded. As HireLah! may include large amounts of data in interview Transcripts, loading all the Transcripts from previous sessions will likely negatively impact startup timing. Furthermore, it is unlikely that an interviewer needs to access previous interview sessions data in a current interview, making a lot of the memory consumption wasteful.

  • Relevance consideration: It is not often that an interviewer would need to switch between sessions while interviewing for a specific thing, for example a role in the company.

• Alternative 3: Require the user to configure the session to load before app starts up, in preferences.json

  • Pros: Simplest to implement, yet memory efficient as only the relevant data is loaded

  • Cons: Not user friendly - functionality cannot be performed within the app. User cannot discover the functionality on how to start a new session without consulting the user guide.

4.2. Find Best Interviewees Feature

4.2.1. Description

When an interviewer wants to take a decision on hiring interviewees, it will be cumbersome for the interviewer to take a look of the interviewees' score, to take a decision, especially when it comes to a large scale hiring pool. Therefore, HireLah! provides a Find Best Interviewees feature to show the top interviewees, depending on how many employees the company need, and what kind of employees does the company desire.

4.2.2. Implementation

The Find Best Interviewee feature is facilitated by the BestCommand. It has the following fields:

• numberOfInterviewees: The number of interviewees that the interviewer wants to hire

• paramPrefix: The prefix of the parameter that wants to be used as a comparator between interviewees.

• paramType: The type of parameter that wants to be used by the interviewer. The possible values are the following: OVERALL, METRIC, and ATTRIBUTE.

Given below are several examples of usage scenarios when the user prompts for Best Interviewees:

Scenario 1. When the user provides a command with incomplete compulsory fields (e.g. number of interviewees), the BestCommandParser will throw ParseException, informing that the size provided is not an integer because the parser takes the preamble of the command to get the value for numberOfInterviewees.

Scenario 2. When the user provides a command with valid fields, yet there are no interviewees that has been interviewed, a CommandException is thrown instead, informing that there is no interviewee that has been interviewed, thus no result can be shown.

Scenario 3. When the user provides a command with multiple parameters that want to be used for a comparator, a ParseException is thrown instead, informing that the user has provided more than 1 parameter.

Here is the Full Sequence Diagram for FindBestCommand for an ideal case:

Getting the best interviewees from Model

To obtain the list of best interviewees, the BestCommand has a private method called getBest which takes in a model, a comparator, and size. The getBest method retrieves the best interviewees using an Iterator design pattern. It does the following:

• Retrieve intervieweeList and bestNIntervieweeList from model

• Clear the current bestNIntervieweeList

• Since the comparator only compares interviewees that have been interviewed, a filter operation needs to be done to filter out interviewees that have not been interviewed

• Sort the filtered interviewees based on the comparator

• Insert the first size interviewees to the bestNIntervieweeList

There are cases where getBest method does not reflect exactly the number of interviewees that the user entered:

• The number of interviewees that has been interviewed is less than the number of interviewees the user prompted. In this case, all the interviewed interviewees will be shown, in a sorted order based on their score. Therefore, the number of interviewees shown will be less than what the user entered.

• There are ties between interviewees at the cut-off position. For example, a case where the fifth interviewee, and the sixth interviewee have the same scores, while the user prompts for the best 5 interviewees. In this case, the sixth interviewee will also be shown. Therefore, the number of interviewees shown will be more than what the user entered.

Below is the activity diagram to summarize and show how getBest method works:

4.2.3. Design Considerations

Aspect: How to display the best interviewees

• Alternative 1 (current choice): Clears the current content of best interviewees, then add the best interviewees one by one.

  • Pros: Easy to implement.

  • Cons: Have a slightly lower execution time.

• Alternative 2: Creates a new ObservableList for the best interviewee list, then change the Model’s best interviewees list to point to this list, and the MainWindow’s BestIntervieweeListPanel.

  • Pros: Have a slightly faster theoretical execution time.

  • Cons: The implementation is slightly trickier compared to alternative 1 since it involves multiple components of the app.

4.3. Logging

We are using java.util.logging package for logging. The LogsCenter class is used to manage the logging levels and logging destinations.

• The logging level can be controlled using the logLevel setting in the configuration file (See Section 4.4, “Configuration”)

• The Logger for a class can be obtained using LogsCenter.getLogger(Class) which will log messages according to the specified logging level

• Currently log messages are output through: Console and to a .log file.

Logging Levels

• SEVERE : Critical problem detected which may possibly cause the termination of the application

• WARNING : Can continue, but with caution

• INFO : Information showing the noteworthy actions by the App

• FINE : Details that is not usually noteworthy but may be useful in debugging e.g. print the actual list instead of just its size

4.4. Configuration

Certain properties of the application can be controlled (e.g user prefs file location, logging level) through the configuration file (default: config.json).

5. Documentation

Refer to the guide here.

6. Testing

Refer to the guide here.

7. Dev Ops

Refer to the guide here.

Appendix A: Product Scope

Target user profile:

• an interviewer, or anyone who needs to conduct interviews

• has a need to manage and a large number of interviewees, their resumes and interview transcripts in an organized manner.

• prefer desktop apps over other types

• can type fast

• prefers typing over mouse input

• is reasonably comfortable using CLI apps

Value proposition: manage contacts faster than a typical mouse/GUI driven app

Appendix B: 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 Interviewer	See usage instructions	Learn to use HireLah!
* * *	Interviewer	Create a new interview session	Initialise the interviewee, their details, attributes and questions specific to this interview session.
* * *	Interviewer	Add a new interviewee to an interview session	Keep track of interviewees applying for a job opening
* * *	Forgetful Interviewer	View the list of interviewees and their interview status	Remember their names and interview those who have not been interviewed
* * *	Interviewer	Delete an interviewee from an interview session	Remove interviewees who withdrew their job application
* *	Interviewer	Update the information of interviewees	Ensure that I have the most up to date information about the interviewees
* *	Interviewer	Add the interviewees' resumes in the app	Not need to manage the resumes externally, possibly missing out on some interviewees and making it more difficult to access
* * *	Interviewer	Make a list of attributes	Remind myself of what to look out for in the interviewees while interviewing them
* * *	Interviewer	Modify the list of attributes	Update the interview session’s rubrics as needed
* * *	Interviewer	Make a list of questions to ask	Ask each interviewee the same set of questions
* * *	Fickle minded Interviewer	Modify the list of questions	Make necessary changes if I decide I want to ask different questions.
* *	Busy Interviewer	Have an easy way to refer to each interviewee	Do not have to remember the full name / ID of each interviewee
* * *	Interviewer	Finalise the attributes and questions for an interview session	Assess all interviewees fairly based on the same attributes and asked the same questions
* * *	Interviewer	See the list of attributes and questions during an interview	Refer back to the list of attributes and questions and assess all interviewees according to these exact parameters.
* * *	Interviewer	Record the remarks of my interviewees during the interview session	Recall details that happened during the interview
* * *	Interviewer	Indicate when a question was asked during the interview	Assess and review the interviewee’s answers to a particular question
* * *	Interviewer	Score the interviewee for each attribute during the interview	Have some basis to compare interviewees later.
*	Interviewer	Have an audio recording for every interview session	Refer back to it to minimize missing details
* * *	Interviewer	Open the interview transcript of an interviewee after interviewing him/her	Recall my impressions of the interviewee when making decisions on who to select.
* *	Interviewer	Easily find the remarks I made at some time during the interview	Not need to slowly scroll through the entire transcript.
* * *	Interviewer	Jump to the point where each question was asked	Focus on the important parts of the interview.
* * *	Interviewer	Find the best few interviewees based on their scores for the attributes	Narrow down the selection when making the decision.
* * *	Interviewer	Find the best few interviewees based on an attribute	Narrow down the selection when making the decision.
* * *	Interviewer	Find the best few interviewees based on a custom metric	Value certain attributes over others and give the most weightage to the most critical characteristics.
*	Interviewer	Play audio of a recording of an interviewee’s interview session at a given time	Recall what the interviewee said.
*	Interviewer	Visualise the score of attributes of all interviewees	To make easy visual comparisons.
* *	Interviewer	Export the full report of each interviewee	Share the information with others.
* *	Interviewer	App to be password protected	Protect sensitive information from prying eyes
* *	Experienced Interviewer	Perform all tasks from the keyboard	Not waste time moving between the cursor and the keyboard, especially while taking notes.

Appendix C: Use Cases

(For all use cases below, the System is the HireLah! and the Actor is the User, unless specified otherwise)

Use case: UC01 - Create new Session

MSS

1. User chooses to create a new Interview Session

2. User provides a name for the Session (eg. CEO Interview)

3. HireLah! creates the new Session and saves it

4. HireLah! automatically opens the Session (UC02)

   Use case ends.

Extensions

• 2a. User provides an invalid name or an existing session name.

  • 2a1. HireLah! shows an error message.

    Use case resumes at step 1.

Use case: UC02 - Open existing Session

MSS

1. User chooses to open a previous Interview Session

2. User provides the name of previous session (eg. CEO Interview)

3. HireLah! restores data from the session from memory

   Use case ends.

Extensions

• 2a. No such previous session exists.

  • 2a1. HireLah! shows an error message.

    Use case resumes at step 2.

Use case: UC03 - Delete session

MSS

1. User chooses to delete a session.

2. User provides the name of the session to delete.

3. HireLah! deletes all the session data of the given session. Use case ends.

Extensions

• 2a. No such previous session exists.

  • 2a1. HireLah! shows an error message.

    Use case resumes at step 2.

Use case: UC04 - Add Interviewee

Precondition

1. User has opened a session (UC02)

MSS

1. User chooses to create a new Interviewee.

2. User provides a name, and an alias (optional) for the Interviewee.

3. HireLah! creates the new Interviewee and saves it.

   Use case ends.

Extensions

• 2a. An interviewee with the exact name already exists

  • 2a1. HireLah! shows an error message.

    Use case resumes at step 2.

• 2b. The alias given already refers to another interviewee (either the name or alias)

  • 2b1. HireLah! creates the new Interviewee without the alias.

  • 2b2. HireLah! displays an error message regarding the repeated alias.

    Use case ends.

Use case: UC05 - Delete Interviewee

Precondition

1. User has opened a session (UC02)

MSS

1. User decides which Interviewee that wants to be deleted from the list.

2. User provides either the full name, the alias, or the ID.

3. HireLah! deletes the interviewee with the following details provided.

   Use case ends.

Extensions

• 2a. There is no interviewee with the given identifier.

  • 2a1. HireLah! shows an error message.

    Use case resumes at step 2.

Use case: UC06 - Update Interviewee

Precondition

1. User has opened a session (UC02)

MSS

1. User chooses to edit an interviewee.

2. User provides either the full name, the alias, or the ID.

3. User provides the updated fields, either name, alias or both.

4. HireLah! updates the interviewee information.

   Use case ends.

Extensions

• 2a. There is no interviewee with the given identifier.

  • 2a1. HireLah! shows an error message.

    Use case resumes at step 2.

• 3a. Either the given new name or alias is invalid (a duplicate, or an illegal value)

  • 3a1. HireLah! shows an error message.

    Use case resumes at step 2.

Use case: UC07 - Add Attribute

Precondition

1. User has opened a session (UC02)

2. User has not finalised the session attributes and questions (UC15)

MSS

1. User chooses a name for the attribute.

2. HireLah! adds the attribute with a given name to the list.

   Use case ends.

Extensions

• 2a. There is already an attribute with the identical name

  • 2a1. HireLah! shows an error message.

    Use case resumes at step 1.

Use case: UC08 - Delete Attribute

Precondition

1. User has opened a session (UC02)

2. User has not finalised the session attributes and questions (UC15)

MSS

1. User indicates which attribute to delete, either by full name or by a unique prefix.

2. HireLah! removes the attribute with the given prefix from the list.

   Use case ends.

Extensions

• 2a. There is no attribute with the given prefix.

  • 2a1. HireLah! shows an error message.

    Use case resumes at step 1.

• 2b. There are multiple attributes with the same given prefix.

  • 2b1. HireLah! shows an error message.

    Use case resumes at step 1.

Use case: UC09 - Update Attribute

Precondition

1. User has opened a session (UC02)

2. User has not finalised the session attributes and questions (UC15)

MSS

1. User indicates the attribute to edit, either by its full name or by a unique prefix.

2. User gives the updated name of the attribute.

3. HireLah! updates the attribute with the given name.

   Use case ends.

Extensions

• 1a. There is no attribute with the given prefix.

  • 1a1. HireLah! shows an error message.

    Use case resumes at step 1.

• 1b. There are multiple attributes with the same given prefix.

  • 1b1. HireLah! shows an error message.

    Use case resumes at step 1.

• 2a. The updated attribute name already exists.

  • 2a1. HireLah! shows an error message.

    Use case resumes at step 1.

Use case: UC10 - Add Question

Precondition

1. User has opened a session (UC02)

2. User has not finalised the session attributes and questions (UC15)

MSS

1. User chooses to add a question and types out the full question.

2. HireLah! adds the question with the given to the list.

   Use case ends.

Extensions

• 1a. There is already a question with the identical description.

  • 1a1. HireLah! shows an error message.

    Use case resumes at step 1.

Use case: UC11 - Delete Question

Precondition

1. User has opened a session (UC02)

2. User has not finalised the session attributes and questions (UC15)

MSS

1. User enters the index of the question that the user wants deleted.

2. HireLah! removes the question with the given index from the list.

   Use case ends.

Extensions

• 1a. The index given is not within the valid range.

  • 1a1. HireLah! shows an error message.

    Use case resumes at step 1.

Use case: UC12 - Update Question

Precondition

1. User has opened a session (UC02)

2. User has not finalised the session attributes and questions (UC15)

MSS

1. User enters an index of the question and the updated question.

2. HireLah! updates the description of the question with the given index.

   Use case ends.

Extensions

• 1a. The index given is not within the valid range.

  • 1a1. HireLah! shows an error message.

    Use case resumes at step 1.

Use caseL UC13 - Upload Interviewee Resume

Precondition

1. User has opened a session (UC02)

MSS

1. User chooses to upload the resume of the interviewee the user specifies.

2. User provides the path to the resume file.

3. HireLah! remembers this path.

   Use case ends.

Extensions

• 1a. HireLah! cannot find the user specified whether by id, alias or full name.

  • 1a1. HireLah! displays an error message.

    Use case resumes at step 1.

• 2a. The file specified by the path does not exist.

  • 2a1. HireLah! displays an error message.

    Use case resumes at step 1.

• 2b. No file is specified.

  • 2b1. HireLah! shows the User files to choose from.

  • 2b2. User chooses a file.

    If User cancels the file choosing dialog, HireLah! displays an error message. Else Use case resumes at step 3.

Use caseL UC14 - Open Interviewee Resume

Precondition

1. User has opened a session (UC02)

MSS

1. User chooses to open the resume of a specified interviewee.

2. HireLah! opens the resume.

   Use case ends.

Extensions

• 1a. The identifier provided is not the id, alias or full name of any interviewee.

  • 1a1. HireLah! displays an error message.

    Use case resumes at step 1.

• 1b. The identified interviewee does not have a resume uploaded (UC13)

  • 1b1. HireLah! displays an error message.

    Use case resumes at step 1.

Use case: UC15 - Finalize Questions and Attributes

Precondition

1. User has opened a session

Guarantees

1. Attribute list and Question list cannot be changed after finalizing

MSS

1. User chooses to finalize the current list of questions and attributes Use case ends

Use case: UC16 - Interview an Interviewee

Precondition

1. User has finalized questions and attributes for the session (UC15).

MSS

1. User gives name or alias or id of Interviewee to interview

2. HireLah! displays the interview questions

3. User writes remarks while conducting the interview

4. HireLah! saves the remark and the time during the interview when the remark was made

5. User records answers to the interview questions (UC17)

6. User scores interviewee on each attribute (UC18)

7. User chooses to end the interview

   Use case ends.

Extensions

• 1a. Name, alias or id does not refer to any interviewee.

  • 1a1. HireLah! shows an error message.

    Use case resumes at step 1.

• 1b. Interviewee specified has already been interviewed.

  • 1b1. HireLah! shows an error message.

    Use case ends.

• 7a. User has not scored the interviewee in all attributes

  • 7a1. HireLah! shows an error message.

    Use case resumes from step 6.

Use case: UC17 - Record Question Answer

Precondition

1. User is interviewing an interviewee (UC16).

MSS

1. User indicates question to record answers for

2. User takes notes of the answer to the question

3. HireLah! saves the remark and the time during the interview when the remark was made

   Use case ends.

Extensions

• 1a. Question number is invalid (too large, or less than 1)

  • 1a1. HireLah! shows an error message.

    Use case ends.

Use case: UC18 - Score Interviewee

Precondition

1. User is interviewing an interviewee (UC16).

MSS

1. User indicates attribute to score

2. User indicates score to give

3. HireLah! overwrites any previous score given with the new score

   Use case ends.

Extensions

• 1a. Attribute does not exist.

  • 1a1. HireLah! shows an error message.

    Use case ends.

• 2a. Score given is not a number

  • 2a1. HireLah! shows an error message.

    Use case resumes from step 1.

• 2b. Score given is out of the range of allowed values (0-10).

  • 2b1. HireLah! shows an error message.

    Use case resumes from step 1.

Use case: UC19 - Working with an Interviewee Report

Precondition

1. User has stopped an interview session(UC16) with any interviewee.

MSS

1. User chooses the interviewee that wants to be examined.

2. User opens the interviewee transcript, containing the remarks that are added during the interview.

3. User may navigate by questions and time (UC20) to view their remarks for those questions or at that time.

4. User closes the interviewee report when he/she is done.

   Use case ends.

Extensions

• 1a. User has not started an interview (UC16) with this interviewee.

  • 1a1. HireLah! shows an error message.

    Use case ends.

• 1b. There is no interviewee with a given details (alias, ID, or fullname).

  • 1b1. HireLah! shows an error message.

    Use case resumes from step 1.

Use case: UC20 - Navigating through the Interview report

Precondition

1. User is viewing an interview report (UC19).

MSS

1. User provides the time or question number for which he/she wishes to see the remarks made during that period of the interview

2. HireLah! scrolls the interview report to the remark made at the moment specified.

   Use case ends.

Extensions

• 1a. Time provided is too large (beyond the end time)

  • 1a1. HireLah! scrolls to the end of the interview.

    Use case ends.

• 1b. Question number provided does not correspond to a question that was answered.

  • 1b1. HireLah! shows an error message.

    Use case ends.

C.1. Use case: UC21 - Choose Best Interviewees

Precondition

1. User has interviewed at least 1 interviewee (UC16).

MSS

1. User indicates the metric (average, best by single attribute, or user-defined weightage) to sort interviewees by

2. User indicates the number of top interviewees to show

3. HireLah! displays the sorted and filtered list of top candidates

   Use case ends.

Extensions

• 1a. The indicated metric does not exist

  • 1a1. HireLah! shows an error message.

    Use case resumes from step 1.

• 2a. The indicated number of interviewees to show is larger than the number of interviewees

  • 2a1. HireLah! sorts and displays all interviewed interviewees in sorted order.

    Use case ends.

• 3a. There are ties amongst the interviewees.

  • 3a1. HireLah! includes all ties, even if it exceeds the number specified in step 2.

    Use case ends.

Use case: UC22 - Add Metric

Precondition

1. User has finalized questions and attributes for the session (UC15).

MSS

1. User chooses the name of the metric and the weight of each attribute

2. HireLah! adds the metric to the list.

   Use case ends.

Extensions

• 1a. Any attribute specified is not in the attribute list.

  • 1a1. HireLah! shows an error message.

    Use case resumes from step 1.

• 1b. Any weight provided is an invalid number.

  • 1b1. HireLah! shows an error message.

    Use case resumes from step 1.

• 1c. The name specified is already used for another metric.

  • 1c1. HireLah! shows an error message.

    Use case resumes from step 1.

Use case: UC23 - Delete Metric

Preconditions

1. User has finalized questions and attributes for the session (UC15).

MSS

1. User indicates the metric to delete by its name, or a unique prefix.

2. HireLah! deletes the metric with the given prefix.

   Use case ends.

Extensions

• 1a. There is no metric with the given prefix

  • 1a1. HireLah! shows an error message.

    Use case ends.

• 1b. There are multiple metrics with the given prefix

  • 1b1. HireLah! shows an error message.

    Use case ends.

Use case: UC23 - Update Metric

MSS

1. User indicates the metric to edit by its name or a unique prefix.

2. User provides a new name, or an updated list of weights for attributes.

3. HireLah! updates the metric with the new name and/or the new weights.

   Use case ends.

Extensions

• 1a. There is no metric with the given prefix

  • 1a1. HireLah! shows an error message.

    Use case ends.

• 1b. There are multiple metrics with the given prefix

  • 1b1. HireLah! shows an error message.

    Use case ends.

• 2a. The new name is invalid (uses illegal characters or is a duplicate)

  • 2a1. HireLah! shows an error message.

    Use case ends.

• 2b. Any attribute specified cannot be found or the weight is not a valid number.

  • 2b1. HireLah! shows an error message.

    Use case ends.

Appendix D: Non Functional Requirements

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 interviewees without a noticeable sluggishness in performance for typical usage.

3. Each command should be intuitively named so the interviewer can get productive with the app without constantly referencing the User Guide.

4. The application should be easy to use even for interviewers who have never used command-line programs before.

5. The UI design of the application should be intuitive to interviewers to navigate between the different phases of the application.

6. The application should not be larger than 100Mb.

7. The application should save data after every command and not require interviews to save it manually.

8. The application not cause interviewers to lose all their progress if the app crashes in the middle of an interview. The user should be able to continue the interview where they left off after restarting the app.

9. Our code should allow other developers to add new features in the application easily.

Appendix E: Glossary

Mainstream OS

Windows, Linux, Unix, OS-X

Private contact detail

A contact detail that is not meant to be shared with others

Appendix F: Product Survey

Product Name

Author: …​

Pros:

• …​

• …​

Cons:

• …​

• …​

Appendix G: Instructions for Manual Testing

Given below are instructions to test the app manually.

ℹ️	These instructions only provide a starting point for testers to work on; testers are expected to do more exploratory testing.

G.1. Launch and Shutdown

1. Initial launch

   1. Download the jar file and copy into an empty folder

   2. Double-click the jar file
      Expected: Shows the GUI with a set of sample contacts. The window size may not be optimum.

2. Saving window preferences

   1. Resize the window to an optimum size. Move the window to a different location. Close the window.

   2. Re-launch the app by double-clicking the jar file.
      Expected: The most recent window size and location is retained.

{ more test cases …​ }

G.2. Deleting a person

1. Deleting a person while all persons are listed

   1. Prerequisites: List all persons using the list command. Multiple persons in the list.

   2. Test case: delete 1
      Expected: First contact is deleted from the list. Details of the deleted contact shown in the status message. Timestamp in the status bar is updated.

   3. Test case: delete 0
      Expected: No person is deleted. Error details shown in the status message. Status bar remains the same.

   4. Other incorrect delete commands to try: delete, delete x (where x is larger than the list size) {give more}
      Expected: Similar to previous.

{ more test cases …​ }

G.3. Saving data

1. Dealing with missing/corrupted data files

   1. {explain how to simulate a missing/corrupted file and the expected behavior}

{ more test cases …​ }