Again and again, specifications and functional specifications are used synonymously in everyday life as well as in ERP projects, despite being completely different in their legal meaning. In this article, we will explain the meaning and explore the differences between a "requirements specification" and a "functional specification." Both documents essentially stand for requirements, for descriptions of one or more states, products or services to be expected. Nevertheless, the requirements specification and the functional specification have very different meaning in the context of contract management.
Table of Contents
- Requirements Specification Vs Functional Specification in ERP Selection
- Specifications
- When Are Specifications Necessary?
- What Must a Specification Contain?
- The Agile Specification - What Does it Mean?
- Structure of a Requirements Specification
- Project Completion
- Summary
Requirements Specification Vs Functional Specification in ERP Selection
Frequently, these two terms are readily articulated as being equivalents, even among ERP project managers. The task of this article is to deliver some clarity about these differences. First and foremost, it is about the specifications and the technical specifications to be provided by the business unit for a specification book. A requirement specification is, in general terms, an idea of services that are required (target concept or catalogue of requirements.) These define, in part, in great detail, the requirements of management in the context of reporting, of the employees and process owners concerned with regards to transactions, support of the processes by an ERP system, as well as those of the technical framework conditions. The requirements for a solution or the requirements for a software system that is to be used to control the company (e.g. ERP software) should be defined in a requirements specification. With its help, material and human resources are usually defined, planned and calculated.
Specifications
When Are Specifications Necessary?
Within the framework of the requirements of the management, corporate strategy and the I.T. strategy to be derived from it, the big line and the goals for the next few years are defined. For the conception of the requirements for a new software or a new ERP solution, it is absolutely necessary to derive the requirements from the corporate strategy and to document them. All requirements always have in the background the business processes to be supported to the customer, the customer service and thus describe the organisational model.
Especially for the management (as the client for the I.T.), this document is therefore important for checking the degree of implementation of the corporate strategy by a specialist department. As a decisive requirements document, the created requirements specification serves as a quality gate for the release of the requirements. With this, the search for an implementation partner (software house) can begin. The requirements specification is a document that formulates an idea (business process) and framework conditions, but does not necessarily specify a solution in detail.
Nevertheless, the requirement specification naturally contains technical and content-related specifications (the entire documentation from the requirement engineering), which describe which business processes are to be supported and which goals are to be achieved with a new software. These can be specifications for ERP software, CRM, master data management systems or entire process chains such as the definition of a (customer-specific) supply chain.
Ideally, the requirements specification is structured in such a way that it gives the contractor (the software company or software service provider) the opportunity to select solutions from the pool of its software. To identify the software processes of a solution that fit the requirements and to work out the ideal solution (configuration) with their experience and combined with best practice approaches.
In contrast to a concept, a specification is always functionally defined by a client (for example, the executive board, the management or a project sponsor from the business sector) and created by the client. It specifically defines the requirements for the organisational model (the business process) and requirements for the technology and recognisable interfaces that should be defined in it.
In exceptional cases, specifications are also created by software suppliers, however, this should be critically questioned and checked. Can the client be sure that he will get the best solution or only one where the capabilities of the software supplier may limit the range of services?
What Must a Specification Contain?
Usually, the requirements in an ERP specification are represented by text descriptions of the requirements and by process descriptions. These can include drawings, tables, flow charts and diagrams.
Tip: Years ago, the experts at Dreher Consulting began to define and incorporate Key Performance Indicators (KPIs) within the specifications. These help our customers to clearly address the requirements for process quality and process efficiency as a definition to the software supplier.
The Agile Specification - What Does it Mean?
This Agile method of requirements specification is being increasingly used in companies. It must be taken into account however, that defining requirements through an agile approach can still bring some organisations to the limits of their capabilities today. The organisation, the requirement engineering, the sprints, the cooperation of the teams, the error culture and the change management must be designed for this. A separate article will be published offering guidance on the topic of agile specifications.
FREE INFOGRAPHIC
If you like this article, take a look at our Infographic summary!
Structure of a Requirements Specification
As a rule, the classic requirements specification is structured according to the following scheme (and suggestion for a table of contents):
Introduction
- Goals of the project and documentation
- Product description (process management)
- Description of the actual state
- Description of the target or target state
- Description of the interfaces
- Product details
- Functional requirements
- Performance and data quality requirements (process KPIs)
- Technical basis and technical environment in which the ERP software is to be integrated
- Requirements for the quality of the solution and the documentation
- Description of the operation of the solution
When drawing up the ERP specifications, it is important to give the software solution provider the opportunity to contribute its expertise to the I.T. project at a later stage. Therefore, it usually does not make sense to stick to a selection method with functional descriptions, as they are usually defined by internet-based selection tools or by endless Excel lists. This applies in the same context to software selection platforms. The key to a successful ROI and thus to a successful project lies in the support of the business processes. This cannot yet be mapped by tools or selection algorithms.
Companies that want to sustainably assert themselves in a digital environment will be more successful if they focus on process selection and define measurable key figures for this.
Already at the beginning of the identification stage of software suppliers with whom an ERP project or another software solution is to be introduced, a systematic selection process is initiated. This leads to the qualitatively demanding identification of a software supplier. In further steps, an increasingly narrow qualification process is carried out. At the end of this neutral ERP selection process, this leads to the commissioning of a supplier. This step-by-step process or procedure model will not be dealt with in this article, which is about the comparison of requirements specifications versus functional specifications.
The requirements specification is usually followed by the functional specification. Once the requirements specification has been drawn up, it is converted into a functional specification. The target values are fixed. They have been defined at a high level in the corporate and I.T. strategy and have been broken down to the working level in the documentation. In addition, KPI's (Key Performance Indicators) are defined to measure the process quality.
Together with the software provider, the scope of services of the software solution (when purchasing standard software) is compared with the specifications and then enriched with the experiences from best practice approaches of the contractor (software supplier) with this experience and information. This illustrates the essential difference between the requirements specification and the specifications. This is also nicely visible in the illustration: from the requirements specification to the functional specification. The difference is defined by the enrichment of the content, represented here by the size of the area.
It is precisely defined where standards will be used and where individual programming will be necessary. In the case of exclusively individual programming, the scope of the programming results should be precisely defined, since it is not possible to fall back on the results of existing software. Here, accuracy and precision of the expected description of results is usually an important point in order to complete a project successfully.
It is also important to define the integration of the new software into the existing I.T. system and thus the exchange of information between the systems via interfaces in the existing software or linked databases. The necessary work in the context of data cleansing, extensions of master data and master data structures should also be described in a specification. The requirements for the hardware, the network (performance and security) as well as the data storage (database) must be defined in a requirements specification. The requirements for master data in the previous systems, their quality and the transfer to a new system should not be underestimated
Project Completion
Our experience has shown that it is useful and helpful to define the acceptance procedure and quality management in the specifications as well. This is not always easy, but it is worthwhile in any case, because then buyer and supplier know exactly when a service can be accepted.
On the basis of the requirements specification, the software provider then prepares an offer and then a contract document. Ideally, the requirements specification becomes part of the purchase contract.
Summary
In the requirements specification, business goals, technical and process requirements, graphics, tables and, where possible, process flows are described and specified. The software provider adds to the specification information on the capability of his solution, his methodology, the interfaces and the project methodology, defining them as a joint document between the client and the contractor (software house).
This turns a requirements specification into a functional specification with exacting details upon which an offer and subsequently a contract can be drawn up (of which the requirements specification is one important component).
The infographic "Requirements specification Vs Functional specification" shows in brief where the differences lay, who is responsible for each type of specification and what the objectives of the specifications are.
