In general, each team is expected to take one of these two directions:

• [Direction 1] Optimize AddressBook for a more specific target user group:

  An AddressBook,

  • for users in a specific profession e.g. doctors, salesmen, teachers, etc.
  • based on the nature/scale of contacts e.g. huge number of contacts (for HR admins, user group admins), mostly incomplete contacts, highly volatile contact details, contacts become inactive after a specific period (e.g. contract employees)
  • based on what users do with the contacts e.g. organize group events, share info, do business, do analytics

• [Direction 2] Morph AddressBook into a different product: Given that AddressBook is a generic app that manages a type of elements (i.e. contacts), you can use it as a starting point to create an app that manages something else.

  An app to manage,

  • Bookmarks of websites
  • Tasks/Schedule
  • Location info
  • Thing to memorize i.e. flash cards, trivia
  • Forum posts, news feeds, Social media feeds
  • Online projects or issue trackers that the user is interested in
  • Emails, possibly from different accounts
  • Multiple types of related things e.g. Contacts and Tasks (if Tasks are allocated to Contacts)

Note that both directions are equally acceptable.

For either direction, you need to define a target user profile and a value proposition:

• Target user profile: Define a very specific target user profile.
  We require you to narrow down the target user profile as opposed to trying to make it as general as possible. Here is an example direction of narrowing down target user: anybody → teachers → university teachers → tech savvy university teachers → CS2103/T instructors.
  
  Be careful not to contradict given project constraints when defining the user profile e.g. the target user should still prefer typing over mouse actions.
  
  It is expected that your product will be optimized for the chosen target users i.e., add features that are especially/only applicable for target users (to make the app especially attractive to them). w.r.t. the example above, there can be features that are applicable to CS2103/T instructors only, such as the ability to navigate to a student's project on GitHub
  Your project will be graded based on how well the features match the target user profile and how well the features fit-together.

  • It is an opportunity to exercise your product design skills because optimizing the product to a very specific target user requires good product design skills.
  • It minimizes the overlap between features of different teams which can cause plagiarism issues. Furthermore, higher the number of other teams having the same features, less impressive your work becomes especially if others have done a better job of implementing that feature.
  
  
• Value proposition: Define a clear value proposition (what problem does the product solve? how does it make the the user's life easier?) that matches the target user profile.

[Individual] Expectations on Enhancements

• You are expected to enhance the product in some way(s). User-visible enhancements are preferred, but it is not a strict requirement. Some examples:

• The enhancement(s) should fit with the rest of the software (and the target user profile) and should have the consent of the team members. You will lose marks if you go 'rogue' and add things that don't fit with the product.

• How much code to write? The project grade depends on the value you added, as perceived by evaluators (i.e., team members, peer evaluators, and tutors) as well as other factors such as the quality of the code. As such, there is no strong correlation between the LoC and the grade. For instance, in a recent semester, a student who wrote 500 LoC of functional code (i.e., excluding test code and documentation) was able to reach top 20% (in terms of project marks), another who wrote 900 LoC reached the top 10%, while another who wrote more than 5000 LoC ended up in the bottom 10%. Also see the the percentiles of functional LoC written by that batch of students, given below:

  Percentile	25	50	75
  LoC	~1000	~1500	~2500

[Individual] Expectations on Documentation

• You are expected to write user documentation and developer documentation for your features.
• The objective is to showcase your ability to write the two types of documentation. If the documentation for your features is not enough to meet that objective, or does not reach the following minimal requirement, you can make up the shortfall by documenting 'proposed' features and alternative designs/implementations.
  • Contribution to the user guide: 1 page
  • Contribution to the developer guide: 3 pages
• You are expected to showcase your ability to use the various UML diagrams (at least 2 types). As mentioned in the previous point, if the documentation of your features doesn't give you enough opportunities to do so e.g., your features only required minor updates to existing diagrams, you are expected to create those opportunities yourself by documenting proposed features or alternative designs. Evaluators will not be able to give you marks unless there is sufficient evidence of your documentation skills.
• You are required to update the entire UG and DG to match your product. However, there is no need to update other documents such as tutorials that are AB3 specific.

[Individual] Expectations on Testing

[Individual] Expectations on Teamwork

Team-tasks are the tasks that someone in the team has to do. Marks allocated to team-tasks will be divided among team members based on how much each member contributed to those tasks.

Here is a non-exhaustive list of team-tasks:

1. Necessary general code enhancements e.g.,
   1. Work related to renaming the product
   2. Work related to changing the product icon
   3. Morphing the product into a different product
2. Setting up the GitHub, Travis, AppVeyor, etc.
3. Maintaining the issue tracker
4. Release management
5. Updating user/developer docs that are not specific to a feature e.g. documenting the target user profile
6. Incorporating more useful tools/libraries/frameworks into the product or the project workflow (e.g. automate more aspects of the project workflow using a GitHub plugin)

Roles indicate aspects you are in charge of and responsible for. E.g., if you are in charge of documentation, you are the person who should allocate which parts of the documentation is to be done by who, ensure the document is in right format, ensure consistency etc.

This is a non-exhaustive list; you may define additional roles.

• Team lead: Responsible for overall project coordination.
• Documentation (short for ‘in charge of documentation’): Responsible for the quality of various project documents.
• Testing: Ensures the testing of the project is done properly and on time.
• Code quality: Looks after code quality, ensures adherence to coding standards, etc.
• Deliverables and deadlines: Ensure project deliverables are done on time and in the right format.
• Integration: In charge of versioning of the code, maintaining the code repository, integrating various parts of the software to create a whole.
• Scheduling and tracking: In charge of defining, assigning, and tracking project tasks.
• [Tool ABC] expert: e.g. Intellij expert, Git expert, etc. Helps other team member with matters related to the specific tool.
• In charge of[Component XYZ]: e.g. In charge of Model, UI, Storage, etc. If you are in charge of a component, you are expected to know that component well, and review changes done to that component in v1.3-v1.4.

Please make sure each of the important roles are assigned to one person in the team. It is OK to have a 'backup' for each role, but for each aspect there should be one person who is unequivocally the person responsible for it.