Requirements gathering
The following information is from this course
Types of requirements
To ensure you deliver value, you must understand needs and translate them into system requirements before you begin writing code or provisioning cloud resources.
There are three distinct types of requirements:
Business Requirements: These define the high-level goals of the company, such as increasing the user base or growing revenue.
Stakeholder Requirements: These are the specific needs of individuals within the organization that allow them to perform their jobs effectively.
System Requirements: These are defined by engineers to describe exactly what the system must do to satisfy the business and stakeholder requirements mentioned above.
Functional Requirements
Non-functional Requirements
1. Functional Requirements (The "What")
These requirements describe the specific behaviors and functions of the system.
Definition: They describe "what the system must be able to do to meet the needs of stakeholders".
Origin: You arrive at these by directly translating the stakeholder needs you gathered earlier.
Examples:
provide regular updates to a database
alert a user about an anomaly in the data
2. Non-Functional Requirements (The "How")
These requirements describe the quality attributes and technical constraints of the system.
Definition: They are the "technical specifications of how the system will do what it needs to do".
Role in Development: These requirements are critical when choosing your tech stack, as you must identify tools and technologies specifically capable of meeting these non-functional constraints (such as speed, scale, or security).
Examples:
technical specifications of an ingestion or orchestration or storage approach
how you'll meet the end user's needs
Translate stakeholder needs into specific requirements
Here's an approach for translating stakeholder conversations into specific data system requirements.
Key Elements of Requirements Gathering
To effectively extract requirements, you should follow four main steps:
Analyze Existing Systems: Learn what solutions are currently in place and identify their specific pain points.
Identify Planned Actions: Ask stakeholders exactly what actions they intend to take based on the data you serve them.
Confirm Understanding: Repeat what you have learned back to the stakeholder to ensure accuracy.
Expand the Network: Identify other stakeholders you need to interview if gaps in information remain.
Translating Pain Points into Requirements
By analyzing the Data Scientist's complaints, the engineer can derive specific system needs:
Source System Issues: If the stakeholder mentioned using suboptimal daily data dumps to avoid crashing the production database. This indicates a need to coordinate with Software Engineers (source owners) to build a safe ingestion solution and establish notifications for schema changes.
Automation Needs: The stakeholder described data cleaning as "cumbersome," which translates to a functional requirement that the system must automate ingestion and transformation.
The "Action" Tactic: Clarifying Ambiguity
Stakeholders often misidentify their own needs or use technical terms loosely.
The "Real-Time" Trap: Users may request "real-time" data when they actually only need daily or even monthly reports.
Focus on Action: Instead of accepting a request for "real-time" at face value, you must ask what action they plan to take with the data.
Example:
Recommender System: If the action is serving recommendations to customers browsing a site, the requirement is genuinely sub-second latency.
Dashboards: If the action is making campaign decisions, the definition of "real-time" is unclear, necessitating a follow-up conversation with the marketing team to define the actual non-functional requirements.
Last updated