Requirements Gathering for SaaS: Identifying Core Entities

Previously in this course, we explored the introduction to database design, establishing why a well-planned schema is the backbone of any application. Now that you understand the "why," it is time to tackle the "what."

In this lesson, we move from high-level concepts to practical execution. We will learn how to perform requirements gathering for a SaaS product by dissecting a business brief to isolate the nouns that will eventually become your database tables.

From Business Brief to Data Model

When you receive a project request, it rarely arrives in a developer-friendly format. It usually comes as a stream of consciousness from a product manager or stakeholder. Your job as a data architect is to strip away the "fluff" and identify the core entities—the "things" your database needs to track.

Objects vs. Actions

The most common mistake beginners make is confusing entities with actions.

• Entities (Nouns): These are the permanent or semi-permanent things in your system that exist independently (e.g., User, Invoice, Subscription).
• Actions (Verbs): These are the things that happen to or between entities (e.g., "User logs in," "System sends email," "Customer upgrades plan").

If you treat an action as an entity, you end up with a bloated, confusing database. If you miss an entity, you’ll find yourself scrambling to add tables halfway through development.

Worked Example: The SaaS Project Brief

Let’s look at a hypothetical brief for a SaaS product called "TaskFlow":

"We need a platform where a User can sign up and create a Workspace. Within that workspace, the user can create Tasks and assign them to other team members. Users should be able to subscribe to a Plan (Basic or Pro) to unlock more storage. The system must also track Payments for each subscription."

Step 1: Identify the Nouns

Let's highlight the potential entities:

1. User (A person using the system)
2. Workspace (A container for work)
3. Task (The unit of work)
4. Plan (The tier of service)
5. Payment (The financial record)

Step 2: Filter for Entities vs. Actions

Are these all entities?

• "Sign up": This is an action. We don't need a "Sign up" table; we need a "User" table that stores information about the user.
• "Assign": This is an action. It describes a relationship between a User and a Task. We will handle this later in the course when we discuss relationships.
• "Unlock": This is a logic-based action, not a data entity.

Our core entity list remains: User, Workspace, Task, Plan, Payment.

Hands-on Exercise

Read the following requirement for an extension to our "TaskFlow" app:

"The system should allow users to upload Attachments to tasks. We also need a Notification log that records when a task is updated or a deadline is approaching."

Your Task:

1. List the potential entities in this snippet.
2. Are "upload" and "updated" entities? Why or why not?

Self-Correction: If you identified "Attachment" as an entity, you are correct. If you flagged "Notification" as an entity, you are also correct. If you thought "upload" or "updated" were entities, remember: if you can't describe it as a physical or conceptual "thing" that needs its own row in a table, it’s likely an action or a property of an entity.

Common Pitfalls in Requirements Gathering

• Over-modeling: Don't create an entity for everything. If a piece of data is just a simple status (e.g., "Task status: Pending/Complete"), it belongs as a column (attribute) inside the Task table, not as a standalone Status table.
• Ignoring the "Who": Always ensure your entities can be linked back to a user or an account. If you have an entity that exists in a vacuum, you might have forgotten to define its ownership.
• Confusing Attributes with Entities: A "Username" is not an entity; it is an attribute of the User entity. Distinguishing between the "thing" and the "characteristic of the thing" is crucial for clean design.

FAQ

Q: How do I know when a noun should be an entity or just a column? A: If the item has multiple pieces of information associated with it (e.g., a "User" has an email, password, and join date), it’s an entity. If it’s just a single descriptive label, it’s likely an attribute.

Q: Should I include every potential requirement in my first draft? A: No. Focus on the core entities first. You can always add more tables later, but starting with a massive, over-engineered schema makes it harder to identify the critical relationships.

Recap

Requirements gathering is the act of turning conversational business needs into a structured set of entities. By separating nouns (entities) from verbs (actions), you create a clean map for your database. We’ve identified our core SaaS entities for the TaskFlow project: User, Workspace, Task, Plan, and Payment.

Up next, we will take these entities and begin defining their specific attributes to flesh out our schema.