What is a "requirement"?

Vern Edwards said:

What is a "requirement"?

What the agency wants along  with a statement that precisely provides what the want should be when delivered.

This comes up a lot as an initial step in developing new IT systems.  Here’s one example

Quote

Requirements are the conditions or capabilities needed by a user to solve a business problem
or achieve an objective.

I'll try:

A future state that an agency has determined necessary to perform its function.

I just remembered I had more from old notes.  This is from a class and not my own thinking

1. “A condition or capability needed to solve a problem or achieve an objective.”

2. “A condition or capability that must be met or possessed by a solution to satisfy a contract, standard, specification or other formally imposed documents.

3. “A documented representation of a condition or capability as in 1 or 2.

formerfed said:

This comes up a lot as an initial step in developing new IT systems.  Here’s one example

That is virtually what ChatGPT provided:

“…[a] requirement is a specific condition or capability needed by a user or system to solve a problem or achieve an objective.”

For me, a requirement is specific goal or particular problem the Government is trying to solve. Description of a requirement includes identification of the quantity, quality, and delivery terms of supplies or services.

formerfed said:

A condition or capability that must be met or possessed by a solution to satisfy a contract, standard, specification or other formally imposed documents

That sounds like a long-winded version of Don's definition:

Don Mansfield said:

A future state that an agency has determined necessary to perform its function.

By "state" I think Don means "state of affairs". The Oxford English Dictionary defines "state of affairs" as follows:

Quote

The way in which events or circumstances stand at a particular time or within a particular sphere; the current situation.

Thinking about this some more--I think requirements exist before they are identified. With that in mind, I think I’ll revise my definition:

"A future state of affairs that is necessary for an agency to perform its function."

Don Mansfield said:

I think requirements exist before they are identified.

But isn't it possible to predict a future and forecast requirements? Doesn't DOD do that based on intelligence?

Yes. I meant requirements can exist before they are identified.

I revised my definition because I don't think the existence of a requirement is dependent on knowledge of the requirement.

Don Mansfield said:

"A future state of affairs that is necessary for an agency to perform its function."

Isn’t that a vision that leads to identifying requirements?

Don Mansfield said:

Yes. I meant requirements can exist before they are identified.

I revised my definition because I don't think the existence of a requirement is dependent on knowledge of the requirement.

As in: you could have a need before you know you have a need?

Jamaal Valentine said:

As in: you could have a need before you know you have a need?

Correct

formerfed said:

Isn’t that a vision that leads to identifying requirements?

How about the following?

"A requirement is the difference between the present state of affairs and a future state of affairs that is necessary for an agency to perform its function."

Vern Edwards said:

But isn't it possible to predict a future and forecast requirements? Doesn't DOD do that based on intelligence?

 A wish but that wish does not become reality all the time.   

Don Mansfield said:

A requirement is the difference between the present state of affairs and a future state of affairs that is necessary for an agency to perform its function."

Is a requirement really necessary to perform the function?   After all there are requirements that get canceled and requirements that sit on the shelf forever but the agency keeps performing.

Don Mansfield said:

How about the following?

"A requirement is the difference between the present state of affairs and a future state of affairs that is necessary for an agency to perform its function."

@Don Mansfield You keep adding words. Stop. Go back to your second definition, but delete the word "future", since futurity is obvious from context:

Don Mansfield said:

"A future state of affairs that is necessary for an agency to perform its function."

You could even delete "that is".

Don Mansfield said:

A future state of affairs that is necessary for an agency to perform its function

Short, crisp, and clear.

But many in the workforce will not understand "state of affairs" and probably wouldn't look it up. It's an important and very useful concept. (There's at least one book devoted to its explanation, the frequently-cited, A World of States of Affairs, by D.M. Armstrong, Cambridge, 1997. There's a short Wikipedia page devoted to the concept -- https://en.wikipedia.org/wiki/State_of_affairs_(philosophy -- and a lengthy and challenging entry at the online Stanford Encyclopedia of Philosophy. The usual thesaurus synonym is "situation", but "state" or "state of affairs" is more formal.

Here's the definition of "requirements" from the DAU Glossary of Defense Acquisition Acronyms and Terms:

Quote

The need or demand for personnel, equipment, facilities, other resources, or services, by specified quantities for specific periods of time or at a specified time.

🙄 

Isn't it interesting that FAR should not define so important a word? But, then, it's not a textbook.

Of course, other definitions are possible. So the thread is still open, although most readers will be lurkers, not participants.

One of the biggest challenges in acquisition is to contractually specify (not "define") requirements.

Vern Edwards said:

A state of affairs necessary for an agency to perform its function

This is prescriptive but not fully accurate descriptively.  Government engineers, program managers, and other requirements developers would need to live lives of simplicity to only think about what is "necessary" in performing their jobs.  That type of life has become exceedingly rare ever since economists and Madison Avenue dreamed up how to convert World War II factories into GDP-boosters.  Here is a more descriptive definition: A state of affairs desired for an agency to pursue happiness. 😆

Vern Edwards said:

One of the biggest challenges in acquisition is to contractually specify (not "define") requirements.

@Vern Edwards please explain what/why you distinguish the two. A lot of the common talk and training mention ‘defining requirements,’ but I’m sure you have a thoughtful reason.

I’m reminded of the FAR 2.101 definition of contracting.

”Contracting includes description (but not determination) of supplies and services required“

Jamaal Valentine said:

{P]\please explain what/why you distinguish the two. A lot of the common talk and training mention ‘defining requirements,’ but I’m sure you have a thoughtful reason.

According to my dictionary, American Heritage, 5th ed., define means to state the meaning of. Specify means to describe in detail. For contractual purposes I would want to describe, not define, the requirement. Based on Don's definition of requirement, I would want to describe the desired state of affairs, so the contractor could produce it.

Thank you, @Vern Edwards

Is the CO's contribution to requirements specification mainly in the following?

• Selection of unit rates, if any.
• Inclusion and exclusion of PWS paragraphs in CLIN descriptions, followed by proposal evaluation to examine (by Work Breakdown Structure or otherwise) resulting costs' effects on future contract administration 
• Specific application of clauses to each CLIN
• Establishment of inspection and acceptance criteria by CLIN

Note this question assumes the CO is a requirements developer.

On 5/18/2024 at 8:55 AM, Vern Edwards said:

What is a "requirement"?

On 5/18/2024 at 8:55 AM, Vern Edwards said:

what does an RFP describe when it describes a Government "requirement"?

Are we going to get to the bottom of these questions on this thread?  The implications are broad: below is a list of some heavy-hitting definitions in FAR 2.101 that use the term "requirement" (with my emphases).

Quote

Acquisition means the acquiring by contract with appropriated funds of supplies or services (including construction) by and for the use of the Federal Government through purchase or lease, whether the supplies or services are already in existence or must be created, developed, demonstrated, and evaluated. Acquisition begins at the point when agency needs are established and includes the description of requirements to satisfy agency needs, solicitation and selection of sources, award of contracts, contract financing, contract performance, contract administration, and those technical and management functions directly related to the process of fulfilling agency needs by contract.

* * * *

Advisory and assistance services...are classified in one of the following definitional subdivisions:

(1) Management and professional support services, i.e., contractual services that provide assistance, advice or training for the efficient and effective management and operation of organizations, activities (including management and support services for R&D activities), or systems. These services are normally closely related to the basic responsibilities and mission of the agency originating the requirement for the acquisition of services by contract...

* * * *

Best value means the expected outcome of an acquisition that, in the Government's estimation, provides the greatest overall benefit in response to the requirement.

* * * *

Bundling —

(1) Means a subset of consolidation that combines two or more requirements for supplies or services, previously provided or performed under separate smaller contracts (see paragraph (2) of this definition), into a solicitation for a single contract...

* * * *

Classified acquisition means an acquisition in which offerors must have access to classified information to properly submit an offer or quotation, to understand the performance requirements, or to perform the contract

* * * *

Commercial product means—

(1) A product, other than real property, that is of a type customarily used by the general public or by nongovernmental entities for purposes other than governmental purposes, and—

(i) Has been sold, leased, or licensed to the general public; or

(ii) Has been offered for sale, lease, or license to the general public;

(2) A product that evolved from a product described in paragraph (1) of this definition through advances in technology or performance and that is not yet available in the commercial marketplace, but will be available in the commercial marketplace in time to satisfy the delivery requirements under a Government solicitation;

(3) A product that would satisfy a criterion expressed in paragraph (1) or (2) of this definition, except for—

(i) Modifications of a type customarily available in the commercial marketplace; or

(ii) Minor modifications of a type not customarily available in the commercial marketplace made to meet Federal Government requirements. “Minor modifications” means modifications that do not significantly alter the nongovernmental function or essential physical characteristics of an item or component, or change the purpose of a process. Factors to be considered in determining whether a modification is minor include the value and size of the modification and the comparative value and size of the final product. Dollar values and percentages may be used as guideposts, but are not conclusive evidence that a modification is minor;

(4) Any combination of products meeting the requirements of paragraph (1), (2), or (3) of this definition that are of a type customarily combined and sold in combination to the general public...

* * * *

Cost realism means that the costs in an offeror's proposal—

(1) Are realistic for the work to be performed;

(2) Reflect a clear understanding of the requirements; and

(3) Are consistent with the various elements of the offeror's technical proposal.

Does "a description of the desired state of affairs" endure as the meaning of requirement in all cases of its use above?  Or do we need to discuss?

What about the use of the term in the following FAR Part 16 senses I emphasize?

Quote

16.301-2 Application.

(a) The contracting officer shall use cost-reimbursement contracts only when—

(1) Circumstances do not allow the agency to define its requirements sufficiently to allow for a fixed-price type contract (see 7.105)...

* * * *

16.603-2 Application.

(a) A letter contract may be used when

(1) the Government's interests demand that the contractor be given a binding commitment so that work can start immediately and

(2) negotiating a definitive contract is not possible in sufficient time to meet the requirement. However, a letter contract should be as complete and definite as feasible under the circumstances.

Voyager said:

Is the CO's contribution to requirements specification mainly in the following?

I think the answer to that depends on the representative of the requirements activity and the CO.

The specification is ultimately a legal (contractual) document with technical content. The writer(s) must understand both facets of it a some level.

When I was a contract specialist and then CO, I always co-wrote the statement of work. So did many other COs in my field of acquisition, even for development of launch vehicles and reentry vehicles. How much I wrote depended on the requirement and the contracting know-how of thee project officer or program manager. I even provided contracting input to the technical requirements document.

I bought, borrowed, and read books about engineering and design so I could talk to engineers and designers like an educated layperson. When I worked in projects and programs I read books and several manuals about work breakdown structuring. I and several of my colleagues were taught CLIN structuring by the late Mary Ann Scott, one of the smartest people in contracting back in the '70s and '80s. I read books about process design and engineering so I could be useful to the requiring activities that I supported. In one year I taught a class at my organization entiled Engineering for Non-engineers. One colleague and friend, the CO for the Titan II launch vehicle, reviewed the technical specs and read technical proposals cover-to-cover.

But most COs wanted nothing to do with SOW preparation.

I did not decide what was required. I decided how the requirement would be described, because I was a better writer knew more about contracts than most (not all) of my program colleagues.

Voyager said:

Are we going to get to the bottom of these questions on this thread?

So, in ultimate answer to your question, the CO's contribution to requirements specification depends on the inclination and the competence of the CO.

Voyager said:

Are we going to get to the bottom of these questions on this thread?

I don't know. I opened this thread for discussion, not to present a treatise. As usual, most of the contributors have been regulars. Most readers, however many there have been, have been𑁋again, as usual𑁋lurkers. That's contracting for you.

Vern Edwards said:

I taught a class at my organization entiled Engineering for Non-engineers

That should be a course, mandatory for certain CO's, if it isn't. Once you learn the lingo, abutment, at-grade, embankment, headwall, cross sections, BIM, riprap. etc. everything else comes together for the non-engineer... in my experience.

Ahh! Construction terms.

There nothing quite as essential to CO for construction as a good dictionary of construction terms and a class on construction specs and drawings. Is the material rock or cemented fanglomerate?

As a fellow jack-of-all-trades myself, I think when I assist my requirements owner in development of Section C of a cost-reimbursement RFP (see FAR 16.301-2 application above) I am more open to including process descriptions as a requirement of the contract.  If it’s a firm-fixed-price RFP, I examine it with a lens for removal of all “how” descriptions in favor of just the “what”.  So, my written state of affairs is contract type-dependent.

Furthermore and along that vein, I also have to examine the state of affairs with a lens for my ACO and TCO’s benefit, imagining what is needed in there to someday T4D this thing - given all the heightened political pressure that accompanies that - without needing to capitulate conversion to a T4C.

Voyager said:

If it’s a firm-fixed-price RFP, I examine it with a lens for removal of all “how” descriptions in favor of just the “what”.  So, my written state of affairs is contract type-dependent.

The what versus how sounds like most training on performance-based acquisitions versus non-performance-based acquisitions. Especially when talking about requirements documents (e.g., PWS vs traditional SOW).

The notion of a rigid what-how distinction is stupid. Sometimes how is what. Sometimes agreement on how is essential to mutual success and dispute-avoidance, especially in service contracting.

The official approach to "performance-based contracting" has been one of the greatest failures in the history of acquisition policymaking, as is the rigid policy of proposal-based competition.

Read-up on contract design principles. I have provided references elsewhere.

Vern Edwards said:

Sometimes how is what.

Agreed.  I once got involved in a situation where the government had a "requirement" to have paint removed from the exterior of a building.     The contract did not state how this was to be done.  The contractor started to remove the paint by sandblasting.  The government stopped the contractor from using this method because the building was a historic preservation property and sandblasting would damage the building.  The government insisted on a more costly and time consuming method of removal by hand.  Here, obviously, how was the what.  I am sure there are other examples of situations like this.

Vern Edwards said:

The official approach to "performance-based contracting" has been one of the greatest failures in the history of acquisition policymaking, as is the rigid policy of proposal-based competition.

Vern, I know you won’t agree with this but some of the earlier PBAS were successful.  Yes, there’s not quantifiable proof but post award information from customers and end users showed happiness with the outcomes.  It’s just too difficult and time consuming to establish baselines and measures of success and most agencies don’t want to spend the time and effort - getting a timely award is what counts.

But most PBAs over the years didn’t produce positive results.  I think that’s because of two things - one is contracting personnel didn’t have proper training and guidance as well as expertise to pull them off and the OFPP mandate to get a certain share of awards as PBAs.  That usually resulted in taking a SOW and changing a few works and call it a PWS.

As far back as I can remember the successful PBAs had common elements - use of a SOO, conduct of comprehensive market research, employment of IPTs, and strong, experienced COs and PMs.

Vern Edwards said:

The notion of a rigid what-how distinction is stupid.

Is it stupid or is it just a rule of thumb suitable to requirements written by people in positions of nonessential function and with no professional aspirations?  There’s a lot of them in this career field.  It may be good enough for their government work.

formerfed said:

Vern, I know you won’t agree...

You're right. In my 50 years in government contracting I have learned not to trust undocumented "success stories." Most don't stand up to scrutiny.  They're propaganda.

But I'm receptive to documented evidence. Tell me the tale and show me the facts.