This topic has been brought up before. Sorry about that. But I really haven't found a definitive answer.
I want to write a scope document to provide guidance to the project team. I have some "old school" developers on board, and they continue to tell me that "we need the requirements before we can provide any answers to you as you scope the project." Fair enough.
I have the high level business requirements, but they are looking for the full blown requirements document. They want to see what type of work effort is in store before they "committ" to anything regarding the scope of the project. Let's not even go to where I want to develop the schedule.
Simple question for everyone: If I'm following the traditional methodology of a project - Initiation, Planning, Executing/Monitoring/Control, Close. In order to plan, do I need the requirements (i.e. the requirements document) completed OR do I plan and is the act of gathering the requirements done in the Execution phase of a project?
http://en.wikipedia.org/wiki/Scope_(project_management) provides the classic view on scope.
In project management, the scope of a project is the sum total of all of its products and their requirements or features. According to the Guide to the Project Management Body of Knowledge (PMBOK) "Project Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. It is primarily concerned with defining and controlling what is or is not included in the project." 
Sometimes the term scope is used to mean the totality of work needed to complete a project.
In traditional project management, the tools to describe a project's scope (product) are the product breakdown structure and product descriptions. The primary tool to describe a project's scope (work) is the work breakdown structure.
If requirements are not completely defined and described and if there is no effective change control in a project, scope or requirement creep may ensue.
So it seems the developers are right and the requirements must be completely detailed. However that is a project in itself, mostly called the Design phase or even higher up Requirements Gathering Phase.
What I normally do is based on the high level requirements define a project break down structure where I detail the next phase to go through, in your case I would say the design phase and plan this phase thoroughly.
I will also estimate high level (top down) the remaining estimate and underpin this with a number of assumptions.
During the design phase I will detail the requirements to the desired level and at the same time validate the assumptions. At the end of the Design phase I detail the next phase, development phase, and if extensive testing and roll out is required I will estimate the work again with a number of assumptions to be validated during the development phase
An assumption, which will not be true, will result in a change request to adjust the estimate for the next phase. Validating the assumptions is an activity or integrated in detailing the requirements and therefore estimated in the current phase
With my experience in project management I agree with your approach of project scope definition first, followed by requirement collection.
Scope definition defines how would the final product look like, what all features it will carry and what it will not contain. I have seen customers tend to digress from what they have asked for in the RFP. Usually the functional expert with in the customer side is different from the one who initiated the RFP. When the requirement collection starts, new things starts showing up.
A correct scope document, duely signed-off by all stake holders help in containing the customer ambitions at the sametime it helps the system analyst/architect to collect the requirements and design the software with in predefined scope.
Scope definition is the basis of a project and definitely starts before requirement gathering.
I am not sure if you have got your reply by now or not? But I have something to share with you.
In the cases where customer is not sure about the detailed requirements, there is phase in projects that is called "Requirement Gathering", which enables the project team to gather requirements from various identified stakeholders from customer side. Now in order to start this phase, project manager needs to create a "Broad scope document" based on overview ideas from stakeholders and get this signed off by customer with provisioning of "Requirement gathering phase". Any subsequent planning and detailed scope document with all the estimates are generally out come of the requirement gathering phase itself.
We normally receive high level scope from Customer via RFP, based on that we capture detail requirements. Over requirement phase completes with all the use cases required to build the product. We submit the customer our requirement document which includes the work to be done in the project, and also the work which will not be done in the project, assumptions etc. So a single document will work as a requirement and scope documents, it will go through change if during execution new requirement or scope item is identified or removed. Each change will follow detailed impact analysis wrt cost/time/efforts.
There is a normal tendency of project managers or solution architects to create abstraction while writing requirements so that customer will not be able to provide evidence that few items are missed from the requirement document but for long term relationship it is always good to properly frame the requirement document so that all stakeholders are well aware of the final outcome of the project.
It is very important to write implicit requirements like audit trail, security, performance bench mark as these are basic needs of any application. Customer will never take the point that RFP doesn't have explicit explanation of above scope items.
Hope this will help.
Hi Paul - I agree with Hans comments re. the scoping of a project - and what it represents in project management terms. The methodogies for project management are PMBOK, PRINCE etc .
Reading between the lines however I think your developers want what we call in the UK a 'Functional Specification' - which is deliverable (document) of the analysis stage of your project - which set out the business / user requirements of an application development project. The methodology we use in the UK is SSADM - Structured System Analysis and Design methodology. This method is typically used for large system development projects. Other methods are RAD (Rapid Application Development, AGILE etc.)
If my understanding is correct - and your developers are looking for system scope - ie business requriements - then you need a business analyst to drive this. Functional Specifications are typically written by a business analyst who works with the business to define how the system needs to work to meet the business requirements of the software - for example a BA will design the system GUIs - the processes, navigation, database modelling elements etc. If you don't have a Business Analyst onboard - you could get a business lead to work with a developer (but one that is business savvy!!) to develop a strawman / prototype of the system - this involves mocking up screens etc. so that the business can look at the proposed system GUI and interact with your developers to define the specific requirements . However before you go down this route you should have a general understanding of the scope of the business requirements which you could define at a high level.
If you are developing a software application from scratch then I would strongly advise you to get a business analyst on board to lead the business requriements definition - they can also write test scripts down the line to ensure your User Acceptance Testing goes to plan.
If my guess is right it will explain why your developers need the functional specification - they need it before they can code the system. Its a pre-requisite. They are referring to the business scope requirements - and not the project scope reqirements.
To clarity - if you are project managing an application development project you will have several elements to that project (scope).
a) a project management piece around scope, schedule, cost, resources, time etc. The totality of the project scope however will have several elements to it - which are defined in the Work Breakdown Structure:
b) an infrastructure piece which is about what box the system will sit on and a technical architect will lead this piece and help you define the scope of the system architecture.
c) you may also need a system architect - if you need to develop a software application from scratch. They will deliver a document around System Architecture - this will be concerned with the front end, back end and middleware of the system and how it fits together - ie data feeds etc.
d) there is a piece around developing the application itself - ie. the software which developers will drive and
The most important element is around defining the business \ user requirements of the system - and it will drive everything else. THere are 2 bits to this a) functional requirements of the application and b) non functional requirements (if the system is to be available 24x7 etc). I think this is what your developers are asking for.
A Business Analyst leads the defination of the business requriements and not a project manager. A BA should liase with the business to identify the business requirements for the sofrware.
Hope I am on the right track and have interpreted your requirements correctly!!
This discussion is a good example of why the standard waterfall process hinders application development vs. using iterative development. You can still adopt iterative practices in a waterfall project by running multiple design-code-test iterations.
The development team will adopt better to this approach since requirements are expected at a high level and refined as the team progresses through each iteration.
You can still define the high level scope and include the requirements definition phase as part of your project without adopting iterative techniques. By including the development team in the process, they can better understand the requirements upfront.
Another approach is to run an analysis project to deliver the requirements so the development team can engage in purely developing and testing the code...however, I still prefer an engaged team.