There is a tear in my jeans. Right in between my legs, which is exactly where you'd expect it if you knew me. I have thick thighs, they rub against each other when I walk, and I walk a lot. It's a combination that has destroyed more pairs of trousers than I'd like to admit. At some point I stopped being annoyed by it and started being curious about it. How would an engineer define the requirements for a pair of jeans? More specifically, how would they define the requirements for the part of the jeans that has to survive me?
This is not a trivial question. In automotive and aerospace engineering, the concept of a requirement is both simple and transcendental simultaneously. What must the product do, and what must it not do. Simple enough as a statement, but it becomes the cornerstone from which the complete development cycle is built. You take a key characteristic of the final product and decompose it into smaller functions that cascade down to each component. Every requirement must be met, and evidence must be provided that it has been.
I like to think that the products I buy follow the same kind of rigour as the products I develop. They almost certainly don't, but the exercise of applying that rigour anyway turns out to be a useful way to understand why things fail, and what it would actually take to make them not fail.
So. A pair of jeans. Built to last. Let's define what that means.
Setting the top level requirement
"Long lasting" is not a requirement. It's an aspiration. To make it useful you have to put a number on it. For our purposes: two years of daily usage. If alternated with other trousers and worn once a week, that's fourteen years of service life. A reasonable middle ground for a well-made garment.
That is our top level requirement. Everything else cascades from it.
Cascading down to the failure mode I know personally
Two years of daily usage means the material and construction must withstand abrasion against itself, at a given pressure, for a given number of cycles. That single sentence, as simple as it sounds, does something powerful: it tells you exactly what to test, and it tells you what you're looking for in a material before you've seen a single swatch.
Now it gets interesting. I actually went and measured the contact patch on several pairs of my jeans by looking at where the fabric whitens from friction. It's a surprisingly consistent area across different cuts. The pressure is trickier. My best attempt involved a kitchen scale placed between my legs while standing, which I'll admit looked exactly as undignified as it sounds. The reading was roughly 10 N, which we'll take as our working value. For steps, the average person walks around 10,000 a day. In a proper development program you'd calculate for the 99th percentile across the distribution and test to that number of cycles. For this exercise, let's say we've done that, and we now have three values: contact area, pressure, and cycle count.
We've just drafted the first material requirement for our pair of trousers.
The next step is to stack additional requirements on top of it and use them to narrow the material candidates. We're staying with organic fibres, so cotton. That decision immediately constrains the knit type, the weave density, and the fabric weight. From there you source samples, test them to the cycle and pressure values you've defined, and the survivors move to the next round of filtering. You continue until you have a shortlist of materials you can be confident will last the service life.
The button is another easy example. How many opening and closing cycles must it survive? How much constant tension when the fit is right, and how much when it isn't quite right anymore after a few months of good eating? The logic is identical. Define the condition, put a number on it, test to it.
Where this gets harder, and more interesting
Not every requirement is solved by material selection. Some are solved purely by design: moving stitching and load-bearing joints away from the sections that take the most abuse, for instance. Others are solved through serviceability, designing something to be repaired rather than replaced. But the underlying logic is always the same. You define the full set of requirements, cascade them down until you reach something you can test, then validate performance against each one.
The difficult part is not the cascade. The difficult part is the top level. Most people skip it because it forces you to commit to something specific and measurable before you've made any of the comfortable decisions about materials or aesthetics. But skipping it means your design has no anchor. You're making choices without knowing what you're optimising for.
And here is where it connects to design in a way that I think gets overlooked: aesthetics can be a top level requirement. It is less trivial to validate than abrasion resistance, but it is a requirement nevertheless. What that means in practice, and how you define and test for it, is the subject of the next piece.