Software development RFP (Request For Proposal) is a document created to inform potential vendors about the project, learn more about their domain expertise and receive project cost and time estimates. As there are no rigid standards and templates for an RFP, businesses create documents, which match their product specifics best.
A request for proposal for software development explains:
- project’s business context
- project objectives
- the overall technical architecture
- the planned scope of work.
If your RFP contains an inquiry on vendor’s project estimates, it’s vital to make sure the project idea is delivered properly. Detailed work on the RFP helps to avoid serious misunderstandings with the software developer (which is possible at the initial stage). Such an approach can substantially facilitate the comparison of bids.
There is a risk that some vendors may significantly underestimate the costs, while others may claim higher estimates because they consider the project way more difficult than it actually is.
By reading this article, you can learn about best practices on how to write an RFP for custom software development and ensure the vendor selection is objective and informative.
Are you sure the vendor provides reliable estimates upon receiving your software development RFP?
Option 1: Ask for reconstruction or a presentation
For sure, software development RFP samples may consist of 2-3 pages of free-format project details and a product wishlist attached. However, there is a risk of having a 10x (!) estimate deviation from different software developers. Some businesses attach examples of competing products similar to their project vision. It makes sense, but such an approach cannot replace a thorough explanation of the project business and domain logic. Some details may not be obvious for developers looking through the examples of digital products you present.
It’s hardly possible to do without investing time in a careful listing of high-level business and system requirements. Include the suggested structure of vendor bids in your RFP to get nicely structured responses.
And the key advice: ask vendors to reconstruct the idea of the project and its requirements the way they comprehend it.
Another method that will work just as well is to go for real-time communication and ask for a presentation of the vendor’s proposal with a detailed analysis of risks and expenses calculation.
Option 2: Include a comprehensive list of requirements and nice-to-haves into the RFP
This option implies investing more time in preparations and hoping that software development companies get a better project outlook and send you a very informative response right away.
The level of engineering requirements may vary depending on project complexity. So, as for the list of requirements, we suggest splitting them into the following sections:
1. General vision of the project
- Target audience (for example, retail and business customers)
- Objectives (for example, to implement a Digital Banking Platform with the Internet bank, the Mobile bank, and the CMS platform)
- Necessary changes in the existing functionality (if any).
2. Business requirements (BR) and Market Requirements (MR)
Business requirements focus on customer needs and expectations. A Business Requirement Document (BRD) may indicate project deliverables, the inputs/outputs of each function, but is high-level and does not specify functions or technical solutions. Business requirements are about one page long and are provided in a bulleted list.
For example:
- There should be a comparison tool helping users to differentiate between different services.
- The user should be able to continue the interrupted session at a later time on any device.
- The homepage design, layout & navigation logic should be adapted to target audiences from different countries.
Market requirements are optional. They are also high-level and are provided in the form of a prioritized bulleted list. However, this list is a few times longer than the list of business requirements. Instead of the company’s specific business goals, market requirements outline market needs in order to get a better perspective of the product across the market niche.
3. Functional requirements
They include the list of product features and functions, usually in the form of use cases to cover product functionality in detail. Functional requirements can run a few hundred pages, depending on the software being developed.
For example:
- The comparison tools should be available for payment cards and deposits.
- The AI suggestion is enabled for authenticated users.
- Customer’s IT employees should be able to add, remove and reorder the following blocks and buttons:…
- Upon clicking “Continue Later”, the user can send the link to the application form at their email. The unique URL is attached upon clicking “Send”. The user can continue filling out the form by clicking on the link from any device.
The BRD focuses on high-level business needs, whereas the Functional Requirement Document (FRD) consists of the functions necessary to fulfill the business needs. The former specifies what the business wants, and the latter specifies how it can be achieved. Functional requirements derive from business requirements and cannot exist in a software development RFP on their own.
4. Non-functional requirements
They have nothing to do with the actual product functionality, but cover other technical aspects of great priority, for example:
- Specific technologies that should be used in project implementation
- Project deployment requirements (deployment with customer’s own servers or cloud technologies)
- Product performance (the loading time for simultaneous or concurrent users)
- Multichannel user requirements (the overview of all ongoing processes: for example, all variations in execution paths should be detectable)
- Scalability
- Capacity expansion
- Compatibility with browsers, mobile platforms, and their versions
- Security (such as the enhancement of security-related components with no impact on other layers)
- Integration (for example, with third-party authentication providers)
- Maintainability requirements (for example, self-diagnostics and system monitoring tools).
The section of non-functional requirements is one of the trickiest: many projects make the mistake of not specifying them explicitly.
5. Other Requirements (optional)
Massive development projects may require an additional project handover stage. The project handover includes transferring the source code along with extended support and training customer’s technical employees on the new system usage.
How to get reliable estimates for a massive software development project?
If businesses lack resources and technical expertise to work through the requirements, experts suggest dividing the software development RFP into two parts. This would be especially convenient for large or multi-component system development.
Part 1. Pre-study
You may outsource not only the project itself, but the process of setting functional and non-functional requirements, creating high-level technical architecture and, perhaps, even a UI/UX wireframe for the future project. Hire a vendor to do that for you. The vendor should not necessarily be the one you are going to select for the project implementation.
From our experience, it takes about 1-2 months to plan out the development of a compound system.
The scope of work at the first stage includes:
- Creating a Business Requirement Document
- Writing a draft of a Technical Specification Document.
A Technical Specification Document may have different templates depending on the technology and methodology used, the priorities of stakeholders, and other factors.
Here are the key items to include:
- The executive summary of the project and the project scope
- User review
- Operating environment
- System features
- Requirements of the external interface
- User, hardware, software, and communication interfaces
- Non-functional requirements
- Software quality
- Assumptions, risks, dependencies, and constraints
- A glossary to explain technical terminology used in the document
- References to related documents.
Why a pre-study can be extremely useful?
There is something that sets software development apart from other engineering activities: it is spacious enough for requirements to appear as the project implementation evolves.
The key reason is the intangible nature of a software product. There is always a way (or even a few) to modify business requirements at the later phase. However, it’s important to keep in mind that introducing changes in the code at a later development stage is perceived to be easier than it is.
Part 2. Detailed RFP
Having gathered all the requirements, businesses can include them in the software development RFP. It assists in receiving more accurate cost estimates, and terms of cooperation.
In the second part make sure you specify the RFP Response timeline, the suggested structure for vendor bids and the key selection criteria.
This way vendors will provide the information in a detailed and nicely structured manner. It will make the comparison and the final decision a lot easier.
