Module: Requirements

Functional Requirements

System Design Fundamentals: Requirements - Functional Requirements

This document outlines the process of defining Functional Requirements as part of the overall System Design process. It builds upon the initial Requirements gathering phase.

I. Understanding the Context: From Requirements to Functional Requirements

  • Requirements (Overall): Broad statements of what a system should do. They capture the needs of stakeholders. These can be categorized as:

    • Business Requirements: High-level goals of the organization. (e.g., "Increase customer engagement")
    • User Requirements: What users need to do with the system. (e.g., "A user should be able to search for products.")
    • Functional Requirements: Detailed descriptions of how the system will fulfill user and business requirements. This is our focus.
    • Non-Functional Requirements: Qualities of the system (performance, security, scalability, etc.). These constrain how the system is built.
  • Functional Requirements (FRs): Describe specific behaviors or functions the system must perform. They define what the system does, not how it does it (that's design). They are often expressed as "The system shall..." statements.

II. Characteristics of Good Functional Requirements

  • Complete: Covers all necessary functions.
  • Correct: Accurately reflects stakeholder needs.
  • Consistent: No conflicting requirements.
  • Unambiguous: Clear and understandable to all stakeholders. Avoid vague terms like "easily" or "user-friendly."
  • Verifiable: Testable. You should be able to determine if the requirement has been met.
  • Traceable: Linked back to the original business or user requirements.
  • Prioritized: Ranked based on importance (e.g., Must-have, Should-have, Could-have, Won't-have).

III. Techniques for Eliciting Functional Requirements

  • User Stories: (Agile methodology) "As a [user role], I want to [goal] so that [benefit]." Example: "As a customer, I want to be able to add items to a shopping cart so that I can purchase multiple items at once."
  • Use Cases: Detailed descriptions of how a user interacts with the system to achieve a specific goal. Includes actors, preconditions, main success scenario, and alternative flows.
  • Interviews: Directly asking stakeholders about their needs.
  • Workshops: Collaborative sessions with stakeholders to brainstorm and define requirements.
  • Prototyping: Creating a basic version of the system to get feedback.
  • Document Analysis: Reviewing existing documentation (e.g., business processes, reports) to identify requirements.

IV. Example: Online Shopping System - Functional Requirements

Let's consider a simplified online shopping system. Here's how we might define some FRs:

A. User Account Management

  • FR-UAM-001: The system shall allow users to register for a new account, providing a unique email address, password, and other required information (e.g., name, address).
  • FR-UAM-002: The system shall allow registered users to log in using their email address and password.
  • FR-UAM-003: The system shall allow users to reset their password via email if they forget it.
  • FR-UAM-004: The system shall allow users to update their profile information (e.g., address, phone number).

B. Product Catalog & Search

  • FR-PC-001: The system shall display a catalog of products, categorized by type.
  • FR-PC-002: The system shall allow users to search for products by keyword.
  • FR-PC-003: The system shall display product details, including name, description, price, and images.
  • FR-PC-004: The system shall allow users to filter products by price range, category, and other relevant attributes.

C. Shopping Cart & Checkout

  • FR-SCC-001: The system shall allow users to add products to a shopping cart.
  • FR-SCC-002: The system shall allow users to view the contents of their shopping cart.
  • FR-SCC-003: The system shall allow users to update the quantity of items in their shopping cart.
  • FR-SCC-004: The system shall allow users to remove items from their shopping cart.
  • FR-SCC-005: The system shall calculate the total cost of the items in the shopping cart, including taxes and shipping.
  • FR-SCC-006: The system shall allow users to proceed to checkout.

D. Order Management

  • FR-OM-001: The system shall allow users to enter their shipping address and payment information during checkout.
  • FR-OM-002: The system shall process payments securely. (Note: This is a high-level FR; security details are often in Non-Functional Requirements)
  • FR-OM-003: The system shall generate an order confirmation email to the user.
  • FR-OM-004: The system shall store order history for each user.
  • FR-OM-005: The system shall allow administrators to view and manage all orders.

V. Tools for Managing Functional Requirements

  • Requirement Management Tools: Jira, Azure DevOps, Jama Connect, ReqView
  • Spreadsheets: (Simple projects) Excel, Google Sheets
  • Document Editors: Microsoft Word, Google Docs (for more narrative use cases)

VI. Key Considerations

  • Granularity: Find the right level of detail. Too granular can be overwhelming; too high-level can be ambiguous.
  • Iteration: Requirements are rarely perfect on the first try. Expect to refine them as you learn more.
  • Collaboration: Involve all stakeholders in the requirements process.
  • Prioritization: Focus on the most important requirements first.

This provides a foundational understanding of Functional Requirements in system design. Remember to tailor these principles to the specific needs of your project.