Meeting Info
Date: 14th August Time: 12:00 Location: 12:00pm Tutorial Note taker: Oliver Starkey
Attendance
- Oliver Starkey
- Julian Lewis
- Matthew Wang
- Alex Zhang (had an assessment)
- Zoy Zhong
Agenda
- Our first (mock) standup
Summary
Presentation
Summary of the presentation Harry gave at the start of the tutorial #TODO maybe ask Harry for the slides.
**Steps of requirements analysis process
- Stakeholder Identification (done)
- Elicitation of requirements
- Documentation of requirements
- Analysis and Negotiation
- Validation and verification
Requirement analysis (steps 2 and 3)
Given the list of requirements we’ll:
- Break down into what’s in scope
- Break down into function vs non-functional requirements
- Break down into user stories
- Discussion/feedback from requirements with clients
User stories form a backlog:
- These will be broken into product backlog (all)
- And a sprint backlog (subset just for that sprint - chosen carefully)
User Stories
Consist of:
- Priority (assignment should be decided with the client - important for sprint planning)
- Story Point (quantify how much work it is - important property: relative scale)
- Due Date
- Assignee
- Status
- Acceptance Criteria
- Reviewer
Epic
Is an approach to breaking down and focussing on features. They operate at a higher level about user-stories. User-stories are assigned to an Epic. E.g., Maps might be an epic.
Technology:
- You can automate and nicely organise a lot of these processes using software. Harry explained this for Jira, we should figure out the best workflows on GitHub.
Summary:
- Defined how to achieve Sprint Goal (design)
- Create Sprint Backlog (User Stories) from Product
- Estimate Sprint Backlog using team velocity and Story Point estimates (e.g. Alice can complete 10 SP’s in a sprint, Bob can complete 5.)
- Product Owner priority guides the work (e.g. priority assignment)
- Release Plan is created
- High-level design is considered
Final Doc (Exemplar from past year)
He wen’t over an absolutely CRACKED final document. Here is some general structure:
- Table with decision making
- Communication (e.g. schedule meeting meetings - different types of meeting e.g. client meetings)
- Sprint planning
- Sprint review
- Sprint retrospective
- What we did well
- What we could do bette
- External communication (e.g. emails sent, prototypes sent and feedback from client)
- Architecture documentation (functional and non-functional requirments)
- DCD
- Database Diagram
- Architecture Diagram (don’t forget to include deployment platform)
- Product brief
- Market analysis
- Frontend
- Storybook for documentation of frontend components
- Webflow routing (user flow diagram)
- Backend
- Research (on tech stack, on authentication)
- API doc (use Swagger - automatic for the endpoints etc. )
- Table for the different methods (what the response messages mean etc.)
- Feedback
- Supervisor feedback
- Peer feedback
- Epic and User stories
- Every user story linked to a jira ticket (priority / story point)
- Cancelling user stories is ok
- Rules for creating new user stories
- Types of tickets ( development, feature request, bug report, impprovements, chores)
- Ticket components
- Code and Repo standard
- Naming conventions
- Guide on Prettier Linter
- GitHub conventions (branching etc. / pull request workflow)
- Backend / front end file structure
- Handover document
- Features
- Features by sprint
- Frontend Design
- Product Overview and Stakeholder Information
- Known Issues and Future Works
- For developers
- Change Logs
- Authentication and Authorisation
- Demo Video
Action Items
- Chase up Harry about the requirements document (can’t really start until we have this)
- Documentation
- Backfill stuff like decision making
- Start on the architecture documents
- Researching tech stack and justifying/comparing choices?
- Setting up documentation very cleanly (perhaps think about how we might deploy it)
Next Meeting
- Tuesday after MOC?