What to put in a requirement

Most requirements that stall do not stall on supply. They stall because something in them could mean two different parts, and nobody can price two different parts at once. The back-and-forth that follows, not the hardware, is what eats the week.

Four things make a requirement quotable: what the part is, how it is configured, how many you want, and when it stops being useful to you. Everything else is helpful background.

For the first one, give the identifier the supply chain uses rather than the one on the box. A manufacturer part number is best. Model plus variant is workable. A product family on its own is the start of a conversation, because families span form factors and power envelopes that will not physically fit the same machine.

Configuration is where most of the accuracy lives. The same processor sells as tray and boxed at different prices with different warranties. The same accelerator ships in a module that needs a purpose-built baseboard and in a card that drops into a normal server. The same memory density comes in ranks that a given board will refuse to run at full speed. None of that is pedantry; it is the difference between hardware that racks on arrival and hardware that goes back.

Quantity changes the route, not just the total. One unit and forty units go through different suppliers with different lead times, and a price written for one does not simply multiply. Give us the real number and say whether it can arrive in batches.

Then the date. Say when it has to land and whether that is firm. Knowing it early means we can tell you a configuration will not make it while there is still time to pick a different one.