The technical requirements provides enough technical details about the project so as to allow a precise definition of the design of the infrastructure (and the characteristics of the service) to be implemented, while avoiding being too prescriptive as explained below. Through the technical requirements design process, costs are assessed, which are a key input for the commercial feasibility analysis explained further in this chapter.The technical requirements are also a basic input to the other feasibility analyses, such as the environmental feasibility, economic feasibility, Value for Money assessment, and the affordability analysis.
Furthermore, a precisely designed set of technical requirements offers an essential body of data for bidders to assess the technical risks the private partner will be exposed to, as well as to price the service, which effectively contributes to a more competitive tender. It is a good practice for the design of the technical requirements to be preceded by the identification of benchmark projects which can be a precious source of historical data, as well as of significant lessons on the design of the infrastructure and details of service delivery.
A technical requirement document empowers your team to come to a mutual understanding of what is required, technically, to make your project or product a success. Out of the 5 Phases of Project Management, technical requirement documents
should be created during Phase 2 of your project’s life cycle. During this phase the scope of your project is defined and goals are set. Technical requirement documents will also provide information that will help you:
1. Determine your budget.
2. Create your work breakdown schedule.
3. Develop the project Gantt Chart.
4. Initiate a communication plan.
5. Define risk-management aspects.
Anyone preparing a technical requirement document should understand what comprises a ‘good’ system requirement and how to communicate this information in a clear way. The following points one must keep in mind, be creative about the sources you choose to explore as you analyze your technical requirements and always use your business need as a basic reference point, help others understand your results by using easy-to-understand language, use prototypes to figure out what you are missing, make sure you understand the interrelationships, priorities, cost, implementation, and environmental consequences when you decide what to include and define system boundaries.
1. Functional requirements
2. Driving dates in terms of milestones
3. Physical requirements
4. Specifics of the technical environment
5. Data requirements
6. External interfaces
Consider gathering the following types of information for your technical requirements document:
What core problem will your product or software solve for your audience? What do you want people to accomplish while using your product or software? How will lives be made easier and more productive?
Which team members are responsible for aspects of the work?
Use mock-ups, narratives, or lists. Clearly state interface requirements. Clarify customer or client requirements especially if product or software is being built to a client’s specification. Define development stages. Include specific steps to completion, and create an initial schedule that can be refined as more details are discovered and decided. Identify contingencies by exploring which parts of the process are dependent on each other and why.
Create a prototype to help clarify the outcomes users anticipate from the new product or system when complete
Define the entire lifecycle of product development, including people, process, software and technology development, change management
The relevant function it performs. Any kind of limits, in terms of design, legal, or regulatory constraints or risks. Environment design requirements for operational location, use, or storage. Considering System Qualities like availability, latent capacity, performance, scalability, serviceability, and security.