From Problem to Requirements: Defining System Needs

Introduction

In our last lesson, we explored First Principles Thinking as a method for deconstructing complex business problems down to their fundamental truths. We established the crucial Why -> What -> How workflow, emphasizing the need to understand the business purpose ("Why") before defining what needs to be built.

This lesson builds directly upon that foundation. We will focus on the process of translating the "Why" into a detailed and actionable blueprint for the "How." You will learn to translate a high-level business problem into a precise set of functional and non-functional requirements. This is the critical bridge between a business idea and a technical design, and mastering this translation is a non-negotiable skill for any developer aspiring to an architectural or leadership role. By the end of this lesson, you will be able to methodically define what a system must do and how well it must do it.

1. The Hierarchy of Requirements

Before diving into the specifics, it's important to understand that "requirements" are not a monolithic concept. They exist at different levels of abstraction, flowing from high-level business goals down to detailed technical specifications.

As you can see, the process starts at the top with the broadest context and becomes progressively more detailed:

• Business Requirements: This is the "Why" we discussed in the last lesson. It defines the high-level goal the business wants to achieve, such as "increase customer retention by 20%" or "reduce operational costs in the logistics department."
• User Requirements: These describe what users need to be able to do to help achieve the business goals. They are often expressed as user stories or use cases, focusing on user goals and interactions (e.g., "As a customer, I want to track my order in real-time").
• System Requirements: This is where we, as engineers, live. These are the detailed specifications derived from the user requirements. They are broken down into two essential categories that will be the focus of our lesson: functional and non-functional requirements.

2. Functional vs. Non-Functional Requirements: The "What" vs. The "How Well"

To build a successful system, you need to know not only what it should do, but also how well it should do it. This is the fundamental distinction between functional and non-functional requirements.

Let's start with a foundational reading and a video walkthrough to solidify these definitions.

Now, let's reinforce these concepts with a video that walks through the same ideas using a familiar example: an e-commerce platform like Amazon.

To bring it all together, here is a helpful summary of the key differences.

As a developer, you've spent most of your time implementing functional requirements—building the features. The leap to a senior role involves taking ownership of the non-functional requirements, as they have a profound impact on system architecture, technology choices, and ultimately, user satisfaction. A feature that is slow, insecure, or constantly unavailable is a failed feature, regardless of how well it's coded.

3. The Translation Process in Practice

Now that we have the definitions, how do we perform the translation from a vague business problem to a concrete list of requirements? We'll use the Why -> What -> How framework, which the Troy Martin video from our previous lesson explains perfectly.

This workflow gives us our process. Here are the steps you can follow for any new project or feature:

Step 1: Clarify the Business Goal (The "Why")
Start by understanding the core business objective. This is the first-principles thinking we covered before. What is the ultimate goal? Is it to increase revenue, improve user engagement, or reduce operational costs?

Step 2: Gather User Needs and Business Constraints (The "What")
With the "Why" established, you need to talk to stakeholders—product managers, end-users, business leaders—to understand their needs and constraints. This is where you elicit the raw material for your requirements.

Step 3: Draft Functional and Non-Functional Requirements
This is the core translation step. You will synthesize the information gathered into formal statements.

Let's use an example.

• Business Problem (Why): A subscription-based online magazine is losing subscribers due to low engagement. The business goal is to "Increase monthly active users by 15% in the next quarter."
• User Need (What): A product manager tells you, "Users are complaining that they can't find content relevant to their interests. As a reader, I want to easily discover articles I'll enjoy without having to search."

From this, you can derive the following requirements:

Functional Requirements (What the system will do):

• FR1: The system shall display a "Recommended for You" section on the user's home page.
• FR2: This section shall contain a list of 5 articles.
• FR3: The recommendations shall be generated based on the user's previously read articles.
• FR4: A user shall be able to click on a recommended article to navigate to it.

Non-Functional Requirements (How well the system will do it):

• Performance: The "Recommended for You" section must load in under 400 milliseconds.
• Availability: The recommendation service must maintain 99.9% uptime.
• Scalability: The system must handle recommendation generation for 100,000 concurrent users.
• Privacy: A user's reading history and generated recommendations must not be visible to any other user.
• Maintainability: The recommendation algorithm should be implemented as a separate microservice to allow for independent updates.

Notice how the functional requirements define the feature, while the non-functional requirements dictate the architectural choices needed to make that feature successful (e.g., caching for performance, microservices for maintainability, robust data protection for privacy).

4. Documenting Requirements in a Technical Specification

Once you have defined your requirements, they must be documented. A well-written Technical Specification (or Tech Spec) is the canonical source of truth for a project. It ensures alignment across the team and serves as a reference throughout the development lifecycle. This aligns directly with your goal of improving asynchronous communication and creating "paper trails of competence."

The section on "Goals or Product and Technical Requirements" is precisely where the functional and non-functional requirements you've just defined would live. The "Non-Goals" section is equally important for preventing scope creep by explicitly stating what you are not building.

Conclusion

In this lesson, you've moved from the abstract "Why" of a business problem to the concrete "What" and "How Well" of system design. You now have a structured process for translating business needs into the language of engineering.

Key Takeaways:

• Requirements exist in a hierarchy: Business -> User -> System.
• Functional Requirements define what a system does (its features).
• Non-Functional Requirements (NFRs) define how well it performs (its quality attributes like performance, security, and scalability). NFRs are what drive major architectural decisions.
• The translation process follows a clear path: understand the business goal, gather user needs, and then formally draft and document both functional and non-functional requirements.
• A Technical Specification document is the professional standard for recording these requirements and aligning your team.

You are now equipped to define the problem with precision. In our next lesson, "Propose a high-level architectural approach that satisfies a given set of business requirements," we will take these well-defined requirements and start designing the solution.