- Conceptualize the MVP version
- Draft the feature specification Sun, Sep 22nd 23:59
- Set up the project repo
- Get familiar with the codebase
Intro to tP Week 6
Connecting the dots so far ...
Previously, we mentioned the following two project planning strategies:
Last week,
- to help with PS1, we collected potential user stories for the final product.
- to help with PS2, we selected a subset of those user stories for an MVP version of the product.
What's happening this week:
This week, we focus on two fronts:
- The first front (which aligns with PS2) moves towards defining a precise target for the first version (i.e., MVP): task 1 translates the selected user stories into a feature list and task 2 expands that feature lists to a more precise feature specification.
- On the other front, we prepare to start coding work. Tasks 3 (Set up the project repo), and 4 (Get familiar with the codebase) help with that.
Things to note:
- tP tasks progress is graded. Completing individual and team tasks are considered for grading the project management component of your project grade. That said, unless a deliverable is marked 'time-sensitive', there is no penalty for missing a deadline provided you catch up with most of them within a few days after the deadline.
- Most aspects of project progress are tracked using automated scripts. Please follow our instructions closely or else the script will not be able to detect your progress. There will be no partial credit for work that did not follow the instructions precisely, but in most cases you can get the work to be counted simply by rectifying the non-compliance.
1 Conceptualize the MVP version
- Task: Based on your user stories selected previously, conceptualize the MVP in the form of a feature list.
Why?: So far, we have user stories we want to include in the MVP version. But user stories simply tell us user needs. To move towards a product design, we need to design product features of the product can fulfill those user needs.
Submission: Note down the feature list in your online project notes document.
2 Draft the feature specification Sun, Sep 22nd 23:59
This task is time-sensitive. If done later than the deadline, it will not be counted as 'done' (i.e., no grace period).
Deadline: Recommended to finish by the regular weekly project deadline (i.e., before the next weekly briefing), but given the iP final submission is due this week, you may take until Sunday (Sun, Sep 22nd 2359) to submit this.
Why? In addition to helping towards PS2, this deliverable forces you to make some fine-grained product design decisions early, thus giving you a better idea about the complexities that lie ahead, and hence, a better sense of the effort that will be required.
Task: Collate into a document the complete detailed description of the intended behavior of the MVP version of the product.
- The intended audience for this document is team members, not users (i.e., this is not a user guide).
- Use a medium that is convenient for collaboration (e.g., a GoogleDoc).
- The content need not be polished. Don't waste time in formatting, copy editing etc.
- For each feature, specify the following:
Feature: Name of the feature e.g., Add contact
Purpose: What it does
Command format: The precise command format of the command.
Example commands: (to show how the command is used)
For each parameter, specify:
- Acceptable values e.g., If a command takes a person name as a parameter, what inputs are accepted as valid person names? Some example aspect to consider:
- Which formats are allowed for dates, times, telephone numbers, etc.?
- How does extra/leading/trailing spaces affect the value -- for instance is 'John Doe' same as 'John Doe' (note the multiple spaces in the middle of the name)?
- How does UPPER/lower case affects values -- is
John Doesame asjohn doe? - It's not enough to state 'valid name'; you need to specify what rules will be used to determine if the input is a valid name.
- Error message if the value is not acceptable
- Rationale for any the validity rule e.g., why only certain characters are allowed for person names?
Yes, making these decisions is not easy -- and that's why we want you to think about them now rather than later. Feel free to discuss these validation rules in the forum.
Outputs: Precise expected outputs when the command,
- succeeds e.g., changes in the GUI, messages shown to the user
- fails e.g., what are the error messages shown when a specific parameter is invalid, missing, specified multiple times, etc.
Duplicate handling: What rules are used to determine if two contacts are duplicates? e.g., is having the same name enough for two contacts to be considered duplicates, or all details need to be the same?
How does the application react to such duplicate entries? Reject or accept? Why?
Relevant UI mock-ups (unless the UI will be exactly the same as AB3): they can be hand-drawn or created using a tool such as PowerPoint, PlantUML, Figma, etc. -- they can be very low-fidelity mock-ups, as they are meant to be temporary
Recommended: Decide priorities of finer aspects of features, for example, as must-have (to implement in the MVP) and nice-to-have (i.e., to implement in the MVP only if there is time)
e.g., you can decide one date format that is to be supported in user commands as must-have and two other formats as nice-to-have.
It is OK to make compromises when making product decisions -- every design option has costs and benefits, and sometimes, costs outweigh the benefits.
For example, it is fine to restrict the person name to a certain length and a character set even if it is theoretically possible for those restrictions to conflict with some rare real-world person names. But you need to be aware of such conflicts, justify the restriction (e.g., ease of implementation/display), and know how users can work around such a conflict should they encounter it (e.g., if you app doesn't allow two contacts to have the same name but the user need to store two contacts which are different people with the same name, what should the user do?).You are welcome to (but not required to) follow AB3 when defining the behavior of the new features e.g., use similar command formats, input validation rules, error message formats.
Should the feature specification include features already in AB3?
Yes (). But you may copy-paste parts of the UG onto your feature spec if that helps.
- Ensure feature-fit: While doing this, ensure the features written by each member fit together to form a cohesive product, and meet other grading criteria of the product design aspect. This might require several rounds of refinement. You are encouraged to peer-review feature details written by other team members and refine the overall product design together.
- Submission [one person per team]: Save the file as a PDF file, name it
{team-id}.pdfe.g.,CS2103-T09-2.pdf, and upload to Canvas. - Grading criteria: to be considered 'done', the feature spec. should meet all the following criteria:
- Covers all features in the smallest set of features the product cannot do without.
- Contains all details mentioned above for each of those features
- Details seem well-thought-out (i.e., not a half-hearted attempt to satisfy the expected level of details)
Recommended: Divide among team members so that each person does a non-trivial amount of documentation; 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 wrote.
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:
3 Set up the project repo
- [/ one member] Set up the team org:
While only one member needs to do this, it may be useful to do this as a team while that member is screensharing, so that others get to see how it is done too.
- [/ one member] Set up the team repo (including the issue tracker):
- [ each member] Set up individual forks:
4 Get familiar with the codebase
Ideally, you should do this task in this week, but you may take an extra week (i.e., by week 7) to finish.
- Do the following tutorials to get familiar with the codebase