An accurate verification of requirements for creating a product allows a software house to provide the pricing to the client. The quality and quantity of information provided influences the accuracy of estimation. While in the process, a Project Manager consults the project with specialists on the team, who estimate the amount of time needed based on their experience.
Arrangements between the client and provider enable to create a functional specification, that is, a document describing the application’s characteristics and functionalities. It can also be delivered to a subcontractor and then the whole process is simplified. The specification becomes the basis for further cooperation (naturally, apart from the contract). To put it simply, it determines what is to be done and how.
Information for valuation
Let’s start with the beginning and say that as a client, we want to get a pricing from a subcontractor and we don’t have a specification yet. The answers to questions that we should send depend on whether we talk about an existing application and its development or creating a new digital product. Definitively, you need ask yourself a question – what information will the provider need to understand the way the product should function and what logic and input data will help describe the technology.
Example of mobile app offer request – 7 main points
Exemplary information that you should include when sending an offer request (for this article, let’s assume that the product is a mobile app):
- What is the application’s goal, who is the target group, what is the app’s vision, what is its business logic?
- Is there already a specification of a brief for the planned project?
- What platforms should the app be implemented on?
- What devices should the app be designed for – only for smartphones, or also for tablets?
- What is the scope of the planned project?
- Is the project only of mobile nature, or are there also web elements?
- Should the pricing include the cost of preparing graphic design (Are there any mockups/sketches of particular screens)?
- Are the services (API) for the mobile app, along with the documentation, going to be provided, or should you prepare them on your end?
- Is a CMS panel necessary to manage content of the app?
- Is there a fixed budget for the app?
- Is there a deadline for the project?
Answers to the questions above enable you to initially define the project’s shape, however, they aren’t enough information to estimate the cost. Still, they are a good basis for getting more knowledge about the project (additional questions from Project Manager rely on the answers provided) and send the pricing.
Two project estimation methods – fixed price and time & material
There are two approaches to constructing the estimate: general pricing based on the input data or settling the time based on the number of hours spent on the project. Both methods have their advantages and disadvantages, and their choice should rely on the project’s completeness.
Each additional function, change requires broadening the scope of cooperation and influences the schedule. It is additional work from the PM, developers, designers and testers, who have to design, create and test a given feature. Each new idea requires involving additional resources out of the schedule and more work. That’s why based on the prepared conception for the project, different pricing models should be applied:
Fixed price – it relies on an estimate pricing of the project based on the data presented by the client. If the scope of the project and the product’s features are clearly determined, the risk of implementing changes is small, and the functional specification is prepared, this pricing model is effective. It is a declaration the provider will finish the product within a determined schedule. So, they need to plan the resources well.
Time & material – it relies on settling the account for the number of hours spent on the project. It is a very good method if the client doesn’t have a detailed functional specification, but only a vision for the product and there is a high probability of changing the scope of the project in the process. The flexibility of this method enables you to eliminate functions and widen them in any way.
Taking both approaches’ pros and cons into account, you need to think which way of settling the project will fit your needs.
The best way to get the same level of understanding with a subcontractor is to prepare the functional specification before the pricing, either on your own, on through a workshop together. This way, you eliminate the potential risk of underestimating the resources if working in the fixed price model.
What information is included in the functional specification
Let’s think what requirements specification is and what information it should include. The functional requirements specification is a document which helps you determine: what is the scope of the project, how the end product should look and function, and what technologies will be used. In simplest terms, it explains how the app is supposed to work and what actions the user will be able to do with it.
Going through each element of the specification, you can see exemplary sections:
- Description of the project – the goal, the scope, the roles in which element,
- Available materials (attachments) – links to texts, mockups, graphic files,
- Technical requirements – what platforms the application is for, what systems, what integrations it uses, how the frontend and backend will communicate, what markets it will be available on,
- App functions – what elements the app will have, what they will be for, what actions the user will be able to perform with them, what information they will have,
- Elements out of the scope of the project – additional elements of the project, which are e.g. prepared by other subjects, e.g. hardware.
The specification is a document shared between the client and the software house. It is the effect of the work from the company executing the order and the client. The more precisely it is defined, the more flexible the cooperation will be.
The success of the project is to a large extent dependent on how engaged the client is and how much concrete information they are able to deliver (not necessarily all by themselves) – says Krzysztof Dryjański, Project Manager at Appchance.