Digging Deeper: Finding the Requirements That Truly Matter
I'm a fullstack developer and my stack is includes .net, angular, reactjs, mondodb and mssql
I currently work in a little tourism company, I'm not only a developer but I manage a team and customers.
I love learning new things and I like the continuous comparison with other people on ideas.
In the world of software development, everyone talks about requirements. But not all requirements are created equal. For the Software Architect, the real job is not to collect a long list of features, but to dig deep to identify the few, crucial Architecturally Significant Requirements (ASRs).
These are not the obvious requirements (like "the system must allow login"), but they are the hidden gems that dictate the form, structure, and fundamental trade-offs of the entire system. A system fails when these critical requirements are ignored or misunderstood.
The Difference Between Function and Architecture
Most projects start with functional requirements: what the system must do for the user (e.g., register an order, view a report). These are important, but they rarely determine the architecture.
ASRs are composed of three main elements that, when combined, define the true design challenge:
Non-Functional Requirements (NFRs): The quality of the system (e.g., scalability, security, performance, maintainability).
Constraints: Fixed limitations (e.g., budget, time, legacy technology, legal regulations like GDPR).
Business Priorities: Strategic objectives that define the urgency of one NFR over another (e.g., if time-to-market beats extreme security in an initial phase).
Reflection: I have learned that the art of the architect is to transform a generic statement ("The system must be fast") into a measurable Quality Scenario: "When 10,000 concurrent users submit search requests, the system must respond within 200 milliseconds in 95% of cases." Only then does the requirement become an architectural guide, not a vague hope.
Digging Techniques: The Architect's Questions
To bring ASRs to light, we must adopt an investigative approach:
Ask "Why" Five Times: Similar to the Toyota method, never accept a requirement at the first level. If a stakeholder asks, "We need to use Kafka," ask "Why?" (Because we need asynchronous messaging.) "Why do we need asynchronous messaging?" (Because we need to handle peaks of 10,000 transactions per minute.) At this point, scalability and resilience become ASRs.
Work on Stress Points: Identify the most extreme or critical scenarios. What happens in case of failure (resilience)? What happens with 100x the peak load (scalability)? What happens if a malicious person tries to access data (security)?
Identify Inviolable Constraints: Ask directly: "What are the three things we absolutely cannot change (legacy technology, maximum budget) and the three things that must be guaranteed (legal regulation X, certification Y)?"
Practical Example: A Fashion E-commerce System
A business team requests a new e-commerce system. The functional requirements are clear: catalog, cart, checkout. But what are the ASRs?
| Initial Requirement / Concern | Architect's Excavation (The "Why") | Architecturally Significant Requirement (ASR) |
| Business: "Collections change every 3 months." | Why is this important? "We need to rapidly launch and retire products and bundles without site downtime." | ASR (Agility/Deploy): The system must support Zero-Downtime Deployment and a catalog schema change (new attributes) in less than 1 hour. |
| Operations: "We want to sell during Black Friday too." | What is the volume? "We expect a peak of 15,000 orders per hour for 8 consecutive hours." | ASR (Scalability/Resilience): The checkout and inventory management pipeline must be isolated and scale autonomously to handle at least 5 transactions/second with latency below 300ms. |
| Legal: "New European privacy laws must be complied with." | What are the consequences if we don't? (High penalties). How do we handle them? (Anonymization, right to be forgotten). | ASR (Security/Compliance): Mandatory implementation of encryption at rest for all PII (Personally Identifiable Information) and creation of an isolated account management service that supports complete user deletion within 24 hours of request. |
Without digging, one risks building a standard e-commerce site and failing miserably during the first Black Friday or the first legal compliance request. Clearly identifying and documenting ASRs is the contract between the architect and the success of the project. It is what justifies difficult decisions, such as choosing a complex microservices architecture to ensure isolation of scalability, or spending more on a security solution that meets regulatory requirements. Effective design is rooted in the reality of critical requirements.
