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 |
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.
A-JUnit: JUnit Testing Add JUnit tests to test the behavior of the code.
Notes:
[project root]\src\test\java\ folder (reason: to follow the convention followed by the project structure so far).Todo.java can be tested by TodoTest.java), and put it in a package to match. For example,
seedu.duke.Todo: src\main\java\seedu\duke\Todo.javaseedu.duke.TodoTest: src\test\java\seedu\duke\TodoTest.javaAdding JUnit support to your project: As JUnit is a third-party library, you need to add support to it specifically in your project.
[project root]\src\test\java\ (you may have to do this outside of Intellij)File → New → Module From Existing Sources ...[project root]\src\test\ (not the java) folder.Create module from existing sourcesNext until the process is completeProject 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).java folder and type @Test inside it. Example:
public class DukeTest {
@Test
}
@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.Sources, JavaDocs and Annotations boxes. After that, click OK to add the JUnit 5 to the project dependencies.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 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.
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.
Relevant: [
Please follow the organization/repo name format precisely because we use scripts to download your code or else our scripts will not be able to detect your work.
After receiving your team ID, one team member should do the following steps:
SEMESTER-TEAM_ID. e.g. AY1920S1-CS2113T-W12-2 or AY1920S1-CS2113-T13-1developers to your organization.
Relevant: [
Only one team member:
main. This repo (let's call it the team repo) is to be used as the repo for your project.master branch to [nuscs2113-AY1920S1/PersonalAssistant-Duke] master branch. PR name: [Team ID] Product Name e.g., [AY1920S1-CS2113-T13-1] Contact List Pro. As you merge code to your team repo's master branch, this PR will auto-update to reflect how much your team's product has progressed. In the PR description All team members:
main repo (created above) i.e., go to the repo and click on the watch button to subscribe to activities of the repomain repo to your personal GitHub account.Note that some of our download scripts depend on the following folder paths. Please set up the these paths in your project carefully.
/src/main/src/test/docs
Relevant: [
We recommend you configure the issue tracker of the main repo as follows:
Issue type labels:
type.Epic : A big feature which can be broken down into smaller stories e.g. searchtype.Story : A user storytype.Enhancement: An enhancement to an existing storytype.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 bugStatus labels:
status.Ongoing : The issue is currently being worked on. note: remove this label before closing an issue.
Priority labels:
priority.High : Must dopriority.Medium : Nice to havepriority.Low : Unlikely to doBug 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
v1.0.Step 0 : Identify the target user profile and the problem you are solving for the target users
Decide on the project direction (e.g., enhance or morph?)
Document these details in the introduction section of your developer guide.
Step 1 : Brainstorm user stories
This is a good time to analyze requirements with a view to conceptualizing the next version of the product (i.e. v2.0).
Get together with your team members and
It is ok to have more user stories than you can deliver in the project. Aim to create at least 30 user stories. Include all 'obvious' ones you can think of but also look for 'non obvious' ones that you think are likely to be missed by other teams.
Refer
You can write each user story in a piece of paper (e.g. yellow sticky note, index card, or just pieces of paper about the size of a playing card). Alternatively you can use an online tool (some examples given in
Note that you should not 'evaluate' the value of user stories while doing the above. Reason: an important aspect of brainstorming is not judging the ideas generated.
Requirements → Gathering Requirements →
Brainstorming: A group activity designed to generate a large number of diverse and creative ideas for the solution of a problem.
In a brainstorming session there are no "bad" ideas. The aim is to generate ideas; not to validate them. Brainstorming encourages you to "think outside the box" and put "crazy" ideas on the table without fear of rejection.
What is the key characteristic about brainstorming?
(b)
Requirements → Specifying Requirements → User Stories →
User story: User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. [Mike Cohn]
A common format for writing user stories is:
User story format: As a {user type/role} I can {function} so that {benefit}
Examples (from a Learning Management System):
We can write user stories on index cards or sticky notes, and arrange on walls or tables, to facilitate planning and discussion. Alternatively, we can use a software (e.g., GitHub Project Boards, Trello, Google Docs, ...) to manage user stories digitally.
[credit: https://www.flickr.com/photos/jakuza/with/2726048607/]
[credit: https://commons.wikimedia.org/wiki/File:User_Story_Map_in_Action.png]
Critique the following user story taken from a software project to build an e-commerce website.
As a developer, I want to use Python to implement the software, so that we can resue existing Python modules.
Refer to the definition of a user story.
User story: User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. [Mike Cohn]
This user story is not written from the perspective of the user/customer.
Bill wants you to build a Human Resource Management (HRM) system. He mentions that the system will help employees to view their own
Remember to follow the correct format when writing user stories.
User story format: As a {user type/role} I can {function} so that {benefit}
As an employee, I can view my leave balance, so that I can know how many leave days I have left.
Note: the {benefit} part may vary as it is not specifically mentioned in the question.
You can create issues for each of the user stories and use a GitHub Project Board to sort them into categories.
Example Project Board:
Example Issue to represent a user story:
A video on GitHub Project Boards:
Example Google Sheet for recording user stories:
Example Trello Board for recording user stories:
Given their lightweight nature, user stories are quite handy for recording requirements during early stages of requirements gathering.
Here are some tips for using user stories for early stages of requirement gathering:
As a user, I want to see a list of tasks that needs my attention most at the present time, so that I pay attention to them first.Step 2: Prioritize the user stories
Suggested workflow:
Take one user story at a time and get team member opinions about it.
Based on the team consensus, put the story (i.e. the piece of paper) onto one of these three piles:
Must-Have : The product will be practically useless to the target user without this feature.Nice-To-Have : The target user can benefit from this user story significantly but you are not certain if you'll have time to implement it.Not-Useful : No significant benefit to the target user, or does not fit into the product vision.If using physical paper to record user stories: After all stories have been put in the above three piles, you can make a record of which stories are in the three piles.
Step 3: Document requirements of the product
Based on your user story categorization in the step above, given module requirements/constraints for the project, and the current state of the product, select which user stories you are likely to include in v2.0.
Document the following items using a convenient format (e.g., a GoogleDoc).
Requirements → Specifying Requirements → Use Cases →
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: 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.
Unified Modeling Language (UML) is a graphical notation to describe various aspects of a software system. UML is the brainchild of three software modeling specialists James Rumbaugh, Grady Booch and Ivar Jacobson (also known as the Three Amigos). Each of them has developed their own notation for modeling software systems before joining force to create a unified modeling language (hence, the term ‘Unified’ in UML). UML is currently the de facto modeling notation used in the software industry.
Use cases capture the functional requirements of a system.
Requirements → Requirements →
Requirements can be divided into two in the following way:
Some examples of non-functional requirement categories:
We may have to spend an extra effort in digging NFRs out as early as possible because,
Given below are some requirements of TEAMMATES (an online peer evaluation system for education). Which one of these are non-functional requirements?
(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.
Requirements → Specifying Requirements → Glossary →
Glossary: A glossary serves to ensure that all stakeholders have a common understanding of the noteworthy terms, abbreviation, acronyms etc.
Here is a partial glossary from a variant of the Snakes and Ladders game:
Requirements → Gathering Requirements →
Studying existing products can unearth shortcomings of existing solutions that can be addressed by a new product. Product manuals and other forms of documentation of an existing system can tell us how the existing solutions work.
When developing a game for a mobile device, a look at a similar PC game can give insight into the kind of features and interactions the mobile game can offer.