As part of designing the bid / proposal you have choices. You could define some software requirements, and request companies bid to deliver you some software that met the stated requirements. Normally, these would include functional items relating to use cases and business / user objectives for using the software. It would also be wise to include non functional requirements. Non functional requirements could include timescales for doing specific tasks, or capacity constraints such as the website must be able to handle 2,000 concurrent user sessions, with 1% actively retrieving a page at any moment in time.

However, you could define the bid / proposal differently. You can define the bid proposal as a bid to implement a project to deliver the software.

The difference here, is that by defining the project requirements as well as the initial software requirements, it enables you to:

1. Place some degree of influence on the processes and quality controls that will be implemented in developing the software. Companies bidding for work, will be looking for delivering sufficient quality for the lowest effort. By defining the project requirements obout engineering quality controls, you are retaining control of key quality controls in the project.

2. By defining the bid as a project, you are not tied quite so tightly into the initial specification, and are more likely to think about how to manage spec clarification as the project and its implementation details become better understood.

If you look at software consultancy websites, their sales pitch is never about how cheaply they pay their developers, it's always about their craftsmanship and how they have superior developmental processes.

As part of designing the bid / proposal you have choices. You could define some software requirements, and request companies bid to deliver you some software that met the stated requirements. Normally, these would include functional items relating to use cases and business / user objectives for using the software. It would also be wise to include non functional requirements. Non functional requirements could include timescales for doing specific tasks, or capacity constraints such as the website must be able to handle 2,000 concurrent user sessions, with 1% actively retrieving a page at any moment in time.

However, you could define the bid / proposal differently. You can define the bid proposal as a bid to implement a project to deliver the software.

The difference here, is that by defining the project requirements as well as the initial software requirements, it enables you to:

1. Place some degree of influence on the processes and quality controls that will be implemented in developing the software. Companies bidding for work, will be looking for delivering sufficient quality for the lowest effort. By defining the project requirements obout engineering quality controls, you are retaining control of key quality controls in the project.

2. By defining the bid as a project, you are not tied quite so tightly into the initial specification, and are more likely to think about how to manage spec clarification as the project and its implementation details become better understood.

3. This would allow you to put in requirements around the automated testability of the software i would also think carefully about the level of testability that is required and how the complexity of the product will still enable quick deployment cycles without the automated test process taking 3-4 hours to complete.

Finally, as a note - If you look at software consultancy websites, their sales pitch is never about how cheaply they pay their developers, it's always about their craftsmanship and how they have superior developmental processes - their sales team will be very capable in explaining how their project processes will deliver an exceptional customer experience that meets your project brief