Defining System Requirements for Scalable Software Architecture

Welcome to the "System Design Fundamentals" course. We are starting our journey by establishing the "why" and "what" of our project before we ever touch a line of code.

In software engineering, the most common cause of project failure isn't a lack of coding skill; it’s a lack of clarity. When you build a system without firm requirements and scoping, you end up with "scope creep" or, worse, a system that doesn't actually solve the problem it was intended to fix.

The Anatomy of Requirements

Requirements are the constraints and capabilities that define your system. We categorize them into two main buckets:

1. Functional Requirements: What the system does. These are the features.
2. Non-Functional Requirements (NFRs): How the system behaves. These are the "quality attributes" like speed, reliability, and security.

Think of it this way: "The system shall allow users to upload photos" is a functional requirement. "The system shall complete the upload in under 200ms" is a non-functional requirement.

Writing Functional Requirements

Functional requirements should be specific and measurable. Use the "User-Action-Outcome" structure to keep them clear.

Example for our course project: We are building a URL Shortening service (like bit.ly).

• FR1: A user can input a long URL and receive a shortened alias.
• FR2: When a user visits the shortened alias, the system redirects them to the original long URL.
• FR3: The system shall track the number of times each link is clicked.

Pro-tip: Avoid fluff. Don't say "The system should be user-friendly." Say "The system shall allow link creation in under two clicks."

Defining Non-Functional Requirements

NFRs are where the architecture gets serious. If you ignore these, your system might work fine with one user, but collapse under the weight of one thousand.

Creating Your Project Scope Document

Your scope document defines the boundaries of your work. It tells stakeholders what you are building and, just as importantly, what you are not building.

The Project Scope Template:

1. Problem Statement: One sentence describing the pain point.
2. In-Scope: The core features (e.g., URL shortening, redirection, click analytics).
3. Out-of-Scope: Features we are explicitly deferring (e.g., user accounts, paid subscriptions, custom alias branding).
4. Success Metrics: How we measure success (e.g., "100k requests per day with <200ms latency").

Hands-on Exercise

For our running project, write a simple scope document for a System Monitoring Dashboard.

1. List three functional requirements for this dashboard.
2. Define two non-functional requirements (e.g., latency for data retrieval, data retention period).
3. Write one "Out-of-Scope" item to prevent feature creep.

Common Pitfalls

• The "Everything" Problem: Trying to build too much at once. If you don't define "Out-of-Scope," you will never finish.
• Vague NFRs: Saying "the system must be fast" is useless. "The system must respond in under 200ms" is a requirement you can test against.
• Ignoring Constraints: Sometimes the business has a hard budget or a deadline. These are requirements too!

Frequently Asked Questions (FAQ)

Q: Can non-functional requirements change? A: Yes. As you learn more about your infrastructure, you might realize 99.99% availability is too expensive. You may adjust to 99.9%. Always document why you changed them.

Q: Do I need a formal document for small projects? A: Even a single page or a GitHub issue template counts as a document. The act of writing it down forces you to think through the logic.

Recap

We have defined the foundation of our design. By separating functional requirements (what it does) from non-functional requirements (how it performs), we can now begin to sketch out the high-level architecture. Remember: clear scoping is the difference between a prototype and a production-ready system.

Up next: High-Level Architecture Diagramming