Repository navigation
Week 4 Sprint Plan
Connect NYC · Week 4 · High-level design and full E01 implementation plan
High Level Design · High Level Analysis · E01 · ZenHub Board
Design sprint goal: Produce the high-level design for E01 — Finding a Wi-Fi Hotspot, explain the UML interactions, connect the design to the backlog, and establish responsibilities and a Definition of Done.
Next implementation sprint goal: Deliver the full E01 experience. Without signing in, a visitor can browse official NYC hotspot markers, search by location/address or landmark, filter by borough/neighborhood, provider or hotspot type, and open a profile showing official information, existing written reviews and average ratings with clear source labels.
Implementation sprint: October 13–19, 2026, inclusive.
Epic owner: Boqing Xin (jay-den-21). The next implementation sprint includes the complete E01 scope described below, including profiles and existing community feedback.
The component overview assigns responsibilities to the browser, application, database and official-data import. The two UML sequence diagrams cover search/filter and hotspot-profile reads, including no-match and no-rating outcomes. The deployment view identifies runtime boundaries, while the data model and read interfaces connect those responsibilities to the backlog.
The implementation covers E01's six child stories (#8–#12 and #41), the average-rating behavior in #22, the source labels in #28, and the public-reading portion of #19. Data preparation and QA are explicit support tasks.
Registration, contribution sign-in flows, review creation/editing/deletion, forums, moderation, availability reports, reliability scores, follows and notifications remain outside this sprint. Map/list switching, nearby-radius search and search-state restoration are not added to the existing scope. An official hotspot record does not establish current connectivity.
Most implementation work is assigned to Boqing and Jiahao. Kavya and Suvan prepare the data and model inputs; Xiaoqi verifies the application, defects and demo data.
| Story | Scope in the next implementation sprint | Primary implementation owner | Dependency |
|---|---|---|---|
| US01 / #8 — Interactive map | Official hotspot markers and basic location information on selection. | Boqing | Official records, coordinates and map rendering. |
| US02 / #9 — Location search | Location/address search, the landmark scope in E01, matching markers and no-match feedback. | Jiahao (linj4114) |
Documented location matching and stored hotspot locations. |
| US03 / #10 — Area filter | Select/change/remove borough or neighborhood; matching markers and no-match feedback. | Jiahao | Geographic field mapping and neighborhood coverage. |
| US04 / #11 — Provider filter | Select/change/remove provider; matching markers and no-match feedback. | Jiahao | Provider field mapping and map display. |
| US05 / #12 — Type filter | Select/change/remove hotspot type; matching markers and no-match feedback. | Jiahao | An explicit mapping to the official source's type field. |
| US31 / #41 — View a Hotspot Profile and Existing Reviews | The selected hotspot's official information and existing reviews; integration with ratings and source labels. | Boqing, with Jiahao supporting the read API and data integration | #8, stored review data, #22 and #28. |
| US12 / #22 — Average rating | Correct aggregation, no-rating state, public display and recalculation after stored ratings change. | Jiahao | E03 rating data linked to the correct hotspot. |
| US18 / #28 — Source labels | Distinguish official NYC Open Data fields from community ratings/reviews on the profile. | Boqing | Official source identity and #41 profile integration. |
| Support task | Responsibility | Deliverable |
|---|---|---|
| #42 — Official data, field mapping and ERD | Kavya (KavyaMukewar) and Suvan (suvanamruth) |
Obtain the official data, document its source and field mappings, prepare reproducible data inputs, and produce the ERD for hotspot identity and its rating/review relationships. |
| #43 — E01 acceptance verification, defects and demo-data checks | Xiaoqi | Execute the verification matrix, record expected/actual results, report and retest defects, and check that demo data and labels accurately represent the underlying records. |
Boqing coordinates integration and delivery as E01 owner. Boqing and Jiahao implement application code, automated checks and defect fixes for their assigned work. Data and QA support continue through integration rather than ending at handoff.
- Data and model foundation: Kavya and Suvan supply official data, field mappings and the ERD. Boqing and Jiahao connect the application to the data and document the location-matching implementation. Xiaoqi derives expected results from the same data.
- Discovery: Boqing implements the map; Jiahao implements search and the three filter stories. Each query path is checked against known hotspot records, including a no-match case.
- Profile and community reads: Boqing implements #41 and #28 while Jiahao implements #22 and supports the profile read API. Existing review fixtures include multiple hotspots, ratings with and without text, and a hotspot with no ratings.
- Integration and verification: Xiaoqi verifies the complete anonymous journey and retests reported defects. Boqing and Jiahao resolve implementation failures. Completion is assessed against the Definition of Done.
These steps organize the full sprint scope. Search, area/type filters and profiles are included in this sprint rather than deferred candidates.
The matrix verifies story-specific behavior. The shared Definition of Done in Section 5 establishes the quality required for every completed item.
| Requirement | Acceptance verification | Verification method |
|---|---|---|
| #8 — Official map | Official records appear as selectable markers; selecting each tested marker displays that record's basic location information. | Fixture-to-marker comparison and UI verification. |
| #9 and E01 — Location/address/landmark search | Known queries return the expected hotspots and location information under the documented matching method. Results remain selectable; a query with no matching hotspots shows a message. | Search cases with expected hotspot identifiers and actual results. |
| #10 — Borough/neighborhood | Verify both geographic categories: select, change and remove the filter; every result matches the selected area; markers remain selectable; no-match feedback appears when applicable. | Field mapping, automated query checks and UI verification. |
| #11 — Provider | Select, change and remove a provider; only matching selectable hotspots appear; a no-match case displays a message. | Provider fixture cases and UI verification. |
| #12 — Hotspot type | The filter uses the documented official type field. Select/change/remove works, results match the selected value, markers remain selectable, and no-match feedback is shown. | Type mapping, fixture cases and UI verification. |
| #41 — Profile and existing reviews | The selected hotspot's profile displays its stored location/provider information and associated existing review text. Another hotspot's reviews do not appear. #22 and #28 are integrated. | A fixture containing distinct hotspots and reviews, plus profile integration checks. |
| #22 — Average rating | Check known averages, no-rating behavior and ratings without written text. Adding, editing or deleting stored ratings changes the displayed average correctly. Only hotspot star ratings enter the calculation. | Automated model/service tests and profile display checks. |
| #28 — Source distinction | Official fields identify NYC Open Data; ratings/reviews identify community content; both labels are visible on the hotspot profile. | Profile UI verification. |
| #19 public-reading portion and E01 | In a signed-out session, complete map → search/filter → profile → existing reviews/ratings without being required to log in. | Anonymous end-to-end verification. |
For the rating check, a deterministic fixture can use ratings [1, 3] → average 2; add 5 → 3; edit 1 to 4 → 4; delete 5 → 3.5. A rating without written text remains part of the average. “No ratings yet” is shown only when there are no ratings. Test fixtures are identified as test/demo content rather than presented as real user submissions.
- Acceptance criteria pass: Every applicable acceptance criterion for the completed story is verified. Partial work is not marked complete.
- The application works end to end: The affected browser, application and data components work together for the completed story in the demo environment. Results correspond to the selected hotspot and query. Epic completion also requires the full anonymous discovery-to-profile journey to pass.
- Data and setup are reproducible: Source data, field mappings, the ERD, setup and data-loading instructions are documented. Official records retain their identity; review fixtures are clearly identified as test/demo data. Another contributor can reproduce the verification.
- Checks and QA pass: Relevant automated tests cover search/filter correctness, hotspot associations and rating aggregation. Xiaoqi verifies acceptance criteria, records defects and retests fixes. No unresolved defect prevents an acceptance criterion from passing.
- Code is reviewed and integrated: Implementation is reviewed and merged. Any CI checks already configured for the repository pass. The verified build is the one used for the demo.
- Information is represented accurately: Official and community information are distinguished. Missing ratings are not shown as a zero score, and official records are not presented as a live connectivity check. Known limitations and remaining work are recorded.
E01 is complete when all its included stories and profile integrations satisfy their acceptance criteria and this Definition of Done.
- E01 / #41: Profile and existing-review reading are explicitly included in this sprint. E01 completion requires them in addition to the five original map/search/filter stories.
- E02 / #19: This sprint implements the public-reading portion. Sign-in prompts and resuming contribution actions remain outside scope; anonymous access alone does not complete all of #19.
- E03 / #22: All average-rating acceptance criteria are in scope, including recalculation after stored ratings are added, edited or deleted. Model/service tests can verify those changes without implementing the contribution UI. #22 can be completed when all its criteria pass; this does not complete review creation, editing or deletion in #21, #23 or #24.
- E04 / #28: Source labels are in scope and #28 can be completed when all its criteria pass. This does not complete E04 as a whole.
- E04 / #26: The data support task supplies official records needed by E01. Administrator-triggered import, duplicate prevention and administrator-only stored-record viewing remain #26's separate requirements. Data preparation alone does not complete #26.
The linked E03/E04 stories retain their existing parents. Their E01 integration is tracked here without duplicating their requirements or treating entire dependent Epics as part of the sprint.