Requirement specifications - content and structure
In project management, the requirement specification is an essential building block for achieving successful results. This documentation serves as an indispensable basis for the planning, implementation and acceptance of projects. This article takes a closer look at the importance and purpose of the requirement specification and its role in the efficient design of projects.
Content
Definition and meaning
The requirement specification is the description by the client to the contractor of the services to be provided. It is needed in the start-up phase of the project. The requirement specification describes the client's specific requirements for achieving the project goal and is used, among other things, to solicit bids and to provide guidance and planning certainty, since the conditions for the project are known through the precise description of the requirements. In addition, it can contribute to risk minimisation, since the precise description minimises planning and control errors.
On the basis of the requirements specification, the contractor can draw up the performance specification. This contains all the steps that are necessary to carry out the project like deadlines, prices or even the complete project planning. The contractor shows the client from the outset which project requirements can be realised or which alternatives there might be to the requirements. In this way, both parties enter into contact to realise the project.
On the basis of the requirements specification, the contractor can draw up the performance specification. This contains all the steps that are necessary to carry out the project like deadlines, prices or even the complete project planning. The contractor shows the client from the outset which project requirements can be realised or which alternatives there might be to the requirements. In this way, both parties enter into contact to realise the project.
Elements of a requirement specification
The requirement specification is drawn up at the beginning of the project and should be more extensive and detailed the larger the project is. Since every project has a different scope and therefore different requirements, the scope varies from project to project. However, there are some points that apply to all projects.
The introduction should start with a brief summary of the project, the financial framework and the planned start of the project. This also includes the status quo, i.e. the initial situation. This way, the reader knows immediately what the project is about, how much time is available for the preparation of the functional specifications, or for the project, and what financial resources are available.
Example:
Imagine you want to cut a fabric with scissors. But the fabric is very slippery, keeps warping and you cannot cut a nice, straight line. That is the status quo. You want to develop something that makes it easier to cut the fabric without it slipping. The product should be on the market in 6 months and has a budget of CHF 100,000.
The next point is the specification of the service to be provided, also called goal definition. This includes the delivery item on the one hand and the delivery object on the other. The deliverable is a clear and verifiable product, result or service to be provided at the end of a phase, project or milestone. In other words, it is the result of a process or project described by a quality criterion. Quality criteria ensure that project results meet customer requirements and must be formulated as precisely as possible so that they can be objectively verified and measured. Project results also refer to the delivery object.
Example:
The aim is to develop a product that is like a kind of pizza cutter. For this purpose, various quality criteria are defined, e.g. that the material is cut straight by the blade or that it can withstand a certain number of cuts before it becomes blunt.
Next come the functional requirements for the project, which include a detailed formulation of the product's purpose, function or behaviour, depending on what it is. This defines how the product must behave to meet the customer's needs. This serves as a guide for the team to develop, release and market the product.
Example:
The round blade of the cutting tool needs to be stowed away so that you don't accidentally cut yourself. A mechanism has to be developed to pull the blade out manually. Maybe this mechanism is so well developed compared to the competition that the product can be marketed well with it.
But non-functional requirements must also be mentioned. These include restrictions that have to be considered during the project, e.g. budget, time and resources. In part, these also influence each other, because if a resource in the form of a material is delayed, the production of the product is also delayed. Resource consumption in the form of materials is also part of service production.
Example:
It may be specified that the handle of the rotary cutter should be made of plastic and the blade of stainless steel.
In addition to all these requirements that relate to the product, there are also requirements that are intended to ensure cooperation between the parties involved in the project.
These include the contractual conditions, the requirements for the contractor and for the contractor's project management.
Contractual conditions include, for example, requirements for warranty, cancellation of the agreement, compensation, termination for cause and risk management. Worst-case scenarios do not always have to happen, but if one party fails to perform as defined, it is important to have a clear understanding of what would happen in the worst case and what the rights are.
Requirements for the contractor can be certain requirements for the staff, e.g. that they have certain certifications in a certain industry or that a certain procedure is used. Project management requirements may include how the project is to be documented, how communication between the parties is to take place, who the contact persons are and who the project managers are.
The introduction should start with a brief summary of the project, the financial framework and the planned start of the project. This also includes the status quo, i.e. the initial situation. This way, the reader knows immediately what the project is about, how much time is available for the preparation of the functional specifications, or for the project, and what financial resources are available.
Example:
Imagine you want to cut a fabric with scissors. But the fabric is very slippery, keeps warping and you cannot cut a nice, straight line. That is the status quo. You want to develop something that makes it easier to cut the fabric without it slipping. The product should be on the market in 6 months and has a budget of CHF 100,000.
The next point is the specification of the service to be provided, also called goal definition. This includes the delivery item on the one hand and the delivery object on the other. The deliverable is a clear and verifiable product, result or service to be provided at the end of a phase, project or milestone. In other words, it is the result of a process or project described by a quality criterion. Quality criteria ensure that project results meet customer requirements and must be formulated as precisely as possible so that they can be objectively verified and measured. Project results also refer to the delivery object.
Example:
The aim is to develop a product that is like a kind of pizza cutter. For this purpose, various quality criteria are defined, e.g. that the material is cut straight by the blade or that it can withstand a certain number of cuts before it becomes blunt.
Next come the functional requirements for the project, which include a detailed formulation of the product's purpose, function or behaviour, depending on what it is. This defines how the product must behave to meet the customer's needs. This serves as a guide for the team to develop, release and market the product.
Example:
The round blade of the cutting tool needs to be stowed away so that you don't accidentally cut yourself. A mechanism has to be developed to pull the blade out manually. Maybe this mechanism is so well developed compared to the competition that the product can be marketed well with it.
But non-functional requirements must also be mentioned. These include restrictions that have to be considered during the project, e.g. budget, time and resources. In part, these also influence each other, because if a resource in the form of a material is delayed, the production of the product is also delayed. Resource consumption in the form of materials is also part of service production.
Example:
It may be specified that the handle of the rotary cutter should be made of plastic and the blade of stainless steel.
In addition to all these requirements that relate to the product, there are also requirements that are intended to ensure cooperation between the parties involved in the project.
These include the contractual conditions, the requirements for the contractor and for the contractor's project management.
Contractual conditions include, for example, requirements for warranty, cancellation of the agreement, compensation, termination for cause and risk management. Worst-case scenarios do not always have to happen, but if one party fails to perform as defined, it is important to have a clear understanding of what would happen in the worst case and what the rights are.
Requirements for the contractor can be certain requirements for the staff, e.g. that they have certain certifications in a certain industry or that a certain procedure is used. Project management requirements may include how the project is to be documented, how communication between the parties is to take place, who the contact persons are and who the project managers are.
Procedure for drawing up the requirement specification
The creation of a requirement specification is very time-consuming because the exact description of the requirements takes a lot of time. However, if the requirements are very detailed, each party knows exactly what is required and it can be ensured that the end result of the project is a product or service that both parties are satisfied with. It also saves a lot of time that would otherwise have to be spent on any adjustments.
To create the requirement specifications, a brainstorming session can be held with the key participants. In this process, they collect all the requirements that they consider important for the project. Once all the requirements have been collected, they must be summarised in the specifications. There are several ways to do this: On the one hand, there are suppliers who provide a template, but it may also be that a template already exists in the company. If one does not yet exist and you want to create one yourself, the most important points from the brainstorming should definitely be filtered out and listed, as these can serve as the basis for creating a new document. Graphical representations and tables can help to illustrate the requirements. In this way, the document does not only consist of continuous text, but is loosened up.
However, it is not only important to list all requirements, but also to pay attention to formal requirements. These include the creator, the contact person, the date, a history of changes as well as a table of contents. It would be ideal if there were space in this file for the contractor's notes on each item listed, for the functional specifications. In this way, the potential contractor's answer to each point is immediately available.
To create the requirement specifications, a brainstorming session can be held with the key participants. In this process, they collect all the requirements that they consider important for the project. Once all the requirements have been collected, they must be summarised in the specifications. There are several ways to do this: On the one hand, there are suppliers who provide a template, but it may also be that a template already exists in the company. If one does not yet exist and you want to create one yourself, the most important points from the brainstorming should definitely be filtered out and listed, as these can serve as the basis for creating a new document. Graphical representations and tables can help to illustrate the requirements. In this way, the document does not only consist of continuous text, but is loosened up.
However, it is not only important to list all requirements, but also to pay attention to formal requirements. These include the creator, the contact person, the date, a history of changes as well as a table of contents. It would be ideal if there were space in this file for the contractor's notes on each item listed, for the functional specifications. In this way, the potential contractor's answer to each point is immediately available.
Conclusion
The requirement specification is an essential project document that defines the requirements, goals and expectations for a product or service. It forms the basis for the entire project planning and implementation by setting clear guidelines for design, development and process. A well-developed requirement specification promotes communication between those involved, minimises misunderstandings, reduces subsequent changes and thus contributes significantly to the success of a project.
Author: IAPM internal
Keywords: Project management, Requirement specifications