A stakeholder asks for a complete requirements specification with a full traceability matrix before any design work starts, on a product that's expected to pivot significantly based on early user feedback. As the architect, when do you push back on that level of upfront requirements analysis, and what do you propose instead?

## Rigor scales with two factors The amount of upfront requirements analysis an architecture should carry is not a fixed best practice, it's a variable that should scale with two factors: 1. how volatile the requirements are likely to be 2. how expensive a wrong or missing requirement is to fix later A full, heavyweight specification with an exhaustively maintained traceability matrix is the right tool when volatility is low and the cost of error is high, such as a payments-clearing system subject to regulatory audit, an aerospace control system, or a fixed-price government contract with a defined scope. It is close to the wrong tool when volatility is high and the cost of a wrong guess about the details is low, such as an early-stage product where the team explicitly expects to learn from real users and change direction, where writing an exhaustive functional specification today just means writing a very detailed description of something that will likely be substantially rewritten in three months. The judgment call a principal-level architect has to make is recognizing which regime a given project is actually in, and pushing back when a stakeholder's request for process, a full spec, a full matrix, before any design starts, doesn't match that regime, not because process is bad, but because it's being applied at the wrong point on the volatility-versus-cost curve. ## The two-tier split The mechanism for pushing back productively, rather than just refusing, is to decompose the requirement set into two tiers instead of treating 'requirements analysis' as one monolithic activity. **The first tier** is what's genuinely expensive to get wrong or retrofit later regardless of how the product pivots: - constraints such as regulatory, data-residency, or mandated integrations - core non-functional requirements that shape the architecture's skeleton such as security posture, availability targets, and data model boundaries that affect auditability or multi-tenancy - the handful of functional capabilities so central to the product's identity that a pivot away from them would essentially be a different product These deserve real upfront rigor, interviews, explicit documentation, and yes, traceability where compliance is in play, precisely because a mistake here is architecture-level, not feature-level. **The second tier** is the bulk of ordinary functional requirements, specific screens, workflows, and feature details that are exactly what the team expects to learn is wrong or incomplete once real users touch the product. These are better handled as a living, prioritized backlog, refined a slice at a time, validated against real usage each iteration, rather than fully specified up front. ## The trade-off runs both ways The trade-off here is genuinely two-sided, and a principal architect needs to be able to argue both directions depending on context, not just default to 'always be lean.' - **Over-investing** in upfront analysis for a volatile product wastes real calendar time and, worse, produces a false sense of certainty, a beautifully detailed spec for a feature set that gets thrown away after the first round of user testing is not neutral, it's actively misleading if anyone treats it as settled. - **But under-investing** in upfront analysis for the wrong kind of system is equally costly in the other direction: skipping constraint identification and non-functional-requirement analysis on a system that turns out to be regulated, or that turns out to need to scale far beyond its first deployment, produces exactly the retrofit costs described elsewhere in this topic, re-platforming, compliance gaps, and audits that can't produce evidence. The skill isn't picking a side of 'heavyweight versus lightweight' as a philosophy; it's correctly diagnosing which parts of a given system belong in which tier. ## The two failure modes - The failure mode on the **'too heavyweight'** side shows up as an organization that spends months producing a complete specification and matrix, ships something built exactly to that spec, and then discovers the spec was already wrong by the time development finished, because the market or user feedback moved during the analysis phase, the project pays the cost of rigor without getting the benefit of accuracy. - On the **'too lightweight'** side, the failure mode is the one already covered for constraints and non-functional requirements: an under-analyzed system built fast turns out to need re-platforming once it hits real scale, faces an audit, or needs to integrate with a system nobody surfaced as a constraint early, and the savings from skipping upfront analysis get paid back with heavy interest. ## A startup asked for the full spec A concrete way this plays out: a startup building a new B2B SaaS product is asked by a newly hired enterprise-sales-oriented executive for a full requirements spec and traceability matrix before the MVP is built, because 'that's how requirements were done' at their previous large enterprise employer. The right response isn't a flat refusal, and it isn't silent compliance either, it's identifying that these genuinely deserve upfront rigor and should be locked down before writing code: - the product's core security model - its multi-tenant data isolation boundary - its first two committed enterprise customers' mandated compliance requirements, such as SOC 2-relevant controls Retrofitting tenant isolation into a system built without it is a severe rewrite, while the actual screens, workflows, and feature details of the MVP are explicitly scoped as a rolling backlog to be refined against the first cohort of pilot customers' real usage, with the trade-off made explicit to the executive rather than assumed.