Lab 8: Requirements Review & Acceptance Planning
These are the requirements we commit to completing in the final delivery.
They align with Suzan Hoca’s feedback (visualizations, healthy ranges, data correctness), backend consistency needs, and team feasibility.
| Req. ID | Requirement Description | Current Status (%) | Priority | Reason for Inclusion |
|---|---|---|---|---|
| 1.3.x | RecipeModel Refactor (Central DB, remove mock/static data) | 0% | High | Blocker for costing & recipe accuracy; required for architecture maturity |
| 1.9.x Update | Nutrition Score Update (include water intake) | 0% | High | Direct instructor feedback; improves medical accuracy of score |
| 1.1.9 Extension | Healthy Range / Portion Safety Validation | 60% | High | Critical safety element (portion warnings) requested in feedback |
| 1.1.x | Micronutrient Range Filtering API | 0% | High | Enables advanced filtering (“Vitamin C > X mg”) |
| UI/UX Update | Radar (Spider-Web) Charts Everywhere | ~50% | High | Strong requirement from Suzan Hoca; improves clarity |
| 1.5.x Extension | Future-Oriented Meal Planner (What-If Planning) | 0% | Medium | Enables next-week and scenario-based nutrition planning |
| 1.4.x | Admin Panel: Edit User Food Proposals Before Approval | 0% | Medium | Improves moderation workflow; requested explicitly |
| NFR – Standards | W3C / WCAG-Compliant UI Improvements | 25–30% | Medium | Required for accessibility & course grading |
During the review of the previous milestone, several cross-cutting issues were identified that are not tied to specific functional requirements but significantly impact the overall quality of the software engineering project. These should be resolved before the final demo.
-
Formatting
- Use Case Diagrams: Inconsistent formatting across diagrams, with multiple diagrams containing layout and styling issues. Plan: Re-export all use case diagrams using consistent formatting rules and a standardized layout template.
-
Planning
- Milestone plan issues: Many GitHub issues lack start or end dates, making it difficult to track the project timeline accurately. Plan: Update every issue in GitHub Projects to include explicit start and end dates, assignees (owners), and dependencies where applicable.
These items will not be completed during this milestone due to size, complexity, or low immediate priority.
| Req. ID | Requirement Description | Current Status (%) | Exclusion Reason |
|---|---|---|---|
| 1.3.5–1.3.6 | Recipe costing (price filters, cost estimation) | 20–40% | Depends on RecipeModel refactor; cannot be completed in 2 weeks |
| 1.2.13–1.2.19 | Badges, impact metrics, helped count | 25–70% | Large UI+backend effort; not requested in CM2 feedback |
| 1.8.2–1.8.16 | Moderation roles, appeals, automated detection | 5–45% | Complex workflows; out of scope for final milestone |
| 1.4.14–1.4.17 | Extra engagement features (responsibility prompt, top posts) | 10–25% | Enhancements, not core functionality |
| 1.7.5–1.7.6 | Password recovery & email verification | 10–15% | Low priority; not essential for demo |
| Full NFR Suite | Performance testing, load testing, availability | 25–45% | Too sophisticated to complete; focus only on WCAG fixes |
RecipeModel Refactor (1.3.x) - Critical
- Migrate recipe storage to centralized database with Recipe-Food relationships
- Create API endpoints and update all clients to remove mock/static data
- Team: Backend (2 devs) + Frontend (1 dev)
- Impact: Unblocks nutrition aggregation and future costing features
Nutrition Score Update (1.9.x) - Critical
- Add water intake tracking to nutrition model and score calculation
- Implement UI for water logging (ml/glasses) with daily progress visualization
- Team: Backend (1 dev) + Web/Mobile UI (2 devs)
- Rationale: Direct customer feedback from Suzan Hoca on accuracy
Radar Charts (UI/UX) - High Priority
- Complete radar chart integration for food comparison and recipe breakdown
- Implement mobile equivalent (circular/adapted format) in at least 2 contexts
- Team: Frontend (2 devs) + Mobile (1 dev)
- Status: Already 50% complete; strong customer emphasis on visual clarity
Healthy Range Validation (1.1.9) - High Priority
- Complete backend validation for unsafe portions with visual warnings
- Integrate tooltips and color indicators into food detail and meal logging
- Team: Backend (1 dev) + Web/Mobile (2 devs)
- Status: Already 60% complete; safety feature explicitly requested
Micronutrient Range Filtering (1.1.x) - High Priority
- Design API endpoint with min/max filters for top 10-15 micronutrients
- Create UI components with sliders and preset options
- Team: Backend (1 dev) + Frontend (1 dev) + Mobile (1 dev)
- Use Case: Enable advanced search like "Iron > 5mg" or "Sodium < 200mg"
Admin Panel Edits (1.4.x) - Medium Priority
- Add edit functionality to food proposal review with audit logging
- Update approval workflow to notify users of moderator corrections
- Team: Backend (1 dev) + Frontend (1 dev)
- Benefit: Reduces rejection rate and improves data quality
Future Meal Planner (1.5.x) - Medium Priority (Contingent)
- Extend planner to support multi-week date selection with save/load
- Implement comparison view for nutritional differences between plans
- Team: Backend (1 dev) + Web/Mobile (2 devs)
- Note: Contingent scope; may be reduced to basic date picker if delays occur
WCAG Compliance (NFR) - Medium Priority
- Run accessibility audits and fix critical issues (contrast, keyboard nav, ARIA)
- Add alt text and skip navigation; validate with screen readers
- Team: Frontend (2 devs)
| Team | Week 1 Focus | Week 2 Focus |
|---|---|---|
| Backend (3 devs) | RecipeModel refactor, Water intake tracking | Micronutrient filtering API, Safety validation, Admin edits |
| Frontend (3 devs) | Radar charts, Recipe integration | Range filtering UI, WCAG compliance, Admin panel |
| Mobile (2 devs) | Water intake UI, Radar chart equivalent | Range filtering, Meal planner extension |
| Risk | Mitigation Strategy |
|---|---|
| RecipeModel refactor extends beyond Week 1 | Shift resources from Future Meal Planner; prioritize core functionality over nice-to-have features |
| Radar charts too complex for mobile | Deliver enhanced bar charts with comparable information density; maintain web radar charts |
| Micronutrient filtering performance issues | Limit initial rollout to top 10 micronutrients; expand iteratively with optimization |
| WCAG compliance broader than expected | Focus on critical user flows only; address remaining issues post-submission |
| Future Meal Planner scope creep | Reduce to single-week date selection with basic save functionality |
| Category | Requirements |
|---|---|
| Must-Have (Critical) | RecipeModel complete with zero mock data Water intake tracking functional in score calculation Radar charts deployed in minimum 2 contexts Healthy range warnings functional for top 15 micronutrients Micronutrient filtering API operational |
| Should-Have (High Priority) | Admin edit workflow deployed WCAG 2.1 Level AA compliance for critical flows Future meal planner with basic multi-week support |
| Nice-to-Have (If Time) | Extended radar chart coverage Complete WCAG compliance across application Advanced meal plan comparison features |
All new features must include:
- Unit tests for backend endpoints (enforced by CI)
- Component tests for UI visualizations and filtering
- Accessibility tests integrated into PR review
- Manual QA session before final submission
Acceptance testing is not a single event but a continuous cycle that runs parallel to our development roadmap. Our future planning ensures that stakeholders transition from passive observers (during demos) to active participants (during testing). Our testing strategy moves beyond simple code verification to ensure the final product aligns with user needs and business goals. We employ a multi-layered approach involving the following methodologies:
- Focus: We validate specific user situations, such as "A user attempting to log an unsafe amount of sugar" or "A user filtering foods by Vitamin C content." This ensures that the system handles both "Happy Paths" (ideal usage) and "Edge Cases" (errors/limits) correctly.
We validate complete user journeys that span across multiple modules (Frontend, Backend, and Database) to ensure system cohesion.
- Approach: We simulate critical user flows from start to finish. We use Selenium tests as well as user acceptance tests to verify this.
- Example Workflow: User Registration → Profile Customization → Searching for a Food Item → Adding Item to Meal Plan → Verifying Update in Daily Nutrition Values.
- Goal: This confirms that the integration between the Social module (User ID), Food Catalog (Data), and Calculation functions seamlessly as a single unit.
- Approach: Regular milestone meetings (Customer Milestone 1 & 2) where live demos are performed. Moving forward, we have scheduled specific windows for User Acceptance Testing (UAT) where stakeholders will interact with the system directly in the Staging Environment, rather than watching a screen share.
-
Execution:
We conduct dedicated review sessions with our stakeholders to validate the product's value proposition. In these sessions before the final release, we will provide stakeholders with credentials to a
stagingbuild. This allows them to explore the application at their own pace without the pressure of a live presentation. During these sessions, we will observe if the Acceptance Criteria hold true in practice. For example, if Suzan Hoca feels the warning modal is too intrusive during a standard workflow, we will adjust the criterion to be less aggressive.
Following the UAT, after we have reflected on the feedbacks we got from the UAT, we will hold a structured review meeting with Suzan Hoca to validate the safety, content, value and logic components of the project. The goal is to confirm that the future planning for the features aligns with the educational and analytical goals of the project. The ultimate goal of this planning strategy is to reach a Consensus of Readiness. In this meeting, we will also review the Traceability Matrix with stakeholders to demonstrate that every critical feedback point raised during Customer Milestone 2 has been addressed, tested, and verified.
Our testing strategy focuses on validating complete User Workflows rather than isolated code functions. We define specific paths a user takes through the application, establish acceptance criteria for key steps within those paths, and systematically test every point to ensure compliance.
We employ the following core methodologies:
Instead of testing atomic features in isolation, we map out full "End-to-End Workflows" (e.g., The lifecycle of a Food Proposal).
- Approach: We define the sequence of steps a user performs to achieve a goal.
- Validation: We attach specific Acceptance Criteria to critical decision points within that workflow.
- Execution: We test every single criterion within the flow. If one point fails (e.g., a warning fails to trigger), the entire workflow is marked as "Failed."
During the scheduled Stakeholder UAT sessions, we will use the following schema to rigorously validate the High Priority requirements defined in our new direction. These tables will be filled out live during the sessions with Suzan Hoca.
Stakeholder: Suzan Hoca | Priority: High | Goal: Verify proactive planning logic.
| T-101 | Step No | Instruction | Expected Behavior | Actual | Result | Note |
|---|---|---|---|---|---|---|
| 1 | Open Calendar and select a date +3 days from today. | The UI switches focus to the future date; "Today's" data is hidden. | ||||
| 2 | Search for "Grilled Salmon" and click "Add to Lunch." | The item appears in the specific meal slot for that future date. | ||||
| 3 | Navigate back to "Today" (Home Dashboard). | The "Grilled Salmon" macros must not appear in today's consumed total. | ||||
| 4 | Return to Future Date and view "Projected Score." | The score must calculate a hypothetical total based on the Salmon. |
Stakeholder: Arda/Furkan | Priority: High | Goal: Verify Central Database & Admin capabilities.
| T-103 | Step No | Instruction | Expected Behavior | Actual | Result | Note |
|---|---|---|---|---|---|---|
| 1 | Log in to Admin Panel and open "Pending Proposals." | List loads dynamically from the Central Database (not local JSON). | ||||
| 2 | Click "Edit" on a proposal with a typo (e.g., "Apble"). | A form opens allowing modification of the Name field. | ||||
| 3 | Correct name to "Apple" and click "Publish." | Status updates to APPROVED and item vanishes from Pending list. |
||||
| 4 | Log in as standard User and search "Apple." | The newly approved item appears in search results immediately. |
We have established a formal mechanism to convert stakeholder feedback into actionable development tasks for the final milestone:
- Capture: Feedback provided during UAT sessions is recorded immediately as "Raw Observations."
-
Triage: The team reviews observations to categorize them:
- Critical Bug: Must be fixed immediately (e.g., Nutrition Score calculating incorrectly).
- Critical Feature: Must be implemented immediately (e.g. Portion sizes should be added to the warning system).
- UX Refinement: To be polished if time permits (e.g., Color contrast on the Spider Chart).
- Future Scope: Valuable ideas that are too large for the current semester (added to "Future Work" documentation).
- Execution: Accepted feedback is converted into GitHub Issues/User Stories and assigned to the relevant developer (Frontend/Backend).
To ensure no requirement is left behind, we maintain a Traceability Matrix that links every Acceptance Test back to a specific entry in the Software Requirements Specification (SRS).
-
Approach: Every User Story or Test Case includes a reference tag (e.g.,
Test-05validatesSRS-Req-12). - Goal: This guarantees Functional Completeness. If a Requirement in the SRS does not have a corresponding passed Acceptance Test, the feature is marked as "Incomplete." This prevents scope creep and ensures all promised deliverables are verified.
We validate the "Quality of Experience" by gathering qualitative feedback during the review and UAT sessions.
- Approach: We observe how stakeholders interact with new UI elements without direct guidance.
- Metric: We look for friction points—areas where the user hesitates or misunderstands the interface (e.g., "Is the '100g' toggle clear?" or "Did the user notice the help button?").
- Outcome: Feedback is immediately converted into UI/UX refinement tasks (e.g., the decision to create a "Safe View" mode based on feedback regarding alert fatigue).
To validate we are building "the right thing," we use Workflow-Based Acceptance Criteria. We outline the user's path and list the specific conditions that must be met for the workflow to be considered successful.
Rationale: Addresses feedback from Suzan Hoca regarding portion control and safety.
Example Workflow:
- User navigates to "Add Food" page.
- User inputs food name and macro details.
- User inputs a specific portion size (grams).
- User attempts to submit the proposal.
Acceptance Criteria:
- Criterion 1: If the entered portion size exceeds the healthy limit (e.g., >200g sugar), the system must display a warning modal immediately.
- Criterion 2: The warning modal must clearly state why the amount is flagged (e.g., "Exceeds daily recommended limit").
- Criterion 3: The "Submit" button must remain disabled or blocked until the user explicitly acknowledges the warning or corrects the value.
- Criterion 4: If the value is within range, the submission proceeds without interruption.
A workflow is only marked "Complete" when the stakeholder agrees that every point in the criteria list has been satisfied to their standard.
| Standard / Guideline | Current Status | Gaps | Plan |
|---|---|---|---|
| WCAG 2.1 AA (2.2.1) Text Alternatives | Deferred | Missing alt attributes on food images |
Low Priority: Will rely on adjacent text headings for context; implementation postponed. |
| WCAG 2.1 AA (2.2.2) Color Contrast | Partial | Inconsistent ratios on secondary UI elements | Audit and adjust hex codes to meet 4.5:1 ratio. |
| **WAI-ARIA 1.2 (2.2.3)**Keyboard Navigation | Descoped | Focus indicators and tab order undefined | Excluded: Feature deemed non-vital due to primary mobile-touch use case. |
| BCP 47 (2.2.4) Language Tags | Pending | No lang attributes defined |
Implement dynamic lang tagging (e.g., tr-TR) for all pages. |
| W3C i18n (2.2.5) Bidirectional Script | Pending | UI currently LTR only | Implement dir="rtl" logic, specifically for Arabic support. |
| W3C i18n (2.2.6) Locale Formatting | Pending | Prices static; no multi-currency logic | Implement dual-currency storage and locale-aware display formatting. |
| ISO 23662:2021 Vegan/Vegetarian Criteria | Pending | Data model lacks specific dietary flags | Add fields for dietary compliance verification. |
| OIC/SMIIC 1:2019 General Halal Food | Pending | Data model lacks Halal certification flags | Add fields for Halal compliance verification. |
To address the gaps identified above, the following technical roadmap will be executed:
-
Implement Internationalization (i18n) Core:
-
Apply BCP 47 Language Tags to the HTML root based on the user's selected preference.
-
Enable Bidirectional support, ensuring the layout mirrors correctly (RTL) when Arabic is selected.
-
-
Develop Locale-Aware Currency System:
-
Modify the
FoodItemdata schema to include two distinct price fields:price_local(input by user) andprice_usd(normalized). -
Implement a nightly background job to fetch current exchange rates and update the
price_usdfield based on theprice_localvalue. -
Ensure the frontend renders prices using W3C locale formatting (e.g., comma vs. decimal points).
-
-
Finalize Visual Accessibility:
- Conduct a review of the color palette to ensure the 4.5:1 contrast ratio is met for all text elements (Standard 2.2.2).
-
Integrate Dietary Information Models:
-
Update the database schema to support specific dietary standards, citing:
-
ISO 23662:2021: Definitions and technical criteria for foods and food ingredients suitable for vegetarians or vegans.
-
OIC/SMIIC 1:2019: General Requirements for Halal Food.
-
-
-
Document Deviations:
- Formalize the decision to deprioritize Keyboard Navigation (2.2.3) and **Text Alternatives (2.2.1)**based on the mobile-first scope and existing UI redundancy.
| Source | Feedback Summary | Impact (High/Med/Low) | Planned Change |
|---|---|---|---|
| Instructor | Example: “Filter labels unclear” | High | Redesign filter panel |
| Demo Users | “Loading feels slow” | Medium | Add skeleton loading UI |
| ... | ... | ... | ... |
- Confusing navigation
- Inconsistent button styles
- No loading indicators
- Mobile version layout issues
- Limited feedback after actions
Feedback: The system should warn users if selected quantity/grams exceed healthy ranges, or make this a selectable option/view. Additionally, users should be able to select servings rather than only entering grams.
UX Impact: Currently, users can input unsafe portion sizes without any guidance, potentially leading to unhealthy consumption patterns. The lack of serving size options also makes the input process less intuitive, as users typically think in terms of servings (e.g., "1 cup", "2 slices") rather than grams.
Improvement Plan:
- Add serving size selection option alongside gram-based input (e.g., "1 serving", "1 cup", "2 slices")
- Implement warning modal system that alerts users when portions exceed recommended daily values
- Add configurable "Safe View" toggle for users who want continuous proactive guidance
- Integrate with RDA (Recommended Dietary Allowance) standards for threshold determination
- Priority: High
- Timeline: Until final milestone
Feedback: The Advanced Meal Planner needs to support future-oriented nutrition planning, allowing users to schedule micronutrition values for future dates and explore "what-if" scenarios.
UX Impact: Current retrospective-only logging limits the app's utility for proactive health management. Users cannot plan ahead or model different dietary scenarios, reducing the app's value as a preventive health tool.
Improvement Plan:
- Extend meal planner to support future date selection (at least 30 days ahead)
- Implement "what-if" scenario modeling for comparing different meal plans
- Add visual comparison tools showing projected nutritional impact of different choices
- Enable saving and comparing multiple planning scenarios
- Priority: High
- Timeline: Until final milestone
Feedback: Use Spider Web (Radar) charts more frequently for nutrition comparisons to better display multi-variable data.
UX Impact: Current basic charts and tables struggle to convey complex nutritional profiles across multiple micronutrients simultaneously, making it difficult for users to grasp overall nutritional balance at a glance.
Improvement Plan:
- Integrate Spider Web charts as the primary visualization for nutrition comparisons
- Deploy in Daily Summary, Meal Comparison, and Food Profile views
- Add interactive tooltips for nutrient interpretation
- Ensure charts render efficiently (< 500ms) for good user experience
- Priority: Medium
- Timeline: Until final milestone
Feedback: Water intake should be included in the nutrition score calculation.
UX Impact: Current scoring system is medically inaccurate by omitting hydration as a fundamental pillar of nutrition, potentially misleading users about their overall health status.
Improvement Plan:
- Research and define water intake weighting methodology in overall nutrition score
- Refactor scoring algorithm to incorporate hydration metrics
- Update UI to clearly show water's contribution to overall score
- Document the weighting formula for transparency
- Priority: High
- Timeline: Until final milestone
Feedback: Add filtering capabilities by micronutrient range (e.g., "Show foods with > 20mg Vitamin C").
UX Impact: Users cannot efficiently search for foods that meet specific nutritional needs, reducing the app's utility for targeted nutrition management, especially for users addressing specific deficiencies.
Improvement Plan:
- Design filter UI with range sliders for common micronutrients
- Implement backend filtering logic with efficient database queries
- Add filter presets for common nutritional goals (e.g., "High Iron", "High Protein")
- Enable combining multiple micronutrient filters simultaneously
- Priority: Medium
- Timeline: Until final milestone
Feedback: Recipes are currently hardcoded/local and need to be fetched from a larger, central database.
UX Impact: Limited recipe variety, potentially outdated information, and poor scalability affect user experience by restricting meal planning options and preventing dynamic content updates.
Improvement Plan:
- Design centralized database schema and API endpoints for recipe management
- Refactor RecipeModel to consume API instead of local data
- Migrate existing recipes to centralized database
- Ensure lightweight client performance while accessing larger recipe library
- Priority: Medium
- Timeline: Until final milestone
Feedback: Admin panel must include the ability to edit food proposals submitted by users or scrapers before publication.
UX Impact: Quality control gap in user-submitted and scraped food data could lead to inaccurate nutritional information reaching users, undermining trust in the app.
Improvement Plan:
- Implement food proposal editing interface in admin panel
- Add change tracking and version control for edited proposals
- Create approval workflow with edit history
- Priority: Low
- Timeline: Until final milestone or post-delivery
1. Improve Proactive Health Guidance
- Implement safety warnings for potentially unhealthy portion sizes
- Add intuitive serving size selection to simplify food logging
- Begin supporting future-oriented planning with basic "what-if" scenario modeling
- Move toward enabling users to plan meals in advance, not just record past consumption
2. Improve Health Assessment Accuracy
- Incorporate hydration into nutrition scoring alongside macros and micros
- Work toward a more complete representation of overall health status
- Provide users with more comprehensive health metrics
3. Improve Data Visualization and Comprehension
- Introduce Spider Web charts for multi-nutrient visualization where appropriate
- Add information tooltips to help non-professionals interpret nutritional data
- Attempt to balance simplicity for beginners with useful detail for more experienced users
- Make complex nutritional profiles easier to understand at a glance
4. Support More Targeted Nutrition Management
- Enable micronutrient range filtering for more efficient food discovery
- Continue personalizing recommendations based on user fitness metrics and goals
- Help users more efficiently address specific nutritional needs or deficiencies
5. Improve System Scalability and Data Quality
- Migrate to centralized database for recipe management to support future growth
- Work toward maintaining lightweight client performance while accessing larger content
- Establish quality control processes for user-contributed content through admin editing
6. Adhere to Core Design Principles
- Accessibility: Provide tooltip-based information for non-professionals; offer expandable detailed micronutrient lists for experts; aim for multi-level information architecture
- Inclusivity: Ensure health advice considers user background and context; respect individual fitness goals and dietary restrictions; avoid one-size-fits-all recommendations
- Ethical Data Privacy: Maintain strict privacy on user body metrics and preferences; prevent public sharing or cross-user visibility of sensitive health data; provide clear data usage policies
7. Target Delivery Metrics
- Address all high-priority UX issues identified in feedback
- Implement the critical milestone feedback items
- Complete serving size selection for food items
- Support future-date meal planning for at least 30 days ahead
- Include water intake in nutrition score calculation with documented methodology
- Optimize Spider Web chart rendering for reasonable performance
- Implement micronutrient filtering for key nutrients
- Seek validation that the app provides more proactive guidance than simple retrospective tracking
- Test that safety warnings are helpful without being intrusive
- Verify that serving size input feels more natural than gram-only input
- Work toward visualizations that effectively communicate nutritional complexity
- Aim for users to feel more informed when making nutritional decisions
The feedback has helped us refine our product direction: moving from primarily retrospective logging toward enabling some future planning, from purely displaying data toward providing more contextual guidance, from basic visualizations toward more interpretive charts, from food-only tracking toward including hydration, and from technical gram-based input toward more natural serving sizes. We aim to deliver a tool that helps users make more informed nutritional decisions while remaining realistic about the scope achievable within our timeline.
