Requirements specification: The basis for ERP implementation
The requirements specification – not to be confused with the functional specification – forms the basis for the successful implementation of an ERP system. In this requirements specification, the company describes which requirements the new system should satisfy. On this basis, ERP providers can in turn submit concrete offers for implementing suitable systems. The company's own staff will also use the requirements specification later to conduct tests and approvals. Find out here how it should be structured with regard to ERP implementation and what the differences to the Pflichtenheft are.
What is a requirements specification?
According to the DIN standard, the requirements specification includes the “comprehensive set of requirements for the deliveries and services of a contractor within a project” fixed by the client. If an ERP software is to be introduced in the company, the project team in the requirements specification thus determines what functions and properties are required – and for what goal. Subsequently, ERP providers can on this basis offer solution proposals for the implementation.
To ensure the requirements for the ERP system in the requirements specification can be defined as detailed as possible, the project managers should first address some fundamental questions:
- Why do we even need an ERP system in the company?
- What goals should the system implementation achieve?
- In which processes is there potential for optimization?
These base questions should clearly guide the later requirements that are recorded in the requirements specification. Ultimately, the project team expresses in this documentation which goals, strategies and processes should be optimally supported by the new ERP system.
Important: The requirements specification is not directed exclusively at the ERP provider. It also serves as a basis for later tests and acceptances. Therefore the project-responsible team must formulate the requirements specification in such a way that its own users can understand the content—including those who are not experienced ERP providers.
Structure of an ERP requirements specification
A clean structure of an ERP requirements specification is advisable in the first place because it makes the creation of the document itself easier. In addition, both the ERP provider's employees and the company's own staff navigate better in the requirements specification when the structure clearly organizes the requirements. The following structure is recommended:
1. Description of the company
2. Offered products/services and description of the market environment
3. USPs and core strengths
4. Presentation of the current IT landscape including the number of users
5. Description of the functional requirements
6. Timeline
7. Contact person
With this structure, project teams can ensure that software vendors correctly interpret the requirements listed in the requirements specification.
Requirements specification and functional specification: Differences
Even though the terms requirements specification and functional specification are sometimes used synonymously, a clear distinction must be made between the two documents. In general:
- The requirements specification describes the What and Why.
- The functional specification describes the How and With What.
First, the ERP-implementing company creates the requirements specification and describes which requirements the ERP system must fulfill in the company. Subsequently the ERP provider can explain in the Pflichtenheft how the company's requirements can be implemented.
After the creation of the requirements specification, the project team sends this to several ERP providers. This clearly simplifies the selection process for the company.
If the choice is a shortlist of two to four providers, a workshop with exactly these providers is held. As a result, the Pflichtenheft and a concrete offer for the ERP implementation are created. In it, the software provider precisely describes how the requirements profile of the requirements specification will be technically implemented. Thus the Pflichtenheft contains exact specifications regarding the software configuration, addressing the concrete use case in the company.
How should ERP requirements be described in the requirements specification?
On the basis of a concrete, specific requirements specification, the ERP provider can again describe a tailor-made Pflichtenheft. And this ultimately ensures that, with the new ERP system, the goals desired at go-live are achieved. Project teams must therefore ask themselves: “How should I structure the requirements specification so that our ERP-system requirements are as clear and comprehensible as possible?”
The essential challenge for the team is to choose the right level of information depth in the requirements specification:
- too superficial: If the description does not go deep enough, misunderstandings arise for the ERP provider. Also the company's own employees who will later use the requirements specification during testing and acceptance of the system will have numerous follow-up questions if the description is too superficial.
- too detailed: Yet a maximal level of detail is definitely not productive. If every eventuality is covered in the requirements specification, the ERP provider will hardly be able to manage the high scope and workload.
Thus it is important to create a good balance between depth of detail and efficient work effort. In general, processes and requirements should be described in a way that is understandable to outsiders. Unnecessary details divert from the essential content. Also the description of sprawling “can-have” functions that are not strictly needed is not productive. At the same time, standard features such as order-related invoice verification, which is needed in every company, should only be touched on briefly.
erplanner.com - Your Requirements Specification Generator
The preselection of suitable ERP vendors requires creating a requirements specification
The ERP Planner shows you, simply and for free, how the internally required specifications of a potential ERP system can be mapped in the requirements specification.
Solutions are in the Functional Specification
From the outset it was mentioned that the how belongs in the functional specification – and not in the requirements specification. However, in practice both terms are often only loosely distinguished. Time and again you will find in the requirements specifications already concrete solution paths for the implementation of the ERP software. Exactly this, however, remains reserved for the functional specification or the ERP provider who creates it. A banal example should illustrate where the listing of solution paths in the requirements specification would lead:
- A company wants to be able to create well-defined workflows with the ERP system.
- In these workflows, especially important steps should be highlighted in the company color „blue“.
- Suppose an ERP provider actually delivers perfectly suitable solutions for predefined workflows. However, steps here cannot be highlighted in blue, but only in other colors.
Conclusion: Requirements specification as the basis for ERP implementation
- In the requirements specification, project teams, which requirements the new ERP system must meet. On this basis the ERP provider selection process and also the later ERP implementation can in turn be simplified. It is important to formulate all requirements in a solution-neutral manner – how the requirements are implemented, that is described by the ERP provider later in the functional specification. If the structure of the requirements specification is built according to a structured and process-oriented pattern and against the backdrop of the actual goals of ERP implementation, the requirements specification is optimally formulated.
FAQ: Frequently Asked Questions about the Requirements Specification
What is a requirements specification?
The customer requirements specification is a central document in project management, in which the client formulates all requirements for a service or product to be delivered (such as a new ERP software). It describes comprehensively, what should be achieved and for what the solution is needed, but not yet, how this will be technically implemented.
What is the difference between a requirements specification and a functional specification?
The requirements specification is prepared by the client (customer) and defines the requirements and objectives ("What and Why"). The Pflichtenheft, on the other hand, is the supplier's (e.g., software provider) response to the requirements specification. It describes in detail the technical and functional implementation ("How") of the requested services.
Is there a standard for the requirements specification?
Yes, the term and the basic structure of the requirements specification in project management are standardized in Germany by DIN Standard 69901-5. This provides helpful guidance for its structure, even though in practice it is often adapted to sector-specific needs.
What contents must be included in a requirements specification?
A structured requirements specification should include at least the following points:
- The current situation (as-is state) and objective (to-be state).
- A detailed functional and performance description (must-have and nice-to-have requirements).
- Technical, legal, and organizational framework conditions.
- Scope of delivery, schedule, and acceptance criteria.
Why is the distinction between must-have and nice-to-have criteria important?
The prioritization of must-have criteria (mandatory) and nice-to-have criteria helps potential service providers calculate the effort precisely. For the client, it makes an objective comparison of different offers easier, since it becomes immediately clear which provider meets the absolute minimum requirements.
Who in the company is responsible for creating the requirements specification?
The responsibility lies with the client. Ideally, a cross-departmental project team (e.g., consisting of IT, functional departments, management, and possibly external consultants) jointly gathers the requirements to ensure that all relevant areas of the company are covered.
Is the requirements specification legally binding?
The requirements specification generally forms the basis for the invitation to tender and for subsequent contract negotiations. Once it is included in the contract or supplemented by the functional specification prepared by the contractor and approved by the customer, it becomes a binding basis for the contract.
How detailed should an ERP requirements specification be?
It should be as detailed as necessary, but as open as possible in its wording. The functional requirements and business processes must be clearly described so that the provider understands the scope. At the same time, it should leave room for the provider's expertise (best-practice solutions) on how the requirements can be optimally implemented in software.
What are the most common mistakes in creating the requirements specification?
Among the most common mistakes are unclear or contradictory formulations, the omission of important framework conditions (e.g., IT security requirements), the lack of clear prioritization, and the premature specification of technical solutions that unnecessarily restricts the provider's room for maneuver.
Does the requirements specification still serve a purpose after the project has started?
Yes, the requirements specification together with the functional specification is an important control instrument throughout the entire project. It serves as a checklist at the final acceptance of the system to verify whether all originally specified goals and functions were actually delivered.