This thought came up when answering the question IsExtremeProgrammingWacko?

How detailed do you want your requirements to be if all you are trying to do is CaptureRequirementsForPrioritization. So early on in ProjectInception, what you really need to do is figure out HowBigIsTheSystem, and a (very) LowPrecision mechanism for doing this is counting the number of requirements you have. 

So how do you count the number of requirements, without having to do a lot of RequirementsAnalysis? A LowPrecision UseCase would be a way of doing this, brainstorm all the ActorGoal pairs, add some explanation for each and then see how many you have. The XP UserStory is an alternative mechanism.

Given these LowPrecision requirements, we can haggle and negotiate about scope, without having to spend 5 days per UseCase in RequirementsAnalysis. This way, RequirementsTriage is cheap, and later on we can get the real detail when we CaptureRequirementsForImplementation. But at least then we have a rough agreement on scope and priority.

--PeteMcBreen

Also, how do you even know what the requirements are without doing a lot of Requirements Analysis? How do you to you get the customer to agree what the "job" is and what is the product without doing Requirements Analysis? 
-----

My context for CaptureRequirementsForPrioritization is a software house evaluation many different ideas for systems and enhancements to existing systems. What I need in this situation is some technique for evaluating the options without spending a ton of money and time.

So ''how do you even know what the requirements are without doing a lot of Requirements Analysis?'', well you do not know them in enough detail for Design, that was covered by CaptureRequirementsForImplementation. All I want at this stage is a ballpark figure to see if the development cost matches the available funds.

For a non-software analogy, suppose I go to a Builder and inquire about the cost of building a Log Cabin out in the country. Given a small amount of information (3000 square foot, 4 bed, treed lot with serviceson a rocky hillside) I can soon be told that sloping, rocky lot is very expensive compared to a flat lot etc. 

As for ''How do you to you get the customer to agree what the "job" is?'' Well the simple answer is at this stage you do not get agreement. What you determine is whether it looks likely that we can build something for the price that the customer is willing to pay that will meet the customers needs. And we do this CustomerQualification cheaply and quickly so that we do not divert ourselves into doing work for free. 

That leaves ''what is the product without doing Requirements Analysis?'',  well we do not know yet. What we have done at this stage is started the conversation and got into negoitiation and determined some customer priorities and values. Informally in our heads we have a picture of the system from LowPrecision UseCases, but we will not get a better picture until we commit to the extra expense of RequirementsAnalysis and  CaptureRequirementsForImplementation.
--PeteMcBreen