What contracting needs before the acquisition can move. Could be a little. Could be a lot. Depends entirely on what you're buying.
A requirements package is the file you hand to contracting that says: this is what we need, this is why we need it, this is how much it costs, this is when we need it, and this is how we'll know it worked. The purchase request is just one document inside it.
The job here is not to turn customers into contracting officers. The job is to give the CO enough facts to pick the right path on the first try, ask the right questions, and not lose three weeks reverse-engineering what you wanted.
One thing to set up before the rest of this makes sense: contracting can buy almost anything. A $1.27 box of paper clips. A trillion-dollar fighter program. The Federal Acquisition Regulation governs both, but the specific rules, paperwork, approvals, and oversight scale enormously with complexity. A paper-clip buy invokes almost no documentation. A weapons program invokes a regulatory ecosystem with its own milestone reviews and congressional reporting. Your package is somewhere on that spectrum, and "what should be in my package" depends entirely on where.
Federal contracting buys things on a scale most outsiders never see. A $25 office-supply micro-purchase and a $400-billion weapons system both fall under the FAR umbrella, but the specific FAR sections invoked, the documentation required, the approvals needed, and the oversight imposed are wildly different at each end. Almost everything scales — and it scales hard.
Where your buy lands on that scale tells you what should be in your package. Don't show up with an F-35 binder for a printer buy. Don't show up with a sentence for a $50M services contract. Build to your tier.
A description, a justification, a fund cite, and someone with a Government Purchase Card. Hours of effort, not weeks. A CO often never touches it.
Add a rough IGCE, light market research, basic specs or a short PWS, a real need date, and clear POCs. Days of work supported by your CO.
Commercial actions may still use FAR Part 12 simplified procedures up to $9M; non-commercial actions usually need a different acquisition strategy (FAR 14, 15, or 16 territory). Either way, expect a real requirement document, documented IGCE, market research memo, evaluation inputs, COR nomination, surveillance plan, and any restriction justifications. Most service, IT, and equipment buys live here.
Acquisition plan, formal source selection plan, OCI analysis, technical evaluation factors, life-cycle thinking, often EVMS reporting. Months of customer effort, multiple offices coordinating.
These programs get their own dedicated program office and a portfolio of documents — capability requirements, test plans, sustainment plans, milestone decision packages, congressional notifications, and more. The "package" becomes a library. The F-35 has had hundreds of people working on requirements documentation for two decades.
Most customer-built packages live in Tier 2 or Tier 3. The rest of this guide is calibrated to those, with notes when something only kicks in higher up.
Contracting cannot buy an idea. They buy a defined requirement, with funds attached, on a real schedule, with a way to know it worked. If those pieces aren't in the file, the CO has three options: stop the package, rebuild it with you, or guess. The first costs the CO weeks. The second costs you weeks of your own time. The third is how you end up with a contract you can't administer and a vendor you can't terminate cleanly.
A good package does three things at once. It gives industry a clear target so they can price the work. It gives the CO a defensible file when GAO, the IG, or your own leadership asks questions later. And it gives you, the customer, a contract you can actually manage after award. If your package only says "buy software" or "continue the support contract," it doesn't do any of those things yet.
When your package lands with the CO, the first review is the CO working through five practical questions. Every section of your package exists to help answer one of them.
Specific enough that industry can price it. "Software for analytics" is not specific. "Web-based dashboard for 85 users with three weekly reports" is.
The mission problem, not the preferred answer. "Vendor X knows our systems" is not a need. "We have a quarterly reporting deadline that requires this capability" is.
Prior buys, known vendors, commercial availability, small business sources. The CO needs to see the shape of the market before picking a strategy.
Funding year, need date, period of performance, approval timing — all of those have to line up. Wishing they did doesn't make them.
Acceptance criteria, deliverables, COR duties, surveillance plan. If you can't tell when the contractor is done, neither can the contractor.
If your package answers those five, the CO can help. If it doesn't, the CO has to play detective before they can play buyer.
A requirements package gets built by a team. A first-time customer who shows up trying to do everything alone usually ends up doing none of it well. Here's the unspoken org chart.
| Role | Owns |
|---|---|
| You (program office / requiring activity) | The need, the mission rationale, the technical facts, acceptance criteria, and the points of contact. |
| Resource advisor / financial manager | Fund type, fiscal year, amount, and current funding status. |
| Technical SME | Technical accuracy, minimum requirements, and inspection logic. |
| Contracting officer | Acquisition strategy, solicitation, award, file defensibility, and contract authority. |
| COR / acceptance owner | Surveillance and inspection after award. |
| IT, security, safety, legal | Specialty reviews when the requirement triggers them. |
If your name isn't next to a row, that doesn't mean you're not part of the package — it means you're providing inputs, not making the call. The customer side of the package needs all of those people to play their position. Bring them in early.
This is the comprehensive view: everything that could be in a requirements package, organized by when it kicks in. Almost no buy needs all of it. Every buy needs the first list. Use this as a menu, not a checklist — pick what your acquisition actually pulls in.
If you're sending it to contracting at all, any one of these missing means the package isn't ready. (A pure GPC micro-purchase often doesn't go through contracting and may not need a formal package — but if a CO is involved, these are the floor.)
Most service, IT, and equipment buys add some or all of these. Pull what applies to your buy.
These show up only when something specific about the buy pulls them in. If the trigger fits, the document is required or strongly expected. If the trigger doesn't fit, ignore the line.
You are not expected to know which of these apply. Your CO does. Your job is to bring the facts that determine which trigger fires — the dollar value, the requirement type, whether it's commercial, who furnishes what, and what could make it controversial. The earlier you bring those facts (even rough), the less rework happens later.
The difference is rarely length. It's specificity. A two-page package with real facts beats a twenty-page package full of vague language. Every time.
"Need contractor support for data analytics. Must be experienced. Need award by end of month. Vendor X is preferred because they know our mission."
"Need a web-based analytics dashboard for 85 users to ingest weekly CSV exports, apply five defined business rules, and generate three standard reports by 0800 each Monday for one base year and two option years."
The "ready" version isn't perfect. It still needs funding, market research, security review, evaluation inputs, and a real PWS. But it gives the acquisition team a starting point that doesn't require a guessing game.
You can absolutely send an early draft to ask for help. That's good. What you should not do is send a half-built package as if it's ready for solicitation. The list below is the difference.
The requirement is just a brand or vendor name. If "we need Vendor X" is the whole story, the file needs the minimum need and the facts supporting any restriction.
The need date is urgent but unexplained. If the schedule is the whole justification, the file needs facts, not just stress.
No one can describe acceptance. If the customer can't tell when the contractor is done, the contractor can't either.
Funding is unknown or mismatched. The CO can talk strategy, but award planning depends on a real funding story.
The customer team is not identified. If contracting has no technical POC, no fund POC, and no decision-maker, the package will sit.
Before the package goes to contracting, gather the program owner, the technical SME, the resource advisor, the potential COR, and anyone who can veto the requirement later. In thirty minutes, answer these questions out loud.
This meeting is not bureaucracy. It's the cheapest possible place to find the problem. Finding it after solicitation is expensive. Finding it after award is pain with letterhead.
"Sent to contracting" does not mean "ordered." Submitting the package starts an acquisition process. A simplified flow:
Where in this flow does the customer expect to be involved? Steps 1, 2, 4, and 6, mostly. The CO drives 3 and 5, but you're still the technical authority they call when industry asks "what does the requirement actually mean?"
How long does this take? It depends on the buy. A simplified action might be 30 days from package submission to award. An above-SAT competitive negotiated procurement might be 6 to 12 months. A major program is measured in years. The PALT Builder can give you a realistic timeline once the strategy is set.
Once you have a working package draft, run it through Preflight. Preflight reads the same questions a CO would ask on intake and tells you which pieces are present, which are missing, and which look risky. It's the cheapest second opinion you can get on a package, and it runs in your browser without uploading anything.
If you're still shaping the requirement, start with the Requirements Builder. It walks you through the requirement document, market research notes, evaluation thinking, and funding story without forcing you to sit down with a blank Word template.