Before a software project starts, there is a phase that has not received much consideration in requirements engineering literature yet: the precontract or bidding phase during which a rough concept of the software to be implemented has to be established in the form of a bid or proposal.
An important part of a bid is a cost estimate that should be as precise as possible. For this cost estimate, an initial requirements analysis and documentation is necessary, because nobody is able to calculate a project without knowing what to implement. To be fast with the cost estimation, it is also helpful to use prepared artefacts from old bids that handle similar problems.
The proposal is used to enhance the comprehension of the project and provides a basis for the contract to be concluded with a prospective customer. So it has to be written and presented in an understandable way especially for the decision makers that are not willing and able to read a complex IT documentation.
The problem is that during the bidding stage, detailed requirements analyses are not yet possible because the analysis is not paid and the bidders are competing with other suppliers. If a bidder is not awarded the contract for the software project, the incurred expenses are not covered. The possible amount of this investment depends on the bidder’s estimation regarding the acceptance of his bid and is hard to determine. Budgets are running short and require an efficient approach when preparing a bid. Thus, too high investments in sound requirements analyses do usually not take place.
Thus, the preparation process involves risks and uncertainties both for the principal and the agent. There is an asymmetry of information between the two parties. The potential agent doesn’t know the requirements and the budget, the principal only has a limited notice of the agent’s actual reputation in the project field. Therefore, both partners try to exchange the information required for decision-making. For the agent, this means that he has to prepare a bid and demonstrate his capacity.
As this phase of a software project is not yet developed in literature, we want to find solutions in the workshop that help us to get a better understanding of this phase, improve requirements engineering and cost estimation methods as well as tools to be applicable in it.