Aviation Web Learning Lab
EN / ID
Theme

Module 1 - Day 2 of 3

Gemini Web Chat

Day 2: Writing Your PRD

Welcome to Day 2! Yesterday you created the foundation of your PRD -- the flight plan overview with your destination and purpose. Today you will add the detailed route with specific waypoints. You will define exactly what features your application has, write user stories for each feature, create testable acceptance criteria, and list every page your app needs. These are the most important sections of your PRD because they tell a developer exactly what to build and how each feature should work. User stories follow a simple pattern: "As a [role], I want to [action], so that [benefit]." You will write one for each CRUD operation -- Create, Read, Update, and Delete. Each story will also include acceptance criteria that can be checked with a simple yes or no answer. By the end of today, your PRD will clearly describe what your Aircraft Maintenance Log app actually does and how each feature should behave. Open Gemini Web Chat and let's continue building your PRD.

Step 1

List the features your application will have

Concept

An aircraft has many systems: engines, hydraulics, avionics, landing gear. But your "aircraft" is very simple -- it has exactly four systems, one for each CRUD operation. Your feature list is like listing all the systems on an aircraft, but since your project is deliberately small, the list is short and clear. Every feature must map to one of the four CRUD operations: Create, Read, Update, or Delete.

Apply

Use Gemini to generate a feature list for your PRD. Make sure it lists exactly 4 features -- one for each CRUD operation.

Prompt

I am writing the Feature List section of my PRD for a web application called "Aircraft Maintenance Log". Please create a feature list table with exactly these 4 features (no more, no less): 1. Create a new maintenance log entry 2. View a list of all maintenance logs 3. Update an existing maintenance log entry 4. Delete a maintenance log entry Format as a table with these columns: | Feature Name | CRUD Operation | Description | Each description should be 1-2 sentences explaining what the feature does. Do NOT add any features beyond these 4.

Expected Result

Your PRD should have a Feature List table with exactly 4 rows -- one for each CRUD operation. No extra features like search, filter, export, login, or notifications.

Troubleshooting

  • • If Gemini adds extra features like search, filter, export, login, notifications, or dashboard, remove them. Your app has exactly 4 features -- one for each CRUD operation. This is the number one place where students accidentally over-scope their project.
Step 2

Write a user story for creating a maintenance log entry

Concept

In aviation, a maintenance task card tells a technician exactly what task to perform, under what conditions, and what the expected result is. A user story does the same thing for software: it tells the developer exactly what the user needs to accomplish. The format is: "As a [role], I want to [action], so that [benefit]." Today you will write user stories for each CRUD operation, starting with Create.

Apply

Use Gemini to write the Create user story with acceptance criteria. Copy it into your PRD document.

Prompt

I am writing user stories for my PRD. The application is "Aircraft Maintenance Log" for aviation maintenance technicians. Please write ONE user story for the Create operation using this exact format: **User Story:** "As an aviation maintenance technician, I want to [what they want to do], so that [why they need it]." **Acceptance Criteria:** (list 3-4 criteria, each must be testable with yes/no) - The form has fields for: aircraft_id, date, maintenance_type, description, technician_name, and status - The form validates that all required fields are filled before saving - After saving, the new log entry appears in the maintenance logs list - The user sees a confirmation message after successfully creating a log entry Do NOT add login, authentication, or any features beyond creating a log entry.

Expected Result

Your PRD should have a user story for the Create operation in "As a... I want to... so that..." format, with 3-4 testable acceptance criteria.

Troubleshooting

  • • If the acceptance criteria are vague like "the form works properly," rewrite them to be specific and testable. Good example: "The form has fields for aircraft_id, date, maintenance_type, description, technician_name, and status." You can verify this with yes or no.
  • • Make sure the user story uses the correct format: "As a [role], I want to [action], so that [benefit]." All three parts are required.
Step 3

Write user stories for Read, Update, and Delete operations

Concept

Continuing the task card analogy: just as an aircraft maintenance program has separate task cards for inspection, repair, and replacement, your PRD needs separate user stories for each operation. Each story focuses on one specific thing the user needs to do. Today you will write the remaining 3 user stories for Read, Update, and Delete operations.

Apply

Use Gemini to write 3 more user stories with acceptance criteria. Copy them into your PRD document.

Prompt

I am writing 3 more user stories for my "Aircraft Maintenance Log" PRD. Please write user stories for these 3 operations: 1. **Read/View:** As an aviation maintenance technician, I want to view a list of all maintenance log entries. 2. **Update:** As an aviation maintenance technician, I want to edit an existing maintenance log entry. 3. **Delete:** As an aviation maintenance technician, I want to delete a maintenance log entry. For each user story, use the format: "As an aviation maintenance technician, I want to [action], so that [benefit]." For each user story, write 2-3 acceptance criteria that are testable with yes/no. Examples: - Read: "The page displays all maintenance logs in a table with columns for date, aircraft_id, maintenance_type, and status" - Update: "The edit form is pre-filled with the existing log entry data" - Delete: "A confirmation dialog appears before the log entry is deleted" Do NOT add features beyond these 3 CRUD operations.

Expected Result

Your PRD should now have user stories for all 4 CRUD operations (Create from Step 2, plus Read, Update, and Delete from this step), each with testable acceptance criteria.

Troubleshooting

  • • Make sure each user story has distinct acceptance criteria. The Delete story should require a confirmation step. The Update story should mention pre-filling the form with existing data. The Read story should describe what columns the table shows.
  • • Do not add user stories for features like search, sort, filter, export, or login. You have exactly 4 user stories -- one per CRUD operation.
Step 4

Review and improve all acceptance criteria

Concept

Before an aircraft returns to service, each maintenance task has specific inspection sign-off criteria. The inspector checks each criterion with a clear yes or no answer. Your acceptance criteria must be just as specific: each one should be testable with a clear yes or no. "The form works" is NOT a good criterion. "The form has fields for aircraft_id, date, maintenance_type, description, technician_name, and status" IS a good criterion.

Apply

Use Gemini to review all your acceptance criteria and improve any that are vague or untestable.

Prompt

I have written acceptance criteria for 4 user stories in my PRD. Please review them and make sure each criterion is: 1. TESTABLE: Can be verified with a clear yes or no answer 2. SPECIFIC: States exactly what should happen (not "works properly" but "displays a table with columns X, Y, Z") 3. COMPLETE: Covers the main happy path (what happens when everything goes right) Here are my acceptance criteria. Please rewrite any that are vague: CREATE: [paste your Create acceptance criteria here] READ: [paste your Read acceptance criteria here] UPDATE: [paste your Update acceptance criteria here] DELETE: [paste your Delete acceptance criteria here] For each criterion that needs improvement, show the original and the improved version.

Expected Result

All acceptance criteria across all 4 user stories should be specific, testable with yes/no, and complete. No vague criteria like "works properly" or "looks good."

Troubleshooting

  • • Vague criteria like "the page works" or "it looks good" are NOT acceptable. Replace them with specific statements like "the page displays a table with columns for date, aircraft_id, maintenance_type, and status."
  • • Do not add acceptance criteria for features not in your scope. If a criterion mentions login, search, or notifications, remove it.
Step 5

List all pages your application will need

Concept

An airport terminal map shows what areas exist and what happens in each one: check-in here, security there, gates over there. Your page list does the same thing for your app. It shows what pages exist and what the user does on each one. Your app needs very few pages because it is so simple: one page to list all logs, one to create a new log, one to view a single log in detail, and one to edit a log.

Apply

Use Gemini to generate a page list for your PRD. Copy it into your PRD document.

Prompt

I am writing the Page List section of my PRD for the "Aircraft Maintenance Log" app. Please create a page list with exactly these 4 pages: 1. Home/Index page -- shows all maintenance logs in a table with columns for date, aircraft_id, maintenance_type, and status. Has a button to create a new log entry. 2. Create page -- a form to add a new maintenance log entry with fields for aircraft_id, date, maintenance_type, description, technician_name, and status. 3. Show/Detail page -- shows one maintenance log entry in full detail with all fields displayed. 4. Edit page -- a form to edit an existing maintenance log entry, pre-filled with the current data. Format as a table: | Page Name | URL Path | Description | Do NOT add pages for login, settings, dashboard, admin panel, or user profiles. Only these 4 pages.

Expected Result

Your PRD should have a Page List table with exactly 4 pages matching the 4 CRUD operations: Index (Read), Create (Create), Show (Read detail), and Edit (Update).

Troubleshooting

  • • Do not add pages for login, registration, settings, dashboard, admin panel, or user profiles. Your app has no authentication. Only 4 pages for 4 CRUD operations.
  • • Some applications combine Create and Edit into one form. That is fine too, but for this project keep them as separate pages -- it is clearer for beginners.
Step 6

Review and organize all Day 2 sections in your PRD

Concept

After every flight, pilots do a post-flight debrief. They review what went well and what needs attention. Now it is time to review all the PRD sections you wrote today. Check that everything is consistent: your features match your CRUD operations, your user stories match your features, and your page list matches your user stories.

Apply

Ask Gemini to review all your Day 2 PRD content for consistency. Fix any issues it finds.

Prompt

I have written the following sections of my PRD today. Please review them for consistency: 1. Feature List (should have exactly 4 features: Create, Read, Update, Delete) 2. User Stories (should have 4 stories, one per CRUD operation, in "As a... I want to... so that..." format) 3. Acceptance Criteria (each should be specific, testable with yes/no) 4. Page List (should have 4 pages matching the CRUD operations) Please check: - Does each feature have a matching user story? - Does each user story have testable acceptance criteria? - Does the page list cover all features? - Are there any extra features, stories, or pages beyond CRUD? - Is anything contradictory or missing? List any issues you find. If everything looks good, say "Your Day 2 PRD sections look consistent."

Expected Result

All Day 2 PRD sections should be consistent and complete: 4 features, 4 user stories with acceptance criteria, and 4 pages, all matching the CRUD operations.

Troubleshooting

  • • If Gemini suggests adding features, pages, or user stories beyond the 4 CRUD operations, do not add them. Your scope is intentionally small. Stick to the flight envelope.
  • • If there are inconsistencies (e.g., a feature without a user story, or a page that does not match any feature), fix them now before moving to Day 3.

Self-Check

Quiz