Achieve some team tasks in Phase 1. Decide on a overall project direction. Document the requirements of Phase 2.

Here is a summary of items you need to deliver to reach v1.0 individual () and team () milestones. See sections below for more details of each item.

Milestone	Minimum acceptable performance to consider as 'reached'
Complete the Duke increments specified	Tag and push the commits to your own fork as per the instructions
Complete the team tasks as specified, including the Duke increments	Tag the relevant commit and push to your team fork
Decide on a overall project direction	Document the user profile, problem addressed, societal impact, optimize or morph in the developer guide (Introduction)
Decide on requirements of Phase 2	Document the user stories, use cases, non-functional requirements in the developer guide (as Appendix A)
[optional] Product survey documented	none

Duke tasks ( individual)

Implement the following increments while committing code incrementally

Try to use a branch-frequent-merge-frequent (i.e., Create a branch for each increment and merge to your master after the completing the task.) approach while implementing these increments. Reason: to learn effective use of branches in the development cycle.
As earlier, push these changes to your own fork of Duke.

Write some unit tests using Junit
- Note that you are still not required to incorporate Gradle in your work

A-JUnit: JUnit Testing

A-JUnit

↳ Add JUnit tests

Add JUnit tests to test the behavior of the code.

Notes:

Add test code in a folder named [project root]\src\test\java\ folder (reason: to follow the convention followed by the project structure so far).
Name the test class to match the class being tested (Todo.java can be tested by TodoTest.java), and put it in a package to match. For example,
- Class being tested seedu.duke.Todo: src\main\java\seedu\duke\Todo.java
- Test class seedu.duke.TodoTest: src\test\java\seedu\duke\TodoTest.java

Adding JUnit support to your project: As JUnit is a third-party library, you need to add support to it specifically in your project.

Add a folder named [project root]\src\test\java\ (you may have to do this outside of Intellij)
Go to Intellij and add a new module to the project as follows.
1. File → New → Module From Existing Sources ...
2. Choose the [project root]\src\test\ (not the java) folder.
3. In the next screen, select Create module from existing sources
4. Keep clicking Next until the process is complete
In the Project panel of Intellij, expand the newly-created test module, right-click on the java folder inside it, and choose Mark Directory as → Test Source Root (that will make the folder turn to green color).
Now, create a class inside the java folder and type @Test inside it. Example:
```
public class DukeTest {
    @Test
}
```
Note how the @Test turn to red because Intellij (not having JUnit support yet) does not understand it. But it will pop up a hint, asking if you want to add support for JUnit. Select Add JUnit 5.* to classpath.
In the dialog that pops up, you can optionally tick the Sources, JavaDocs and Annotations boxes. After that, click OK to add the JUnit 5 to the project dependencies.

To check if JUnit integration is working as expected,

Add a dummy test method to the class e.g.,

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.assertEquals;

public class DukeTest {
    @Test
    public void dummyTest(){
        assertEquals(2, 2);
    }
}

Run the test (right-click on the class and choose Run DukeTest.

Refer to the Gradle tutorial at the Duke repo (i.e., the repo you forked from) to find how to use JUnit via Gradle.

A-Gradle

↳ Automate project builds using Gradle

Use Gradle to automate some of the build tasks of the project. Refer to the Gradle tutorial at the Duke repo (i.e., the repo you forked from) to find how to set up Gradle for your project.

Minimal: Learn how to use Gradle when it is already set up.
Recommended: Learn how to tweak the Gradle gradle set up of for a project.
Stretch Goal: Learn how to set up Gradle for a project.

Document your code appropriately

A-JavaDoc: JavaDoc

A-JavaDoc

↳ Add JavaDoc comments

Add JavaDoc comments to the code.

Duke tasks ( team)

Project Setup

Create your team organization.

Relevant: [Admin Appendix E(extract): Organization setup ]

Set up the team repo

Relevant: [Admin Appendix E(extract): Repo setup ]

Setup the issue tracker in the team repo

Relevant: [Admin Appendix E(extract): Issue tracker setup ]

Issue tracker setup

We recommend you configure the issue tracker of the main repo as follows:

Delete existing labels and add the following labels.
💡 Issue type labels are useful from the beginning of the project. The other labels are needed only when you start implementing the features.

Issue type labels:

type.Epic : A big feature which can be broken down into smaller stories e.g. search
type.Story : A user story
type.Enhancement: An enhancement to an existing story
type.Task : Something that needs to be done, but not a story, bug, or an epic. e.g. Move testing code into a new folder)
type.Bug : A bug

Status labels:

status.Ongoing : The issue is currently being worked on. note: remove this label before closing an issue.

Priority labels:

priority.High : Must do
priority.Medium : Nice to have
priority.Low : Unlikely to do

Bug Severity labels:

severity.Low : A flaw that is unlikely to affect normal operations of the product. Appears only in very rare situations and causes a minor inconvenience only.
severity.Medium : A flaw that causes occasional inconvenience to some users but they can continue to use the product.
severity.High : A flaw that affects most users and causes major problems for users. i.e., makes the product almost unusable for most users.

Create following milestones : v1.0, v1.1, v1.2, v1.3, v1.4,
You may configure other project settings as you wish. e.g. more labels, more milestones

Port the phase 1 code to your team repo

Now carefully port the phase 1 code to the team repo you setup above.
(Caution!) This can be messy.
- You are allowed to decide and choose which team member's code goes into the team repo. There can be various combinations.
  - E.g., Codebase for different purposes (interaction, storage to file, logic, etc.,) can belong to different team members.
  - E.g., Entire codebase from Phase 1 can belong to just one or two team members.
- However, the decision on whose code is used should be made collectively within the team, the teaching team will not intervene.
- In the interest of the team, you can choose the best code to be the starter codebase.
- Note: You will be graded individually for your Phase 1 of the project, so irrespective of your code being used or not used as the base code for the team project, you will have received the due credit for your work. Conversely, since your work is evaluated in Phase 1, you will not receive any additional credits if your code is used as the base code for the team project.
Push the changes to the team repo.

## Implement the following increments in the team repo

Organize code better

A-Packages: Java Packages

A-Packages

↳ Divide classes into packages

Organize the classes into suitable java packages. e.g., duke.task, duke.command

After the above increment is completed, tag your codebase with v1.0.

Requirements → Specifying Requirements → Use Cases →

Introduction

Use Case: A description of a set of sequences of actions, including variants, that a system performs to yield an observable result of value to an actor.[ 📖 : uml-user-guideThe Unified Modeling Language User Guide, 2e, G Booch, J Rumbaugh, and I Jacobson ]

Actor: An actor (in a use case) is a role played by a user. An actor can be a human or another system. Actors are not part of the system; they reside outside the system.

A use case describes an interaction between the user and the system for a specific functionality of the system.

System: ATM
Actor: Customer
Use Case: Check account balance
1. User inserts an ATM card
2. ATM prompts for PIN
3. User enters PIN
4. ATM prompts for withdrawal amount
5. User enters the amount
6. ATM ejects the ATM card and issues cash
7. User collects the card and the cash.

System: A Learning Management System (LMS)
Actor: Student
Use Case: Upload file
1. Student requests to upload file
2. LMS requests for the file location
3. Student specifies the file location
4. LMS uploads the file

UML includes a diagram type called use case diagrams that can illustrate use cases of a system visually , providing a visual ‘table of contents’ of the use cases of a system. In the example below, note how use cases are shown as ovals and user roles relevant to each use case are shown as stick figures connected to the corresponding ovals.

Use cases capture the functional requirements of a system.

Requirements → Requirements →

Non-Functional Requirements

Requirements can be divided into two in the following way:

Functional requirements specify what the system should do.
Non-functional requirements specify the constraints under which system is developed and operated.

Some examples of non-functional requirement categories:

Data requirements e.g. size, volatility, persistency etc.,
Environment requirements e.g. technical environment in which system would operate or need to be compatible with.
Accessibility, Capacity, Compliance with regulations, Documentation, Disaster recovery, Efficiency, Extensibility, Fault tolerance, Interoperability, Maintainability, Privacy, Portability, Quality, Reliability, Response time, Robustness, Scalability, Security, Stability, Testability, and more ...

Business/domain rules: e.g. the size of the minefield cannot be smaller than five.
Constraints: e.g. the system should be backward compatible with data produced by earlier versions of the system; system testers are available only during the last month of the project; the total project cost should not exceed $1.5 million.
Technical requirements: e.g. the system should work on both 32-bit and 64-bit environments.
Performance requirements: e.g. the system should respond within two seconds.
Quality requirements: e.g. the system should be usable by a novice who has never carried out an online purchase.
Process requirements: e.g. the project is expected to adhere to a schedule that delivers a feature set every one month.
Notes about project scope: e.g. the product is not required to handle the printing of reports.
Any other noteworthy points: e.g. the game should not use images deemed offensive to those injured in real mine clearing activities.

We may have to spend an extra effort in digging NFRs out as early as possible because,

NFRs are easier to miss e.g., stakeholders tend to think of functional requirements first
sometimes NFRs are critical to the success of the software. E.g. A web application that is too slow or that has low security is unlikely to succeed even if it has all the right functionality.

Given below are some requirements of TEAMMATES (an online peer evaluation system for education). Which one of these are non-functional requirements?

a. The response to any use action should become visible within 5 seconds.
b. The application admin should be able to view a log of user activities.
c. The source code should be open source.
d. A course should be able to have up to 2000 students.
e. As a student user, I can view details of my team members so that I can know who they are.
f. The user interface should be intuitive enough for users who are not IT-savvy.
g. The product is offered as a free online service.

(a)(c)(d)(f)(g)

Explanation: (b) are (e) are functions available for a specific user types. Therefore, they are functional requirements. (a), (c), (d), (f) and (g) are either constraints on functionality or constraints on how the project is done, both of which are considered non-functional requirements.

Project: v1.0 [week 5]

Duke tasks ( individual)

Implement the following increments while committing code incrementally

A-JUnit

A-Gradle

A-JavaDoc

Duke tasks ( team)

Project Setup

Create your team organization.

Set up the team repo

Setup the issue tracker in the team repo

Port the phase 1 code to your team repo

A-Packages

Project Phase 2

Project: v1.0 [week 5]

Duke tasks ( individual)

Implement the following increments while committing code incrementally

A-JUnit

A-Gradle

A-JavaDoc

Duke tasks ( team)

Project Setup

Create your team organization.

Organization setup

Set up the team repo

Repo setup

Setup the issue tracker in the team repo

Issue tracker setup

Port the phase 1 code to your team repo

A-Packages

Project Phase 2

Brainstorming

Introduction

Introduction

Non-Functional Requirements

What

Product Surveys