- Conceptualize v1.0
- Draft the UG midnight before the tutorial
1 Conceptualize v1.0
- Based on your user stories selected previously, conceptualize the product in terms of how it will look like at v1.0 in the form of a feature list.
Note down the feature list in your online project notes document.
FAQ: How many features should we put in v1.0?
A: Aim for the smallest set of features the product cannot do without. Even a most basic version of those features is enough. After completing that feature set, you can add more if there is time left.
2 Draft the UG midnight before the tutorial
This task is time-sensitive. If done later than the deadline, it will not be counted as 'done' (i.e., no grace period). Reason: This is 'an early draft'; if done late, it can't count as 'early'.
- Draft a user guide in a convenient medium (e.g., a GoogleDoc) to describe what the product would be like when it is at v1.0.
- We recommend that you follow the AB3 User Guide in terms of structure and format.
- As this is a draft only and the final version will be in a different format altogether (i.e., in Markdown format), don't waste time in formatting, copy editing etc. You can also limit this to just the 'Features' section only and omit the other sections.
While the UG draft need not be 'polished', it should be detailed enough to tell the user how to use the product features in concern. - IMPORTANT:
- Specify the precise/full command syntax for the CLI commands that you will deliver at v1.0. i.e., we want you to know exactly what you plan to deliver at v1.0 -- while it is fine to change this plan later, it is still important to have a plan first.
- Include all features that will be available in v1.0. There is no need to include features that will be delivered beyond v1.0.
- Consider including examples of expected outputs too.
- Submission [one person per team]: Save the draft UG as a PDF file, name it
{team-id}.pdfe.g.,CS2113-T09-2.pdf, and upload to Canvas.
Recommended: Divide among team members equally; preferably based on enhancements/features each person would be adding e.g., If you are the person planing to add a feature X, you should be the person to describe the feature X in the User Guide and in the Developer Guide.
Reason: In the final project evaluation your documentation skills will be graded based on sections of the User/Developer Guide you have written.
If you are not sure what we mean by 'enhancements/features each person would be adding' mentioned above, see the panel below for our recommendation on how to divide the tP work: