Chapter 5

Core skill: hands-on full-stack projects

Master the complete process from requirements to delivery, understand the methodology of Spec-driven development, learn WBS decomposition and DoD definition, and gain enterprise-level project management and quality control capabilities.

Requirements clarification methodology

Clarifying requirements is the foundation of project success. Through a systematic approach, ensure that real needs are understood and rework and misunderstandings are avoided.

Reverse Interview technique

Reverse Interview is a proactive questioning technique that uncovers real needs by asking "why":

Ask “why” instead of “what”

Incorrect way to ask a question：“What features do you need?”

How to ask the right question: "Why do you need this feature? What problem does it solve?"

By asking "why," understand the real motivations and business goals behind the need.

Ask "when" and "who"

  • • Use cases: "When will this feature be used? How often will it be used?"
  • • Target users: "Who will use this feature? What is their technical level?"
  • • Usage environment: "In what environment is it used? What are the limitations?"

Ask "what if..."

  • • Edge cases: "What would happen if this feature didn’t exist?"
  • • Exception handling: "What happens if the data is abnormal?"
  • • Scalability: "What happens if the requirements change?"

User story writing

A user story is the smallest unit of requirements and includes three elements: role, goal, and value:

User story template:

As [role],
I want [goal],
So that [value/reason].

Characteristics of a good user story

  • • Independence: Can be developed and tested independently
  • • Negotiable: Can be discussed and adjusted
  • • Valuable: Provides real value to users
  • • Estimable: Can estimate development time
  • • Small: can be completed in one iteration
  • • Testable: There are clear acceptance criteria

Acceptance criteria

Each user story should have clear acceptance criteria, using the Given-When-Then format:

Given: The user is logged in
When: the user clicks the "Create task" button
Then: display the task creation form
And: The user can enter a task title and description
And: Users can save tasks

Requirement prioritization

MoSCoW method

  • • Must have: a must-have, a key feature for project success
  • • Should have: Should exist; important but not critical
  • • Could have: It can be there; do it if time permits
  • • Won't have: If we don’t do it this time, we may do it later

Value-complexity matrix

Based on the value and complexity of features, prioritize developing high-value, low-complexity features.

Practical case: requirement clarification for an e-commerce platform

Initial requirements

"We need a shopping cart feature"

Reverse Interview process

  • Q: "Why is a shopping cart needed?" A: "Users need to be able to select multiple products at the same time"
  • Q: "When should it be used?" A: "When browsing products, add the ones you like to the cart"
  • Q: "Who will use it?" A: "All registered users"
  • Q: "What happens if the user is not logged in?" A: "They can add items to the cart, but they need to log in at checkout"

Clarified requirements

  • • Users can add products to the cart (logged in/not logged in)
  • • Users can view the items in the shopping cart
  • • Users can modify product quantities
  • • Users can delete products
  • • The cart for logged-out users is stored in local storage
  • • Merge the local cart and the server cart after login

Spec-driven development

Spec-driven development turns requirements into executable specifications, and AI can directly generate code based on the Spec, improving development efficiency and code quality.

PRD writing

PRD structure

  • • Product overview: Product positioning, target users, core value
  • • Functional requirements: Detailed feature descriptions and user stories
  • • Non-functional requirements: performance, availability, security, scalability
  • • User interface: Interface design and interaction flows
  • • Data model: Data structures and relationships
  • • Acceptance criteria: Functional acceptance, performance acceptance, security acceptance

PRD Writing Principles

  • • Clear and explicit: use clear language and avoid ambiguity
  • • Executable: AI can directly generate code based on the PRD
  • • Testable: each requirement has clear acceptance criteria
  • • Traceable: requirements can be traced back to business goals

API Spec (OpenAPI specification)

Advantages of the OpenAPI specification

  • • Standardization: Industry standard with robust tool support
  • • Executable: AI can directly generate code based on OpenAPI
  • • Testable: Can automatically generate API test cases
  • • Documentable: Automatically generate API documentation

API Spec example

openapi: 3.0.0
info:
  title: Task Management API
  version: 1.0.0
paths:
  /api/tasks:
    get:
      summary: Get task list
      parameters:
        - name: status
          in: query
          schema:
            type: string
            enum: [pending, in-progress, completed]
      responses:
        '200':
          description: Success
          content:
            application/json:
              schema:
                type: object
                properties:
                  tasks:
                    type: array
                    items:
                      $ref: '#/components/schemas/Task'
    post:
      summary: Create task
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/CreateTaskRequest'
      responses:
        '201':
          description: Created successfully
components:
  schemas:
    Task:
      type: object
      properties:
        id:
          type: string
        title:
          type: string
        status:
          type: string
          enum: [pending, in-progress, completed]

UI Spec

UI Spec content

  • • Page layout: page structure, component placement
  • • Component design: component types, styles, interactions
  • • Interaction flow: user operation flow, state changes
  • • Responsive design: Adaptation to different screen sizes

Tips for writing UI Specs

  • • Use Figma or similar tools to design interfaces
  • • Describe in detail the state and interactions of each component
  • • Use AI tools (such as v0) to generate code based on descriptions
  • • Provide design systems and component libraries

Practical case: complete flow from PRD to code

Step 1: Write the PRD

Define product goals, functional requirements, and non-functional requirements

Step 2: Write the API Spec

Use the OpenAPI specification to define API interfaces, and AI can generate API code based on the Spec

Step 3: Write the UI Spec

Describe the interface design in detail and use tools like v0 to generate UI code

Step 4: Use Cursor to generate code

Provide the PRD, API Spec, and UI Spec to Cursor Agent to generate complete code

Step 5: Testing and optimization

Write test cases based on the Spec to verify whether the functionality meets the Spec requirements

WBS decomposition

WBS (Work Breakdown Structure) breaks down large tasks into executable smaller tasks, clarifies dependencies between tasks, and facilitates project management and progress tracking.

Task decomposition principles

Granularity Control

  • • 2-4 hour rule: Each task should be completed within 2-4 hours
  • • Testability: Each task has clear acceptance criteria
  • • Independence: Minimize dependencies between tasks as much as possible
  • • Estimable: can accurately estimate completion time

Dependencies

  • • Identify dependencies: Clarify the dependencies between tasks
  • • Critical path: Identify the project's critical path and complete it first
  • • Parallel tasks: Identify tasks that can be executed in parallel
  • • Dependency management: Use tools (such as GitHub Projects) to manage dependencies

Time estimate

Three-point estimation

Estimation formula:(optimistic time + 4×most likely time + pessimistic time) / 6

Example: optimistic 2 hours, most likely 4 hours, pessimistic 8 hours → estimate = (2 + 4×4 + 8) / 6 = 4.3 hours

Analogy estimation

Refer to the completion time of similar tasks and adjust according to the complexity of the current task.

AI-assisted estimation

Use AI tools to analyze task complexity and combine historical data to estimate time.

Resource allocation

Staffing

  • • Assign tasks based on skills and experience
  • • Consider people’s workload
  • • Ensure backup personnel for critical tasks

Tool allocation

  • • Ensure there are sufficient development tools and resources
  • • Consider the tool’s license and cost
  • • Prepare a backup plan

Time allocation

  • • Consider the project deadline
  • • Reserve buffer time to handle risks
  • • Balance parallel tasks and serial tasks

Practical case: WBS decomposition example

1. Project preparation (4 hours)
1.1 Environment Setup (2 hours)
1.2 Project initialization (2 hours)
2. Database design (6 hours)
2.1 Data model design (3 hours)
2.2 Database table creation (2 hours)
2.3 Data migration script (1 hour)
3. Backend API Development (16 hours)
3.1 User authentication API (4 hours, depends on 2.1)
3.2 Task CRUD API (8 hours, depends on 2.1)
3.3 Data statistics API (4 hours, depends on 2.1)
4. Front-end UI development (12 hours)
4.1 Login page (2 hours)
4.2 Task list page (4 hours, depends on 3.2)
4.3 Task details page (3 hours, depends on 3.2)
4.4 Data Statistics Page (3 hours, depends on 3.3)
5. Testing and deployment (8 hours)
5.1 Unit testing (4 hours)
5.2 Integration Testing (2 hours)
5.3 Deployment (2 hours)

Critical path: 1 → 2.1 → 3.2 → 4.2 → 5 (total duration about 34 hours)

DoD definition

DoD (Definition of Done) defines the criteria for task completion, ensuring delivery quality and avoiding situations where something “looks done but is not actually done.”

Quality Standards

Code quality

  • • Pass ESLint checks, with no major warnings
  • • The code complies with team standards
  • • Code has passed code review
  • • No known bugs

Test coverage

  • • Unit test coverage >80%
  • • Key features have integration tests
  • • All tests passed
  • • Test code quality meets the standard

Documentation is complete

  • • API documentation is complete
  • • Code comments are sufficient
  • • User manual updates
  • • Changelog updates

Performance metrics

  • • Page load time <2 seconds
  • • API response time <500ms
  • • Database query optimization
  • • No memory leaks

Acceptance criteria

Feature acceptance

  • • Implement all features according to the Spec
  • • User story acceptance criteria are met
  • • Edge case handling is correct
  • • Robust error handling

Performance acceptance testing

  • • Performance metrics meet requirements
  • • Load test passed
  • • Passed stress test
  • • Performance monitoring is normal

Security acceptance testing

  • • Through security scanning
  • • No critical vulnerabilities
  • • Data encryption is correct
  • • Correct permission control

Practical case: DoD checklist

Code has been committed to Git and passed CI/CD checks
The code has passed ESLint checks, with no serious warnings
Unit test coverage >80%, all tests passed
The code has passed code review, and review comments have been addressed
The feature has been tested and meets the acceptance criteria
Performance tests passed, metrics met the targets
Security scan passed, no critical vulnerabilities
The documentation has been updated, and the API documentation and user manual are complete
Deployed to the test environment, UAT passed
Passed product manager acceptance, ready to release

Learning outcomes

After completing this chapter, you will:

  • 1Master requirement clarification methodologies (Reverse Interview, user stories, prioritization) and be able to uncover real needs
  • 2Understand the engineering practices of Spec-driven development and be able to write clear PRDs, API Specs, and UI Specs
  • 3Master the WBS decomposition method and be able to reasonably split tasks, estimate time, and allocate resources
  • 4Understand DoD quality standards, define acceptance criteria, and ensure delivery quality
  • 5Possesses enterprise-level project management and quality control capabilities, ensuring successful project delivery
Previous chapter: Core skills: AI Agent developmentNext chapter: Core skills: tools and efficiency