Requirements: Defining Your Future State

With your business case approved, it's time to specify exactly what you need. Requirements define the future state—what the improved process must do and what characteristics it must have.

What Are Requirements?

Requirements describe what a solution must accomplish. They bridge the gap between "we need to improve" and "here's what we're building."

Good requirements:

• Describe needs, not solutions
• Are testable - you can verify they're met
• Are complete - nothing essential is missing
• Are consistent - they don't contradict each other
• Are traceable - linked to business needs

Types of Requirements

Functional Requirements

What the system or process must DO.

Functional requirements describe capabilities, features, and behaviors.

Examples:

• The system must calculate order totals including tax and shipping
• Supervisors must approve purchases over $5,000
• The process must route international orders to the export compliance team
• Users must be able to search orders by customer name, date, or order number

Non-Functional Requirements

What the system or process must BE.

Non-functional requirements describe qualities, constraints, and characteristics.

Business Rules

Constraints and policies that govern decisions.

Business rules capture the logic that drives process behavior:

User Stories

User stories are a popular format for expressing requirements, especially in agile environments.

The Classic Format

As a [role], I want to [action] so that [benefit].

This format captures:

• Who needs it (role)
• What they need (action)
• Why they need it (benefit)

Examples

As a customer service representative, I want to see the customer's complete order history so that I can answer questions without transferring the call.

As a warehouse supervisor, I want to receive alerts when inventory falls below minimum levels so that I can reorder before stockouts occur.

As a finance manager, I want to approve expense reports on my mobile device so that processing isn't delayed when I'm traveling.

INVEST Criteria

Good user stories are:

Story Hierarchy

Large initiatives break down into smaller pieces:

Acceptance Criteria

Every requirement needs clear criteria for verification. Acceptance criteria answer: "How will we know this is complete?"

Format Options

Checklist style:

Story: As a customer, I want to track my order status

Acceptance Criteria:
- [ ] Customer can view current order status
- [ ] Status updates within 1 hour of shipment scan
- [ ] Tracking number links to carrier website
- [ ] Mobile-friendly display
- [ ] Works for all supported carriers

Given-When-Then (BDD style):

Scenario: Customer views shipped order

Given the customer has a shipped order
When they view the order details
Then they see:
  - Current status "Shipped"
  - Carrier name
  - Tracking number (clickable link)
  - Estimated delivery date

Requirements Traceability

Requirements don't exist in isolation. They connect to business needs upstream and design/testing downstream.

Requirements Traceability Matrix (RTM)

Why Traceability Matters

Forward tracing ensures: Every business need has requirements, design, and tests

Backward tracing answers: "Why does this test exist? What requirement does it verify? What business need does that support?"

Gathering Requirements

Techniques

Questions That Uncover Requirements

• "Walk me through what you do when..."
• "What information do you need to make this decision?"
• "What's the worst thing that could happen if..."
• "How would you know if this was working well?"
• "What do you wish you could do that you can't today?"

Common Requirement Gaps

Commonly missed: Exception handling ("what happens when things go wrong?") and interfaces ("how does this connect to other systems?")

Requirements Documentation

Levels of Detail

Keep It Accessible

Requirements documents should be:

• Living - Updated as understanding evolves
• Searchable - Easy to find specific requirements
• Versioned - Track what changed when
• Shared - Available to all who need them

Real-World Requirements Example

Process: Employee Expense Reimbursement

Functional Requirements:

Non-Functional Requirements:

Business Rules:

Sample User Story:

As an employee, I want to photograph receipts with my phone so that I can submit expenses immediately without keeping paper.

Acceptance Criteria:

• Camera captures receipt within app
• Image quality sufficient to read details
• OCR extracts vendor, date, amount (editable by user)
• Image stored as expense attachment

Requirements Pitfalls

Solution Masquerading as Requirement

Bad: "The system must use Oracle database" Good: "The system must store 5 years of transaction history with sub-second query response"

Vague Requirements

Bad: "The system must be fast" Good: "Search results display within 2 seconds for queries returning up to 1,000 records"

Gold-Plating

Adding requirements that sound nice but aren't needed. Every requirement has a cost—include only what delivers value.

Assumed Requirements

Things stakeholders assume are obvious but never state. Ask explicitly about security, error handling, reporting, and integrations.

Requirements Checklist

Before finalizing, verify:

• All stakeholder groups have provided input
• Functional requirements describe what, not how
• Non-functional requirements are measurable
• Business rules are documented
• Acceptance criteria exist for each requirement
• Requirements trace to business needs
• Exceptions and errors are addressed
• Interfaces and integrations are specified
• Requirements are prioritized
• Stakeholders have reviewed and approved