Skip to main content

Project Requirements

Introduction​

Effective project planning starts with understanding what the user wants. This includes:

  • Engaging stakeholders early and often
  • Asking targeted questions
  • Identifying constraints, goals, and priorities

Two Types of Requirements​

  1. Functional Requirements These describe WHAT the system should do.

    • Examples:
      • The system shall allow users to log in.
      • The application should send an email when a user registers.

  2. Non-Functional Requirements These describe HOW the system performs.

    • Examples:
      • The application must respond within 2 seconds.
      • The system should support 1000 concurrent users.

Software Requirements Specification (SRS)​

An SRS document serves as a contract between stakeholders and developers.

Typical SRS sections:

  • Introduction
  • Functional Requirements
  • Non-Functional Requirements
  • System Features
  • Use Case Descriptions
  • External Interfaces

More details: How to Write an SRS

Use Case Diagrams​

Use case diagrams help visualize interactions between users and systems.

  • Actors: Users or other systems
  • Use Cases: Tasks or goals the system enables
  • Relationships: Associations between actors and use cases

Use case diagrams highlight how features are expected to be used from a user's perspective.

Example:

What is a Use Case?​

A use case describes:

  • Preconditions: What must be true before it begins
  • Normal flow: Step-by-step interaction
  • Alternate flows: What happens when things go wrong
  • Postconditions: What must be true afterward

Use cases are effective tools for understanding both user expectations and system behavior.

Question: Can you determine at least 4 use cases in the example above. Do any of them have a pre-conditions? Are there any dependencies between the use cases?

User Stories​

In Agile, requirements are captured as user stories. A user story answers:

  • What: Description of the feature
  • Who: The user who will benefit
  • Why: The value it delivers

Format:

As a [role], I want [goal], so that [reason].

Example:

As a student, I want to create a secure password so that my personal information remains secure.

Acceptance Criteria​

Defines when a story is complete.

Example Acceptance Criteria for the example user story above:

  • Minimum 8 characters
  • Includes lowercase, uppercase, numbers, special characters
  • No repeated letters

More info:

Epic vs. User Story​

  • Epic: Large user need broken into smaller stories
    • Example: As a host, I want to make Thanksgiving dinner so my guests think I’m a good cook.
  • User Stories from Epic:
    • As a host, I want to bake a pie, so guests have dessert.
    • As a host, I want to set the table, so guests have a place to eat.

Types of Backlogs​

Product Backlog​

A product backlog is an ordered list of all the work that needs to be done on a product. It includes features, enhancements, bug fixes, technical work, and knowledge acquisition necessary for product development. The backlog is dynamic, constantly evolving based on customer feedback, market changes, and team insights.

Key Characteristics​

  • Prioritized by value, risk, and effort
  • Owned by the Product Owner
  • Refined regularly (backlog grooming)
  • Items are usually written as user stories

In Agile, the product backlog serves as the single source of truth for the development team about what to build next.

Sprint Backlog​

The sprint backlog is a detailed and time-bound subset of the product backlog that the development team selects during a sprint planning meeting. It includes the specific user stories, tasks, or backlog items that the team commits to completing within the current sprint (typically a 1–4 week iteration). In addition to listing the items, the sprint backlog also outlines the team’s plan for how to implement and track progress on each item.

Key Characteristics​

  • Represents the team’s commitment to deliver specific work during the sprint.
  • Contains work planned for a single sprint, typically 1–4 weeks.
  • Only the development team manages and updates it.
  • Tasks may be broken down or updated, but scope changes require team agreement.
  • Items are decomposed into tasks that can be acted on immediately.
  • Supports tracking through daily stand-ups and visual tools like task boards.
  • All items should directly contribute to achieving the sprint objective.

User Story Points​

Points are assigned to stories based on:

  • The amount of work to do
  • The complexity of the work
  • Risk or uncertainty in doing the work
  • Time / Duration

Techniques like Planning Poker help assign points collaboratively.

Reference: Atlassian on Planning Poker

Velocity​

Measures how many story points a team delivers per sprint.

More details: Scrum.org - Velocity

Burndown Chart​

Tracks remaining work over time to monitor sprint progress.

Real-time visualization of team velocity and goal tracking.

More info: Burndown Basics

User Interfaces and User Stories​

UI wireframes should complement your user stories but not dictate implementation.

Example User Story with Scenario:

As a user, I want to be able to log into the system so that I can use it.

Scenario:
Given a logged-out user
And the user provides login credentials
When they are authenticated
Then they see their homepage

Tools: Microsoft TFS vs. Jira​

Disclaimer: Generative AI was used in part to generate these lecture notes.